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=e
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
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
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
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
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
<o...@adacore.com>)
Specifically, a macro con
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
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
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
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
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>:
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
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
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
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
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
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
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
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
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-taprop.adb
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
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
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
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
: 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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60794
John Marino gnugcc at marino dot st changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
John Marino gnugcc at marino dot st changed:
What|Removed |Added
CC||gnugcc at marino dot
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.
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
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.
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
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
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!
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)
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
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=47005
John Marino gnugcc at marino dot st changed:
What|Removed |Added
CC||gnugcc at marino dot
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
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
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
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
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)
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)
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)
89 matches
Mail list logo
