mkdir -p ada/bldtools/einfo
(cd ada/bldtools/sinfo gnatmake -q xsinfo ./xsinfo ../../sinfo.h )
rm -f ada/bldtools/einfo/einfo.ads ada/bldtools/einfo/einfo.adb
ada/bldtools/einfo/xeinfo.adb
cp -p ../../gcc/gcc/ada/einfo.ads ../../gcc/gcc/ada/einfo.adb
--- Comment #3 from charlet at adacore dot com 2008-08-07 06:41 ---
Subject: Re: /bin/sh: line 1: 26087 Aborted (core dumped)
./xsinfo ../../sinfo.h
mkdir -p ada/bldtools/einfo
(cd ada/bldtools/sinfo gnatmake -q xsinfo ./xsinfo ../../sinfo.h )
rm -f
--- Comment #16 from manu at gcc dot gnu dot org 2008-08-07 07:50 ---
The expression cannot be very complicated because it needs to be a INTEGER_CST.
On the other hand, I agree that it is best to give users as much information as
reasonable. I think it is better if you comment in
--- Comment #7 from urjaman at gmail dot com 2008-08-07 07:51 ---
I did a simple test on my avr-gcc 4.2.2 and it seems that this bug (i dont
think it should be Resolution: INVALID but...) is fixed in 4.2.2 atleast. I
changed the register used in the example to r2 to see if the AVR's
--- Comment #3 from Joey dot ye at intel dot com 2008-08-07 07:55 ---
Although 138318 fixes the compiler ICE, it miscompile with -O3 -ffast-math on
x86-64:
Running 172.mgrid ref base o3 default
*** Miscompare of mgrid.out, see
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-08-07 08:50 ---
Confirmed. This is the other machinery.
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-07 08:51 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
At revision 138835
/data/vondele/gcc_bench/gcc_trunk/gcc/gcc/dwarf2out.c: In function
gen_subprogram_die:
/data/vondele/gcc_bench/gcc_trunk/gcc/gcc/dwarf2out.c:13496: error:
unrecognizable insn:
(insn 1465 2398 1466 235
/data/vondele/gcc_bench/gcc_trunk/gcc/gcc/dwarf2out.c:8357 (parallel [
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-07 10:01 ---
Subject: Bug 37042
Author: rguenth
Date: Thu Aug 7 09:59:58 2008
New Revision: 138836
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138836
Log:
2008-08-07 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-08-07 10:02 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-08-07 10:03 ---
Subject: Bug 37042
Author: rguenth
Date: Thu Aug 7 10:01:48 2008
New Revision: 138837
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138837
Log:
2008-08-07 Richard Guenther [EMAIL PROTECTED]
PR
In the following example, the fucntion hooray() does not get inlined,
even though it could.
#include stdlib.h
#include stdio.h
static __attribute__((always_inline)) void hooray ()
{
printf (hooray\n);
}
static __attribute__((always_inline)) void hiphip (void (*f)())
{
printf (hip hip\n);
--- Comment #1 from jamborm at gcc dot gnu dot org 2008-08-07 10:11 ---
I am testing the patch below which should fix the problem:
2008-08-07 Martin Jambor [EMAIL PROTECTED]
* tree-inline.c (remap_gimple_stmt): Remove extraneous addr_expr
from call statements.
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-07 11:22 ---
Then this is confirmed and it works in GCC 4.4.0
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2008-08-07 11:54 ---
Confirmed as enhancement.
To clarify how to implement this, I have some questions:
(In reply to comment #0)
-Wc++-compat should allow bool, wchar_t, char16_t and char32_t as typedefs
defined in system headers,
--- Comment #2 from joseph at codesourcery dot com 2008-08-07 12:04 ---
Subject: Re: -Wc++-compat refinements
On Thu, 7 Aug 2008, manu at gcc dot gnu dot org wrote:
To clarify how to implement this, I have some questions:
(In reply to comment #0)
-Wc++-compat should allow bool,
--- Comment #1 from jv244 at cam dot ac dot uk 2008-08-07 12:21 ---
Just in case this is useful, this is the corresponding command line:
/data/vondele/gcc_bench/gcc_trunk/obj/./prev-gcc/xgcc
-B/data/vondele/gcc_bench/gcc_trunk/obj/./prev-gcc/
--- Comment #5 from simonb at gcc dot gnu dot org 2008-08-07 12:29 ---
Subject: Bug 36999
Author: simonb
Date: Thu Aug 7 12:27:48 2008
New Revision: 138838
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138838
Log:
gcc/cp/ChangeLog:
Backport from mainline:
In 7.3.1.1p2, the standard states The use of the static keyword is deprecated
when declaring objects in a namespace scope, yet g++ does not warn about such
uses. Compiling the following snippet:
static int i;
int g() { return i; }
results in no diagnostics of any kind, not even with
Revision 138835 breaks bootstrap on Linux/x86-64:
[EMAIL PROTECTED] zlib]$ /export/gnu/import/svn/gcc-test/bld/./prev-gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/ -DPACKAGE_NAME=\\
-DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-07 13:11 ---
4 years old, no activity, unconfirmed. Please fill bugs for specific targets
with testcases so the target maintainers are aware of this issue.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #17 from bangerth at dealii dot org 2008-08-07 13:13 ---
(In reply to comment #16)
The expression cannot be very complicated because it needs to be a
INTEGER_CST.
Sure, but it can be of the form
~SOME_PREPROCESSOR_MACRO | (MACRO2 ^ MACRO3)
What I meant to say is that
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-07 13:14 ---
Looks good. Similar things may happen with CCP propagation for like
void foo(void) {}
void bar(void)
{
void (*fn)(void) = foo;
fn();
}
can you verify this as well? Thanks.
--
--- Comment #21 from hjl at gcc dot gnu dot org 2008-08-07 13:17 ---
Subject: Bug 36992
Author: hjl
Date: Thu Aug 7 13:16:23 2008
New Revision: 138839
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138839
Log:
gcc/
2008-08-07 H.J. Lu [EMAIL PROTECTED]
PR target/36992
--- Comment #22 from hjl dot tools at gmail dot com 2008-08-07 13:18
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2008-08-07 13:20 ---
*** This bug has been marked as a duplicate of 37048 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-07 13:20 ---
*** Bug 37045 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2008-08-07 13:21 ---
It also happens on Linux/ia32.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37048
--- Comment #2 from scott at stg dot net 2008-08-07 13:31 ---
Okay, so if I change:
FooBar operator (const char *s,FooBar dest)
to
FooBar operator (const char *s,FooBar dest)
It now compiles on both msvc and g++, but required functionality (operation
affecting existing object, not
--- Comment #3 from hjl dot tools at gmail dot com 2008-08-07 13:47 ---
[EMAIL PROTECTED] prev-gcc]$ cat ../zlib/x.c
typedef struct gz_stream {
char *inbuf;
long offset;
} gz_stream;
void *malloc(__SIZE_TYPE__ size);
long
foo (void * file, long offset)
{
gz_stream *s =
--- Comment #3 from scott at stg dot net 2008-08-07 13:53 ---
For clarification, this code compiles runs in gcc msvc:
FooBar test1(one);
Atest1;
And this code compiles runs fine in msvc, but gives compile error in gcc:
BFooBar(two);
Since it's the same
--- Comment #4 from jh at suse dot cz 2008-08-07 14:30 ---
Subject: Re: [4.4 Regression] Revision 138835 breaks bootstrap
Hi,
thanks for testcase, for some reason it does not reproduce on our
testing setup, probably due to ancient glibc that still has
memcpy/memset inlines.
This
--- Comment #6 from simon_baldwin at yahoo dot com 2008-08-07 14:42 ---
Fixed for mainline and 4.3 branch -- resolving as FIXED.
--
simon_baldwin at yahoo dot com changed:
What|Removed |Added
--- Comment #5 from hjl dot tools at gmail dot com 2008-08-07 14:52 ---
(In reply to comment #4)
Subject: Re: [4.4 Regression] Revision 138835 breaks bootstrap
Hi,
thanks for testcase, for some reason it does not reproduce on our
testing setup, probably due to ancient glibc that
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-08-07 14:56 ---
Subject: Bug 37048
Author: hubicka
Date: Thu Aug 7 14:55:32 2008
New Revision: 138841
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138841
Log:
PR target/37048
* i386.md (single stringop
--- Comment #4 from schwab at suse dot de 2008-08-07 15:19 ---
Because the result of FooBar(two) is an rvalue, but test1 is an lvalue.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #13 from manu at gcc dot gnu dot org 2008-08-07 15:22 ---
Unsubscribing: not sure what is to fix here.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-07 15:25 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jamborm at gcc dot gnu dot org 2008-08-07 15:49 ---
Unfortunately, I got a fortran regression:
/abuild/mjambor/iinln/gcc/testsuite/gfortran.dg/char_cast_1.f90:24: internal
com
piler error: in expand_call_inline, at tree-inline.c:3117
The assert is gcc_assert
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-08-07 16:00 ---
Interesting. I may have a look into the CCP problem.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
[EMAIL PROTECTED] gcc]$ cat /tmp/push-1.c
/* { dg-do compile { target { { i?86-*-* x86_64-*-* } ilp32 } } } */
/* { dg-options -w -msse2 -Os } */
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
extern void foo (__m128 x, __m128 y ,__m128 z ,__m128 a, int size);
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-07 16:38 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00204.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from aesok at gcc dot gnu dot org 2008-08-07 16:53 ---
The gcc.dg/debug/dwarf2/dwarf-die3.c testcase FALL on x86_64-unknown-linux-gnu
also.
Anatoliy
--
aesok at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2008-08-07
17:12 ---
Subject: Re: /bin/sh: line 1: 26087 Aborted (core dumped) ./xsinfo
../../sinfo.h
Right, and xeinfo is built with your base compiler. I'd try with an older
or more recent base GNAT version. It's more
--- Comment #7 from hjl dot tools at gmail dot com 2008-08-07 17:23 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-07 18:58 ---
Created an attachment (id=16037)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16037action=view)
A testcase
/export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc
--- Comment #6 from schilds at sun dot ac dot za 2008-08-07 19:07 ---
This is a serious bug, make no mistake. It causes existing Fortran 77 code to
fail. It's wasted a lot of my time and, no doubt, a lot of other, good peoples'
too.
The print*, (or write(*,*)) statement certainly _IS_
--- Comment #2 from hjl dot tools at gmail dot com 2008-08-07 19:09 ---
The problem is -E never generates any debug info. So __GCC_HAVE_DWARF2_CFI_ASM
won't be defined for -E and PCH gets a mismatch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37033
Since I am unable to bootstrap gcc-4.3.1 using the Sun cc compiler (see bug
Bug#: 33304), I attempted to compile using Sun's version of gcc
(http://cooltools.sunsource.net/gcc/). This does not work either. The
configure fails in the sparc-sun-solaris2.10/libgcc directory.
The version of gcc
--- Comment #7 from burnus at gcc dot gnu dot org 2008-08-07 19:48 ---
The print*, (or write(*,*)) statement certainly _IS_ standard Fortran 77 and
its ubiquitousness should make fixing this bug a priority.
The * is standard Fortran 66 to 2008, however, its interpretation was not
--- Comment #3 from rth at gcc dot gnu dot org 2008-08-07 20:07 ---
Subject: Bug 37033
Author: rth
Date: Thu Aug 7 20:06:36 2008
New Revision: 138850
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138850
Log:
PR debug/37033
* gcc.c (cpp_options): Pass along -g*.
--- Comment #4 from rth at gcc dot gnu dot org 2008-08-07 20:11 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #9 from tromey at gcc dot gnu dot org 2008-08-07 20:28 ---
See this note for some details on the semantics of this warning,
with respect to keywords:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00808.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21759
--- Comment #1 from pault at gcc dot gnu dot org 2008-08-07 21:23 ---
Daniel,
By golly, I never even thought of that possibility. Thanks!
I'll fix it as obvious as soon as I can.
Paul
PS Could you please CC me next time? I do not have ove much time for hacking
right now. I either
--- Comment #2 from tromey at gcc dot gnu dot org 2008-08-07 21:33 ---
This works in 4.3, probably due to the switch to mapped locations.
I didn't try anything earlier.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-08-07 21:40 ---
Could you please CC me next time?
Thought I did, I Surely wanted to?!
Please excuse the oversight :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37011
I have been encountering random failures when running ECJ 3.4. ECJ 3.3 works
fine and I did also encounter random failures with Sun's VM so I initially
filed a bug at eclipse.org. However, further tests have indicated that there
are two different issues here, one affecting GCJ and one affecting
gcc -save-temps -v -O2 -fomit-frame-pointer -c testreloads.c
Dropping optimization from -O2 to -O1 or dropping -fomit-frame-pointer allows
this to succeed.
Using built-in specs.
Target: m68k-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-8'
--- Comment #1 from stephen at marenka dot net 2008-08-08 00:46 ---
Created an attachment (id=16038)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16038action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37052
--- Comment #2 from stephen at marenka dot net 2008-08-08 00:47 ---
Created an attachment (id=16039)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16039action=view)
reduced source from hdf5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37052
gcc -fpic -O1 -c postreload.c
Dropping optimization from -O1 to -O0 or dropping -fpic allows this to succeed.
Using built-in specs.
Target: m68k-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-8'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--- Comment #1 from stephen at marenka dot net 2008-08-08 01:02 ---
Created an attachment (id=16040)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16040action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
--- Comment #2 from stephen at marenka dot net 2008-08-08 01:02 ---
Created an attachment (id=16041)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16041action=view)
reduced source from r-base
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
When I try to build gnustep-base I get undefined reference to
`objc_exception_throw'
apparently it is missing in libobjc.def
--
Summary: undefined reference to `objc_exception_throw'
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity:
--- Comment #3 from contact at multimedia dot cx 2008-08-08 03:25 ---
Created an attachment (id=16042)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16042action=view)
Preprocessor output for file that is crashing compiler
As requested, this is the preprocessed output when adding
-Os (test for excess errors)
WARNING: gcc.dg/torture/fp-int-convert-timode.c -Os compilation failed to
produce executable
These all fail with errors of the form...
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20080807/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20080807
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-08 05:13 ---
bash-3.2$ cat /tmp/x.i
unsigned
foo (double d)
{
return d;
}
bash-3.2$ ./xgcc -B./ -msse2 -mfpmath=sse -S /tmp/x.i -Os -m32
/tmp/x.i: In function foo:
/tmp/x.i:3: internal compiler error: in emit_unop_insn,
67 matches
Mail list logo
