--- 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
Command line:
gcc -fschedule-insns testcase-1.c ./a.out
gcc -O[123s] -fschedule-insns testcase-2.c ./a.out
Tested revisions:
r158486 - fail
r158225 - OK
4.5 r158486 - OK
Compiler output:
$ /mnt/svn/gcc-trunk/binary-158486-lto-fortran/bin/gcc -O3 -fschedule-insns
testcase.c ./a.out
Aborted
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-19 14:06 ---
Testcase?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from zsojka at seznam dot cz 2010-04-19 14:10 ---
Created an attachment (id=20416)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20416action=view)
reduced testcase (from gcc.c-torture/execute/stdarg-2.c)
Command line:
$ gcc -fschedule-insns pr43799.c ./a.out
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #3 from zsojka at seznam dot cz 2010-04-19 14:14 ---
Created an attachment (id=20417)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20417action=view)
reduced testcase (from gcc.c-torture/execute/stdarg-4.c)
Command line:
$ gcc -O3 -fschedule-insns pr43799-2.c ./a.out
--- Comment #4 from zsojka at seznam dot cz 2010-04-19 14:23 ---
Created an attachment (id=20418)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20418action=view)
list of testsuite failures (gcc, g++, fortran)
$ make check RUNTESTFLAGS=--target_board=unix/-fschedule-insns
$ grep
--- Comment #3 from justinmattock at gmail dot com 2010-04-19 14:26 ---
Subject: Re: kernel/rtmutex.c:1138:1: internal compiler
error: in cgraph_decide_inlining_of_small_functions, at
ipa-inline.c:1009
On Mon, Apr 19, 2010 at 12:24 AM, jiez at gcc dot gnu dot org
--- Comment #3 from beebe at math dot utah dot edu 2010-04-19 14:34 ---
Subject: Re: Erroneous expansion of __asm__() directive
Oh I forgot to mention, sqrt will use sqrtsd and will be inlined so you don't
need to use inline-asm yourself.
The test code that I sent is an extract of
--- Comment #4 from beebe at math dot utah dot edu 2010-04-19 14:35 ---
Subject: Re: Erroneous expansion of __asm__() directive
That is wrong because with ATT style x86 asm, the src is first and the dest
is
second.
That cannot be the case: you cannot change the operand order
--- Comment #5 from irar at il dot ibm dot com 2010-04-19 14:35 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #8 from hjl dot tools at gmail dot com 2010-04-19 14:44 ---
On Linux/ia32, I got
Executing on host:
/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/g++2/../../g++
-B/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/g++2/../../
On Linux/ia32, revision 158513 gave
FAIL: libgomp.c++/for-3.C -O0 (test for excess errors)
FAIL: libgomp.c++/for-3.C -O1 (test for excess errors)
FAIL: libgomp.c++/for-3.C -O2 (test for excess errors)
FAIL: libgomp.c++/for-3.C -O3 -fomit-frame-pointer (test for excess errors)
FAIL:
--- Comment #10 from navin dot kumar at gmail dot com 2010-04-19 14:53
---
However, what would make_pair have deduced its T1 and T2 to be in this example?
My impression was make_pair(x,y) would have deduced T1=uint32_t and
T2=uint32_t. Therefore, make_pairuint32_t,uint32_t(x,y)
--- Comment #11 from navin dot kumar at gmail dot com 2010-04-19 14:54
---
typo: constructor has not changed in the above post should be function has
not changed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
--- Comment #5 from jakub at gcc dot gnu dot org 2010-04-19 14:56 ---
Nobody changed the order of arguments, in ATT syntax always the result is the
last, in Intel syntax (not the default on Linux unless -masm=intel) the result
is the first.
Perhaps you were lucky and both the input and
--- Comment #12 from bangerth at gmail dot com 2010-04-19 14:57 ---
(In reply to comment #9)
Also, make_pair's reason for existing is to deduce template arguments. If you
don't want argument deduction why use make_pair?
True. I don't know why one would want to do this either, but
--- Comment #6 from pinskia at gmail dot com 2010-04-19 15:07 ---
Subject: Re: Erroneous expansion of __asm__() directive
Sent from my iPhone
On Apr 19, 2010, at 7:35 AM, Nelson H. F. Beebe
be...@math.utah.edu wrote:
That is wrong because with ATT style x86 asm, the src is
--- Comment #16 from burnus at gcc dot gnu dot org 2010-04-19 15:13 ---
Works: 2009-07-24-r150035
Fails: 2009-07-29-r150196
(Both trees were _not_ clean, but the first has the same patches as the second
one, plus one more - thus, it is rather likely that the regression range is
still
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-19 15:17 ---
Subject: Bug 43796
Author: rguenth
Date: Mon Apr 19 15:17:26 2010
New Revision: 158520
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158520
Log:
2010-04-19 Richard Guenther rguent...@suse.de
PR
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.5.0 4.6.0 |4.5.0
Known to work|4.4.4 |4.4.4 4.6.0
--- Comment #13 from redi at gcc dot gnu dot org 2010-04-19 15:26 ---
(In reply to comment #10)
However, what would make_pair have deduced its T1 and T2 to be in this
example?
My impression was make_pair(x,y) would have deduced T1=uint32_t and
T2=uint32_t. Therefore,
--- Comment #14 from redi at gcc dot gnu dot org 2010-04-19 15:37 ---
(In reply to comment #13)
Well it's about time someone put a stop to it ;-)
Seriously though, it's quicker to write e.g.
return std::pairuint32_t, uint32_t(x, y)
than
return std::make_pairuint32_t, uint32_t(x,
1 - 100 of 201 matches
Mail list logo
