--- Comment #1 from pault at gcc dot gnu dot org 2009-02-09 08:15 ---
Coo! I did't know anything about PR323. I now don't want to know anything
about it:-)
Confirmed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ubizjak at gmail dot com 2009-02-09 08:28 ---
On alpha, we generate (-O3 -fno-tree-vectorize -funroll-loops):
$L2:
lda $19,4($1)
addq $17,$1,$21
lda $2,8($1)
cpys $f31,$f31,$f31
addq $17,$19,$20
ldl $22,0($21)
l
--- Comment #4 from pault at gcc dot gnu dot org 2009-02-09 08:42 ---
Does not
if (ns->save_all || !gfc_option.flag_automatic)
gfc_save_all (ns);
in resolve_types not fix the problem? (I have not had a chance to try this
yet.)
Confirmed
Paul
--
pault at gcc dot gnu dot org
--- Comment #17 from xuepeng dot guo at intel dot com 2009-02-09 09:16
---
Below is a loop in the case in its original form(compiled by GCC 4.4):
_Z7bench_1PfS_fj:
.LFB2309:
shrl$2, %edx
shufps $0, %xmm0, %xmm0
subl$1, %edx
xorl%eax, %eax
--- 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
--- 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 #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 #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
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 #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
-
--- 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 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 #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 #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
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
--
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
--- 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
--- 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 #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 #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
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 #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
--- 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
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")
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.0
Known to work||4.3.2
--- 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
--- 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
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 #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
--- 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 #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 #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 #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 #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
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 #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.
--- 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 #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 #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 #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 #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 #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 #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
--
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 #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
--- 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 #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 #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 #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()
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 #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
--- 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 #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 #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
---
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
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)
--- 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
--- 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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
--
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=39120
--- 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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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
1 - 100 of 104 matches
Mail list logo
