--- Comment #3 from rob1weld at aol dot com 2009-02-13 08:36 ---
Here is another person who makes the same complaint (with a patch):
http://hackage.haskell.org/trac/ghc/ticket/2951
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
--- Comment #21 from jakub at gcc dot gnu dot org 2009-02-13 09:17 ---
To answer 2), I bet fwprop would suffer the same problem, but fwprop is
disabled at -O1, LICM is not. I can try it today.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
--- Comment #4 from rob1weld at aol dot com 2009-02-13 09:11 ---
Googling for "amd64-pc-solaris2.11" gives a few hits.
Googling for "x86_64-pc-solaris2.11" gives a dozen hits.
That is not many. Perhaps there is 'no such word'.
It seems there are a few others who discovered this problem
/* { dg-options "-O2 -m32 -fvisibility=hidden -msecure-plt -fpic" } */
__attribute__((noinline)) int
foo (int x)
{
return x;
}
int foo (int x);
int
bar (int x)
{
return foo (x);
}
ICEs on the
if (DEFAULT_ABI == ABI_V4 && flag_pic)
{
gcc_assert (!TARGET_SECURE_PLT);
return
--- Comment #14 from bonzini at gnu dot org 2009-02-13 09:57 ---
It seems to me that it would help to have a postreload LIM pass that would
concentrate on loop-invariant memory accesses that are as cheap or cheaper than
loading back a spill. These would be excluded from the current (non
--- Comment #15 from steven at gcc dot gnu dot org 2009-02-13 10:03 ---
Re. Comment #14
No, this is not crazy. It is called postreload-gcse. But it is a stupid pass
that doesn't handle all cases it ought to handle.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-13 10:34 ---
For completeness, the F2003 standard has in "4.4.4 Character type"
"The length is a type parameter; its value is greater than or equal to zero."
and later
"If the character length parameter value evaluates to a ne
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-13 10:36 ---
The problem is in the redundant prototype after function.
First the foo FUNCTION_DECL is created, afterwards finish_function calls
c_determine_visibility on it which changes its visibility from default to
hidden.
After
--- Comment #22 from rguenther at suse dot de 2009-02-13 11:06 ---
Subject: Re: Code that compiles fine in 1GB of memory
with 4.1.2 requires > 20GB in 4.2.* and higher
On Thu, 12 Feb 2009, lucier at math dot purdue dot edu wrote:
> --- Comment #19 from lucier at math dot purdue d
--- Comment #23 from rguenth at gcc dot gnu dot org 2009-02-13 11:08
---
Lemme close this bug as a dup of the one marked as regression.
*** This bug has been marked as a duplicate of 26854 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #85 from rguenth at gcc dot gnu dot org 2009-02-13 11:08
---
*** Bug 39157 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #7 from tsyvarev at ispras dot ru 2009-02-13 11:21 ---
(In reply to comment #4)
>
> I'm not sure I understand your rationale or I agree that this is a bug. IIUC,
> string(1, CHAR_MAX) indicates that groups may be of arbitrary length, which
> includes "123,456" This behavior
--- Comment #8 from paolo dot carlini at oracle dot com 2009-02-13 11:31
---
(In reply to comment #7)
Standard use term "unlimited length", which
> means(as I understand) that all other digits should incorporate in only one
> group - only "123456" is co
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-13 11:33 ---
Created an attachment (id=17292)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17292&action=view)
gcc44-pr39175.patch
Patch I'm going to bootstrap/regtest.
--
jakub at gcc dot gnu dot org changed:
--- Comment #9 from paolo dot carlini at oracle dot com 2009-02-13 11:39
---
In other terms, as usual about those matters, Martin is right ;) Only he has
got a wrong data point about libstdc++, he believes we are setting eofbit.
Thanks anyway for pointing our attention to this CHAR_MAX
I noticed this running mixed mpi/openmp on a system that required an executable
without dynamics libraries. Don't know if the Fortran IO is supposed to be
thread safe (i.e. serialized thread safe), but this seems to work without
-static. It also appears to work with 4.3.1 but not 4.4 (trunk)
> cat
--- Comment #1 from jv244 at cam dot ac dot uk 2009-02-13 11:42 ---
adding Jakub
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
CC|
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39176
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-13 11:50 ---
This has been repeated many times. Don't use -static for threaded programs, it
is really bad idea, and if you really have to, you need to link the whole
libpthread.a in (-Wl,--whole-archive -lpthread -Wl,--no-whole-ar
--- Comment #3 from jv244 at cam dot ac dot uk 2009-02-13 12:19 ---
(In reply to comment #2)
> This has been repeated many times. Don't use -static for threaded programs,
> it
> is really bad idea, and if you really have to, you need to link the whole
> libpthread.a in (-Wl,--whole-arc
--- Comment #4 from jakub at gcc dot gnu dot org 2009-02-13 12:35 ---
It is glibc specific, on the other hand it isn't particularly -fopenmp related.
I guess easiest will be if glibc stops shipping libpthread.a.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39176
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-13 12:44 ---
This also ICEs on the 4.3 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39175
--- Comment #3 from pault at gcc dot gnu dot org 2009-02-13 12:53 ---
The patch for 36703 also fixes this fellow.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from jsm28 at gcc dot gnu dot org 2009-02-13 13:11 ---
Subject: Bug 35444
Author: jsm28
Date: Fri Feb 13 13:10:52 2009
New Revision: 144155
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144155
Log:
PR c/35444
* c-parser.c (c_parser_parms_list_decl
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-02-13 13:12 ---
Fixed for 4.4.0 and 4.3.4. Not planning to work on a backport to 4.2.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from tsyvarev at ispras dot ru 2009-02-13 13:41 ---
(In reply to comment #8)
> (In reply to comment #7)
> Standard use term "unlimited length", which
> > means(as I understand) that all other digits should incorporate in only one
> > grou
--- Comment #11 from paolo dot carlini at oracle dot com 2009-02-13 13:43
---
(In reply to comment #10)
> Do you mean that when reading "123,456" with string(1, -1), failbit shouldn't
> be set?
Right, as Martin said.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
--- Comment #5 from jv244 at cam dot ac dot uk 2009-02-13 14:01 ---
(In reply to comment #4)
> It is glibc specific, on the other hand it isn't particularly -fopenmp
> related.
> I guess easiest will be if glibc stops shipping libpthread.a.
but if -fopenmp automatically adds -lpthread
--- Comment #3 from hjl at gcc dot gnu dot org 2009-02-13 14:34 ---
Subject: Bug 39162
Author: hjl
Date: Fri Feb 13 14:34:00 2009
New Revision: 144157
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144157
Log:
gcc/
2009-02-13 H.J. Lu
PR target/39162
* config
--- Comment #21 from hjl at gcc dot gnu dot org 2009-02-13 14:37 ---
Subject: Bug 39152
Author: hjl
Date: Fri Feb 13 14:37:11 2009
New Revision: 144158
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144158
Log:
gcc/
2009-02-13 H.J. Lu
PR target/39152
* confi
Topic brought up on #gfortran by Janne.
There are some potential issues in using main.c in a library; thus one should
have only link a "main()" if the *.o files don't have a "main".
See also:
http://groups.google.com/group/comp.os.linux.development.apps/browse_thread/thread/e35b2224a7dc27bf/
http
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-13 14:57 ---
s/MAIN_/MAIN__/g
* * *
> Intel's solution is to link "for_main-o", but that is not as elegant as for
> "ifort *.o" one needs to specify "-nofor-main" if there is a non-fortran C
The last line should read: 'if ther
--- Comment #12 from tsyvarev at ispras dot ru 2009-02-13 15:04 ---
Let's consider the following situation (seems lifelike to me). Suppose one
needs a representation of numbers in which only the last 3 digits are separated
from all other digits (grouped), like "1234,567" or "1234567,890"
--- Comment #13 from paolo dot carlini at oracle dot com 2009-02-13 15:11
---
(In reply to comment #12)
> Could you suggest which grouping string should be used to do such number
> representation? Or is this unachievable?
Actually \003\176 seems perfectly practical to me. In particular
--- Comment #2 from burnus at gcc dot gnu dot org 2009-02-13 15:11 ---
Note: Moving main() to f951 will break programs which assume that MAIN__ will
be called, compile e.g. the following program with gcc:
---
#include
int MAIN__( int argc, char* argv[] )
{printf("argc is
--- Comment #14 from paolo dot carlini at oracle dot com 2009-02-13 15:21
---
If I understand correctly, in order to implement the POSIX behavior for C++,
assuming we want it, the Standard should be clarified to explain that values <=
0 or CHAR_MAX are different in that do no admit repe
--- Comment #21 from d dot g dot gorbachev at gmail dot com 2009-02-13
15:25 ---
Created an attachment (id=17293)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17293&action=view)
precompiled source
The same issue with GCC 4.3.3 (i686-pc-linux-gnu).
C source:
http://svn.savannah.
--- Comment #15 from tsyvarev at ispras dot ru 2009-02-13 15:38 ---
(In reply to comment #14)
> If I understand correctly, in order to implement the POSIX behavior for C++,
> assuming we want it, the Standard should be clarified to explain that values
> <=
> 0 or CHAR_MAX are different
--- Comment #86 from lucier at math dot purdue dot edu 2009-02-13 15:40
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
It's unfortunate that the discussion from 39157 will be somewhat hard to
find now that that bug is closed.
Steven wrote in a comme
It seems so that for optimization levels one or higher, gcc produces wrong code
for the two test files below.
If I compile the same test with -O or -Os everything works fine.
On taking a look into produced assembly, it seems that it wrongly assumes the
assert alway have to raise.
File 1: t1.cpp
--- Comment #16 from paolo dot carlini at oracle dot com 2009-02-13 15:49
---
(In reply to comment #15)
> (In reply to comment #14)
> > If I understand correctly, in order to implement the POSIX behavior for C++,
> > assuming we want it, the Standard should be clarified to explain that
--- Comment #6 from hjl dot tools at gmail dot com 2009-02-13 15:51 ---
I checked gcc 3.4.6. The bug is there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39082
--with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local
--without-ppl
Thread model: posix
gcc version 4.4.0 20090213 (experimental) [trunk revision 144149] (GCC)
# gmake
...
./gcj-dbtool -n classmap.db || touch classmap.db
/bin/sh: line 1: 20225: Memory fault(coredump)
cp
--- Comment #10 from hjl dot tools at gmail dot com 2009-02-13 15:57
---
Fixed. Gcc 4.4.0 revision 144128 generates:
foo2:
movd%edi, %xmm0
movd%esi, %xmm1
movd%edx, %xmm2
punpckldq %xmm0, %xmm1
movd%ecx, %xmm0
punpck
--- Comment #37 from hjl dot tools at gmail dot com 2009-02-13 16:00
---
Gcc 4.4.0 revision 144128 generates:
.globl convert
.type convert, @function
convert:
movl%edi, -4(%rsp)
movss -4(%rsp), %xmm0
ret
.size convert, .-convert
--- Comment #44 from bonzini at gnu dot org 2009-02-13 16:05 ---
A simplified (local, noncascading) fwprop not using UD chains would not be hard
to do... Basically, at -O1 use FOR_EACH_BB/FOR_EACH_BB_INSN instead of walking
the uses, keep a (regno, insn) map of pseudos (cleared at the b
--- Comment #45 from lucier at math dot purdue dot edu 2009-02-13 16:09
---
Subject: Re: [4.3/4.4 Regression] 30%
performance slowdown in floating-point code caused by r118475
On Fri, 2009-02-13 at 16:05 +, bonzini at gnu dot org wrote:
> --- Comment #44 from bonzini at gnu
--- Comment #46 from bonzini at gnu dot org 2009-02-13 16:32 ---
Regarding your comment in bug 26854:
> address calculations are no longer optimized as much as they
> were before
Sometimes, actually, they are optimized better. It depends on the case.
In comment #42, also, you talked
--- Comment #7 from mmitchel at gcc dot gnu dot org 2009-02-13 16:41
---
In that case, this isn't a high-priority bug. That doesn't mean that it can't
be fixed before 4.4; that's up to the x86 maintainers. But, it shouldn't block
the release.
--
mmitchel at gcc dot gnu dot org cha
http://builder.classpath.org/japi/classpath-libgcj.html#err_missing_java_lang
Classpath now has two new constructors from 1.6 that take a
java.nio.charset.Charset. We need to provide these in gcj too.
--
Summary: New String constructors need to be implemented in local
--- Comment #87 from bonzini at gnu dot org 2009-02-13 16:54 ---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
> It's unfortunate that the discussion from 39157 will be somewhat hard to
> find now that that bug is closed.
Well, the patch there is not lo
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-13 16:58 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #88 from jakub at gcc dot gnu dot org 2009-02-13 17:06 ---
The patch in PR39157 is IMHO finished and has been bootstrapped/regtested on
x86_64-linux and i686-linux. I haven't posted it looked like Richard, Zdenek
and Steven prefer some other solution for it. If this isn't s
--- Comment #47 from lucier at math dot purdue dot edu 2009-02-13 17:22
---
Subject: Re: [4.3/4.4 Regression] 30%
performance slowdown in floating-point code caused by r118475
On Fri, 2009-02-13 at 16:32 +, bonzini at gnu dot org wrote:
>
>
> --- Comment #46 from bonzini a
--- Comment #22 from hjl dot tools at gmail dot com 2009-02-13 17:23
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|REOPENE
Small testcase:
_Complex int bar(_Complex int z)
{
return z;
}
--- CUT ---
This causes some testsuite failures on spu-elf.
t.c: In function bar:
t.c:9: internal compiler error: in spu_expand_mov, at config/spu/spu.c:4117
Please submit a full bug report,
with preprocessed source if appropriate.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39181
--- Comment #89 from lucier at math dot purdue dot edu 2009-02-13 17:30
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
On Fri, 2009-02-13 at 17:06 +, jakub at gcc dot gnu dot org wrote:
>
>
> --- Comment #88 from jakub at gcc dot gnu dot or
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-13 17:31 ---
It started to ICE between revision 142828 and revision 144107 (a little over
two months worth).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39181
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-13 17:31 ---
(In reply to comment #2)
> See the comment:
>
> "... Remove this code in GCC 3.2 or later."
>
But given the bogus warning message, we may never remove it :-).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39
--- Comment #90 from lucier at math dot purdue dot edu 2009-02-13 17:37
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
On Fri, 2009-02-13 at 16:54 +, bonzini at gnu dot org wrote:
>
>
> --- Comment #87 from bonzini at gnu dot org 2009-02-1
--- Comment #91 from lucier at math dot purdue dot edu 2009-02-13 17:43
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
On Fri, 2009-02-13 at 17:37 +, lucier at math dot purdue dot edu
wrote:
> --- Comment #90 from lucier at math dot purdue do
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-13 17:44 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00657.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from gnu_andrew at member dot fsf dot org 2009-02-13 17:45
---
Created an attachment (id=17294)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17294&action=view)
Preliminary patch, has issues with the returned string reading from the wrong
memory location
Preliminar
--- Comment #5 from hjl at gcc dot gnu dot org 2009-02-13 17:48 ---
Subject: Bug 39149
Author: hjl
Date: Fri Feb 13 17:48:20 2009
New Revision: 144160
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144160
Log:
2009-02-13 H.J. Lu
PR target/39149
* config/i386/
--- Comment #2 from tromey at gcc dot gnu dot org 2009-02-13 17:54 ---
This line looks fishy:
+ boffset = cbuf->position();
boffset is a byte offset from the start of 'data' to the first character.
So, you probably need to multiply by sizeof(jchar) and also add in
the size of t
We get this error multiple places in the RTEMS code base.
m32c-rtems4.10-gcc --pipe -mcpu=m32cm --pipe -DHAVE_CONFIG_H -I..
-I../../../lib/include -D__RTEMS_INSIDE__ -Wall
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -fasm -g
-O2 -mcpu=m32cm -MT src/libsapi_a-ioregis
--- Comment #1 from joel at gcc dot gnu dot org 2009-02-13 18:50 ---
Created an attachment (id=17295)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17295&action=view)
preprocessed test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39182
--- Comment #2 from joel at gcc dot gnu dot org 2009-02-13 18:52 ---
WORKS: m32c-rtems4.10-gcc -mcpu=m32cm j.c -c
FAILS: m32c-rtems4.10-gcc -mcpu=m32cm j.c -O1 -c
FAILS: m32c-rtems4.10-gcc -mcpu=m32cm j.c -O2 -c
--
joel at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from jason at gcc dot gnu dot org 2009-02-13 19:14 ---
Subject: Bug 39070
Author: jason
Date: Fri Feb 13 19:14:07 2009
New Revision: 144161
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144161
Log:
PR c++/39070
* semantics.c (finish_call_expr): Ch
--- Comment #19 from jakub at gcc dot gnu dot org 2009-02-13 19:15 ---
Created an attachment (id=17296)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17296&action=view)
Unsuccessful attempt to avoid stack realignment for DImode and for DFmode at
-Os
Just for the record, here is an
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39181
I just tried to compile the Linux kernel 2.6.28.5
with the GNU C compiler version 4.4 snapshot 20090206,
using the valgrind debugging tool.
The compiler said
as --gdwarf2 -V -Qy --64 -o arch/x86/ia32/ia32entry.o ia32entry.s
==4085== Conditional jump or move depends on uninitialised value(s)
==408
--- Comment #48 from bonzini at gnu dot org 2009-02-13 20:09 ---
Subject: Re: [4.3/4.4 Regression] 30%
performance slowdown in floating-point code caused by r118475
> Yes. I don't see why the optimizations in CSE, which were relatively
> cheap and which were effective for thi
--- Comment #1 from dcb314 at hotmail dot com 2009-02-13 20:10 ---
Created an attachment (id=17297)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17297&action=view)
pre-processed assembly language code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39183
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-13 20:11 ---
As is not part of GCC project, report it to binutils project,
http://sourceware.org/bugzilla/
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-02-13 20:18 ---
Not a gcc bug so closing as invalid. That warning comes from glibc anyways.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-13 20:19 ---
FWIW, I can't reproduce it with the current binutils in CVS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39183
--- Comment #3 from dj at redhat dot com 2009-02-13 20:28 ---
Fails with m32c-elf in 4.3.4 also.
Note: does NOT fail in 4.4/trunk
--
dj at redhat dot com changed:
What|Removed |Added
-
ICE at -O1 and -02. Target specific error message at -O0. But even that would
be more helpful if it told what the actual limit was.
$ avr-rtems4.10-gcc -mmcu=avr25 -O2 j.c -c
../../../../../rtems/cpukit/telnetd/des.c: In function 'des_init':
../../../../../rtems/cpukit/telnetd/des.c:274: inter
--- Comment #1 from joel at gcc dot gnu dot org 2009-02-13 20:54 ---
Created an attachment (id=17298)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17298&action=view)
preprocessed test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39184
--- Comment #7 from jv244 at cam dot ac dot uk 2009-02-13 21:00 ---
(In reply to comment #6)
> Not a gcc bug so closing as invalid.
The gcc 'bug' is that -fopenmp -static should link to pthreads as
-Wl,--whole-archive -lpthread -Wl,--no-whole-archive, if that is required, or
error o
--- Comment #8 from jakub at gcc dot gnu dot org 2009-02-13 21:10 ---
This is not a gcc bug, glibc either should not ship libpthread.a at all or
mv libpthread.a libpthreadx.a; gcc -r -nostdlib -o libpthread.a --whole-archive
libpthreadx.a; rm libpthreadx.a
I'll try the latter in Fedora s
--- Comment #3 from pault at gcc dot gnu dot org 2009-02-13 21:12 ---
Subject: Bug 36528
Author: pault
Date: Fri Feb 13 21:12:34 2009
New Revision: 144164
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144164
Log:
2009-02-13 Paul Thomas
PR fortran/36703
PR fo
--- Comment #4 from pault at gcc dot gnu dot org 2009-02-13 21:12 ---
Subject: Bug 36703
Author: pault
Date: Fri Feb 13 21:12:34 2009
New Revision: 144164
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144164
Log:
2009-02-13 Paul Thomas
PR fortran/36703
PR fo
$ h8300-rtems4.10-gcc -O1 -msx -c j.c
../../../../../rtems/cpukit/libnetworking/netinet/in_cksum.c: In function
'in_cksum':
../../../../../rtems/cpukit/libnetworking/netinet/in_cksum.c:118: internal
compiler error: in gen_rtx_SUBREG, at emit-rtl.c:773
Please submit a full bug report,
with preproces
--- Comment #1 from joel at gcc dot gnu dot org 2009-02-13 21:17 ---
Created an attachment (id=17299)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17299&action=view)
preprocessed test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39185
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-13 21:20 ---
Most likely related to PR 33163 and PR 32739.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39185
--- Comment #8 from jason at gcc dot gnu dot org 2009-02-13 21:53 ---
Subject: Bug 39070
Author: jason
Date: Fri Feb 13 21:53:38 2009
New Revision: 144166
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144166
Log:
PR c++/39070
* semantics.c (finish_call_expr): Ch
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-13 21:58 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00674.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #4 from sje at gcc dot gnu dot org 2009-02-13 21:59 ---
Subject: Bug 38056
Author: sje
Date: Fri Feb 13 21:59:32 2009
New Revision: 144168
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144168
Log:
PR target/38056
* config/ia64/ia64.c (ia64_function_o
--- Comment #5 from burnus at gcc dot gnu dot org 2009-02-13 22:16 ---
Subject: Bug 38259
Author: burnus
Date: Fri Feb 13 22:16:20 2009
New Revision: 144169
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144169
Log:
2009-02-13 Mikael Morin
PR fortran/38259
*
--- Comment #6 from burnus at gcc dot gnu dot org 2009-02-13 22:17 ---
FIXED on the trunk (4.4.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-with-mpfr=/usr/local
--without-ppl
Thread model: posix
gcc version 4.4.0 20090213 (experimental) [trunk revision 144162] (GCC)
# as --version
GNU assembler (GNU Binutils) 2.19.1
# ld --version
GNU ld (GNU Binutils) 2.19.1
The Build breaks here:
# gmake
...
cp gcj gcj-cross
gmake[2]: Leaving
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-13 23:54 ---
the -X86_64 option is not being passed to as which is a bug in the specs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
[...@gnu-6 936]$ cat x.cc
#include "foo.h"
const char *
x (void)
{
return f ();
}
[...@gnu-6 936]$ cat y.cc
#include
#include "foo.h"
extern const char *x (void);
int
main ()
{
printf ("%p, %p\n", x (), f ());
return 0;
}
[...@gnu-6 936]$ cat foo.h
inline const char *
f ()
{
static cons
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-14 00:11 ---
Except the C++ standard has a defect against this area, see PR 12056 which is
still opened the last time I looked.
*** This bug has been marked as a duplicate of 12056 ***
--
pinskia at gcc dot gnu dot org chang
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-14 00:11 ---
*** Bug 39187 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
Summary: G++ doesn't handle static anonymous union right
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
Report
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-14 00:38 ---
[...@gnu-6 936]$ cat x.cc
#include "foo.h"
int *
x (void)
{
return f ();
}
[...@gnu-6 936]$ cat y.cc
#include
#include "foo.h"
extern int *x (void);
int
main ()
{
printf ("%p, %p\n", x (), f ());
return 0;
1 - 100 of 111 matches
Mail list logo
