--- Comment #24 from mark at codesourcery dot com 2009-02-10 06:20 ---
Subject: Re: [4.2/4.3/4.4 regression] ICE on invalid default
template parameter
paolo dot carlini at oracle dot com wrote:
> Mark, can you have a closer look to the draft patch? I'm still looking but I
> don't thi
--- Comment #1 from Joey dot ye at intel dot com 2009-02-10 05:35 ---
Argument need 32 bytes alignment, No way to guarantee the argument won't be
spilled. That's why stack adjustment is there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[...@gnu-6 avx-abi]$ cat x5.i
typedef long long __m256i __attribute__ ((__vector_size__ (32),
__may_alias__));
__m256i
bar (__m256i x)
{
return x;
}
[...@gnu-6 avx-abi]$ /export/build/gnu/gcc-avx/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-avx/build-x86_64-linux/gcc/ -mavx
-fno-asynchr
Greetings!
An assertion was hit in the Ada front end.
Note that the test code (attached) is not semantically correct.
For me, the bug manifests in both 4.3.2 and the latest snapshot
4.4-20090206.
Configure options:
--disable-multilib --enable-languages=c,ada
System type:
$ uname -ro
2.6.2
Compiling the snippet below using
g++ -O3 -std=c++0x foo.cpp -lboost_regex
fails.
However, the compile succeeds with:
g++ -O2 -std=c++0x foo.cpp -lboost_regex
g++ -O2 -std=c++0x foo.cpp -funswitch-loops -fpredictive-commoning
-fgcse-after-reload -ftree-vectorize foo.cpp -lboost_regex (i.e. -O3
--- Comment #22 from hjl dot tools at gmail dot com 2009-02-10 01:36
---
I guess it is too expensive to add a new reg class for each
register to support constraints for all registers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
--- Comment #5 from paolo dot carlini at oracle dot com 2009-02-10 00:35
---
Take your time. Please, understand that if a PR is not filed in the proper
form, the chances that a knowledgeable person seriously look into it, sharply
decreases. You can probably find this also useful:
htt
--- Comment #3 from paolo dot carlini at oracle dot com 2009-02-10 00:08
---
Ah, ok, it's i686...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39060
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-02-09 22:58
---
I can still reproduce it with trunk from 2009-02-07 (updated after your
comment).
As mentioned before the testcase is a little fragile. Some weeks ago I had a
much larger testcase (about 150 lines) which I couldn'
--- Comment #4 from macdonellba+gcc at gmail dot com 2009-02-09 22:54
---
I'm not really sure that this is worth pursuing for me, since I'm a touch
uncertain whether I should expect to have problems with OOM (using over 800MB
of RAM once buffers are cleared) on an macro-laden 79KLOC gen
--- Comment #17 from mmitchel at gcc dot gnu dot org 2009-02-09 22:53
---
The patch to remove addr2name.awk has now been committed to mainline. I am not
sure what else, if anything, remains on this PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5303
--- Comment #16 from mmitchel at gcc dot gnu dot org 2009-02-09 22:45
---
Patch to remove addr2name.awk now available here:
http://gcc.gnu.org/ml/java-patches/2009-q1/msg00013.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5303
--- Comment #12 from ubizjak at gmail dot com 2009-02-09 22:43 ---
(In reply to comment #11)
> Uros, how hard to support this in x86 backend?
I remember there were concerns when xmm0 single-register constraint was
introduced... We need new constraint letter and new regclass entry. I don
--- Comment #21 from ian at airs dot com 2009-02-09 22:37 ---
I agree with Jakub that the original test case, and the one in comment #7,
appear to conform to the documented gcc extension. I think that gcc has to
treat this sort of code as valid, and not break it. We can't casually or
a
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-09 22:10 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from jason at gcc dot gnu dot org 2009-02-09 21:46 ---
Subject: Bug 39109
Author: jason
Date: Mon Feb 9 21:46:18 2009
New Revision: 144044
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144044
Log:
PR c++/39109
* semantics.c (simplify_aggr_init_ex
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39120
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
--- Comment #20 from hjl dot tools at gmail dot com 2009-02-09 21:09
---
(In reply to comment #19)
> No. This bug is about all targets, not just x86-64, and is about code which
> follows extend.texi documentation (Extended Asm and Explicit Reg Vars) for
> years (glibc e.g. uses it this
--- Comment #19 from jakub at gcc dot gnu dot org 2009-02-09 21:01 ---
No. This bug is about all targets, not just x86-64, and is about code which
follows extend.texi documentation (Extended Asm and Explicit Reg Vars) for
years (glibc e.g. uses it this way for more than 10 years). Do y
--- Comment #2 from janis at gcc dot gnu dot org 2009-02-09 20:53 ---
Subject: Bug 33300
Author: janis
Date: Mon Feb 9 20:53:22 2009
New Revision: 144043
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144043
Log:
2009-02-09 Jack Howarth
PR testsuite/33300
*
--- Comment #18 from hjl dot tools at gmail dot com 2009-02-09 20:52
---
(In reply to comment #17)
> This is wrong, this is not a dup of PR16331. PR16331 is invalid, it makes a
> call with r8 in scope. This one doesn't. That's pretty substantial
> difference.
>
PR 16331 is "x86-64
--- Comment #11 from hjl dot tools at gmail dot com 2009-02-09 20:49
---
Uros, how hard to support this in x86 backend?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #17 from jakub at gcc dot gnu dot org 2009-02-09 20:49 ---
This is wrong, this is not a dup of PR16331. PR16331 is invalid, it makes a
call with r8 in scope. This one doesn't. That's pretty substantial
difference.
--
jakub at gcc dot gnu dot org changed:
Wh
--- Comment #10 from hjl dot tools at gmail dot com 2009-02-09 20:47
---
The rational for this request is at
http://gcc.gnu.org/bugzilla/attachment.cgi?id=17274
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16331
--- Comment #16 from hjl dot tools at gmail dot com 2009-02-09 20:46
---
*** This bug has been marked as a duplicate of 16331 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #9 from hjl dot tools at gmail dot com 2009-02-09 20:46 ---
*** Bug 39139 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #8 from hjl dot tools at gmail dot com 2009-02-09 20:46 ---
Reopened.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|RESOLV
--- Comment #15 from hjl dot tools at gmail dot com 2009-02-09 20:44
---
I tempted to reopen PR 16331 and mark PR 38925/39139 as dup
for PR 16331.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
--- Comment #14 from hjl dot tools at gmail dot com 2009-02-09 20:43
---
PR 16331 is another.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
BugsThisDep
--- Comment #13 from hjl dot tools at gmail dot com 2009-02-09 20:41
---
(In reply to comment #10)
> The code in question is setting up parameters for a Xen hypercall. The
> hypercall ABI defines what arguments go in which registers. It uses the
> "register unsigned long arg asm" synt
--- Comment #12 from jeremy at goop dot org 2009-02-09 20:37 ---
Created an attachment (id=17274)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17274&action=view)
Original code to set up hypercalls.
This is the original code Jakub distilled the reproducer from. It includes a
comm
--- Comment #11 from jakub at gcc dot gnu dot org 2009-02-09 20:36 ---
Sure, but in your testcase you do the operation that requires the register
while the register var is still in scope and live. The compiler doesn't have a
possibility to compile it right. But, if we say it is ok for
--- Comment #10 from jeremy at goop dot org 2009-02-09 20:35 ---
The code in question is setting up parameters for a Xen hypercall. The
hypercall ABI defines what arguments go in which registers. It uses the
"register unsigned long arg asm" syntax because that's the only way to specify
--- Comment #5 from spop at gcc dot gnu dot org 2009-02-09 20:35 ---
Subject: Bug 38953
Author: spop
Date: Mon Feb 9 20:35:09 2009
New Revision: 144042
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144042
Log:
2009-02-09 Sebastian Pop
PR middle-end/38953
*
--- Comment #9 from hjl dot tools at gmail dot com 2009-02-09 20:32 ---
We should take a look at the problem "register unsigned long reg asm"
trying to resolve. We may need to provide some other reliable ways
to address the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=391
--- Comment #8 from hjl dot tools at gmail dot com 2009-02-09 20:29 ---
[...@gnu-6 reg-1]$ cat b.c
extern void abort (void);
int g = 3;
int main()
{
register int x __asm__("ecx");
x = 5;
if ((1 << g) != 8 || x != 5)
abort ();
return 0;
}
[...@gnu-6 reg-1]$ /export/
--- Comment #12 from jzb2 at aexorsyst dot com 2009-02-09 20:25 ---
So it appears that the root cause of this issue is the long standing libtool
DESTDIR problem.
I've reworked the original patch above into to following, which works with my
./configure options:
Index: gcc_native-4.2.2/l
--- Comment #7 from jakub at gcc dot gnu dot org 2009-02-09 20:17 ---
This is different from that PR. In this case the code does nothing dangerous
in the block with the register vars. For %rdi and a couple of other regs on
x86-64
one could actually use "D" etc. constraints, but r8-r15
--- Comment #6 from hjl dot tools at gmail dot com 2009-02-09 19:39 ---
I think gcc treats REG in:
register unsigned long reg asm ("rax");
as an alias of the RAX register. If you use REG in any
way which interferes with register allocator, you will
get either ICE or unexpected results.
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-09 19:12 ---
I think it is related to PR 38941.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
--- Comment #6 from janis at gcc dot gnu dot org 2009-02-09 18:59 ---
Fixed in mainline and 4.3 branch.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-09 18:59
---
*** Bug 39144 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2009-02-09 18:59
---
*** This bug has been marked as a duplicate of 18640 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #5 from janis at gcc dot gnu dot org 2009-02-09 18:51 ---
Subject: Bug 39035
Author: janis
Date: Mon Feb 9 18:51:31 2009
New Revision: 144039
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144039
Log:
PR c/39035
* real.c (do_compare): Special-case co
--- Comment #84 from pinskia at gcc dot gnu dot org 2009-02-09 18:45
---
*** Bug 39143 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-09 18:45 ---
This code is undefined as you are assigning to the variable i without a
sequence point inbetween the assignment.
*** This bug has been marked as a duplicate of 11751 ***
--
pinskia at gcc dot gnu dot org changed
gcc produces codes that segfaults.
The following program segfaults when compiled for 64-bit code on an x86-64
linux system. The program should sort a vector of doubles into descending
order.
I tested with versions 3.3.6, 3.4.6, 4.1.2, 4.2.3, 4.3.2 and 4.3.3.
- When compiling for 32-bit code (-m32)
A friend of mine have noticed an error in GCC when he was developing his own C
compiler. The problem happens when using -O0 (no optimization) and local vars.
See sample code:
#include
int jj = 0, ii = 0; //global vars
int main()
{
int j = 0, i = 0; // local vars
i -= i += 2; // i = 0 i
--- Comment #3 from paolo dot carlini at oracle dot com 2009-02-09 18:15
---
Please reduce it to a manageable size. For example, try 'delta', if you don't
have other ways.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #4 from jakub at gcc dot gnu dot org 2009-02-09 18:12 ---
... must do what exactly? Using DECL_HARD_REGISTER vars in macros or inline
functions is very common, starting from kernel, glibc, many programs that
invoke syscalls directly, etc., and it worked well until now.
I thi
--- Comment #2 from macdonellba+gcc at gmail dot com 2009-02-09 18:13
---
Paolo Carlini:
I was unable to attach the reproducer, as the bugzilla would not accept it due
to it's size. In the meantime, I have uploading it to
http://macdonellba.googlepages.com/_io.i .
--
macdonellba+gcc
--- Comment #1 from paolo dot carlini at oracle dot com 2009-02-09 18:10
---
Please follow the bug-reporting instructions, in particular, please provide a
pre-processed reproducer:
http://gcc.gnu.org/bugs.html
--
paolo dot carlini at oracle dot com changed:
What|R
Command line:
gcc -I../include -I. -O2 -mtune=generic -march=i686 -Wall -W -Wno-unused -O1
-fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing
-fwrapv -fmodulo-sched -freschedule-modulo-scheduled-loops -fomit-frame-pointer
-fPIC -fno-common -mieee-fp -DHAVE_CONFIG_H -D___GAMB
--- Comment #9 from paolo dot carlini at oracle dot com 2009-02-09 17:59
---
(In reply to comment #8)
> At no point was vector::resize() ever instantiatable with a
> non-DefaultConstructible Tp, even with the old size_type-only member
> function. It would have failed on value_type()
--- Comment #8 from fang at csl dot cornell dot edu 2009-02-09 17:54
---
Subject: Re: std::mem_fun_ref fails to accept a member
function whose second argument with default value
> --- Comment #7 from paolo dot carlini at oracle dot com 2009-02-09 17:26
> ---
> (In reply to
--- Comment #7 from paolo dot carlini at oracle dot com 2009-02-09 17:26
---
(In reply to comment #6)
> Was there a compelling reason to remove it in favor of the unified
> ::resize(size_type, const value_type& t = T)?
Yes, is non-conforming! I thought it was clear at this point... Jus
--- Comment #53 from janis at gcc dot gnu dot org 2009-02-09 17:22 ---
Rob, you don't seem to understand that setting GCC_EXEC_PREFIX does NOT cause
the tests to use GCC files from the install tree. The test framework
explicitly uses -B options to override GCC_EXEC_PREFIX, so the only e
--- Comment #6 from fang at csl dot cornell dot edu 2009-02-09 17:21
---
Subject: Re: std::mem_fun_ref fails to accept a member
function whose second argument with default value
> --- Comment #5 from paolo dot carlini at oracle dot com 2009-02-09 16:47
> ---
> Your snippet
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #23 from paolo dot carlini at oracle dot com 2009-02-09 17:09
---
Mark, can you have a closer look to the draft patch? I'm still looking but I
don't think we can extract and commonize much code from grok_array_decl, unless
we accept to pass from the callers an in_parser flag
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-09 16:53 ---
Another option is RESOLVED INVALID. Whoever uses local fixed regs ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
--- Comment #5 from paolo dot carlini at oracle dot com 2009-02-09 16:47
---
Your snippet boils down to this, which is clearly invalid:
struct vector
{
void resize(long unsigned int, int = 0);
};
template
void
mem_fun_ref(_Ret (_Tp::*__f)(_Arg));
void
test() {
mem_fun_ref(&ve
--- Comment #15 from aph at redhat dot com 2009-02-09 16:46 ---
Subject: Re: Undocumented java programs
mmitchel at gcc dot gnu dot org wrote:
> --- Comment #14 from mmitchel at gcc dot gnu dot org 2009-02-09 16:20
> ---
> Would the Java maintainers accept a patch to remove a
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-09 16:45 ---
This would be a fragile solution. I think the backend has to cope with that
in some way, for example not using string expanders when there is any local
register variable.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-09 16:42 ---
Fixed since GCC 4.3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-09 16:39 ---
Regression since http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134321
tree-ssa-sink.c moves e = {} store across a1 = 11 initialization, where a1
is a register asm ("%rdi") variable, so into a spot where %rdi is live
--- Comment #14 from mmitchel at gcc dot gnu dot org 2009-02-09 16:20
---
Would the Java maintainers accept a patch to remove addr2name.awk?
As far as I can tell, it is no longer used after:
2002-08-24 Mark Wielaard
* Makefile.am (libgcj_la_SOURCES): Remove name-finder.cc.
I see a 50% cycle increase for EEMBC idctrn01 going from gcc 4.2.1 to gcc 4.4 .
There are two issues, overzealous unrolling, and constant propagation in the
unrolled loops.
While both issues can be avoided by reducing the parameter
"max-completely-peeled-insns" to 200, this is not really satisfacto
--- Comment #11 from manu at gcc dot gnu dot org 2009-02-09 16:15 ---
Actually, I am going to close it as WORKSFORME, but if you can reproduce this
with a GCC later than revision 143971 (even in this huge testcase), please
reopen. Thanks for the report.
--
manu at gcc dot gnu dot org
--- Comment #10 from manu at gcc dot gnu dot org 2009-02-09 16:13 ---
I cannot reproduce this with current GCC 4.4
Also, the testcase is too big.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-09 16:11
---
(In reply to comment #3)
> I'm looking at the current draft, n2798.
> 23.2.6.2/10-11 [vector.capacity]
> which lists both forms of resize().
> Yes, libstdc++ covers both by using the trailing default argument,
--- Comment #6 from valery_reznic at yahoo dot com 2009-02-09 16:09 ---
(In reply to comment #4)
> Or you can subq $128, %rsp; call my_syscall; addq $128, %rsp in your inline
> assembly.
>
When I understood what happened I did it, but thank you anyway.
--
http://gcc.gnu.org/bugzill
--- Comment #5 from valery_reznic at yahoo dot com 2009-02-09 16:07 ---
(In reply to comment #3)
> > > r11 is saved by the caller so this is the generated code is valid.
> > > Since nothing else uses r11 in the inline-asm, the code is correct.
> > The problem is not that r11 not saved a
--- Comment #2 from manu at gcc dot gnu dot org 2009-02-09 16:06 ---
This works in GCC 4.1, 4.3 and 4.4, so this is either a regression (that
probably will not be fixed before 4.2 is closed) or it is not a regression and
should be closed as FIXED already in trunk.
--
manu at gcc dot
In the code below, g++ should eliminate both function calls when called with
-O2:
$ cat > inline_varargs.c <
08048420 :
$ gcc -O2 inline_varargs.c
$ objdump -d a.out | grep Vararg
08048350 :
08048360 :
$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--e
--- Comment #3 from fang at csl dot cornell dot edu 2009-02-09 15:58
---
Subject: Re: std::mem_fun_ref fails to accept a member
function whose second argument with default value
> --- Comment #2 from paolo dot carlini at oracle dot com 2009-02-09 09:53
> ---
> (In reply to
--- Comment #6 from manu at gcc dot gnu dot org 2009-02-09 15:56 ---
This testcase is too big to see clearly what is going on. A reduced testcase
would be appreciated (preferably with just 1 function).
--
manu at gcc dot gnu dot org changed:
What|Removed
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.0
Known to work||4.3.2
static inline int
foo (unsigned int x, void *y)
{
register unsigned long r asm ("rax");
register unsigned long a1 asm ("rdi") = a1;
register unsigned long a2 asm ("rsi") = a2;
a1 = (unsigned long) x;
a2 = (unsigned long) y;
asm volatile ("" : "=r" (r), "+r" (a1), "+r" (a2) : : "memory")
--- Comment #4 from manu at gcc dot gnu dot org 2009-02-09 15:41 ---
We cannot reproduce the bug you reported with a recent revision of GCC 4.4.
If you still see the problem, please reopen. Thanks.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from manu at gcc dot gnu dot org 2009-02-09 15:35 ---
After inlining, pp is initialized to 0.
# BLOCK 3 freq:9550, starting at line 0
# PRED: 10 [95.5%] (true,exec)
[/home/manuel/pr36823.c : 23] D.1611_4 = [/home/manuel/pr36823.c : 23]
pD.1607_2->bD.1592;
ppD.1620
While building "gcc version 4.4.0 20090208" I noticed we need to check our
dates:
# gmake
... (long time)
GNATLINK 4.4.0 20090208 (experimental)
Copyright (C) 1995-2008, Free Software Foundation, Inc.
...
We need instances of "2008" (and if there is "2007", etc...) to read "2009".
Thanks,
Rob
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-09 15:21 ---
(In reply to comment #3)
> How can #1 cause a problem with -ftree-vectorize (especially when it hasn't
I don't believe "-mpreferred-stack-boundary=2 -ftree-vectorize" works
well in gcc 4.3.
> been problem in 4.3 an
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-09 15:06 ---
How can #1 cause a problem with -ftree-vectorize (especially when it hasn't
been problem in 4.3 and earlier)? We'd do realignment for V[1248]* modes, just
not for DImode/DFmode...
--
http://gcc.gnu.org/bugzilla/s
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-09 14:57 ---
(In reply to comment #1)
> Confirmed. I think with -Os or even more with -mpreferred-stack-boundary
> dynamic stack alignment should _not_ be used.
>
That will cause core dump on programs with __m128/__m256. We ha
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-09 14:39 ---
Confirmed. I think with -Os or even more with -mpreferred-stack-boundary
dynamic stack alignment should _not_ be used.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
On i?86, Linux kernel (or e.g. valgrind) are compiled with -Os -m32
-mpreferred-stack-boundary=2. AFAIK this is used primarily to make generated
code small. But when compiled with gcc 4.4, lots of functions at least in
valgrind (haven't checked kernel, but I assume even more so there) now newly
u
--- Comment #2 from rob1weld at aol dot com 2009-02-09 13:50 ---
I tried to lower the "Priority" but I can not alter my own Bug Reports.
(In reply to comment #1)
> Subject: Re: New: trunk revision 143992 - Too many Testsuite
> FAILs = email > 400K = bounce
> On Sat, 7 Feb 2009, rob1w
--- Comment #19 from bonzini at gnu dot org 2009-02-09 13:37 ---
Also, Dwarak, here the change is not from
addps (%rax, %rsi), %xmm1
to
movps (%rax, %rsi), %xmm0
addps %xmm0, %xmm1
but rather from
movps %xmm0, %xmm1
addps (%rax, %rsi), %xmm1
to the second s
--- Comment #18 from bonzini at gnu dot org 2009-02-09 13:35 ---
Xuepeng, can you test with the loop as produced by my posted patch, that is:
.L11:
movaps (%rsi,%rax), %xmm0
addps %xmm1, %xmm0
movaps %xmm0, (%rdi,%rax)
addq$16, %rax
cmpq
--- Comment #15 from jakub at gcc dot gnu dot org 2009-02-09 12:54 ---
And, even if decl_ultimate_origin checking is weakened and it actually looks
for ultimate origin for RESULT_DECLs, I'm not sure the generated debug info is
correct. The problem is that the tree NRV optimization is an
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2009-02-09 11:11
---
Thanks for reporting the problem.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
tree-ssa-coalesce.c (add_coalesce): Cap the costs of coalesce pairs
at MUST_COALESCE_COST-1 instead of MUST_COALESCE_COST.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20090209-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-coalesce.c
--
--- Comment #2 from paolo dot carlini at oracle dot com 2009-02-09 09:53
---
(In reply to comment #0)
> I'm not sure if this is valid code. However, the standard seems to indicate
> that resize(size_type), is a required member function (or at least interface)
> of std::vector.
Which
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-02-09 09:36 ---
Fixed for trunk. Not worth fixing on the branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-02-09 09:35 ---
Subject: Bug 35202
Author: rguenth
Date: Mon Feb 9 09:35:22 2009
New Revision: 144030
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144030
Log:
2009-02-09 Richard Guenther
PR middle-end/35202
--- Comment #1 from schwab at suse dot de 2009-02-09 09:30 ---
This is a GCC extension, use -Wpointer-arith or -pedantic or -pedantic-errors.
$ gcc -c -std=c99 -pedantic-errors cast.c
cast.c: In function ‘test’:
cast.c:6: error: invalid application of ‘sizeof’ to a function type
cast.c
1 - 100 of 104 matches
Mail list logo
