On 04/18/2010 10:35 PM, Ben Gamari wrote:
On Sun, 18 Apr 2010 21:19:19 -0700, Justin Mattockjustinmatt...@gmail.com
wrote:
so far I've compiled most of the system
(glibc,Xserver,etc..)
and not really anything has crashed and burned
except for the kernel:
You are using a pre-release
On 04/19/2010 02:43 PM, Justin P. Mattock wrote:
I couldn't resist..(had to play),
anyways I looked through the reports
but didn't see anything that was
familiar. so I went and created an entry:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791
Thanks. Please add a preprocessed source file so
On 04/18/2010 11:57 PM, Jie Zhang wrote:
On 04/19/2010 02:43 PM, Justin P. Mattock wrote:
I couldn't resist..(had to play),
anyways I looked through the reports
but didn't see anything that was
familiar. so I went and created an entry:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791
Thanks.
On Mon, Apr 19, 2010 at 7:04 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
Mark Mitchell wrote:
The Free Software Foundation and the GNU Compiler Collection (GCC)
development team have released GCC 4.5.0. [...]
It is really unfortunate the annoucement did not mention plugins,
On Mon, Apr 19, 2010 at 10:50:48AM +0200, Richard Guenther wrote:
On Mon, Apr 19, 2010 at 7:04 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
Mark Mitchell wrote:
The Free Software Foundation and the GNU Compiler Collection (GCC)
development team have released GCC 4.5.0. [...]
On Mon, Apr 19, 2010 at 02:13:52AM +0100, Dave Korn wrote:
/gnu/gcc/gcc/libjava/classpath/javax/swing/plaf/basic/BasicLookAndFeel.java:483:0:
note: variable tracking size limit exceeded with
-fvar-tracking-assignments, retrying without
Re-running the build command manually spins CPU
Hi,
My architecture supports instructions with two parallel side effects.
For example, addition and subtraction can be done in parallel:
(define_insn assi6
[(parallel [
(set (match_operand:SI 0 register_operand =r)
(minus:SI (match_operand:SI 1 register_operand r)
consider :
typedef int INT1 ;
int func (INT1 x) ;
now if I am in grokparms() parsing INT1 x and I want to issue a
nice diagnostic for x...
I can't seem to find the right magic that gets me back to that DECL
for INT1
(I actually want any attributes attached to it and an
On Mon, Apr 19, 2010 at 3:03 PM, IainS develo...@sandoe-acoustics.co.uk wrote:
consider :
typedef int INT1 ;
int func (INT1 x) ;
now if I am in grokparms() parsing INT1 x and I want to issue a nice
diagnostic for x...
I can't seem to find the right magic that gets me back to
On 19 April 2010 15:03, IainS develo...@sandoe-acoustics.co.uk wrote:
consider :
typedef int INT1 ;
int func (INT1 x) ;
now if I am in grokparms() parsing INT1 x and I want to issue a nice
diagnostic for x...
Can I ask what you mean by a nice diagnostic? and what you want to use
On Mon, Apr 19, 2010 at 11:23:35AM +0200, Basile Starynkevitch wrote:
...
I am not a native english speaker, but something like the following
paragraph [to be added after the paragraph: GCC 4.5.0 is now capable
of link-time optimization. ... and equally significant reductions in
code size.]
On 19 Apr 2010, at 14:18, Manuel López-Ibáñez wrote:
On 19 April 2010 15:03, IainS develo...@sandoe-acoustics.co.uk
wrote:
consider :
typedef int INT1 ;
int func (INT1 x) ;
now if I am in grokparms() parsing INT1 x and I want to issue a
nice
diagnostic for x...
Can I ask
Basile Starynkevitch wrote:
It is really unfortunate the annoucement did not mention plugins,
another major feature of GCC. Why ?
I consider plug-ins an important feature for the future of GCC. I gave
a talk this past week as the Linux Foundation Collaboration Summit in
which I made the case
Hi,
Now that GCC is in the stage1 and gc-improv branch work is finished as
I see it, I propose to merge it to mainline.
The goal of the branch is to make the type of GC-allocated objects
known to GC at allocation time, by changing the allocation interface
from
foo *x = (foo *)ggc_alloc (sizeof
On 04/19/10 06:58, Frank Isamov wrote:
Hi,
My architecture supports instructions with two parallel side effects.
For example, addition and subtraction can be done in parallel:
(define_insn assi6
[(parallel [
(set (match_operand:SI 0 register_operand =r)
(minus:SI
Laurynas Biveinis wrote:
Hi,
Now that GCC is in the stage1 and gc-improv branch work is finished as
I see it, I propose to merge it to mainline.
The goal of the branch is to make the type of GC-allocated objects
known to GC at allocation time, by changing the allocation interface
from
foo *x =
2010/4/19 Basile Starynkevitch bas...@starynkevitch.net:
Laurynas Biveinis wrote:
The goal of the branch is to make the type of GC-allocated objects
known to GC at allocation time, by changing the allocation interface
from
foo *x = (foo *)ggc_alloc (sizeof (x));
to
foo *x = ggc_alloc_foo
Mark Mitchell wrote:
Basile Starynkevitch wrote:
It is really unfortunate the annoucement did not mention plugins,
another major feature of GCC. Why ?
I consider plug-ins an important feature for the future of GCC. I gave
a talk this past week as the Linux Foundation Collaboration Summit in
On 19 April 2010 18:34, Basile Starynkevitch wrote:
Note [*]: are we sure that other announced features, like Link Time
Optimization, are *easily* usable by *ordinary* GCC users? I don't know, and
I am not sure... Perhaps most ordinary users only know about -O1 or -O3...
Well, yes, because
On 19 April 2010 08:20, Justin P. Mattock wrote:
On 04/18/2010 11:57 PM, Jie Zhang wrote:
On 04/19/2010 02:43 PM, Justin P. Mattock wrote:
I couldn't resist..(had to play),
anyways I looked through the reports
but didn't see anything that was
familiar. so I went and created an entry:
On 04/19/2010 02:17 PM, Jonathan Wakely wrote:
On 19 April 2010 08:20, Justin P. Mattock wrote:
On 04/18/2010 11:57 PM, Jie Zhang wrote:
On 04/19/2010 02:43 PM, Justin P. Mattock wrote:
I couldn't resist..(had to play),
anyways I looked through the reports
but didn't see anything that was
On 19/04/2010 15:31, Mark Mitchell wrote:
But, I don't think that plug-ins are yet a useful thing to announce in
what is essentially a marketing context. Most users won't be able to
use them yet. We have some infrastructure; we don't have a lot of use
of that infrastructure yet.
Well, to
--- Comment #5 from irar at gcc dot gnu dot org 2010-04-19 06:02 ---
Subject: Bug 43771
Author: irar
Date: Mon Apr 19 06:02:27 2010
New Revision: 158503
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158503
Log:
PR tree-optimization/43771
* tree-vect-slp.c
--- Comment #6 from irar at gcc dot gnu dot org 2010-04-19 06:18 ---
Subject: Bug 43771
Author: irar
Date: Mon Apr 19 06:17:56 2010
New Revision: 158504
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158504
Log:
PR tree-optimization/43771
* tree-vect-analyze.c
building the latest kernel(2.6.34-rc4-00082-g250541f)
I'm hitting this:
kernel/rtmutex.c: At top level:
kernel/rtmutex.c:1138:1: internal compiler error: in
cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009
Please submit a full bug report,
with preprocessed source if appropriate.
--- Comment #11 from jakub at gcc dot gnu dot org 2010-04-19 07:02 ---
This change broke building wine on x86-64. Distilled testcase:
__attribute__ ((ms_abi)) fn2 (int, int);
struct S { int s; };
struct T { int t; struct S *u; };
void
foo (struct T *x, void *y)
{
int a, b, c, d;
--- Comment #12 from jakub at gcc dot gnu dot org 2010-04-19 07:03 ---
Forgot to say this is on the 4.4 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43562
--- Comment #13 from jakub at gcc dot gnu dot org 2010-04-19 07:07 ---
Ah, that is PR43662.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jakub at gcc dot gnu dot org 2010-04-19 07:10 ---
I don't think llp64 there would be very much helpful, then all functions are
ms_abi and thus no ABI changes in between functions and no ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43662
--- Comment #1 from justinmattock at gmail dot com 2010-04-19 07:13 ---
Created an attachment (id=20414)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20414action=view)
kernel .config
here is my .config I used to hit this error,
and FWIW here is my compile flags that I used for
The below at the bottom of this comment gives:
/usr/local/bin/g++ -v -save-temps -std=gnu++0x -o
CMakeFiles/gccError.dir/gccError.cpp.o -c
/home/darlingm/code.gccerror/testing/gccError/gccError.cpp
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
--- Comment #1 from darlingm at gmail dot com 2010-04-19 07:23 ---
(bad refresh)
*** This bug has been marked as a duplicate of 43790 ***
--
darlingm at gmail dot com changed:
What|Removed |Added
--- Comment #1 from darlingm at gmail dot com 2010-04-19 07:23 ---
*** Bug 43792 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43790
--- Comment #2 from jiez at gcc dot gnu dot org 2010-04-19 07:24 ---
Justin,
You can add V=1 when make linux kernel. Then you can find the command line used
to compile rtmutex.c. Change -c in the command line to -E and return the
command line. Rename the resulted rtmutex.o to rtmutex.i
--- Comment #11 from jiez at gcc dot gnu dot org 2010-04-19 07:24 ---
Thanks all. This is the updated patch:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01157.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43662
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #7 from irar at il dot ibm dot com 2010-04-19 07:48 ---
Fixed on 4.6, 4.5 and 4.4.
--
irar at il dot ibm dot com changed:
What|Removed |Added
A recent regression on CP2K for
gcc version 4.6.0 20100419 (experimental) [trunk revision 158504] (GCC)
with the attached testcase and 'gfortran -c -fbounds-check':
1075.f90: In function sparse_alltoall:
1075.f90:544:0: internal compiler error: tree check: expected tree that
contains decl
--- Comment #1 from jv244 at cam dot ac dot uk 2010-04-19 07:52 ---
small enough for pasting:
cat bug.f90
MODULE fft_tools
INTEGER, PARAMETER :: sp=4, dp=8
INTEGER, PARAMETER :: lp = dp
CONTAINS
SUBROUTINE sparse_alltoall ( rs, scount, sreq, rq, rcount, rreq, group )
Two semantically equivalent files output different results using gcc 4.5.0
release,while gcc 4.4.1 produced correct results.
here is the command line option used to compile the files:
gcc -O2 MTest-1.c -o MTest-1.exe
gcc -O2 MTest-7.c -o MTest-7.exe
#and the results
./MTest-1.exe # generate
--- Comment #1 from wuwei08 at iscas dot ac dot cn 2010-04-19 08:09 ---
Created an attachment (id=20415)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20415action=view)
source files to trigger this bug
Source files to trigger this bug.it is a tar file,include
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-19 08:52 ---
Confirmed, probably introduced/uncovered between revisions 158215 (no ICE) and
158486 (ICE).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
--- Comment #24 from ramana at gcc dot gnu dot org 2010-04-19 09:06 ---
(In reply to comment #23)
Fixed for 4.6, if you confirm the patch for the branch tested ok I'll apply
that
there.
The patch works fine on the 4.5 branch with arm-linux-gnueabi.
A bootstrap with
--- Comment #4 from irar at gcc dot gnu dot org 2010-04-19 09:11 ---
Subject: Bug 37027
Author: irar
Date: Mon Apr 19 09:10:45 2010
New Revision: 158506
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158506
Log:
PR tree-optimization/37027
* tree-vectorizer.h
--- Comment #25 from rguenth at gcc dot gnu dot org 2010-04-19 09:12
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from rguenth at gcc dot gnu dot org 2010-04-19 09:13
---
Subject: Bug 43572
Author: rguenth
Date: Mon Apr 19 09:12:13 2010
New Revision: 158507
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158507
Log:
2010-04-19 Richard Guenther rguent...@suse.de
PR
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-19 09:17 ---
Also seen on powerpc64-unknown-linux-gnu (see
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01669.html ).
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #3 from jv244 at cam dot ac dot uk 2010-04-19 09:23 ---
Dominique, you should ask for 'bugzilla confirmation rights' which will allow
to touch the 'Confirm' fields etc...
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #4 from dominiq at lps dot ens dot fr 2010-04-19 09:30 ---
Dominique, you should ask for 'bug zilla confirmation rights' which will allow
to touch the 'Confirm' fields etc...
Do you WHO I should ask for 'bug zilla confirmation rights'?
--
--- Comment #7 from dodji at gcc dot gnu dot org 2010-04-19 09:32 ---
Subject: Bug 43704
Author: dodji
Date: Mon Apr 19 09:32:16 2010
New Revision: 158508
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158508
Log:
Fix PR c++/43704
gcc/cp/ChangeLog:
PR c++/43704
*
--- Comment #8 from redi at gcc dot gnu dot org 2010-04-19 09:35 ---
It works fine without -std=c++0x, so is only a regression in code using an
experimental compiler mode which implements an incomplet and incorrekt
standard.
This is not the right place to open defect reports against
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-19 09:36 ---
I can confirm that the output of MTest-7.c differs with -O2 -fno-inline -m32
vs.
-O2 -fno-inline -m32 -fno-tree-pre. The latter is equivalent to the -O0 -m32
output.
As inlining seems to be not relevant to trigger
--- Comment #16 from redi at gcc dot gnu dot org 2010-04-19 09:38 ---
Unsuspending, DR743 was recently resolved
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Dear All,
I want to compile gcc-4.5.0 on a Quad-Core AMD Opteron(tm) Processor 8356 in my
user repository.
The compiler is gcc version 4.1.2 20070626 (Red Hat 4.1.2-14).
I think that I correctly installed all(?) the needed lib to compile gcc-4.5.0.
But I issue the following error to the $make
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-19 09:49 ---
The function seems to be MetamorphicTestFunc and the issue is that GCC
thinks that
D.3914_916 = D.3912_898 * 14400;
D.3915_917 = D.3914_916 % 200;
is zero because 14400 % 200 == 0. As signed overflow is
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-19 09:50 ---
(In reply to comment #4)
Dominique, you should ask for 'bug zilla confirmation rights' which will
allow
to touch the 'Confirm' fields etc...
Do you WHO I should ask for 'bug zilla confirmation rights'?
If
--- Comment #8 from redi at gcc dot gnu dot org 2010-04-19 09:54 ---
(In reply to comment #3)
At the very least, you'd agree that it's a performance bug to be copying bytes
from memory when the class is empty. At the severe use-case, it breaks
existing code.
As far as I can see,
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-19 09:56 ---
Confirmed (libbid result is incorrect, GCC constant-folded result is correct).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dominiq at lps dot ens dot fr 2010-04-19 09:56 ---
If you have svn write access you have full bugzilla rights if you use
a bugzilla account with your @gcc.gnu.org address.
Indeed I don't have svn write access and I am not planning to ask for it in a
near future.
--- Comment #12 from jiez at gcc dot gnu dot org 2010-04-19 10:03 ---
Subject: Bug 43662
Author: jiez
Date: Mon Apr 19 10:02:52 2010
New Revision: 158509
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158509
Log:
PR target/43662
* reginfo.c (reinit_regs): Set
--- Comment #9 from redi at gcc dot gnu dot org 2010-04-19 10:03 ---
Also, make_pair's reason for existing is to deduce template arguments. If you
don't want argument deduction why use make_pair?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
--- Comment #13 from jiez at gcc dot gnu dot org 2010-04-19 10:05 ---
Subject: Bug 43662
Author: jiez
Date: Mon Apr 19 10:04:43 2010
New Revision: 158510
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158510
Log:
PR target/43662
* reginfo.c (reinit_regs): Set
--- Comment #14 from jiez at gcc dot gnu dot org 2010-04-19 10:06 ---
Subject: Bug 43662
Author: jiez
Date: Mon Apr 19 10:06:13 2010
New Revision: 158511
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158511
Log:
PR target/43662
* reginfo.c (reinit_regs): Set
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Summary|possible wrong code at all
--- Comment #15 from jiez at gcc dot gnu dot org 2010-04-19 10:10 ---
Should be fixed now on trunk, 4.5 and 4.4 branches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43662
uname -a
Linux loanamd25 2.6.16.46-0.10-smp #1 SMP Mon May 7 13:37:05 UTC 2007 x86_64
x86_64 x86_64 GNU/Linux
gfortran --version
GNU Fortran (GCC) 4.5.0
cat f06fkfn.f90
FUNCTION F06FKFN(N,W,INCW,X,INCX)
IMPLICIT NONE
INTEGER, PARAMETER :: WP = KIND(0.0D0)
REAL
--- Comment #4 from steven at gcc dot gnu dot org 2010-04-19 10:21 ---
Do we have a warning option for this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43794
--- Comment #5 from rguenther at suse dot de 2010-04-19 10:35 ---
Subject: Re: [4.5/4.6 Regression] miscompile
semantically equivalent C source files using -O2
On Mon, 19 Apr 2010, steven at gcc dot gnu dot org wrote:
--- Comment #4 from steven at gcc dot gnu dot org
typedef int INT1 __attribute__((deprecated(No INT1)));
INT1 f1 (void) __attribute__((deprecated(No f1)));
INT1 f2 (void) __attribute__((deprecated));
void func (void)
{
f1();
f2();
}
===
produces:
warning: 'f1' is deprecated (declared at...): No f1*** (correct)
warning: 'f2' is
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-19 10:56 ---
Confirmed on trunk with '-O[23] -m32 -fcheck=bounds' (compiles with '-O[01s]').
Works for me with 4.5 revision 157991 and 4.4.2 (with '-fbounds-check' instead
of '-fcheck=bounds'), hence at least a 4.6 regression.
--- Comment #1 from mikpe at it dot uu dot se 2010-04-19 11:00 ---
(In reply to comment #0)
Dear All,
I want to compile gcc-4.5.0 on a Quad-Core AMD Opteron(tm) Processor 8356 in
my
user repository.
The compiler is gcc version 4.1.2 20070626 (Red Hat 4.1.2-14).
I think that I
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-19 11:02 ---
It's not bid128_ext_fma that is miscompiled but bid_round.c, building that
with -O1 [-ftree-pre] works [fails].
__bid_round192_39_57 is miscompiled by PRE.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #3 from janus at gcc dot gnu dot org 2010-04-19 11:07 ---
Confirmed. Backtrace:
#0 gfc_add_component_ref (e=0x17cb5e0, name=0x77f2fe70 base_transp1) at
/home/jweil/gcc46/fortran-dev/gcc/fortran/expr.c:703
#1 0x00528306 in resolve_class_typebound_call
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-19 11:20 ---
Testcase:
typedef __attribute__((aligned(16)))
struct {
unsigned long w[3];
} UINT192;
UINT192 __bid_Kx192[32];
extern void abort (void);
int main()
{
int i = 0;
unsigned long x = 0;
for (i = 0; i 32;
--- Comment #11 from dominiq at lps dot ens dot fr 2010-04-19 11:25 ---
Should not this PR closed as fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42517
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-19 11:39 ---
Confirm. It fails with 4.5 and 4.6 using the option -fbounds-check (==
-fcheck-bounds), but only with -O2 and higher and for some reasons only with
-m32 and not with -m64 on x86_64-unknown-linux-gnu.
It works with
--- Comment #11 from pluto at agmk dot net 2010-04-19 11:44 ---
(In reply to comment #9)
The testcase is btw a too twisted maze. Can you wrap up a simple main()
so that it fails at runtime?
i'll try to reduce it to something human readable...
--
--- Comment #12 from pluto at agmk dot net 2010-04-19 11:44 ---
(In reply to comment #10)
Oh, and does it fail with http://gcc.gnu.org/bugzilla/attachment.cgi?id=20394
applied?
this patch didn't help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
--- Comment #7 from jv244 at cam dot ac dot uk 2010-04-19 11:56 ---
(In reply to comment #6)
If you have svn write access you have full bugzilla rights if you use
a bugzilla account with your @gcc.gnu.org address.
Indeed I don't have svn write access and I am not planning to ask
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-04-19 11:57 ---
The array element alignment is not properly visible, but instead loads of
random crap alignments appear in trees.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43783
--- Comment #9 from pault at gcc dot gnu dot org 2010-04-19 12:12 ---
I decided to take a look at this during lunchtime today. The source that I had
to hand is the 20091203 4.5.0 snapshot. To my astonishment, this does not show
the problem. I have had a quick look at the intervening
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-19 12:26 ---
Program received signal SIGSEGV, Segmentation fault.
0x00bdb380 in needs_overflow_infinity (type=0x0)
at /space/rguenther/src/svn/gcc-4_5-branch/gcc/tree-vrp.c:184
184 return INTEGRAL_TYPE_P (type)
--- Comment #6 from wuwei08 at iscas dot ac dot cn 2010-04-19 12:32 ---
Subject: Re: [4.5/4.6 Regression] miscompile
semantically equivalent C source files using -O2
On Mon, 2010-04-19 at 10:21 +, steven at gcc dot gnu dot org wrote:
--- Comment #4 from steven at gcc dot
--- Comment #10 from dominiq at lps dot ens dot fr 2010-04-19 12:33 ---
I decided to take a look at this during lunchtime today. The source that I
had
to hand is the 20091203 4.5.0 snapshot. To my astonishment, this does not
show
the problem. I have had a quick look at the
--- Comment #7 from wuwei08 at iscas dot ac dot cn 2010-04-19 12:36 ---
Thank you for your attention.
There is no warning for it with '-Wstrict-overflow[=[123]]' option.
(In reply to comment #5)
Subject: Re: [4.5/4.6 Regression] miscompile
semantically equivalent C source files
--- Comment #5 from uros at gcc dot gnu dot org 2010-04-19 12:37 ---
Subject: Bug 43766
Author: uros
Date: Mon Apr 19 12:37:16 2010
New Revision: 158515
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158515
Log:
PR target/43766
* config/i386/i386.c
--- Comment #6 from ubizjak at gmail dot com 2010-04-19 12:38 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from janus at gcc dot gnu dot org 2010-04-19 12:51 ---
(In reply to comment #10)
AFAICR the problem is specific to the fortran-dev branch.
No, this is definitely not the case! Only the failure of comment #0 is specific
to the branch. However, this failure is caused by
--- Comment #2 from ubizjak at gmail dot com 2010-04-19 12:53 ---
(In reply to comment #0)
If I take off -msse2, I get this:
movd(%eax), %mm0
movd4(%eax), %mm1
punpcklbw %mm1, %mm0
The code above is produced _without_ SSE (-mno-sse), since
in libbid we have
typedef __attribute__((aligned(16)))
struct {
unsigned long long w[3];
} UINT192;
UINT192 bid_Kx192[32];
thus we request 16-byte alignment for UINT192 (whose elements add
up to a size of 24). Now the array ends up with elements of size 24
and thus the elements are _not_
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-19 13:05 ---
Namely the bid_Kx192 decl looks like
var_decl 0x75af8000 bid_Kx192
type array_type 0x75add7e0
type record_type 0x75add690 UINT192 type_0 BLK
size integer_cst 0x77ef70c8
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-19 13:06 ---
When searching for the origin of the regression, one should use the test case
in comment #3 and look at the 4.5 trunk.
I keep forgetting this test!-(on i686-apple-darwin9, it compiles at revision
147438,
--- Comment #13 from janus at gcc dot gnu dot org 2010-04-19 13:21 ---
I keep forgetting this test!-(on i686-apple-darwin9, it compiles at revision
147438, 20090512, and fails at revision 150825, 20090817).
That's a start. I can see two (hypothetical) candidates in this range:
*
--- Comment #2 from schwab at linux-m68k dot org 2010-04-19 13:28 ---
An array cannot have internal padding, so the padding needs to be added to the
element type.
The attempt to define such an array should probably be rejected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43798
--- Comment #3 from ubizjak at gmail dot com 2010-04-19 13:34 ---
From sse.md:
;; ??? In theory we can match memory for the MMX alternative, but allowing
;; nonimmediate_operand for operand 2 and *not* allowing memory for the SSE
;; alternatives pretty much forces the MMX alternative
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-04-19 13:37 ---
Subject: Bug 43783
Author: rguenth
Date: Mon Apr 19 13:36:54 2010
New Revision: 158517
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158517
Log:
2010-04-19 Richard Guenther rguent...@suse.de
PR
--- Comment #3 from jakub at gcc dot gnu dot org 2010-04-19 13:44 ---
At least with pointers alignment greater than size of the pointed to type (or
not divisible by it) is often used to say that the start of the array is
aligned some way.
--
--- Comment #14 from janus at gcc dot gnu dot org 2010-04-19 13:46 ---
(In reply to comment #13)
I keep forgetting this test!-(on i686-apple-darwin9, it compiles at revision
147438, 20090512, and fails at revision 150825, 20090817).
That's a start. I can see two (hypothetical)
--- Comment #15 from dominiq at lps dot ens dot fr 2010-04-19 13:54 ---
I just checked r150724, which also fails. This means that both my guesses were
wrong. But at least it bring us down to the range 147438:150724 (which is
still
three months of development).
I don't have access
--- Comment #4 from rguenther at suse dot de 2010-04-19 13:57 ---
Subject: Re: attribute((aligned(x))) not honored for array
element types?
On Mon, 19 Apr 2010, jakub at gcc dot gnu dot org wrote:
--- Comment #3 from jakub at gcc dot gnu dot org 2010-04-19 13:44 ---
At
1 - 100 of 223 matches
Mail list logo
