- The more conservative one is to use more aggressively the release
milestone field. Hard-to-fix bugs would be left as P2, but bumped to
the next major release at the beginning of stage 3.
Advantages: no need for churn in the bug database---very easy to implement
Disadvantages: the
Dear All,
I want to use multilib (EL/EB) in mips-unknown-linux-gcc.
So when I add some lines to gcc/config/mips/t-mips, it looks like gcc uses
multilib.
[r...@st1 SPECS]# mips-vniins-linux-gcc -print-multi-lib
.;
el;@EL
But output of
mips-unknown-linux-gcc --print-search-dirs
and
Ok, I understand now. Thank you very much for your explanations,
Jean Christophe Beyler
On Sat, Feb 7, 2009 at 5:13 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
On Sat, Feb 07, 2009 at 03:54:51PM -0500, Jean Christophe Beyler wrote:
Dear all,
I have a question about the way the
On Mon, Feb 09, 2009 at 03:15:20PM +0300, Sergey Anosov wrote:
[r...@st1 SPECS]# mips-vniins-linux-gcc -print-multi-lib
.;
el;@EL
But output of
mips-unknown-linux-gcc --print-search-dirs
and
mips-unknown-linux-gcc -mel --print-search-dirs
is the same.
Did you try mips-unknown-linux-gcc
Yes, of course.
My gcc/config/mips/t-mips file:
FPBIT = fp-bit.c
DPBIT = dp-bit.c
$(T)crti.o: $(srcdir)/config/mips/crti.asm $(GCC_PASSES)
$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(MULTILIB_CFLAGS) $(INCLUDES) \
-c -o $(T)crti.o -x assembler-with-cpp $(srcdir)/config/mips/crti.asm
$(T)crtn.o:
On Thu, 5 Feb 2009, Paul Brook wrote:
For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH
to zero. Inlining at -Os should already only happen if it decreases
(overall!) code-size. Thus, inlining a function that is called once and
that does not need to be emitted will always be an
On Friday 06 February 2009, Ian Lance Taylor wrote:
Jean Christophe Beyler jean.christophe.bey...@gmail.com writes:
All of these have an outer code of SET. Therefore, I'm not quite
positive of how I'm supposed to implement my rtx_cost function. Since
I don't seem to get a choice between a
Status
==
Trunk remains in Stage 4 (regression and documentation fixes mode).
GCC 4.4 will be branched when there are no open P1 regressions for 4.4
and the runtime library sources have been converted to GPLv3 with the
new licensing exception; the number of P1, P2 and P3 regressions has
been
On Mon, Feb 9, 2009 at 1:57 PM, Joseph S. Myers jos...@codesourcery.com wrote:
Status
==
Trunk remains in Stage 4 (regression and documentation fixes mode).
GCC 4.4 will be branched when there are no open P1 regressions for 4.4
and the runtime library sources have been converted to
Ian Lance Taylor:
that you are looking for. I'm not aware of any other processor which is
able to load a large constant in a single instruction, but for which an
add instruction is cheaper if there is a similar constant already
available.
Paul Brook:
This is true for Arm/Thumb. You have
--- 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)
--- 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 #8216;test#8217;:
cast.c:6: error: invalid application of #8216;sizeof#8217; to a
--- 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=gccview=revrev=144030
Log:
2009-02-09 Richard Guenther rguent...@suse.de
PR
--- 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
-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
--
http
--- 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
--- 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
--- 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, rob1weld
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
--
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 have
--- 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...
--
--- 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 and
--- 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;
--- 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);
return
--
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 END
inline void nonVararg( const char * dummy ) {}
inline void Vararg( const char * dummy, ... ) {}
int main()
{
nonVararg(Hello);
Vararg(World);
}
END
$ g++ -O2 inline_varargs.c
$
--- 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 at
--- 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.
--
--- 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, but
--- 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
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
--- 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 m...@klomp.org
* Makefile.am (libgcj_la_SOURCES): Remove
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-09 16:39 ---
Regression since http://gcc.gnu.org/viewcvs?root=gccview=revrev=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
--- 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.
--
--- 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
--- 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);
};
templatetypename _Ret, typename _Tp, typename _Arg
void
mem_fun_ref(_Ret
--- 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
--
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
--- 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... Just
--- 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 vectorTp::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
--- 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
--- 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 .
--
--- 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
--- 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 stdio.h
int jj = 0, ii = 0; //global vars
int main()
{
int j = 0, i = 0; // local vars
i -= i += 2; //
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
--- 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
--- 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=gccview=revrev=144039
Log:
PR c/39035
* real.c (do_compare): Special-case
--- 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 #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:
--- 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]$
--- 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=gccview=revrev=144042
Log:
2009-02-09 Sebastian Pop sebastian@amd.com
PR
--- 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=17274action=view)
Original code to set up hypercalls.
This is the original code Jakub distilled the reproducer from. It includes a
--- 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 syntax
--- 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
--- 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
--- 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:
--- 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=gccview=revrev=144043
Log:
2009-02-09 Jack Howarth howa...@bromo.med.uc.edu
PR
--- 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
--- 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=gccview=revrev=144044
Log:
PR c++/39109
* semantics.c
--- 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
--- 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
--- 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
1 - 100 of 110 matches
Mail list logo
