https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65464
--- Comment #10 from Markus Trippelsdorf ---
And even with !IA32_EMULATION the kernel build uses -m16 a few times on x86_64.
Please note that we're talking about -ffreestanding target here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65464
--- Comment #9 from Markus Trippelsdorf ---
(In reply to Alan Modra from comment #7)
> On x86_64-linux you can run 32-bit binaries. On powerpc64le-linux you
> can't. It's that simple. -m32 support in powerpc64le gcc, by default,
> doesn't make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60851
--- Comment #11 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Mar 20 06:07:30 2015
New Revision: 221529
URL: https://gcc.gnu.org/viewcvs?rev=221529&root=gcc&view=rev
Log:
PR rtl-optimization/60851
* recog.c (constrain_operands):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475
--- Comment #3 from Jan Hubicka ---
The following should help:
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 221528)
+++ ipa-devirt.c(working copy)
@@ -1412,9 +14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
--- Comment #22 from Jeffrey A. Law ---
Let's try to stay focused. Killing copyrename seems like a fine thing to do as
long as the resulting debug info is good. But that's independent of this BZ.
I still find myself wondering if leaving the "0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65483
Jan Hubicka changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65483
--- Comment #1 from Jan Hubicka ---
Benchmarking build with -O3 -flto -Ofast -funroll-loops
For mainline I get (running on input.graphic)
real0m35.673s
user0m35.556s
sys 0m0.133s
and setting early-inlining-insns=80 to get bsR/bsW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484
Bug ID: 65484
Summary: FAIL: g++.dg/vect/pr36648.cc on powerpc64
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65483
Bug ID: 65483
Summary: bzip2 bsR/bsW should be auto-inlined
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65449
--- Comment #4 from ma.jiang at zte dot com.cn ---
Hi Bernd,
Thanks for your apply.
(In reply to Bernd Edlinger from comment #3)
> Yes, but that is not the fault of the strict volatile code path any more.
// Sure,I agree with you. The redundan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65482
Bug ID: 65482
Summary: -mno-allow-movmisalign undocumented
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65481
--- Comment #1 from Andrew Pinski ---
contrib/gcc_update --touch is usually used to fix this problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466
--- Comment #4 from joseph at codesourcery dot com ---
On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466
>
> --- Comment #3 from Manuel López-Ibáñez ---
> (In reply to jos...@codesourcery.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65481
Bug ID: 65481
Summary: _Pragma GCC dependency broken on powerpc64
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preproce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Jan Hubicka changed:
What|Removed |Added
Component|tree-optimization |ipa
Summary|crafty performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466
--- Comment #3 from Manuel López-Ibáñez ---
(In reply to jos...@codesourcery.com from comment #2)
> On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote:
>
> > (If I was re-doing that patch again, I will try to overload inform(),
> > because
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479
--- Comment #1 from Martin Sebor ---
The same problem is causing failures in the following tests on these targets:
c-c++-common/asan/misalign-2.c
c-c++-common/asan/null-deref-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466
--- Comment #2 from joseph at codesourcery dot com ---
On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote:
> (If I was re-doing that patch again, I will try to overload inform(), because
> inform_with_flags is just too much typing).
Note that d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65480
Bug ID: 65480
Summary: libstdc++-prettyprinters/libfundts.cc test failures on
powepc64
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #2 from joseph at codesourcery dot com ---
The issue is that someone needs to go through all the parsing for OpenMP
constructs, and figure out exactly where to add calls to
convert_lvalue_to_rvalue (if an OpenMP construct reads the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65443
--- Comment #6 from vries at gcc dot gnu.org ---
After looking into it a bit further, I think what we're trying to get is:
...
:
goto ;
:
i_17 = (int) ivtmp_y;
_7 = (long unsigned int) i_17;
_8 = _7 * 4;
_9 = pretmp_24 + _8;
_10 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65464
--- Comment #8 from Matthias Klose ---
Alan told me that you can work around it by configuring with
--enable-targets=powerpcle-linux --disable-multilib
to still have the -m32 option recognized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #8 from David ---
(In reply to Kai Tietz from comment #7)
The first code block in comment #6 is what is in the code now. As you can see,
it already has the #define you are describing. I don't understand what you
mean by "change it t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939
--- Comment #6 from Zoltan Hidvegi ---
gcc collect2 links the programs twice, first it links just all the object and
archive files passed, then it parses the output and if necessary creates a
source file that contains information about static con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65240
Michael Meissner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65240
--- Comment #15 from Michael Meissner ---
Author: meissner
Date: Thu Mar 19 22:37:33 2015
New Revision: 221524
URL: https://gcc.gnu.org/viewcvs?rev=221524&root=gcc&view=rev
Log:
[gcc]
2015-03-19 Michael Meissner
PR target/65240
* con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479
Bug ID: 65479
Summary: sanitizer stack trace missing frames past #0 on
powerpc64
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65474
--- Comment #3 from wmi at google dot com ---
Thanks. You are right. I wrote a microbenchmark (attached), and tested it on
different intel microarchitectures.
westmere:
1.gcc.out:19.42
1.llvm.out: 19.32
sandybridge:
1.gcc.out:18.61
1.l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65474
--- Comment #2 from wmi at google dot com ---
Created attachment 35069
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35069&action=edit
microbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456
--- Comment #7 from Anton Blanchard ---
Thanks Martin.
Bill: the swaps pass isn't catching our vectorised copy, I guess because of the
adds in the loop:
lxvd2x 0,9,4
addi 28,1,-48
add 6,9,10
xxpermdi 12,0,0,2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Jan Hubicka changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Bug ID: 65478
Summary: crafty performance regression
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65464
--- Comment #7 from Alan Modra ---
On x86_64-linux you can run 32-bit binaries. On powerpc64le-linux you can't.
It's that simple. -m32 support in powerpc64le gcc, by default, doesn't make
sense until we have
- supported and tested compat layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65477
Bug ID: 65477
Summary: gnat is built with nodlopen
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: ada
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198
--- Comment #25 from Paul Thomas ---
Author: pault
Date: Thu Mar 19 20:12:29 2015
New Revision: 221523
URL: https://gcc.gnu.org/viewcvs?rev=221523&root=gcc&view=rev
Log:
2014-03-19 Paul Thomas
PR fortran/59198
* trans-types.c (gfc_ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63491
--- Comment #13 from Vladimir Makarov ---
Author: vmakarov
Date: Thu Mar 19 19:59:38 2015
New Revision: 221522
URL: https://gcc.gnu.org/viewcvs?rev=221522&root=gcc&view=rev
Log:
2015-03-19 Vladimir Makarov
PR rtl-optimization/63491
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59739
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65476
Bug ID: 65476
Summary: Long_Float array does not byte swap correctly when set
to Scalar_Storage_Order with High Order First
Product: gcc
Version: 5.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65046
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470
--- Comment #5 from Daniel Krügler ---
(In reply to aral from comment #3)
> I don't argue that it might be a misunderstanding of the user, hence my
> suggestion 1) - however, I disagree with your wording "clearly documented"
> as far as
>
> (a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65046
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Thu Mar 19 19:31:48 2015
New Revision: 221521
URL: https://gcc.gnu.org/viewcvs?rev=221521&root=gcc&view=rev
Log:
PR c++/65046
Automatically propagate ABI tags to variables and fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470
--- Comment #4 from aral at gmx dot de ---
Addition: after you referred to the properties of match_results, I had a look
at
http://en.cppreference.com/w/cpp/regex/match_results
which has a clearer wording. However, I still think this clear sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475
--- Comment #1 from Martin Liška ---
In odr_vtable_hasher::equal:
585 t2 = TYPE_MAIN_VARIANT (t2);
586 if (t1 == t2)
587return true;
588 tree v1 = BINFO_VTABLE (TYPE_BINFO (t1));
589 tree v2 = BINFO_VTABLE (TYPE_BINFO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470
--- Comment #3 from aral at gmx dot de ---
I don't argue that it might be a misunderstanding of the user, hence my
suggestion 1) - however, I disagree with your wording "clearly documented" as
far as
(a) http://en.cppreference.com/w/cpp/regex/reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475
Bug ID: 65475
Summary: [5 Regression] ICE in odr_vtable_hasher::equal
(Segmentation fault)
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65474
Andrew Pinski changed:
What|Removed |Added
Target||i?86-*-* x86_64-*-*
Component|m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456
--- Comment #6 from Martin Sebor ---
Created attachment 35066
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35066&action=edit
Assembly emitted by gcc 5.0.0 20150319 after aplying the patch referenced in
comment #5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65474
Bug ID: 65474
Summary: sub-optimal code for __builtin_abs
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572
howarth at bromo dot med.uc.edu changed:
What|Removed |Added
CC||howarth at bromo dot med
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62051
--- Comment #5 from Jan Hubicka ---
yep, this seems to be the usual situation where visibilities does not mix that
well with assumptions that program is linked with symbols defined in the
headers.
I suppose we could make C++ FE to track if a typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65238
--- Comment #9 from Jakub Jelinek ---
Patch awaiting ack:
http://gcc.gnu.org/ml/gcc-patches/2015-03/msg00647.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65303
Bug 65303 depends on bug 65380, which changed state.
Bug 65380 Summary: [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1,
at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65465
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380
--- Comment #15 from Martin Liška ---
Author: marxin
Date: Thu Mar 19 17:37:15 2015
New Revision: 221519
URL: https://gcc.gnu.org/viewcvs?rev=221519&root=gcc&view=rev
Log:
Fix PR ipa/65380.
PR ipa/65380
* ipa-icf.c (sem_function::merge)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
--- Comment #12 from Jakub Jelinek ---
For the early objsz pass, I'm afraid it can have security implications.
Artificial testcase:
extern char *strcpy (char *__restrict __dest, const char *__restrict __src)
__attribute__ ((__nothrow__ , __leaf__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65465
--- Comment #6 from Martin Liška ---
Author: marxin
Date: Thu Mar 19 17:35:52 2015
New Revision: 221518
URL: https://gcc.gnu.org/viewcvs?rev=221518&root=gcc&view=rev
Log:
Fix for PR ipa/65465.
PR ipa/65465
* cgraphunit.c (cgraph_node::c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62051
--- Comment #4 from Jason Merrill ---
So what's happening here is that the compiler sees that *m is a Derived, so it
can devirtualize the destructor call to ~Derived, and ~Derived refers to the
vtable.
One solution would be to give ~Derived defa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
--- Comment #6 from Manuel López-Ibáñez ---
*** Bug 65472 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472
Manuel López-Ibáñez changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #7 from Manu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46582
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17534
Manuel López-Ibáñez changed:
What|Removed |Added
CC||d.g.gorbachev at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65465
--- Comment #5 from Jakub Jelinek ---
Reduced testcase:
struct A {};
struct B { virtual A foo () const; };
struct C { A foo () const; };
struct D : virtual B { A foo () const {} };
struct F : D { virtual int bar () const; };
int F::bar () const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472
Ulya changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #6 from Ulya ---
(In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
Manuel López-Ibáñez changed:
What|Removed |Added
CC||skvadrik at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472
Ulya changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #4 from Ulya ---
So GCC's inte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65473
Bug ID: 65473
Summary: Including does not define __GLIBCXX__
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472
--- Comment #2 from Ulya ---
$ gcc -W -Wall -Wextra -c 1.c
gives the same result: no warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472
Bug ID: 65472
Summary: -Wunreachable-code failure
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63230
--- Comment #5 from vehre at gcc dot gnu.org ---
Fix available with:
https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html
https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html
https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57456
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #5 from ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64787
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #3 from ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65465
--- Comment #4 from Martin Liška ---
Patch I've been testing:
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index e640907..8b7d056 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -2484,8 +2484,9 @@ cgraph_node::create_wrapper (cgraph_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Component|target |middle-end
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62255
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65464
--- Comment #6 from Markus Trippelsdorf ---
(In reply to Matthias Klose from comment #5)
> > Well, on x86_64 if you build gcc with --disable-multilib you still
> > can compile with -m32 (even without a 32-bit user runtime).
> > Why should this be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65464
--- Comment #5 from Matthias Klose ---
> Well, on x86_64 if you build gcc with --disable-multilib you still
> can compile with -m32 (even without a 32-bit user runtime).
> Why should this be different on ppc64le?
$ gcc -m32 -c foo.c
foo.c:1:0: e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356
Jason Merrill changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #16 from Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65457
Bernd Edlinger changed:
What|Removed |Added
Target||arm-linux-gnueabihf
Component|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65471
Bug ID: 65471
Summary: type interpretation in _Generic
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65449
--- Comment #3 from Bernd Edlinger ---
Yes, but that is not the fault of the strict volatile code path any more.
For bit-fields this redundant read is exactly what AAPCS demands:
"7.1.7.5 Volatile bit - fields preserving number and width of con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
Richard Biener changed:
What|Removed |Added
Known to work|5.0 |
Summary|[4.9 Regression] me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
--- Comment #10 from Richard Biener ---
Author: rguenth
Date: Thu Mar 19 13:36:18 2015
New Revision: 221515
URL: https://gcc.gnu.org/viewcvs?rev=221515&root=gcc&view=rev
Log:
2015-03-19 Richard Biener
Revert
2015-03-10 Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65459
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #55 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
--- Comment #11 from Richard Biener ---
Created attachment 35064
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35064&action=edit
patch
I am testing the attached, testcases to be ameded from the dups.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63230
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
--- Comment #10 from Richard Biener ---
I do think that the gimplifiers "folding" is premature. All propagators know
to apply the trick internally. This premature folding is probably to avoid
regressions with removing the invalid maybe_fold_* s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
--- Comment #9 from Jakub Jelinek ---
For the option of not folding this to MEM_REFs before objsz pass, I'd note this
could be just about the &MEM_REF cases, if there is an actual memory access, so
we aren't taking the address of the MEM_REF, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
--- Comment #8 from Jakub Jelinek ---
So, given that you promoted this to P1, what are we going to do with this?
This indeed started with r214941, and from objsz POV, in *.original, while it
changed from:
- strcpy (&a.buf1[4], str1 + 5);
+ str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52659
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52659
--- Comment #2 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Thu Mar 19 11:02:47 2015
New Revision: 221513
URL: https://gcc.gnu.org/viewcvs?rev=221513&root=gcc&view=rev
Log:
2015-03-19 Paolo Carlini
PR c++/52659
* g++.dg/cpp0
1 - 100 of 154 matches
Mail list logo
