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=64212
--- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
Reduced testcase:
inline void
foo (void)
{
}
__attribute__ ((__dllimport__))
void foo (void);
void
bar (void)
{
foo ();
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #13 from Nathan Sidwell nathan at acm dot org ---
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 #6 from Tom Tromey tromey at gcc dot gnu.org ---
Also, -Wconditionally-supported triggers other warning as well.
It would be more convenient if different warnings were individually
controllable; and then something like
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:
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 tromey at gcc dot gnu.org changed:
What|Removed |Added
CC||tromey at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #14 from Nathan Sidwell nathan at acm dot org ---
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=64878
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #12 from Jan Hubicka hubicka at gcc dot gnu.org ---
BTW the following fix the issue for me
Index: gcov-io.c
===
--- gcov-io.c (revision 220230)
+++ gcov-io.c (working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
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=64867
--- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349
--- Comment #12 from Arnaud Charlet charlet at gcc dot gnu.org ---
Author: charlet
Date: Fri Jan 30 15:13:15 2015
New Revision: 220285
URL: https://gcc.gnu.org/viewcvs?rev=220285root=gccview=rev
Log:
2015-01-30 Tristan Gingold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #5 from Tom Tromey tromey at gcc dot gnu.org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
Nathan Sidwell nathan at acm dot org changed:
What|Removed |Added
CC||nathan at acm dot
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org ---
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=64349
Arnaud Charlet charlet at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64212
--- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64873
--- Comment #2 from David Malcolm dmalcolm at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
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=63472
--- Comment #7 from Benjamin Braun bjmnbraun at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64688
--- Comment #13 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
Author: vmakarov
Date: Fri Jan 30 22:22:58 2015
New Revision: 220297
URL: https://gcc.gnu.org/viewcvs?rev=220297root=gccview=rev
Log:
2015-01-30 Vladimir Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64872
--- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org ---
Created attachment 34630
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34630action=edit
Patch I am testing
The problem is that ICF merge profiles and profile merging sometimes
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #9 from Tom Tromey tromey at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64877
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326
--- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org ---
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=64617
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
CC||ubizjak at gmail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
--- Comment #1 from Sebastian Pop spop at gcc dot gnu.org ---
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810
--- Comment #21 from David Malcolm dmalcolm at gcc dot gnu.org ---
*** Bug 64873 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64877
--- Comment #3 from Tom Tromey tromey at gcc dot gnu.org ---
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 ‘SDerived::S() [with Derived = T]’:
x.cc:19:8:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64617
--- Comment #3 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
Author: vmakarov
Date: Fri Jan 30 17:47:44 2015
New Revision: 220294
URL: https://gcc.gnu.org/viewcvs?rev=220294root=gccview=rev
Log:
2015-01-30 Vladimir Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|RESOLVED|REOPENED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53949
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
--- Comment #2 from Sebastian Pop spop at gcc dot gnu.org ---
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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63923
iverbin at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #15 from Jan Hubicka hubicka at ucw dot cz ---
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64311
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
--- Comment #3 from Sebastian Pop spop at gcc dot gnu.org ---
-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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717
--- Comment #6 from Gert-jan Los gerrit.los at gmail dot com ---
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=64873
David Malcolm dmalcolm at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64877
--- Comment #2 from Tom Tromey tromey at gcc dot gnu.org ---
(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://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472
Benjamin Braun bjmnbraun at gmail dot com changed:
What|Removed |Added
CC||bjmnbraun at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64879
Benjamin Braun bjmnbraun at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64617
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64872
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61599
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021
Ian Lance Taylor ian at airs dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64875
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63493
Ian Lance Taylor ian at airs dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--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=64867
--- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org ---
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 redi at gcc dot gnu.org ---
(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
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 nathan at acm dot org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64001
--- Comment #5 from Ian Lance Taylor ian at airs dot com ---
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=63560
--- Comment #3 from Ian Lance Taylor ian at airs dot com ---
Was the patch in comment #1 ever committed? I don't see it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64688
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64875
--- Comment #2 from Daniel Gutson daniel.gutson at tallertechnologies dot com
---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64688
--- Comment #15 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Please note that 4.9.2 is also affected, so a backport would be appreciated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64431
Eugene Zelenko eugene.zelenko at gmail dot com changed:
What|Removed |Added
CC|
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 marxin at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63319
--- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870
--- Comment #6 from Conrad conradsand.arma at gmail dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64829
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365
--- Comment #14 from rguenther at suse dot de 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 brooks at gcc dot gnu.org
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=64817
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61458
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||paolo at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870
--- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864
--- Comment #6 from dodji at seketeli dot org dodji at seketeli dot org ---
mpolacek at gcc dot gnu.org gcc-bugzi...@gcc.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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64592
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64829
--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Fri Jan 30 09:22:17 2015
New Revision: 220275
URL: https://gcc.gnu.org/viewcvs?rev=220275root=gccview=rev
Log:
2015-01-30 Richard Biener rguent...@suse.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64865
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
(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;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|5.0 |6.0
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64865
TC rs2740 at gmail dot com changed:
What|Removed |Added
CC||rs2740 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854
--- Comment #7 from Lorenz Hüdepohl bugs at stellardeath dot org ---
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=63319
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803
Dodji Seketeli dodji at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63319
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64817
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Attachment #34487|0 |1
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670
--- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org ---
Created attachment 34628
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34628action=edit
Updated test case (part 2/2): [aux file]
Updated test case. The first file matches what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64865
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
(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++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810
--- Comment #20 from David Malcolm dmalcolm at gcc dot gnu.org ---
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=62173
--- Comment #32 from Richard Biener rguenth at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64275
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
The simplest way to solve this might be to replace the extern declarations in
ios_init.cc such as:
extern stdio_sync_filebufchar buf_cout_sync;
with a pointer:
extern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |5.0
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=220277root=gccview=rev
Log:
PR target/15184
* gcc.target/i386/pr15184-1.c: Compile for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64873
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61458
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
P.S. this isn't an urgent problem for the library, as we don't use
aligned_storageN internally, we always use __aligned_bufferT which
specifies the alignment explicitly rather than
1 - 100 of 102 matches
Mail list logo
