[Bug target/85246] New: [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85246
Bug ID: 85246
Summary: [og7, nvptx, openacc] gemm.f90 fails with
-mlong-vector-in-workers
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
When adding:
...
/* { dg-additional-options "-foffload=-mlong-vector-in-workers" } */
...
to gemm.f90 it fails.
[Bug middle-end/33699] [6/7/8 regression] missing optimization on const addr area store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33699 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #26 from Jakub Jelinek --- (In reply to Michael Matz from comment #12) > Smaller perhaps, but it uses two registers, where it originally used none. > For x86 that's the better tradeoff. That can be handled by doing it in some very late post-RA pass, and only do it if we can find a usable register for that.
[Bug target/79185] [6/7/8 Regression] register allocation in the addition of two 128 bit ints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185 Jakub Jelinek changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- *** Bug 85096 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/85096] [6/7/8 Regression] Unnecessary(?) MOV instructions for int128 addition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85096 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jakub Jelinek --- Actually, we have a dup for this already. *** This bug has been marked as a duplicate of bug 79185 ***
[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222 --- Comment #13 from Richard Biener --- Just to mention the testcase fails in the same way if you build and run it with GCC 7 and libstdc++ from GCC 7 when that was configured with the gcc-4 compatible ABI by default. Just in case that wasn't obvious... Dropping the // Determines the version of ios_base::failure thrown by __throw_ios_failure. // If !_GLIBCXX_USE_DUAL_ABI this will get undefined automatically. #define _GLIBCXX_USE_CXX11_ABI 1 from src/c++11/ios.cc probably makes that more "consistent", matching the default ABI. The PR66145 changed that from an unconditional #define to 0 to an unconditional #define to 1. While, as the comment now says, a build without the dual-abi will use the old behavior switching the ABI default does not influence the behavior. I realize PR66145 is exactly about "fixing" the case of the user not using the default ABI but now we have still exactly the same situation when the user does #define _GLIBCXX_USE_CXX11_ABI 0 with a compiler defaulted to the new ABI. So IMHO the original change was totally pointless... :/ I'm probably going to locally patch it to be consistent with the default ABI choice - that at least keeps programs working that do not explicitely choose the ABI via #define _GLIBCXX_USE_CXX11_ABI and is consistent with the system integrators choice of the default ABI to keep compatibility to older GCC versions.
[Bug target/85246] [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85246 --- Comment #1 from Tom de Vries --- I went through a couple of cycles of minimizing the failure, seeing something suspicious, modifying by hand or writing a tentative patch, but every time I went back to the original non-minimized example I got the failure again. Anyway, things that may be causing this fail: 1. The og7 fix for PR85204 introduces a unified jump (bra.uni) for a jump conditional consisting of a test for vector id == 0 && worker id == 0. The fact that we're going a different direction in worker id 0 for vector id 0 and vector id 1 means the branch diverges, and is _not_ unified. It seems prudent to fix this by reverting the og7 fix and backporting the trunk fix. 2. The bar.sync instruction may not be sufficiently understood. In the documentation for bar.sync it says: ... bar.sync and bar.red also guarantee memory ordering among threads identical to membar.cta . Thus, threads within a CTA that wish to communicate via memory can store to memory, execute a bar.sync or bar.red instruction, and then safely read values stored by other threads prior to the barrier. ... The question is what happens when you specify a thread count. Does the memory ordering still apply to the whole CTA, or only to the threads participating in the barrier? So if we store something in vector id 0, worker id 0, and load it in worker id 1, we may have to use a bar.sync 0 instead to synchronize (or keep the same barrier but add a membar.cta).
[Bug lto/85078] [8 Regression] LTO ICE: tree check: expected tree that contains 'decl minimal' structure, have 'identifier_node' in decl_mangling_context, at cp/mangle.c:878
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85078
--- Comment #4 from rguenther at suse dot de ---
On Fri, 6 Apr 2018, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85078
>
> Jakub Jelinek changed:
>
>What|Removed |Added
>
> CC||jakub at gcc dot gnu.org
>
> --- Comment #3 from Jakub Jelinek ---
> (In reply to Richard Biener from comment #2)
> > --- tree.c (revision 258851)
> > +++ tree.c (working copy)
> > @@ -5522,6 +5522,8 @@ find_decls_types_r (tree *tp, int *ws, v
> > FOR_EACH_VEC_ELT (*BINFO_BASE_BINFOS (TYPE_BINFO (t)), i, tem)
> > fld_worklist_push (TREE_TYPE (tem), fld);
> > fld_worklist_push (BINFO_VIRTUALS (TYPE_BINFO (t)), fld);
> > + fld_worklist_push (BINFO_TYPE (tem), fld);
> > + fld_worklist_push (BINFO_VTABLE (tem), fld);
>
> I don't see how this can work, tem should be NULL here, as it is outside of
> the
> FOR_EACH_VEC_ELT loop. That said, I don't really see the b class ever
> appearing here, t is just i and g, nothing else.
Sorry, the patch pasted was bogus, my final attempts were the following
but it seems devirt has some fancy way to reach to other classes.
Honza, can you please look at this? Otherwise I'll revert the offending
change.
Index: tree.c
===
--- tree.c (revision 259082)
+++ tree.c (working copy)
@@ -5520,8 +5520,14 @@ find_decls_types_r (tree *tp, int *ws, v
unsigned i;
tree tem;
FOR_EACH_VEC_ELT (*BINFO_BASE_BINFOS (TYPE_BINFO (t)), i, tem)
- fld_worklist_push (TREE_TYPE (tem), fld);
+ {
+ fld_worklist_push (BINFO_TYPE (tem), fld);
+ fld_worklist_push (BINFO_VIRTUALS (tem), fld);
+ fld_worklist_push (BINFO_VTABLE (TYPE_BINFO (tem)), fld);
+ }
fld_worklist_push (BINFO_VIRTUALS (TYPE_BINFO (t)), fld);
+ fld_worklist_push (BINFO_TYPE (TYPE_BINFO (t)), fld);
+ fld_worklist_push (BINFO_VTABLE (TYPE_BINFO (t)), fld);
}
if (RECORD_OR_UNION_TYPE_P (t))
{
@@ -5700,7 +5706,11 @@ find_decls_types_in_node (struct cgraph_
gimple *stmt = gsi_stmt (si);
if (is_gimple_call (stmt))
- find_decls_types (gimple_call_fntype (stmt), fld);
+ {
+ find_decls_types (gimple_call_fntype (stmt), fld);
+ if (virtual_method_call_p (gimple_call_fn (stmt)))
+ find_decls_types (obj_type_ref_class (gimple_call_fn
(stmt)), fld);
+ }
for (i = 0; i < gimple_num_ops (stmt); i++)
{
[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #14 from Jakub Jelinek --- For the in-place transformation in libsupc++ if something catches the old failure and a new failure is thrown, is it possible? The other way around, if we would be throwing the new failure and catching the old one, doesn't seem to be possible, the cxx11 failure is bigger (32 bytes compared to 16 bytes for the old one). Could we just move it to a temporary, in-place construct the old one and destruct the temporary? What if the code then rethrows it and is caught again in code that expects the new failure?
[Bug libstdc++/83860] [6/7/8 Regression] valarray replacement type breaks with auto and more than one operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83860 --- Comment #6 from Marc Glisse --- GMP's expression templates, which are based on libstdc++ valarray, have the same issue. I tried using values in GMP ( https://gmplib.org/list-archives/gmp-bugs/2014-January/003319.html ). I never committed it for lack of time, but it seemed to improve performance as well, not just safety. Somehow gcc/llvm had an easier time seeing through the expressions with (copied) values. Not sure this applies to valarray though, since the expressions have bounded depth there. The real solution is still to avoid mixing auto with expression templates, at least until we get some version of what was once proposed as "operator auto". Maybe invent some [[warn_auto]] attribute?
[Bug tree-optimization/85244] [6/7/8 Regression] Bad optimisation with flexible array member (may be related to -ftree-dominator-opts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85244 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 Component|c |tree-optimization CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 Summary|Bad optimisation with |[6/7/8 Regression] Bad |flexible array member (may |optimisation with flexible |be related to |array member (may be |-ftree-dominator-opts) |related to ||-ftree-dominator-opts) Target Milestone|--- |6.5 --- Comment #1 from Jakub Jelinek --- Started with r232508.
[Bug middle-end/85234] missed optimisation opportunity for (~x >> n) ? a : b with n, a, b constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85234 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 Component|target |middle-end Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug target/85236] missing _mm256_atan2_ps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85236
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
Component|c++ |target
--- Comment #3 from Richard Biener ---
You might want to file this against glibc in case they want to provide
intrinsic headers for libmvec supported functions. Hopefully _mm256_atan2_ps
isn't in a header provided by GCC ... hmm, ICC seems to have it in immintrin.h:
/suse/matz/bin/2018.1/include/icc/immintrin.h:extern __m256 __ICL_INTRINCC
_mm256_atan2_ps(__m256, __m256);
and also:
/suse/matz/bin/2018.1/include/dvec.h:friend F32vec8 atan2(const F32vec8 &a,
const F32vec8 &b) { return _mm256_atan2_ps(a, b); }
not sure if we have a way to provide the intrinsic in a reasonable way from
GCC,
doing auto-dispatch to libmvec or alternatively open-coding elementwise?
[Bug middle-end/85237] missed optimisation opportunity for large/negative shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85237 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 Component|rtl-optimization|middle-end Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Yeah, we don't really take advantage of UB in shifts. Instead we really treat them implementation-defined aka 100 >> 1000 is zero, likewise we do (did?) treat 100 >> -2 as 100 << 2. Note historically RTL doesn't have any UB, it matches target implementation behavior for shifts (see that stupid SHIFT_COUNT_TRUNCATED thing...).
[Bug tree-optimization/85244] [6/7/8 Regression] Bad optimisation with flexible array member (may be related to -ftree-dominator-opts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85244 --- Comment #2 from Jakub Jelinek --- That said, it is get_ref_base_and_extent that for the variable index returns offset 96 bits and size == maxsize == 32, identical to the [0] case. Perhaps we shouldn't trust: 638 /* If maxsize is unknown adjust it according to the size of the 639 base decl. */ 640 else if (!known_size_p (maxsize) 641&& DECL_SIZE (exp) 642&& poly_int_tree_p (DECL_SIZE (exp))) 643 maxsize = wi::to_poly_offset (DECL_SIZE (exp)) - bit_offset; if exp is DECL_EXTERNAL and the struct/union ends with flexible array member (or flexible array member-like array)? Perhaps we'd need to remember from the case where we set seen_variable_array_ref to true if it was array_at_end_of_struct_p and if yes and DECL_EXTERNAL, ignore this? Richard?
[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238 Richard Biener changed: What|Removed |Added Target||cygwin, mingw Status|UNCONFIRMED |NEW Keywords||lto Last reconfirmed||2018-04-06 Component|lto |target CC||jyong at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|lto-wrapper: fatal error: |[8 Regression] lto-wrapper: |simple_object_copy_lto_debu |fatal error: |g_sections not implemented: |simple_object_copy_lto_debu |Invalid argument on Cygwin |g_sections not implemented: ||Invalid argument on Cygwin Target Milestone|--- |8.0 --- Comment #1 from Richard Biener --- That's expected. On darwin that was mitigated with 2018-03-02 Richard Biener PR target/82005 * config/darwin.c (saved_debug_info_level): New static global. (darwin_asm_lto_start): Disable debug info generation for LTO out. (darwin_asm_lto_end): Restore debug info generation settings. so mingw/cygwin need to do sth similar and define the TARGET_ASM_LTO_START/END hooks, see config/darwin.[ch] for examples. Or, of course, implement COFF support for simple_object_copy_lto_debug_sections.
[Bug c++/85247] New: Filesystem filename() wrong result for host-like path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85247
Bug ID: 85247
Summary: Filesystem filename() wrong result for host-like path
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ixsci at yandex dot ru
Target Milestone: ---
Here is a small example which is using a host-like path:
#include
#include
namespace fs = std::filesystem;
int main()
{
std::cout << fs::path("//host").filename() << '\n';
}
Which according to the Standard ([fs.path.decompose]p7) should display "" but
it displays "host" instead. Tested on Wandbox with gcc HEAD.
[Bug tree-optimization/85244] [6/7/8 Regression] Bad optimisation with flexible array member (may be related to -ftree-dominator-opts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85244
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener ---
(In reply to Jakub Jelinek from comment #2)
> That said, it is get_ref_base_and_extent that for the variable index returns
> offset 96 bits and size == maxsize == 32, identical to the [0] case.
>
> Perhaps we shouldn't trust:
> 638 /* If maxsize is unknown adjust it according to the size of the
> 639base decl. */
> 640 else if (!known_size_p (maxsize)
> 641 && DECL_SIZE (exp)
> 642 && poly_int_tree_p (DECL_SIZE (exp)))
> 643 maxsize = wi::to_poly_offset (DECL_SIZE (exp)) - bit_offset;
> if exp is DECL_EXTERNAL and the struct/union ends with flexible array member
> (or flexible array member-like array)? Perhaps we'd need to remember from
> the case where we set seen_variable_array_ref to true if it was
> array_at_end_of_struct_p and if yes and DECL_EXTERNAL, ignore this?
>
> Richard?
Hmm, what about
extern int a[];
or
extern int a[1];
?
so should we just treat structs with trailing flexible arrays in this way
(flexible as in [] or [0]?).
I think if we fix another case in get_ref_base_and_extent like with
Index: gcc/tree-dfa.c
===
--- gcc/tree-dfa.c (revision 259082)
+++ gcc/tree-dfa.c (working copy)
@@ -464,6 +464,11 @@ get_ref_base_and_extent (tree exp, poly_
maxsize += tem;
}
}
+ /* An component ref with an adjacent field up in the
+ structure hierarchy constrains the size of any variable
+ array ref lower in the access hierarchy. */
+ if (next)
+ seen_variable_array_ref = false;
}
}
else
then we can just do
@@ -622,7 +627,9 @@ get_ref_base_and_extent (tree exp, poly_
if (DECL_P (exp))
{
- if (flag_unconstrained_commons && VAR_P (exp) && DECL_COMMON (exp))
+ if (VAR_P (exp)
+ && ((flag_unconstrained_commons && DECL_COMMON (exp))
+ || (DECL_EXTERNAL (exp) && seen_variable_array_ref)))
{
tree sz_tree = TYPE_SIZE (TREE_TYPE (exp));
/* If size is unknown, or we have read to the end, assume there
and that way also handle plain arrays (very) conservatively.
[Bug tree-optimization/85244] [6/7/8 Regression] Bad optimisation with flexible array member (may be related to -ftree-dominator-opts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85244 --- Comment #4 from Jakub Jelinek --- Isn't non-NULL next fine in unions?
[Bug tree-optimization/85244] [6/7/8 Regression] Bad optimisation with flexible array member (may be related to -ftree-dominator-opts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85244 --- Comment #5 from Jakub Jelinek --- I.e. shouldn't it just be else seen_variable_array_ref = false; rather than if (next) seen_variable_array_ref = false; ?
[Bug tree-optimization/85232] gcc fails to vectorize a nested simd function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85232 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. I'm not sure how we set up vectorization of the SIMD clones but it appears that whatever we do we do not include if-conversion in that process. Jakub?
[Bug tree-optimization/85244] [6/7/8 Regression] Bad optimisation with flexible array member (may be related to -ftree-dominator-opts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85244 --- Comment #6 from Jakub Jelinek --- On the other side, this is done only if known_size_p (maxsize), don't we want to reset it even if maxsize isn't known?
[Bug rtl-optimization/85180] Infinite loop in RTL DSE optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180 --- Comment #14 from Richard Biener --- Author: rguenth Date: Fri Apr 6 08:30:52 2018 New Revision: 259166 URL: https://gcc.gnu.org/viewcvs?rev=259166&root=gcc&view=rev Log: 2018-04-06 Richard Biener PR middle-end/85180 * alias.c (find_base_term): New wrapper around find_base_term unwinding CSELIB_VAL_PTR changes. (find_base_term): Do not restore CSELIB_VAL_PTR during the recursion. * gcc.dg/pr85180.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr85180.c Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222 --- Comment #15 from Jonathan Wakely --- (In reply to Richard Biener from comment #13) > I'm probably going to locally patch it to be consistent with the default ABI > choice - that at least keeps programs working that do not explicitely choose > the ABI via #define _GLIBCXX_USE_CXX11_ABI and is consistent with the system > integrators choice of the default ABI to keep compatibility to older GCC > versions. That makes sense. Maybe we should do that on trunk too (it doesn't affect the default configuration where the new ABI is the default).
[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222 --- Comment #16 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #14) > For the in-place transformation in libsupc++ if something catches the old > failure and a new failure is thrown, is it possible? The other way around, > if we would be throwing the new failure and catching the old one, doesn't > seem to be possible, the cxx11 failure is bigger (32 bytes compared to 16 > bytes for the old one). I must be misunderstanding the scenario you're describing, because to me it seems like we could use 32 bytes to store a 16 byte object, but not the other way around. Anyway, I think in-place transformations are not an option. Code could have pointers to the data in the original exception. If we destroy it and create a new object in the same location we invalidate those pointers.
[Bug c++/85247] Filesystem filename() wrong result for host-like path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85247 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- The example in the standard is wrong, it is implementation-defined whether "//host" is a root-name, or a root-directory followed by a filename. On GNU/Linux and most POSIX systems there is no special treatment for a pathname like "//host" and so our std::filesystem implementation just treats it as a root-directory followed by a filename, i.e. "/" and "host". For Cygwin our implementation should treat that as a root-name, because on Cygwin "//host" is mapped to an SMB share called \\host
[Bug lto/85078] [8 Regression] LTO ICE: tree check: expected tree that contains 'decl minimal' structure, have 'identifier_node' in decl_mangling_context, at cp/mangle.c:878
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85078 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #5 from Jan Hubicka --- Will take a look.
[Bug ipa/85233] Incorrect -Wmaybe-uninitialized with -fpartial-inlining -finline-small-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85233
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-04-06
CC||jamborm at gcc dot gnu.org,
||marxin at gcc dot gnu.org,
||mliska at suse dot cz
Component|c |ipa
Blocks||24639
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
It needs intraprocedural analysis to prove that x is always initialized if
f returns nonzero. That's fragile and in the presence of partial inlining
it seems to break.
So what we are missing is IPA propagation of the single constant return
value of f.part.0. After fnsplit:
f.part.0 ()
{
...
[100.00%]:
# _3 = PHI <0(4)>
return _3;
}
h ()
{
int D.1847;
...
[16.50%]:
_11 = f.part.0 ();
if (_11 == 0)
goto ; [46.00%]
else
we fail to optimize this conditional. I realize we don't have return
jump-functions but if the single return value can be easily proved
by IPA-CP we could constant propagate that during its transform phase?
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug rtl-optimization/85180] Infinite loop in RTL DSE optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.0 Resolution|--- |FIXED Known to fail||7.3.1 --- Comment #15 from Richard Biener --- Fixed for GCC 8.
[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222 --- Comment #17 from rguenther at suse dot de --- On Fri, 6 Apr 2018, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222 > > --- Comment #16 from Jonathan Wakely --- > (In reply to Jakub Jelinek from comment #14) > > For the in-place transformation in libsupc++ if something catches the old > > failure and a new failure is thrown, is it possible? The other way around, > > if we would be throwing the new failure and catching the old one, doesn't > > seem to be possible, the cxx11 failure is bigger (32 bytes compared to 16 > > bytes for the old one). > > I must be misunderstanding the scenario you're describing, because to me it > seems like we could use 32 bytes to store a 16 byte object, but not the other > way around. > > Anyway, I think in-place transformations are not an option. Code could have > pointers to the data in the original exception. If we destroy it and create a > new object in the same location we invalidate those pointers. Yeah, I think throwing a composite object of both representation is the easiest way here (apart from the difficulty to build that in the first place).
[Bug ipa/60865] ICE: verify_cgraph_node failed: comdat-local function called by outside its comdat with -fdeclone-ctor-dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60865 VdP changed: What|Removed |Added CC||moltonel at gmail dot com --- Comment #2 from VdP --- See https://bugs.gentoo.org/640010 which has another reduced testcase and affects libreoffice -Os builds. It looks like the same bug to me, but maybe I'm wrong ?
[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222 --- Comment #18 from rguenther at suse dot de --- On Fri, 6 Apr 2018, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222 > > --- Comment #15 from Jonathan Wakely --- > (In reply to Richard Biener from comment #13) > > I'm probably going to locally patch it to be consistent with the default ABI > > choice - that at least keeps programs working that do not explicitely choose > > the ABI via #define _GLIBCXX_USE_CXX11_ABI and is consistent with the system > > integrators choice of the default ABI to keep compatibility to older GCC > > versions. > > That makes sense. Maybe we should do that on trunk too (it doesn't affect the > default configuration where the new ABI is the default). FYI: Index: libstdc++-v3/src/c++11/ios.cc === --- libstdc++-v3/src/c++11/ios.cc (revision 258812) +++ libstdc++-v3/src/c++11/ios.cc (working copy) @@ -26,9 +26,8 @@ // ISO C++ 14882: 27.4 Iostreams base classes // -// Determines the version of ios_base::failure thrown by __throw_ios_failure. -// If !_GLIBCXX_USE_DUAL_ABI this will get undefined automatically. -#define _GLIBCXX_USE_CXX11_ABI 1 +// The ABI version of ios_base::failure thrown by __throw_ios_failure +// is determined by the default ABI version choosed at configure time #include #include
[Bug tree-optimization/85244] [6/7/8 Regression] Bad optimisation with flexible array member (may be related to -ftree-dominator-opts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85244
--- Comment #7 from rguenther at suse dot de ---
On Fri, 6 Apr 2018, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85244
>
> --- Comment #6 from Jakub Jelinek ---
> On the other side, this is done only if known_size_p (maxsize), don't we want
> to reset it even if maxsize isn't known?
All true. So like the following, wasting a few cycles in the
!known_size_p && seen_variable_array_ref case
Index: gcc/tree-dfa.c
===
--- gcc/tree-dfa.c (revision 259082)
+++ gcc/tree-dfa.c (working copy)
@@ -438,7 +438,7 @@ get_ref_base_and_extent (tree exp, poly_
referenced the last field of a struct or a union member
then we have to adjust maxsize by the padding at the
end
of our field. */
- if (seen_variable_array_ref && known_size_p (maxsize))
+ if (seen_variable_array_ref)
{
tree stype = TREE_TYPE (TREE_OPERAND (exp, 0));
tree next = DECL_CHAIN (field);
@@ -454,7 +454,7 @@ get_ref_base_and_extent (tree exp, poly_
|| ssize == NULL
|| !poly_int_tree_p (ssize))
maxsize = -1;
- else
+ else if (known_size_p (maxsize))
{
poly_offset_int tem
= (wi::to_poly_offset (ssize)
@@ -464,6 +464,11 @@ get_ref_base_and_extent (tree exp, poly_
maxsize += tem;
}
}
+ /* An component ref with an adjacent field up in the
+ structure hierarchy constrains the size of any
variable
+ array ref lower in the access hierarchy. */
+ else
+ seen_variable_array_ref = false;
}
}
else
[Bug c++/85247] Filesystem filename() wrong result for host-like path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85247 --- Comment #2 from Evgeniy Shcherbina --- How is that incorrect? It is a pretty valid URI which I can change to this: "ftp://blahblah.org"; and gcc will tell me that filename is "blahblah.org" which is obviously wrong. Anyway, I will find where to ask the Standard guys about the issue and will get back there afterwards.
[Bug ipa/85233] Incorrect -Wmaybe-uninitialized with -fpartial-inlining -finline-small-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85233 --- Comment #2 from Erik Carstensen --- I know nothing about GCC internals, but I did make some observations on the warning's behaviour while minimizing the test case. An unqualified guess based on this is that intraprocedural analysis is not done unless the function is inlined; if GCC decides to not inline a function, then the warning is effectively suppressed in order to avoid having to do intraprocedural analysis. A possible bug might then be that f "counts" as inlined (in the sense that the warning is not suppressed) even if it is only partially inlined.
[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ktietz at gcc dot gnu.org
[Bug tree-optimization/85232] gcc fails to vectorize a nested simd function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85232 --- Comment #2 from Jakub Jelinek --- if-conversion is attempted, but fails. I can get it to work (as in, use the simd clones) if fun1 is __attribute__((const)); and when using -ffast-math. const attribute is needed to prove no side-effects. Now, not really sure why we require all data refs in the loop to be analyzable; perhaps if find_data_references_in_loop fails, we should just remember it and if-convert only if the blocks have no data references at all (that is the case here)?
[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #2 from Kai Tietz --- as intermediate the duplication of darwin's logic is fine. Nevertheless I would prefer proper support of COFF here.
[Bug libstdc++/83860] valarray replacement type breaks with auto and more than one operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83860 Jonathan Wakely changed: What|Removed |Added Keywords||patch Known to work|5.4.0 | Target Milestone|6.5 |--- Summary|[6/7/8 Regression] valarray |valarray replacement type |replacement type breaks |breaks with auto and more |with auto and more than one |than one operation |operation | --- Comment #7 from Jonathan Wakely --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00292.html I'm unmarking this as a regression, since the stack-use-after-scope problem has always been there.
[Bug c++/85247] Filesystem filename() wrong result for host-like path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85247 --- Comment #3 from Jonathan Wakely --- I've already reported it as a potential defect in the standard, so it will get addressed (either by fixing the standard or giving justification for leaving it as is). The Filesystem library is not meant to support URIs, so I don't find your argument convincing.
[Bug c++/85210] [7/8 Regression] ICE with broken structured binding in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85210 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 43864 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43864&action=edit gcc8-pr85210.patch Untested fix.
[Bug c++/85210] [7/8 Regression] ICE with broken structured binding in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85210 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |7.4
[Bug rtl-optimization/84872] [8 Regression] ICE in create_preheader, at cfgloopmanip.c:1536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84872
--- Comment #2 from Andrey Belevantsev ---
Nothing to do with sel-sched as is :) We're just asking to make loop
preheaders that will be fallthrough blocks. The loop has blocks 5 and 6 (6->5
is a loop latch), and the pred block is block 7 but there's block 4 between 7
and 5 like this:
(note 52 53 24 7 [bb 7] NOTE_INSN_BASIC_BLOCK)
<...>
(jump_insn/j 25 24 38 7 (set (pc)
(if_then_else (le (reg:CCNO 17 flags)
(const_int 0 [0]))
(label_ref:DI 18)
(pc))) "../prs/pr84872.c":13 682 {*jcc}
(expr_list:REG_DEAD (reg:CCNO 17 flags)
(nil))
-> 18)
(note 38 25 48 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(jump_insn 48 38 49 4 (set (pc)
(label_ref 22)) -1
(nil)
-> 22)
(barrier 49 48 18)
(code_label 18 49 16 5 3 (nil) [2 uses])
(note 16 18 17 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
<...>
The create_preheader code asks to split the 7->5 edge and we happily make block
9:
(note 52 53 24 7 [bb 7] NOTE_INSN_BASIC_BLOCK)
<...>
(jump_insn/j 25 24 38 7 (set (pc)
(if_then_else (le (reg:CCNO 17 flags)
(const_int 0 [0]))
(label_ref:DI 18)
(pc))) "../prs/pr84872.c":13 682 {*jcc}
(expr_list:REG_DEAD (reg:CCNO 17 flags)
(nil))
-> 18)
(note 38 25 48 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(jump_insn 48 38 49 4 (set (pc)
(label_ref 22)) -1
(nil)
-> 22)
(barrier 49 48 60)
(note 60 49 18 9 [bb 9] NOTE_INSN_BASIC_BLOCK)
(code_label 18 60 16 5 3 (nil) [2 uses])
(note 16 18 17 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
But then we hit the "can't allow a region crossing edge to be fallthrough"
conditional in rtl_split_edge, the edge is forced to be nonfallthru and the
create_preheader assert fires.
The below of course "fixes" it so we need to do something with the bb
partitioning rules or something. Any pass that will ask for fallthrough
preheaders after bb reordering between partitions has been completed will blow
up.
diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
index fd095ac59ed..ed6b0c11802 100644
--- a/gcc/cfgrtl.c
+++ b/gcc/cfgrtl.c
@@ -1901,7 +1901,7 @@ rtl_split_edge (edge edge_in)
/* Can't allow a region crossing edge to be fallthrough. */
if (BB_PARTITION (bb) != BB_PARTITION (edge_in->dest)
- && edge_in->dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
+ && edge_in->dest != EXIT_BLOCK_PTR_FOR_FN (cfun) && false)
{
new_bb = force_nonfallthru (single_succ_edge (bb));
gcc_assert (!new_bb);
[Bug lto/85248] New: [6/7/8 Regression] Miscompilation when using error function that returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85248
Bug ID: 85248
Summary: [6/7/8 Regression] Miscompilation when using error
function that returns
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, jamborm at gcc dot gnu.org,
marxin at gcc dot gnu.org
Target Milestone: ---
Isolated from dwz program:
$ cat dwz.c
#include
int a;
int get(void)
{
return a;
}
static void
dwz (void)
{
error (0, 1, "");
__builtin_printf ("PES\n");
}
static void usage ()
{
error (1, 0, "usage\n");
}
int
main (int argc)
{
if (get())
usage ();
dwz ();
return 0;
}
Note that error does not return when 1st argument == 0.
Without LTO:
$ gcc dwz.c -O1 && ./a.out
./a.out: : Operation not permitted
PES
With LTO:
$ gcc dwz.c -O1 -flto && ./a.out
./a.out: : Operation not permitted
Segmentation fault (core dumped)
Where inliner decides to inline usage function and then removes the BB with PES
printf:
Inlining usage to main with frequency 0
Updating SSA:
Registering new PHI nodes in block #0
Registering new PHI nodes in block #2
Updating SSA information for statement __error_noreturn (0, 1, "");
Updating SSA information for statement __builtin_puts (&"PES"[0]);
Updating SSA information for statement return;
Symbols to be put in SSA form
{ D.4014 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 3
Number of blocks to update: 2 ( 67%)
Affected blocks: 0 2
Inlining dwz to main with frequency 999
Removing basic block 7
basic block 7, loop depth 0
pred:
succ:
Removing basic block 9
basic block 9, loop depth 0
pred: 11
return 0;
succ: EXIT
Removing basic block 11
basic block 11, loop depth 0
pred: 10
# DEBUG __status => NULL
# DEBUG __errnum => NULL
# DEBUG __format => NULL
__builtin_puts (&"PES"[0]);
succ:
[Bug lto/85248] [6/7/8 Regression] Miscompilation when using error function that returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85248 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Last reconfirmed||2018-4-6
[Bug lto/85248] [6/7/8 Regression] Miscompilation when using error function that returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85248 --- Comment #1 from Andrew Pinski --- I suspect this is because error is marked as noreturn in the header file and not a gcc issue.
[Bug target/84762] GCC for PowerPC32 violates the SysV ABI spec for small struct returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84762
--- Comment #13 from Franz Sirl ---
Yes, I can do a patch for GCC-9. Any idea for the option naming? Like
-msvr4-struct-return-msb? Or should I consolidate -maix-struct-return and
-msvr4-struct-return into -maggr-return-mode={aix,svr4,svr4gnu}?
[Bug tree-optimization/85232] gcc fails to vectorize a nested simd function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85232 --- Comment #3 from rguenther at suse dot de --- On Fri, 6 Apr 2018, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85232 > > --- Comment #2 from Jakub Jelinek --- > if-conversion is attempted, but fails. > I can get it to work (as in, use the simd clones) if fun1 is > __attribute__((const)); and when using -ffast-math. > const attribute is needed to prove no side-effects. > > Now, not really sure why we require all data refs in the loop to be > analyzable; > perhaps if find_data_references_in_loop fails, we should just remember it and > if-convert only if the blocks have no data references at all (that is the case > here)? we don't need data references to be analyzable for if-conversion, all not analyzable refs can be simply "skipped" AFAIK. So I'd just open-code find_data_references_in_loop like other passes do and ignore the non-analyzable refs.
[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238 --- Comment #3 from rguenther at suse dot de --- On Fri, 6 Apr 2018, ktietz at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238 > > Kai Tietz changed: > >What|Removed |Added > > CC||ktietz at gcc dot gnu.org > > --- Comment #2 from Kai Tietz --- > as intermediate the duplication of darwin's logic is fine. Nevertheless I > would > prefer proper support of COFF here. Of course. I asked for help here (similar for Mach-O and darwin) about one and a half years ago. The proposed mitigation should get you about as much debug info with LTO as in the pre-early-LTO debug era. So all you should (in theory) get is no "better" debug...
[Bug c++/85214] [7/8 Regression] ICE on valid C++17 code on x86_64-linux-gnu: in tsubst_copy, at cp/pt.c:14562
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85214
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-04-06
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Target Milestone|--- |7.4
Summary|ICE on valid C++17 code on |[7/8 Regression] ICE on
|x86_64-linux-gnu: in|valid C++17 code on
|tsubst_copy, at |x86_64-linux-gnu: in
|cp/pt.c:14562 |tsubst_copy, at
||cp/pt.c:14562
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Reduced testcase:
typedef int a;
namespace b {
template struct e { static constexpr c f = d; constexpr
operator int() { return f; } };
typedef e g;
template struct h : g {};
template class k;
template constexpr bool m = h::f;
template struct n;
template struct aa;
template struct C;
template using o = typename C::q;
template struct p {};
template > struct F;
template struct F> { typedef p ae; };
template using t = typename F::ae;
template using w = p;
template using af = t;
template struct aa> : e {};
template constexpr a ah = aa::f;
template struct C<0, k> { typedef ai
q; };
}
template void al(ak am, b::w) { int{(am(b::e{}), 0)...}; }
template void al(ak am) { al(am, b::af()); }
void ao() {
using ap = b::k;
const a aq = b::ah;
al([](auto i) {
using ar = b::o;
al([](auto j) { using as = b::o; if constexpr (b::m) ;
});
});
}
Started to ICE with r239338 when if constexpr has been introduced.
[Bug c++/85249] New: [6/7/8 Regression] ICE with invalid default parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85249
Bug ID: 85249
Summary: [6/7/8 Regression] ICE with invalid default parameter
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following invalid code snippet triggers an ICE since GCC 4.8.0:
struct A
{
void operator= (const A& = A());
void foo(const A&);
};
void A::foo(const A& = A()) {}
bug.cc:3:33: error: 'void A::operator=(const A&)' cannot have default arguments
void operator= (const A& = A());
^
bug.cc:7:27: internal compiler error: canonical types differ for identical
types 'void (A::)(const A&)' and 'void (A::)(const A&)'
void A::foo(const A& = A()) {}
^
0x9dc198 comptypes(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.c:1480
0x89241a duplicate_decls(tree_node*, tree_node*, bool)
../../gcc/gcc/cp/decl.c:2226
0x899062 grokfndecl
../../gcc/gcc/cp/decl.c:9099
0x8a95f0 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/gcc/cp/decl.c:12429
0x8ac476 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
../../gcc/gcc/cp/decl.c:15299
0x93c891 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26711
0x93c891 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19501
0x944508 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13049
0x945318 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12874
0x9492a2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12772
0x9496b1 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12648
0x9499a4 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4563
0x9499a4 c_parse_file()
../../gcc/gcc/cp/parser.c:39016
0xa49636 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report, [etc.]
[Bug c++/85250] New: Builtin operator overload resolution fails to consider user-defined conversion template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85250
Bug ID: 85250
Summary: Builtin operator overload resolution fails to consider
user-defined conversion template
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rustamabd at gmail dot com
Target Milestone: ---
Consider the following contrived example.
---
#include
struct A {
template::value,int>::type = 0>
operator T() { return static_cast(1); }
};
int main() {
int x = 1;
A a;
return x + a;
}
---
Output from g++:
error: no match for 'operator+' (operand types are 'int' and 'A')
return x + a;
~~^~~
---
Compiles fine in clang.
---
A lookup on + should find the built-in int operator+(int&,int) as the only
viable candidate (see [over.match.oper]/6).
That candidate is viable because A can be converted to int via a user-defined
conversion.
If operator int() isn't a template, G++ is able to compile the code.
It's just the conversion function *template* that fails to be considered.
Нови модели от Invicta! Наличностите са ограничени!
? , . Invicta INV-24695 489 302 Invicta 21792 246 152 Invicta 23723 224 138 Invicta 25329 202 124 Invicta 24922 313 193 Invicta 7116 268 166 Invicta 23715 303 187 Invicta 20205 401 247 Invicta 14702 268 166 Invicta 25709 343 212 Invicta 22772 369 228 Invicta 23061 246 152 Invicta 25855 470 290 Invicta 17566 338 208 Invicta 12790 510 315 Invicta 8933 193 119 Invicta INV-24670 357 220 Invicta INV-24229 322 199 Invicta 25513 647 399 Invicta 24751 462 285 Invicta 25863 669 413 Invicta 25814 277 171 Invicta 24970 391 241 I
[Bug c++/85251] New: Using declaration for base class constructor looses explicit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85251
Bug ID: 85251
Summary: Using declaration for base class constructor looses
explicit.
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
Example:
#include
struct A {
template
A(Args&&... args) { std::printf("%s\n", __PRETTY_FUNCTION__); }
explicit A(int) { std::printf("%s\n", __PRETTY_FUNCTION__); }
};
struct B : A { using A::A; };
int main(int ac, char**) {
A a = ac;
B b = ac;
}
Outputs:
A::A(Args&& ...) [with Args = {int&}]
A::A(int)
Expected output (clang++-3.9.0 output):
A::A(Args&& ...) [with Args = {int&}]
A::A(Args&& ...) [with Args = {int&}]
[Bug c++/85249] [6/7/8 Regression] ICE with invalid default parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85249 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |6.5
[Bug debug/85252] New: Segmentation fault with -g for static zero-length array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85252
Bug ID: 85252
Summary: Segmentation fault with -g for static zero-length
array initialization
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: themos.tsikas at gmail dot com
Target Milestone: ---
A one-liner source provokes Segmentation fault (you can see the source line in
the message below). Bug shows up in 4.x 5.x 6.x 7.x series of compilers.
$ /opt/gcc-7/bin/gcc -c -g bug.c
bug.c: In function ‘xxx’:
bug.c:1:1: internal compiler error: Segmentation fault
void xxx(){static char a[0] = ""; return;}
^~~~
0xa0d9ff crash_signal
/scratch/themos/pi/gcc-7-src/gcc/toplev.c:337
0xc18940 tree_int_cst_sgn(tree_node const*)
/scratch/themos/pi/gcc-7-src/gcc/tree.c:7373
0xc19e8b compare_tree_int(tree_node const*, unsigned long)
/scratch/themos/pi/gcc-7-src/gcc/tree.c:7583
0x71d59d rtl_for_decl_init
/scratch/themos/pi/gcc-7-src/gcc/dwarf2out.c:18740
0x71d781 rtl_for_decl_location
/scratch/themos/pi/gcc-7-src/gcc/dwarf2out.c:19013
0x753759 add_location_or_const_value_attribute
/scratch/themos/pi/gcc-7-src/gcc/dwarf2out.c:19134
0x7547f2 gen_variable_die
/scratch/themos/pi/gcc-7-src/gcc/dwarf2out.c:22941
0x73ce2b gen_decl_die
/scratch/themos/pi/gcc-7-src/gcc/dwarf2out.c:25398
0x7400e8 process_scope_var
/scratch/themos/pi/gcc-7-src/gcc/dwarf2out.c:24870
0x7402bf decls_for_scope
/scratch/themos/pi/gcc-7-src/gcc/dwarf2out.c:24895
0x740a87 gen_subprogram_die
/scratch/themos/pi/gcc-7-src/gcc/dwarf2out.c:22452
0x73cd28 gen_decl_die
/scratch/themos/pi/gcc-7-src/gcc/dwarf2out.c:25331
0x73d9de dwarf2out_decl
/scratch/themos/pi/gcc-7-src/gcc/dwarf2out.c:25840
0x73ddfe dwarf2out_function_decl
/scratch/themos/pi/gcc-7-src/gcc/dwarf2out.c:25855
0x7a36fa rest_of_handle_final
/scratch/themos/pi/gcc-7-src/gcc/final.c:4520
0x7a36fa execute
/scratch/themos/pi/gcc-7-src/gcc/final.c:4562
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug lto/85248] [6/7/8 Regression] Miscompilation when using error function that returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85248 Richard Biener changed: What|Removed |Added Priority|P1 |P2 Version|unknown |7.3.1 Target Milestone|--- |6.5
[Bug libstdc++/83860] valarray replacement type breaks with auto and more than one operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83860 --- Comment #8 from Jonathan Wakely --- N.B. compiling with -fstack-reuse=none will prevent the optimizer from reusing the stack space immediately, so the dangling references can still be used to access the temporaries after their lifetime ends.
[Bug lto/85248] [6/7/8 Regression] Miscompilation when using error function that returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85248
--- Comment #2 from Martin Liška ---
(In reply to Andrew Pinski from comment #1)
> I suspect this is because error is marked as noreturn in the header file and
> not a gcc issue.
No, it's not. It's properly distinguished:
extern void __error_alias (int __status, int __errnum, const char *__format,
...) __asm__ ("" "error")
__attribute__ ((__format__ (__printf__, 3, 4)));
extern void __error_noreturn (int __status, int __errnum, const char *__format,
...) __asm__ ("" "error")
__attribute__ ((__noreturn__, __format__ (__printf__, 3, 4)));
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__gnu_inline__)) void
error (int __status, int __errnum, const char *__format, ...)
{
if (__builtin_constant_p (__status) && __status != 0)
__error_noreturn (__status, __errnum, __format, __builtin_va_arg_pack ());
else
__error_alias (__status, __errnum, __format, __builtin_va_arg_pack ());
}
[Bug rtl-optimization/84872] [8 Regression] ICE in create_preheader, at cfgloopmanip.c:1536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84872 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 43865 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43865&action=edit gcc8-pr84872.patch Untested fix.
[Bug sanitizer/84428] ==7122==AddressSanitizer CHECK failed: ../../../sanitizer/asan/asan_interceptors.cc:384 "((__interception::real___cxa_throw)) != (0)" (0x0, 0x0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84428 --- Comment #18 from Vojtech Fried --- Created attachment 43866 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43866&action=edit simple repro I have added a simple way to reproduce it. Unpack and run run.sh. You need python3 installed (including dev packages). It creates a simple python3 module and runs a python script using it. If built and run with sanitizers, it will reproduce the problem.
[Bug libstdc++/83860] valarray replacement type breaks with auto and more than one operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83860 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |9.0
[Bug libfortran/85253] New: asan detects heap-buffer-overflow in matmul_r4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85253 Bug ID: 85253 Summary: asan detects heap-buffer-overflow in matmul_r4.c Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu ! In trunk 258946 asan detects heap buffer overflow in libgfortran/generated/matmul_r4.c:2035 ! "t1[l - ll + 2 + ((i - ii + 2) << 8) - 257] = a[i + 1 + (l + 1) * a_dim1];" ! l=1 ll=1 i=1 ii=1 a_dim1=2 ! Generated with ~/local/gcc-258946-address/bin/gfortran p.f -g -lasan -static-libgfortran ! Initially detected with "export MALLOC_CHECK_=1" (see man mallopt) (I put it into .bashrc) ! gfortran 7.3.0 seems to be ok real data_d(2,2),ptr(1,2) ! and similarly for other real and integer types (complex ok) data data_d/1,2,3,4/ data ptr/1,2/ print *,MATMUL(data_d,TRANSPOSE(ptr)) !must display 7.0 10.0 end !./a.out != !==32750==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61900484 at pc 0x0041ac82 bp 0x7fff2a84aff0 sp 0x7fff2a84afe8 !WRITE of size 4 at 0x61900484 thread T0 !#0 0x41ac81 in matmul_r4_vanilla ../../../gcc-258946/libgfortran/generated/matmul_r4.c:2035 !#1 0x41f348 in _gfortran_matmul_r4 ../../../gcc-258946/libgfortran/generated/matmul_r4.c:2377 !#2 0x402efe in MAIN__ /home/vitti/1tb/vitti/test/cp2k-18361/cp2k/tests/QS/regtest-pao-2/p.f:6 !#3 0x402fa6 in main /home/vitti/1tb/vitti/test/cp2k-18361/cp2k/tests/QS/regtest-pao-2/p.f:7 !#4 0x147ac2eeff29 in __libc_start_main (/usr/lib64/libc.so.6+0x20f29) !#5 0x402bc9 in _start (/home/vitti/1tb/vitti/test/cp2k-18361/cp2k/tests/QS/regtest-pao-2/a.out+0x402bc9) ! !0x61900484 is located 0 bytes to the right of 1028-byte region [0x61900080,0x61900484) !allocated by thread T0 here: !#0 0x147ac3b10040 in __interceptor_malloc ../../../../gcc/libsanitizer/asan/asan_malloc_linux.cc:86 !#1 0x41a6db in matmul_r4_vanilla ../../../gcc-258946/libgfortran/generated/matmul_r4.c:1995 !#2 0x41f348 in _gfortran_matmul_r4 ../../../gcc-258946/libgfortran/generated/matmul_r4.c:2377 !#3 0x402efe in MAIN__ /home/vitti/1tb/vitti/test/cp2k-18361/cp2k/tests/QS/regtest-pao-2/p.f:6 !#4 0x402fa6 in main /home/vitti/1tb/vitti/test/cp2k-18361/cp2k/tests/QS/regtest-pao-2/p.f:7 !#5 0x147ac2eeff29 in __libc_start_main (/usr/lib64/libc.so.6+0x20f29) ! !SUMMARY: AddressSanitizer: heap-buffer-overflow ../../../gcc-258946/libgfortran/generated/matmul_r4.c:2035 in matmul_r4_vanilla !Shadow bytes around the buggy address: ! 0x0c327fff8040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ! 0x0c327fff8050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ! 0x0c327fff8060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ! 0x0c327fff8070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ! 0x0c327fff8080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 !=>0x0c327fff8090:[04]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ! 0x0c327fff80a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ! 0x0c327fff80b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ! 0x0c327fff80c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ! 0x0c327fff80d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ! 0x0c327fff80e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa !Shadow byte legend (one shadow byte represents 8 application bytes): ! Addressable: 00 ! Partially addressable: 01 02 03 04 05 06 07 ! Heap left redzone: fa ! Freed heap region: fd ! Stack left redzone: f1 ! Stack mid redzone: f2 ! Stack right redzone: f3 ! Stack after return: f5 ! Stack use after scope: f8 ! Global redzone: f9 ! Global init order: f6 ! Poisoned by user:f7 ! Container overflow: fc ! Array cookie:ac ! Intra object redzone:bb ! ASan internal: fe ! Left alloca redzone: ca ! Right alloca redzone:cb !==32750==ABORTING
[Bug sanitizer/85213] [8 Regression] -fsanitize=undefined internal compiler error: in fold_convert_loc, at fold-const.c:2402
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85213 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Apr 6 11:24:36 2018 New Revision: 259167 URL: https://gcc.gnu.org/viewcvs?rev=259167&root=gcc&view=rev Log: PR sanitizer/85213 * fold-const.c (twoval_comparison_p): Remove SAVE_P argument and don't look through SAVE_EXPRs with non-side-effects argument. Adjust recursive calls. (fold_comparison): Adjust twoval_comparison_p caller, don't handle save_p here. * c-c++-common/ubsan/pr85213.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/pr85213.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/85213] [8 Regression] -fsanitize=undefined internal compiler error: in fold_convert_loc, at fold-const.c:2402
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85213 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug lto/85248] [6/7/8 Regression] Miscompilation when using error function that returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85248
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Richard Biener ---
I think the issue is:
extern void __error_noreturn (int __status, int __errnum, const char *__format,
...) __asm__ ("" "error")
__attribute__ ((__noreturn__, __format__ (__printf__, 3, 4)));
and
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__gnu_inline__)) void
error (int __status, int __errnum, const char *__format, ...)
{
if (__builtin_constant_p (__status) && __status != 0)
__error_noreturn (__status, __errnum, __format, __builtin_va_arg_pack ());
else
__error_alias (__status, __errnum, __format, __builtin_va_arg_pack ());
}
and LTO ending up with
main (int argc)
{
int D.4004;
int _1;
int _4;
[100.00%]:
_4 = 0;
_5 = _4;
_1 = _5;
if (_1 != 0)
goto ; [0.04%]
else
goto ; [99.96%]
[0.04%]:
__error_noreturn (1, 0, "usage\n");
[99.96%]:
__error_noreturn (0, 1, "");
seemingly with bogus expansion and/or alias resolving.
[Bug debug/85252] ICE with -g for static zero-length array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85252 Richard Biener changed: What|Removed |Added Keywords||accepts-invalid, ||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 CC||jsm28 at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I think the initialization shouldn't have been accepted but rejected with an error on the grounds the string doesn't fit. QOI means that #4 0x00ac1d20 in rtl_for_decl_init (init=, type=) at /space/rguenther/src/svn/early-lto-debug/gcc/dwarf2out.c:19602 19602 TREE_STRING_LENGTH (init) - 1) == 0 (gdb) l 19597 if (is_int_mode (TYPE_MODE (enttype), &mode) 19598 && GET_MODE_SIZE (mode) == 1 19599 && domain 19600 && integer_zerop (TYPE_MIN_VALUE (domain)) 19601 && compare_tree_int (TYPE_MAX_VALUE (domain), 19602 TREE_STRING_LENGTH (init) - 1) == 0 19603 && ((size_t) TREE_STRING_LENGTH (init) 19604 == strlen (TREE_STRING_POINTER (init)) + 1)) lacks a test for non-NULL TYPE_MAX_VALUE. TYPE_DOMAIN is [0:] here. Joseph?
[Bug debug/85252] [6/7/8 Regression] ICE with -g for static zero-length array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85252 Richard Biener changed: What|Removed |Added Known to work||5.5.0 Target Milestone|--- |6.5 Summary|ICE with -g for static |[6/7/8 Regression] ICE with |zero-length array |-g for static zero-length |initialization |array initialization
[Bug tree-optimization/85244] [6/7/8 Regression] Bad optimisation with flexible array member (may be related to -ftree-dominator-opts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85244 --- Comment #8 from Richard Biener --- Author: rguenth Date: Fri Apr 6 11:47:18 2018 New Revision: 259168 URL: https://gcc.gnu.org/viewcvs?rev=259168&root=gcc&view=rev Log: 2018-04-06 Richard Biener PR middle-end/85244 * tree-dfa.c (get_ref_base_and_extent): Reset seen_variable_array_ref after seeing a component reference with an adjacent field. Treat refs to arrays at struct end of external decls similar to refs to unconstrained commons. * gcc.dg/torture/pr85244-1.c: New testcase. * gcc.dg/torture/pr85244-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr85244-1.c trunk/gcc/testsuite/gcc.dg/torture/pr85244-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-dfa.c
[Bug tree-optimization/85244] [6/7 Regression] Bad optimisation with flexible array member (may be related to -ftree-dominator-opts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85244 Richard Biener changed: What|Removed |Added Known to work||8.0 Summary|[6/7/8 Regression] Bad |[6/7 Regression] Bad |optimisation with flexible |optimisation with flexible |array member (may be|array member (may be |related to |related to |-ftree-dominator-opts) |-ftree-dominator-opts) --- Comment #9 from Richard Biener --- Fixed on trunk sofar.
[Bug c++/85006] [7 Regression] [concepts] ICE with bogus parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85006 Volker Reichelt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Volker Reichelt --- Fixed by Jason's patch.
[Bug libfortran/85253] [8 Regression] asan detects heap-buffer-overflow in matmul_r4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85253 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 CC||jvdelisle at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org Known to work||7.0.1 Target Milestone|--- |8.0 Summary|asan detects|[8 Regression] asan detects |heap-buffer-overflow in |heap-buffer-overflow in |matmul_r4.c |matmul_r4.c Ever confirmed|0 |1 Known to fail||8.0.1 --- Comment #1 from Dominique d'Humieres --- It looks to be a gcc8 regression that occurred between revision r245276 (7.0.1) and r254086 (8.0). I see ==28006==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61900984 at pc 0x000105e887a3 bp 0x7ffeea337be0 sp 0x7ffeea337bd8 WRITE of size 4 at 0x61900984 thread T0 #0 0x105e887a2 in matmul_r4_avx matmul_r4.c:365 ...
[Bug debug/85252] [6/7/8 Regression] ICE with -g for static zero-length array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85252 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started to ICE with r224161.
[Bug debug/85252] [6/7/8 Regression] ICE with -g for static zero-length array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85252 --- Comment #3 from Jakub Jelinek --- As for warning/error, we do accept static char a[1] = "a"; without warning, and emit a warning for static char a[1] = "ab"; warning: initializer-string for array of chars is too long and similarly emit a warning for a[0] = "a";
[Bug c++/85254] New: boost::is_final does not work for template types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85254
Bug ID: 85254
Summary: boost::is_final does not work for template types
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Created attachment 43868
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43868&action=edit
Preprocessed test case
This problem was initially reported to Boost here:
https://github.com/boostorg/type_traits/issues/66
The test case is this:
#include
#include
#include
struct final1 final {};
template struct final2 final {};
int main() {
std::cout << "boost::is_final: " << boost::is_final::value
<< std::endl;
std::cout << "boost::is_final>::value: " << boost::is_final<
final2 >::value << std::endl;
std::cout << "std::is_final::value: " <<
std::is_final::value << std::endl;
std::cout << "std::is_final>::value: " << std::is_final<
final2 >::value << std::endl;
}
The output with gcc 6.4 and 7.2:
boost::is_final: 1
boost::is_final>::value: 0
std::is_final::value: 1
std::is_final>::value: 1
The expected output should be all 1s.
I suspect the compiler intrinsic __is_final produces incorrect result because
of remove_cv for some reason. boost::is_final is defined like this:
template struct is_final : public integral_constant::type)> {};
where BOOST_IS_FINAL is defined to __is_final. This is similar to std::is_final
except for the remove_cv trait. If I remove remove_cv then the test results are
as expected. remove_cv is implemented this way:
template struct remove_cv{ typedef T type; };
template struct remove_cv{ typedef T type; };
template struct remove_cv{ typedef T type; };
template struct remove_cv{ typedef T type; };
plus the similar specializations for array types, which are irrelevant to this
test.
Unfortunately, I could not reproduce the problem with a more reduced testcase,
including when I re-implemented is_final and remove_cv locally, so it's
possible that some surrounding code is at play.
I'm attaching a preprocessed source a compilable test code. Compile with:
g++ -I -o is_final_test is_final_test.cpp
I'm using Boost develop (pre-1.67), but the problem reproduces with Boost 1.62
that comes with Kubuntu 17.10 and likely any newer versions.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.2.0-8ubuntu3.2' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3.2)
$ g++-6 -v
Using built-in specs.
COLLECT_GCC=g++-6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.4.0-8ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multil
[Bug debug/85252] [6/7/8 Regression] ICE with -g for static zero-length array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85252 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 43867 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43867&action=edit gcc8-pr85252.patch Untested fix.
[Bug c++/85254] boost::is_final does not work for template types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85254 --- Comment #1 from andysem at mail dot ru --- Created attachment 43869 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43869&action=edit Compilable test case
[Bug target/85255] New: [8 Regression] wrong code with -O2 -fno-tree-fre -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85255
Bug ID: 85255
Summary: [8 Regression] wrong code with -O2 -fno-tree-fre
-mavx512f
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 43870
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43870&action=edit
reduced testcase
Output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-tree-fre -mavx512f testcase.c
$ sde64 -- ./a.out
Aborted
The call to foo() is omitted; v[] == {1, 0, 0, 0, } instead of {0, 0, 0,
...}
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-259161-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-259161-checking-yes-rtl-df-extra-amd64
Thread model: posix
gcc version 8.0.1 20180406 (experimental) (GCC)
[Bug c++/85256] New: [8 Regression] ICE with capturing pointer to VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85256
Bug ID: 85256
Summary: [8 Regression] ICE with capturing pointer to VLA
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following code snippet triggers an ICE on trunk:
=
void foo(int i)
{
int (*x)[i];
[=]{ [=]{ 0 ? x : x; }; };
}
=
bug.cc: In lambda function:
bug.cc:4:17: error: capture of variable-size type 'int (*)[i]' that is not an
N3639 array of runtime bound
[=]{ [=]{ 0 ? x : x; }; };
^
bug.cc:4:21: error: capture of variable-size type 'int (*)[i]' that is not an
N3639 array of runtime bound
[=]{ [=]{ 0 ? x : x; }; };
^
bug.cc: In lambda function:
bug.cc:4:24: internal compiler error: in insert_capture_proxy, at
cp/lambda.c:319
[=]{ [=]{ 0 ? x : x; }; };
^
0x615c84 insert_capture_proxy(tree_node*)
../../gcc/gcc/cp/lambda.c:319
0x8dbd9e insert_pending_capture_proxies()
../../gcc/gcc/cp/lambda.c:354
0x9260da cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:10212
0x9260da cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:5263
0x938d7c cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7022
0x939950 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8314
0x91974f cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9082
0x919f5a cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9183
0x91b794 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9478
0x91bea8 cp_parser_expression
../../gcc/gcc/cp/parser.c:9647
0x91db88 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:11123
0x923fcd cp_parser_statement
../../gcc/gcc/cp/parser.c:10927
0x925530 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11266
0x926007 cp_parser_lambda_body
../../gcc/gcc/cp/parser.c:10677
0x926007 cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:10178
0x926007 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:5263
0x938d7c cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7022
0x939950 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8314
0x91974f cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9082
0x919f5a cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9183
Please submit a full bug report, [etc.]
The regression was introduced between 2017-10-07 and 2017-10-13.
I'm not sure whether the code is indeed invalid as the error messages suggest.
The code is accepted by GCC 4.5 - 4.8.
The code is accepted, if I use "int x[i]" instead of "int (*x)[i]".
And clang 3.6 - 5.0 accepts the code.
[Bug lto/85248] [6/7/8 Regression] Miscompilation when using error function that returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85248
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
Self-contained testcase for testsuite:
--- gcc/testsuite/gcc.dg/lto/pr85248_0.c.jj 2018-04-06 14:40:13.483893916
+0200
+++ gcc/testsuite/gcc.dg/lto/pr85248_0.c2018-04-06 14:38:35.190883488
+0200
@@ -0,0 +1,45 @@
+/* PR lto/85248 */
+/* { dg-lto-do run } */
+/* { dg-lto-options { { -flto -O2 } } } */
+
+extern void test_alias (int s, int e) __asm__ (__USER_LABEL_PREFIX__ "test");
+extern void test_noreturn (int s, int e) __asm__ (__USER_LABEL_PREFIX__
"test")
+ __attribute__ ((__noreturn__));
+
+extern inline __attribute__ ((__always_inline__, __gnu_inline__)) void
+test (int s, int e)
+{
+ if (__builtin_constant_p (s) && s != 0)
+test_noreturn (s, e);
+ else
+test_alias (s, e);
+}
+
+int
+foo (void)
+{
+ static volatile int a;
+ return a;
+}
+
+static void
+bar (void)
+{
+ test (0, 1);
+ __builtin_exit (0);
+}
+
+static void
+baz ()
+{
+ test (1, 0);
+}
+
+int
+main ()
+{
+ if (foo ())
+baz ();
+ bar ();
+ __builtin_abort ();
+}
--- gcc/testsuite/gcc.dg/lto/pr85248_1.c.jj 2018-04-06 14:40:16.611894244
+0200
+++ gcc/testsuite/gcc.dg/lto/pr85248_1.c2018-04-06 14:39:24.452888715
+0200
@@ -0,0 +1,9 @@
+/* { dg-options "-fno-lto" } */
+
+__attribute__((__noipa__)) void
+test (int s, int e)
+{
+ asm volatile ("" : "+g" (s), "+g" (e) : : "memory");
+ if (s)
+__builtin_abort ();
+}
[Bug tree-optimization/85257] New: [6/7/8 Regression] wrong code with -O -fno-tree-ccp and reading zeroed vector member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85257 Bug ID: 85257 Summary: [6/7/8 Regression] wrong code with -O -fno-tree-ccp and reading zeroed vector member Product: gcc Version: 8.0.1 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 43871 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43871&action=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -O -fno-tree-ccp testcase.c $ ./a.out Aborted In the assembly: foo: movabs rax, 140736001103584 mov edx, 16329040 ret garbage is returned. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-259161-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-259161-checking-yes-rtl-df-extra-amd64 Thread model: posix gcc version 8.0.1 20180406 (experimental) (GCC)
[Bug c++/85258] New: [7/8 Regression] ICE with invalid range-based for-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85258
Bug ID: 85258
Summary: [7/8 Regression] ICE with invalid range-based for-loop
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following invalid code snippet triggers an ICE since GCC 7.1.0:
template void foo()
{
int x[8];
for (int& i, j : x)
i = 0;
}
void bar()
{
foo<0>();
}
bug.cc: In function 'void foo()':
bug.cc:4:14: error: multiple declarations in range-based 'for' loop
for (int& i, j : x)
^
bug.cc: In instantiation of 'void foo() [with int = 0]':
bug.cc:10:10: required from here
bug.cc:5:5: internal compiler error: Segmentation fault
i = 0;
^
0xebd87f crash_signal
../../gcc/gcc/toplev.c:325
0x85245d reduced_constant_expression_p(tree_node*)
../../gcc/gcc/cp/constexpr.c:1776
0x964822 tsubst_copy
../../gcc/gcc/cp/pt.c:15142
0x9654ef tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18526
0x966768 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17467
0x965a96 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17771
0x971627 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:17099
0x97092e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16300
0x970f2c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16495
0x97005c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16286
0x96e71f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16583
0x96d8b8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16271
0x96d8b8 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23682
0x99476b instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:23798
0x8b8e3b c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4725
Please submit a full bug report, [etc.]
[Bug c++/85242] [6/7/8 Regression] ICE with invalid template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85242 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222
--- Comment #19 from Richard Biener ---
Luckily both failure classes are immutable (via access limitations) so the
following issue with the __dual_ios_failure idea doesn't exist:
catch (old-ABI &e)
{
modify e in-place
throw;
}
...
catch (new-ABI &e)
{
... expect modified content ...
}
[Bug debug/85252] [6/7/8 Regression] ICE with -g for static zero-length array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85252 --- Comment #5 from Themos Tsikas --- If you find a gcc version that doesn't ICE, make sure you try the options "-g -O".
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 Richard Biener changed: What|Removed |Added Target|*-*-solaris2|x86-*-solaris2 Priority|P1 |P3 --- Comment #69 from Richard Biener --- So if sparc*-solaris is clean the priority can be lowered since x86-solaris is neither primary nor secondary. Making it P3 to not completely fall off the radar.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #22 from Jakub Jelinek --- Another gentle ping. As has been mentioned, powerpcspe also lacks gcc-8/changes.html entry.
[Bug middle-end/85123] [8 regression] test case gcc.dg/pr63594-2.c begins failing with r254862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85123 --- Comment #7 from Tamar Christina --- Patch has been reverted as r259169.
[Bug middle-end/85123] [8 regression] test case gcc.dg/pr63594-2.c begins failing with r254862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85123 Jakub Jelinek changed: What|Removed |Added Status|REOPENED|RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Thus fixed.
[Bug ipa/84947] UBSAN: ipcp_bits_lattice::meet_with(generic_wide_int >, generic_wide_int >, unsigned int) ../../gcc/ipa-cp.c:1058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84947 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Jambor --- Fixed
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 84947, which changed state. Bug 84947 Summary: UBSAN: ipcp_bits_lattice::meet_with(generic_wide_int >, generic_wide_int >, unsigned int) ../../gcc/ipa-cp.c:1058 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84947 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/85254] boost::is_final does not work for template types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85254
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-04-06
Ever confirmed|0 |1
--- Comment #2 from Jonathan Wakely ---
Reduced to less than 30kloc
namespace boost {
template
struct integral_constant
{
static const bool value = val;
};
template
bool const integral_constant::value;
template struct remove_cv{ typedef T type; };
template struct is_final
: integral_constant<__is_final(typename remove_cv::type)> {};
}
struct final1 final {};
template struct final2 final {};
static_assert( boost::is_final::value, "" );
static_assert( boost::is_final>::value, "" );
[Bug c++/85258] [7/8 Regression] ICE with invalid range-based for-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85258 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |7.4 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r242422.
[Bug tree-optimization/85257] [6/7/8 Regression] wrong code with -O -fno-tree-ccp and reading zeroed vector member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85257 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |6.5 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r213045. I'll have a look.
[Bug c++/85214] [7/8 Regression] ICE on valid C++17 code on x86_64-linux-gnu: in tsubst_copy, at cp/pt.c:14562
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85214 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/85256] [8 Regression] ICE with capturing pointer to VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85256 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r253601.
[Bug c++/63217] template conversion operator returning const reference not used for conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63217 --- Comment #4 from Jonathan Wakely --- Bug 77660 also looks related
[Bug c++/85254] boost::is_final does not work for template types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85254
--- Comment #3 from Jonathan Wakely ---
Reduced a little further:
template struct remove_cv{ typedef T type; };
template struct is_final
{
static const bool value = __is_final(typename remove_cv::type);
};
struct final1 final {};
template struct final2 final {};
static_assert( is_final::value, "" );
static_assert( is_final>::value, "" );
This should compile but fails with:
is_final_test.cpp:12:16: error: static assertion failed
static_assert( is_final>::value, "" );
^
[Bug target/85177] [8 Regression] wrong code with -O -fno-tree-ccp -fno-tree-sra -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85177 --- Comment #2 from Jakub Jelinek --- *** Bug 85255 has been marked as a duplicate of this bug. ***
[Bug target/85255] [8 Regression] wrong code with -O2 -fno-tree-fre -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85255 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Dup. I've added testcase from this PR into my patch, still waiting for review. *** This bug has been marked as a duplicate of bug 85177 ***
[Bug tree-optimization/85259] New: [8 Regression] Missing -Wstringop-overflow= since r256683
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85259
Bug ID: 85259
Summary: [8 Regression] Missing -Wstringop-overflow= since
r256683
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: law at gcc dot gnu.org, msebor at gcc dot gnu.org
Target Milestone: ---
Since the revision, for:
$ cat /tmp/xx11.c
#include
char buf[6];
int main(int argc, char **argv) {
strcpy(buf,"hello ");
strcat(buf,"world!");
return 0;
}
$ gcc -O2 -Wall /tmp/xx11.c -D_FORTIFY_SOURCE=2
[no output]
Before the revision I see:
/usr/include/bits/string_fortified.h:128:10: warning: ‘__builtin___memcpy_chk’
writing 7 bytes into a region of size 6 overflows the destination
[-Wstringop-overflow=]
