--- Comment #7 from ian at airs dot com 2008-01-28 04:12 ---
Created an attachment (id=15036)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15036&action=view)
DECL_NO_TBAA patch
With regard to comment #3, I just bootstrapped and tested this patch on
i686-pc-linux-gnu. Any opinion
--- Comment #1 from andry at inbox dot ru 2008-01-28 02:46 ---
In gcc 4.3 (trunk, 2008.01.27), bug still doesn't fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34158
--- Comment #28 from jason at gcc dot gnu dot org 2008-01-28 02:20 ---
Really fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #27 from jason at gcc dot gnu dot org 2008-01-28 02:20 ---
Subject: Bug 27177
Author: jason
Date: Mon Jan 28 02:19:38 2008
New Revision: 131899
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131899
Log:
PR c++/27177
* class.c (build_base_path): Fix pr
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-01-28 02:11
---
Fixed.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCO
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-01-28 02:09
---
Subject: Bug 34994
Author: jvdelisle
Date: Mon Jan 28 02:09:07 2008
New Revision: 131898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131898
Log:
2008-01-27 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-01-28 01:18 ---
(In reply to comment #6)
> Am I wrong, here ?
Semi, what is happening is the values for std::less is being stored in
the fpr register and that is really a 80bit register and not a 64bit fp
register. -mpc64 is anot
--- Comment #3 from andry at inbox dot ru 2008-01-28 01:16 ---
I build trunk (2008.01.27) and run test. Several tests still failing:
FAILED: test5
FAILED: test7
FAILED: test20
FAILED: test21
FAILED: test25
FAILED: test26
FAILED: test37
FAILED: test46
FAILED: test47
FAILED: test48
10 test
--- Comment #1 from hjl dot tools at gmail dot com 2008-01-28 00:17 ---
With -m32, we got
doit ()
{
real(kind=4) doit1[2];
{
struct array1_real(kind=4) parm.6;
parm.6.dtype = 281;
parm.6.dim[0].lbound = 1;
parm.6.dim[0].ubound = 2;
parm.6.dim[0].stride = 1;
--- Comment #6 from roebel at ircam dot fr 2008-01-28 00:14 ---
Andrew,
while -ffloat-store fixes the problem, this solution is obviously not
acceptable. Moreover, here the problem is not that I compare floats
using <= the problem is that std::set::insert(double) compares
set elements
On Linux/Intel64 with revision 131893, I got
Executing on host:
/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gfortran/../../gfortran
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gfortran/../../
/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/missing_optional_dummy_5.f90
-
--- Comment #102 from pinskia at gcc dot gnu dot org 2008-01-27 23:17
---
*** Bug 34992 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-01-27 23:17 ---
Even though -mfpmath=sse is used, x87 is used in some cases still and what you
are seeing is an effect of PR 323. Closing as a duplicate. You should be more
careful with your comparison loop of FP values.
*** Thi
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34993
The following valid code snippet triggers an ICE since GCC 4.0.0:
typedef int x[] __attribute((may_alias));
bug.c:1: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
The c
--- Comment #4 from roebel at ircam dot fr 2008-01-27 23:05 ---
yes indeed, that fixes the problem.
now, does that mean holding double values in a set
is not possible?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34992
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-27 22:58 ---
Since you are doing some <= for fp, does -ffloat-store help?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34992
--- Comment #2 from roebel at ircam dot fr 2008-01-27 22:57 ---
Created an attachment (id=15035)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15035&action=view)
script to compile the source and reproduce the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34992
--- Comment #1 from roebel at ircam dot fr 2008-01-27 22:55 ---
Created an attachment (id=15034)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15034&action=view)
source file for reproducing the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34992
Hello,
for some time now I had problems with one of my projects with compilers gcc
4.2.1 and above. For obscure reasons my testsuite did not run correctly when I
did compile with optimization enabled. I now tracked the problem down
to a very strange bug that I can reproduce with a test case that I
--- Comment #7 from pault at gcc dot gnu dot org 2008-01-27 22:27 ---
Created an attachment (id=15033)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15033&action=view)
A patch for this regression
I have just put this on to bootstrap and regtest whilst I sleep. Since it
changes no
--- Comment #28 from pcarlini at suse dot de 2008-01-27 22:27 ---
(In reply to comment #27)
> So I guess you're using an older version of darwin that doesn't know about
> pie.
I'm testing on Darwin 8.11, that is the last Tiger, still pretty common...
> In that case I guess your patc
--- Comment #27 from ghazi at gcc dot gnu dot org 2008-01-27 22:03 ---
(In reply to comment #26)
> (In reply to comment #23)
> > I meant for just using -fpie on darwin with no other changes.
> The problem I see, on darwin, is that -fpie cannot be passed to the driver,
> because eventuall
--- Comment #26 from pcarlini at suse dot de 2008-01-27 21:35 ---
(In reply to comment #23)
> I meant for just using -fpie on darwin with no other changes.
The problem I see, on darwin, is that -fpie cannot be passed to the driver,
because eventually, the linker rejects -pie. Is that a
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2008-01-27 21:32
---
Right, sorry.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #25 from ghazi at gcc dot gnu dot org 2008-01-27 21:17 ---
(In reply to comment #22)
> Created an attachment (id=15031)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15031&action=view) [edit]
> New draft
I tried your latest draft and it fails for has_nothrow_assign.C b
--- Comment #24 from ghazi at gcc dot gnu dot org 2008-01-27 21:10 ---
Patch which works on i686-unknown-linux-gnu:
2008-01-27 Kaveh R. Ghazi <[EMAIL PROTECTED]>
* g++.dg/ext/has_nothrow_assign.C: Add -fpie when __PIC__.
* g++.dg/ext/has_nothrow_constructor.C: Likewis
--- Comment #23 from ghazi at gcc dot gnu dot org 2008-01-27 21:09 ---
(In reply to comment #20)
> Hi Kaveh. I just checked darwin and indeed, we have an issue there, which,
> AFAICS, is not worked around with -fpie.
Hmm, did you mean darwin failed with (your patch + -fpie) or just with
--- Comment #22 from pcarlini at suse dot de 2008-01-27 20:49 ---
Created an attachment (id=15031)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15031&action=view)
New draft
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
--- Comment #21 from pcarlini at suse dot de 2008-01-27 20:47 ---
Since you are already set for this extended kind of testing, can you run the
new patch? Thanks a lot in advance!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
--- Comment #20 from pcarlini at suse dot de 2008-01-27 20:40 ---
Hi Kaveh. I just checked darwin and indeed, we have an issue there, which,
AFAICS, is not worked around with -fpie. I say, let's just skip the test when
__PIC__ is defined, and be done with it.
--
http://gcc.gnu.org/b
--- Comment #19 from ghazi at gcc dot gnu dot org 2008-01-27 20:09 ---
(In reply to comment #18)
> If it does, maybe instead you simply nuke the problematic cases when you see
> __PIC__.
Another option that might work is to add -fpie when we see __PIC__. That
should work on darwin etc
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-01-27 19:56
---
Fixed on trunk
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #18 from ghazi at gcc dot gnu dot org 2008-01-27 19:54 ---
(In reply to comment #17)
> Hi Kaveh. One problem I can see is that we are dealing with special member
> functions, like constructors and assignment operators
Ah, I guess you can't make those static.
> Can you see a
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-01-27 19:51
---
Subject: Bug 34990
Author: jvdelisle
Date: Sun Jan 27 19:50:16 2008
New Revision: 131891
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131891
Log:
2008-01-27 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-01-27 19:39
---
Subject: Bug 34990
Author: jvdelisle
Date: Sun Jan 27 19:38:59 2008
New Revision: 131890
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131890
Log:
2008-01-27 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #10 from bero at arklinux dot org 2008-01-27 19:36 ---
> this should make lot of difference on K&R code (I wonder if
> any is still around in usual distro)
Some parts of xorg still follow K&R conventions, few parts of teTeX have K&R
code in them, cdrtools is fully K&R (I "fi
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-01-27 19:33
---
I get no regressions with the fix in comment #2. I will just commit it as
obvious.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34990
--- Comment #5 from debian-gcc at lists dot debian dot org 2008-01-27
19:27 ---
the fix was checked in on the trunk only; please reopen the report
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34688
--- Comment #9 from hubicka at ucw dot cz 2008-01-27 19:24 ---
Subject: Re: [4.3 regression] calling a function with undefined parameters
causes segmentation fault at -O1 or higher
However the failure here is not early calling of cgraph_local_info (it
is ugly, but harmless, we are just
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-01-27 19:21 ---
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #17 from pcarlini at suse dot de 2008-01-27 18:54 ---
Hi Kaveh. One problem I can see is that we are dealing with special member
functions, like constructors and assignment operators. Can you see anything
wrong with the straightforward implementation of idea per the attached
--- Comment #16 from pcarlini at suse dot de 2008-01-27 18:51 ---
Created an attachment (id=15030)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15030&action=view)
Draft idea for the -fpic/-fPIC fails
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2008-01-27 18:47
---
Fixed in the above revision.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from ghazi at gcc dot gnu dot org 2008-01-27 18:39 ---
> All in all I'm now thinking that
> it's good to have such tests, we should only conditionalize the result of the
> tests on -fpic/PIC, I suppose we do have a macro for that?!?
How about binding locally when pic? E
--- Comment #17 from manu at gcc dot gnu dot org 2008-01-27 18:39 ---
Fixed in GCC 4.2.3
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NE
--- Comment #16 from manu at gcc dot gnu dot org 2008-01-27 18:37 ---
Subject: Bug 32102
Author: manu
Date: Sun Jan 27 18:36:59 2008
New Revision: 131887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131887
Log:
2008-01-27 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR 3
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-01-27 18:37
---
Reverting with the following clears this bug:
Index: array.c
===
--- array.c (revision 131876)
+++ array.c (working copy)
@@ -1025,7 +1025,6
--- Comment #2 from aldot at gcc dot gnu dot org 2008-01-27 18:35 ---
right.. thus closing.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-01-27 18:19 ---
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-01-27 18:16 ---
(gdb) p debug_generic_expr (stmt)
*(struct globals * *) &ptr_to_globals = 0B
Well that is obviously not valid gimple.
tree-ssa-forwprop.c is causing it:
#10 0x00550bff in mark_symbols_for_renaming (stmt=0x43497060)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.3.0
http://gcc
--- Comment #7 from aldot at gcc dot gnu dot org 2008-01-27 18:10 ---
original and reduced testcases work with 4.2:
$ gcc-4.2 -O2 -c -o bazoo.o one.i two.i -combine ; echo $?
0
$ gcc-4.2 -O2 -c -o bazoo.o syslogd.i xregcomp.i -combine ; echo $?
0
$ gcc-4.2 --version | sed 1q
gcc-4.2 (GC
--- Comment #8 from hubicka at ucw dot cz 2008-01-27 18:10 ---
Subject: Re: [4.3 regression] calling a function with undefined parameters
causes segmentation fault at -O1 or higher
> One more reason to gimplify unit-at-a-time...
Yep, on the other hand there is probably not much need t
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-01-27 18:05 ---
First file:
extern struct globals *const ptr_to_globals;
struct globals { };
int syslogd_main(int argc, char **argv)
{
(*(struct globals**)&ptr_to_globals) = 0;
}
- CUT -
Second file:
extern struct globals
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3 |P4
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-27 18:00 ---
Yet another IMA bug. P2. Does 4.2 work?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #20 from ubizjak at gmail dot com 2008-01-27 17:53 ---
(In reply to comment #19)
> The problem in comment #13 is fixed for 4.3.0 by the fix for PR 34771.
Oops, PR 34711.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #19 from ubizjak at gmail dot com 2008-01-27 17:52 ---
The problem in comment #13 is fixed for 4.3.0 by the fix for PR 34771.
--
ubizjak at gmail dot com changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-01-27 17:40 ---
Reducing, the order for the files matter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34989
_i686/mpfr --disable-nls
--enable-threads --disable-multilib --with-arch=pentium4 --with-tune=pentium4
--disable-libgomp
Thread model: posix
gcc version 4.3.0 20080127 (experimental) (GCC)
--
Summary: ICE in in get_addr_dereference_operands, at tree-ssa-
opera
--- Comment #3 from aldot at gcc dot gnu dot org 2008-01-27 17:26 ---
Works fine with
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
And did work with trunk until recently (at least end of december, IIRC)
--
aldot at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from aldot at gcc dot gnu dot org 2008-01-27 17:24 ---
Created an attachment (id=15029)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15029&action=view)
file2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34989
--- Comment #1 from aldot at gcc dot gnu dot org 2008-01-27 17:24 ---
Created an attachment (id=15028)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15028&action=view)
file 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34989
I have wrongly reported this regression under PR34848: pr33998.f90 started to
fail after rev. 131676 and pr34897.f90 after rev. 131679. These ICEs occurs now
for the original test cases:
[ibook-dhum] f90/bug% cat pr33998.f90
module test
implicit none
contains
function my_string(x)
--- Comment #32 from steven at gcc dot gnu dot org 2008-01-27 15:35 ---
I have re-tested Zdenek's patch on arm-unknown-elf.
128 files are smaller with the patch, and 126 files are larger. The total size
increase with the patch is 324 bytes on 3601910 bytes total size (or <0.01%)
with r
--- Comment #5 from rakdver at gcc dot gnu dot org 2008-01-27 15:35 ---
The patch fixes the problem for me on ppc (tested in crosscompiler) and on
amd64, I did not check the other architectures (arm, hppa, mips)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34711
--- Comment #4 from steven at gcc dot gnu dot org 2008-01-27 15:05 ---
Fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34711
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-27 14:19 ---
One more reason to gimplify unit-at-a-time...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-27 14:14 ---
One important structure copy propagation that SRA is not able to handle is
struct X { int i; int j; };
void foo(struct X);
inline void wrap(struct X w) { foo(w); }
void bar(struct X x) { wrap(x); }
where a copy fr
--- Comment #6 from hubicka at ucw dot cz 2008-01-27 13:54 ---
Subject: Re: [4.3 regression] calling a function with undefined parameters
causes segmentation fault at -O1 or higher
cgraph_local_info still behaves as expected returning NULL when info is
not computed yet. Unfortunately c
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-27 13:45 ---
Copyprop for aggregates would also help here.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from aldot at gcc dot gnu dot org 2008-01-27 13:36 ---
$ for i in 2.95 3.3 3.4 4.1 4.3.orig-HEAD 4.3-HEAD;do echo "# GCC $(gcc-$i
--version | sed 1q)";gcc-$i -Os -c -o pr.o.gcc-$i pr23782.c;done
# GCC 2.95.4
pr23782.c:8: warning: `fastcall' attribute directive ignored
# GC
--- Comment #14 from pcarlini at suse dot de 2008-01-27 13:34 ---
(In reply to comment #13)
> If a function isn't marked nothrow and the function can be overridden by a
> shared library (that is, it doesn't bind locally), the compiler cannot derive
> such property from its body.
Thanks
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-27 13:27 ---
I think this is another variant of PR28831. For the simplified testcase
typedef struct {
unsigned short x, y;/* x should be the easyest to read */
} coord;
void setpixel (coord xy, unsigned color);
voi
Hello world,
this fixes PR 34980, a 4.3 regression.
In the PR, there is a comment from Tobias B. with an alternate approach.
I was already into testing my patch when I read that comment, which is
why I didn't pursue that approach further. I have to admit that I feel
better about adding something
--- Comment #5 from mariobonino at ubuntu-it dot org 2008-01-27 12:56
---
I don't know if this is ok but I've got this.
http://pastebin.ubuntu.com/3935/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34983
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-27 12:50 ---
The initialize_command_download() exposes the usual memory-hungriness of GCC
with repetitive C++ initializers. We have plenty of bugreports with testcases
for this, closing as invalid. And yes, 32MB + 200MB swap wi
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-01-27 12:48
---
If a function isn't marked nothrow and the function can be overridden by a
shared library (that is, it doesn't bind locally), the compiler cannot derive
such property from its body.
(I didn't look at the tests, bu
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-27 12:45 ---
Ok, someone needs to analyze this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from roebel at ircam dot fr 2008-01-27 12:35 ---
Hi,
I run the tests with g++ 422 and it seems to me the issue is closed.
Compilation without the salias-max-implicit-fields flag is nor producing
any substantial increase in run time any more and with and without
this par
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-27 12:22 ---
We still need preprocessed souce (you get that from passing -save-temps) of the
affected file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34983
--- Comment #15 from dominiq at lps dot ens dot fr 2008-01-27 12:02 ---
> Note that I am not sure to blame the right patch.
I was correct, pr33998.f90 started to fail after rev. 131676 and pr34897.f90
after rev. 131679.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34848
--- Comment #3 from pluto at agmk dot net 2008-01-27 11:46 ---
4.3.0 20080127:
textdata bss dec hex filename
281 0 0 281 119 tmp.o
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23782
--- Comment #12 from pcarlini at suse dot de 2008-01-27 11:44 ---
Yes, I noticed. Frankly, I'm not really worried because of the nature of the
tests: the checks can give different answers depending on whether the compiler
is able or not to figure out that a given function cannot throw. F
--- Comment #14 from dominiq at lps dot ens dot fr 2008-01-27 11:26 ---
Note that I am not sure to blame the right patch. What I can tell for sure is
that pr33998.f90 started to fail between the 19th (working, rev. 131656) and
the 20th (ICE, rev. 131679), and pr34897.f90 between the 20th
--- Comment #13 from dominiq at lps dot ens dot fr 2008-01-27 10:41 ---
Following comment #12, I also see an ICE for pr34897:
pr34897.f90: In function 'my_string':
pr34897.f90:1: warning: Function does not return a value
pr34897.f90:4: internal compiler error: in gfc_typenode_for_spec,
--- Comment #6 from pault at gcc dot gnu dot org 2008-01-27 10:34 ---
I note that the pigeon carrying my reply to #3 got lost; my subsequent message
must therefore be a bit mysterious.
Changing the name of the symtree of an unwanted symbol from 'foo' to
'hidden.foo' is completely screwi
--- Comment #12 from dominiq at lps dot ens dot fr 2008-01-27 10:32 ---
It seems that this patch breaks the original test case of pr33998:
pr33998.f90: In function 'my_string':
pr33998.f90:7: internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:842
but not the re
--- Comment #1 from giamby at infinito dot it 2008-01-27 10:26 ---
Created an attachment (id=15027)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15027&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34988
I'm trying to build gcc 4.3 on a PS3 with a ppc linux (yellow dog linux 5.1,
gcc 4.1.1, binutils 2.18).
I get the following error:
/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/./gcc/xgcc -v
-save-temps -shared-libgc
c -B/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/./gcc -n
--- Comment #3 from mariobonino at ubuntu-it dot org 2008-01-27 10:09
---
That error was received on a Ubuntu build machine so I don't have information
about memory. However, I tried to build the package on my computer and I
received the same error. I have 2GB RAM and gcc-4.2.2-7ubuntu1
--- Comment #2 from pluto at agmk dot net 2008-01-27 09:48 ---
(In reply to comment #1)
> Can someone provide numbers for 4.1, 4.2 and 4.3?
>
4.1.2 (-Os -march=i486)
textdata bss dec hex filename
281 0 0 281 119 tmp.o
4.2.2 20071010:
text
94 matches
Mail list logo
