https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #9 from Jan Hubicka ---
Looking at the backtrace, all functions are 0x707
until the __gcov_merge_add which is 0x77fe so apparently coming from a
different DSO. This seems to be because the pointer come from gcov_info
d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870
--- Comment #6 from Conrad ---
(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 operands.
I agree this is not how C++ defines it. At th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64592
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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=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=64829
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=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=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=61458
Jonathan Wakely changed:
What|Removed |Added
CC||paolo at gcc dot gnu.org
--- Comment #
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=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=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=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=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=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=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=64864
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.0
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=64872
Markus Trippelsdorf changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Targe
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
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
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=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=64670
Tobias Burnus changed:
What|Removed |Added
Attachment #34487|0 |1
is obsolete|
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=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=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
--- 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=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=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=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=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=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=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
Arnaud Charlet changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
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=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=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=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=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=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=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=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=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=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 #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=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=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=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 #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=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=64878
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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=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=63923
iverbin at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
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=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=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=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=64873
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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 #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=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=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
Benjamin Braun changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=64311
Uroš Bizjak 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=64617
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=64872
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
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=61599
Uroš Bizjak changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
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=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=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 #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=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=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=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=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=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 #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=64431
Eugene Zelenko changed:
What|Removed |Added
CC||eugene.zelenko at gmail dot com
--- Com
--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=64021
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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=63493
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=64688
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 102 matches
Mail list logo
