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,
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.
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&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86211
John Marino changed:
What|Removed |Added
CC||gnugcc at marino dot st
--- Comment #4
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 s
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.
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_
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
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?
: 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
)
Specifically, a macro condition was modified improperly
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
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79542
John Marino changed:
What|Removed |Added
CC||gnugcc at marino dot st
--- Comment #5
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
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405
--- Comment #22 from John Marino ---
(gdb) p/x $rax
$1 = 0x800af0748
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>: p
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
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 ...
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
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.
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 thi
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
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
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
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
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&action=edit
gzipped build log
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
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 failures
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-tapro
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 pre
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&action=edit
codecvt/max_length/wchar/4.cc patch
codecvt/max_length/wchar/4.cc test thinks that 6 is the maximum byte size for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58583
John Marino changed:
What|Removed |Added
CC||gnugcc at marino dot st
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67096
--- Comment #1 from John Marino ---
Created attachment 36108
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36108&action=edit
modification to test that makes it legal
As an illustration, I've modified the test to stop before 0x20 which
: 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 li
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-warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60794
John Marino changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451
--- Comment #4 from John Marino ---
Created attachment 35054
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35054&action=edit
gzipped archive of matreshka source files
I created a tarball of the source files rather than concatenate. I tho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451
--- Comment #2 from John Marino ---
right url for freshports: http://www.freshports.org/devel/matreshka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451
--- Comment #1 from John Marino ---
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65292
--- Comment #8 from John Marino ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65292
--- Comment #7 from John Marino ---
typo -- it was gcc 4.7, not gcc7 that succeeded. (I say that to help answer
the question in the QT5 bug report)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65292
--- Comment #6 from John Marino ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65292
John Marino changed:
What|Removed |Added
CC||gnugcc at marino dot st
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61309
--- Comment #5 from John Marino ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61309
--- Comment #4 from John Marino ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61309
--- Comment #2 from John Marino ---
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?
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" in
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
T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411
--- Comment #24 from John Marino ---
(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
> sigtr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60793
--- Comment #8 from John Marino ---
(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 ans
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60793
--- Comment #6 from John Marino ---
(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 back
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60793
--- Comment #4 from John Marino ---
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 rec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60730
--- Comment #4 from John Marino ---
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/GENE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411
--- Comment #23 from John Marino ---
(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 t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411
--- Comment #21 from John Marino ---
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 m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60794
--- Comment #2 from John Marino ---
Hmmm, only 3 of the 25 files use 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60793
--- Comment #2 from John Marino ---
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 pos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411
--- Comment #19 from John Marino ---
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?
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=32573&action=edit
Patch to add debug-mode requirement to
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=32572&action=edit
List of 172 libstdc++ tests that should target *-*-dr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411
--- Comment #17 from John Marino ---
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
Joh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60730
John Marino changed:
What|Removed |Added
CC||gnugcc at marino dot st
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411
--- Comment #15 from John Marino ---
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 dev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411
--- Comment #12 from John Marino ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411
John Marino changed:
What|Removed |Added
CC||gnugcc at marino dot st
--- Comment #11
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47052
--- Comment #4 from John Marino 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47052
John Marino changed:
What|Removed |Added
CC||gnugcc at marino dot st
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46704
John Marino changed:
What|Removed |Added
CC||gnugcc at marino dot st
--- Comment #12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005
--- Comment #15 from John Marino 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 underst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005
--- Comment #13 from John Marino 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005
--- Comment #11 from John Marino 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47131
--- Comment #7 from John Marino 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 wee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005
--- Comment #7 from John Marino 2011-01-04 13:27:52
UTC ---
I confirm that test c62002a is still failing on OpenBSD i386 as of today (SVN
168458)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47131
--- Comment #6 from John Marino 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!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005
John Marino changed:
What|Removed |Added
CC||gnugcc at marino dot st
--- Comment #4
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490
--- Comment #12 from John Marino 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
G
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490
--- Comment #7 from John Marino 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490
--- Comment #5 from John Marino 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) The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490
--- Comment #3 from John Marino 2010-11-15 19:56:33
UTC ---
Created attachment 22407
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22407
SlimC46007 program (3 of 3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490
--- Comment #2 from John Marino 2010-11-15 19:55:34
UTC ---
Created attachment 22406
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22406
SlimC46007 program (2 of 3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490
--- Comment #1 from John Marino 2010-11-15 19:53:38
UTC ---
Created attachment 22405
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22405
SlimC46007 program (1 of 3)
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
Statu
89 matches
Mail list logo
