The symptoms are that for some inputs, my C++ program gets stuck after a
`throw' and before the corresponding `catch', with CPU running. With an
appropriate DYLD_LIBRARY_PATH, the problem disappears.
The problem comes IMHO from libgcc/config/t-slibgcc-darwin (lines 29-35) where
libgcc_s.10.5.dylib
--- Comment #17 from jason at gcc dot gnu dot org 2010-05-13 05:25 ---
Fixed for 4.5.1.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #16 from jason at gcc dot gnu dot org 2010-05-13 05:23 ---
Subject: Bug 43787
Author: jason
Date: Thu May 13 05:23:14 2010
New Revision: 159352
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159352
Log:
PR c++/43787
gcc:
* gimplify.c (gimplify_expr):
--- Comment #3 from jason at gcc dot gnu dot org 2010-05-13 05:18 ---
Fixed for 4.6.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #5 from jason at gcc dot gnu dot org 2010-05-13 05:17 ---
Should be fixed now.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from jason at gcc dot gnu dot org 2010-05-13 05:05 ---
Subject: Bug 44048
Author: jason
Date: Thu May 13 05:04:46 2010
New Revision: 159350
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159350
Log:
PR bootstrap/44048
PR target/44099
gcc/cp:
--- Comment #5 from jason at gcc dot gnu dot org 2010-05-13 05:05 ---
Subject: Bug 44099
Author: jason
Date: Thu May 13 05:04:46 2010
New Revision: 159350
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159350
Log:
PR bootstrap/44048
PR target/44099
gcc/cp:
int f(int i)
{
if (i == undefined_var) {
return 1;
}
else {
return 0;
}
}
/usr/local/gcc-svn/bin/g++ -Wall -Wextra -c bad-return.cpp
bad-return.cpp: In function int f(int):
bad-return.cpp:3:13: error: undefined_var was not declared in this scope
bad-return.cpp:9:1: warn
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-13 04:14 ---
FAIL: objc.dg/torture/tls/thr-init-3.m -O2 -flto (test for excess errors)
FAIL: objc.dg/torture/tls/thr-init-3.m -O2 -fwhopr (test for excess errors)
are new tests. The rest may be caused by revision 159321:
ht
--- Comment #1 from kargl at gcc dot gnu dot org 2010-05-13 01:53 ---
(In reply to comment #0)
>
> $ /root/gcc-4.4.4/libgfortran/configure --cache-file=./config.cache
> --enable-multilib --with-gmp=/usr/local --with-fpmr=/usr/local
Should that be --with-mpfr?
> configure:14173: ch
make of gcc suite halts with the following message:
configure: error: GNU Fortran is not working; please report a bug in
http://gcc.gnu.org/bugzilla, attaching
/root/gcc-4.4.4/i686-pc-linux-gnu/libgfortran/config.log
make[1]: *** [configure-target-libgfortran] Error 1
make[1]: Leaving directory `/
--- Comment #24 from ubizjak at gmail dot com 2010-05-12 22:51 ---
(In reply to comment #23)
> Well I can't approve it but I think it's as close to "obvious" as anything
> gets. If you send it to libjava-patches (and cc the upstream list for
> boehm-gc: - we're trying to avoid any div
On Linux/ia32, revision 159321 gace
FAIL: gcc.dg/guality/example.c -O2 -flto (internal compiler error)
FAIL: gcc.dg/guality/example.c -O2 -flto (test for excess errors)
FAIL: gcc.dg/guality/example.c -O2 -fwhopr (internal compiler error)
FAIL: gcc.dg/guality/example.c -O2 -fwhopr (test for
On Linux/ia32, revision 159328 gave
AIL:
/export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libjava/testsuite/TestEarlyGC.exe
execution -
/export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libjava/testsuite/TestEarlyGC.exe
FAIL:
/export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libjava/t
--- Comment #26 from dougmencken at gmail dot com 2010-05-12 22:29 ---
Some results:
October 15, 2009
GCC 4.4.2 has been released.
January 21, 2010
GCC 4.4.3 has been released.
initially bad: 1a47c687053db495606b79a42ddefd0671ce3b15 (2010-01-21)
initially good: e5f3e814b3056564
--- Comment #23 from davek at gcc dot gnu dot org 2010-05-12 22:20 ---
(In reply to comment #22)
> Hm, I'm not able to run thread_test.c and thread_leak_test.c tests using "make
> -k check", so otherwise deadly trivial patch can't be fully tested.
>
Well I can't approve it but I think
--- Comment #6 from langton at gcc dot gnu dot org 2010-05-12 22:14 ---
Created an attachment (id=20653)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20653&action=view)
decl.c patch
Trying again: this patch fixes the bug in the testcase and passes regression
testing.
--
langt
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-05-12 21:36
---
Looking into it.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot
|dot org
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-05-12 21:34
---
Looking into it.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #17 from pinskia at gcc dot gnu dot org 2010-05-12 20:54
---
Not a bug, you need to configure libstdc++ and stlport the same if you want
them to work together.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from pluto at agmk dot net 2010-05-12 20:27 ---
(In reply to comment #15)
> the problematic is eh_globals.o which was merged into libstlport.a.
> the TLS version of the get_globals causes memory corruption in my app.
>
strictly, the __thread based eh_globals.cc doesn't
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-12 20:16 ---
So, the issue is that the loop copying vals to m looks like
:
D.21310_23 = r_22 * 4;
D.21309_25 = D.21310_23 + c_24;
D.21308_26 = (long unsigned int) D.21309_25;
D.21305_29 = vals[0][D.21308_26];
m.m[D.213
--- Comment #8 from froydnj at gcc dot gnu dot org 2010-05-12 19:52 ---
r114536 has been committed as r159340.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43977
--- Comment #5 from langton at gcc dot gnu dot org 2010-05-12 19:37 ---
The patch I posted isn't correct. It causes a regression in
gfortran.dg/cray_pointers_2.f90.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37039
--- Comment #4 from jason at gcc dot gnu dot org 2010-05-12 19:20 ---
I marked it as a dupe because it has the same cause, though different specific
effects.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from mikpe at it dot uu dot se 2010-05-12 19:15 ---
I get the same errors with nullptr01.C on sparc64-unknown-linux-gnu. My build
has c++ as an enabled language, and most other c++ and libstdc++ tests work, so
I don't think this is a dupe of PR44048.
--
mikpe at it dot
// { dg-do compile }
// { dg-options "-O2" }
void baz (void);
struct A { A (); ~A (); };
static inline int
foo (void)
{
asm goto ("" : : : : l1, l2);
__builtin_unreachable ();
l1:
return 1;
l2:
return 0;
}
int
bar (int x)
{
if (x == 5)
{
A a, b;
baz ();
}
if (fo
--- Comment #22 from ubizjak at gmail dot com 2010-05-12 17:50 ---
Hm, I'm not able to run thread_test.c and thread_leak_test.c tests using "make
-k check", so otherwise deadly trivial patch can't be fully tested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811
--- Comment #21 from ubizjak at gmail dot com 2010-05-12 17:46 ---
Created an attachment (id=20652)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20652&action=view)
GC testsuite fixes
Patch that declares "int main" and adds "return 0;" to the tests.
--
http://gcc.gnu.org/bugz
--- Comment #20 from ubizjak at gmail dot com 2010-05-12 17:39 ---
(In reply to comment #19)
> As indeed it does in the other case as well, which now makes me suspect that
> the alpha FAIL is probably a false negative. The test code is rather old,
> declares main as an implict int func
--- Comment #2 from jason at gcc dot gnu dot org 2010-05-12 17:35 ---
Subject: Bug 20669
Author: jason
Date: Wed May 12 17:34:55 2010
New Revision: 159335
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159335
Log:
PR c++/20669
* call.c (add_template_candidate_rea
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #3 from jason at gcc dot gnu dot org 2010-05-12 17:29 ---
*** Bug 44099 has been marked as a duplicate of this bug. ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from jason at gcc dot gnu dot org 2010-05-12 17:29 ---
Yeah, another aspect of the same issue as 44048.
*** This bug has been marked as a duplicate of 44048 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-05-12 17:28
---
Isn't that again a C++ tree code that leaks into the back-end?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44099
--- Comment #1 from ro at gcc dot gnu dot org 2010-05-12 17:22 ---
Could you please provide some more details, please: what system are you running
on, what version of libelf is in use?
And please provide config.log and configure output from the toplevel and from
the gcc subdirectory, to
--- Comment #4 from langton at gcc dot gnu dot org 2010-05-12 16:51 ---
Created an attachment (id=20651)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20651&action=view)
Possible fix (minimal testing)
Removing cp_as entirely seems to work. I'll have to test this some more.
--
--- Comment #19 from davek at gcc dot gnu dot org 2010-05-12 16:48 ---
(In reply to comment #18)
> FYI, the same failure happens on x86_64-pc-linux-gnu, but is silent for some
> reason:
> Leaked composite object at 0x2b5d6f749ef0
> (../../../gcc-svn/trunk/boehm-gc/tests/leak_test.c:16,
--- Comment #9 from mikpe at it dot uu dot se 2010-05-12 16:34 ---
Confirmed with cross to armv5tel-unknown-linux-gnueabi. 4.3/4.4/4.5/4.6 all
generate the signal-unsafe epilogue.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
--
Between there appeared two new testsuite failures on Tru64 UNIX V5.1B:
FAIL: 25_algorithms/fill/4.cc (test for excess errors)
WARNING: 25_algorithms/fill/4.cc compilation failed to produce executable
Excess errors:
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/25_algorithms/fill/4.cc:27:1:
e
--- Comment #1 from ro at gcc dot gnu dot org 2010-05-12 16:23 ---
Created an attachment (id=20650)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20650&action=view)
preprocessed source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44100
Between 20100422 and 20100507 there appeared a testsuite regression on Tru64
UNIX
V5.1B:
FAIL: g++.dg/init/struct2.C (internal compiler error)
FAIL: g++.dg/init/struct2.C (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/init/struct2.C:20:5: internal
compile
The new g++.dg/debug/nullptr01.C test currently fails on Solaris 10/11 SPARC:
FAIL: g++.dg/debug/nullptr01.C -gdwarf-2 -g1 (internal compiler error)
FAIL: g++.dg/debug/nullptr01.C -gdwarf-2 -g1 (test for excess errors)
ERROR: g++.dg/debug/nullptr01.C: error executing dg-final: couldn't open "nullp
--- Comment #3 from langton at gcc dot gnu dot org 2010-05-12 15:57 ---
I don't think this is a dupe of either of those bugs. In this case, the
dimension attribute isn't properly applied to 'tab' on line 5. The problem
appears to be in variable_decl() (decl.c), where I kept an extra gf
--- Comment #7 from froydnj at gcc dot gnu dot org 2010-05-12 15:56 ---
r114547 and 114548 have been committed as r159328.
r115342 has been committed as part of the CALL_EXPR changes that *did* make it
in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43977
--- Comment #7 from ro at gcc dot gnu dot org 2010-05-12 15:54 ---
Also on i386-pc-solaris2.1[01] and sparc-sun-solaris2.1[01].
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from ro at gcc dot gnu dot org 2010-05-12 15:48 ---
Also happens on i386-pc-solaris2.1[01] and sparc-sun-solaris2.1[01].
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from froydnj at gcc dot gnu dot org 2010-05-12 15:35 ---
r114291, r114400, and r114401 have been committed as r159326.
--
froydnj at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from paolo dot carlini at oracle dot com 2010-05-12 15:29
---
*** This bug has been marked as a duplicate of 21920 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #151 from paolo dot carlini at oracle dot com 2010-05-12 15:29
---
*** Bug 44098 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #10 from jakub at gcc dot gnu dot org 2010-05-12 15:27 ---
Created an attachment (id=20649)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20649&action=view)
locus follow-up
Follow-up patch to fix up the locus.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44036
--- Comment #9 from jakub at gcc dot gnu dot org 2010-05-12 15:25 ---
Created an attachment (id=20648)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20648&action=view)
gcc46-pr44036.patch
Updated patch which implements that. I've split off the locus changes to a
separate follow-u
--- Comment #7 from paolo dot carlini at oracle dot com 2010-05-12 15:25
---
You are violating the aliasing rules, anything can happen, at any optimization
level...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44098
--- Comment #6 from maister at archlinux dot us 2010-05-12 15:23 ---
That worked (-O3 -fno-strict-aliasing). But why does this work on -O2 and not
-O3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44098
--- Comment #5 from paolo dot carlini at oracle dot com 2010-05-12 15:07
---
and then try -O3 -fno-strict-aliasing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44098
--- Comment #4 from paolo dot carlini at oracle dot com 2010-05-12 15:04
---
First blush, I can see some pretty serious aliasing violations... try -Wall
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #8 from jakub at gcc dot gnu dot org 2010-05-12 15:01 ---
Seems dummy procedures are already in F95 and therefore something that OpenMP
3.0 should take into account. So probably for them it would be better to
keep rejecting them in the clause lists and ensure they aren't rej
--- Comment #3 from maister at archlinux dot us 2010-05-12 15:01 ---
Created an attachment (id=20647)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20647&action=view)
ASM output with -O3
Assembly output with -O3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44098
--- Comment #2 from maister at archlinux dot us 2010-05-12 15:00 ---
Created an attachment (id=20646)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20646&action=view)
ASM output with -O2
Assembly output using gcc -S -O2 invsqrt.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from maister at archlinux dot us 2010-05-12 14:56 ---
Created an attachment (id=20645)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20645&action=view)
The test case.
Actually, it's quite absurd, but trying to print out from 1 to 10 rather than 1
to 100 seemed to wo
I have tested the famous quickInvSqrt() algorithm uses in Quake, and it does
not compile correctly when compiling with -O3. It does however work completely
fine when compiling for -O0, -O1 and -O2.
The function goes like so:
float quickInvSqrt(float x)
{
float xhalf = 0.5f*x;
int i = *(int*
--- Comment #5 from jakub at gcc dot gnu dot org 2010-05-12 14:39 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #7 from longb at cray dot com 2010-05-12 14:34 ---
For what it's worth, the Cray compiler produces this message for the test code:
!$OMP shared (a,n,f)
^
ftn-1473 crayftn: ERROR DP, File = test.f90, Line = 13, Column = 19
Object F must be a variable to
--- Comment #3 from redi at gcc dot gnu dot org 2010-05-12 14:16 ---
2.12 Keywords [lex.key]
1 The identifiers shown in Table 3 are reserved for use as keywords (that
is, they are unconditionally treated as keywords in phase 7) except in an
attribute-token (7.6.1) [ Note: The export keywo
--- Comment #2 from redi at gcc dot gnu dot org 2010-05-12 14:15 ---
export is still going to be a keyword in C++1x, even though the feature has
been removed, so it should still be recognised as a keyword by GCC.
--
redi at gcc dot gnu dot org changed:
What|Removed
--- Comment #15 from pluto at agmk dot net 2010-05-12 13:57 ---
the problematic is eh_globals.o which was merged into libstlport.a.
the TLS version of the get_globals causes memory corruption in my app.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
--- Comment #1 from paolo dot carlini at oracle dot com 2010-05-12 13:57
---
Well, one thing is *reserving* a keyword, another implementing a semantics.
About the next Standard, yes it could make sense to drop it from the set of
keywords, but I don't think we should rush to do that, cer
Try to define a simple function:
void export() {
// whatever
}
This will not compile, because 'export' is considered a keyword. After googling
a bit for this keyword, I found that there has been a long debate already
regarding this keyword. But everywhere I look it is claimed that the only
com
--- Comment #77 from jcea at hispasec dot com 2010-05-12 13:14 ---
Discussión in progress:
http://mail.python.org/pipermail/python-dev/2010-May/100044.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
--- Comment #76 from jcea at hispasec dot com 2010-05-12 13:00 ---
[Zlib-devel] HEADS UP: Apparent bad compilation under (just released) GCC 4.5.0
http://mail.madler.net/pipermail/zlib-devel_madler.net/2010-May/002267.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
--- Comment #2 from hjl at gcc dot gnu dot org 2010-05-12 12:48 ---
Subject: Bug 44088
Author: hjl
Date: Wed May 12 12:48:02 2010
New Revision: 159319
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159319
Log:
Support AVX for cmpss/cmpsd.
gcc/
2010-05-12 H.J. Lu
PR
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-12 12:43 ---
With current trunk (r159282), we have a locus - but not the right one:
pr41922.f:11.72:
end
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-12 12:30 ---
Subject: Bug 44085
Author: jakub
Date: Wed May 12 12:30:21 2010
New Revision: 159318
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159318
Log:
PR middle-end/44085
* gimplify.c (enum omp_region
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-12 12:26 ---
*** Bug 41218 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33015
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-12 12:26 ---
*** This bug has been marked as a duplicate of 33015 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-12 12:19 ---
Subject: Bug 44085
Author: jakub
Date: Wed May 12 12:18:55 2010
New Revision: 159317
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159317
Log:
PR middle-end/44085
* gimplify.c (enum omp_region
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-12 12:11 ---
Subject: Bug 44085
Author: jakub
Date: Wed May 12 12:11:00 2010
New Revision: 159316
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159316
Log:
PR middle-end/44085
* gimplify.c (enum omp_region
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-12 12:09 ---
Subject: Bug 42278
Author: jakub
Date: Wed May 12 12:08:34 2010
New Revision: 159315
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159315
Log:
PR debug/42278
* dwarf2out.c (base_type_die): Don
--- Comment #8 from sebastian dot huber at embedded-brains dot de
2010-05-12 12:03 ---
A summary follows. Broken means bdbuf.i generates an invalid stack frame usage
sequence in a function epilogue. Works means that the corresponding area is
valid.
Flags: -march=armv5t -mthumb -Os
--- Comment #5 from jay dot krell at cornell dot edu 2010-05-12 12:02
---
Rainer, sorry, I meant cross build a native gcc.
build=whatever
host=target=solaris
Not cross compiling with gcc itself (other than to build gcc).
Old versions accept a certain syntax.
New versions accept a sup
--- Comment #10 from joseph at codesourcery dot com 2010-05-12 11:52
---
Subject: Re: Incorrect nonnull assumed in code generation
On Wed, 12 May 2010, pmoulder at mail dot csse dot monash dot edu dot au wrote:
> Coming back to memcpy etc.: As this is such an edge case, I'll give mor
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-05-12
11:50 ---
Subject: Re: Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on
same line
> --- Comment #3 from jay dot krell at cornell dot edu 2010-05-12 10:50
> ---
> > Using something like TARG
--
amodra at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at gmail dot com
|dot org |
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-12 11:37 ---
Indeed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #1 from redi at gcc dot gnu dot org 2010-05-12 11:36 ---
the case label must be an integer constant, this is not the same as a const
int.
the * operator is not allowed in an integer constant expression, so the code is
invalid
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44095
--- Comment #1 from knurt at geislersoftware dot de 2010-05-12 11:18
---
Correction:
For my workaround I used the cfns.h file from Release 4.4.2, as I did not have
this problem around the time 4.4.2 was released.
--
knurt at geislersoftware dot de changed:
What|Remo
--- Comment #7 from sebastian dot huber at embedded-brains dot de
2010-05-12 11:13 ---
GCC 4.3.2 20080827 has this problem too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
Problem when building stage 2:
cp/except.o: In function `nothrow_libfn_p':
except.c:(.text+0x126d): undefined reference to `libc_name_p'
collect2: ld gab 1 als Ende-Status zurück.
I found the same problem in this message:
http://gcc.gnu.org/ml/gcc-help/2009-10/msg00402.html
When I checked cfns
--- Comment #6 from sebastian dot huber at embedded-brains dot de
2010-05-12 11:06 ---
If you use GCC 4.5.0 20100414 with '-march=armv7' '-mthumb' '-Os' the function
epilogue is also correct. It seems that this is a Thumb 1 problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
Java is severely broken on sparc64-linux with gcc 4.5/4.6, which is a major
regression from 4.4:
http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00853.html (4.6 broken)
http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00681.html (4.5 broken)
http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00472.
--- Comment #9 from hv at crypt dot org 2010-05-12 10:54 ---
The direction of discussion has centred so far on the documentation, but as far
as I can tell the only point at which the documentation confused someone was
the triage at #3. Should there not be a separate bug opened for proble
switch(xxx)
{
case *(const int* const)"abc":
break;
}
does not get compiled. saying:
error: case label does not reduce to an integer constant
I think it is the bug.
--
Summary: case xxx statement does not recognize const int value
Product: gcc
Version: unknown
--- Comment #3 from jay dot krell at cornell dot edu 2010-05-12 10:50
---
> Using something like TARGET_SOLARIS is wrong: this is just a bug in older
Sun
I don't completely agree.
- I regularly do cross builds.
What will you do for that? Assume the old version? I think so. Since t
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-12 10:34 ---
And neither 4.0.0 nor 4.2.x are maintained anymore nor do you provide a
testcase to verify your failure.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from dfranke at gcc dot gnu dot org 2010-05-12 10:12
---
Fixed in 4.5 and trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dfranke at gcc dot gnu dot org 2010-05-12 10:12 ---
Subject: Bug 40728
Author: dfranke
Date: Wed May 12 10:11:50 2010
New Revision: 159306
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159306
Log:
gcc/fortran/:
2010-05-12 Daniel Franke
PR fortran
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-12 10:06 ---
See also: PR31560, PR37039.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-12 10:06 ---
Another possible dupe: PR29813.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37039
1 - 100 of 120 matches
Mail list logo
