Bidimensional iterated array aggregate causes gnat to crash

Hi,
I ask this here because apparently GCC Bugs - GNU Project is a joke, I have to mail to get an account to file a bug… Yeah sure mate.
The following line are the culprit:

A:  array (1 .. Maxindex, 1 .. Maxindex) of Integer := (for I in 1..MaxIndex => (for J in 1..MaxIndex => I * J));

With maxindex between 1 and say, 100 or whatever. Works with a loop, not with this expression.
The bug looks like this:

gcc -c -gnatdd testclok.adb
--> Reallocating lines table, size = 1000
--> Allocating new Source_File table, size = 30
--> Allocating new Sem.Scope_Stack table, size = 30
--> Reallocating lines table, size = 1000
--> Allocating new Elists table, size = 400
--> Allocating new Source_File table, size = 90
--> Allocating new Elists table, size = 800
--> Allocating new String_Chars table, size = 6250
--> Allocating new Lists table, size = 12000
--> Allocating new String_Chars table, size = 15625
--> Allocating new Elists table, size = 1600
--> Allocating new Elmts table, size = 2400
--> Allocating new Units table, size = 60
--> Allocating new Name_Chars table, size = 100000
--> Allocating new Name_Chars table, size = 200000
+===========================GNAT BUG DETECTED==============================+
| 14.2.0 (x86_64-pc-linux-gnu) GCC error:                                  |
| in gnat_to_gnu_entity, at ada/gcc-interface/decl.cc:464                  |
| Error detected at testclok.adb:41:50                                     |
| Compiling testclok.adb                                                   |
--> Allocating new Name_Entries table, size = 12000
--> Allocating new Name_Chars table, size = 205852
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .              |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact command that you entered.                              |
| Also include sources listed below.                                       |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

testclok.adb
cpuclock.ads

compilation abandoned
gnatmake: "testclok.adb" compilation error

If you know a good place to ask, tell me, I don’t see an Adacore github for gnat-gcc.

I ask this here because apparently GCC Bugs - GNU Project is a joke, I have to mail to get an account to file a bug… Yeah sure mate.

It’s not a joke, it’s serious. No one can force you to file a bug, but equally, if you don’t, it’ll be pure luck if it gets fixed. You had to sign up to post here, I’m pretty sure you need to sign up to be able to post on Github.

I tried to repeat this issue, but a minimal reproducer didn’t fail.

If you know a good place to ask, tell me, I don’t see an Adacore github for gnat-gcc.

There’s no Adacore github repo for GNAT; there’s a mirror of the GCC repo, but no way to post issues or pull requests. They have their own processes.

Here’s one of the better places to post; you could try StackOverflow. Or there’s Reddit. Or Gitter. Some people swear by IRC.

Here’s fine :slight_smile:
Ok please excuse my tone, but I found very funny that one had to send an email to someone to get an account, while making a github account is like, nearly immediate. Gnu’s websites in general aren’t the most modern I ever saw, let’s put it that way.

My gnat build is gnat_native_14.2.1_06bb3def, and here’s my minimal example:

pragma Ada_2022;
WITH Ada.Text_IO, Ada.Calendar;
use Ada.Text_IO;
WITH Ada.Integer_Text_IO;
WITH Ada.Float_Text_IO;

PROCEDURE TestClok IS
  SavedTime : Ada.Calendar.Time;
  subtype CPUSecond is float;
  PROCEDURE ResetCPUTime IS
  BEGIN
    SavedTime := Ada.Calendar.Clock;
  END ResetCPUTime;
  FUNCTION CPUTime RETURN CPUSecond IS
  BEGIN
    RETURN CPUSecond (Ada.Calendar."-"(Ada.Calendar.Clock,SavedTime));
  END CPUTime;
    TrialTime      : CPUSecond;   -- CPU time for each trial
  NumberOfTrial : CONSTANT Integer := 10000;
  Maxindex       : Integer := 1000;
BEGIN -- TestClok
  FOR Trial IN 1 .. NumberOfTrial LOOP   
    maxindex := maxindex + 1;
    ResetCPUTime;
    declare
      A : ARRAY (1 .. Maxindex, 1 .. Maxindex) OF Integer := (for I in 1..MaxIndex => (for J in 1..MaxIndex => I * J));
      use Ada.Float_Text_IO;
    begin
      TrialTime := CPUTime;
      Put (maxindex'Image);
      Put (TrialTime, Fore => 2, Aft => 7, Exp => 0);
      new_line;
    end;
  END LOOP;
END TestClok;

Godbolt replicates this with every compiler for the x86_64 from 12.1 on. It compiles successfully with 11.4 when I add the -gnat2020 compiler option, but I get a stack overflow or erroneous memory access error.

(Let me caveat that I didn’t check the error message very carefully. What I’ve replicated is that the compiler terminates with “GNAT BUG DETECTED” on each of those compilers.)

I’m very surprised this persists, because something like it has been around for a while: I happen to like this construction very much, encountered the same problem some years ago, and reported it. (Oddly, though, I can only find this one in bugzilla, which someone else reported, and I no longer have access to the email address I’d have used to report the original encounter.) I was sure it had been fixed.

(Looking more closely at the ticket: I may be mistaken that it’s the same; perhaps there’s a subtle difference, and likewise with the ticket I reported way back when. But they all involve the bidimensional iterated array aggregate.)

the overflow is to be expected.

It looks as though the error @cantanima found isn’t quite the same - the report shows an assertion failure, now we get a stack overflow (but the old report was using a pre-production compiler, they have more assertions enabled).

I managed to produce a minimal version,

pragma Ada_2022;

PROCEDURE TestClok IS
  PROCEDURE ResetCPUTime is null;
  Maxindex       : Integer := 100;
BEGIN -- TestClok
  ResetCPUTime;
  declare
    A : ARRAY (1 .. Maxindex, 1 .. Maxindex) OF Integer := (for I in 1..MaxIndex => (for J in 1..MaxIndex => I * J));
  begin
    null; -- new_line;
  end;
END TestClok;

where eliminating the call to ResetCPUTime eliminates the failure, as does replacing Maxindex by 100.

Do you think it’s worth adding this example to the PR? or raising a new one, and cross-referencing it?

1 Like

The overflow is unrelated to the expression and bug related. Your code stll produces the bug here, at the line with the aggregate.

See PR117018 (I see it’s now assigned, so it should end up fixed in GCC 15 – or just possibly in 14.3).

2 Likes

Do you have a reason for optimism? When I was searching for bugs I’d reported, I saw that some remain unresolved two years later.

I am unclear why you would expect someone somewhere somewhen to fix issues for you. Such work takes time, requires careful testing, code reviews,…
Bug reports are more useful as a way to get workaround suggestions from people (like Simon suggested, use stackoverflow for instance).
If you need actual fixes, then you likely should become a customer of the company that makes the compiler. Yes, this requires money, but why would you expect to get this for free ?
Simon has also numerous times in the past submitted actual patches. Those are of course way more likely to be noticed (though I would still recommend that you talk directly to the compiler vendor, rather than post on any online social network)

Not sure if you’re talking to me.
Personally I don’t expect anything. I just meant to post this somewhere someone is bound to notice it, and also see if others have the same issues, and if not then maybe changing version could suffice.

Yeah, I don’t know if this was directed at me, either, but if so I think it’s uncalled for, for several reasons.

I stated that a problem resembles some tickets I reported a few years, and if it was in fact the same, that it surprised me. I even mentioned that I thought it was fixed. I added that it might have been a different bug in fact.

I then said that I came across some bugs reported some years ago that remain unresolved two years later.

I did not express frustration that they weren’t solved. Surprise and frustration are not the same, let alone surprise and entitlement.

I have inquired with AdaCore multiple times, and AdaCore declines so much to give me, an individual developer, the time of day.*** It has been said (not by me) that AdaCore basically deals only with corporate customers.

If that policy has changed, then by all means let me know where I can acquire a license.

That said, I thought gnat was not, strictly speaking, an AdaCore product.

***To elaborate on this: I used to be a member of GAP, and as I was about to leave academia, I told the GAP contact that I would no longer qualify, but I would like to know about a regular license. I was given a sales representative’s name and email, and I duly emailed the representative. I never heard back. This was not my only such experience like that with AdaCore. I don’t really have a problem with that, by the way; I appreciate very much what AdaCore does. But it’s quite astonishing to be told that if I want immediate attention (which I didn’t ask for!) then I should pay for it (which I can’t!).

1 Like

I’ve had 3 or 4 bugs that I reported in the last year fixed. I think a lot of it has to do with the difficulty of the fix, the availability of workarounds, and the impact of the error. They have to prioritize and I would imagine outside of priority if it is a simple fix, they sometimes just do it if reasonable. I think maybe a better route would be to look at the number of fixes done vs outstanding bugs (whether or not the bugs are related to yours/similar to yours doesn’t necessarily indicate how easy they are to fix). You’ll probably see that they do fix a lot of things, it’s just hard to fix everything.

Side note: My intention in this post is not to disagree with you, just hoping to provide you some of my experience.

1 Like

I’m not sure frustration is coming from. I’ve also reported multiple compiler bugs before, and they’ve been fixed within a few months. The latest actually being related to initialization with array aggregates: 116190 – wrong finalization of anonymous array aggregate

Every single bug I’ve submitted has also had its fix back-ported to both version 13 and 14, so it’s possible this one will too.

1 Like

Thanks, and please don’t misunderstand, but I was just curious why @simonjwright was optimistic, as in, perhaps he had some particular insight on the needed fix. That really came off wrong somehow, but reading and rereading it, I just don’t see how…!

I was responding less specifically to your comment and more to the tone of the thread (“GCC Bugs - GNU Project is a joke”). I’ve been seeing that attitude in a few places (e.g. matrix) and I don’t get why.

Oh no, your post didn’t come off that way to me (that’s why I provided some examples on my end so you could see where the optimism was potentially coming from).

Just that if a PR is assigned to a maintainer, it stands a much better chance of getting resolved than if it isn’t. And within the last month, two PRs I raised have been resolved.

I don’t know what the criteria for backports are. Difficulty must be one factor.

1 Like