https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64688
--- Comment #15 from Markus Trippelsdorf ---
Please note that 4.9.2 is also affected, so a backport would be appreciated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64875
--- Comment #2 from Daniel Gutson
---
inline is as useful in c++ as in C regardless of ODR or any other reason but
its original purpose: performance.I want to know when my hint is not honored
which is the exact intent of this warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64688
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #12 from Jonathan Wakely ---
N.B. trivially-copyable is not the same as trivial (and there are separate type
traits for testing those two properties).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #11 from Jonathan Wakely ---
(In reply to Tom Tromey from comment #9)
> However my belief is that because this class has a user-provided
> default constructor, it is not trivial.
True, but ...
> I tested this by adding "#include " a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63493
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63560
--- Comment #3 from Ian Lance Taylor ---
Was the patch in comment #1 ever committed? I don't see it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64875
--- Comment #1 from Jonathan Wakely ---
I don't think this warning is very relevant to C++.
In C++ 'inline' is more useful for telling the compiler that the function may
be defined in mutiple translation units, and that is typically more importa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64001
--- Comment #5 from Ian Lance Taylor ---
Just a note that I have not been able to reproduce this. I ran the program
from comment #1 50 times with no failures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
--prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20150130 (experimental) [trunk revision 220273] (GCC)
$
$ gcc-trunk -O3 -c small.c
$ gcc-trunk -O2 -g -c small.c
$ gcc-4.9 -O3 -g -c small.c
$
$ gcc-trunk -O3 -g -c small.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64431
Eugene Zelenko changed:
What|Removed |Added
CC||eugene.zelenko at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #17 from Nathan Sidwell ---
I'm having difficulty constructing a testcase that fails. 2 DSOs are isolated
as I expect. (rong, your description is essentially correct).
A recipe would be good. Also, is this on gcc trunk or gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64797
--- Comment #5 from howarth at bromo dot med.uc.edu ---
(In reply to Dominique d'Humieres from comment #4)
> The test has been introduced at r219780. The first failure I see is for
> r219808 (the previous tested revision is r219776). It is likely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #16 from xur at google dot com ---
I did not follow the trunk version closely. But from reading the code, I
think the design is each DSO uses its own copy of gcov_* functions
(including gcov_open and gcov_read_counter) and accesses its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64688
--- Comment #13 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Jan 30 22:22:58 2015
New Revision: 220297
URL: https://gcc.gnu.org/viewcvs?rev=220297&root=gcc&view=rev
Log:
2015-01-30 Vladimir Makarov
PR target/64688
* lra-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64872
--- Comment #2 from Jan Hubicka ---
Created attachment 34630
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34630&action=edit
Patch I am testing
The problem is that ICF merge profiles and profile merging sometimes nukes the
function body m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717
--- Comment #6 from Gert-jan Los ---
I want to confirm that all false warnings in my code are fixed by your patch.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
--- Comment #3 from Sebastian Pop ---
-fdbg-cnt=registered_jump_thread:44 passes
-fdbg-cnt=registered_jump_thread:45 fails
So this is the jump thread that produces the wrong code:
Registering FSM jump thread: (10, 114) incoming edge; (4, 93) n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
--- Comment #2 from Sebastian Pop ---
Jump threading is called twice as two separate passes, the "miscompiled" jump
thread during the first invocation is:
Registering FSM jump thread: (10, 114) incoming edge; (4, 93) nocopy;
The "miscompiled"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
--- Comment #1 from Sebastian Pop ---
It fails with -O2 --param max-fsm-thread-paths=10 and does not fail with 9.
This is the thread that generates wrong code:
Registering FSM jump thread: (102, 6) incoming edge; (5, 128) nocopy;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472
--- Comment #7 from Benjamin Braun ---
A workaround for the code at the top of this thread is to wrap the transaction
in the loop with a function and instead call that function from the loop.
This workaround also works for the case given in dup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61599
Uroš Bizjak changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472
--- Comment #6 from torvald at gcc dot gnu.org ---
(In reply to ak from comment #4)
> copy_bbs:
>
> (illegal code due to goto into transaction?)
>
> g_56[];
> fn1() {
> int *p_79;
> if (g_56[7])
> __transaction_atomic {
> lbl_196:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64872
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53949
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64617
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349
Dominique d'Humieres changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64311
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64617
Uroš Bizjak changed:
What|Removed |Added
CC||ubizjak at gmail dot com
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472
Benjamin Braun changed:
What|Removed |Added
CC||bjmnbraun at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64879
Benjamin Braun changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64880
Bug ID: 64880
Summary: OpenACC gcc/g++ Discrepancy
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64879
Bug ID: 64879
Summary: ICE for -O3 when calling a transactional method from a
transaction inside a for loop
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64877
--- Comment #3 from Tom Tromey ---
Oops, had the wrong gcc in $PATH.
That test case does warn:
pokyo. g++ -std=c++11 -c -Wall -Waddress -O2 x.cc
x.cc: In instantiation of ‘S::S() [with Derived = T]’:
x.cc:19:8: required from here
x.cc:9:29: wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64877
--- Comment #2 from Tom Tromey ---
(In reply to Manuel López-Ibáñez from comment #1)
> Hard to say without a minimized testcase.
Yeah.
The original code is here:
https://dxr.mozilla.org/mozilla-central/source/gfx/gl/ScopedGLHelpers.h#35
My a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64873
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810
--- Comment #21 from David Malcolm ---
*** Bug 64873 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64877
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326
--- Comment #4 from Jan Hubicka ---
make_forwarder_block is definitely wrong on not capping. But I do not see how
vectorizing can get us to a frequncy over FREQ_MAX? So probably some earlier
bug in there too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #15 from Jan Hubicka ---
> No. Each dso's gcov machinery is individually invoked. There should be no
> cross-dso accessing of data (beyond the global chain of dso)
I am not saying my fix is correct, just lets me to continue in train
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63923
iverbin at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64617
--- Comment #3 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Jan 30 17:47:44 2015
New Revision: 220294
URL: https://gcc.gnu.org/viewcvs?rev=220294&root=gcc&view=rev
Log:
2015-01-30 Vladimir Makarov
PR target/64617
* lra-constr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #9 from Tom Tromey ---
> Are you sure that class is not trivial which is why gcc is not warning about
> it? C++11 does not really have pod and non-pod any more but rather trivial
> and non-trivial and the rules has chnaged with respe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
Bug ID: 64878
Summary: [5 Regression] Miscompilation of nntpgrab
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #8 from Andrew Pinski ---
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm . It does
look like gcc is implementing the correct new pod rules and clang is not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #7 from Andrew Pinski ---
(In reply to Tom Tromey from comment #5)
> (In reply to Jason Merrill from comment #3)
> > Passing a non-POD to a varargs function is conditionally-supported, with
> > implementation-defined semantics. In GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #6 from Tom Tromey ---
Also, -Wconditionally-supported triggers other warning as well.
It would be more convenient if different warnings were individually
controllable; and then something like -Wconditionally-supported
would act as if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #14 from Nathan Sidwell ---
Jan, I'm fairly sure that even though your fix makes things work, it is wrong.
You're at the very least exposing an internal API across the DSO boundary,
which should not be exposed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #13 from Nathan Sidwell ---
No. Each dso's gcov machinery is individually invoked. There should be no
cross-dso accessing of data (beyond the global chain of dso)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #5 from Tom Tromey ---
(In reply to Jason Merrill from comment #3)
> Passing a non-POD to a varargs function is conditionally-supported, with
> implementation-defined semantics. In GCC 5 it's supported and treated like
> normal pass-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #12 from Jan Hubicka ---
BTW the following fix the issue for me
Index: gcov-io.c
===
--- gcov-io.c (revision 220230)
+++ gcov-io.c (working copy)
@@ -39,7 +39,7 @@ st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20710
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #8 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64877
Bug ID: 64877
Summary: strange warning message from -Waddress
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #11 from Jan Hubicka ---
Yep, I think the problem is that each of DSOs will have its own set of infos
that will point to its own gcov_merge_add that calls its own gcov_io routines.
Now the winning gcov will walk the list but as soon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64876
Bug ID: 64876
Summary: Regressions in gcc-testresults for powerpc64 gccgo in
5.0 due to change for static chain for closures
(219776)
Product: gcc
Version: 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64873
--- Comment #2 from David Malcolm ---
I think this is misconfigurfation at my end; sorry.
I'm on power7 hw, emulating via qemu, and I did *not*
configure with the options suggested by Jakub in comment #1;
so I think I'm misconfiguring the build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356
--- Comment #14 from fiesh at zefix dot tv ---
Bounty: EUR 150
I'd like to try something new and place a bounty on this issue. In order to
collect it, you have to provide a patch that is accepted into 4.9 and 5. You
also need to be able to writ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64212
--- Comment #4 from Kai Tietz ---
A side-note: Of course the dllimport attribute is part of the prototype. So
for C case it would be consistent to have the dllimport-attribute also
specified for the inline, which gets rejected. This reject mig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64212
--- Comment #3 from Kai Tietz ---
(In reply to Jakub Jelinek from comment #2)
> Reduced testcase:
>
> inline void
> foo (void)
> {
> }
>
> __attribute__ ((__dllimport__))
> void foo (void);
>
> void
> bar (void)
> {
> foo ();
> }
>
> No opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349
Arnaud Charlet changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
Nathan Sidwell changed:
What|Removed |Added
CC||nathan at acm dot org
--- Comment #10 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349
--- Comment #12 from Arnaud Charlet ---
Author: charlet
Date: Fri Jan 30 15:13:15 2015
New Revision: 220285
URL: https://gcc.gnu.org/viewcvs?rev=220285&root=gcc&view=rev
Log:
2015-01-30 Tristan Gingold
PR ada/64349
* env.c: Move vxwo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64875
Bug ID: 64875
Summary: -Winline does not report C++ methods
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63319
--- Comment #3 from Markus Trippelsdorf ---
While retesting I came across this seemingly bizarre issue:
markus@x4 /tmp % touch qt_pch.ii
markus@x4 /tmp % g++ -w -O2 -std=c++0x -x c++-header -c qt_pch.ii
qt_pch.ii:1:0: internal compiler error: Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64813
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #12 from Martin Liška ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64874
Bug ID: 64874
Summary: gcov's magic number possibly increasing too quickly
with new gcc version numbering scheme.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63319
--- Comment #2 from Jakub Jelinek ---
And if yes, can it be also reproduced with building the pch file with
-save-temps? Then perhaps you could attach the preprocessed source from which
the pch is compiled, and tweak qhash.cpp to preprocess it t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803
Dodji Seketeli changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #7 from Dodji Seke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63319
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670
--- Comment #6 from Tobias Burnus ---
Created attachment 34628
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34628&action=edit
Updated test case (part 2/2): [aux file]
Updated test case. The first file matches what the original source cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670
Tobias Burnus changed:
What|Removed |Added
Attachment #34487|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854
--- Comment #7 from Lorenz Hüdepohl ---
> Use valgrind or -fsanitize=address to detect this kind of
> memory problems.
I can live with that, thanks for your comments!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64817
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64872
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #32 from Richard Biener ---
"So I take the other way around by passing the IV's ssa_name into
scev_probably_wraps_p along call sequence
"idx_find_step->convert_affine_scev->scev_probably_wraps". Since the IV's
ssa_name is tagged with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64872
Markus Trippelsdorf changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61458
--- Comment #3 from Jonathan Wakely ---
P.S. this isn't an urgent problem for the library, as we don't use
aligned_storage internally, we always use __aligned_buffer which
specifies the alignment explicitly rather than relying on the 16-byte defa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64275
--- Comment #2 from Jonathan Wakely ---
The simplest way to solve this might be to replace the extern declarations in
ios_init.cc such as:
extern stdio_sync_filebuf buf_cout_sync;
with a pointer:
extern stdio_sync_filebuf* buf_cout_sync_p;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64865
--- Comment #3 from Jonathan Wakely ---
(In reply to TC from comment #2)
> Since the allocator_type member must be the Alloc template argument provided
> by the user and not any rebound types, though,
N.B. libstdc++ supports std::vector> and so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810
--- Comment #20 from David Malcolm ---
Patches posted for review as:
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02704.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184
--- Comment #34 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Jan 30 10:53:53 2015
New Revision: 220277
URL: https://gcc.gnu.org/viewcvs?rev=220277&root=gcc&view=rev
Log:
PR target/15184
* gcc.target/i386/pr15184-1.c: Compile fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64873
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64865
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #2 from TC ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|5.0 |6.0
--- Comment #10 from Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61458
Jonathan Wakely changed:
What|Removed |Added
CC||paolo at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64873
Bug ID: 64873
Summary: jit testsuite failures on
powerpc64le-unknown-linux-gnu
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64817
--- Comment #3 from Jakub Jelinek ---
Alex mentioned this is related to PR48866 and it is also related to PR56510.
Since the latter, we actually break too complex debug insn expressions into
simpler ones (with maximum depth of 4), and it would d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64865
--- Comment #1 from Jonathan Wakely ---
(In reply to Casey Carter from comment #0)
> * Close this bug report as WONTFIX since it is horrible design to specialize
> std::allocator instead of declaring a new allocator type; given that
> container i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64872
Bug ID: 64872
Summary: [5 Regression] ICE: Segmentation fault during Chromium
PGO build
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64829
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64829
--- Comment #8 from Richard Biener ---
Author: rguenth
Date: Fri Jan 30 09:22:17 2015
New Revision: 220275
URL: https://gcc.gnu.org/viewcvs?rev=220275&root=gcc&view=rev
Log:
2015-01-30 Richard Biener
PR tree-optimization/64829
* tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365
--- Comment #14 from rguenther at suse dot de ---
On Fri, 30 Jan 2015, brooks at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365
>
> --- Comment #13 from Brooks Moses ---
> FWIW, if you haven't done the 4.9 backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864
--- Comment #6 from dodji at seketeli dot org ---
"mpolacek at gcc dot gnu.org" a écrit:
> I'm going to prepare the porting_to bit
Thank you for doing that!
> then I think we should close this bug.
FWIW, I agree.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870
--- Comment #7 from Andrew Pinski ---
(In reply to Conrad from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > No, that is not how C++ defines it. As mentioned before C++ does not define
> > the order of the execution of the operan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64592
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
1 - 100 of 102 matches
Mail list logo
