--- 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;
fn
--- 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
Statu
--- 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=20414&action=view)
kernel .config
here is my .config I used to hit this error,
and FWIW here is my compile flags that I used for g
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++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86
--- 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
Stat
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
conta
--- 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 )
COMPLEX
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 MTest
--- 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=20415&action=view)
source files to trigger this bug
Source files to trigger this bug.it is a tar file,include
MTest-1.c,MTest-1.i,
--- 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 --with-cpu
--- 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=gcc&view=rev&rev=158506
Log:
PR tree-optimization/37027
* tree-vectorizer.h (st
--- 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
Status|ASSIGNE
--- 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=gcc&view=rev&rev=158507
Log:
2010-04-19 Richard Guenther
PR tree-optimizatio
--- 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'?
--
http://gcc.gnu.org/bugzilla
--- 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=gcc&view=rev&rev=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 the
--- 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 in
--- 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 undefi
--- 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 right
--- 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=gcc&view=rev&rev=158509
Log:
PR target/43662
* reginfo.c (reinit_regs): Set cal
--- 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=gcc&view=rev&rev=158510
Log:
PR target/43662
* reginfo.c (reinit_regs): Set cal
--- 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=gcc&view=rev&rev=158511
Log:
PR target/43662
* reginfo.c (reinit_regs): Set cal
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Summary|possible wrong code at all -|[4.4/4.5/4
--- 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 (KIND
--- 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 2010-04-1
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 de
--- 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 th
--- 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 (code=0x
--- 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 GC
--- 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...
--
http://gcc.gnu.org/bugzilla/sh
--- 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
--- 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 g
--- 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 usi
--- 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=gcc&view=rev&rev=158515
Log:
PR target/43766
* config/i386/i386.c (ix86_decompos
--- 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), sin
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_ al
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-19 13:05 ---
Namely the bid_Kx192 decl looks like
unit size
user align 128 symtab 0 alias set -1 canonical type 0x75add498
fields context
pointer_to_this >
BLK
size
--- 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, 2009051
--- 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 t
--- 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=gcc&view=rev&rev=158517
Log:
2010-04-19 Richard Guenther
PR tree-optimization/
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- 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 (hypothetica
--- 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 acce
--- 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 l
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
Aborte
--- 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
Status|UNCONF
--- 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=20416&action=view)
reduced testcase (from gcc.c-torture/execute/stdarg-2.c)
Command line:
$ gcc -fschedule-insns pr43799.c && ./a.out
Abo
--
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=20417&action=view)
reduced testcase (from gcc.c-torture/execute/stdarg-4.c)
Command line:
$ gcc -O3 -fschedule-insns pr43799-2.c && ./a.o
--- 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=20418&action=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
wrote:
>
>
>
--- 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
--- 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 AT&T style x86 asm, the src is first and the dest
>> is
>> second.
That cannot be the case: you cannot change the operand orde
--- 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/../../
/export/gnu/import/svn/gcc-test/src-trunk/gcc/
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: libgomp
--- 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_pair(x,y)" should be
synonymou
--- 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 AT&T 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 se
--- 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"
wrote:
>>> That is wrong because with AT&T style x86 asm, the src is first
>>> and th
--- 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 co
--- 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=gcc&view=rev&rev=158520
Log:
2010-04-19 Richard Guenther
PR tree-optimization/
--
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, "make_p
--- 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::pair(x, y)
than
return std::make_pair(x, y);
I can't see why anyone would us
Command line:
g++ -fipa-cp -fipa-cp-clone testcase.C
Tested revisions:
r158486 - fail
r153685 - fail
4.4 r158133 - OK
Compiler output:
$ g++ -fipa-cp -fipa-cp-clone -c testcase.C
testcase.C: In member function 'virtual void B::_ZN1B1fEi.clone.0()':
testcase.C:5:16: error: virtual void B::_ZN1B1fE
--- Comment #1 from zsojka at seznam dot cz 2010-04-19 15:44 ---
Created an attachment (id=20420)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20420&action=view)
reduced testcase (from g++.old-deja/g++.mike/p3708.C)
Command line:
g++ -fipa-cp -fipa-cp-clone pr43801.C
--
http
--- Comment #15 from bangerth at gmail dot com 2010-04-19 15:51 ---
(In reply to comment #14)
> > Well it's about time someone put a stop to it ;-)
>
> Seriously though, it's quicker to write e.g.
> return std::pair(x, y)
> than
> return std::make_pair(x, y);
No question. The poin
1 - 100 of 200 matches
Mail list logo
