[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039 Eric Botcazou changed: What|Removed |Added CC||helloqirun at gmail dot com --- Comment #29 from Eric Botcazou --- *** Bug 69887 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/69887] [4.9/5/6 Regression] gcc ICE at -O1 and above on x86_64-linux-gnu in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69887 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Eric Botcazou --- __builtin_longjmp cannot be used in the same function as __builtin_setjmp. *** This bug has been marked as a duplicate of bug 59039 ***
[Bug rtl-optimization/69887] [4.9/5/6 Regression] gcc ICE at -O1 and above on x86_64-linux-gnu in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69887 --- Comment #3 from Jakub Jelinek --- But we shouldn't ICE on this. It is fine to reject it with error.
[Bug lto/69953] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 Markus Trippelsdorf changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Markus Trippelsdorf --- markus@x4 tmp % g++ -flto -c -O2 -std=c++11 treeviewcolumn.i && nm treeviewcolumn.o | grep _ZTVN3Gtk14TreeViewColumnE W _ZTVN3Gtk14TreeViewColumnE markus@x4 tmp % g++ -c -O2 -std=c++11 treeviewcolumn.i && nm treeviewcolumn.o | grep _ZTVN3Gtk14TreeViewColumnE V _ZTVN3Gtk14TreeViewColumnE In the resulting lib: x4 ~ # nm /usr/lib64/libgtkmm-2.4.so.1.1.0 | grep _ZTVN3Gtk14TreeViewColumnE 003408e0 d _ZTVN3Gtk14TreeViewColumnE.lto_priv.729 (without lto:) x4 ~ # nm /tmp/libgtkmm-2.4.so.1.1.0 | grep _ZTVN3Gtk14TreeViewColumnE 004331a0 V _ZTVN3Gtk14TreeViewColumnE
[Bug target/69551] [4.9/5/6 Regression] Wrong code with single element vector insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69551 --- Comment #12 from Richard Biener --- Author: rguenth Date: Fri Feb 26 08:34:58 2016 New Revision: 233734 URL: https://gcc.gnu.org/viewcvs?rev=233734&root=gcc&view=rev Log: 2016-02-26 Richard Biener PR tree-optimization/69551 * tree-ssa-structalias.c (get_constraint_for_ssa_var): When looking through aliases adjust DECL_PT_UID to refer to the ultimate alias target. * gcc.dg/torture/pr69951.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr69951.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug tree-optimization/69951] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69951 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Known to work||6.0 Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed for GCC 6.
[Bug lto/69953] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #7 from john.frankish at outlook dot com --- err, OK - excuse my ignorance, but that does that imply?
[Bug lto/69953] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #6 from Markus Trippelsdorf --- markus@x4 tmp % g++ -flto -fPIC -DPIC -shared -nostdlib treeviewcolumn.i && nm ./a.out | grep _ZTVN3Gtk14TreeViewColumnE b4d8 d _ZTVN3Gtk14TreeViewColumnE.lto_priv.2 markus@x4 tmp % g++ -fPIC -DPIC -shared -nostdlib treeviewcolumn.i && nm ./a.out | grep _ZTVN3Gtk14TreeViewColumnE d648 V _ZTVN3Gtk14TreeViewColumnE
[Bug rtl-optimization/69887] [4.9/5/6 Regression] gcc ICE at -O1 and above on x86_64-linux-gnu in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69887 --- Comment #4 from Qirun Zhang --- (In reply to Eric Botcazou from comment #2) > __builtin_longjmp cannot be used in the same function as __builtin_setjmp. > > *** This bug has been marked as a duplicate of bug 59039 *** But the original bug has been fixed by r204592, as mentioned by c#27 of pr59039. The ICE in this report should be a new issue.
[Bug rtl-optimization/69887] [4.9/5/6 Regression] gcc ICE at -O1 and above on x86_64-linux-gnu in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69887 --- Comment #5 from Eric Botcazou --- > But we shouldn't ICE on this. It is fine to reject it with error. See the discussion under PR c/59039. These builtins are undocumented and people must know what they are doing if they use them, which is obviously not the case here since the buffer would already be overrun... HJ's proposed patch for PR c/59039 does document the restriction.
[Bug lto/69953] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #8 from Markus Trippelsdorf --- (In reply to john.frankish from comment #7) > err, OK - excuse my ignorance, but that does that imply? It it the reason for your link failure. Now the question is, if the compiler is right to make the symbol local with LTO?
[Bug rtl-optimization/69887] [4.9/5/6 Regression] gcc ICE at -O1 and above on x86_64-linux-gnu in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69887 --- Comment #6 from Eric Botcazou --- > But the original bug has been fixed by r204592, as mentioned by c#27 of > pr59039. The ICE in this report should be a new issue. No, PR c/59039 is open and not fixed, the patch is still pending.
[Bug target/54349] _mm_cvtsi128_si64 unnecessary stores value at stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54349
Alexander Peslyak changed:
What|Removed |Added
CC||solar-gcc at openwall dot com
--- Comment #10 from Alexander Peslyak ---
I confirm that this is fixed in 4.9. Since a lot of people are still using
pre-4.9 gcc and may stumble upon this bug, here's my experience with the bug
and with working around it:
The bug manifests itself the worst when only a pre-SSE4.1 instruction set is
available (such as when compiling for x86_64 with no -m... options given), and
(at least for me) especially on AMD Bulldozer: over 26% speedup from fully
working around the bug in plain SSE2 build of yescrypt with Ubuntu 12.04's gcc
4.6.3 on FX-8120. On Intel CPUs, the impact of the bug is typically 5% to 10%.
Enabling SSE4.1 (or AVX or better) mostly mitigates the bug, resulting in
inbetween or full speeds (varying by CPU), since "(v)pextrq $0," is then
generated and it is almost as good as "(v)movq" (but not exactly).
The suggested "-mtune=corei7" workaround works, but is only recognized by gcc
4.6 and up (thus, is only for versions 4.6.x to 4.8.x). At source file level,
this works:
#if defined(__x86_64__) && \
__GNUC__ == 4 && __GNUC_MINOR__ >= 6 && __GNUC_MINOR__ < 9
#pragma GCC target ("tune=corei7")
#endif
A related bug is that those versions of gcc with that workaround wrongly
generate "movd" (as in e.g. "movd %xmm0, %rax") instead of "movq". Luckily,
binutils primarily looks at the register names and silently corrects this error
(there's "movq" in the disassembly).
For a much wider range of gcc versions - 4.0 and up - this works:
#if defined(__x86_64__) && __GNUC__ == 4 && __GNUC_MINOR__ < 9
#ifdef __AVX__
#define MAYBE_V "v"
#else
#define MAYBE_V ""
#endif
#define _mm_cvtsi128_si64(x) ({ \
uint64_t result; \
__asm__(MAYBE_V "movq %1,%0" : "=r" (result) : "x" (x)); \
result; \
})
#endif
A drawback for using inline asm for a single instruction is that it might
negatively affect gcc's instruction scheduling (where gcc ends up unaware of
the inlined instruction's timings). However, on this specific occasion (with
yescrypt) I am not seeing any slowdown of such code compared to the
"tune=corei7" approach, nor compared to gcc 4.9+. It just works for me.
Still, because of this concern, it might be wise to combine the two approaches,
only resorting to inline asm on pre-4.6 gcc:
/* gcc before 4.9 would unnecessarily use store/load (without SSE4.1) or
* (V)PEXTR (with SSE4.1 or AVX) instead of simply (V)MOV. */
#if defined(__x86_64__) && \
__GNUC__ == 4 && __GNUC_MINOR__ >= 6 && __GNUC_MINOR__ < 9
#pragma GCC target ("tune=corei7")
#endif
#include
#include
#if defined(__x86_64__) && __GNUC__ == 4 && __GNUC_MINOR__ < 6
#ifdef __AVX__
#define MAYBE_V "v"
#else
#define MAYBE_V ""
#endif
#define _mm_cvtsi128_si64(x) ({ \
uint64_t result; \
__asm__(MAYBE_V "movq %1,%0" : "=r" (result) : "x" (x)); \
result; \
})
#endif
Unfortunately, unlike the pure inline asm workaround, this relies on binutils
correcting the "movd" for gcc 4.6.x to 4.8.x. Oh well.
I've tested the above combined workaround on these gcc versions (and it works):
4.0.0 4.1.0 4.1.2 4.2.0 4.2.4 4.3.0 4.3.6 4.4.0 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5
4.4.6 4.5.0 4.5.3 4.6.0 4.6.2 4.7.0 4.7.4 4.8.0 4.8.4 4.9.0 4.9.2
[Bug c++/69970] Surprising warning with -Wnonnull-compare - 'this' compared to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69970
--- Comment #1 from Richard Biener ---
You are comparing this against null when invoking the constructor and the
compiler tells you the code is equivalent to
Bar ()
: foo_ (new (true))
{}
[Bug other/69968] RFC: Use Damerau-Levenshtein within spellcheck.c, rather than Levenshtein
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69968 --- Comment #1 from Richard Biener --- but the distance from coorzd1 to coordz1 should be 2 one deletion and one insertion. Why's that not found?
[Bug c++/69970] Surprising warning with -Wnonnull-compare - 'this' compared to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69970 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Jakub Jelinek --- Yeah, the warning here is right IMHO.
[Bug c++/69967] #pragma GCC diagnostic ignored being ignored for -Wunused-variable in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69967 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-26 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Yes, IPA (symtab) code warns about this and it doesn't push/pop warning options. In fact for global variables there are no saved options at all.
[Bug c++/69961] Segfault when calling constructor from variadic template by referring to T::T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69961 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-26 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- It crashes in Format::~Format during buffer destruction.
[Bug middle-end/69975] Missing uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69975 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener --- We have dups about the missed warning (CCP is too eager to optimize this for a warning to trigger)
[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891
Eric Botcazou changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Eric Botcazou ---
The problematic store is based on argp so it isn't killed by the memset, since
only those based on sp or fp are:
**scanning insn=20
mem: (symbol_ref:SI ("memset") [flags 0x41] )
after canon_rtx address: (symbol_ref:SI ("memset") [flags 0x41]
)
gid=1 offset=0
processing const load gid=1[0..1)
removing from active insn=19 has store
removing from active insn=18 has store
removing from active insn=17 has store
memset call 20
It's apparently a small loophole in the PR middle-end/31150 enhancement.
Index: dse.c
===
--- dse.c (revision 233545)
+++ dse.c (working copy)
@@ -2528,6 +2528,10 @@ scan_insn (bb_info_t bb_info, rtx_insn *
i_ptr = i_ptr->next_local_store;
}
+ /* But a call to memset clobbers memory so invalidates stores. It's
+not only an optimization issue (the previous stores may be dead)
+but also a correctness issue since the previous stores cannot be
+seen as the source of the current value of the locations. */
if (memset_call)
{
rtx args[3];
@@ -2556,6 +2560,8 @@ scan_insn (bb_info_t bb_info, rtx_insn *
active_local_stores = insn_info;
}
}
+ else
+ add_non_frame_wild_read (bb_info);
}
}
else if (SIBLING_CALL_P (insn) && reload_completed)
Jakub, does this look good to you?
[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891
--- Comment #4 from Eric Botcazou ---
> It's apparently a small loophole in the PR middle-end/31150 enhancement.
In fact this is sufficient:
Index: dse.c
===
--- dse.c (revision 233545)
+++ dse.c (working copy)
@@ -2528,6 +2528,10 @@ scan_insn (bb_info_t bb_info, rtx_insn *
i_ptr = i_ptr->next_local_store;
}
+ /* But a call to memset clobbers memory so invalidates stores. It's
+not only an optimization issue (the previous stores may be dead)
+but also a correctness issue since the previous stores cannot be
+seen as the source of the current value of the locations. */
if (memset_call)
{
rtx args[3];
@@ -2556,6 +2560,8 @@ scan_insn (bb_info_t bb_info, rtx_insn *
active_local_stores = insn_info;
}
}
+ else
+ reset_active_stores ();
}
}
else if (SIBLING_CALL_P (insn) && reload_completed)
[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891
--- Comment #5 from Jakub Jelinek ---
(In reply to Eric Botcazou from comment #3)
> The problematic store is based on argp so it isn't killed by the memset,
> since only those based on sp or fp are:
>
> **scanning insn=20
> mem: (symbol_ref:SI ("memset") [flags 0x41] memset>)
>
>after canon_rtx address: (symbol_ref:SI ("memset") [flags 0x41]
> )
> gid=1 offset=0
> processing const load gid=1[0..1)
> removing from active insn=19 has store
> removing from active insn=18 has store
> removing from active insn=17 has store
> memset call 20
>
> It's apparently a small loophole in the PR middle-end/31150 enhancement.
>
> Index: dse.c
> ===
> --- dse.c (revision 233545)
> +++ dse.c (working copy)
> @@ -2528,6 +2528,10 @@ scan_insn (bb_info_t bb_info, rtx_insn *
> i_ptr = i_ptr->next_local_store;
> }
>
> + /* But a call to memset clobbers memory so invalidates stores.
> It's
> +not only an optimization issue (the previous stores may be dead)
> +but also a correctness issue since the previous stores cannot be
> +seen as the source of the current value of the locations. */
> if (memset_call)
> {
> rtx args[3];
> @@ -2556,6 +2560,8 @@ scan_insn (bb_info_t bb_info, rtx_insn *
> active_local_stores = insn_info;
> }
> }
> + else
> + add_non_frame_wild_read (bb_info);
> }
> }
>else if (SIBLING_CALL_P (insn) && reload_completed)
>
>
> Jakub, does this look good to you?
But the memset could be also SIBLING_CALL_P.
Wouldn't it be better to change the else if to if, and add
if (const_call) return;
plus return to the end of mems_found == 1 then block? Then it would fall
through to arbitrary other call handling.
[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891
--- Comment #6 from Eric Botcazou ---
> But the memset could be also SIBLING_CALL_P.
> Wouldn't it be better to change the else if to if, and add
> if (const_call) return;
> plus return to the end of mems_found == 1 then block? Then it would fall
> through to arbitrary other call handling.
That would unnecessarily add a wild read. So what about:
Index: dse.c
===
--- dse.c (revision 233545)
+++ dse.c (working copy)
@@ -2528,6 +2528,10 @@ scan_insn (bb_info_t bb_info, rtx_insn *
i_ptr = i_ptr->next_local_store;
}
+ /* But a call to memset clobbers memory so invalidates stores. It's
+not only an optimization issue (the previous stores may be dead)
+but also a correctness issue since the previous stores cannot be
+seen as the source of the current value of the locations. */
if (memset_call)
{
rtx args[3];
@@ -2556,6 +2560,8 @@ scan_insn (bb_info_t bb_info, rtx_insn *
active_local_stores = insn_info;
}
}
+ else if (!SIBLING_CALL_P (insn))
+ reset_active_stores ();
}
}
else if (SIBLING_CALL_P (insn) && reload_completed)
[Bug fortran/69834] Collision in derived type hashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69834
--- Comment #8 from Paul Thomas ---
(In reply to Dominique d'Humieres from comment #6)
> > Created attachment 37791 [details]
> > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37791&action=edit
> > Better Patch
>
> Withe patch applied to my working tree (many patches) fixes the PR but I see
> several regressions at run time
>
> FAIL: gfortran.dg/allocate_with_source_(7|8).f08 * execution test
> FAIL: gfortran.dg/unlimited_polymorphic_zzz.f03 * execution test
>
> with zzz in (1, 5, 6, 14, 17, 18, 20, 22). AFAICT it "fixes"
>
> FAIL: gfortran.dg/finalize_21.f90 -O scan-tree-dump original "static
> struct __vtype__STAR __vtab__STAR = {._hash=0, ._size=., ._extends=0B,
> ._def_init=0B, ._copy=0B, ._final=0B};"
Dominique,
I just applied the patch posted here to another tree on another machine and it
regtests fine.
Could you please send me the tree dump for one of the failing cases, especially
unlimited_polymorphic_1.f03 if that is amongst them?
It would be good if you could confirm that it is only cases of intrinsic types
that cause the failures. I had a lot of trouble with those. Try this testcase
and send me the tree dump as well:
type a
integer :: a = 99
end type
type, extends (a) :: b
real :: b = 1.0
end type
class(*), allocatable :: star
real(8) :: x = 3.14152
character(4) :: chr = "abcd"
allocate (star, mold = b())
select type (star)
type is (a)
print *, "a = ", star%a
type is (b)
print *, "b = ", star%a, star%b
class default
print *, "FAILURE"
end select
deallocate (star)
allocate (star, source = x)
select type (star)
type is (real(8))
print *, "x = ", star
class default
print *, "FAILURE on REAL(8)"
end select
deallocate (star)
allocate (star, source = chr)
select type (star)
type is (character(*))
print *, "chr = ", star
class default
print *, "FAILURE on CHARACTER(*)"
end select
end
Thanks
Paul
[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #7 from Eric Botcazou --- Testing a fix.
[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891 --- Comment #8 from Jakub Jelinek --- I think the right fix is just: --- gcc/dse.c.jj2016-01-19 13:32:12.0 +0100 +++ gcc/dse.c 2016-02-26 11:03:36.694206088 +0100 @@ -2556,6 +2556,8 @@ scan_insn (bb_info_t bb_info, rtx_insn * active_local_stores = insn_info; } } + else + clear_rhs_from_active_local_stores (); } } else if (SIBLING_CALL_P (insn) && reload_completed) memset, even if we can't figure out its arguments, is never a read of anything (except for the arguments, but those are already handled similarly to const calls). clear_rhs_from_active_local_stores () is the punt action in record_store, we store something, but we don't know where exactly.
[Bug middle-end/69976] New: Zero the local stack on function exit; don't optimize out memset before return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976 Bug ID: 69976 Summary: Zero the local stack on function exit; don't optimize out memset before return Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: daniel.gutson at tallertechnologies dot com Target Milestone: --- Existing security practices recommend to the arrays of automatic storage duration (e.g. by zeroing them) upon function exit. This could be done by calling memset; however, gcc seems to optimize out the call to memset before the return statement (or when the memset call is the last statement). This forces secure-sensitive applications to implement their own memset, usually a copy of it. I suggest the following enhancement: -provide two new attributes: 'clear_stack' and 'allow_ending_memset' -provide two new flags: -fclear-stack and -Wdirty-stack -logic: by using -fclear-stack, the following modes can be specified: -fclear-stack=none: current behavior, memset is optimized out -fclear-stack=attribute: user controls the behavior per function basis by using the attributes; 'clear_stack' causes gcc to add the memset call at the end of the function (no control flow analysis recommended), whereas 'allow_ending_memset' prevents gcc to optimize out the call to memset enabling the user to call it. Specifying both attributes in the same function should not be allowed. -fclear-stack=auto: instructs gcc to emit a call to memset at the end of functions having arrays of automatic storage duration (zeroing those arrays only). The 'clear_stack' attribute can be used in this mode to force the stack zeroing on particular functions overriding the decision logic -fclear-stack=always: instructs gcc to emit a call to memset at the end of every function having a nonempty stack. -Wdirty-stack: only to be used with -fclear-stack=attribute, causes gcc to emit a warning message when a function has at least an array of static storage duration but is not zeroed at the end (either because 'clear_stack' wasn't specified or because there is no memset call statement; control flow analysis similar to the one used by detecting paths with no return statement on non void-return functions could be used). Please assign this to andres.tirabos...@tallertechnologies.com
[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891 --- Comment #9 from Jakub Jelinek --- Created attachment 37801 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37801&action=edit gcc6-pr69891.patch Full patch I'm going to bootstrap/regtest.
[Bug fortran/69834] Collision in derived type hashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69834
--- Comment #9 from Dominique d'Humieres ---
> > > Created attachment 37791 [details]
> > > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37791&action=edit
> > > Better Patch
> >
> > With the patch applied to my working tree (many patches) fixes the PR
> > but I see several regressions at run time
> >
> > FAIL: gfortran.dg/allocate_with_source_(7|8).f08 * execution test
> > FAIL: gfortran.dg/unlimited_polymorphic_zzz.f03 * execution test
> >
> > with zzz in (1, 5, 6, 14, 17, 18, 20, 22). AFAICT it "fixes"
> >
> > FAIL: gfortran.dg/finalize_21.f90 -O scan-tree-dump original "static
> > struct __vtype__STAR __vtab__STAR = {._hash=0, ._size=., ._extends=0B,
> > ._def_init=0B, ._copy=0B, ._final=0B};"
> I just applied the patch posted here to another tree on another machine
> and it regtests fine.
The failures come from a conflict with your patch for recursive allocatable
derived type components. If I revert it, gfortran regtests fine with the patch
for this PR with the following patch
--- ../_clean/gcc/testsuite/gfortran.dg/finalize_21.f90 2015-05-29
11:25:09.0 +0200
+++ gcc/testsuite/gfortran.dg/finalize_21.f90 2016-02-26 10:39:18.0
+0100
@@ -8,4 +8,4 @@
class(*), allocatable :: var
end
-! { dg-final { scan-tree-dump "static struct __vtype__STAR __vtab__STAR =
{._hash=0, ._size=., ._extends=0B, ._def_init=0B, ._copy=0B, ._final=0B};"
"original" } }
+! { dg-final { scan-tree-dump "static struct __vtype__STAR __vtab__STAR =
\{._hash=0, ._size=., ._extends=0B, ._def_init=0B, ._copy=0B, ._final=0B,"
"original" } }
[Bug lto/69953] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 Markus Trippelsdorf changed: What|Removed |Added CC||hubicka at ucw dot cz --- Comment #9 from Markus Trippelsdorf --- clang makes the symbol external for both lto and non-lto: d5f0 D _ZTVN3Gtk14TreeViewColumnE Reducing...
[Bug c++/69977] New: internal compiler error: Segmentation fault when using generic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69977
Bug ID: 69977
Summary: internal compiler error: Segmentation fault when using
generic lambdas
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub.gocol at gmail dot com
Target Milestone: ---
Created attachment 37802
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37802&action=edit
compiler output, preprocessed input that causes crash
class A {
private:
void method(int i) {
(void) i;
}
public:
void publicMethod() {
auto lambda = [&] (const auto k) {
method(k);
};
lambda(42);
}
};
int main()
{
A a;
a.publicMethod();
return 0;
}
===
Following code causes g++ to crash:
test.cpp: In lambda function:
test.cpp:10:13: internal compiler error: Segmentation fault
method(k);
^
I'm compiling with command: g++ -std=c++14 file.cpp
output of g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-8'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --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 --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.1 20160205 (Debian 5.3.1-8)
In attachment I provided:
- full compiler output (with backtrace)
- preprocessed input that causes crash
- preprocessed, slightly modified input, that works as expected
[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891 Eric Botcazou changed: What|Removed |Added Assignee|ebotcazou at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #10 from Eric Botcazou --- > I think the right fix is just: > --- gcc/dse.c.jj 2016-01-19 13:32:12.0 +0100 > +++ gcc/dse.c 2016-02-26 11:03:36.694206088 +0100 > @@ -2556,6 +2556,8 @@ scan_insn (bb_info_t bb_info, rtx_insn * > active_local_stores = insn_info; > } > } > + else > + clear_rhs_from_active_local_stores (); > } > } >else if (SIBLING_CALL_P (insn) && reload_completed) > > memset, even if we can't figure out its arguments, is never a read of > anything (except for the arguments, but those are already handled similarly > to const calls). clear_rhs_from_active_local_stores () is the punt action > in record_store, we store something, but we don't know where exactly. Yes, this looks more precise than reset_active_stores indeed. Assign back if you want me to do the testing.
[Bug target/69946] [6 Regression] Invalid ppc64 assembly emitted starting with r226005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69946 --- Comment #2 from Jakub Jelinek --- Created attachment 37803 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37803&action=edit gcc6-pr69946.patch What about this untested patch? Ideas for better name of the new helper function? Seems that both rs6000_is_valid_shift_mask and rs6000_insn_for_shift_mask were doing pretty much the same thing in their first halves (preparation), except that for insert we assume that the shift count is always CONST_INT. So, this patch moves all that preparation into the helper, and uses it in all the 4 functions.
[Bug c++/69977] internal compiler error: Segmentation fault when using generic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69977 Jonathan Wakely changed: What|Removed |Added Severity|major |normal
[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891
--- Comment #11 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 37801 [details]
> gcc6-pr69891.patch
>
> Full patch I'm going to bootstrap/regtest.
+/* PR rtl-optimization/69891 */
+/* { dg-do run } */
+/* { dg-options "-O -fno-tree-fre -mstringop-strategy=libcall -Wno-psabi" } */
+/* { dg-additional-options "-mno-sse" { target ia32 } } */
-mstringop-strategy is x86 specific option.
[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891
--- Comment #12 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to Jakub Jelinek from comment #9)
> > Created attachment 37801 [details]
> > gcc6-pr69891.patch
> >
> > Full patch I'm going to bootstrap/regtest.
>
> +/* PR rtl-optimization/69891 */
> +/* { dg-do run } */
> +/* { dg-options "-O -fno-tree-fre -mstringop-strategy=libcall -Wno-psabi" }
> */
> +/* { dg-additional-options "-mno-sse" { target ia32 } } */
>
> -mstringop-strategy is x86 specific option.
Oh ... the testcase *is* in gcc.target/i386/... directory
[Bug c++/69977] internal compiler error: Segmentation fault when using generic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69977 Richard Biener changed: What|Removed |Added Keywords||accepts-invalid, ||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-26 Known to work||6.0 Ever confirmed|0 |1 Known to fail||5.3.0 --- Comment #1 from Richard Biener --- Confirmed on the GCC 5 branch, trunk rejects the testcase: > ./cc1plus -quiet t.ii -std=c++14 t.ii: In instantiation of ‘A::publicMethod():: [with auto:1 = int]’: t.ii:9:33: required by substitution of ‘template A::publicMethod()operator decltype (((A::publicMethod()::)0u).operator()(static_cast())) (*)(auto:1)() const [with auto:1 = int]’ t.ii:12:11: required from here t.ii:10:6: error: cannot call member function ‘void A::method(int)’ without object method(k); ^~
[Bug c++/69970] Surprising warning with -Wnonnull-compare - 'this' compared to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69970 --- Comment #3 from Lars Gullik Bjønnes --- The warning might be right, but is very unhelpful. Also with gcc 5 I get no warning (and seeming working code). Note that this is reduced (and thus a bit strange) from a much larger code base.
[Bug middle-end/69976] Zero the local stack on function exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-26 Assignee|unassigned at gcc dot gnu.org |andres.tiraboschi@tallertec ||hnologies.com Summary|Zero the local stack on |Zero the local stack on |function exit; don't|function exit |optimize out memset before | |return | Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I think what is more reasonable is just adding a function attribute clear_stack that makes sure stack adjustments clear no longer necessary stack slots _plus_ not use the red zone if available (or clear that as well). Such attribute must also make the function not considered for inlining. Nothing specific to "memset" should be implemented. To allow inlining eventually the inliner would have to propagate the clearing requirement up to the functions inlined to. Note that secure stack does not only mean to clear local arrays as a programmer would be able to do with memset (if the compiler were not optimizing that away) but also ensuring that all spill slots are cleared as (old) register values carrying secure information may leak to them otherwise.
[Bug c/69974] [6 Regression] gcc ICE on invalid code on x86_64-linux-gnu in "create_tmp_from_val"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69974
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-02-26
CC||jakub at gcc dot gnu.org
Summary|gcc ICE on invalid code on |[6 Regression] gcc ICE on
|x86_64-linux-gnu in |invalid code on
|"create_tmp_from_val" |x86_64-linux-gnu in
||"create_tmp_from_val"
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Started with r232622.
Less broken testcase with the same ICE:
struct S;
char foo (struct S *);
struct S a;
int b;
void
bar ()
{
b &= foo (&a);
}
[Bug c/69974] [6 Regression] gcc ICE on invalid code on x86_64-linux-gnu in "create_tmp_from_val"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69974 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |6.0
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #27 from rguenther at suse dot de --- On Thu, 25 Feb 2016, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 > > --- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- > > --- Comment #23 from Richard Biener --- > > Well, looks like same analysis as the last time ;) Sth is broken on > > solaris - > > please check with gdb how the stack is aligned on function entry. > > I've checked stack alignment on entry to md5_finish_ctx and found 8-byte > alignment on Solaris 10, 4-byte alignment on Solaris 11 and 12 (where > the test never failed). > > Very strange. We still have PR target/62281 which claims that 32-bit > Solaris/x86 still only guarantees 4-byte alignment, in accordance with > the 32-bit x86 psABI. Unfortunately, the submitter never responded to > my questions; I'll have to ask my contacts for details. > > Maybe we'll need the Solaris 9-only fix from PR libgomp/60107 on Solaris > 10+, too. Or do -mstackrealign by default like it is done on Windows. Richard.
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #27 from rguenther at suse dot de --- [...] >> Maybe we'll need the Solaris 9-only fix from PR libgomp/60107 on Solaris >> 10+, too. > > Or do -mstackrealign by default like it is done on Windows. That's exactly what that patch did: #define STACK_REALIGN_DEFAULT 1 in i386/sol2-9.h. Rainer
[Bug other/69968] RFC: Use Damerau-Levenshtein within spellcheck.c, rather than Levenshtein
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69968
--- Comment #2 from David Malcolm ---
(In reply to Richard Biener from comment #1)
> but the distance from coorzd1 to coordz1 should be 2 one deletion and one
> insertion. Why's that not found?
I think the distance given in the initial comment is slightly wrong, sorry.
AIUI, with Levenshtein as the distance metric, *all* of the fields have
distance 2 (rather than 3): "coorzd1" to "coordx" can be reached by a deletion
and a substitution:
coorzd1 -> coord1 -> coordx (Levenshtein distance = 2)
Similarly for all "coord{xyz}":
coorzd1 -> coord1 -> coord{xyz} (Levenshtein distance = 2)
For "coord{xyz}1" we have:
coorzd1 -> coord1 -> coord{xyz}1 (Levenshtein distance = 2)
i.e. all fields have Levenshtein distance of 2 from "coorzd1".
With Damerau-Levenshtein, we'd have (I think):
coorzd1 -> coorzd1 (Damerau-Levenshtein distance = 1)
coorzd1 -> coord1 -> coord{xy}[1] (Damerau-Levenshtein distance = 2)
coorzd1 -> coordz1 -> coordz (Damerau-Levenshtein distance = 2)
and hence "coorzd1" would be uniquely closer to "coorzd1" than all of the other
5 fields.
(using http://www.let.rug.nl/kleiweg/lev/, and adjusting all weights to 1)
[Bug target/69789] g++ -O2 is removing tests against a variable that can be changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69789 Tomek Mrugalski changed: What|Removed |Added CC||thomson at klub dot com.pl --- Comment #4 from Tomek Mrugalski --- This issue also manifests itself on fully up-to-date Ubuntu 15.10, which has the following version g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010. Here's also a bug report that confirms this issue on Fedora 23: https://lists.isc.org/pipermail/kea-users/2016-February/000232.html, https://lists.isc.org/pipermail/kea-users/2016-February/000234.html The reported version there is: g++ (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)
[Bug other/69968] RFC: Use Damerau-Levenshtein within spellcheck.c, rather than Levenshtein
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69968
--- Comment #3 from David Malcolm ---
(In reply to David Malcolm from comment #2)
Gah; I had typos in some of these; fixing them inline below (I hope):
> With Damerau-Levenshtein, we'd have (I think):
>
> coorzd1 -> coordz1 (Damerau-Levenshtein distance = 1)
> coorzd1 -> coord1 -> coord{xy}[1] (Damerau-Levenshtein distance = 2)
> coorzd1 -> coorzd -> coordz (Damerau-Levenshtein distance = 2)
>
> and hence "coorzd1" would be uniquely closer to "coordz1" than all of the
> other 5 fields.
[Bug c/69796] [6 Regression] ICE on invalid code in useless_type_conversion_p, at gimple-expr.c:83
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69796 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|bernds at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 37804 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37804&action=edit gcc6-pr69796-1.patch As the other PRs clearly show, the middle-end is simply unprepared to have error_mark_node type on the VAR_DECLs appearing so late in the IL. So, IMHO we have two options, either set TREE_TYPE to some random other valid type, as this patch...
[Bug c/69796] [6 Regression] ICE on invalid code in useless_type_conversion_p, at gimple-expr.c:83
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69796 --- Comment #5 from Jakub Jelinek --- Created attachment 37805 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37805&action=edit gcc6-pr69796-2.patch Or don't change it at all. If the FE emits error, then we are in error recovery and don't reach assemble_variable anyway, e.g. symbol_table::compile does nothing if seen_error (), so I think the risks of emitting the error twice are low.
[Bug c++/69978] New: Invalid sizeof... value for variadic template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69978
Bug ID: 69978
Summary: Invalid sizeof... value for variadic template
arguments
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yanikibo at yandex dot com
Target Milestone: ---
#include
#include
template < std::size_t N >
struct A { enum : std::size_t { value = N }; };
template < class... TL >
using B = A< sizeof...(TL) >;
template < class T >
struct C { using type = T; };
template < class... TL >
using D = typename C< B >::type;
template < class T, class U, class... TL >
void foo( T, U, TL... )
{
assert( (B::value) == (2 + sizeof...(TL)) );
// failed(g++4.7) passed(g++4.8+)
assert( (D::value) == (2 + sizeof...(TL)) );
// failed(g++4.7) passed(g++4.8+)
assert( (C< B >::type::value) == (2 + sizeof...(TL)) );
// failed(g++4.7+)
}
int main()
{
foo(10, 20, 30, 40, 50);
}
[Bug c++/69978] Invalid sizeof... value for variadic template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69978 Jonathan Wakely changed: What|Removed |Added Severity|major |normal --- Comment #1 from Jonathan Wakely --- Surely a dup of PR 69958
[Bug middle-end/69976] Zero the local stack on function exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- It should also clear all call clobbered registers at the end of the function that could be touched by the function (or all, if it calls other functions).
[Bug lto/69953] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
--- Comment #10 from Markus Trippelsdorf ---
markus@x4 tmp % cat foo.ii
namespace Glib {
class ObjectBase {
protected:
virtual ~ObjectBase();
};
class A : virtual public ObjectBase {};
class B : virtual public ObjectBase {};
}
namespace Gtk {
class C : Glib::A {};
class D : public Glib::B {};
class TreeViewColumn : C, D {
~TreeViewColumn();
};
TreeViewColumn::~TreeViewColumn() {}
}
markus@x4 tmp % g++ -Os -flto -fPIC -shared -nostdlib -std=c++11 foo.ii && nm
./a.out | grep "_ZTVN3Gtk14TreeViewColumnE"
26a8 d _ZTVN3Gtk14TreeViewColumnE
markus@x4 tmp % g++ -Os -fPIC -shared -nostdlib -std=c++11 foo.ii && nm ./a.out
| grep "_ZTVN3Gtk14TreeViewColumnE"
25c8 V _ZTVN3Gtk14TreeViewColumnE
markus@x4 tmp % g++ -O2 -fPIC -shared -nostdlib -std=c++11 foo.ii && nm ./a.out
| grep "_ZTVN3Gtk14TreeViewColumnE"
13a8 V _ZTVN3Gtk14TreeViewColumnE
markus@x4 tmp % clang++ -O2 -fPIC -shared -nostdlib -std=c++11 foo.ii && nm
./a.out | grep "_ZTVN3Gtk14TreeViewColumnE"
2900 D _ZTVN3Gtk14TreeViewColumnE
markus@x4 tmp % clang++ -flto -O2 -fPIC -shared -nostdlib -std=c++11 foo.ii &&
nm ./a.out | grep "_ZTVN3Gtk14TreeViewColumnE"
2450 D _ZTVN3Gtk14TreeViewColumnE
[Bug c++/69977] internal compiler error: Segmentation fault when using generic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69977 Jonathan Wakely changed: What|Removed |Added Keywords|accepts-invalid,|ice-on-valid-code |ice-on-invalid-code | --- Comment #2 from Jonathan Wakely --- Trunk rejects it incorrectly, I think that's PR 61636
[Bug c++/69978] Invalid sizeof... value for variadic template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69978
--- Comment #2 from Ibrahim Gokhan YANIKLAR ---
template < class T, class U, class... TL >
void goo( T, U, TL... )
{
std::cout << (B::value) << std::endl;
std::cout << (D::value) << std::endl;
std::cout << (C< B >::type::value << std::endl;
}
int main()
{
goo(10, 20, 30, 40, 50);
}
//---
// output(g++4.7):
//---
// 3
// 3
// 3
//---
// output(g++4.8-g++5.2):
//---
// 5
// 5
// 3
//---
// output(correct)
//---
// 5
// 5
// 5
[Bug c++/69958] sizeof... computes wrong size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69958
Ibrahim Gokhan YANIKLAR changed:
What|Removed |Added
CC||yanikibo at yandex dot com
--- Comment #2 from Ibrahim Gokhan YANIKLAR ---
#include
template < std::size_t N >
struct A { enum : std::size_t { value = N }; };
template < class... TL >
using B = A< sizeof...(TL) >;
template < class T >
struct C { using type = T; };
template < class... TL >
using D = typename C< B >::type;
template < class T, class U, class... TL >
void foo( T, U, TL... )
{
std::cout << (B::value) << std::endl;
std::cout << (D::value) << std::endl;
std::cout << (C< B >::type::value) << std::endl;
}
int main()
{
foo(10, 20, 30, 40, 50);
}
//---
// output(g++4.7):
//---
// 3
// 3
// 3
//---
// output(g++4.8-g++5.3):
//---
// 5
// 5
// 3
//---
// output(correct)
//---
// 5
// 5
// 5
[Bug c++/69978] Invalid sizeof... value for variadic template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69978 Ibrahim Gokhan YANIKLAR changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Ibrahim Gokhan YANIKLAR --- It's duplicate of PR 69958 *** This bug has been marked as a duplicate of bug 69958 ***
[Bug c++/69958] sizeof... computes wrong size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69958 --- Comment #3 from Ibrahim Gokhan YANIKLAR --- *** Bug 69978 has been marked as a duplicate of this bug. ***
[Bug target/69979] New: ARM naked function attribute not handling structs bigger than 32 bits correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69979
Bug ID: 69979
Summary: ARM naked function attribute not handling structs
bigger than 32 bits correctly
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andre.simoesdiasvieira at arm dot com
Target Milestone: ---
As reported by Cory in https://bugs.launchpad.net/gcc-arm-embedded/+bug/1549542
It seems the naked function attribute for ARM is generating code for struct
parameters being passed in registers. This code stores these structs being
passed as registers on the stack, using 'r3' as a scratch register. Apart from
being suboptimal, this writes to 'r3' even though 'r3' might be used to hold a
parameter!
For instance with the following C code:
struct test {
int a;
int b;
};
int
foo (struct test t, int a, int b)
{
__asm ("mov r0, r3\n\t"
"bx lr");
}
when compiled with
$arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -S
will yield the following assembly:
foo:
@ Naked Function: prologue and epilogue provided by programmer.
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 1, uses_anonymous_args = 0
mov r3, r7
stm r3, {r0, r1}
.syntax unified
@ 9 "tnaked.c" 1
mov r0, r3
bx lr
@ 0 "" 2
.syntax unified
nop
mov r0, r3
As you see 'r3' will have been rewritten with the frame pointer before being
moved to 'r0' for the return. Also the last 'mov r0, r3' after the 'nop' looks
a bit odd!
Something equally weird happens when returning such a struct:
struct test
bar (int a, int b, int c)
{
__asm ("stmia r0, {r2, r3}\n\t"
"bx lr");
}
One would naturally expect to be storing 'b' and 'c' into '[r0]', the place
where the caller expects the return value to be written to. However the
following assembly is generated, which overwrites r3 (which should contain
argument 'c'):
bar:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, r0
@ 16 "tnaked.c" 1
stmia r0, {r2, r3}
bx lr
@ 0 "" 2
.thumb
mov r0, r3
bx lr
Again with the unexpected epilogue code creeping in.
I have observed this behavior for various ARM targets dating back to gcc 4.8
(haven't tried earlier than that).
[Bug tree-optimization/69980] New: [6 regression] Supposedly wrong SLP code emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69980 Bug ID: 69980 Summary: [6 regression] Supposedly wrong SLP code emitted Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: kyukhin at gcc dot gnu.org Target Milestone: --- Created attachment 37806 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37806&action=edit Reproducer Hello, Attached test runfails when compiled is following: $ gfortran -m64 -Ofast repro.f90 -msse When compiled w/ -O2 - it works fine. Second loop nest is just for verification. Issue lives here: mumax = 0; do k=1,26 do i=1,3 mumax(i) = max(mumax(i), mu(i,k)+mu(i,k)) end do end do Looks like SLP emits some wrong permutations here.
[Bug tree-optimization/69980] [6 regression] Supposedly wrong SLP code emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69980 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-26 CC||jakub at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r224281.
[Bug c/69981] New: -f[no]keep-static-consts has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69981 Bug ID: 69981 Summary: -f[no]keep-static-consts has no effect Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: equinox-gccbugs at diac24 dot net Target Milestone: --- This bug is an extension of #20319; the -fkeep-static-consts option seems to have no effect in either direction. (#20319 was focused on the "-fkeep" variant; my issue is with -O0 -fno-keep-static-consts.) My application code is extern struct foo ref; static struct foo * const myconst = &ref; Where ref is defined in a library that is not always linked in, which works on -O1 -Og -Os -O2 -O3 but not on "-O0 -fno-keep-static-consts". I think it should. Trying older versions, gcc-4.2.4 already behaves the same. $ ./test.sh gcc-4.9.3 -O0 l O .rodata0004 intval l O .data.rel.ro 0008 ptrval gcc-4.9.3 -O0 -fkeep-static-consts l O .rodata0004 intval l O .data.rel.ro 0008 ptrval gcc-4.9.3 -O0 -fno-keep-static-consts l O .rodata0004 intval l O .data.rel.ro 0008 ptrval gcc-4.9.3 -O1 gcc-4.9.3 -O1 -fkeep-static-consts gcc-4.9.3 -O1 -fno-keep-static-consts gcc-5.3.0 -O0 l O .rodata0004 intval l O .data.rel.ro 0008 ptrval gcc-5.3.0 -O0 -fkeep-static-consts l O .rodata0004 intval l O .data.rel.ro 0008 ptrval gcc-5.3.0 -O0 -fno-keep-static-consts l O .rodata0004 intval l O .data.rel.ro 0008 ptrval gcc-5.3.0 -O1 gcc-5.3.0 -O1 -fkeep-static-consts gcc-5.3.0 -O1 -fno-keep-static-consts $ cat test.sh #!/bin/sh cat >const.c <
[Bug c/69981] -f[no]keep-static-consts has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69981 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I disagree, removing static consts is an optimization, if you tell the compiler not to optimize, it doesn't perform the optimizations.
[Bug c/69981] -f[no]keep-static-consts has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69981 --- Comment #2 from David L. --- (In reply to Jakub Jelinek from comment #1) > I disagree, removing static consts is an optimization, if you tell the > compiler not to optimize, it doesn't perform the optimizations. Documentation bug then? It says it's independent of optimization. -fkeep-static-consts Emit variables declared static const when optimization isn't turned on, even if the variables aren't referenced. GCC enables this option by default. If you want to force the compiler to check if a variable is referenced, regardless of whether or not optimization is turned on, use the -fno-keep-static-consts option.
[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69920 David Edelsohn changed: What|Removed |Added Target|i?86-*-*|i?86-*-* powerpc*-*-* ||arm*-*-* CC||dje at gcc dot gnu.org, ||seurer at linux dot vnet.ibm.com, ||wschmidt at gcc dot gnu.org --- Comment #7 from David Edelsohn --- This also is failing for powerpc for -m32 multilib, AIX, and I also see on AIX. g++.dg/torture/pr42704.C: In member function 'void nsTreeRows::InvalidateCachedRow()': g++.dg/torture/pr42704.C:44:1: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in get_ref_base_and_extent, at tree-dfa.c:394
[Bug fortran/67451] [5/6 Regression] [F08] ICE with sourced allocation from coarray.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67451 --- Comment #15 from Dominik Vogt --- The problem is gone on today's trunk for s390 and s390x.
[Bug tree-optimization/69980] [6 regression] Supposedly wrong SLP code emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69980 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine.
[Bug c++/69889] [6 Regression] ICE: in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69889 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug c/69974] [6 Regression] gcc ICE on invalid code on x86_64-linux-gnu in "create_tmp_from_val"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69974 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jakub Jelinek --- Same reason for ICE as PR69796. *** This bug has been marked as a duplicate of bug 69796 ***
[Bug c/69796] [6 Regression] ICE on invalid code in useless_type_conversion_p, at gimple-expr.c:83
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69796 Jakub Jelinek changed: What|Removed |Added CC||helloqirun at gmail dot com --- Comment #6 from Jakub Jelinek --- *** Bug 69974 has been marked as a duplicate of this bug. ***
[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69920 Dominik Vogt changed: What|Removed |Added CC||vogt at linux dot vnet.ibm.com --- Comment #8 from Dominik Vogt --- Also failing on s390 and s390x; the same bug possibly causes several other test failures: FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error) FAIL: gcc.dg/tree-ssa/pr69666.c (internal compiler error) Maybe these too: FAIL: gfortran.dg/reassoc_6.f -O scan-tree-dump-not optimized "~" FAIL: gcc.dg/graphite/scop-sor.c scan-tree-dump-times graphite "number of SCoPs\ : 1" 1
[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69920 --- Comment #9 from Dominik Vogt --- (Fails only with -m31.)
[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69920 --- Comment #10 from Martin Jambor --- I am currently bootstrapping and testing the fix I posted as: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01656.html I am confident it will fix all of these problems (provided the issue is a SSA_NAME still in the IL).
[Bug c/69981] -f[no]keep-static-consts has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69981 --- Comment #4 from David L. --- Argh, for some reason this submitted in the middle of editing... Poking around a bit, in wrapup_global_declaration_2() in gcc/toplev.c, the check for else if (TREE_READONLY (decl) && !TREE_PUBLIC (decl) && (optimize || !flag_keep_static_consts || DECL_ARTIFICIAL (decl))) is never hit because the earlier else if (node && node->definition) needed = false; is taken (on both -O0 or -O1). Thus, the value of flag_keep_static_consts is irrelevant (and this is the only place in the code where it's used...)
[Bug c/69982] New: missing warning when using __thread with -std=c99 -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69982
Bug ID: 69982
Summary: missing warning when using __thread with -std=c99
-pedantic
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
When I compile the following program with -std=c99 -pedantic, I get a warning
for _Thread_local but not for __thread while both are invalid in C99. This is
not consistent!
__thread int x;
_Thread_local int y;
int main(void)
{
return 0;
}
I get:
$ gcc-snapshot -std=c99 -pedantic tst.c -o tst
tst.c:2:1: warning: ISO C99 does not support '_Thread_local' [-Wpedantic]
_Thread_local int y;
^
This occurs with:
gcc (Debian 20160125-1) 6.0.0 20160125 (experimental) [trunk revision 232803]
and previous versions such as 4.9.3 and 5.3.1.
[Bug c/69981] -f[no]keep-static-consts has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69981 --- Comment #3 from David L. --- Poking around a bit, in wrapup_global_declaration_2() in gcc/toplev.c, the check for else if (TREE_READONLY (decl) && !TREE_PUBLIC (decl) && (optimize || !flag_keep_static_consts » » || DECL_ARTIFICIAL (decl)))
[Bug target/69969] [5/6 Regression] Function attribute no-vsx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69969 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 37807 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37807&action=edit gcc6-pr69969.patch Untested fix.
[Bug c/69982] missing warning when using __thread with -std=c99 -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69982 --- Comment #1 from Vincent Lefèvre --- Note: This actually means that a program that switches from __thread to _Thread_local (which could be regarded as more portable) could suddenly fail to build with "-std=c99 -pedantic -Werror".
[Bug lto/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
Markus Trippelsdorf changed:
What|Removed |Added
Known to work||4.9.2
Summary|Using lto causes|[5/6 Regression] Using lto
|gtkmm/gparted and |causes gtkmm/gparted and
|gtkmm/inkscape compile to |gtkmm/inkscape compile to
|fail|fail
Known to fail||5.1.0, 6.0
--- Comment #11 from Markus Trippelsdorf ---
Here's another testcase that only produces a local symbol for all -O levels
with -flto:
namespace Glib {
class A {};
class Object : virtual A {
protected:
~Object();
};
class B : virtual A {};
}
class C : Glib::Object {};
namespace Gtk {
class D : Glib::B {};
class TreeViewColumn : C, D {
virtual ~TreeViewColumn();
};
TreeViewColumn::~TreeViewColumn() {}
}
[Bug c/69982] missing warning when using __thread with -std=c99 -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69982 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Well, there is a difference, __thread is an extension, while _Thread_local is standard in a later version of the standard, and __thread uses the implementation namespace, so it is similar for the compiler not complaining about __attribute__((__noinline__)) even in -std=c99 -pedantic, or about __extension__ etc.
[Bug c/69981] -f[no]keep-static-consts has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69981 --- Comment #5 from David L. --- (In reply to David L. from comment #4) > Poking around a bit, in wrapup_global_declaration_2() in gcc/toplev.c, the > check for >else if (TREE_READONLY (decl) && !TREE_PUBLIC (decl) >&& (optimize || !flag_keep_static_consts >|| DECL_ARTIFICIAL (decl))) > is never hit because the earlier > else if (node && node->definition) > > needed = false; > is taken (on both -O0 or -O1). > > Thus, the value of flag_keep_static_consts is irrelevant (and this is the > only place in the code where it's used...) If I put a "static const int intvalnoinit;" into my test source, -fno-keep-static-consts does actually have an effect on that. It seems a little counterintuitive to me though that static consts only get removed if they have no initialiser...
[Bug c/69982] missing warning when using __thread with -std=c99 -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69982 --- Comment #3 from Vincent Lefèvre --- (In reply to Jakub Jelinek from comment #2) > [...] and __thread uses the implementation namespace, [...] Is this really the implementation namespace? The C standard says: "All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use." so that there doesn't seem to be a difference between __thread (underscore + underscore) and _Thread_local (underscore + uppercase letter). What if the C committee decided to choose __thread instead of _Thread_local?
[Bug target/61397] [4.9/5/6 regression] FAIL: gcc.target/powerpc/p8vector-ldst.c scan-assembler lxsdx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61397 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Bill Schmidt --- I've applied Mike's test case patch to GCC 5 and GCC 6.
[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Fri Feb 26 15:53:43 2016 New Revision: 233743 URL: https://gcc.gnu.org/viewcvs?rev=233743&root=gcc&view=rev Log: PR rtl-optimization/69891 * dse.c (scan_insn): If we can't figure out memset arguments or they are non-constant, call clear_rhs_from_active_local_stores. * gcc.target/i386/pr69891.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr69891.c Modified: trunk/gcc/ChangeLog trunk/gcc/dse.c trunk/gcc/testsuite/ChangeLog
[Bug target/69613] [6 Regression] wrong code with -O and simple 128bit arithmetics and vectors @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69613 --- Comment #6 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Feb 26 15:59:45 2016 New Revision: 233744 URL: https://gcc.gnu.org/viewcvs?rev=233744&root=gcc&view=rev Log: [AArch64] PR target/69613: Return zero TARGET_SHIFT_TRUNCATION_MASK when SHIFT_COUNT_TRUNCATED is false PR target/69613 * config/aarch64/aarch64.c (aarch64_shift_truncation_mask): Return 0 if !SHIFT_COUNT_TRUNCATED. * gcc.dg/torture/pr69613.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr69613.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981 Jerry DeLisle changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #14 from Jerry DeLisle --- Nothing, closing
[Bug target/69613] [6 Regression] wrong code with -O and simple 128bit arithmetics and vectors @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69613 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from ktkachov at gcc dot gnu.org --- Fixed on trunk.
[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245 --- Comment #16 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Feb 26 16:02:21 2016 New Revision: 233745 URL: https://gcc.gnu.org/viewcvs?rev=233745&root=gcc&view=rev Log: [AArch64] Set TREE_TARGET_GLOBALS in aarch64_set_current_function when new tree is the default node to recalculate optab availability PR target/69245 * config/aarch64/aarch64.c (aarch64_set_current_function): Save/restore target globals when switching to target_option_default_node. * gcc.target/aarch64/pr69245_1.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr69245_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/testsuite/ChangeLog
[Bug c/69981] -f[no]keep-static-consts has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69981 --- Comment #6 from David L. --- Created attachment 37808 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37808&action=edit patch (gcc-5.3.0) patch attached (probably makes the user's PC explode and burns down their house) varpool_node::finalize_decl (tree decl) -node->force_output = true; +node->force_output = !TREE_READONLY (decl) || flag_keep_static_consts;
[Bug rtl-optimization/69942] gcc.dg/ifcvt-5.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69942
--- Comment #1 from Yuri Rumyantsev ---
The cause of issue is that before ce1 phase pde (or pre) transformation has
been done to remove partial redundant moves to variable i and j, i.e.
code
int i = x;
int j = y;
if (x > y)
{
i = a;'
j = i;
}
has been transformed to
int i,j;
if (x > y)
{
i = a;
j = i;
}
else
{
i = x;
i = y;
}
and ifcvt phase does speculative motion else-part before if-part, i.e. to
original code. This transformation is considered as true change and test is
failed. I assume that test must accept also '6 basic blocks,' to get test
passed.
[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891 --- Comment #14 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/69976] Zero the local stack on function exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976 --- Comment #3 from Daniel Gutson --- Those are very good ideas but fell into the land of the backend. The red zone IIUC is a x86_64 only ABI concept. What do you think about adding also a -m counterpart option with the same semantic but for the backend? Our plan is to address separately the middle end part and the backend part (initially for x86_64) and subdivide the latter in clobbered registers and red zone cleaning, so 3 sets of patches.
[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69920 --- Comment #11 from Martin Jambor --- I have proposed a fix on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01824.html
[Bug fortran/69962] ICE on missing parameter attribute, in gfc_set_constant_character_len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69962 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-26 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0).
[Bug fortran/69964] ICE on misspelled end block data, in gfc_ascii_statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69964 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-26 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0).
[Bug go/69966] libgo: Port syscall.SetsockoptUcred from golang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69966 --- Comment #1 from ian at gcc dot gnu.org --- Author: ian Date: Fri Feb 26 17:36:00 2016 New Revision: 233747 URL: https://gcc.gnu.org/viewcvs?rev=233747&root=gcc&view=rev Log: PR go/69966 syscall: Add new Getsockopt functions. Add GetsockoptICMPv6Filter, GetsockoptIPv6MTUInfo, GetsockoptUcred as appropriate. These functions exist in the master library. For GCC PR 69966. Reviewed-on: https://go-review.googlesource.com/19960 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/syscall/socket.go trunk/libgo/go/syscall/socket_bsd.go trunk/libgo/go/syscall/socket_linux.go trunk/libgo/mksysinfo.sh
[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69920 --- Comment #12 from Dominik Vogt --- The Ice in 42704.c is gone on s390[x] with trunk (but not the other FAILs). Is the Ice below related to this bug report or is it something totally different? .../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c: In function 'main':^M .../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c:45:1: internal compiler error: Segmentation fault^M 0x8061ac19 crash_signal^M ../../gcc/toplev.c:335^M 0x80a6305e translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*, vec*)^M ../../gcc/graphite-isl-ast-to-gimple.c:1408^M 0x80a630a9 translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*, vec*)^M ../../gcc/graphite-isl-ast-to-gimple.c:1418^M 0x80a630a9 translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*, vec*)^M ../../gcc/graphite-isl-ast-to-gimple.c:1418^M 0x80a630a9 translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*, vec*)^M ../../gcc/graphite-isl-ast-to-gimple.c:1418^M 0x80a647e3 translate_isl_ast_to_gimple::rename_all_uses(tree_node*, basic_block_def*, basic_block_def*)^M ../../gcc/graphite-isl-ast-to-gimple.c:1569^M 0x80a64989 translate_isl_ast_to_gimple::get_rename_from_scev(tree_node*, gimple**, loop*, basic_block_def*, basic_block_def*, vec)^M ../../gcc/graphite-isl-ast-to-gimple.c:1623^M 0x80a66af9 translate_isl_ast_to_gimple::rename_uses(gimple*, gimple_stmt_iterator*, basic_block_def*, loop*, vec)^M ../../gcc/graphite-isl-ast-to-gimple.c:1730^M 0x80a683c5 translate_isl_ast_to_gimple::graphite_copy_stmts_from_block(basic_block_def*, basic_block_def*, vec\ )^M ../../gcc/graphite-isl-ast-to-gimple.c:2596^M 0x80a68943 translate_isl_ast_to_gimple::copy_bb_and_scalar_dependences(basic_block_def*, edge_def*, vec)^M ../../gcc/graphite-isl-ast-to-gimple.c:2809^M 0x80a68f4d translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*, edge_def*, std::map, std::allocator > >&)^M ../../gcc/graphite-isl-ast-to-gimple.c:935^M 0x80a692ed translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*, isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std\ ::map, std::allocator > >&)^M ../../gcc/graphite-isl-ast-to-gimple.c:685^M 0x80a6956f translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*, isl_ast_node*, edge_def*, std::map, std::allocator > >&)^M ../../gcc/graphite-isl-ast-to-gimple.c:854^M 0x80a69209 translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*, edge_def*, std::map\ , std::allocator > >&)^M ../../gcc/graphite-isl-ast-to-gimple.c:1032^M 0x80a696b1 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*, isl_ast_node*, edge_def*, std::map, std::allocator > >&)^M ../../gcc/graphite-isl-ast-to-gimple.c:964^M 0x80a691c1 translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*, edge_def*, std::map\ , std::allocator > >
[Bug go/69966] libgo: Port syscall.SetsockoptUcred from golang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69966 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Lance Taylor --- Fixed on mainline, thanks.
[Bug hsa/69674] hsa offloading, -m32: "internal compiler error: in hsa_build_append_simple_mov"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69674 --- Comment #2 from Martin Jambor --- Author: jamborm Date: Fri Feb 26 17:45:37 2016 New Revision: 233750 URL: https://gcc.gnu.org/viewcvs?rev=233750&root=gcc&view=rev Log: [hsa/69674] Make testsuite libgomp.c/for-3.c compile with -m32 2016-02-26 Martin Jambor pr hsa/69674 * hsa-gen.c (gen_hsa_phi_from_gimple_phi): Use proper hsa type for pointers. (gen_hsa_addr): Allow integer constants in TMR_INDEX2. Modified: trunk/gcc/ChangeLog trunk/gcc/hsa-gen.c
[Bug hsa/69568] Invalid HSAIL opcode when using builtin vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69568 --- Comment #2 from Martin Jambor --- Author: jamborm Date: Fri Feb 26 17:48:19 2016 New Revision: 233751 URL: https://gcc.gnu.org/viewcvs?rev=233751&root=gcc&view=rev Log: [hsa/69568] Fix ld instruction type for packed data 2016-02-26 Martin Jambor PR hsa/69568 * hsa.h (hsa_type_packed_p): Declare. * hsa.c (hsa_type_packed_p): New function. * hsa-gen.c (mem_type_for_type): Use unsigned type for packed loads. (gen_hsa_insns_for_store): Use hsa_type_packed_p. * hsa-brig.c (emit_basic_insn): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/hsa-brig.c trunk/gcc/hsa-gen.c trunk/gcc/hsa.c trunk/gcc/hsa.h
[Bug hsa/69568] Invalid HSAIL opcode when using builtin vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69568 --- Comment #3 from Martin Jambor --- Fixed on trunk. The hsa branch will pick this up next week as a part of a merge from trunk.
