--- Comment #1 from jakub at gcc dot gnu dot org 2010-01-04 08:02 ---
There is no such guarantee, the testcase contains data race.
It can increment a shared variable in multiple threads using non-atomic
instructions. One fix would be to use
!$omp atomic
s = s + n
instead of just
s
--- Comment #4 from dodji at gcc dot gnu dot org 2010-01-04 09:37 ---
Confirmed on 4.5. The ICE happens only with -O2, with checking enabled.
I think this should be flagged as P1.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from burnus at gcc dot gnu dot org 2010-01-04 09:44 ---
Mark as new as Jerry has confirmed it. Jerry, do you see whether this is a
regression? From comment 0: this worked in previous versions of gfortran
It would be useful to know in which version it still worked. Does
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-04 09:47
---
Let's CC Jason...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2010-01-04 09:55 ---
Confirmed. The initialization works - if in a procedure or program, but it
fails in the declaration part of a module.
The problem seems to be related to returning an array - one should not have
called
/* { dg-do compile } */
/* { dg-options -O3 -g -ffast-math } */
unsigned *d;
unsigned short e;
int f;
float h[3][4];
void
test (unsigned short *b)
{
int a, c, i;
float g[3];
unsigned j[32] = { 10, 0x63707274 };
for (i = 0; i (int) j[0]; i++)
{
j[i * 3 + 2] = d[0];
d[0]
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #14 from paolo dot carlini at oracle dot com 2010-01-04 10:30
---
For sure Jon the code is very, very clean, excellent.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
--- Comment #2 from ramana at gcc dot gnu dot org 2010-01-04 10:54 ---
Confirmed with trunk I get
longfunc:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mul r1, r2, r1
mla
--- Comment #6 from ramana at gcc dot gnu dot org 2010-01-04 11:09 ---
Fixed on trunk . This problem doesn't exist on 4.4 branch.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ramana at gcc dot gnu dot org 2010-01-04 11:26 ---
The default is set to be v5t rather than v4t because interworking is enabled by
default for v5t. In case you want a GNU/ Linux toolchain with v4t , you need
to make sure interworking is enabled and all shared
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #8 from ramana at gcc dot gnu dot org 2010-01-04 11:32 ---
Waiting for feedback on this one as per Comment #7.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2010-01-04 11:33 ---
(In reply to comment #1)
Confirmed. The initialization works - if in a procedure or program, but it
fails in the declaration part of a module.
Actually, it also fails there; it only succeeded because the (unused)
--- Comment #14 from developer at sandoe-acoustics dot co dot uk
2010-01-04 11:49 ---
(In reply to comment #13)
Is this bug now fixed?
AFAICT, yes - comment #9 is not the result of this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41605
--- Comment #10 from irar at gcc dot gnu dot org 2010-01-04 12:46 ---
Subject: Bug 41956
Author: irar
Date: Mon Jan 4 12:45:46 2010
New Revision: 155614
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155614
Log:
PR tree-optimization/41956
* tree-vect-analyze.c
--- Comment #11 from burnus at gcc dot gnu dot org 2010-01-04 13:12 ---
(In reply to comment #9)
On x86_64-apple-darwin10, the two new test cases are cause ICEs...
FAIL: gfortran.dg/graphite/pr42334-1.f -O (internal compiler error)
FAIL: gfortran.dg/graphite/pr42334-1.f -O (test
--- Comment #10 from rwild at gcc dot gnu dot org 2010-01-04 13:18 ---
This looks like http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00650.html.
To confirm, please throw away your build tree once, build, then proceed as
described in above mail (adjusting $target etc). Your build fails
[forwarded from http://bugs.debian.org/501560]
gfortran documentation lacks any kind of info about how to create a module
.mod file. It should be quite easy to indicate that the standard gcc option -c
when applied to the to-be-compiled file creates the .mod file along with the .o
file.
should -c
The following code compiles without error and lead to a seg fault at runtime:
template class U, class V
struct A;
template class V
struct Aint, V {
void f();
};
template struct Aint, int;
int main() {
Aint, int a;
a.f();
return 0;
}
Notice that there is no body defined for Aint,
hi i'm using gcc in i686-pc-cygwin and building djvulibre library for target
i686-pc-mingw32 version of gcc in two platform is from latest git reprository.
and i'm using following configuration for djvulibre
./configure --prefix=/usr/i686-pc-mingw32 CC='gcc -mno-cygwin' CXX='g++
-mno-cygwin
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-04 14:15 ---
Created an attachment (id=19460)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19460action=view)
gcc45-pr42508.patch
Fix, so far not bootstrapped/regtested. The cgraphunit.c hunk is only somewhat
related, is
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-04 14:16 ---
This sounds more like a cygwin problem, not a GCC one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42609
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-04 14:19 ---
Confirmed.
Starting with GCC 4.4 we emit:
.size main, .-main
.weak _ZN1AIiiE1fEv
.weak _ZN1AIiiE1fEv
.weak _ZN1AIiiE1fEv
.ident GCC: (Debian 4.4.2-8) 4.4.2
--- Comment #9 from jakub at gcc dot gnu dot org 2010-01-04 14:20 ---
BTW, DESTDIR is documented e.g. in automake.info quite well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42409
--- Comment #2 from hjl dot tools at gmail dot com 2010-01-04 14:22 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00141.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42602
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-04 14:22 ---
The testcase gfortran.dg/gomp/recursion1.f90 which was moved to
libgomp/testsuite/libgomp.fortran/recursion1.f90 now fails randomly,
see PR42602.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42517
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-01-04 14:26
---
Sure, but let's wait for possible problems with the patch to show up in 4.5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42577
--- Comment #3 from hjl at gcc dot gnu dot org 2010-01-04 14:28 ---
Subject: Bug 42602
Author: hjl
Date: Mon Jan 4 14:28:30 2010
New Revision: 155615
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155615
Log:
Make 's' atomic
2010-01-04 H.J. Lu hongjiu...@intel.com
PR
--- Comment #6 from aldyh at gcc dot gnu dot org 2010-01-04 14:29 ---
Increase your stack size.
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl at gcc dot gnu dot org 2010-01-04 14:42 ---
Subject: Bug 42581
Author: hjl
Date: Mon Jan 4 14:42:38 2010
New Revision: 155616
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155616
Log:
Turn on trace in collect2 if needed
2010-01-04 H.J. Lu
Split off from PR 41872.
The following program fails because of:
static struct .class.t.a a = {.$vptr=0B};
That is: Only $vptr and not also $data is initialized by NULL. Thus:
if (a.$data == 0B)
fails. The initialization is seemingly done in gfc_build_class_symbol, but I do
not see ad
seen on current branches and the trunk, at least on x86 and x86_64:
Matthias
$ cat x.C
#include stdio.h
#include stdlib.h
#include unistd.h
#include sys/types.h
#include sys/mman.h
#include sys/stat.h
#include fcntl.h
#include memory.h
#include string.h
#include limits.h
#include errno.h
--- Comment #1 from debian-gcc at lists dot debian dot org 2010-01-04
15:03 ---
Created an attachment (id=19461)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19461action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42611
--- Comment #6 from doko at gcc dot gnu dot org 2010-01-04 15:13 ---
Subject: Bug 40134
Author: doko
Date: Mon Jan 4 15:13:08 2010
New Revision: 155617
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155617
Log:
2010-01-04 Mikael Pettersson mi...@it.uu.se
PR
--- Comment #15 from doko at gcc dot gnu dot org 2010-01-04 15:13 ---
Subject: Bug 42503
Author: doko
Date: Mon Jan 4 15:13:08 2010
New Revision: 155617
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155617
Log:
2010-01-04 Mikael Pettersson mi...@it.uu.se
PR
--- Comment #1 from jakub at gcc dot gnu dot org 2010-01-04 15:13 ---
Created an attachment (id=19462)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19462action=view)
gcc45-pr42604.patch
Untested shot in the dark. Just skipping the debug stmts leads to checking
failure, resetting
--- Comment #12 from hjl at gcc dot gnu dot org 2010-01-04 15:14 ---
Subject: Bug 42542
Author: hjl
Date: Mon Jan 4 15:14:31 2010
New Revision: 155618
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155618
Log:
Don't convert GTU to GT for V4SI and V2DI
gcc/
2010-01-04 H.J. Lu
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-04 15:20 ---
Shorter testcase:
struct S { int a; char b[2147483647]; };
void
foo (void)
{
struct S s;
}
with -m32.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from davek at gcc dot gnu dot org 2010-01-04 15:42 ---
COMMON symbols don't cause members to be pulled in from library archives. You
can omit -L. -lex from the final link altogether and get the same result:
it's unused. So the reference from bug.o to _jindx2 doesn't
It seems post-increment addressing is not used as often as it could be,
resulting in sub-optimal code. Take this trivial test case:
char * func(char *p)
{
*p++=0;
*p++=0;
*p++=0;
return p;
}
On ARM, we end up with:
mov r2, #0 @ 6
mov r3, r0 @ 28
strb
--- Comment #6 from jakub at gcc dot gnu dot org 2010-01-04 16:03 ---
Subject: Bug 42442
Author: jakub
Date: Mon Jan 4 16:02:41 2010
New Revision: 155622
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155622
Log:
PR driver/42442
* gcc.c
--- Comment #13 from dominiq at lps dot ens dot fr 2010-01-04 16:05 ---
The test fails also on *-apple-darwin9, but not on x86_64-apple-darwin10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
--- Comment #3 from ubizjak at gmail dot com 2010-01-04 16:07 ---
(In reply to comment #2)
The inline-asm is totally incorrect here ...
Actually, the asm is correct, it is just a couple of volatiles that are
missing. Please see arch/x86/include/asm/bitops.h from linux-2.6 for correct
--- Comment #14 from kargl at gcc dot gnu dot org 2010-01-04 16:13 ---
(In reply to comment #12)
COMMON symbols don't cause members to be pulled in from library archives. You
can omit -L. -lex from the final link altogether and get the same result:
it's unused. So the reference
--- Comment #6 from burnus at gcc dot gnu dot org 2010-01-04 16:16 ---
Mark as fixed as:
- The issue of comment 0 is fixed
- PR42602 is fixed
- As -frecursion is already triggering it (cf. comment 4)
and as I do not see a need for a __THREAD version, cf. comment 3. If you see a
real
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Component|c
--- Comment #15 from davek at gcc dot gnu dot org 2010-01-04 16:36 ---
(In reply to comment #14)
(In reply to comment #12)
COMMON symbols don't cause members to be pulled in from library archives.
You
can omit -L. -lex from the final link altogether and get the same result:
--
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 #16 from kargl at gcc dot gnu dot org 2010-01-04 17:13 ---
(In reply to comment #15)
(In reply to comment #14)
(In reply to comment #12)
COMMON symbols don't cause members to be pulled in from library archives.
You
can omit -L. -lex from the final link
--- Comment #15 from rwild at gcc dot gnu dot org 2010-01-04 17:15 ---
Created an attachment (id=19463)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19463action=view)
proposed patch
(In reply to comment #14)
Is this still an issue?
I have not tried to reproduce it, but I
--- Comment #4 from hjl dot tools at gmail dot com 2010-01-04 17:34 ---
I am marking this one fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-save-temps doesn't work completely for -fwhopr (and you
need to set the collect2 env vars for -fwhopr).
--
Summary: -save-temps doesn't work completely for -fwhopr
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
--- Comment #1 from hjl dot tools at gmail dot com 2010-01-04 17:38 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00158.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from debian-gcc at lists dot debian dot org 2010-01-04
17:42 ---
rechecked with 20090104. setting BOOT_CFLAGS to -g -O1 lets the gcc bootstrap
pass.
Matthias
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
--- Comment #2 from jason at gcc dot gnu dot org 2010-01-04 17:53 ---
Subject: Bug 42567
Author: jason
Date: Mon Jan 4 17:53:29 2010
New Revision: 155627
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155627
Log:
PR c++/42567
* semantics.c (describable_type):
--- Comment #6 from jason at gcc dot gnu dot org 2010-01-04 17:53 ---
Subject: Bug 42555
Author: jason
Date: Mon Jan 4 17:53:37 2010
New Revision: 155628
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155628
Log:
PR c++/42555
* pt.c (tsubst_decl): Don't apply
--- Comment #7 from bdavis at gcc dot gnu dot org 2010-01-04 17:54 ---
Index: gcc/gcc/fortran/trans-decl.c
===
--- gcc/gcc/fortran/trans-decl.c(revision 155625)
+++ gcc/gcc/fortran/trans-decl.c(working copy)
--- Comment #7 from jason at gcc dot gnu dot org 2010-01-04 17:55 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
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 #7 from jakub at gcc dot gnu dot org 2010-01-04 17:56 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from jason at gcc dot gnu dot org 2010-01-04 17:56 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #17 from davek at gcc dot gnu dot org 2010-01-04 18:05 ---
(In reply to comment #16)
You made an unmerited assertion that COMMON symbols don't cause
members to be pulled in from library archives. I've shown the
counter example.
On what platform?
This appears to
--- Comment #3 from janis at gcc dot gnu dot org 2010-01-04 18:06 ---
No testcase yet, I was hoping to get bergner or meissner to look at it since
they have access to the benchmark.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431
--- Comment #18 from davek at gcc dot gnu dot org 2010-01-04 18:06 ---
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1811 also looks pertinent.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
--- Comment #3 from hjl dot tools at gmail dot com 2010-01-04 18:10 ---
It is caused by revision 144914:
http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00421.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-01-04 18:12 ---
I think this is related to (or a dup of bug 42146).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42611
--- Comment #9 from peter_foelsche at agilent dot com 2010-01-04 18:12
---
Created an attachment (id=19464)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19464action=view)
tmp.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42355
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-01-04 18:13 ---
I think you attached the wrong preprocessed source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39184
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-04 18:17 ---
It is not caused by that commit, just add asm volatile ( : : r (s)) to the
testcase and you'll reproduce it even before that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42611
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-01-04 18:19 ---
Subject: Bug 42366
Author: jamborm
Date: Mon Jan 4 18:18:54 2010
New Revision: 155630
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155630
Log:
2010-01-04 Martin Jambor mjam...@suse.cz
PR
On the following test case compiled with GCC 4.4.1 release version and the
following command line
gcc -S -O2 -finline-functions-called-once -fdump-tree-all-details
-fdump-ipa-all fail.c
typedef struct SEntry
{
unsigned char num;
} TEntry;
typedef struct STable
{
TEntry data[2];
} TTable;
--- Comment #6 from jamborm at gcc dot gnu dot org 2010-01-04 18:25 ---
Subject: Bug 42398
Author: jamborm
Date: Mon Jan 4 18:25:14 2010
New Revision: 155631
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155631
Log:
2010-01-04 Martin Jambor mjam...@suse.cz
PR
--- Comment #6 from hjl dot tools at gmail dot com 2010-01-04 18:26 ---
Gcc 3.4 gave:
r42611.c: In function `foo':
pr42611.c:6: error: size of variable 's' is too large
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-01-04 18:34 ---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from hjl dot tools at gmail dot com 2010-01-04 18:39 ---
Now I got
At line 14 of file
/export/gnu/import/svn/gcc-test/src-trunk/libgomp/testsuite/libgomp.fortran/recursion1.f90
Fortran runtime error: Recursive call to nonrecursive procedure 'sub'
--
--- Comment #8 from hjl dot tools at gmail dot com 2010-01-04 18:41 ---
The testcase failed at run-time. See PR 42602
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2010-01-04 18:53 ---
From the tree optimizers we go to expand with the following code (from
PR42612.c.139t.optimized):
;; Function func (func)
func (char * p)
{
bb 2:
*p_1(D) = 0;
p_2 = p_1(D) + 1;
*p_2 = 0;
p_3 = p_2 + 1;
--- Comment #19 from kargl at gcc dot gnu dot org 2010-01-04 18:56 ---
(In reply to comment #17)
(In reply to comment #16)
You made an unmerited assertion that COMMON symbols don't cause
members to be pulled in from library archives. I've shown the
counter example.
On
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-04 19:19 ---
Created an attachment (id=19465)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19465action=view)
gcc45-pr42611.patch
Untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-04 19:33 ---
Can you massage this into a runtime testcase that calls abort () when
miscompiled?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jamborm at gcc dot gnu dot org 2010-01-04 19:35 ---
Hm, with this patch we hit the subsequent assert on x86_64 (as opposed to
i686). I'm looking into this further.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42366
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-01-04 19:39
---
Please also provide output of g++ -v. If you manage to compile this
successfully then the output of -ftime-report will also be interesting.
Confirmed with -g (-g0 is very fast and lean). G++ 4.1 doesn't want to
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-01-04 19:45
---
A random backtrace from where we take endless time and memory:
#0 0x007b8a46 in pp_c_type_qualifier_list (pp=0x18b6280,
t=0x756b8dc8)
at
#include stdio.h
int main() {
int x = 0x87654321;
switch (3*x % 3) {
case 2: puts(SUCCESS); break;
default: puts(FAILURE); break;
}
return 0;
}
gcc -fwrapv test.c
./a.out
FAILURE
Expected output: SUCCESS
This would not be a bug, since integer overflow is
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-04 19:56 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-04 19:56 ---
int __attribute__((noinline))
foo (int x)
{
return 3 * x % 3;
}
extern void abort (void);
int main()
{
int x = 0x87654321;
if (foo (x) != 2)
abort ();
return 0;
}
--
A trivial program with an OMP'ed loop *inside* a pthread does crash at
libgomp.h:380 where gomp_thread()-task becomes NULL-task.
mingw32 on xp is (with my installation) an installation where TLS (thread local
storage) is inop. Hence the pthread_get_specific() and family are used. I
suspect there
--- Comment #12 from peter_foelsche at agilent dot com 2010-01-04 20:00
---
(In reply to comment #10)
Please also provide output of g++ -v. If you manage to compile this
successfully then the output of -ftime-report will also be interesting.
Confirmed with -g (-g0 is very fast and
--- Comment #1 from jos dot de_laender at telenet dot be 2010-01-04 20:01
---
Created an attachment (id=19466)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19466action=view)
The test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616
--- Comment #2 from jos dot de_laender at telenet dot be 2010-01-04 20:03
---
Created an attachment (id=19467)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19467action=view)
A GDB output.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616
--- Comment #6 from jamborm at gcc dot gnu dot org 2010-01-04 20:05 ---
Please disregard the previous comment, I have too many screens on my screen.
This is now fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jason at gcc dot gnu dot org 2010-01-04 20:26 ---
*** This bug has been marked as a duplicate of 35278 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jason at gcc dot gnu dot org 2010-01-04 20:26 ---
*** Bug 38517 has been marked as a duplicate of this bug. ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from bkoz at gcc dot gnu dot org 2010-01-04 20:35 ---
Created an attachment (id=19468)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19468action=view)
remove -O1 to cause fail
With this patch, the following gcc:
ames:gcc benjamin$ ./gcc/xgcc -v
Using built-in
--- Comment #6 from bkoz at gcc dot gnu dot org 2010-01-04 20:38 ---
Optimization Error on Valid
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42346
--- Comment #16 from burnus at gcc dot gnu dot org 2010-01-04 21:01 ---
Subject: Bug 36161
Author: burnus
Date: Mon Jan 4 21:01:10 2010
New Revision: 155632
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155632
Log:
2010-01-04 Tobias Burnus bur...@net-b.de
PR
1 - 100 of 126 matches
Mail list logo
