I am trying to derive a minimal Testcase for a Bug found in:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186
d# gcc/xgcc -v
Using built-in specs.
Target: x86_64-pc-solaris2.11
Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11
--target=x86_64-pc-solaris2.11
--enable-languages=ad
--- Comment #9 from jason at gcc dot gnu dot org 2009-02-14 05:42 ---
Fixed in 4.3 and 4.4.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #8 from rob1weld at aol dot com 2009-02-14 04:36 ---
(In reply to comment #7)
> ...
> Slowly I inch forward ...
and go back ...
/usr/local/bin/ld: /usr/share/src/gcc_build/./gcc/amd64/crtbegin.o: relocation
R_X86_64_32 against `__DTOR_END__' can not be used when making a sha
--- Comment #7 from rob1weld at aol dot com 2009-02-14 04:17 ---
I grepped for CRT_GET_RFIB_DATA and found a definition at the tail of:
/usr/share/src/gcc_trunk/gcc/config/frv/frv.h .
Here is ../gcc_trunk/gcc/crtstuff.c :
static void __attribute__((used))
frame_dummy (void)
{ ...
and
--- Comment #6 from rob1weld at aol dot com 2009-02-14 03:39 ---
I wonder if I discovered a regression ...
If I compile with gcc version 4.4.0 20090213 (experimental) [trunk revision
144149] it produces a little of 32-bit code that is not going to get
compiled with all the "-m64
--- Comment #5 from rob1weld at aol dot com 2009-02-14 02:48 ---
I forced that 32 bit and continued, failing here:
T=`${PWDCMD-pwd}`/ \
&& cd ../../.././gcc \
&& gmake GCC_FOR_TARGET="/usr/share/src/gcc_build/./gcc/xgcc
-B/usr/share/src/gcc_build/./gcc/ -B/usr/local/x86_64-pc-solaris2.1
--- Comment #4 from rob1weld at aol dot com 2009-02-14 02:08 ---
Correction, should have said:
-Thus, I conclude that the "-m32" for
+Thus, I conclude that the "-m64" for
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186
--- Comment #3 from rob1weld at aol dot com 2009-02-14 02:06 ---
The next issue is here:
../gcc_trunk/gcc/unwind-dw2.c and ../gcc_trunk/gcc/unwind-dw2-fde.c, etc ...
../../../../gcc_trunk/libgcc/../gcc/gthr-posix.h:44:21: error: pthread.h: No
such file or directory
../../../../gcc_tru
When using perverted technique like:
SUBROUTINE A
INTEGER, ALLOCATABLE, DIMENSION(:), TARGET :: ARRAY
INTEGER, POINTER, DIMENSION(:) :: ARRAY_PTR
COMMON /AP/ ARRAY_PTR !for later use in another sub
ALLOCATE(ARRAY(10))
ARRAY = 10
ARRAY_PTR => ARRAY
END SUBROUTINE A
SUBROUTINE B
INTEGER, POINTER,
--- Comment #2 from rob1weld at aol dot com 2009-02-14 01:19 ---
A quick hack in ../gcc_trunk/libgcc/configure (line 2065) to
add "-m64" to the 'ac_compile' and 'ac_link' lines will allow
the build to proceed through libgcc to libgcov where it then
fails due to an issue unrelated to this
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-14 00:56 ---
FWIW, it isn't a problem with GNU linker when all files are compiled
with the same version of gcc since linker can merge identical strings
with gcc help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12056
--- 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;
--
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 #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
---
--- 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
[...@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-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
---
-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 #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
--- 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 #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 #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 #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 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 #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
$ 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 #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
--- 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 #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 #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 #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
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 #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
-
--- 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 #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 #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 #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 #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
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
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39181
--- 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
--- 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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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
--
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
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.
--- 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
--- 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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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
--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 #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
--- 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
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 #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
--- 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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 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 #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
--
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 #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|
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 #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
--- 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 #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 #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
1 - 100 of 111 matches
Mail list logo
