--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-12 07:00 ---
I'm not convinced that external (without pointer attribute) objects are allowed
in the shared etc. clause lists. The OpenMP 3.0 standard says that a list item
is a variable name or common block name. And the definiti
--- Comment #1 from fierevere at mail dot ru 2010-05-12 07:01 ---
Created an attachment (id=20640)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20640&action=view)
this file triggers ICE in cc1plus
i have exactly the same, affects 4.5.0 release and current gcc-4_5-branch
../${SRC
--- Comment #2 from fierevere at mail dot ru 2010-05-12 07:05 ---
Please change:
component to bootstrap
Host/Target and Build to i686-pc-linux-gnu
set higher priority and severity, this problem makes profiledbootstrap make
target unable to build and FDO-built GCC unusable, its definitel
GCC generates an invalid stack frame usage sequence in a function epilogue.
Function prologue with comments:
.align 2
.global rtems_bdbuf_read
.code 16
.thumb_func
.type rtems_bdbuf_read, %function
rtems_bdbuf_read:
push{r4, r5, r6, r7, lr}
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2010-05-12 07:21 ---
Created an attachment (id=20641)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20641&action=view)
Log.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2010-05-12 07:21 ---
Created an attachment (id=20642)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20642&action=view)
Preprocessed source file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #3 from sebastian dot huber at embedded-brains dot de
2010-05-12 07:22 ---
Created an attachment (id=20643)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20643&action=view)
Generated assembler file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #4 from burnus at gcc dot gnu dot org 2010-05-12 07:52 ---
For information:
Pathscale 3.2.99 and 3.9.99 and Portland pgf90 10.1-0 compile it without
showing an error/warning.
Using the Intel Fortran Compiler 11.1 (20090630), one gets:
test.f90(10): error #6429: This name
--- Comment #5 from burnus at gcc dot gnu dot org 2010-05-12 08:13 ---
(In reply to comment #4)
> Using the Intel Fortran Compiler 11.1 (20090630), one gets:
> test.f90(10): error #7655: A variable is required in this OpenMP context.
Ditto for procedure pointers.
> Sun Studio 12 an
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-12 08:29 ---
Created an attachment (id=20644)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20644&action=view)
gcc46-pr44036.patch
Only very lightly tested patch.
1) allows dummy procedures and procedure pointers, disallows
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
If I compile a short Programm with g++ and I declare a STL-String (only
declare!), than it is ok ("g++ -c -Wall Progname.c").
But if I link the same programm with "g++ -o Progname Progname.o", than I get
an linker error:
ld: 0711-317 ERROR: Undefined symbol: .std::basic_string, std::allocator >::b
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-05-12 09:20 ---
I believe this was temporary issue fixed by subsequent commit. Will double
check.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44087
--- Comment #8 from pmoulder at mail dot csse dot monash dot edu dot au
2010-05-12 09:25 ---
OK, on careful reading, I agree re memcpy etc. (see below).
Consequently, I amend my suggested change to the documentation to:
- Add a sentence about implicit `this' argument (copied & paste
--- Comment #1 from paolo dot carlini at oracle dot com 2010-05-12 09:31
---
Something seems seriously broken in your setup, of course in a proper one this
kind of problem would have blocked the release. Let's CC David...
--
paolo dot carlini at oracle dot com changed:
W
--- Comment #4 from sebastian dot huber at embedded-brains dot de
2010-05-12 09:40 ---
GCC 4.5.0 20100414 has this problem too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #18 from ubizjak at gmail dot com 2010-05-12 09:46 ---
FYI, the same failure happens on x86_64-pc-linux-gnu, but is silent for some
reason:
gmake[4]: Entering directory
`/home/uros/gcc-build/x86_64-unknown-linux-gnu/boehm-gc'
Switched to incremental mode
Emulating dirty bits
I recently tried to bootstrap the GCC 4.4.2 release on Solaris 9/x86 with Sun
as
and ld. The bootstrap failed linking libgomp.so:
libtool: link: /vol/obj/gnu/gcc/gcc-4.4.2/9-gcc/./gcc/xgcc
-B/vol/obj/gnu/gcc/gcc-4.4.2/9-gcc/./gcc/
-B/vol/gcc-4.4/i386-pc-solaris2.9/bin/ -B/vol/gcc-4.4/i386-pc-sola
--- Comment #2 from ro at gcc dot gnu dot org 2010-05-12 10:02 ---
Mine. patch in progress.
Using something like TARGET_SOLARIS is wrong: this is just a bug in older Sun
as
versions; a feature test macro to enable this will be autoconfigured.
--
ro at gcc dot gnu dot org changed:
--- Comment #5 from sebastian dot huber at embedded-brains dot de
2010-05-12 10:03 ---
GCC 4.2.4 does not have this problem.
Function epilogue:
.L672:
ldr r0, [r7, #4]
mov sp, r7
add sp, sp, #52
@ sp needed for prologue
pop {r4,
--- 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
--- 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 #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 #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 #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 #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
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 #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
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 #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
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 #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
--- 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
--
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 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?
--- 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
--
amodra at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at gmail dot com
|dot org |
--- 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
--- 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 #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 #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 #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 #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: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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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
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
--- 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 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 #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
--
--- 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 #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 #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 #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 #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 #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
---
--
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 #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
--- 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 #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 #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
// { 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 #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
--- 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 #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 #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 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 #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 #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
1 - 100 of 120 matches
Mail list logo
