--- Comment #11 from burnus at gcc dot gnu dot org 2010-01-05 07:19 ---
Subject: Bug 41872
Author: burnus
Date: Tue Jan 5 07:19:30 2010
New Revision: 155639
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155639
Log:
2010-01-05 Tobias Burnus
PR fortran/41872
--- Comment #1 from kargl at gcc dot gnu dot org 2010-01-05 05:49 ---
(In reply to comment #0)
> [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 stand
--- Comment #4 from adam at consulting dot net dot nz 2010-01-05 04:17
---
/* Workaround discovered! */
void test_int_vectors_containing_fp_data_using_local_reg_var_overlay() {
//create local register variables of the required floating point type
//(for the same global register vari
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2010-01-05 03:01
---
I have read through the links given by Dave. My take is that we have some
implementation dependent, non portable, behaviour in linkers. Now that we know
we have this inconsistency, the question is do we want to
--- Comment #11 from jlpoole at pon dot net 2010-01-05 02:34 ---
For the record:
plug build # ls -la config.log
-rw-r--r-- 1 root root 36708 2010-01-03 17:37 config.log
plug build # head config.log
This file contains any messages produced by compilers while
running configure, to aid debu
--- Comment #10 from jlpoole at pon dot net 2010-01-05 02:31 ---
http://gcc.gnu.org/install/finalinstall.html has:
v
...
We strongly recommend to install into a target directory where there is no
previous version of GCC present.
...
Installation into a temporary staging area or into
--- Comment #8 from bkoz at gcc dot gnu dot org 2010-01-05 01:10 ---
Glad you can reproduce now. Sorry I was so vague before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42346
--- Comment #2 from janis at gcc dot gnu dot org 2010-01-05 00:53 ---
Currently the compiler explicitly allows "-mvsx -mno-altivec". If those
options are used together, should vsx and altivec both be turned on, or both
turned off?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4241
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2010-01-05 00:19
---
Regarding "There's nothing funny or weird about the compile line folks", well,
actually, it was really needed. Turns out it doesn't fail without "-g", which
is why I didn't see it.
--
fxcoudert at gcc dot gnu
--- Comment #8 from yuri at rawbw dot com 2010-01-04 23:57 ---
Subject: Re: Segmentation fault when ecj.jar is run as a
binary compiled by gcj
gerald at pfeifer dot com wrote:
> --- Comment #6 from gerald at pfeifer dot com 2010-01-03 13:10 ---
> Would you mind trying again w
--- Comment #4 from kkojima at gcc dot gnu dot org 2010-01-04 23:49 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from kkojima at gcc dot gnu dot org 2010-01-04 23:47 ---
Subject: Bug 42316
Author: kkojima
Date: Mon Jan 4 23:46:56 2010
New Revision: 155634
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155634
Log:
PR target/42316
* configure.ac (PICFLAG): Use
--- Comment #1 from ramana at gcc dot gnu dot org 2010-01-04 23:44 ---
For completeness the options are with -mthumb -Os -march=armv5te ?
With trunk I see a size of 52 bytes and this code.
.type test, %function
test:
push{r4, r5, r6, r7, lr}
sub sp,
--- Comment #1 from simon at pushface dot org 2010-01-04 23:34 ---
Created an attachment (id=19469)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19469&action=view)
Reproducer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42618
The test program writes 3 values of a discriminated record to a stream
('Output) and then reads them back ('Input).
It then uses 'Write and 'Read for a single value.
No problem arises with 32-bit compilations, or with 64-bit compilations with
-O0.
With -O1 or -O2, the values read back are incorre
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||alias, mi
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-04 23:25 ---
See http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00463.html for a half-way
working
patch. Somebody needs to dive into var-tracking.c and fix the fallout.
--
rguenth at gcc dot gnu dot org changed:
Wh
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #50 from rguenth at gcc dot gnu dot org 2010-01-04 23:11
---
ira_traverse_loop_tree and its callee process_bb_node_for_cost accounts for
nearly as much time as reload takes on hashes.c.
Btw, I find valgrind --tool=callgrind together with kcachegrind a better tool
for benchm
--- Comment #4 from bergner at gcc dot gnu dot org 2010-01-04 23:05 ---
Ahh, yes, you are correct. I can confirm the bogus assembly code. I'll
investigate.
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
---
http://gcc.gnu.org/ml/gcc/2009-12/msg00169.html
From: Jianzhang Peng
I unroll the following code one times in a gimpile pass.
for(i=0; i< N ; i++)
a[i] = b[i] + c[i];
And then I create the loops's ddg using build_intra_loop_deps ( ) in
an RTL pass;
I found the data dependence information: i
--- Comment #5 from hjl dot tools at gmail dot com 2010-01-04 22:37 ---
(In reply to comment #4)
> 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 proced
--- Comment #9 from hjl dot tools at gmail dot com 2010-01-04 22:36 ---
(In reply to comment #8)
> The testcase failed at run-time. See PR 42602
>
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00187.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42517
--- Comment #3 from janis at gcc dot gnu dot org 2010-01-04 22:12 ---
I get the same error with mainline built today. I'm using a compiler that
defaults to -m32; it works fine with -m64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42427
--- Comment #2 from bergner at gcc dot gnu dot org 2010-01-04 21:57 ---
The assembly looks different and doesn't error with today's trunk (revision
155629). I'll try with the revision Janis pointed out and see if it really is
fixed or is just latent again.
--
http://gcc.gnu.org/bug
--- Comment #17 from burnus at gcc dot gnu dot org 2010-01-04 21:13 ---
FIXED. Thanks Göran for the suggestion! If you want to try, I can send you the
gcc.pot file of the current 4.5 trunk (or do "cd $GCC_build_dir/gcc; make
gcc.pot" to create ./po/gcc.pot yourself.)
See also http://gcc
--- 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=gcc&view=rev&rev=155632
Log:
2010-01-04 Tobias Burnus
PR fortran/36161
--- 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 #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=19468&action=view)
remove -O1 to cause fail
With this patch, the following gcc:
ames:gcc benjamin$ ./gcc/xgcc -v
Using built-in spe
--- 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 #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 #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 #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=19467&action=view)
A GDB output.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616
--- 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=19466&action=view)
The test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616
--- 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 an
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 #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;
}
--
http://gcc.gnu.org/bugz
--- 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|
#include
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 undefined in
--- 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 /space/rguenther/src/svn/trunk/gcc/c-pretty-print.c:24
--- 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 #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 #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 #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=19465&action=view)
gcc45-pr42611.patch
Untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- 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.
--- 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)
{
:
*p_1(D) = 0;
p_2 = p_1(D) + 1;
*p_2 = 0;
p_3 = p_2 + 1;
*p_3 =
--- 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 #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'
--
http://gcc.gnu.or
--- 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 #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 #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=gcc&view=rev&rev=155631
Log:
2010-01-04 Martin Jambor
PR tree-optimization/423
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;
T
--- 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=gcc&view=rev&rev=155630
Log:
2010-01-04 Martin Jambor
PR tree-optimization/423
--- 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 #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 #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=19464&action=view)
tmp.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42355
--- 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 #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 #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 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 #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 appear
--- 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 #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
--
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 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
--- 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 #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=gcc&view=rev&rev=155628
Log:
PR c++/42555
* pt.c (tsubst_decl): Don't apply ty
--- 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=gcc&view=rev&rev=155627
Log:
PR c++/42567
* semantics.c (describable_type): Re
--- 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 #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
---
-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
P
--- 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
--- 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=19463&action=view)
proposed patch
(In reply to comment #14)
> Is this still an issue?
I have not tried to reproduce it, but I woul
--- 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
--
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 #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 res
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Component|c |rtl-optim
--- 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 need
--- 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 #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 #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 #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=gcc&view=rev&rev=155622
Log:
PR driver/42442
* gcc.c (SWITCH_IGNORE_PERMANENTL
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 #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 c
--- 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 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=gcc&view=rev&rev=155618
Log:
Don't convert GTU to GT for V4SI and V2DI
gcc/
2010-01-04 H.J. Lu
--- 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=19462&action=view)
gcc45-pr42604.patch
Untested shot in the dark. Just skipping the debug stmts leads to checking
failure, resettin
--- 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=gcc&view=rev&rev=155617
Log:
2010-01-04 Mikael Pettersson
PR target/42503
--- 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=gcc&view=rev&rev=155617
Log:
2010-01-04 Mikael Pettersson
PR target/42503
B
--- 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=19461&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42611
seen on current branches and the trunk, at least on x86 and x86_64:
Matthias
$ cat x.C
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define DEBUG_MODE 1
#define _DEBUG(str,param) { if( DEBUG_MODE == 1 ) { fprintf( std
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
--- 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=gcc&view=rev&rev=155616
Log:
Turn on trace in collect2 if needed
2010-01-04 H.J. Lu
P
--- 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
S
--- 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=gcc&view=rev&rev=155615
Log:
Make 's' atomic
2010-01-04 H.J. Lu
PR libgomp/42602
--- 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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed-op
--- 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
--
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 #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
---
1 - 100 of 126 matches
Mail list logo
