https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853
--- Comment #2 from Jakub Jelinek ---
I think the problem is that:
Visiting statement:
_15 = _56 & 1;
Applying pattern match.pd:312, gimple-match.c:13772
Applying pattern match.pd:235, gimple-match.c:13525
Match-and-simplified _56 & 1 to 0
Inte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810
--- Comment #18 from ramana.radhakrishnan at arm dot com ---
On 28/01/15 17:58, dmalcolm at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810
>
> --- Comment #9 from David Malcolm ---
> Thanks Ramana.
>
> I attempted a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853
--- Comment #3 from Jakub Jelinek ---
Simulating block 2
Simulating block 2
Simulating block 25
Simulating block 15
Simulating block 4
Simulating block 3
Simulating block 5
Simulating block 6
Simulating block 4
Simulating block 12
Simulating bloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64719
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64844
--- Comment #3 from Richard Biener ---
(In reply to Andrew Pinski from comment #2)
> t.c:8:5: note: === vect_update_slp_costs_according_to_vf ===
> t.c:8:5: note: cost model: the vector iteration cost = 26 divided by the
> scalar iteration cost =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61798
--- Comment #1 from Jakub Jelinek ---
Exit code 155 is indeed that the process has been killed by SIGPROF signal.
Without a testcase there is hard to say anything more on this, libgomp
certainly doesn't install a signal handler for this signal, n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61798
--- Comment #2 from Andrew Pinski ---
What target is this on?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64844
--- Comment #4 from Richard Biener ---
Created attachment 34613
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34613&action=edit
patch
Patch I am testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853
--- Comment #4 from Jakub Jelinek ---
--- gcc/tree-vrp.c.jj2015-01-28 08:39:51.0 +0100
+++ gcc/tree-vrp.c2015-01-29 10:44:37.395688127 +0100
@@ -7093,14 +7093,14 @@ vrp_valueize_1 (tree name)
if (TREE_CODE (name) == SSA_NAME)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Richard Bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854
Bug ID: 64854
Summary: No bound check for explicit-shape arrays
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803
--- Comment #3 from Dodji Seketeli ---
Created attachment 34614
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34614&action=edit
Candidate fix
This is the patch that I am currently testing. It seems to fix the issue for
me. Please let me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322
--- Comment #7 from vehre at gcc dot gnu.org ---
I just want to report some progress. I have a patch that fixes the issues in
comment #1 and #3. The tree-dump shows, that a class array is handled the same
for a class array as for a "type array" as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853
--- Comment #7 from Richard Biener ---
Sth like
Index: gcc/tree-ssa-propagate.c
===
--- gcc/tree-ssa-propagate.c(revision 220235)
+++ gcc/tree-ssa-propagate.c(working copy)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855
Bug ID: 64855
Summary: FAIL: libffi.call/* -W -Wall -Wno-psabi -O0
-DABI_NUM=* -DABI_ATTR=* execution test on
x86_64-apple-darwin*
Product: gcc
Version: 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64047
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64783
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349
--- Comment #11 from Dominique d'Humieres ---
I have bootstrapped x86_64-apple-darwin10 with the patch. Any plan to commit it
soon?
Thanks,
Dominique
> Le 27 janv. 2015 à 04:00, demoonlit at panathenaia dot halfmoon.jp
> a écrit :
>
> https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64805
--- Comment #4 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Thu Jan 29 11:03:02 2015
New Revision: 220240
URL: https://gcc.gnu.org/viewcvs?rev=220240&root=gcc&view=rev
Log:
gcc/
PR middle-end/64805
* ipa-inline.c (early_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64477
Jakub Jelinek changed:
What|Removed |Added
Summary|[4.9/5 Regression] x86 sse |[4.9 Regression] x86 sse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854
--- Comment #2 from Lorenz Hüdepohl ---
(Please remove the line "use m1" from my example, its a leftover from a
previous
version)
I'm not denying that there is a mistake in the example program. I just hoped
that -fcheck=bounds would save me fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64856
Bug ID: 64856
Summary: Initializing struct not accepted in gnu99
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64856
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803
--- Comment #4 from Alexander Klimov ---
Thanks! Your patch works for llvm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64857
Bug ID: 64857
Summary: Headers missing from and
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64857
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803
--- Comment #5 from Jakub Jelinek ---
Note, instead of doing such ugly hacks with __LINE__, IMHO gtest should use
__COUNTER__ instead, that doesn't care if it is on one line or multiple, and
doesn't get upset if you put more such macros on the sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64809
--- Comment #10 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Thu Jan 29 12:20:55 2015
New Revision: 220241
URL: https://gcc.gnu.org/viewcvs?rev=220241&root=gcc&view=rev
Log:
gcc/testsuite/
PR middle-end/64809
* gcc.dg/pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64844
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Thu Jan 29 12:53:39 2015
New Revision: 220244
URL: https://gcc.gnu.org/viewcvs?rev=220244&root=gcc&view=rev
Log:
2015-01-29 Richard Biener
PR tree-optimization/64844
* tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64844
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853
--- Comment #9 from Richard Biener ---
Author: rguenth
Date: Thu Jan 29 13:50:37 2015
New Revision: 220247
URL: https://gcc.gnu.org/viewcvs?rev=220247&root=gcc&view=rev
Log:
2015-01-29 Richard Biener
PR tree-optimization/64853
* tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64746
--- Comment #3 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Thu Jan 29 13:52:28 2015
New Revision: 220248
URL: https://gcc.gnu.org/viewcvs?rev=220248&root=gcc&view=rev
Log:
gcc/
PR tree-optimization/64746
* tree-if-conv.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64858
Bug ID: 64858
Summary: [5 Regression] Libreoffice build failure caused by ICF
crash
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51153
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184
--- Comment #32 from Jeffrey A. Law ---
Author: law
Date: Thu Jan 29 14:30:45 2015
New Revision: 220249
URL: https://gcc.gnu.org/viewcvs?rev=220249&root=gcc&view=rev
Log:
PR target/15184
* combine.c (try_combine): If I0 is a memory load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61798
--- Comment #3 from Manuel Kessler ---
Thank you both for trying to help.
@Andrew: This is on x86_64, running kernel 3.1.0 on an (admittedly old)
openSUSE 11.4.
@Jakub: You are probably right, but the question remains, how a SIGPROF
(probably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839
--- Comment #1 from Harald van Dijk ---
FWIW, libsanitizer builds just fine if the rpc references are forcibly removed,
like so:
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
+++ b/libsanitizer/sanitizer_common/sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64858
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64859
Bug ID: 64859
Summary: -Wabi-tag is not documented
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49508
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717
Gert-jan Los changed:
What|Removed |Added
CC||gerrit.los at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717
--- Comment #2 from Gert-jan Los ---
Created attachment 34616
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34616&action=edit
test case with virtual base class
version: gcc version 5.0.0 20150128 (experimental) (GCC)
options: -O -fsanitiz
t=x86_64-suse-linux
Thread model: posix
gcc version 5.0.0 20150129 (experimental) (SUSE Linux)
gcc-4.8.3 and 4.9.2 compile and link the same code just fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860
Richard Biener changed:
What|Removed |Added
Keywords||lto, wrong-code
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49508
Jason Merrill changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64394
Jana Saout changed:
What|Removed |Added
CC||jana at saout dot de
--- Comment #1 from Ja
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670
--- Comment #4 from Jason Merrill ---
This seems like a bug in the user's code, not the compiler. If the class is
defined in a header with #pragma interface, there needs to be a matching
#pragma implementation somewhere to cause the typeinfo and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810
--- Comment #19 from David Malcolm ---
(In reply to ramana.radhakrish...@arm.com from comment #18)
[...snip...]
> Yes this value is bogus as are the other .cpu values - the assembler
> output suggests to me that the configure time options aren't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64521
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Thu Jan 29 16:09:56 2015
New Revision: 220251
URL: https://gcc.gnu.org/viewcvs?rev=220251&root=gcc&view=rev
Log:
PR c++/64521
* repo.c (repo_emit_p): It's OK for a clone to be ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49508
--- Comment #8 from Jason Merrill ---
Author: jason
Date: Thu Jan 29 16:10:08 2015
New Revision: 220252
URL: https://gcc.gnu.org/viewcvs?rev=220252&root=gcc&view=rev
Log:
PR c++/49508
* semantics.c (finish_return_stmt): Suppress -Wreturn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49508
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64861
Bug ID: 64861
Summary: Possible wrong code with BIND(C) and PRIVATE +
slightly bogus warning
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64780
--- Comment #3 from David Malcolm ---
Author: dmalcolm
Date: Thu Jan 29 16:25:14 2015
New Revision: 220253
URL: https://gcc.gnu.org/viewcvs?rev=220253&root=gcc&view=rev
Log:
PR jit/64780: configure: --enable-host-shared and the jit
ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855
--- Comment #2 from Richard Henderson ---
I apologize for my mis-diagnosis earlier. These tests are not
expected to pass on Darwin at present. Disabling them in the
testsuite is the best thing to do for now.
Long term, someone needs to figure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855
--- Comment #3 from howarth at bromo dot med.uc.edu ---
FYI, I reported struct5.exe execution failures upstream earlier in the
thread...
https://sourceware.org/ml/libffi-discuss/2015/msg00019.html
https://sourceware.org/ml/libffi-discuss/2015/msg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #11 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64521
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Thu Jan 29 16:47:32 2015
New Revision: 220255
URL: https://gcc.gnu.org/viewcvs?rev=220255&root=gcc&view=rev
Log:
PR c++/64521
* repo.c (repo_emit_p): It's OK for a clone to be ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862
Bug ID: 64862
Summary: printf attribute should accept other string types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64863
Bug ID: 64863
Summary: error for use of members of a forward declared enum is
poor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64844
--- Comment #7 from Chris Jones ---
Confirmed fixed at TOT. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64521
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855
--- Comment #4 from Iain Sandoe ---
(In reply to Richard Henderson from comment #2)
> I apologize for my mis-diagnosis earlier. These tests are not
> expected to pass on Darwin at present. Disabling them in the
> testsuite is the best thing to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864
Bug ID: 64864
Summary: [5 Regression] preprocessor linemarkers break
configure checks
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864
--- Comment #2 from Jakub Jelinek ---
I really think this is porting_to.html material, rather than a bug report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64865
Bug ID: 64865
Summary: std::allocator::construct/destroy not called for
specialization of std::allocator
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64866
Bug ID: 64866
Summary: Lost visibility of package Interfaces after task or PO
declaration
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864
--- Comment #3 from Markus Trippelsdorf ---
(In reply to Jakub Jelinek from comment #2)
> I really think this is porting_to.html material, rather than a bug report.
I agree that the issue is borderline. Feel free to close this bug.
What is gain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864
--- Comment #4 from Jakub Jelinek ---
The line markers allows the compiler to properly distinguish between what
tokens come from where, e.g. system headers vs. normal headers (should we warn
about issues in there if -Wsystem-headers is not used a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
Bug ID: 64867
Summary: warning for passing non-POD to varargs function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862
--- Comment #1 from Andreas Schwab ---
glibc has this in :
extern int wprintf (const wchar_t *__restrict __format, ...)
/* __attribute__ ((__format__ (__wprintf__, 1, 2))) */;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862
--- Comment #2 from Tom Tromey ---
Naturally my example was wrong.
Sorry about that. But gcc still doesn't handle it:
#include
#include
extern void p (const char16_t *fmt, ...)
__attribute__((format (__printf__, 1, 2)));
void f()
{
p (u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862
Andrew Pinski changed:
What|Removed |Added
Depends on||38308
--- Comment #3 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #1 from Andrew Pinski ---
>From https://gcc.gnu.org/gcc-4.5/changes.html:
Diagnostics that used to complain about passing non-POD types to ... or jumping
past the declaration of a non-POD variable now check for triviality rather than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #2 from Jonathan Wakely ---
Jason informs me it's now a warning enabled by -Wconditionally-supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #3 from Jason Merrill ---
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-by-value. You can get a diagnostic about it wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64159
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64047
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365
--- Comment #12 from Brooks Moses ---
Thanks, Richard! It looks like I'll need to backport this to our
google/gcc-4_9 branch before that happens; any chance you already have a
version of this patch that works with 4.9? The wide_int pieces don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64868
Bug ID: 64868
Summary: C front-end rejects valid syntax.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Thu Jan 29 20:40:07 2015
New Revision: 220262
URL: https://gcc.gnu.org/viewcvs?rev=220262&root=gcc&view=rev
Log:
PR c++/64717
* cp-ubsan.c (cp_ubsan_instrument_vptr): Don't wrap v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #4 from Tom Tromey ---
Thanks, I'll give it a try.
Here's my test case FWIW and a short demo showing what clang does:
pokyo. cat q.cc
#include
class ConstUTF8CharsZ
{
const char *mData;
public:
ConstUTF8CharsZ() : mData
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854
--- Comment #4 from Lorenz Hüdepohl ---
> The right way to fix the problem is to fix the program
> by using an appropriate programming style. Writing
>
> real:: a(n1:) ! not: real :: a(n1:n2)
>
> one gets the expected check
I realiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64351
emsr at gcc dot gnu.org changed:
What|Removed |Added
CC||emsr at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64709
--- Comment #6 from Marek Polacek ---
Author: mpolacek
Date: Thu Jan 29 21:02:21 2015
New Revision: 220263
URL: https://gcc.gnu.org/viewcvs?rev=220263&root=gcc&view=rev
Log:
PR c/64709
* c-typeck.c (pop_init_level): If constructor_elemen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64709
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64814
--- Comment #9 from Anquietas ---
(In reply to Jonathan Wakely from comment #8)
> N.B. libc++ changed its copy_n with
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110221/039404.
> html and then libstdc++ did the same in PR 5011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855
--- Comment #5 from howarth at bromo dot med.uc.edu ---
Confirmed on x86_64-apple-darwin14 that...
Index: libffi/testsuite/lib/libffi.exp
===
--- libffi/testsuite/lib/libffi.exp(
1 - 100 of 131 matches
Mail list logo
