Am Thursday 03 September 2009 00:04:43 schrieb Paolo Bonzini:
*) The stack alignment code + msvc_prologue is used by Wine on osx though.
...
I don't think this would prevent the patch from getting the patch in.
Ok, I'll read the patch contribution guidelines again and hope for the best.
I don't know, I was just reworking Stefan's patch. He didn't include
function names (-p) in the patch so I don't know what function this is
part of.
It was ix86_handle_abi_attribute. I'm usually using git, and don't like cvs
and svn too much. It seems svn diff doesn't support a -p option here.
On Wed, Sep 02, 2009 at 11:08:19PM -0600, Ryan Hill wrote:
On Fri, 24 Jul 2009 09:51:07 -0600
Tom Tromey tro...@redhat.com wrote:
Basile == Basile STARYNKEVITCH bas...@starynkevitch.net writes:
Basile Shouldn't a python script for gdb be installed outside of a
directory
Basile
uname -prs
Darwin 8.11.0 powerpc
Updating SVN tree
At revision 151374.
config:
../gcc-4-5-regtest/configure --prefix=/Volumes/ScratchCS/gcc-4-5-
install --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --
build=powerpc-apple-darwin8 --enable-languages=c,objc,c++,obj-c+
+,fortran
Both. By my reading the ABI you're trying to implement does not provide
the guarantees required to use iwmmxt instructions. There are ways around
this, but none of them are simple or pretty. The simplest answer is
don't do that.
Hi Paul,
Thanks for the answer, but I'm not sure what
As we've got quite some build problems on some targets and we clashed
with VTA, free-lang-data, expand and scheduler changes it's a good
time to slush the trunk for a short time.
Thus, starting from now the trunk is in regression and documentation
fixes only mode.
Please help sorting out issues
On Wed, Sep 2, 2009 at 16:06, Basile
STARYNKEVITCHbas...@starynkevitch.net wrote:
Hello All,
My feeling is that the Link Time Optimisation (LTO) effort should be soon
(=is expected to be, or is already) merged inside GCC trunk (future 4.5).
Several years ago, I asked if there is any
On Thu, Sep 3, 2009 at 09:09, Basile
STARYNKEVITCHbas...@starynkevitch.net wrote:
I hope that does not mean that gcc has switched mysteriously from stage 1 to
stage 3 (or even stage 2).
No. We freeze trunk when it crosses specific pain thresholds.
I am extremly interested in having the
Filed as PR 41245.
FX
Hello all,
I am doing a port for a 32bit target in GCC 4.4.0. Of the addressing
modes that are allowed by my target the one with (base register +
offset) is restrictive in QImode. The restriction is that if the base
register is not Stack Pointer then this kind of address cannot come in
a load
Hi,
Oh, I was wrong previously, gcc does respect __attribute__
((__regparm__ (3))) flag (I forget to add -Os so it still uses stack
to store value). And the bug is still there ! Try this test program:
I confirm with gcc-4.4
This is a grave problem then. This check was added by Marco Gerards
Alex,
With your VTA merge, you added the -gtoggle switch. I've read the
documentation for it and while I can parse what it says, I have no
idea what this flag is useful for. I've seen it used during
bootstraps and the documentation claims something about
-fcompare-debug. But I cannot imagine
Mohamed Shafi wrote:
The restriction is that if the base
register is not Stack Pointer then this kind of address cannot come in
a load instruction but only in store instruction.
To implement this i added constrains for all supported memory
operations in QImode. So the pattern is as
On 09/03/09 09:44, Dave Korn wrote:
Mohamed Shafi wrote:
The restriction is that if the base
register is not Stack Pointer then this kind of address cannot come in
a load instruction but only in store instruction.
To implement this i added constrains for all supported memory
operations
#includestdio.h
void foo (int a, int b, void (*hook) (int aa, int bb, int cc))
{
b += a;
hook (a, b, a + b);
}
void qq (int a)
{
auto void q1 (int aa, int bb, int cc);
void q1 (int aa, int bb, int cc)
{
printf (%d %d %d\n, a, aa + bb, cc);
}
foo (a, a + 1, q1);
}
int
Diego,
In fact, it'd be nice to hide some other flags, but that's another problem.
Absolutely, I think the user flags should be well separated from the
developer ones.
Cheers
Dominique
On Thu, Sep 3, 2009 at 5:54 PM, Paolo Bonzinibonz...@gnu.org wrote:
#includestdio.h
void foo (int a, int b, void (*hook) (int aa, int bb, int cc))
{
b += a;
hook (a, b, a + b);
}
void qq (int a)
{
auto void q1 (int aa, int bb, int cc);
void q1 (int aa, int bb, int cc)
{
Hello Jakub,
* Jakub Jelinek wrote on Thu, Sep 03, 2009 at 10:51:42AM CEST:
On Wed, Sep 02, 2009 at 11:08:19PM -0600, Ryan Hill wrote:
I was just wondering if there was any consensus among distros about where to
move these. We cannot keep the .py files in the location they're currently
On Sep 3, 2009, Diego Novillo dnovi...@google.com wrote:
With your VTA merge, you added the -gtoggle switch.
Not really:
gcc/ChangeLog:
2009-06-08 Alexandre Oliva aol...@redhat.com
^^
* common.opt (fcompare-debug=, fcompare-debug-second): New.
(fdump-final-insns=,
Az alabbi linket kuldtek Neked:
http://useurl.us/6ab
Snapshot gcc-4.5-20090903 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090903/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Can someone tell me how to debug this:
splitting
/home/rth/work/gcc/bld-sjlj/gcc/testsuite/ada/acats0/tests/c3/c35502i.ada into:
c35502i.adb
BUILD c35502i.adb
gnatmake --GCC=/home/rth/work/gcc/bld-sjlj/gcc/xgcc -B/home/rth/work/gcc/bld-sjlj/gcc/
-gnatws -O2
On Aug 27, 2009, Jason Merrill ja...@redhat.com wrote:
On 08/15/2009 10:12 AM, Jerry Quinn wrote:
Building with --enable-build-with-cxx fails to bootstrap as follows:
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh_alloc.o differs
...
Do you know why r149964 makes a difference?
No
Richard Henderson wrote:
Can someone tell me how to debug this:
splitting
/home/rth/work/gcc/bld-sjlj/gcc/testsuite/ada/acats0/tests/c3/c35502i.ada
into:
c35502i.adb
BUILD c35502i.adb
gnatmake --GCC=/home/rth/work/gcc/bld-sjlj/gcc/xgcc
-B/home/rth/work/gcc/bld-sjlj/gcc/ -gnatws -O2
If you pass -v to gnatmake, it will output the gcc invocations.
This should be sufficient to find the problem.
Basically, just go to the directory containing c35502i.adb, and
execute the gnatmake command as listed below, with -v added in.
If you only have the 35502i.ada file available, use
Is this a well know problem:
/usr/local/src/trunk/objdir/./gcc/xgcc
-B/usr/local/src/trunk/objdir/./gcc/
-B/usr/local/gnu/i686-pc-cygwin/bin/
-B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem /
usr/local/gnu/i686-pc-cygwin/include -isystem
/usr/local/gnu/i686-pc-cygwin/sys-include-c -g -O2 -W
--- Comment #1 from jv244 at cam dot ac dot uk 2009-09-03 06:46 ---
this is now failing at '-O2 -g' with current trunk.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #3 from jv244 at cam dot ac dot uk 2009-09-03 06:48 ---
gfortran -c -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -g
bug.f90
now fails.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #12 from jv244 at cam dot ac dot uk 2009-09-03 06:50 ---
looks like this is fixed on trunk.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #4 from d dot g dot gorbachev at gmail dot com 2009-09-03
06:51 ---
Created an attachment (id=18469)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18469action=view)
Patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41214
--- Comment #1 from burnus at gcc dot gnu dot org 2009-09-03 06:55 ---
Thomas, I think do to your changes one now gets a warning (unused argument) for
libgfortran/intrinsics/unpack_generic.c.
The last argument of unpack_internal (index_type fsize) is no longer used; as
the function is
--- Comment #30 from dominiq at lps dot ens dot fr 2009-09-03 07:09 ---
This is a regression from gcc 4.3.4 (gfc=trunk r151295, gfc44=4.4.1,
gfc43=4.3.4):
[ibook-dhum] test/dbg_air% gfc -S -m64 -O2 -funsafe-math-optimizations
air_db.f90
--- Comment #4 from jpr at csc dot fi 2009-09-03 07:10 ---
FWIW: I had a look at the -fdump-tree-all files.
All seems well (to my untrained eyes), until
bb 8:
D.1412_51 = y;
D.1430_52 = D.1412_51 * 2.0e+0;
z = D.1430_52;
in m.f90.060t.phiprop
is transformed to
bb 8:
D.1412_51
--- Comment #2 from burnus at gcc dot gnu dot org 2009-09-03 07:12 ---
Nightstrike: I do not understand
libgfortran/intrinsics/getlog.c:85:3: warning: implicit declaration of
function getlogin
There is a
#if defined __MINGW32__
--- Comment #14 from bonzini at gnu dot org 2009-09-03 07:27 ---
Can you also try with 4.5?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2009-09-03 07:36 ---
Subject: Bug 41219
Author: burnus
Date: Thu Sep 3 07:36:36 2009
New Revision: 151371
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151371
Log:
2009-09-03 Tobias Burnus bur...@net-b.de
PR
At revision 151371 I get an RTL checking failure compiling libgcc:
/home/eric/build/gcc/native32/./gcc/xgcc -B/home/eric/build/gcc/native32/./gcc/
-B/home/eric/install/gcc/i586-suse-linux/bin/
-B/home/eric/install/gcc/i586-suse-linux/lib/ -isystem
/home/eric/install/gcc/i586-suse-linux/include
Bootstrap fails on powerpc-apple-darwin9 due to a revision between 151343 and
151349 (see http://gcc.gnu.org/ml/gcc-regression/2009-09/msg00024.html):
/opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/
-B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/bin/
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-09-03 08:14
---
Created an attachment (id=18470)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18470action=view)
Reduced testcase.
To be compiled at -O -g with an --enable-checking=yes,rtl compiler.
--
This ICE breaks alpha bootstrap, it can be reproduced with (to be) attached
preprocessed source on a cross from x86_64-pc-linux-gnu to alpha-linux-gnu.
~/gcc-build-alpha/gcc/cc1 -quiet -O2 -g -mlong-double-128 libgcc2.i
../../../gcc-svn/trunk/libgcc/../gcc/libgcc2.c: In function '__divtc3':
--- Comment #1 from ubizjak at gmail dot com 2009-09-03 08:21 ---
Created an attachment (id=18471)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18471action=view)
libgcc2 preprocessed source
Fails with -g in __divtc3, compiles OK without.
--
This testcase distilled from postgresql fails at runtime on s390x-linux with
-O2 -march=z9-109 -mtune=z10:
/* { dg-do run } */
/* { dg-options -O2 } */
/* { dg-options -O2 -march=z9-109 -mtune=z10 { target s390x-linux } } */
struct S
{
short nargs;
unsigned long arg[2];
};
extern void abort
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-03 08:36 ---
The getlogin function is getting prototyped in headers only, if the _POSIX
define was set. So a bug-fix here would be for w64 to define before including
headers the _POSIX macro.
Cheers,
Kai
--
--- Comment #9 from ubizjak at gmail dot com 2009-09-03 08:47 ---
You can just copy relevant entry from gcc-cvs ml:
Author: jamborm
Date: Wed Sep 2 17:52:18 2009
New Revision: 151345
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151345
Log:
2009-09-02 Martin Jambor
--- Comment #7 from ubizjak at gmail dot com 2009-09-03 08:53 ---
(In reply to comment #3)
Hmm, dropping the stmt looks like it would be a hack. Alex - if I just set
flag_var_tracking_assignments to 1 if I encounter a GIMPLE_DEBUG during
read-in
I get
t.c: In function 'foo':
--- Comment #3 from razya at gcc dot gnu dot org 2009-09-03 08:59 ---
Subject: Bug 38275
Author: razya
Date: Thu Sep 3 08:59:25 2009
New Revision: 151372
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151372
Log:
PR tree-optimization/38275
* tree-parloops.c
--- Comment #4 from razya at gcc dot gnu dot org 2009-09-03 09:14 ---
(In reply to comment #3)
Subject: Bug 38275
Author: razya
Date: Thu Sep 3 08:59:25 2009
New Revision: 151372
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151372
Log:
PR tree-optimization/38275
--- Comment #1 from jakub at gcc dot gnu dot org 2009-09-03 09:24 ---
sched-deps.c uses may_trap_p only to find out what insns can't be speculated,
possibly trapping MEMs are handled by deps_may_trap_p.
I wonder what exactly we want to forbid to cure this testcase.
Just
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-09-03 09:24 ---
This issue is solved for mingw-w64 runtime. It uses no more the mingwm10.dll
mechanism. Instead it uses TLS callbacks to implement it. By this reason the
Cleaning of Exception Contexts is always present for this
--- Comment #5 from razya at gcc dot gnu dot org 2009-09-03 09:27 ---
Fixed for GCC4.5
--
razya at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from razya at gcc dot gnu dot org 2009-09-03 09:39 ---
(In reply to comment #6)
Submited the correct fix:
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00277.html
Committed for GCC4.5
http://gcc.gnu.org/viewcvs?view=revisionrevision=151373
--
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-03 09:51 ---
parm_decl 0x72aca750 c
type real_type 0x72ab1000 TFtype sizes-gimplified TF
size integer_cst 0x72debc00 constant 128
unit size integer_cst 0x72debc30 constant 16
align 128
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-03 10:06 ---
Looking at it, vt_find_parameters has been doing this even before VTA merge,
thinking the low bits of the argument are in $19 instead of where that register
points. At least in 4.4 cross to sparc64-linux for -m32
--- Comment #3 from sezeroz at gmail dot com 2009-09-03 10:10 ---
The discussion thread at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00778.html still haven't provide a
solution for this one even after the recent build system changes.. Will md5.h,
splay-tree.h and sha1.h be modified
--- Comment #8 from rguenther at suse dot de 2009-09-03 10:25 ---
Subject: Re: [LTO] Segfault using -flto with
-fvar-tracking-assignments
On Wed, 2 Sep 2009, rmansfield at qnx dot com wrote:
--- Comment #6 from rmansfield at qnx dot com 2009-09-02 22:50 ---
(In reply to
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-03 10:31 ---
We can never move maybe trapping instructions across a function call that might
not return (and as we don't have an attribute for returns_always we have to
assume that a function may not return always apart from
--- Comment #5 from jpr at csc dot fi 2009-09-03 10:40 ---
Adding -fstrict-aliasing to -O1 breaks the code:
gfortran -o m m.f90 -O1; ./m
y= 0.60653065945526063 2*y= 1.2130613189105213
gfortran -o m m.f90 -O1 -fstrict-aliasing ; ./m
y= 0.60653065945526063 2*y=
--- Comment #4 from ramana at gcc dot gnu dot org 2009-09-03 11:03 ---
Confirmed with rev 151319
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from joseph at codesourcery dot com 2009-09-03 11:04
---
Subject: Re: can not build gcc 4.4.1 on Snow Leopard
Mac OS X 10.6
On Thu, 3 Sep 2009, howarth at nitro dot med dot uc dot edu wrote:
Mike,
Regarding passing -m32 within the x86_64 host case, I was
As of 20090903 (rev. 151371), mainline fails to bootstrap while building the
N64
stage1 libgcc on IRIX 6.5:
vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c: In function '__lshrti3':
/vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c:431:1: error: unrecognizable
insn:
(debug_insn 14 13 15 3 /vol/gcc/src
--- Comment #1 from redi at gcc dot gnu dot org 2009-09-03 11:16 ---
You didn't say how you configured it.
As with bug 40950, you might need --enable-stage1-languages=c,c++
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41234
--- Comment #1 from ubizjak at gmail dot com 2009-09-03 11:17 ---
get_attr_* does not work with DEBUG_INSN instructions. Backtrace will tell you
where to put NONDEBUG_INSN_P instead of INSN_P.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41240
--- Comment #31 from dominiq at lps dot ens dot fr 2009-09-03 11:20 ---
More reduced nonfunctional (invalid) test to show the problem:
IMPLICIT REAL*8(a-H,O-Z)
PARAMETER (NX=150,NY=150)
DIMENSION NPX(30), FV2(NX,NY), T(NX,NY), dtt(NX,NY)
do it = 1, 2000
--- Comment #2 from ubizjak at gmail dot com 2009-09-03 11:24 ---
FYI, similar failure happens on alpha, fixed by:
Index: config/alpha/alpha.c
===
--- config/alpha/alpha.c(revision 151367)
+++ config/alpha/alpha.c
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|VTA: SSA name in freelist
--- Comment #1 from redi at gcc dot gnu dot org 2009-09-03 11:27 ---
*** This bug has been marked as a duplicate of 40664 ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from redi at gcc dot gnu dot org 2009-09-03 11:27 ---
*** Bug 41231 has been marked as a duplicate of this bug. ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from redi at gcc dot gnu dot org 2009-09-03 11:35 ---
Your testcase works for me.
Please see http://gcc.gnu.org/bugs.html for the information you need to
provide, specifically you haven't said how you configured gcc or what command
you're using to compile the testcase.
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-09-03 11:40 ---
This looks like your restrict changes get in the way. We have
y_13 = (real(kind=8) restrict) y;
..
*y_13 = D.1416_35;
...
D.1412_51 = y;
so one access via the plain y gets re-introduced by forwprop somehow
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41237
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||aoliva at gcc dot gnu dot
|
At revision 151371 I get a bootstrap comparison failure on i586 with the
default compiler (--enable-checking=yes):
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/cfgloopmanip.o differs
gcc/ada/sem_res.o
When compiling the following code, gfortran does not correctly recognize a
procedure pointer and crashes with the following message:
no_func.f90:59.12:
n_in = prc_lib% get_n_in (2)
1
Error: 'prc_lib' at (1) is not a function
I attach the code and also as attachment:
module
--- Comment #4 from jakub at gcc dot gnu dot org 2009-09-03 11:58 ---
Created an attachment (id=18472)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18472action=view)
gcc45-pr41238.patch
Here is an untested fix (well, tested on the provided testcase, but nothing
else). The
--- Comment #1 from reuter at physik dot uni-freiburg dot de 2009-09-03
11:58 ---
Created an attachment (id=18473)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18473action=view)
Test file for the bug report
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41242
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-03 12:40 ---
Oh, just curious - if you disable address space randomization, does the build
succeed? (echo 0 /proc/sys/kernel/randomize-va-space)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2009-09-03
12:45 ---
Subject: Re: [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455
building stage1 N64 libgcc
--- Comment #1 from ubizjak at gmail dot com 2009-09-03 11:17 ---
get_attr_* does not
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-03 13:06 ---
Created an attachment (id=18474)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18474action=view)
gcc45-pr41236.patch
Either this, or just using XEXP (rtl, 0) instead of SUBREG_REG (rtl). This is
only RTL
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-03 13:06 ---
I get different .text sizes for _umoddi3_s.o:
- Start of section headers: 676 (bytes into file)
+ Start of section headers: 684 (bytes into file)
...
- [ 1] .text PROGBITS
--- Comment #5 from ubizjak at gmail dot com 2009-09-03 13:08 ---
(In reply to comment #3)
I'm sort of stuck now.
Add -save-temps to failing command on a native compiler, create a crosscompiler
on i.e. x86_64 and debug ../gcc/cc1 from crosscompiler with -O2 -g
some_file.i in x86_64
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2009-09-03
13:09 ---
Subject: Re: [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455
building stage1 N64 libgcc
--- Comment #4 from jakub at gcc dot gnu dot org 2009-09-03 13:03 ---
Just try latest
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-03 12:32 ---
I see similar failure with r151376 on x86_64 with the 32bit multilibs. Trying
to reproduce now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-03 13:19 ---
I get different code with two invocations of stage2 gcc. -g is needed, and
you have to be lucky with address space randomization.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
On Linux/ia32 and Linux/x86-64, I got random
compare failures during bootstrap:
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
x86_64-unknown-linux-gnu/32/libgcc/_umoddi3.o
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-03 13:35 ---
That still assumes that inside of SIGN_EXTEND/ZERO_EXTEND is a REG, which isn't
always the case. Testing with loc_descriptor call there instead now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41236
In attached code:
in find(), generated code computes offset using multiplication/division.
in set(), generated code computes data[10] and compares data[i] with that (to
verify find() fails to be optimised because of overflow rules)
tested gcc: 4.3.4, 4.4.1, 4.5.0-alpha20090827
command line:
gcc
--- Comment #1 from zsojka at seznam dot cz 2009-09-03 13:50 ---
Created an attachment (id=18475)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18475action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41244
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2009-09-03
13:53 ---
Subject: Re: [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455
building stage1 N64 libgcc
--- Comment #5 from ubizjak at gmail dot com 2009-09-03 13:08 ---
(In reply to comment
--- Comment #7 from hjl dot tools at gmail dot com 2009-09-03 13:54 ---
*** Bug 41243 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2009-09-03 13:54 ---
*** This bug has been marked as a duplicate of 41241 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #8 from hjl dot tools at gmail dot com 2009-09-03 13:56 ---
It may be caused by VTA merge. I also got random compare failures.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Subject says it all; i386-apple-darwin is a primary platform.
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/tree.o differs
The output of ../trunk/contrib/compare-debug --preserve stage[23]-gcc/tree.o
is long, so I'll attach it, but the end of it
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-03 14:12 ---
Because the index arithmetic is done unsigned.
return (int) ((unsigned int) i * 212) /[ex] 212;
We lost the information that i * 212 cannot overflow.
Simpler testcase:
extern int data[];
int find(int i)
{
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-09-03 14:13 ---
-g is not needed after all. It's just very random.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|VTA: bootstrap failure, ICE |[4.5 Regression] VTA:
|in loc_cmp, at var-
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2009-09-03 14:19
---
I can confirm I can reproduce this bug with an darwin-to-mingw cross-compiler,
and running the executable under wine.
I can also confirm that it's about the REWIND statement: if you have already
run the test
--- Comment #10 from hjl dot tools at gmail dot com 2009-09-03 14:25
---
I got my first compare failure at revision 151353.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2009-09-03 14:40
---
It's because of this in gcc/config/i386/mingw-w64.h:
#define ASM_SPEC %{v:-V} %{n} %{T} %{Ym,*} %{Yd,*} \
%{Wa,*:%*} %{m32:--32} %{m64:--64}
The %{v:-V} part is what's triggering what you see. Now, the
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-09-03 14:51
---
Created an attachment (id=18476)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18476action=view)
testcase
testcase, _umoddi_s.i from libgcc2.c
valgrind ./cc1 -quiet -O2 -m32 t.i
==1232== Invalid read of
--- Comment #12 from vmakarov at redhat dot com 2009-09-03 15:01 ---
It looks as an old IRA rare hidden bug which was triggered by the new patches.
I check IRA on valgrind on a lot of tests but never saw it.
Update_equiv_reg imported from the old RA uses pseudo class but it was never
1 - 100 of 175 matches
Mail list logo
