--- Comment #11 from howarth at nitro dot med dot uc dot edu 2010-03-12
04:06 ---
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00472.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36399
--- Comment #9 from ilatypov at infradead dot org 2010-03-12 03:49 ---
(In reply to comment #7)
> I am reopening the bug cause I still don't have a clue why "pointer to array
> of
> ints" typed expression is assignment incompatible with a "pointer to array of
> const ints" typed lvalue.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #6 from jason at gcc dot gnu dot org 2010-03-12 02:48 ---
strPOD isn't trivial; its copy assignment operator is ill-formed/deleted. This
is a change in PODness between C++98 and C++0x which may not have been
intended.
--
jason at gcc dot gnu dot org changed:
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #3 from manu at gcc dot gnu dot org 2010-03-12 00:15 ---
Created an attachment (id=20091)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20091&action=view)
patch
This is my current patch to fix this. However, it has a big problem: Since
there is no "namespace" for optio
In this case the variable i should be shared except in the task
construct that contains the do loop on i.
Test case:
program F03_2_9_1_1_5a
use omp_lib
implicit none
integer, parameter :: NT = 4
integer, parameter :: EXPECTED_RESULT = -1 ! expected value of i at end
integer :: dumm
Test case:
program F03_2_9_3_5_2b
use omp_lib
implicit none
integer, parameter :: NT = 4
integer, parameter :: int64_t = selected_int_kind(18)
integer (kind=int64_t), parameter::DYNAMIC_MEMORY = 536870912_int64_t
!512MiB
integer (kind=int64_t), parameter::ARRAY_SIZE = DYNAMIC_MEM
Test case:
program F03_2_9_1_1_2b
use omp_lib
implicit none
integer, parameter :: NT = 4
integer :: explicit_shape_array(NT,0:NT-1) = -1 ! invalid value
integer :: row, thread_num
call omp_set_dynamic(.false.)
call omp_set_num_threads(NT)
call test_assumed_size_array(expl
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-03-11 22:39 ---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-03-11 22:27 ---
Subject: Bug 43257
Author: jamborm
Date: Thu Mar 11 22:27:26 2010
New Revision: 157393
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157393
Log:
2010-03-11 Martin Jambor
PR tree-optimization/432
--- Comment #4 from gmcgrath at yahoo dot com 2010-03-11 21:48 ---
Bug 37188 answers half the problem. It still does not answer why:
register int16x8_t val asm ("q0");
compiles without warning yet does not put "val" into the "q0" NEON register.
--
gmcgrath at yahoo dot com cha
--- Comment #5 from hjl dot tools at gmail dot com 2010-03-11 21:12 ---
It is caused by revision 149721:
http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00602.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #2 from manu at gcc dot gnu dot org 2010-03-11 21:10 ---
James, you probably can implement this as a GCC plugin, not native or forked
GCC needed, as Andrew said.
But, in any case, you should seek developers from outside the core GCC for your
project (and if possible, bring
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-11 20:32 ---
(In reply to comment #2)
> When documentation is missing the needed bits information, these can be
> typically extracted from the source code.
>
> The only problem is that these constraints can be changed any time w
--- Comment #2 from siarhei dot siamashka at gmail dot com 2010-03-11
20:29 ---
When documentation is missing the needed bits information, these can be
typically extracted from the source code.
The only problem is that these constraints can be changed any time without
notice unless pro
--- Comment #14 from meissner at gcc dot gnu dot org 2010-03-11 20:11
---
Created an attachment (id=20090)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20090&action=view)
Patch to remove band-aid now that the underlying problem was fixed
In doing the initial VSX development, I r
--- Comment #2 from hjl dot tools at gmail dot com 2010-03-11 20:06 ---
*** Bug 41931 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from hjl dot tools at gmail dot com 2010-03-11 20:06 ---
*** This bug has been marked as a duplicate of 43336 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-11 20:01 ---
I think instead of creating the _1 functions you should just add the attr
argument to those 2 functions and modify callers to pass DW_AT_const_value.
There aren't so many callers, and
add_location_or_const_value_attrib
--- Comment #18 from burnus at gcc dot gnu dot org 2010-03-11 19:48 ---
Close as FIXED. Thanks for the bugreport!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from burnus at gcc dot gnu dot org 2010-03-11 19:48 ---
Subject: Bug 43228
Author: burnus
Date: Thu Mar 11 19:48:11 2010
New Revision: 157391
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157391
Log:
2010-03-11 Tobias Burnus
PR fortran/43228
--- Comment #11 from pluto at agmk dot net 2010-03-11 19:33 ---
(In reply to comment #8)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew?
> >
> > no, what for? svn status reports no unversioned files in trunk
--- Comment #10 from pluto at agmk dot net 2010-03-11 19:29 ---
Created an attachment (id=20089)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20089&action=view)
build script.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43328
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-03-11
19:29 ---
Created an attachment (id=20088)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20088&action=view)
Patch
This "mustard plaster" helps me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43336
--- Comment #9 from pluto at agmk dot net 2010-03-11 19:28 ---
Created an attachment (id=20087)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20087&action=view)
build log for very very clean source tree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43328
$ gcc -flto -fuse-linker-plugin something.c
$ ls /tmp
ccMec0Js.lto.o
--
Summary: GCC leaves a temporary LTO output file in $TMPDIR
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ot
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-03-11
19:26 ---
Created an attachment (id=20086)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20086&action=view)
Patch
I use this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43335
To reproduce the bug,
[ rename temporarily the lto-wrapper program ]
$ gcc -fuse-linker-plugin something.c
Segmentation fault
--
Summary: Driver crashes dereferencing a null pointer if it can't
find lto-wrapper
Product: gcc
Version: 4.5.0
--- Comment #8 from rwild at gcc dot gnu dot org 2010-03-11 18:33 ---
(In reply to comment #5)
> (In reply to comment #4)
> > Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew?
>
> no, what for? svn status reports no unversioned files in trunk directory.
Please allow me t
--- Comment #7 from pluto at agmk dot net 2010-03-11 18:21 ---
(In reply to comment #6)
> > no, what for? svn status reports no unversioned files in trunk
> > directory.
>
> Svn status does not report .o files normally.
my ~/.subversion/config has custom global-ignores and i know wha
--- Comment #6 from pinskia at gmail dot com 2010-03-11 18:15 ---
Subject: Re: multilib bootstrap broken.
Sent from my iPhone
On Mar 11, 2010, at 10:11 AM, "pluto at agmk dot net" wrote:
>
>
> --- Comment #5 from pluto at agmk dot net 2010-03-11 18:11
> ---
> (In reply
Sent from my iPhone
On Mar 11, 2010, at 10:11 AM, "pluto at agmk dot net" > wrote:
--- Comment #5 from pluto at agmk dot net 2010-03-11 18:11
---
(In reply to comment #4)
Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew?
no, what for? svn status reports no unv
--- Comment #5 from pluto at agmk dot net 2010-03-11 18:11 ---
(In reply to comment #4)
> Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew?
no, what for? svn status reports no unversioned files in trunk directory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43328
--- Comment #1 from pinskia at gmail dot com 2010-03-11 17:37 ---
Subject: Re: New: Generate an XML dump of the parse tree
Sent from my iPhone
On Mar 11, 2010, at 8:26 AM, "jrevans1 at earthlink dot net"
wrote:
> Essentially I would like a feature similair to gccxml
> (www.gccx
Sent from my iPhone
On Mar 11, 2010, at 8:26 AM, "jrevans1 at earthlink dot net" > wrote:
Essentially I would like a feature similair to gccxml
(www.gccxml.org) that is
officially blessed and native to the compiler instead of some out-of-
date hack.
If a feature like this were to be offici
--- Comment #4 from redi at gcc dot gnu dot org 2010-03-11 17:12 ---
it's both trivial and standard layout, so is a POD
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #3 from pinskia at gmail dot com 2010-03-11 17:01 ---
Subject: Re: New: __is_pod seems broken
Sent from my iPhone
On Mar 11, 2010, at 8:03 AM, "matz at gcc dot gnu dot org"
wrote:
> On r157245 (and former revisions) this testcase will abort:
> # cat ispod.cc
> struct
Sent from my iPhone
On Mar 11, 2010, at 8:03 AM, "matz at gcc dot gnu dot org" > wrote:
On r157245 (and former revisions) this testcase will abort:
# cat ispod.cc
struct strPOD
{
const char *const foo;
const char *const bar;
};
I don't think this is a pod as it requires a non trivial con
--- Comment #36 from ghazi at gcc dot gnu dot org 2010-03-11 17:00 ---
I'm seeing failures for gcc.dg/torture/asm-subreg-1.c on
armv5tel-unknown-linux-gnueabi on mainline and 4.4/4.3 branches when using
-fpic or -fPIC and optimizing. See:
http://gcc.gnu.org/ml/gcc-testresults/2010-03/m
--- Comment #2 from paolo dot carlini at oracle dot com 2010-03-11 16:41
---
I would be willing to work on this, of course, but I can't really do it now
because I'm traveling and I don't have with me all the tools I need.
Anyway, we do already have a testcase involving a pair of double
Essentially I would like a feature similair to gccxml (www.gccxml.org) that is
officially blessed and native to the compiler instead of some out-of-date hack.
If a feature like this were to be officially supported, it would open the doors
to many applications who might want to use the gcc to parse
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-11 16:24 ---
Confirmed. 4.4 works as well.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dodji at gcc dot gnu dot org 2010-03-11 16:17 ---
Created an attachment (id=20085)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20085&action=view)
Draft patch
Please find below a copy/paste of the introductory comment of the attached
patch.
Basically the valu
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-11 16:08 ---
Created an attachment (id=20084)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20084&action=view)
gcc45-pr43329.patch
Updated patch that also fixes remove_forwarder_block and adds a testcase.
--
jakub at gcc
--- Comment #16 from burnus at gcc dot gnu dot org 2010-03-11 16:06 ---
Subject: Bug 43228
Author: burnus
Date: Thu Mar 11 16:06:37 2010
New Revision: 157389
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157389
Log:
2010-03-11 Tobias Burnus
PR fortran/43228
--- Comment #4 from rwild at gcc dot gnu dot org 2010-03-11 16:06 ---
Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43328
On r157245 (and former revisions) this testcase will abort:
# cat ispod.cc
struct strPOD
{
const char *const foo;
const char *const bar;
};
extern "C" void abort (void);
int main ()
{
if (!__is_pod (strPOD))
abort ();
return 0;
}
This manifests itself in blocxx not compiling with gcc 4
--- Comment #3 from pluto at agmk dot net 2010-03-11 16:02 ---
(In reply to comment #2)
> Quoting install.texi:
>
> First, we @strong{highly} recommend that GCC be built into a
> separate directory from the sources which does @strong{not} reside
> within the source tree. This is how we
--- Comment #3 from burnus at gcc dot gnu dot org 2010-03-11 15:58 ---
Created an attachment (id=20083)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20083&action=view)
Lightly tested patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43331
--- Comment #2 from rwild at gcc dot gnu dot org 2010-03-11 15:46 ---
Quoting install.texi:
First, we @strong{highly} recommend that GCC be built into a
separate directory from the sources which does @strong{not} reside
within the source tree. This is how we generally build GCC; buildi
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-11 15:21 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from mikpe at it dot uu dot se 2010-03-11 15:19 ---
Created an attachment (id=20082)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20082&action=view)
backport of Adam Nemet's STRIP_NOPS patch to gcc-4.4.3
I've backported Adam Nemet's STRIP_NOPS patch in r148631 to g
This can be related to pr42941
Command line:
gcc -fschedule-insns -fsched-pressure testcase.c
testcase.c
extern void exit(int);
int main(int argc, char *argv[])
{
exit(0);
}
gcc has to be compiled with valgrind checking to show this warning:
$ valgrind -q
--- Comment #2 from dominiq at lps dot ens dot fr 2010-03-11 15:10 ---
What is done for assumed-size arrays such as a(*)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43331
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-11 15:08 ---
Subject: Bug 43255
Author: rguenth
Date: Thu Mar 11 15:08:24 2010
New Revision: 157388
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157388
Log:
2010-03-11 Richard Guenther
PR tree-optimization/
--- Comment #1 from burnus at gcc dot gnu dot org 2010-03-11 14:50 ---
I think the "1" comes about due to the following. That can either leave that
part as is and change it back in in trans*.c via "cp_was_assumed" -- or one
removes that part and sees what will break ;-)
>From decl.c:
/
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-11 14:46 ---
Created an attachment (id=20081)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20081&action=view)
gcc45-pr43329.patch
This patch worked on this testcase. Note that the missing min (and this) DEBUG
stmts are cau
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2010-03-11 14:35
---
Closing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|A
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2010-03-11 14:25
---
yes, you have to be careful as you increment through the indexes to not
overwrite a previous good initialization of end. I suspect there is at least
one other bug in there while you are at it. :)
--
http:/
--- Comment #15 from hjl dot tools at gmail dot com 2010-03-11 14:24
---
You can find my SPEC CPU pass/fail results at
http://gcc.gnu.org/ml/gcc-testresults/
The last one is
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg00855.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-03-11 14:24
---
(In reply to comment #9)
> Should we apply the patch from comment 7 before gcc 4.5 branches?
Well, you certainly need to follow patch submission rules. Thus, post
to gcc-patches w/ a changelog entry and stating h
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2010-03-11 14:20
---
If someone confirms SPEC is cleared, please close.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2010-03-11
14:13 ---
Should we apply the patch from comment 7 before gcc 4.5 branches?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36399
--- Comment #8 from krebbel at gcc dot gnu dot org 2010-03-11 14:06 ---
(In reply to comment #6)
> Why does the new testcase have
>
> +/* { dg-require-effective-target lp64 } */
>
> when the failure is shown with -m32 on x86-64?
>
I've removed that in the new version. Thanks!
--
--- Comment #1 from spop at gcc dot gnu dot org 2010-03-11 13:56 ---
Fixed as shown by the automatic tester results today:
http://groups.google.com/group/gcc-graphite-test/browse_thread/thread/cd55ed193db3862a#
--
spop at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from krebbel at gcc dot gnu dot org 2010-03-11 13:51 ---
Subject: Bug 43280
Author: krebbel
Date: Thu Mar 11 13:51:00 2010
New Revision: 157386
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157386
Log:
2010-03-11 Andreas Krebbel
PR tree-optimization/4
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-11 13:14 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-11 13:14 ---
Subject: Bug 43200
Author: rguenth
Date: Thu Mar 11 13:13:53 2010
New Revision: 157385
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157385
Log:
2010-03-11 Richard Guenther
PR lto/43200
--- Comment #5 from redi at gcc dot gnu dot org 2010-03-11 13:12 ---
Yes, I saw your mail to the std reflector. As I said in my reply there, I
don't understand the rules, but GCC seems to be following them correctly.
Closing this bug.
--
redi at gcc dot gnu dot org changed:
--- Comment #3 from jakub at gcc dot gnu dot org 2010-03-11 13:02 ---
Wonder why we do
548VEC_safe_push (tree, gc, *nonlocalized_list, origin_var);
instead of
548VEC_safe_push (tree, gc, *nonlocalized_list, old_var);
The latter perhaps would need some adjustments in dwarf2out.c,
--- Comment #14 from burnus at gcc dot gnu dot org 2010-03-11 12:58 ---
Mine! I now do as written in comment #13 - except for the "if" which is not
needed (it use the wrong index and wouldn't work anyhow) - and except for
moving it down a bit.
--
burnus at gcc dot gnu dot org changed
--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-11 12:53 ---
The problem is that with early inlining, method (&inst, 24) call is inlined
into
call function, then at the end of einline during arrg3 and min vars in call are
removed as unused locals by remove_unused_locals (the inl
--- Comment #13 from manu at gcc dot gnu dot org 2010-03-11 12:50 ---
And if the patch fixes a PR, it is better to link to the patch from the
original PR and add the PR to the list of bugs that this PR depend on (you can
use the alias "4.6" in the field "Bug X blocks" of your PR).
--
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-11 12:34 ---
That's not a bug. Unlike x86-64, on i?86 when calling (or jumping to) a PLT
slot in position independent code %ebx must be set to the calling function's
PIC pointer. As %ebx is call saved register, this precludes sib
--- Comment #4 from boostcpp at gmail dot com 2010-03-11 12:26 ---
It looks like gcc is correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43315
--- Comment #65 from ubizjak at gmail dot com 2010-03-11 12:18 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-11 12:13 ---
Works on linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43324
I have a patch that exposes this and causes a "miscompile" of
gfortran.dg/cray_pointers_2.f90. Reduced testcase:
! { dg-do run }
! { dg-options "-fcray-pointer -fbounds-check" }
! Series of routines for testing a Cray pointer implementation
program craytest
call ptr5
end program craytest
subro
--- Comment #3 from eric dot niebler at gmail dot com 2010-03-11 11:56
---
Oops, it's not an aggregate. Disregard.
--
eric dot niebler at gmail dot com changed:
What|Removed |Added
--
--- Comment #2 from eric dot niebler at gmail dot com 2010-03-11 11:53
---
You're right. Let me amend my example.
struct S
{
S() = default;
S(S const &) = default;
S(int i) : i(i) {}
int i;
};
S const s {1};
S would seem to satisfy the requirements for a trivi
--- Comment #1 from pinskia at gmail dot com 2010-03-11 11:41 ---
Subject: Re: New: trivial types are not being statically initialized
Sent from my iPhone
On Mar 11, 2010, at 3:24 AM, "eric dot niebler at gmail dot com"
wrote:
> According to the C++0x status page
> (http://gcc.gn
Sent from my iPhone
On Mar 11, 2010, at 3:24 AM, "eric dot niebler at gmail dot com" > wrote:
According to the C++0x status page
(http://gcc.gnu.org/gcc-4.5/cxx0x_status.html), "Standard Layout
Types"
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm)
have been
implement
According to the C++0x status page
(http://gcc.gnu.org/gcc-4.5/cxx0x_status.html), "Standard Layout Types"
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm) have been
implemented in gcc-4.5. A quick test shows that trivial types are not being
statically initialized, as the paper r
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-03-11 11:19 ---
+ ops_arr[op_num] = build1 (NOP_EXPR,
+ TREE_TYPE (gimple_assign_lhs
+(neg)),
+
--- Comment #6 from burnus at gcc dot gnu dot org 2010-03-11 11:12 ---
FIXED on the trunk (4.5) and the 4.4 branch. Thanks for the bug report!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from burnus at gcc dot gnu dot org 2010-03-11 11:10 ---
Subject: Bug 43303
Author: burnus
Date: Thu Mar 11 11:10:37 2010
New Revision: 157383
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157383
Log:
2010-03-11 Tobias Burnus result.
2010-03-11 Tobias Burnus
--- Comment #13 from burnus at gcc dot gnu dot org 2010-03-11 11:08 ---
(In reply to comment #10)
> I plan to commit the following as a compromise. We have had several PRs here
> that contradict.
I am not sure whether the PRs really contradict as they just ask "do what the
other compil
--- Comment #5 from pluto at agmk dot net 2010-03-11 09:40 ---
recent 4.5.0 sibcalls this on x86-64 only:
/opt/gcc45/bin/g++45 t.cpp -O2 -S -m64 -fpie -o t64.s
_Z1gc:
.cfi_startproc
subq$131080, %rsp
.cfi_def_cfa_offset 131088
movl$131072, %edx
--- Comment #12 from kaushik dot phatak at kpitcummins dot com 2010-03-11
09:08 ---
> Rather than attach patches here, it would be better to link to the mailing
> message where the patch was approved.
Understood. This patch has been approved,
http://gcc.gnu.org/ml/gcc-patches/2010-03/m
--- Comment #8 from mkuvyrkov at gcc dot gnu dot org 2010-03-11 08:57
---
Created an attachment (id=20080)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20080&action=view)
Fixed and tested patch
Well, sure enough the initial patch had an error: `(-a) + (-b)' was getting
optimized
91 matches
Mail list logo
