[Bug ada/109881] GNAT BUG DETECTED during RTL pass, raised TYPES.UNRECOVERABLE_ERROR

[gnugcc at marino dot st via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109881

--- Comment #2 from John Marino  ---
I found the problematic line.

I changed this line:
data_in := read_compressed_data (input_stream, planned, bytes_read);

to:
bytes_read := read_compressed_data (input_stream  => input_stream,
bytes_planned => planned,
data_in   => data_in);

and the read_compressed_data function was changed from:
   function read_compressed_data
 (input_stream  : not null SIO.Stream_Access;
  bytes_planned : Natural;
  bytes_read: out Natural) return data_in_type;

to:
   function read_compressed_data
 (input_stream  : not null SIO.Stream_Access;
  bytes_planned : Natural;
  data_in   : out data_in_type) return Natural;

The rearrangement of the function avoided the GNAT bug.

[Bug ada/109881] GNAT BUG DETECTED during RTL pass, raised TYPES.UNRECOVERABLE_ERROR

[gnugcc at marino dot st via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109881

--- Comment #1 from John Marino  ---
I commented out the "file_to_file_decompression" function and the GNAT BUG
disappeared.

[Bug ada/109881] New: GNAT BUG DETECTED during RTL pass, raised TYPES.UNRECOVERABLE_ERROR

[gnugcc at marino dot st via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109881

Bug ID: 109881
   Summary: GNAT BUG DETECTED during RTL pass, raised
TYPES.UNRECOVERABLE_ERROR
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnugcc at marino dot st
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55096
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55096=edit
The three ada source files requested in the GNAT BUG message

During development, I hit this error on GCC 11.2.0 and also got a very similar
one on Community 2020 (Windows).  It just happened so if a future change
resolves it, I'll reattach those source files.  


during RTL pass: expand
+===GNAT BUG DETECTED==+
| 11.2.0 (x86_64-raven-dragonfly6.2) GCC error:|
| in operand_subword_force, at emit-rtl.c:1806 |
| Error detected around
/home/marino/rvn-format/src/zstandard/zstandard-streaming_decompression.adb:249:8|
| 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).

/home/marino/rvn-format/src/zstandard/zstandard-streaming_decompression.adb
zstandard/zstandard-streaming_decompression.ads
zstandard/zstandard.ads

raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:407

commands that built it:
gcc -c unix/stat_opsc.c -o stat_opsc.o

PROG=/raven/share/raven/toolchain/ravensys-gcc/bin/gnatmake
${PROG} unrvn.adb -Izstandard -Iblake3 -Iunix -lzstd -largs -L/raven/lib
-lzstd_pic -lblake3_pic stat_opsc.o

[Bug ada/86211] GCC 8 ada cannot build GCC 7 ada

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86211

John Marino  changed:

   What|Removed |Added

 CC||gnugcc at marino dot st

--- Comment #4 from John Marino  ---
I hit this last night.
Classifying it as "unfortunate" is an understatement.
There's nothing consumers can do about it there's no states policy to maintain
the ability for the next GCC to build the previous one, but A) there probably
should be such a policy and B) hopefully even without policy this situation
should be actively and vigorously avoided.

So in the past, this worked: 5 -> 4.9, 6 -> 5, and 7 -> 6 
I was expecting 8 -> 7 (at least) to also work.  Disappointed that this is a
"WONTFIX" but apparently there's no simple fix.

[Bug ada/85635] typo in link.c for BSD platforms

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85635

--- Comment #12 from John Marino  ---
yeah, my problem is that I was thinking cpp was complaining this whole time,
but it was actually the c compiler.  Once I realized that, the misconception
cleared up.  My fault, should've known better.

And I should have been building gcc trunk more frequently so it would've been
caught before release.

[Bug ada/85635] typo in link.c for BSD platforms

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85635

--- Comment #10 from John Marino  ---
ah, i see you explained what technically happened in the comment above.  I
missed that at first.
That's how the QNX line was visibly limited to the BSD platforms then.  cpp
didn't consider it a macro.  got it.

[Bug ada/85635] typo in link.c for BSD platforms

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85635

--- Comment #9 from John Marino  ---
Those "many" people don't build gnat.  Very few people do according to the
testsuite results page.

link.c code was:

#if defined (__WIN32)
(block 1)
#elif defined (__hpux__)
(block 2)
#elif defined (__FreeBSD__) || defined (__DragonFly__) \
   || defined (__NetBSD__) || defined (__OpenBSD__)
   || defined (__QNX__)
(block 3)
#elif defined (__APPLE__)
(block 4)
#elif defined (__linux__) || defined (__GLIBC__)
(block 5)
#elif defined (_AIX)
(block 6)
#elif (HAVE_GNU_LD)
(block 7)
#elif defined (VMS)
(block 8)
#elif defined (__sun__)
(block 9)
#elif defined (__svr4__) && defined (__i386__)
(block 10)
#else
(block 11)
#endif


I don't see how it would have compiled on linux.  The cpp would have chocked on
__QNX__ check on the __linux__ platform just as it would for any of the BSDs. 
It wasn't a BSD-only issue.

[Bug ada/85635] typo in link.c for BSD platforms

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85635

--- Comment #7 from John Marino  ---
It's a condition ladder.
The windows and hpux conditions are first on the ladder.  The cpp bug would
have been short-circuited on those platforms.  For any platform that has the
condition test fall to BSD first would be broken.  E.g. __APPLE__, __linux__,
etc. which come afterwards.

All those conditions have to pass the BSD check; they would fail too.  The
subject should not be confusing once the code is seen.

Thanks for fixing it though.

[Bug ada/85635] gcc8+: typo in link.c renders gnat unbuildable on non-windows, non hpux

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85635

--- Comment #2 from John Marino  ---
I would think every condition after (e.g. __APPLE__, __linux__, _AIX) would
fail as well.  Wouldn't cpp abort on QNX before the __APPLE__ condition is
evaluated?

[Bug ada/85635] New: gcc8+: typo in link.c renders gnat unbuildable on non-windows, non hpux

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85635

Bug ID: 85635
   Summary: gcc8+: typo in link.c renders gnat unbuildable on
non-windows, non hpux
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnugcc at marino dot st
  Target Milestone: ---

There was a bug introduced at trunk@254573 on (2017-11-09 Pascal Obry
<o...@adacore.com>)

Specifically, a macro condition was modified improperly, resulting in a broken
build on gcc release 8.1 and trunk.

The following (obvious) patch needs to be applied to fix it:

--- gcc/ada/link.c.orig 2018-05-03 17:24:27 UTC
+++ gcc/ada/link.c
@@ -104,7 +104,7 @@ unsigned char __gnat_separate_run_path_o
 const char *__gnat_default_libgcc_subdir = "lib";

 #elif defined (__FreeBSD__) || defined (__DragonFly__) \
-   || defined (__NetBSD__) || defined (__OpenBSD__)
+   || defined (__NetBSD__) || defined (__OpenBSD__) \
|| defined (__QNX__)
 const char *__gnat_object_file_option = "-Wl,@";
 const char *__gnat_run_path_option = "-Wl,-rpath,";

[Bug ada/79542] [7/8 regression] ICE in add_gnat_descriptive_type_attribute

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79542

--- Comment #10 from John Marino  ---
The original updates by rguenth were lost by the bugzilla-wide data failure,
and the rework only fixed the target milestone.  I don't have permission to fix
the missing data, so I'm going to paste the contents of the email received so
someone else can:


8/14/2017 04:05
Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
   Target Milestone|7.2 |7.3
Summary|[7/8 regression] ICE in |[7 regression] ICE in
   |add_gnat_descriptive_type_a |add_gnat_descriptive_type_a
   |ttribute|ttribute
  Known to fail||7.2.0

[Bug ada/79542] [7/8 regression] ICE in add_gnat_descriptive_type_attribute

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79542

--- Comment #9 from John Marino  ---
That's great, although it seems to only have been applied to TRUNK (gcc 8).  I
know it is too late for gcc 7.2, but this changeset should still be backported
to the GCC 7.x branch as well.

[Bug ada/79542] [7/8 regression] ICE in add_gnat_descriptive_type_attribute

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79542

--- Comment #6 from John Marino  ---
It looks like the release of 7.2 is upcoming.  It would be really great if this
ICE/Regression is addressed for that release.  Is there any way to raise the
visibility on this issue to avoid missing a fix for 7.2?

[Bug ada/79542] [7/8 regression] GNAT bug box

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79542

John Marino  changed:

   What|Removed |Added

 CC||gnugcc at marino dot st

--- Comment #5 from John Marino  ---
I hit this bug using GCC 7.1.0 on the same package but different OS (DragonFly
x86_64 was used).

I understand there is a patch for review to fix this:
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02049.html

It was submitted in late May, so could somebody with approval authority take a
look at Pierre-Marie's patch?   It fixes an ICE and a regression on a release
so in my opinion it's relatively high priority.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405

--- Comment #29 from John Marino  ---
 The DFly malloc returned an 8-byte aligned chunk because the requested
structural size was not 16-byte aligned.  However, we agree that any allocation
>= 16 bytes should probably be 16-byte aligned.

I tested a patch that aligns 15 and few bytes at 8 and everything else at 16. 
With that patch, gcc-7 with Ada front-end builds successfully.  We'll push that
patch to the master branch and the current release.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405

--- Comment #28 from John Marino  ---
i can try.  we're actually discussing modifying how malloc works right now.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405

--- Comment #25 from John Marino  ---
I'm being told (one source) that that 16-byte alignment is not a x86-64 abi
requirement.  I don't know either way.  Do you have an iron-clad reference
about this requirement?

(Yes I know __gnat_malloc is libc malloc)

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405

--- Comment #22 from John Marino  ---
(gdb) p/x $rax
$1 = 0x800af0748

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405

--- Comment #20 from John Marino  ---
Dump of assembler code for function osint__file_name_hash_table__setX:
   0x004cbae0 <+0>: mov%edi,%eax
   0x004cbae2 <+2>: mov$0x80604837,%edx
   0x004cbae7 <+7>: push   %r12
   0x004cbae9 <+9>: imul   %edx
   0x004cbaeb <+11>:mov%edi,%r12d
   0x004cbaee <+14>:push   %rbp
   0x004cbaef <+15>:push   %rbx
   0x004cbaf0 <+16>:lea(%rdx,%rdi,1),%eax
   0x004cbaf3 <+19>:mov%edi,%edx
   0x004cbaf5 <+21>:sar$0x1f,%edx
   0x004cbaf8 <+24>:sar$0x9,%eax
   0x004cbafb <+27>:sub%edx,%eax
   0x004cbafd <+29>:imul   $0x3fd,%eax,%eax
   0x004cbb03 <+35>:sub%eax,%r12d
   0x004cbb06 <+38>:movslq %r12d,%r12
   0x004cbb09 <+41>:mov0x84fd80(,%r12,8),%rax
   0x004cbb11 <+49>:test   %rax,%rax
   0x004cbb14 <+52>:jne0x4cbb29

   0x004cbb16 <+54>:jmp0x4cbb50

   0x004cbb18 <+56>:nopl   0x0(%rax,%rax,1)
   0x004cbb20 <+64>:mov0x40(%rax),%rax
   0x004cbb24 <+68>:test   %rax,%rax
   0x004cbb27 <+71>:je 0x4cbb50

   0x004cbb29 <+73>:cmp(%rax),%edi
   0x004cbb2b <+75>:jne0x4cbb20

   0x004cbb2d <+77>:movdqa (%rsi),%xmm0
   0x004cbb31 <+81>:movaps %xmm0,0x10(%rax)
   0x004cbb35 <+85>:movdqa 0x10(%rsi),%xmm0
   0x004cbb3a <+90>:movaps %xmm0,0x20(%rax)
   0x004cbb3e <+94>:movdqa 0x20(%rsi),%xmm0
   0x004cbb43 <+99>:movaps %xmm0,0x30(%rax)
   0x004cbb47 <+103>:   pop%rbx
   0x004cbb48 <+104>:   pop%rbp
   0x004cbb49 <+105>:   pop%r12
   0x004cbb4b <+107>:   retq
   0x004cbb4c <+108>:   nopl   0x0(%rax)
   0x004cbb50 <+112>:   mov%rsi,%rbp
   0x004cbb53 <+115>:   mov%edi,%ebx
   0x004cbb55 <+117>:   mov$0x50,%edi
   0x004cbb5a <+122>:   callq  0x60dc40 <__gnat_malloc>
   0x004cbb5f <+127>:   movdqa 0x0(%rbp),%xmm0
   0x004cbb64 <+132>:   mov0x84fd80(,%r12,8),%rdx
   0x004cbb6c <+140>:   mov%ebx,(%rax)
=> 0x004cbb6e <+142>:   movaps %xmm0,0x10(%rax)
   0x004cbb72 <+146>:   movdqa 0x10(%rbp),%xmm0
   0x004cbb77 <+151>:   mov%rdx,0x40(%rax)
   0x004cbb7b <+155>:   movaps %xmm0,0x20(%rax)
   0x004cbb7f <+159>:   movdqa 0x20(%rbp),%xmm0
   0x004cbb84 <+164>:   mov%rax,0x84fd80(,%r12,8)
   0x004cbb8c <+172>:   movaps %xmm0,0x30(%rax)
   0x004cbb90 <+176>:   pop%rbx
   0x004cbb91 <+177>:   pop%rbp
   0x004cbb92 <+178>:   pop%r12
   0x004cbb94 <+180>:   retq
End of assembler dump.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405

--- Comment #18 from John Marino  ---
does this help?

Program received signal SIGBUS, Bus error.
0x004cbb6e in osint.file_name_hash_table.set (k=k@entry=31291,
e=...) at ../rts/s-htable.adb:381
381 Tab.Set (new Element_Wrapper'(K, E, null));
(gdb) bt
#0  0x004cbb6e in osint.file_name_hash_table.set (k=k@entry=31291,
e=...) at ../rts/s-htable.adb:381
#1  0x004cbc44 in osint.smart_find_file (n=31291, t=t@entry=source,
attr=...)
at
/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada/osint.adb:2839
#2  0x004cf4d5 in osint.smart_find_file (t=source, n=)
at
/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada/osint.adb:2814
#3  osint.full_source_name (n=) at
/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada/osint.adb:1382
#4  osint.next_main_file () at
/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada/osint.adb:2017
#5  0x004d1ca5 in osint.m.next_main_source () at
/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada/osint-m.adb:49
#6  0x004929a8 in make.gnatmake () at
/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada/make.adb:5847
#7  0x0045d015 in gnatmake () at
/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada/gnatmake.adb:38
#8  0x00403067 in main (argc=argc@entry=26,
argv=argv@entry=0x7fffeec8, envp=envp@entry=0x7fffefa0) at
b_gnatm.adb:554
#9  0x004032be in _start (ap=0x7fffeec0, cleanup=)
at /usr/src/lib/csu/x86_64/crt1.c:90

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405

--- Comment #17 from John Marino  ---
that's easier said than done.  The command is over 1600 characters long 

i'll try to script it but ...

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405

--- Comment #15 from John Marino  ---
to all:
I built August 28 snapshot of gcc7 with Ada frontend on FreeBSD 11.0-RC2, there
was no SIGBUS and it completed the build successfully.  (Not good news for DF I
guess)

to H.J.Lu:
There's a complete log showing where in the build the SIGBUG occurs but as far
as the assembly code that causes it, I have no idea.  If you provide me some
instructions on how, maybe I can get some useful information for you.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405

--- Comment #13 from John Marino  ---
I just want to remind that gcc 7 builds fine on DF when the Ada frontend is
excluded from the build.  That's partially why it took so long to see this
regression.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405

--- Comment #12 from John Marino  ---
I don't know.  If you have a specific question or a test case that illustrates
it, I can bring up the topic to the DF developers.

I don't know if we are pointing fingers at the OS or GCC though, only that this
commit introduces a regression.

[Bug ada/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405

--- Comment #10 from John Marino  ---
Okay, I bisected this.

SVN r239376 (August 11) is the last commit that works

I confirmed that r239378, the next commit on the TRUNK, fails to build,
resulting with the SIGBUS error.


The log for that commit is:
Use TImode for piecewise move in 64-bit mode.  We should use TImode in
32-bit mode and use OImode or XImode if they are available.  But since
by_pieces_ninsns determines the widest mode with MAX_FIXED_MODE_SIZE,
we can only use TImode in 64-bit mode.

gcc/

* config/i386/i386.h (MOVE_MAX_PIECES): Use TImode in 64-bit
mode if unaligned SSE load and store are optimal.

[Bug ada/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405

--- Comment #8 from John Marino  ---
if that attempt doesn't let you reproduce it, and if it still happens when I
remove that flag, I can start bisecting and see if I can get it to a specific
day or even commit that caused it.  That will obviously take some time though.

[Bug ada/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405

--- Comment #6 from John Marino  ---
oh, sorry, you're trying to bisect.

Unfortunately this is the first time I tried to build gcc 7.0 in this
configuration.  My previous builds were for gcc 6 and it's been several months
since I ran a test build.

I build gcc 7.0-devel all the time as a "port" along with 24,000 other ports,
but that version of gcc-7 doesn't include the Ada compiler.

[Bug ada/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405

--- Comment #4 from John Marino  ---
from the attached log:
"Updated to revision 239832."

It will be awhile before I can retry without that no-strict-alias flag but I
will say all the test reports I've submitted over the last year have been built
with it without any prior issue.

[Bug ada/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405

--- Comment #1 from John Marino  ---
Created attachment 39515
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39515=edit
gzipped build log

[Bug ada/77405] New: SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405

Bug ID: 77405
   Summary: SIGBUS from gnatmake in stage 3 (gcc 7.0)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnugcc at marino dot st
  Target Milestone: ---

(cd tools; ln -s ../sdefault.adb ../snames.ads ../snames.adb .)
libtool: compile:  /home/marino/iterate-gcc-test/scratch/build/./gcc/xgcc
-B/home/marino/iterate-gcc-test/scratch/build/./gcc/ -B/u
libtool: compile:  /home/marino/iterate-gcc-test/scratch/build/./gcc/xgcc
-B/home/marino/iterate-gcc-test/scratch/build/./gcc/ -B/u
rm -f tools/mlib-tgt-specific.adb; ln -s
/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada/mlib-tgt-specific-linux.adb
touch ../stamp-tools
../../gnatmake -j0 -c -b -I- -I../rts -I.
-I/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada \
  --GNATBIND="../../gnatbind" --GCC="../../xgcc -B../../ -g -pipe -O2
-DLIBICONV_PLUG -fno-strict-aliasing -W -Wall  -gnatpg -gnata
  gnatchop gnatcmd gnatkr gnatls gnatprep gnatxref gnatfind gnatname \
  gnatclean -bargs -I- -I../rts -I.
-I/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada -static -x
raised STORAGE_ERROR : SIGBUS: possible stack overflow

gnatmake: INTERNAL ERROR. Please report.
gmake[4]: *** [../gcc-interface/Makefile:2647: common-tools] Error 4
gmake[4]: Leaving directory
'/build/home/marino-huge/gcc-test-area/build/gcc/ada/tools'
libtool: compile:  /home/marino/iterate-gcc-test/scratch/build/./gcc/xgcc
-B/home/marino/iterate-gcc-test/scratch/build/./gcc/ -B/u
gmake[3]: *** [Makefile:197: gnattools-native] Error 2
gmake[3]: Leaving directory
'/build/home/marino-huge/gcc-test-area/build/gnattools'
gmake[2]: *** [Makefile:12496: all-gnattools] Error 2
gmake[2]: *** Waiting for unfinished jobs


This is repeatable.  The final time I tried with -j2 (down from -j8).
I'll upload the entire log.  GCC 6.1 was used for the first stage, but by stage
3, GCC should be building itself.  (DragonFly host 4.7)

[Bug ada/68345] gnat build broken on dragonfly due to omission of r229342

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68345

--- Comment #4 from John Marino  ---
Hi Arno,

I made the same exact change internally.  It built and the full testsuite was
run afterwards:


=== acats Summary ===
# of expected passes2320
# of unexpected failures0
Native configuration is x86_64-test-dragonfly4.3

=== g++ tests ===

Running target unix

=== gnat Summary ===

# of expected passes2467
# of expected failures  21
# of unsupported tests  5
/build/home/marino-huge/gcc-test-area/build/gcc/gnatmake version 6.0.0 20151114
(experimental)

=== objc tests ===


I think it would be okay to just "blindly" make the same changes to DragonFly
that you do for FreeBSD in the future.  It will almost always be the correct
thing, and if it isn't I'll still catch it with regular build checks.

Thanks for the quick fix,
john

[Bug ada/68345] New: gnat build broken on dragonfly due to omission of r229342

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68345

Bug ID: 68345
   Summary: gnat build broken on dragonfly due to omission of
r229342
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnugcc at marino dot st
  Target Milestone: ---

Due to waiting on big locale patch, I haven't been testing gcc regularly.  I
just did today and gnat files to build on dragonfly:

s-taprop.adb:326:32: ambiguous operand in conversion
s-taprop.adb:326:32: possible interpretation at s-osinte.ads:333
s-taprop.adb:326:32: possible interpretation at s-osinte.ads:334
s-taprop.adb:981:52: ambiguous operand in conversion
s-taprop.adb:981:52: possible interpretation at s-osinte.ads:333
s-taprop.adb:981:52: possible interpretation at s-osinte.ads:334
../gcc-interface/Makefile:311: recipe for target 's-taprop.o' failed
gmake[8]: *** [s-taprop.o] Error 1


the reason is that Get_Page_Size was changed to return an int, and this was
done for a number of systems except dragonfly:

https://gcc.gnu.org/viewcvs/gcc?view=revision=229342

The same change done on s-osinte-freebsd.ads by r229342 needs to be done on
s-osinte-dragonfly.ads

DragonFly is an officially (and well) supported system on GCC!  It should not
be omitted like this.

[Bug libstdc++/67096] libstdc++ testsuite, codecvt: many UTF-8 tests illegal (testing bytes 5 and 6)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67096

--- Comment #4 from John Marino  ---
Created attachment 36332
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36332=edit
codecvt/max_length/wchar/4.cc patch

codecvt/max_length/wchar/4.cc test thinks that 6 is the maximum byte size for
UTF-8 and fails if it detects lengths less than 6 bytes.

Of course, the true limit is 4 bytes, so the test needs to be changed from 6 to
4.

It is related to the tests this PR fixed (same problem, different form).

[Bug libstdc++/67096] libstdc++ testsuite, codecvt: many UTF-8 tests illegal (testing bytes 5 and 6)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67096

--- Comment #5 from John Marino  ---
Hmmm, thinking about this, I'd bet Linux would FAIL this test.  It probably
does allow 6-bytes (even though it should not) and thus K would return 6.

I don't really have a recommendation -- the standard is pretty clear, 4 bytes
is the maximum for UTF-8, so it probably should fail on Linux.

Or maybe this whole test should just be removed?  What's it really testing that
the other tests haven't already?

[Bug c++/58583] [c++11] ICE with invalid non-static data member initialization in template

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58583

John Marino gnugcc at marino dot st changed:

   What|Removed |Added

 CC||gnugcc at marino dot st

--- Comment #6 from John Marino gnugcc at marino dot st ---
so apparently this patch caused a lot of failures:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01062.html

However, I don't see people complaining anymore, nor do I see it on other
testsuite result posts.

However, we're still seeing this on DragonFly:
https://gcc.gnu.org/ml/gcc-testresults/2015-08/msg00196.html

What was the final conclusion?
Is it a dejagnu problem or what?

[Bug libstdc++/67096] libstdc++ testsuite, codecvt: many UTF-8 tests illegal (testing bytes 5 and 6)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67096

--- Comment #1 from John Marino gnugcc at marino dot st ---
Created attachment 36108
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36108action=edit
modification to test that makes it legal

As an illustration, I've modified the test to stop before 0x20 which
results in success for transforms that are strict.

[Bug libstdc++/67096] New: libstdc++ testsuite, codecvt: many UTF-8 tests illegal (testing bytes 5 and 6)

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67096

Bug ID: 67096
   Summary: libstdc++ testsuite, codecvt: many UTF-8 tests illegal
(testing bytes 5 and 6)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnugcc at marino dot st
  Target Milestone: ---

Using the pending locale patch set for DragonFly[1], I've been running
testsuite frequently.  After an update to libc to support LC_CTYPE better, we
suffered a large test regression.

For example, 22_locale/codecvt/length/wchar_t/4.cc started failing.

I modified the test noting that as long as int_type is limited to  0x20,
the test passes.  If it's over 0x20, it fails.  This test, and many similar
to it tests:
  0x20
  0x40
  0x80
  0x100
  0x200
  0x400
  0x800
  0x1000
  0x2000
  0x4000

The reason for the failure is the libc rejects  4 bytes as illegal, as it
should.

According to wiki[2]: 
The original specification covered numbers up to 31 bits (the original limit
of the Universal Character Set). In November 2003, UTF-8 was restricted by RFC
3629 to end at U+10, in order to match the constraints of the UTF-16
character encoding. This removed all 5- and 6-byte sequences, and about half of
the 4-byte sequences.

The test is setting the locale to en_US.UTF-8 which by definition is limited
to 4-byte numbers.  Thus, testing any number 0x20 or greater is illegal and
should not be done.  This probably affects several tests that are making the
same mistake.

[1] https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02678.html
[2] https://en.wikipedia.org/wiki/UTF-8

[Bug ada/66965] New: gnat.dg/specs/addr1.ads obsolete -- failing on trunk

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66965

Bug ID: 66965
   Summary: gnat.dg/specs/addr1.ads obsolete -- failing on trunk
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnugcc at marino dot st
  Target Milestone: ---

the gnat.dg/specs/addr1.ads test has been failing for weeks because the
warnings have changed.

Line 30 is for Obj4'Address use A(2)'Address; -- { dg-warning
(alignment|erroneous) } but 4 lines of warnings are generated, so an excess
warning failure is coming up.

I don't know dejagnu syntax well enough to suggest a fix.

see: https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg02157.html

Note that acats and gnat.dg are now regularly tested on DragonFly and posted in
the gcc-testresults mail list.

[Bug ada/65451] gnat bug: Storage_Error stack overflow or erroneous memory access

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451

--- Comment #4 from John Marino gnugcc at marino dot st ---
Created attachment 35054
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35054action=edit
gzipped archive of matreshka source files

I created a tarball of the source files rather than concatenate.  I thought
that would be more flexible.

[Bug testsuite/60794] 25 libstdc++ tests are missing '{ dg-require-debug-mode }'

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60794

John Marino gnugcc at marino dot st changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from John Marino gnugcc at marino dot st ---
report was invalid, closing.

[Bug ada/65451] New: gnat bug: Storage_Error stack overflow or erroneous memory access

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451

Bug ID: 65451
   Summary: gnat bug: Storage_Error stack overflow or erroneous
memory access
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnugcc at marino dot st
  Host: x86_64-unknown-dragonfly4.1
Target: x86_64-unknown-dragonfly4.1
 Build: x86_64-unknown-dragonfly4.1

I was testing the latest gcc-5 snapshot against FreeBSD Ada ports (which
DragonFly uses).  I am seeing an intermittent GNAT BUG error on the Matreshka
port ( http://freshports/devel/matreshka ):

ada -c -fPIC -g -gnatwa -gnat12 -gnatW8 -O2 -gnatn
matreshka-internals-strings.adb
+===GNAT BUG DETECTED==+
| 5.0.0 20150315 (experimental) -= GNAT AUX [DragonFly64]
(x86_64-aux-dragonfly4.1) |
| Storage_Error stack overflow or erroneous memory access  |
| Error detected at matreshka-internals-utf16.adb:45:33|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| 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).

/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-strings.adb
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-strings.ads
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals.ads
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka.ads
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/league.ads
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-atomics.ads
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-atomics-counters.ads
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-unicode.ads
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-unicode-ucd.ads
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-utf16.ads
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-atomics-generic_test_and_set.ads
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-strings-configuration__x86_64.ads
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-strings-handlers.ads
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/arch/x86_64/matreshka-internals-strings-handlers-x86_64.ads
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-strings-handlers-portable.ads
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/arch/x86_generic/matreshka-internals-strings-handlers-generic_x86_sse2.ads
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/arch/x86_generic/matreshka-internals-strings-handlers-x86_utilities.ads
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-atomics-generic_test_and_set__gcc__64.adb
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-atomics-counters__gcc.adb
/wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-utf16.adb

compilation abandoned
gprbuild: *** compilation phase failed
Makefile.build:36: recipe for target 'league' failed
gmake[2]: *** [league] Error 4
gmake[2]: Leaving directory '/wrkdirs/devel/matreshka/work/matreshka-0.6.0'
Makefile:21: recipe for target 'all' failed
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory '/wrkdirs/devel/matreshka/work/matreshka-0.6.0'
*** Error code 1

I suspect this isn't enough information to diagnose anything.  The link to the
source is found on the freshports site, and some patches are in the svn repo. 
There are an additional three patches that I was testing that are needed to
build on gcc-5 (e.g. missing explicit limited keyword patch)

I just want to get this documented for now.  Let me know what I can provide to
help troubleshoot it.

[Bug ada/65451] gnat bug: Storage_Error stack overflow or erroneous memory access

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451

--- Comment #1 from John Marino gnugcc at marino dot st ---
Note that I saw this on 20150308 snapshot with Matreshka too in a different
file.  That snapshot also failed on building OpenToken with a GNAT BUG, but
OpenToken builds fine with 20150315 snapshot.

[Bug ada/65451] gnat bug: Storage_Error stack overflow or erroneous memory access

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451

--- Comment #2 from John Marino gnugcc at marino dot st ---
right url for freshports: http://www.freshports.org/devel/matreshka

[Bug c++/65292] Template function not emitted

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65292

--- Comment #8 from John Marino gnugcc at marino dot st ---
As a final follow up, webkit-qt5 built on a March 8 version of gcc5 with no
changes from my previous attempt.  

Good news, thanks for the patch!
John

[Bug c++/65292] Template function not emitted

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65292

--- Comment #6 from John Marino gnugcc at marino dot st ---
Thanks Khem,

With your patch, webkit-qt5 continued to build on gcc7 (good news) but I did
not succeed with gcc-5.  The new error during linking is:

/usr/libexec/binutils224/elf/ld.bfd:
/wrkdirs/www/webkit-qt5/work/.build/Source/WebCore/release/libWebCore.a(MediaController.o):
relocation R_X86_64_PC32 against undefined hidden symbol
`_ZNK7WebCore16HTMLMediaElement8hasVideoEv' can not be used when making a
shared object
/usr/libexec/binutils224/elf/ld.bfd: final link failed: Bad value
Makefile.api:111: recipe for target '../lib/libQt5WebKit.so.5.3.2' failed

But libJavaScriptCore issue was fixed, thanks!

[Bug c++/65292] Template function not emitted

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65292

--- Comment #7 from John Marino gnugcc at marino dot st ---
typo -- it was gcc 4.7, not gcc7 that succeeded.  (I say that to help answer
the question in the QT5 bug report)

[Bug c++/65292] Template function not emitted

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65292

John Marino gnugcc at marino dot st changed:

   What|Removed |Added

 CC||gnugcc at marino dot st

--- Comment #4 from John Marino gnugcc at marino dot st ---
Khem, I've also just discovered gcc-5 won't build webkit anymore.  If you have
already come up with a patch for libJavaScriptCore, could you share it here?

[Bug libgcc/61309] cilk-plus tests fail with: hidden symbol `__cpu_model' in /x/gcc/testsuite/g++/../../libgcc.a(cpuinfo.o) is referenced by DSO

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61309

--- Comment #5 from John Marino gnugcc at marino dot st ---
hmmm, I added t-freebsd to the tmake list in libgcc/config.host for dragonfly. 
I thought it would fix the problem but I'm still seeing hidden symbol errors
for __cpu_model

[Bug libgcc/61309] cilk-plus tests fail with: hidden symbol `__cpu_model' in /x/gcc/testsuite/g++/../../libgcc.a(cpuinfo.o) is referenced by DSO

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61309

--- Comment #4 from John Marino gnugcc at marino dot st ---
I suspect the reason it works on FreeBSD is found on libgcc/config.host,
specifically the inclusion of t-freebsd in tmake_file definition.

t-freebsd for i386 add the symbol map $(srcdir)/config/i386/libgcc-bsd.ver
which defines __cpu_model for gcc48 and higher.

DragonFly probably needs the same symbol map.

[Bug libgcc/61309] cilk-plus tests fail with: hidden symbol `__cpu_model' in /x/gcc/testsuite/g++/../../libgcc.a(cpuinfo.o) is referenced by DSO

[gnugcc at marino dot st]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61309

--- Comment #2 from John Marino gnugcc at marino dot st ---
FYI, this is still happening.
So if/when DragonFly features libgcc_s from 5.0 in base, these errors will go
away?

If so, doesn't that imply the linking is making assumptions it should not make?

[Bug libgcc/61097] New: Solaris linker change broke --disabled-shared support

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61097

Bug ID: 61097
   Summary: Solaris linker change broke --disabled-shared support
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnugcc at marino dot st

Regarding the patch [build, libgcc] Ensure libgcc_s unwinder is always used on
64-bit Solaris 10+/x86 (PR target/59788)
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01088.html

This change seems to have broken the --disabled-shared support for the native
solaris linker.

I am seeing this error on GCC 4.9.0 with that option set.
 gmake[5]: Entering directory
 /mech/pkgsrc-work/lang/gcc-aux/work/build/x86_64-aux-solaris2.11/32/libgcc'
 # If this is the top-level multilib, build all the other gmake[5]: *** No
 rule to make target 'libgcc-std.ver', needed by 'libgcc-unwind.map'.
 Stop.

It is caused by libgcc/config/t-slibgcc-sld excerpt:

 # Linker mapfile to enforce direct binding to libgcc_s unwinder
 # (PR target/59788).
 libgcc-unwind.map: libgcc-std.ver
 @(echo {; \
 for f in `grep _Unwind_ $ | sort`; do  \
   echo $$f = EXTERN DIRECT;;  \
 done;   \
 echo }; )  $@


But the libcgcc-std.ver target is only exposed on the condition that shared
library building is enabled per libgcc/Makefile.in:

 ifeq ($(enable_shared),yes)

 # Map-file generation.
 ifneq ($(SHLIB_MKMAP),)
 libgcc.map: $(SHLIB_MKMAP) $(SHLIB_MAPFILES) $(libgcc-s-objects)
 { $(NM) $(SHLIB_NM_FLAGS) $(libgcc-s-objects); echo %%; \
   cat $(SHLIB_MAPFILES) \
 | sed -e '/^[   ]*#/d' \
   -e 's/^%\(if\|else\|elif\|endif\|define\)/#\1/' \
 | $(gcc_compile_bare) -E -xassembler-with-cpp -; \
 } | $(AWK) -f $(SHLIB_MKMAP) $(SHLIB_MKMAP_OPTS)  tmp-$@
 mv tmp-$@ $@
 libgcc_s$(SHLIB_EXT): libgcc.map
 mapfile = libgcc.map
 endif

 libgcc-std.ver: $(srcdir)/libgcc-std.ver.in
 sed -e 's/__PFX__/$(LIBGCC_VER_GNU_PREFIX)/g' \
 -e 's/__FIXPTPFX__/$(LIBGCC_VER_FIXEDPOINT_GNU_PREFIX)/g'  $  
 $@


I found that moving the libgcc-std.ver target above the ifeq
($(enable_shared),yes) line to expose it unconditionally allowed the build to
continue.

[Bug bootstrap/61104] New: Solaris configured without --with-system-zlib fails due to extra folder depth of multi-lib

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61104

Bug ID: 61104
   Summary: Solaris configured without --with-system-zlib fails
due to extra folder depth of multi-lib
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnugcc at marino dot st

The situation is that gcc is configured on x86-64 solaris for a full multilib
bootstrap with no --with-system-zlib input passed.

For completeness, the full configuration is here:

$ /mech/pkgsrc-work/lang/gcc-aux/work/gcc-4.9.0/configure 
 --enable-languages=c ada c++ --build=x86_64-aux-solaris2.11 
 --prefix=/usr/pkg/gcc-aux --enable-threads=posix --disable-libmudflap 
 --disable-libgomp --disable-libssp --disable-libquadmath --disable-nls 
 --disable-shared --disable-lto --disable-libstdcxx-pch --enable-multilib 
 --with-gnu-as --with-as=/usr/pkg/bin/gas 
 --without-gnu-ld --with-ld=/usr/bin/ld


The build breaks in stage 2 here:

Configuring stage 2 in ./libbacktrace
Adding multilib support to Makefile in /mech/pkgsrc-work/lang/gcc-aux/work/gcc-
multidirs=32
with_multisubdir=
Running configure in multilib subdirs 32
pwd: /mech/pkgsrc-work/lang/gcc-aux/work/build/zlib
Running configure in multilib subdir 32
pwd: /mech/pkgsrc-work/lang/gcc-aux/work/build
mkdir 32
configure: creating cache ./config.cache
checking build system type... x86_64-aux-solaris2.11
checking host system type... x86_64-aux-solaris2.11
checking target system type... x86_64-aux-solaris2.11
checking for x86_64-aux-solaris2.11-gcc...  /mech/pkgsrc-work/lang/gcc-aux/work
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether  /mech/pkgsrc-work/lang/gcc-aux/work/build/./prev-gcc/xgcc -B/
checking for  /mech/pkgsrc-work/lang/gcc-aux/work/build/./prev-gcc/xgcc -B/mech
checking how to run the C preprocessor... configure: creating cache ./config.ca
checking build system type...  /mech/pkgsrc-work/lang/gcc-aux/work/build/./prev
x86_64-aux-solaris2.11
checking host system type... checking for grep that handles long lines and -e..
checking target system type... /bin/ggrep
checking for egrep... /bin/ggrep -E
checking for ANSI C header files... x86_64-aux-solaris2.11
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for x86_64-aux-solaris2.11-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /mech/pkgsrc-work/lang/gcc-aux/work/gcc-
checking for gawk... gawk
checking whether /usr/pkg/bin/gmake sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for x86_64-aux-solaris2.11-gcc... /mech/pkgsrc-work/lang/gcc-aux/work/
yes
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... checking for suffix of object fil
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Makefile:12599: recipe for target 'configure-stage2-zlib' failed
gmake[2]: *** [configure-stage2-zlib] Error 1
gmake[2]: *** Waiting for unfinished jobs


The build/32/zlib/config.log contains this bit:

configure:3444: checking for suffix of object files
configure:3466: /mech/pkgsrc-work/lang/gcc-aux/work/build/32/./prev-gcc/xgcc
-B/
mech/pkgsrc-work/lang/gcc-aux/work/build/32/./prev-gcc/
-B/usr/pkg/gcc-aux/x86_6
4-aux-solaris2.11/bin/ -B/usr/pkg/gcc-aux/x86_64-aux-solaris2.11/bin/
-B/usr/pkg
/gcc-aux/x86_64-aux-solaris2.11/lib/ -isystem
/usr/pkg/gcc-aux/x86_64-aux-solari
s2.11/include -isystem /usr/pkg/gcc-aux/x86_64-aux-solaris2.11/sys-include 
-m32
 -c -g -O2  conftest.c 5
/mech/pkgsrc-work/lang/gcc-aux/work/gcc-4.9.0/zlib/configure[3468]: eval[1]:
/me
ch/pkgsrc-work/lang/gcc-aux/work/build/32/./prev-gcc/xgcc: not found [No such
fi
le or directory]
configure:3470: $? = 127
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME 
| #define PACKAGE_TARNAME 
| #define PACKAGE_VERSION 
| #define PACKAGE_STRING 
| #define PACKAGE_BUGREPORT 
| #define PACKAGE_URL 
| #define PACKAGE zlib
| #define VERSION 1.1.4
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3484

[Bug ada/60411] Ada bootstrap failure on ARM

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411

--- Comment #24 from John Marino gnugcc at marino dot st ---
(In reply to Eric Botcazou from comment #22)
  Does this mean effectively nothing lower than ARMv7 can build
  arm-*-linux-androideabi?
 
 Apparently so, but it should be quite easy to fix this in
 sigtramp-armdroid.c by means of some preprocessor magic.

This statement is a little ambiguous to me, which is the current situation?

A) There are no plans to alter sigtramp-android.c to support ARM architectures
below ARMv7.  Patches would be accepted though.
B) There are no plans to alter sigtramp-android.c to support ARM architectures
below ARMv7.  Patches will not be accepted, so to support ARMv5 requires local
modification
C) We are planning to alter sigtramp-android.c to support earlier ARM
architectures, please be patient!

If scenario C, when / what version of GCC?

Thanks!

[Bug libstdc++/60793] Add target *-*-dragonfly* to dg-options on 172 libstdc++ tests

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60793

--- Comment #6 from John Marino gnugcc at marino dot st ---
(In reply to Jonathan Wakely from comment #5)
 It's not that I don't believe you that it's needed, it's that we want to
 avoid that clutter for a target that doesn't even build. You're trying to do
 this backwards.

Perhaps, because I was going for what I perceived as my best chance of success,
and from my point of view getting rid of some patches is better than nothing. 
But if the entire target can be supported, that would be ideal.

  Regarding *all* the patches:
  frankly I am apprehensive about the process.
 This should be a single patch, sent to both the libstdc++ and gcc-patches
 lists.

I was too indirect.  My apprehension is that I'm afraid I'll generate a bunch
of patches that will just be ignored / not evaluated, and then bitrot.  There's
a reputation for that, and the more files that get touched, the more likely
that is to happen.  Hence my impression I need a champion for the cause.

 I would expect these can be a single patch, or two or three related patches
 at most. If you're not sure, post a single patch to the gcc-patches list for
 review. If the relevant maintainers don't like it you'll be asked to split
 it up.

which ironically puts it back in the partial support zone (assuming not all
patches are accepted) that you want to avoid.


  +++ libcilkrts/runtime/os-unix.c
  +++ libitm/configure.tgt
 
 These are optional libraries, so tests can be run after configuring with
 e.g. --disable-libitm until the patches are in (but they're probably small
 enough changes that just including them with the rest of the gcc and libgcc
 changes would be ok for a global reviewer to approve).

They are also trivial / obvious changes so shouldn't be an issue.


 There's no way the files listed above should involve 20 separate
 submissions. I'd guess two or three (not including Ada).
 
 I can help, but I don't really see what the problem is. Post the patches for
 review and see what the relevant maintainers say. If you want to show that
 the patches are correct, post before and after test results. If you don't
 provide test results, expect to be asked for them.

I've had copyright assignment for years but haven't submitted anything
substantial because of my limited time and worry that I'll have to chase the
patches and hound and beg and then do some kind of full bootstrap testing that
I'm not prepared to do.  The perceived barrier is very high.  That's my
problem, but that's why I have hoarded these patches for over two years
(cutting off my nose because I have to keep regenerating them for each release)


 Until then this is speculation and fixing failing tests is premature,
 because they all fail until the compiler can be built.

well - i see that from your POV but from my POV the compiler can be built with
external patches and this fixes the testsuite.  (although I can work around it
with a file list and sed)

 It's stage 1, now is the perfect  time to add support for a new target, but
 to do that you need to post the patches, and preferably test results.

is it logical to run a libstdc++ testsuite on a new target that we know will
fail?  In other words, do you really want take gcc 4.10, add the c++ and gcc
base patches, run the testsuite, then add these libsdc++ changes and run the
suite again just to prove they really are needed?  I can of of course, just
seems like a hoop.

 By asking for your patches to be accepted upstream you're asking the GCC
 community to support your target. That's fine, and we welcome new targets,
 but if noone runs tests for the target then we have no way of knowing if the
 support still works, and it will eventually get removed again. Tests are
 essential.

Is there a testing farm and could dragonfly x86-64 be added to it?  Frankly I
don't care about the i386 platform which will go away at some point, the sooner
the better.  In not, you would expect a weekly cron to attempt to build gcc and
mail the results in automatically?  That could be done probably.

[Bug libstdc++/60793] Add target *-*-dragonfly* to dg-options on 172 libstdc++ tests

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60793

--- Comment #8 from John Marino gnugcc at marino dot st ---
(In reply to Manuel López-Ibáñez from comment #7) 
 But this is something that everybody has to do! It is a trade-off, does it
 take more effort to keep the patches up-to-date or to get them approved?

The answer is obvious - it's less effort to keep the patches up-to-date.  at
least, that's my perception based on observation but not first-hand experience.
 (I'm not trying to start anything, I'm just being honest about *my*
perceptions.)


 You should expect reviewers to ask for changes. That is the whole point of
 having a review process.

Sure, that's reasonable.


 And for sure you will need to ping the patches several times, there are very
 few reviewers and they are doing also 99% of the work, so they miss patches
 all the time. 

Well, while this is the reality of the situation, it's not reasonable.  The
threat of pinging several times per patch set when it could be several sets of
patches is actually why other things have taken priority.  I don't what the
solution is; I guess I was hoping the system would fix itself but it doesn't
sound like that's happened yet.


 Also, I think you will need to do a full bootstrap+testsuite, why wouldn't
 you be able to do that? If you don't have a machine powerful enough, you may
 contact the compile farm to install Dragonfly on a virtual machine:
 http://gcc.gnu.org/wiki/CompileFarm

Because I interpret a full bootstrap to mean every major platform that gcc
supports.  What does bootstrap mean?  Just a standard build with
--disable-boostrap flag not used?  I can test the dragonfly platform, but I
can't test every variety of linux, solaris, etc. for potential effects.


 It is also essential that you submit your port in a way that makes it easy
 for  reviewers to know what they are supposed to look at. See a good example:
 http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00278.html

okay, thanks for providing that example.

  Is there a testing farm and could dragonfly x86-64 be added to it?  Frankly
  I don't care about the i386 platform which will go away at some point, the
  sooner the better.  In not, you would expect a weekly cron to attempt to
  build gcc and mail the results in automatically?  That could be done
  probably.
 
 http://gcc.gnu.org/wiki/CompileFarm
 
 I am not sure what are the requirements for a tertiary platform, but surely
 they are very loose once accepted: The port has to be basically unmaintained
 to get removed.

understood.  DF should be easy to keep maintained once it's in.

Does that means it's just a matter of requesting a virtual machine on the
compile farm and having an assigned responsible to respond to potential fallout
that shows on DF test reports only?  It looks like I would qualify esp. given I
have commit access to three separate BSD projects (DragonFly, FreeBSD, and
NetBSD).

[Bug libstdc++/60793] Add target *-*-dragonfly* to dg-options on 172 libstdc++ tests

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60793

--- Comment #4 from John Marino gnugcc at marino dot st ---
For the matter of this particular PR, NetBSD is also a target so it's not a big
stretch to imagine it's needed for all the BSD targets (and it is).  Plus
there's really no downside if the target isn't really recognized, other than
dejagnu clutter.

Regarding *all* the patches:
frankly I am apprehensive about the process.

For libc++:
+++ libstdc++-v3/config/locale/dragonfly/c_locale.cc (new)
+++ libstdc++-v3/config/locale/dragonfly/ctype_members.cc (new)
+++ libstdc++-v3/config/os/bsd/dragonfly/ctype_base.h (new)
+++ libstdc++-v3/config/os/bsd/dragonfly/ctype_configure_char.cc (new)
+++ libstdc++-v3/config/os/bsd/dragonfly/ctype_inline.h (new)
+++ libstdc++-v3/config/os/bsd/dragonfly/os_defines.h (new)
+++ libstdc++-v3/acinclude.m4
+++ libstdc++-v3/configure
+++ libstdc++-v3/configure.host

for base/c:
+++ gcc/config/dragonfly-stdint.h (new)
+++ gcc/config/dragonfly.h (new)
+++ gcc/config/dragonfly.opt (new)
+++ gcc/config/i386/dragonfly.h (new)
+++ gcc/ginclude/stddef.h
+++ include/libiberty.h
+++ libgcc/crtstuff.c
+++ libgcc/enable-execute-stack-freebsd.c
+++ libgcc/unwind-dw2-fde-dip.c
+++ libgcc/config/i386/dragonfly-unwind.h
+++ gcc/config.gcc
+++ gcc/configure
+++ gcc/Makefile.in
+++ libgcc/config.host
+++ libcilkrts/runtime/os-unix.c
+++ libitm/configure.tgt

for ada (all BSD, not just DragonFly)
+++ gcc/ada/a-exetim-posix.adb
+++ gcc/ada/a-intnam-dragonfly.ads
+++ gcc/ada/a-intnam-netbsd.ads (BSD)
+++ gcc/ada/a-intnam-openbsd.ads (BSD)
+++ gcc/ada/adaint.c
+++ gcc/ada/cio.c
+++ gcc/ada/cstreams.c
+++ gcc/ada/env.c
+++ gcc/ada/g-comlin.adb
+++ gcc/ada/g-expect.adb
+++ gcc/ada/g-socthi-bsd.adb
+++ gcc/ada/g-socthi-netbsd.adb
+++ gcc/ada/g-socthi-netbsd6.ads
+++ gcc/ada/g-trasym-bsd.adb
+++ gcc/ada/gnatchop.adb
+++ gcc/ada/gnatlink.adb
+++ gcc/ada/gsocket.h
+++ gcc/ada/init.c
+++ gcc/ada/initialize.c
+++ gcc/ada/link.c
+++ gcc/ada/make.adb
+++ gcc/ada/mlib-prj.adb
+++ gcc/ada/mlib-utl.adb
+++ gcc/ada/prj-makr.adb
+++ gcc/ada/s-osinte-dragonfly.adb
+++ gcc/ada/s-osinte-dragonfly.ads
+++ gcc/ada/s-osinte-freebsd.adb
+++ gcc/ada/s-osinte-freebsd32.ads
+++ gcc/ada/s-osinte-freebsd64.ads
+++ gcc/ada/s-osinte-netbsd.adb
+++ gcc/ada/s-osinte-netbsd.ads
+++ gcc/ada/s-osinte-netbsd6.ads
+++ gcc/ada/s-osinte-openbsd.adb
+++ gcc/ada/s-osinte-openbsd.ads
+++ gcc/ada/s-osprim-bsd32.adb
+++ gcc/ada/s-osprim-bsd64.adb
+++ gcc/ada/s-osprim-bsdn6.adb
+++ gcc/ada/socket.c
+++ gcc/ada/sysdep.c
+++ gcc/ada/system-dragonfly-x86.ads
+++ gcc/ada/system-dragonfly-x86_64.ads
+++ gcc/ada/system-netbsd-x86.ads
+++ gcc/ada/system-netbsd-x86_64.ads
+++ gcc/ada/system-openbsd-x86.ads
+++ gcc/ada/system-openbsd-x86_64.ads
+++ gcc/ada/terminals.c
+++ gcc/ada/traceback_symbolic.c
+++ gcc/ada/tracebak.c
+++ gcc/ada/gcc-interface/Make-lang.in
+++ gcc/ada/gcc-interface/Makefile.in
+++ gnattools/configure.ac
+++ gnattools/configure

It's pretty reasonable to leave off Ada as a separate effort, but c/c++/base
should all be handled at the same time.  I really need somebody on the inside
to help me with these.  I don't see this as 20 separate submissions but rather
as a package.  Who would that person be?  Would you be that person?

FWIW, I do have copyright assignment on file with FSF so there's no issue about
copyright.  I just need a way to fast-track these.  And there's other patches
too like the FreeBSD unwinder support.

Hopefully the sheer number makes my apprehension clear.

[Bug ada/60411] Ada bootstrap failure on ARM

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411

--- Comment #23 from John Marino gnugcc at marino dot st ---
(In reply to John Marino from comment #17)
 In the end, there were 6 failures. 
 
 C52103x
 C52104x
 C52104y
 c74004a (hung)
 cb1010c
 cb1010d

To follow up, I reworked the testsuite handler to reduce the test times from 6
hours to about 15 minutes, so I've since re-run ACATS several times.  There are
only 5 failures.  I can't reproduce the hung c74004a test, it's executing fine
now.

So it's only the stack-check related tests that are failing.

[Bug ada/60730] 'Round of a fixed point type incorrectly truncates its operand instead of rounding it

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60730

--- Comment #4 from John Marino gnugcc at marino dot st ---
FreeBSD GNAT 4.9.0 is the same 4.7.3 (allegedly broken):

FreeBSD draco.synsport.com 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu
Jan 16 22:34:59 UTC 2014 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC
 amd64

 root@draco:/home/marino/test/rounding # /usr/local/gcc-aux/bin/ada --version
ada (GCC) 4.9.0 20140406 (prerelease) -= GNAT AUX [FreeBSD64]
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


 root@draco:/home/marino/test/rounding # ./round_decimal

raised PROGRAM_ERROR : round_decimal.adb:34 explicit raise

[Bug ada/60411] Ada bootstrap failure on ARM

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411

--- Comment #21 from John Marino gnugcc at marino dot st ---
Hi Eric,
When I tried to build the ARMv5 cross compiler (-march=armv5te) I get the
following error:

/tmp//cc5BKnWK.s: Assembler messages:
/tmp//cc5BKnWK.s:31: Error: selected processor does not support Thumb mode
`stmfd sp!,{r2,r3,lr}'
/tmp//cc5BKnWK.s:46: Error: lo register required -- `ldmfd sp,{r2,r3,pc}'
gmake[8]: *** [sigtramp-armdroid.o] Error 1


Does this mean effectively nothing lower than ARMv7 can build
arm-*-linux-androideabi?  I don't know which ARM arch supports ldmfd
sp,{r2,r3,pc} but I assume ARMv5 and lower doesn't.

John

[Bug ada/60411] Ada bootstrap failure on ARM

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411

--- Comment #15 from John Marino gnugcc at marino dot st ---
Hi Eric,
The compiler builds happily now.
It started right into ACATS testing and has passed the first 3 chapters
flawlessly (with the current setup ACATS takes hours because each test is
SCP'd/SSH'd to the device, but I'm going to improve the remote testing soon).

Thanks,
John

[Bug ada/60730] 'Round of a fixed point type incorrectly truncates its operand instead of rounding it

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60730

John Marino gnugcc at marino dot st changed:

   What|Removed |Added

 CC||gnugcc at marino dot st

--- Comment #2 from John Marino gnugcc at marino dot st ---
what platform is this program being run on?
what is output of uname -a ?

[Bug ada/60411] Ada bootstrap failure on ARM

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411

--- Comment #17 from John Marino gnugcc at marino dot st ---
Hi Eric,
In the end, there were 6 failures.  It appears that the ARM unwinder isn't
quite right yet.  After 2314 passes, the six ACATS failures were:

C52103x
C52104x
C52104y
c74004a (hung)
cb1010c
cb1010d

John

[Bug testsuite/60793] New: Add target *-*-dragonfly* to dg-options on 172 libstdc++ tests

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60793

Bug ID: 60793
   Summary: Add target *-*-dragonfly* to dg-options on 172
libstdc++ tests
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnugcc at marino dot st

Created attachment 32572
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32572action=edit
List of 172 libstdc++ tests that should target *-*-dragonfly*

The attached file is a list of 172 libstdc++ tests that have dg-options target
of *-*-freebsd*.  They should also list *-*-dragonfly*

It should be a simply matter of substituting enmass *-*-freebsd* with
*-*-freebsd* *-*-dragonfly* using perl -pi -e or similar technique.

A giant patchset could be provided upon request if perl -pie isn't good
enough.

[Bug testsuite/60794] New: 25 libstdc++ tests are missing '{ dg-require-debug-mode }'

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60794

Bug ID: 60794
   Summary: 25 libstdc++ tests are missing '{
dg-require-debug-mode  }'
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnugcc at marino dot st

Created attachment 32573
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32573action=edit
Patch to add debug-mode requirement to 25 libstdc++ tests

Twenty-five (25) libstdc++ tests require the debug-mode option but this is not
specified.  I've carried the attached patch for years, time to try to get it
properly into the gcc testsuite base.

The tests are:
23_containers/deque/debug/assign4_neg.cc
23_containers/deque/debug/construct4_neg.cc
23_containers/deque/debug/insert4_neg.cc
23_containers/list/debug/assign4_neg.cc
23_containers/list/debug/construct4_neg.cc
23_containers/list/debug/insert4_neg.cc
23_containers/map/debug/construct4_neg.cc
23_containers/map/debug/insert4_neg.cc
23_containers/multimap/debug/construct4_neg.cc
23_containers/multimap/debug/insert4_neg.cc
23_containers/multiset/debug/construct4_neg.cc
23_containers/multiset/debug/insert4_neg.cc
23_containers/set/debug/construct4_neg.cc
23_containers/set/debug/insert4_neg.cc
23_containers/unordered_map/debug/construct4_neg.cc
23_containers/unordered_map/debug/insert4_neg.cc
23_containers/unordered_multimap/debug/construct4_neg.cc
23_containers/unordered_multimap/debug/insert4_neg.cc
23_containers/unordered_multiset/debug/construct4_neg.cc
23_containers/unordered_multiset/debug/insert4_neg.cc
23_containers/unordered_set/debug/construct4_neg.cc
23_containers/unordered_set/debug/insert4_neg.cc
23_containers/vector/debug/assign4_neg.cc
23_containers/vector/debug/construct4_neg.cc
23_containers/vector/debug/insert4_neg.cc

[Bug ada/60411] Ada bootstrap failure on ARM

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411

--- Comment #19 from John Marino gnugcc at marino dot st ---
ah sorry, I always seem to conclude wrongly that stack checking requires unwind
support.  I'm not sure why I always conflate those two things.

So this patch was proposed 9 months ago but never got committed?  Or was it
only partially committed?

Will stack-check support get added soon?
Thanks,
John

[Bug libstdc++/60793] Add target *-*-dragonfly* to dg-options on 172 libstdc++ tests

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60793

--- Comment #2 from John Marino gnugcc at marino dot st ---
hmmm, that would imply that all the dragonfly patches that we've been carrying
for years (including ada patches) would need to go in first.

DragonFly does not, and has never, built out of the box.  It's not possible to
have an automated test robot until support is added.  I could have a before
-and- after run, but that's a one off comparison.

I've been carrying these patches since 4.6 (actually a lot more, this is only a
small subset).

[Bug testsuite/60794] 25 libstdc++ tests are missing '{ dg-require-debug-mode }'

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60794

--- Comment #2 from John Marino gnugcc at marino dot st ---
Hmmm, only 3 of the 25 files use debug/vector and __gnu_debug::vector
  23_containers/vector/debug/assign4_neg.cc
  23_containers/vector/debug/construct4_neg.cc
  23_containers/vector/debug/insert4_neg.cc

That said, all 25 have some form of #include debug/X and __gnu_debug::X so
likely you were only applying an example for one subset.

I honestly can't remember the exact failure that this solved at the time (gcc
4.6 timeframe).  I want to say the first file I fixed back then was
deque/debug/assign4_neg.cc

It's possible that that I saw debug-mode used in the 1,2,3 versions and thought
it was oversight with the 4 versions, but I would have only looked at it upon a
failure.


All that said, if all 25 look right to you then I'll humbly accept it and a
closed/invalid bug status.

[Bug ada/60411] ADA bootstrap failure on ARM

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411

John Marino gnugcc at marino dot st changed:

   What|Removed |Added

 CC||gnugcc at marino dot st

--- Comment #11 from John Marino gnugcc at marino dot st ---
Eric,
Thanks for these commits.  However, I'm still unable to build
arm-aux-linux-androideabi cross-compiler target after 209227.

This is the current error:
s-osinte.ads:593:07: component sa_flags overlaps sa_mask at line 592

This happens when a-dynpri.adb is being compiled.  s-osinte.ads is
s-osinte-android.ads of course.

I think this is a direct consequence of #include asm/signal.h at sigtramp.h

s-ointe-android.ads, lines 590-594:
   for struct_sigaction use record
  sa_handler at Linux.sa_handler_pos range 0 .. Standard'Address_Size - 1;
  sa_maskat Linux.sa_mask_posrange 0 .. 1023;
  sa_flags   at Linux.sa_flags_pos   range 0 .. Standard'Address_Size - 1;
   end record;

asm/signal.h (NDK, API 15):
typedef unsigned long sigset_t;
struct sigaction {
 union {
 __sighandler_t _sa_handler;
 void (*_sa_sigaction)(int, struct siginfo *, void *);
 } _u;
 sigset_t sa_mask;
 unsigned long sa_flags;
 void (*sa_restorer)(void);
};

So it does seem that struct_sigaction record isn't correct after all.
John

[Bug ada/60411] ADA bootstrap failure on ARM

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411

--- Comment #12 from John Marino gnugcc at marino dot st ---
I am also seeing these errors:

s-intman.adb:263:32: SA_NODEFER is not visible
s-intman.adb:263:32: non-visible declaration at s-linux.ads:110
s-intman.adb:263:45: SA_RESTART is not visible
s-intman.adb:263:45: non-visible declaration at s-linux.ads:109

[Bug ada/60620] New: missing gnattools dependency causes highly parallel build failure with --disable-bootstrap

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60620

Bug ID: 60620
   Summary: missing gnattools dependency causes highly parallel
build failure with --disable-bootstrap
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnugcc at marino dot st

GCC 4.9.0 has been brought into FreeBSD ports (lang/gcc-aux) which supports 4
platforms: i386-FreeBSD, i386-DragonFly, x86_64-FreeBSD, and x86-64-DragonFly. 
On machines with low -j inputs (say -j4) it would build fine, but on powerful
machines with like -j8 or greater, we'd seen a clean jail (no base compiler lib
in path) build break on gnattools such as this:

checking for scalbnl... ../../xg++ -B../../
-B../../../x86_64-aux-freebsd10.0/libstdc++-v3/src/.libs
-B../../../x86_64-aux-freebsd10.0/libstdc++-v3/libsupc++/.libs
-L../../../x86_64-aux-freebsd10.0/libstdc++-v3/src/.libs
-L../../../x86_64-aux-freebsd10.0/libstdc++-v3/libsupc++/.libs
-static-libstdc++ -static-libgcc -I- -I../rts -I.
-I/work/a/ports/lang/gcc-aux/work/gcc-4.9-20140316/gcc/ada -static-libstdc++
-static-libgcc  -DIN_GCC  -g -O2 -W -Wall -o ../../gnatlink b_gnatl.o
gnatlink.o a-except.o ali.o alloc.o butil.o casing.o csets.o debug.o fmap.o
fname.o gnatvsn.o hostparm.o indepsw.o interfac.o i-c.o i-cstrin.o namet.o
opt.o osint.o output.o rident.o s-exctab.o s-secsta.o s-stalib.o s-stoele.o
sdefault.o snames.o stylesw.o switch.o system.o table.o targparm.o tree_io.o
types.o validsw.o widechar.o ../link.o ../targext.o ../../ggc-none.o
../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a
../rts/libgnat.a ../../../intl/libintl.a 
../../../libbacktrace/.libs/libbacktrace.a ../../../libiberty/libiberty.a  
yes
checking for sinf... /usr/bin/ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status
gmake[5]: *** [../../gnatlink] Error 1
gmake[5]: *** Waiting for unfinished jobs


It seems this doesn't happen with a full bootstrap.  For reference, this is a
typical configuration:

/work/a/ports/lang/gcc-aux/work/gcc-4.9-20140316/configure
--enable-languages=c\ c++\ ada\ fortran\ objc --build=x86_64-aux-freebsd10.0
--prefix=/usr/local/gcc-aux --with-system-zlib --with-gmp=/usr/local
--with-mpfr=/usr/local --with-mpc=/usr/local  --enable-shared
--enable-threads=posix --disable-libmudflap --disable-libgomp --disable-libssp
--enable-libquadmath --enable-nls --disable-bootstrap

It appears the linking using g++ is intentional as -static-libstdc++ is passed,
so that means that libstdc++ is required to build gnattools but that dependency
is not documented.  The following patches solved the parallel build problems
with --disable-bootstrap that we were seeing:

--- Makefile.def.orig2013-10-29 13:37:47.0 -0500
+++ Makefile.def
@@ -336,6 +336,7 @@ dependencies = { module=all-libcpp; on=a
 dependencies = { module=all-fixincludes; on=all-libiberty; };

 dependencies = { module=all-gnattools; on=all-target-libada; };
+dependencies = { module=all-gnattools; on=all-target-libstdc++-v3; };

 dependencies = { module=all-lto-plugin; on=all-libiberty; };


--- Makefile.in.orig2014-03-07 07:58:27.0 -0500
+++ Makefile.in
@@ -46730,6 +46730,7 @@ all-stageprofile-libcpp: maybe-all-stage
 all-stagefeedback-libcpp: maybe-all-stagefeedback-intl
 all-fixincludes: maybe-all-libiberty
 all-gnattools: maybe-all-target-libada
+all-gnattools: maybe-all-target-libstdc++-v3
 all-lto-plugin: maybe-all-libiberty

 all-stage1-lto-plugin: maybe-all-stage1-libiberty


It should be a simple matter to confirm that libstdc++ is indeed required for
gnattools and that it's not listed as a dependency.  It is also possible that
gcc 4.8.x is affected by this, but I cannot say as I have never tried to build
that version, nor do I know if libstdc++ is required for gnattools there.

[Bug libobjc/54720] New: libobjc install-strip target not populated

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720



 Bug #: 54720

   Summary: libobjc install-strip target not populated

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libobjc

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: gnu...@marino.st





On versions 4.7.1 and 4.7.2:

executing make install after the build will result in the installation of the

libobjc.* files when objc is specified in --enable-langs



However, make install-strip doesn't install the libobjc.* files in the

library installation directory.  It seems the libobjc/makefile has completely

omitted this target although it references it.





The fix is easy: Add the install-strip target to the libobjc/Makefile.in file.

[Bug libstdc++/47052] make: *** [configure-target-libstdc++-v3] Error 1 Cross compile GCC for Alpha Architecture

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47052

John Marino gnugcc at marino dot st changed:

   What|Removed |Added

 CC||gnugcc at marino dot st

--- Comment #3 from John Marino gnugcc at marino dot st 2012-04-07 06:48:47 
UTC ---
For what it's worth, this report is *not* invalid.

I'm attempting to cross-compile libstdc++-v3 from FreeBSD 9.0 to ARMv5 using
gcc 4.6.3 (the latest of the 4.6 series) and I'm hitting this error too.

In fairness, it's a patched version of gcc 4.6.3 to target Android on ARM. 
This was an attempt to extend the existing lang/gnatdroid-armv5 cross-compiler
port on FreeBSD to include c++, objC, and Fortran.

The commonality between the original report and mine is the cross-compile. 
maybe that's the case where the configure test is lacking.

[Bug libstdc++/47052] make: *** [configure-target-libstdc++-v3] Error 1 Cross compile GCC for Alpha Architecture

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47052

--- Comment #4 from John Marino gnugcc at marino dot st 2012-04-07 07:20:00 
UTC ---
Adding --disable-sjlj-exceptions to the configure options will get one past
this error on the android/arm target.

[Bug debug/46704] [4.6 Regression] Ada compiler fails to build itself

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46704

John Marino gnugcc at marino dot st changed:

   What|Removed |Added

 CC||gnugcc at marino dot st

--- Comment #12 from John Marino gnugcc at marino dot st 2011-01-12 07:27:40 
UTC ---
I'm now seeing this on NetBSD AMD64.  I always used --disable-bootstrap and
never saw it, but when I removed that configuration option I'm getting the
exact error.  This is with gcc build on 5 Jan 2011 and a source snapshot of 9
Jan.

I can't confirm the same on NetBSD32 because when I remove --disable-bootstrap
libiberty can't compile during the first stage (bad assembly, thinks %sil
register is selected which doesn't exist on x86)

It looks like the fix came after the first gcc was built, so I should rebuild
it with Jan 9 snapshot using --disable-bootstrap, install it, and then rebuild
it again with disable snapshot?

Thanks,
John


Using built-in specs.
COLLECT_GCC=gnatgcc
COLLECT_LTO_WRAPPER=/usr/pkg/libexec/gcc/x86_64-aux-netbsd5.1_RC4/4.6.0/lto-wrapper
Target: x86_64-aux-netbsd5.1_RC4
Configured with: /usr/pkgsrc/lang/gnat-aux/work/gcc-4.6-20110104/configure
--enable-languages=c,ada --build=x86_64-aux-netbsd5.1_RC4 --program-prefix=gnat
--prefix=/usr/pkg --with-system-zlib --with-gmp=/usr/pkg --with-mpfr=/usr/pkg
--with-mpc=/usr/pkg --with-libiconv-prefix=/usr/pkg --enable-shared
--enable-threads=posix --disable-bootstrap --disable-libgomp --disable-libssp
--disable-nls
Thread model: posix
gcc version 4.6.0 20110105 (experimental) -= GNAT AUX [NetBSD64] (GCC)

[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005

--- Comment #11 from John Marino gnugcc at marino dot st 2011-01-05 13:49:47 
UTC ---
I rebuilt OpenBSD i386 using then Jan 5 daily bump (SVN 168495) and patched it
with tree-src.c file.

ACATS 62002a now passes, thanks.

[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005

--- Comment #13 from John Marino gnugcc at marino dot st 2011-01-05 15:14:36 
UTC ---
(In reply to comment #12)
 Thanks for confirming.  ACATS is clean on both i386 and i586 Linux SJLJ now,
 are there any remaining failures on BSD platforms?

There are no ACATS or gnat.dg failures on the ZCX platforms (FreeBSD,
DragonFlyBSD, NetBSD: i386 and x86_64)

The regression tests just completed for OpenBSD i386.
There is one failure on ACATS (cb1010a timeout)* 
Between yesterday and today, the test sse_nolib result went from passing to
UNSUPPORTED


Comments:
1) Between yesterday and today, test c390001 wouldn't even compile, but now it
passes.
2)* I haven't investigated cb1010a timeout yet, but I think the problem is with
OpenBSD, not gnat
3) the STACK_CHECK_STATIC_BUILTIN macro value has no effect on OpenBSD.  I was
expecting failures on c5210[3x,4x,4y] and cb1010[a,b,c] but they don't fail.
4) Despite DWARF2_UNWIND_INFO being set to 0 (meaning MD_UNWIND_SUPPORT macro
is ignored), the null_deref and stack_check gnat.dg tests pass.  in gdb, the
segfault comes and then the program just exits normally.
5) I don't know if the behavior of 3) and 4) is normal for an SJLJ target, or
if it's because apparently there's some missing support on OpenBSD for DWARF2
(if I try to set OpenBSD32 to ZCX handling the compile breaks with the
unwind_context structure considered illegal), and commit commits also indicate
something is missing for OpenBSD.

The summary is that the OpenBSD port is currently better then it has ever been,
and one remaining ACATS failure is probably related to how OpenBSD handles
their stack.  As of today, I don't have any errors to report, but that may
change as I discover more about the issues I just outlined above.

[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005

--- Comment #15 from John Marino gnugcc at marino dot st 2011-01-05 16:25:56 
UTC ---
[off PR]

Hi Eric,
Can you clarify one statement?
Regarding the ten stack-check tests as I can them (c5210[3x,4x,4y], 
cb1010[a,c,d], null_deref[1,2], stack-check[1,2]), I now understand that 
it is expected that these tests pass on SJLJ targets.

Are these true passes meaning SJLJ targets are fully capable of handling 
stack overflow and segfaults?  Or are these results just false positives?

Thanks,
John


ebotcazou at gcc dot gnu.org wrote:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005
 
 --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-05 
 15:33:24 UTC ---
 The regression tests just completed for OpenBSD i386.
 There is one failure on ACATS (cb1010a timeout)* 
 
 This is a stack checking test.
 
 3) the STACK_CHECK_STATIC_BUILTIN macro value has no effect on OpenBSD.  I 
 was
 expecting failures on c5210[3x,4x,4y] and cb1010[a,b,c] but they don't fail.
 
 The tests should pass w and w/o it on x86, but it's better to define it.
 
 4) Despite DWARF2_UNWIND_INFO being set to 0 (meaning MD_UNWIND_SUPPORT macro
 is ignored), the null_deref and stack_check gnat.dg tests pass.  in gdb, the
 segfault comes and then the program just exits normally.
 
 This is expected with SJLJ exceptions, you don't need MD_UNWIND_SUPPORT.
 
 The summary is that the OpenBSD port is currently better then it has ever 
 been,
 and one remaining ACATS failure is probably related to how OpenBSD handles
 their stack.  As of today, I don't have any errors to report, but that may
 change as I discover more about the issues I just outlined above.
 
 Great, thanks for the detailed report.

[Bug ada/47131] [4.6 Regression] internal error for ACATS C34011B on SJLJ targets

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47131

--- Comment #6 from John Marino gnugcc at marino dot st 2011-01-04 13:23:28 
UTC ---
I rebuilt the OpenBSD i386 port (SVN 168458, after 4th change to trans.c
today).  It now passes test 34011B.


Thanks!

[Bug ada/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005

--- Comment #7 from John Marino gnugcc at marino dot st 2011-01-04 13:27:52 
UTC ---
I confirm that test c62002a is still failing on OpenBSD i386 as of today (SVN
168458)

[Bug ada/47131] [4.6 Regression] internal error for ACATS C34011B on SJLJ targets

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47131

--- Comment #7 from John Marino gnugcc at marino dot st 2011-01-04 16:21:17 
UTC ---
When OpenBSD i386 finished the test suite, I was surprised to it passed gnat.dg
pack9 unexpectedly.  This is the scan tree dump not optimized test that was
set to expect-fail a few weeks ago due to a change in the rtl optimization I
believe (all this traces back to a PR).

I'm wondering if this change to trans.c now causes SJLJ targets to pass the
pack9 test as a side effect?

[Bug regression/47131] New: Ada C34011B fails with GNAT BUG on SJLJ targets

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47131

   Summary: Ada C34011B fails with GNAT BUG on SJLJ targets
   Product: gcc
   Version: 4.6.0
   URL: http://www.dragonlace.net
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gnu...@marino.st
Target: i386,x86_64 w/o GCC EH


Created attachment 22872
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22872
Test case to demonstrate GNAT regression

On GCC 4.6.0, between Nov 13 and Nov 20, the Ada ACATS test C34011B failed and
continues to fail on targets that don't use the GCC error handler.  I have
three such targets (OpenBSD i386, OpenBSD AMD64, and FreeBSD AMD64), and the
test starting failing on all three targets at the exact same time.

The failure is also optimization level related.  It will pass on all targets at
level 0, but it will fail on SJLJ targets at -O1 or higher.

The GNAT BUG error message is show below.  The attachment is a test case that
will produce the message.



 gnatmake -O1 gimple_2310.adb

gnatgcc -c -O1 gimple_2310.adb
gimple_2310.adb:39:36: warning: static value out of range of type
Standard.Positive
gimple_2310.adb:39:36: warning: Constraint_Error will be raised at run time
gimple_2310.adb:44:16: warning: variable T1 is read but never assigned
+===GNAT BUG DETECTED==+
| 4.6.0 20101221 (experimental) -= GNAT AUX [OpenBSD] (i386-aux-openbsd4.7)
GCC error:|
| in gimple_has_side_effects, at gimple.c:2310 |
| Error detected around gimple_2310.adb:69:5   |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| 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 gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

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).

gimple_2310.adb


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423
gnatmake: gimple_2310.adb compilation error

[Bug ada/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005

John Marino gnugcc at marino dot st changed:

   What|Removed |Added

 CC||gnugcc at marino dot st

--- Comment #4 from John Marino gnugcc at marino dot st 2010-12-30 23:11:56 
UTC ---
I can confirm the same thing on i386 OpenBSD.  I do NOT see it on x86_64
OpenBSD though.  Note that OpenBSD uses SJLJ exception handling.

O0 - passes
O1 - passes
O2 - fails
O3 - fails


Using built-in specs.
COLLECT_GCC=gnatgcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-aux-openbsd4.7/4.6.0/lto-wrapper
Target: i386-aux-openbsd4.7
Configured with: /home/marino/gnat_port/gen_5/work/gcc-4.6-20101221/configure
--enable-languages=c,ada --build=i386-aux-openbsd4.7 --program-prefix=gnat
--prefix=/usr/local --with-system-zlib --with-gmp=/usr/local
--with-mpfr=/usr/local --with-mpc=/usr/local --with-libiconv-prefix=/usr/local
--enable-threads=yes --enable-shared --disable-bootstrap --disable-libgomp
--disable-libssp --disable-nls
Thread model: posix
gcc version 4.6.0 20101221 (experimental) -= GNAT AUX [OpenBSD] (GCC)

[Bug ada/46490] For four major i386 BSDs, GNAT fails FP to static integer conversion with -O2,-O3 optimization

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490

--- Comment #5 from John Marino gnugcc at marino dot st 2010-11-16 10:35:54 
UTC ---
Hi Eric,
Thanks for you comment, but I don't think that is it for several reasons:

1) I am aware of both those quirks, and my codebase is patched with both of
those suggestions.

2) There's no problem with stack checking on FreeBSD i386.  There are no
failures whatsoever on either ACATS or gnat.dejagnu except for this particular
case of c460007.  NetBSD stack-checking doesn't work, but that's outside this
bug report.

3) The test passes with optimization level 0 or 1.  It fails with O2 and O3
settings.

4) There are no other rounding issues.  If TARGET_96_ROUND_53_LONG_DOUBLE is
not set correctly, multiple tests fail.

5) It's occurring identically on all four i386 platforms which are pretty
divergent.


This looks like a problem in the optimization stage.
The two test cases I provided are interesting as you can see the test will pass
if the EQUAL function is nested inside the main procedure rather than being
called as a separate package (also pointing to a problem in optimization I
would think.)

This warrants a closer look, it's not a configuration thing.
Thanks,
John

[Bug ada/46490] ACATS cb460007 fails at -O2 or above

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490

--- Comment #7 from John Marino gnugcc at marino dot st 2010-11-16 11:25:31 
UTC ---
Eric, 
Actually I believe it is limited to the BSDs, although I can't explain why.  I
also ported GNAT to x86 OpenSolaris (SXCE 130) and that one passed all ACATS.  
I also have not seen this failure on any of the Linux testsuite reports for
4.6.0.

This error may have also been present in the 4.5.0 branch, but there were
several other failures back then so I wasn't paying particular attention to it
at the time.

FYI, here are recent test reports if you find this helpful:

DragonFly32 : http://www.dragonlace.net/gnataux/dragonfly32/
FreeBSD32   : http://www.dragonlace.net/gnataux/freebsd32/
OpenBSD32   : http://www.dragonlace.net/gnataux/openbsd32/
NetBSD32: http://www.dragonlace.net/gnataux/netbsd32/

Also, remember x86_64 works fine, there is no issue with -O2,-O3 with this test
on that architecture.

[Bug rtl-optimization/46490] [4.6 regression] ACATS c460007 fails at -O2 or above

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490

--- Comment #12 from John Marino gnugcc at marino dot st 2010-11-16 23:07:46 
UTC ---
That's great news, Eric!

Many thanks, both for spending some long hours resolving this the same day it
was reported, and for the tip on the raise_from_pure test.  This results in two
GNAT ports have zero ACATS errors.

John

[Bug ada/46490] New: For four major i386 BSDs, GNAT fails FP to static integer conversion with -O2,-O3 optimization

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490

   Summary: For four major i386 BSDs, GNAT fails FP to static
integer conversion with -O2,-O3 optimization
   Product: gcc
   Version: 4.6.0
   URL: http://www.dragonlace.net
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gnu...@marino.st
  Host: Same as Target
Target: FreeBSD, OpenBSD, NetBSD, DragonFlyBSD: i386
 Build: Same as Target


Created attachment 22404
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22404
Nested_C460007 program (1 of 1)

I have successfully ported GNAT to all four major BSDs on two architectures,
i386 and x86_64 (8 ports total).
There is a failure of an ACATS test, cb460007, that fails on all four BSD
platforms, but only for the i386 arch.
All of the x86_64 ports pass the test just fine.

I have discovered the test passes on i386 if optimization level 0 or 1 is
specified.
Furthermore, if the test is re-written such that the program is contained
within a single procedure, the
test doesn't fail with any optimization levels.

I have provided two test programs.  The SlimC46007 program is cut-down version
of the ACATS test c460007, and tests case 9 and 10 only (conversion of floating
point to static integer).  The Nested_C460007 program does the same thing, but
without the extra package.


Output of running SlimC46007 to demonstrate effect of optimization levels.

 gnatmake -O2 slimc460007.adb
gnatgcc -c -O2 slimc460007.adb
gnatgcc -c -O2 c460007_1.adb
gnatbind -x slimc460007.ali
gnatlink slimc460007.ali -O2

 ./slimc460007
Test C460007: Rounding for type conversions of real operand to integer target
CASE  9 FAILED (static target subtype)
CASE 10 FAILED (static target subtype)

 rm *.o *.ali
 gnatmake slimc460007.adb
gnatgcc -c slimc460007.adb
gnatgcc -c c460007_1.adb
gnatbind -x slimc460007.ali
gnatlink slimc460007.ali

 ./slimc460007
Test C460007: Rounding for type conversions of real operand to integer target
BOTH TESTS PASSED.




Output of running Nested_C460007 where O-level has no effect
 gnatmake -O2 nested_c460007.adb
gnatgcc -c -O2 nested_c460007.adb
gnatbind -x nested_c460007.ali
gnatlink nested_c460007.ali -O2

 ./nested_c460007
BOTH TESTS PASSED.

 rm *.o *.ali
 gnatmake nested_c460007.adb
gnatgcc -c nested_c460007.adb
gnatbind -x nested_c460007.ali
gnatlink nested_c460007.ali

 ./nested_c460007
BOTH TESTS PASSED.



Note: I've been tracking this failure for months.  It's been part of 4.6.0 as
long as I can remember.
It is the only test failure for the i386 FreeBSD GNAT and the i386 DragonFly
BSD GNAT.  The i386 NetBSD GNAT is doesn't seem to support stack-checking, so
omitting those stack-check ACATS and DejaGNU test, this is the only failure on
that platform as well.


The same test was run on all 4 listed platforms with the exact same results.


i386 DragonFlyBSD 2.6  (13 Nov 2010)

 gnatgcc -v
Using built-in specs.
COLLECT_GCC=gnatgcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-backplane-dragonfly2.6/4.6.0/lto-wrapper
Target: i386-backplane-dragonfly2.6
Configured with: /home/marino/gnat_port/gen_x/work/gcc-4.6-20101113/configure
--enable-languages=c,ada --build=i386-backplane-dragonfly2.6
--program-prefix=gnat --prefix=/usr/local --with-system-zlib
--with-gmp=/usr/pkg --with-mpfr=/usr/pkg --with-mpc=/usr/pkg
--with-libiconv-prefix=/usr/pkg --enable-threads=single --enable-shared
--disable-bootstrap --disable-libgomp --disable-libssp --disable-nls
Thread model: single
gcc version 4.6.0 20101113 (experimental) -= GNAT AUX [DragonFly BSD] (GCC)



i386 FreeBSD 8.0(30 Oct 2010)
=
 gnatgcc -v
Using built-in specs.
COLLECT_GCC=gnatgcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-portbld-freebsd8.0/4.6.0/lto-wrapper
Target: i386-portbld-freebsd8.0
Configured with: /usr/home/marino/workzone/port/work/gcc-4.6-20101030/configure
--enable-languages=c,ada --build=i386-portbld-freebsd8.0 --program-prefix=gnat
--prefix=/usr/local --with-system-zlib --with-gmp=/usr/local
--with-mpfr=/usr/local --with-mpc=/usr/local --with-libiconv-prefix=/usr/local
--enable-shared --disable-bootstrap --disable-libgomp --disable-libssp
--disable-nls
Thread model: posix
gcc version 4.6.0 20101030 (experimental) -= GNAT AUX [FreeBSD] (GCC)



i386 NetBSD 5.1RC4  (30 Oct 2010)
=
 gnatgcc -v
Using built-in specs.
COLLECT_GCC=gnatgcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-pc-netbsdelf5.1/4.6.0/lto-wrapper
Target: i386-pc-netbsdelf5.1
Configured with: /workzone/gnat_port/gen_2/work/gcc-4.6-20101030/configure
--enable-languages=c,ada --build=i386-pc-netbsdelf5.1 --program-prefix=gnat
--prefix=/usr/local --with-system-zlib --with-gmp=/usr/pkg --with-mpfr=/usr/pkg
--with-mpc=/usr/pkg --with-libiconv-prefix=/usr/pkg 

[Bug ada/46490] For four major i386 BSDs, GNAT fails FP to static integer conversion with -O2,-O3 optimization

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490

--- Comment #1 from John Marino gnugcc at marino dot st 2010-11-15 19:53:38 
UTC ---
Created attachment 22405
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22405
SlimC46007 program (1 of 3)

[Bug ada/46490] For four major i386 BSDs, GNAT fails FP to static integer conversion with -O2,-O3 optimization

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490

--- Comment #2 from John Marino gnugcc at marino dot st 2010-11-15 19:55:34 
UTC ---
Created attachment 22406
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22406
SlimC46007 program (2 of 3)

[Bug ada/46490] For four major i386 BSDs, GNAT fails FP to static integer conversion with -O2,-O3 optimization

[gnugcc at marino dot st]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490

--- Comment #3 from John Marino gnugcc at marino dot st 2010-11-15 19:56:33 
UTC ---
Created attachment 22407
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22407
SlimC46007 program (3 of 3)