--
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=34939
The following valid code snippet triggers an ICE since GCC 3.0:
template void foo();
template struct A
{
friend void foo<0>() __attribute((weak));
};
bug.cc:6: internal compiler error: tree check: expecte
The following valid code snippet triggers an ICE since at least GCC 2.95.3:
typedef void (*fptr)() __attribute((noreturn));
template void foo();
template void bar();
fptr f = bar< foo<0> >;
bug.cc:6: int
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3 regression] ICE with |[4.1/4.2/4.3 regression] ICE
|attribute weak
The following valid code snippet triggers an ICE since GCC 3.4.0:
template struct A
{
enum { a, b = a };
void foo(A) __attribute((weak));
};
bug.cc:5: internal compiler error: tree check: expected intege
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3 regression] ICE with |[4.1/4.2/4.3 regression] ICE
|double and attribute
The following valid code snippet triggers an ICE since GCC 3.3:
typedef double X __attribute((may_alias)) ;
template struct A
{
A();
};
A a;
bug.cc: In function 'void __static_initialization_and_destruct
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34935
The following valid code snippet triggers an ICE on mainline:
typedef int X __attribute((may_alias));
void foo(X);
void foo(int,int);
bug.cc:4: internal compiler error: same canonical type node for differen
--- Comment #6 from tammer at tammer dot net 2008-01-23 07:13 ---
Hallo,
this is exactly what I feared. But unfortunately I do not know exactly how to
fix this. I have attached the math.h from AIX 6.1. Maybe you can have a look at
the header and find a quick fix ?
Bye
Rainer
--
h
--- Comment #5 from tammer at tammer dot net 2008-01-23 07:12 ---
Created an attachment (id=15004)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15004&action=view)
AIX 6.1 TL0 SP2 math.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34794
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-23 07:12 ---
The following is invalid standard Fortran 77/90/95/2003 syntax,
volatile /C/
however, it seems to be a not uncommon Fortran 77 vendor extension, supported
by g77, ifort, sunf95, openf95, ...
--
http://gcc.
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-23 07:03 ---
For the mentioed patch see PR 33432
I'm not sure whether it makes sense to implement it, but if one could hide it
behind a -fxor / -fno-xor.
Ifort 10.1 has for instance:
-assume noold_xor
Prevents the compile
--- Comment #2 from pault at gcc dot gnu dot org 2008-01-23 06:48 ---
I do not see how to fix this one at the moment - Tobias' suggestion and other
attempts meet with a variety of rejections. I'll come back to it but must have
a final stab at PR34429 before we time out on bug fixes.
Th
--- Comment #9 from pault at gcc dot gnu dot org 2008-01-23 06:45 ---
(In reply to comment #8)
> we just bail out right now when we need to actually do something.
Yes, that's what I thought. In the circumstance where this block "exists", ie.
there is one beyond it, bailing out is OK.
--- Comment #7 from Ralf dot Wildenhues at gmx dot de 2008-01-23 06:42
---
(In reply to comment #5)
>
> > In an ideal world the toplevel configure would check at runtime and see what
> > subdirs are present and adjust its output accordingly. Also
> > --help=recursive
> > should be fi
--- Comment #3 from bergner at gcc dot gnu dot org 2008-01-23 06:31 ---
Created an attachment (id=15003)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15003&action=view)
Patch to force SDmode args and return values into FP registers.
Here is the ChangeLog for the patch I submitted
--- Comment #17 from ian at airs dot com 2008-01-23 05:55 ---
This is fixed in mainline.
--
ian at airs dot com changed:
What|Removed |Added
Status|WAITING
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-01-23 05:41
---
I am beginning to see it now. This does not help:
if (extent[n] <= 0)
return;
we just bail out right now when we need to actually do something.
--
jvdelisle at gcc dot gnu dot org changed:
--- Comment #15 from ian at airs dot com 2008-01-23 05:21 ---
I would be in favor of backporting to the gcc 4.2 branch. The option is new in
gcc 4.2, and this will make it less confusing to use.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32102
--- Comment #4 from jason at gcc dot gnu dot org 2008-01-23 05:12 ---
Subject: Bug 28560
Author: jason
Date: Wed Jan 23 05:11:58 2008
New Revision: 131755
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131755
Log:
PR c++/28560
* decl.c (groktypename): Also ignore
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-23 04:39 ---
Here is a reduced C testcase compile with -O2 -maltivec:
#define vector __attribute__((vector_size(16) ))
vector int f(int a, int b)
{
int g[10]={};
g[a] = b;
return (vector int){a,a,a,a} + (vector int){g[
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-01-23 04:01 ---
This testcase fails on some targets where size_t is not unsigned int (like
i386-darwin and x86_64-linux-gnu) .
/Users/apinski/src/local/gcc/gcc/testsuite/g++.dg/ext/pr34829.C:12: error:
'operator new' takes type 'si
--- Comment #5 from pmarques at grupopie dot com 2008-01-23 03:31 ---
I just found out another data point: this happens when you pass
-mmcu=atmega128, but not if you pass -mmcu=attiny13 (for instance).
--
pmarques at grupopie dot com changed:
What|Removed
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-01-23 03:25
---
Thats right Steve and we encourage everyone to use .neqv.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34933
--- Comment #2 from eshkinkot at gmail dot com 2008-01-23 03:10 ---
Created an attachment (id=15002)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15002&action=view)
src file
at first this bug was catched in real program and this single source file
created from it, may be it will
--- Comment #1 from eshkinkot at gmail dot com 2008-01-23 03:05 ---
Created an attachment (id=15001)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15001&action=view)
gcc -save-temps -v -W -Wall -O2 -c send_tiny.c
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-23
03:04 ---
Subject: Re: FAIL: gcc.dg/pr28796-[12].c (test for excess errors)
> I don't think this is a regression, this is a new testcase for the branch.
Yes, I missed the fact that the testcases are new.
> There
also crash with:
gcc version 4.1.3 20071209 (prerelease) (Debian 4.1.2-18)
gcc version 4.3.0 20080113 (experimental) [trunk revision 131510] (Debian
20080113-1)
gcc -v -W -Wall -O2 -c send_tiny.c
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c
--- Comment #2 from kargl at gcc dot gnu dot org 2008-01-23 02:58 ---
Roger Sayle implemented .xor., but it was not committed to the tree.
You can probably find discussion in the mailing list archive if you
care to do some spelunking. I recall the patch wasn't committed
because of poss
--- Comment #1 from bdavis at gcc dot gnu dot org 2008-01-23 02:51 ---
metcalf and reid, page 40 says that .neqv. is logically the same as XOR.
so, an easy work around is available.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34933
--- Comment #3 from hutchinsonandy at aim dot com 2008-01-23 02:50 ---
The pattern requires operand 1 to be same register as operand 0
Operands 1 & 2 share 2 subregs of same Himode register R22
But should have been solvable without any problem, since HI24 is just right!
QI:21 -> QI:24
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-23 02:41 ---
I don't think this is a regression, this is a new testcase for the branch.
There was most likely a forgot patch that should have been backported.
--
pinskia at gcc dot gnu dot org changed:
What|R
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-23
02:29 ---
Subject: Re: New: [4.2 Regression] FAIL:
gcc.dg/pr28796-[12].c (test for excess errors)
>link_error (first referenced in /var/tmp//ccjtth6i.o) (code)
Attached is tree dump.
Dave
--- Co
$ cat a.f
logical a,b,c
a = .TRUE.
b = .FALSE.
c = a .xor.b
print*,c
end
$ gfortran --version
GNU Fortran (GCC) 4.3.0 20071217 (experimental)
Copyright (C) 2007 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
Yo
--- Comment #2 from eric dot weddington at atmel dot com 2008-01-23 02:19
---
Command line to test:
avr-gcc -c -mmcu=atmega32 -DF_CPU=14745600UL -O2 dimmer_profile.c -o
dimmer_profile.o
Fails with -O[23]. Successful with -O[01s].
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=349
--- Comment #1 from eric dot weddington at atmel dot com 2008-01-23 02:13
---
Created an attachment (id=14999)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14999&action=view)
Reduced test case,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34932
>From WinAVR bug #1860717
http://sourceforge.net/tracker/index.php?func=detail&aid=1860717&group_id=68108&atid=520074
dimmer_profile.c: In function 'DIM_action':
dimmer_profile.c:26: error: could not find a spill register
(insn 30 29 31 3 (set (reg:HI 24 r24 [53])
(plus:HI (zero_extend:HI
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/
/mnt/
gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr28796-1.c -ffinite-math-only
-fno-show-colu
mn -lm -o pr28796-1.exe(timeout = 300)
/usr/ccs/bin/ld: Unsatisfied symbols:
link_error (first referenced in /var/tmp//ccjtth6i
--- Comment #9 from aoliva at gcc dot gnu dot org 2008-01-23 01:51 ---
Subject: Bug 33984
Author: aoliva
Date: Wed Jan 23 01:50:45 2008
New Revision: 131751
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131751
Log:
gcc/cp/ChangeLog:
PR c++/33984
* call.c (reference_binding): Fo
--- Comment #8 from aoliva at gcc dot gnu dot org 2008-01-23 01:51 ---
Fixed.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from Joey dot ye at intel dot com 2008-01-23 01:45 ---
(In reply to comment #2)
> I bet if you put jj in struct and don't have a nested function, this will be
> the same issue.
Not the same. In fact it passes if not referenced by a nested function. The
root is in tree-nes
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-01-23 01:10 ---
(In reply to comment #5)
> AFAICT vector_mode_valid_p knows about this fallback option.
> Is that incorrect? See the last line...
I think by the time we get here, targetm.scalar_mode_supported_p will have
already b
--- Comment #5 from tromey at gcc dot gnu dot org 2008-01-23 01:05 ---
AFAICT vector_mode_valid_p knows about this fallback option.
Is that incorrect? See the last line...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34911
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34856
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-01-23 00:31 ---
(In reply to comment #4)
> _Then_, at -O2, we ICE in simplify_immed_subreg (x86_64 -m32 -msse)
I get this same ICE for spu-elf too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-23 00:16 ---
Grrr, I guess I will look into this.
Most likely to get this on most other Powerpc targets, you need -maltivec.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-23 00:14 ---
*** Bug 34929 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34930
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-23 00:14 ---
*** This bug has been marked as a duplicate of 34930 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
On powerpc-apple-darwin9, trunk rev.131745gfortran.dg/cray_pointers_2.f90 fails
at -O3 with:
[karma] f90/bug% gfc -fcray-pointer -O3
/opt/gcc/_gcc-clean/gcc/testsuite/gfortran.dg/cray_pointers_2.f90
/opt/gcc/_gcc-clean/gcc/testsuite/gfortran.dg/cray_pointers_2.f90: In function
'ptr12':
/opt/gcc/_g
--
Summary: [4.3 Regression] gfortran.dg/cray_pointers_2.f90:3360:
internal compiler error: in
instantiate_virtual_regs_in_insn, at function.c:1564
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Seve
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13717
--- Comment #8 from dominiq at lps dot ens dot fr 2008-01-22 23:50 ---
On i686-apple-darwin9, testsuite/gcc.c-torture/compile/pr34856.c gives an ICE
at -O3 with trunk rev.131745:
[ibook-dhum] f90/bug% /opt/gcc/w1-gcc4.3w/bin/gcc -O3
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compil
--- Comment #4 from pdb_ml at yahoo dot com dot au 2008-01-22 23:49 ---
As the originator of this request I can verify that the patch provided by
Fabian Groffen as part of Bug 34775 is functional and works as advertised. I
believe the patch should be reviewed and integrated.
The patch d
--- Comment #4 from hutchinsonandy at aim dot com 2008-01-22 23:41 ---
The WRONG CODE is still present on 4.3.0 20080121 HEAD.
This is a regresssion from 4.2 (A big one too!)
4.2.2 20071221 (Winavr) OK
4.3.0 20071213 FAILS
4.3.0 HEAD 20080121 FAILS
vr-gcc -c -mmcu=atmega128 -g -w
--- Comment #13 from jakub at gcc dot gnu dot org 2008-01-22 23:41 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail
--- Comment #52 from dominiq at lps dot ens dot fr 2008-01-22 23:25 ---
> You mean does not, right?
Yes indeed! sorry for skipping the negation. The assembly follows. Comparing it
to the assembly for wo_prof_mult_field_peeling_db.c in comment #35, the
striking difference is that the lat
$ cat vol.f
integer A
common /C/ A
volatile /C/
end
$ gfortran --version
GNU Fortran (GCC) 4.3.0 20071217 (experimental)
Copyright (C) 2007 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of
--- Comment #51 from olga at il dot ibm dot com 2008-01-22 22:58 ---
(In reply to comment #50)
> > I wonder what it will be if we use -fno-unroll-loops in compilation
> It does change the segfault:
You mean does not, right?
Can you please send me its assembly (with -fno-unroll-loops) t
--- Comment #20 from burnus at gcc dot gnu dot org 2008-01-22 22:55 ---
> It appears that the fix to PR34760 breaks my original testcase.
> (r131624 from 20080118 still works, all builds after 20080120 fail).
O well, the checked in test case of this PR uses "WRITE(" (note the "(") while
--- Comment #50 from dominiq at lps dot ens dot fr 2008-01-22 22:47 ---
> I wonder what it will be if we use -fno-unroll-loops in compilation
It does change the segfault:
[ibook-dhum] f90/bug% /opt/gcc/gcc4.3w/bin/gcc -O3 -fno-unroll-loops
-fipa-struct-reorg -fipa-type-escape -fwhole-p
--- Comment #19 from anlauf at gmx dot de 2008-01-22 22:39 ---
It appears that the fix to PR34760 breaks my original testcase.
(r131624 from 20080118 still works, all builds after 20080120 fail).
Tobias?
--
anlauf at gmx dot de changed:
What|Removed
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2008-01-22 22:32
---
.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
URL|
ombine.c (try_combine): Stop and undo after the first combination
if an autoincrement side-effect on the first insn has effectively
been lost.
Added:
branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/20080122-1.c
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
ombine.c (try_combine): Stop and undo after the first combination
if an autoincrement side-effect on the first insn has effectively
been lost.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20080122-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/t
--- Comment #6 from Ralf dot Wildenhues at gmx dot de 2008-01-22 22:25
---
(In reply to comment #2)
> (In reply to comment #0)
> >
> > libstdc++-v3 gives:
> > $ ../../src/gcc-4.3/configure --disable-libstdc++-v3
> > configure: error: invalid feature name: libstdc++-v3
>
> This error i
--- Comment #6 from pault at gcc dot gnu dot org 2008-01-22 22:22 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from bangerth at math dot tamu dot edu 2008-01-22 22:20
---
Subject: Re: Duplicate error message about abstract class
> I think this is because we clone the dtor.
Possible. If we take away the base class, then the error message appears
only once...
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-22 22:17 ---
I think this is because we clone the dtor.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from dje at gcc dot gnu dot org 2008-01-22 22:15 ---
libsdc++ does not appear to be configured correctly on AIX 6.1.
libstdc++-3/libmath/stubs.c and /usr/include/math.h are not interacting
correctly and functions, such as fabsl, are getting redefined by math.h,
causing pr
--- Comment #3 from zadeck at naturalbridge dot com 2008-01-22 22:15
---
Subject: Re: [4.3 Regression] FAIL: gcc.c-torture/execute/va-arg-15.c
execution, -O3 -fomit-frame-pointer -funroll-loops
dave at hiauly1 dot hia dot nrc dot ca wrote:
> --- Comment #2 from dave at hiauly1 d
I get a duplicate error message for this code:
--
class A {};
struct C : A
{
virtual ~C () = 0;
} c;
-
bangerth/tmp> c++ -c x.cc
x.cc:6: error: cannot declare variable 'c' to be of abstract type 'C'
x.cc:4: note: because the following virtual functions are pure within
--- Comment #10 from bangerth at dealii dot org 2008-01-22 22:08 ---
The patch was withdrawn.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729
--- Comment #9 from bangerth at dealii dot org 2008-01-22 22:06 ---
Apparently fixed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-01-22 21:56 ---
(In reply to comment #3)
> It is interesting that handle_vector_size_attribute doesn't
> call vector_mode_valid_p, but the corresponding mode attribute does.
Because the vector_size attribute should be generic and n
--- Comment #49 from olga at il dot ibm dot com 2008-01-22 21:55 ---
(In reply to comment #48)
sorry, with
-O3 -fipa-struct-reorg -fipa-type-escape -fwhole-program -combine
wo_prof_mult_fields_peeling.c -fno-unroll-loops
Olga
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
--- Comment #3 from tromey at gcc dot gnu dot org 2008-01-22 21:51 ---
It is easy to reject bools, but I wonder if that is enough.
It is interesting that handle_vector_size_attribute doesn't
call vector_mode_valid_p, but the corresponding mode attribute does.
Anyway, I can regtest & sub
--- Comment #7 from tromey at gcc dot gnu dot org 2008-01-22 21:44 ---
Subject: Bug 34859
Author: tromey
Date: Tue Jan 22 21:43:49 2008
New Revision: 131743
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131743
Log:
libcpp
PR c++/34859:
* macro.c (_cpp_create_def
--- Comment #6 from tromey at gcc dot gnu dot org 2008-01-22 21:43 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-22
21:39 ---
Subject: Re: [4.3 Regression] FAIL: gcc.c-torture/execute/va-arg-15.c
execution, -O3 -fomit-frame-pointer -funroll-lo
> Supposedly a dup of PR34884.
Could be. gfortran.dg/array_constructor_9.f90 is also
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-22 21:22 ---
Subject: Bug 34875
Author: pault
Date: Tue Jan 22 21:22:13 2008
New Revision: 131742
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131742
Log:
2008-01-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-22 21:14 ---
Supposedly a dup of PR34884.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34926
--- Comment #12 from dje at gcc dot gnu dot org 2008-01-22 21:12 ---
Subject: Bug 34529
Author: dje
Date: Tue Jan 22 21:12:05 2008
New Revision: 131741
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131741
Log:
PR target/34529
* config/rs6000/rs6000.c (rs6000_leg
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||zadeck at gcc dot gnu dot
|
--- Comment #6 from steven at gcc dot gnu dot org 2008-01-22 21:01 ---
There is some discussion about this bug in the following thread on gcc-patches:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00326.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33916
--- Comment #5 from Ralf dot Wildenhues at gmx dot de 2008-01-22 20:43
---
Subject: Re: toplevel ./configure --help is incomplete
* brian at dessent dot net wrote on Tue, Jan 22, 2008 at 07:38:35PM CET:
>
> Remember that this toplevel configure is shared between gcc, binutils, gdb,
>
Executing on host: /home/dave/gnu/gcc-4.3/objdir/gcc/xgcc
-B/home/dave/gnu/gcc-4.3/objdir/gcc/
/home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.c-torture/execute/va-arg-15.c -w
-O3 -fomit-frame-pointer -funroll-loops -fno-show-column -lm -o
/home/dave/gnu/gcc-4.3/objdir/gcc/testsuite/gcc/va-arg-1
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-01-22 20:24
---
Even though it has not been said here yet, the way to fix this is to have
lmw/stmw emitted for r30/r31. Though this only saves 8 bytes per function.
It is the only fix which will help. It does not fix the "regr
--- Comment #48 from olga at il dot ibm dot com 2008-01-22 20:21 ---
Looking closely on the assembly files you generated, I see that in the version
that fails there is a loop unrolling. On my linux x86_64 machine the assembly
generated for 64 bits has no loop unrolling effects, also as t
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-22 20:16 ---
I guess we need to treat DECL_NO_TBAA_P in more places to make it really work,
I suppose the CHANGE_DYNAMIC_TYPE_EXPR fix also doesn't work in all cases for
the same reason.
But as it is mainly the may_alias passes
--- Comment #18 from hubicka at ucw dot cz 2008-01-22 20:12 ---
Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel
> So, we indeed think this issue is invalid, right?
I am convinced so. -mpc64 does not change code generation. I messed up
the change of britten flags
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-22 20:12 ---
THis is not a bug,
-fno-merge-constants works only across TUs and not inside a TU.
>From the documentation:
Attempt to merge identical constants (string constants and floating point
constants) across compilation unit
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-01-22 20:09
---
So, we indeed think this issue is invalid, right?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34852
$ cat sections.c
extern void f( char const* );
__attribute__(( section( ".text.g" ))) void g( void ) { f( "test" ); }
__attribute__(( section( ".text.h" ))) void h( void ) { f( "test" ); }
$ /opt/gcc43/bin/gcc -S -Os -fno-merge-constants sections.c
.section.rodata
.LC0: .string
--- Comment #4 from jason at gcc dot gnu dot org 2008-01-22 20:07 ---
Not worth fixing in 4.1/4.2.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-22 20:06 ---
Fixed on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to f
--- Comment #4 from jason at gcc dot gnu dot org 2008-01-22 20:06 ---
That patch looks right to me. This seems to be a bug caused by the deceptive
name "gen_type_die" which really should be called something like
"gen_main_variant_type_die".
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #8 from burnus at gcc dot gnu dot org 2008-01-22 19:59 ---
I only want to point out that the patch above only fixes a minor problem (which
was part of the draft patch): Before, for absent optional character strings no
string length was passed. Now "0" is passed. I don't know
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-22 19:53 ---
This is fixed on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34924
--- Comment #2 from jason at gcc dot gnu dot org 2008-01-22 19:51 ---
Subject: Bug 34912
Author: jason
Date: Tue Jan 22 19:50:37 2008
New Revision: 131740
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131740
Log:
PR c++/34912
* friend.c (do_friend): Check for pr
1 - 100 of 207 matches
Mail list logo
