--- Comment #12 from ebotcazou at gcc dot gnu dot org 2008-01-06 08:07
---
I don't like it much. I think it puts the work in the wrong place --
libcpp and the lexer -- when, IMO, the problem should be addressed
by changing dbxout.c (and perhaps the debug API).
I'm afraid that
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-06 09:08 ---
Subject: Bug 34662
Author: burnus
Date: Sun Jan 6 09:07:47 2008
New Revision: 131348
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131348
Log:
2008-01-06 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-06 09:19 ---
Subject: Bug 34660
Author: burnus
Date: Sun Jan 6 09:18:43 2008
New Revision: 131349
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131349
Log:
2008-01-06 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-06 09:22 ---
Subject: Bug 34654
Author: burnus
Date: Sun Jan 6 09:21:27 2008
New Revision: 131350
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131350
Log:
2008-01-06 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #14 from burnus at gcc dot gnu dot org 2008-01-06 09:39 ---
Posted patch for this PR and PR 34540.
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00192.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34387
--- Comment #18 from burnus at gcc dot gnu dot org 2008-01-06 09:40 ---
Posted patch for this PR and PR 34387.
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00192.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-06 09:56 ---
The problem is we have loads of unpartitionable SFTs. There are workarounds
possible that only might affect performance of generated code, for example
you can use --param salias-max-array-elements=0, which will
--- Comment #7 from burnus at gcc dot gnu dot org 2008-01-06 10:02 ---
FIXED on the trunk (4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-06 10:03 ---
FIXED on the trunk (4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-06 10:03 ---
FIXED on the trunk (4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-06 10:07 ---
Note that this shouldn't really be affected by strict aliasing or not. Note
that the FE generated IL causes the first alias pass to emit too conservative
alias info as well:
# VUSE MPT.5965_208230
D.6049_4652
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-06 10:08 ---
Patch posted by Paul:
http://gcc.gnu.org/ml/fortran/2008-01/msg00048.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
This is just a reminder to ensure that Richard's patch does not get forgotten:
http://gcc.gnu.org/ml/fortran/2008-01/msg00019.html
(especially since the patch tracker is currently down.)
This adds a middle-end PAREN_EXPR tree code that acts as re-association
barrier for floating point
--- Comment #8 from burnus at gcc dot gnu dot org 2008-01-06 10:24 ---
So, to sum up, the situation could be significantly improved by improving
the FE. (Like I noticed for I/O statements, where I provided a patch -
that was not accepted - to share temporary variables created for
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-06 10:34 ---
Basically, not re-using array descriptor variables is as bad as not re-using
I/O descriptor variables. I also wonder what this _gfortran_internal_{un,}pack
is about?
For
taux=gn(p2+p4)
gfortran generates
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-01-06 10:38
---
This one:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01762.html
basically it mentiones async I/O as a reason to not do it, but instead the
callee can copy the I/O structure in that case instead (it probably
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-01-06 10:50
---
So, currently you can build up arbitrary large chains of virtual clobbers with
write (*,*) 'hello'
write (*,*) 'hello'
...
as each of those writes create two un-partitionable SFTs. For arrays
temporaries
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-01-06 11:09
---
Actually it isn't that bad for I/O as long as there are no pointers to the
dt_parm structs in the IL (function arguments are ok).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-01-06 11:13
---
For array temporaries the pinning of SFTs happens because we have the address
of
the actual array _data_ in the IL:
# SFT.10_52 = VDEF SFT.10_51(D)
atmp.0.data = A.1;
the array descriptor itself is not the
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-01-06 11:46
---
As of optimization, the conversion sequence
atmp.0.data = A.1;
D.540_5 = atmp.0.data;
D.541_6 = (real(kind=4)[0:] *) D.540_5;
...
(*D.541_6)[S.5_1] = D.545_14;
can be optimized to
A.1[S.5_1] =
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-06 12:01 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-06 12:02 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-06 12:18 ---
Please narrow down the particular loop in your testcase that gets slower. It
looks like the testsuite measures several things.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
char_pointer_func.f90 is failing at -O3 on mips-linux-gnu because
of an aliasing bug. We have a function sfoo() that returns a pointer
to a string of length 4:
function sfoo () result (sc1)
character*4, pointer :: sc1
allocate (sc1)
sc1 = abcd
end function sfoo
It gets the
--- Comment #1 from rsandifo at gcc dot gnu dot org 2008-01-06 12:24
---
Testing a patch.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-01-06 12:07
---
Note that the large FRE compile-time is a dup of PR34450, try experimenting
with --param sccvn-max-scc-size=N and find a N where the problem vanishes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-06 12:29 ---
This is a target specific issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-06 12:52 ---
I bet this also fixes PR 14741.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34685
--- Comment #3 from sam at gcc dot gnu dot org 2008-01-06 13:41 ---
This is already fixed in the current SVN version.
When you report bugs against an unreleased version, please make sure you use a
recent one before reporting the bug.
--
sam at gcc dot gnu dot org changed:
--- Comment #5 from joseph at codesourcery dot com 2008-01-06 15:12 ---
Subject: Re: Optimization generates incorrect code
with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
On Sat, 5 Jan 2008, rguenth at gcc dot gnu dot org wrote:
I wouldn't read the language
--- Comment #1 from eres at il dot ibm dot com 2008-01-06 15:26 ---
A patch was committed to trunk r131352.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34263
--- Comment #23 from gdr at cs dot tamu dot edu 2008-01-06 15:28 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
complex type conversion
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Subject: Re: [4.2/4.3 regression] ICE with incompatible
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-06 15:57 ---
I see. So basically we need to split all floating point operators into two
variants, one specifying a default rounding mode is used and one specifying the
rounding mode is unknown. I suppose the frontend parts
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-06 16:20 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00200.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from joseph at codesourcery dot com 2008-01-06 16:28 ---
Subject: Re: Optimization generates incorrect code
with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
On Sun, 6 Jan 2008, rguenth at gcc dot gnu dot org wrote:
I see. So basically we need
--- Comment #7 from asteinarson at gmail dot com 2008-01-06 17:02 ---
(In reply to comment #2)
Created an attachment (id=14728)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14728action=view) [edit]
proposed fix
I'm seeing similar behavior on x86-64 with both g++-4.1.3
--- Comment #2 from XuHotdogs at gmail dot com 2008-01-06 17:18 ---
(In reply to comment #1)
This is a target specific issue.
Yet in MinGW's release 3.4.5, the problem got solved. I don't know why this
happened again in GCC's official release 4.2.*.
Are there anyone having the same
I got a bug while I was trying to compile an emulator i got this error msg:
gpp.exe internal error: (null) (program as)
I use this line to compile: gpp -g GBA.gpp -o gba.exe
--
Summary: my gcc wont compile
Product: gcc
Version: 4.2.2
Status:
--- Comment #1 from jokehell2 at hotmail dot com 2008-01-06 18:02 ---
Created an attachment (id=14886)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14886action=view)
one of the files got by the line suggested by bug reportin instructions
--
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-06 18:08 ---
Subject: Bug 34655
Author: burnus
Date: Sun Jan 6 18:07:52 2008
New Revision: 131353
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131353
Log:
2008-01-06 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-06 18:13 ---
FIXED on the trunk (4.3.0).
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00202.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-06 18:17 ---
FIXED on the trunk (4.3.0).
Thanks for the bug report!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-06 18:17 ---
Subject: Bug 34658
Author: burnus
Date: Sun Jan 6 18:17:14 2008
New Revision: 131355
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131355
Log:
2007-01-06 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2008-01-06 18:19
---
Subject: Bug 34387
Author: jvdelisle
Date: Sun Jan 6 18:19:06 2008
New Revision: 131356
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131356
Log:
2008-01-06 Jerry DeLisle [EMAIL PROTECTED]
PR
[ Forwarded from http://bugs.debian.org/459429 ]
With 4.1 and 4.2 we get the following ICE on m68k with -O2. This doesn't
happen with 4.3.
(etch)3889:[EMAIL PROTECTED]: ..-m68k-20080106-r131352/gcc] ./xgcc -B. -c -O2
~/erlexec.preprocessed.4.2.c
./erlexec.c: In function รข
--- Comment #1 from tbm at cyrius dot com 2008-01-06 18:23 ---
Created an attachment (id=14887)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14887action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34688
On Linux/Intel64, revision 131352 has
FAIL: libgomp.fortran/appendix-a/a.33.3.f90 -O (test for excess errors)
FAIL: libgomp.fortran/appendix-a/a.38.1.f90 -O (test for excess errors)
FAIL: libgomp.fortran/appendix-a/a.33.3.f90 -O (test for excess errors)
FAIL:
On Linux/Intel64, I got
FAIL: gfortran.dg/elemental_args_check_2.f90 -O (test for errors, line 14)
FAIL: gfortran.dg/elemental_args_check_2.f90 -O (test for excess errors)
with revision 131352.
--
Summary: gfortran.dg/elemental_args_check_2.f90 doesn't work
Product:
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2008-01-06 18:35
---
Subject: Bug 34540
Author: jvdelisle
Date: Sun Jan 6 18:34:14 2008
New Revision: 131357
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131357
Log:
2008-01-06 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-06 18:37 ---
gpp.exe internal error: (null) (program as)
as is crashing and as is part of the binutils project.
Can you give the output of compiling and add -v ?
--
pinskia at gcc dot gnu dot org changed:
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2008-01-06 18:40
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2008-01-06 18:40
---
Fixed with patch to 34387.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from burnus at gcc dot gnu dot org 2008-01-06 18:48 ---
Patch: http://gcc.gnu.org/ml/fortran/2008-01/msg00017.html
Paul, what is with your patch (see above)? (I OKed it a few days ago.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-01-06 18:57 ---
I can't remember any recent OMP-related changes in gfortran?!
Moving to component libgomp, adding Jakub as CC.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-06 19:04 ---
Mine. Try gfortran on the test case and you see why it is mine - it has nothing
to do with OpenMP.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-01-06 19:24
---
This is a regression. I thought in the back of my mind that I had this working
right before. Sure enough, 4.2 gives a warning.
gfc42 -static pr34659.f90
Warning: '' not allowed by itself in line 1
--
--- Comment #13 from mmitchel at gcc dot gnu dot org 2008-01-06 19:35
---
I'm not keen on silently changing dynamic_cast to static_cast. But, with
-fno-rtti, making dynamic_castvoid* and static casts work seems OK. Does
that not work now?
And, certainly, adding preprocessor macros
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-06 19:37 ---
Subject: Bug 34689
Author: burnus
Date: Sun Jan 6 19:36:44 2008
New Revision: 131359
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131359
Log:
2008-01-06 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-06 19:47 ---
FIXED on the trunk (4.3.0). Caused by the fix for PR34662.
Thanks for the report.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
The following code is ill-formed according to the standard, but accepted by
GCC:
namespace A {
extern C void f(int = 5);
}
namespace B {
extern C void f(int = 4);
}
using A::f;
using B::f;
int main() {
f(3);//OK
f(); //ERROR
}
When a default argument is used as
--- Comment #14 from pcarlini at suse dot de 2008-01-06 20:05 ---
(In reply to comment #13)
I'm not keen on silently changing dynamic_cast to static_cast. But, with
-fno-rtti, making dynamic_castvoid* and static casts work seems OK. Does
that not work now?
Yes, I checked, and that
--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-06 20:18 ---
Subject: Bug 34689
Author: burnus
Date: Sun Jan 6 20:18:01 2008
New Revision: 131360
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131360
Log:
2008-01-06 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #8 from jakub at gcc dot gnu dot org 2008-01-06 20:26 ---
Subject: Bug 34152
Author: jakub
Date: Sun Jan 6 20:25:57 2008
New Revision: 131361
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131361
Log:
PR c++/34152
* libsupc++/eh_personality.cc
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-06 20:30 ---
Subject: Bug 34690
Author: burnus
Date: Sun Jan 6 20:30:10 2008
New Revision: 131362
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131362
Log:
2008-01-06 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-06 20:31 ---
FIXED my stupid mistake on the trunk (4.3.0) by changing the test case.
Introduced test case as fix for PR34660.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from paulthomas2 at wanadoo dot fr 2008-01-06 20:39 ---
Subject: Re: ICE when compiling Fortran 95 code
Tobias,
Nothing - I have just updated to FC8 and blew all my nice set-up to
pieces. This is the first time that Fedora has let me down. I will be
operational
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-06 20:54 ---
2.95.4 says
t.C:9: `B::f(int)' conflicts with used function
t.C:2: `void A::f(int = 5)' previously declared here
t.C:9: default argument given for parameter 1 of `void B::f(int = 4)'
t.C:2: after previous
--- Comment #24 from mark at codesourcery dot com 2008-01-06 21:06 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with complex type conversion
gdr at cs dot tamu dot edu wrote:
| I'm not sure what you mean by that. It's a public constructor;
I mean
--- Comment #3 from danglin at gcc dot gnu dot org 2008-01-06 21:35 ---
This bug is present on 4.2 branch but head doesn't fail for me. The problem
is a deleted label.
Breakpoint 1, output_operand (x=0x4be5a208, code=0)
at ../../gcc/gcc/final.c:3171
3171 gcc_assert (!x ||
The following testcase triggers an internal error in the preprocessor
since GCC 4.2.0:
#define FOO(expr) (#expr)
FOO(
#pragma GCC diagnostic
)
bug.c:5:1: internal error: unspellable token PRAGMA
bug.c:5:1: internal error:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||34602
Keywords|
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-01-06 21:44 ---
Created an attachment (id=14888)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14888action=view)
partial implementation
This is an implementation for the array intrinsics, but I'm having
trouble with writing
On Linux/Intel64, revision 131362 gives
FAIL: gfortran.dg/common_6.f90 -O (internal compiler error)
FAIL: gfortran.dg/common_6.f90 -O (test for excess errors)
Revision 131352 is OK.
--
Summary: [4.3 Regression] gfortran.dg/common_6.f90 -O
Product: gcc
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-01-06 21:46 ---
Created an attachment (id=14889)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14889action=view)
Test case that doesn't work
This test case fails with my patch, although the dg-shouldfail directive
should take
--- Comment #1 from hjl at lucon dot org 2008-01-06 21:47 ---
It may be introduced by the fix for bug 34658.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-06 21:50 ---
To my understanding the problem existed before though it did not crash as often
as it does now. Before it failed here only with -m64 now also with -m32, but I
believe it is the same problem and thus unrelated to the
--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-06 21:50 ---
*** Bug 34693 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl at lucon dot org 2008-01-06 21:54 ---
Why didn't I see it with revision 131352?
--
hjl at lucon dot org changed:
What|Removed |Added
The warning for the following testcase contains a wrong line number
on mainline (compile with -fopenmp -O -Wall):
int i;
void foo()
{
#pragma omp parallel
{
int j;
i = j;
}
}
bug.c: In function 'foo.omp_fn.0':
--
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=34694
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-06
21:59 ---
Subject: Re: ICE: output_operand: invalid expression as
operand on hppa
This bug is present on 4.2 branch but head doesn't fail for me. The problem
is a deleted label.
The label is deleted in
--- Comment #17 from pault at gcc dot gnu dot org 2008-01-06 22:00 ---
Subject: Bug 34545
Author: pault
Date: Sun Jan 6 22:00:00 2008
New Revision: 131364
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131364
Log:
2008-01-06 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #16 from jaydub66 at gmail dot com 2008-01-06 22:08 ---
I've done some experimenting with older GCC versions I have floating around on
my machines:
Compiling the test case with both 4.1.2 and 4.2.1 gives an ICE, so I guess we
can't exactly call this a regression.
But then
--- Comment #17 from rguenther at suse dot de 2008-01-06 22:12 ---
Subject: Re: Fortran FE generated IL pessimizes middle-end
IL and analysis
On Sun, 6 Jan 2008, jaydub66 at gmail dot com wrote:
--- Comment #16 from jaydub66 at gmail dot com 2008-01-06 22:08 ---
I've done
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||33870
Component|fortran |middle-end
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-06 22:14 ---
I think this was introduced with the pragma changes from the openmp branch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
When -Werror is passed in, libcpp silently converts warnings to errors:
$ gcc foo.c -Wall -Werror
foo.c:3:1: error: FOO redefined
foo.c:2:1: error: this is the location of the previous definition
This is potentially confusing, and inconsistent with cc, which displays:
$ gcc foo.c -Wall -Werror
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-06 22:23 ---
I don't know. When I investigated PR 33375, I found that that the symbol
existed but was uninitialized. I do not understand why it started to fail with
x86-64 but valgrind showed it used also before uninitialized
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-06 22:23 ---
*** Bug 34693 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33375
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-01-06 22:30
---
Confirmed. Here's a further reduced testcase that triggers the warning
already with -O -Wall:
struct A {};
struct B : A
{
double x, y;
B() : x(), y() {}
};
inline B getB()
--- Comment #15 from paolo at gcc dot gnu dot org 2008-01-06 22:31 ---
Subject: Bug 34680
Author: paolo
Date: Sun Jan 6 22:30:32 2008
New Revision: 131366
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131366
Log:
gcc/
2008-01-06 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #1 from ed at catmur dot co dot uk 2008-01-06 22:35 ---
Created an attachment (id=14892)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14892action=view)
gcc-cpp-Werror-message.patch
Proposed patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34695
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-06 22:40 ---
See http://gcc.gnu.org/ml/fortran/2008-01/msg00067.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34669
Given the following test program:
#include sstream
#include iostream
class X : private std::ostringstream {
public:
templatetypename a X operator(a arg)
{
#if 0
std::ostringstream o= *this;
o arg;
#else
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-01-06 23:11
---
This trivial patch fixes this:
Index: scanner.c
===
--- scanner.c (revision 131355)
+++ scanner.c (working copy)
@@ -1176,7 +1176,7 @@
--- Comment #9 from asteinarson at gmail dot com 2008-01-06 23:18 ---
(In reply to comment #8)
Subject: Bug 34152
Author: jakub
Date: Sun Jan 6 20:25:57 2008
New Revision: 131361
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131361
Log:
PR c++/34152
*
Here's the source code:
extern inline void f() {}
int main () {}
Compile with
gcc -c -std=gnu99 filename.c
Use nm filename.o to see that a global symbol f has been declared, but it
shouldn't be.
This prevents libgmp from being usable under Mac OS 10.5.
% uname -a
Darwin
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-06 23:25 ---
Well extern inline for 4.3.0 and before in C99 mode was the GNU 89 extern
inline and not the C99 extern inline. This was fixed for 4.3.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from danglin at gcc dot gnu dot org 2008-01-06 23:27 ---
Breakpoint 1, delete_insn (insn=0x4be5a208) at ../../gcc/gcc/cfgrtl.c:111
111 if (LABEL_P (insn))
(gdb) bt
#0 delete_insn (insn=0x4be5a208) at ../../gcc/gcc/cfgrtl.c:111
#1 0x001a8f30 in delete_related_insns
1 - 100 of 122 matches
Mail list logo
