[Bug tree-optimization/94163] [8/9 Regression] internal compiler error: in set_ptr_info_alignment, at tree-ssanames.c:671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94163 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |8.5 Summary|internal compiler error: in |[8/9 Regression] internal |set_ptr_info_alignment, at |compiler error: in |tree-ssanames.c:671 |set_ptr_info_alignment, at ||tree-ssanames.c:671 Known to work||10.0, 7.3.0, 7.4.0 Known to fail||8.3.0, 8.4.0, 9.2.0 --- Comment #1 from Andrew Pinski --- I wonder if this is a latent bug in GCC 10.
[Bug tree-optimization/94163] [8/9 Regression] ICE in set_ptr_info_alignment with -O2 and __builtin_assume_aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94163 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Priority|P3 |P2 Ever confirmed|0 |1 Last reconfirmed||2020-03-13 --- Comment #2 from Richard Biener --- Likely - mine.
[Bug tree-optimization/94163] [8/9 Regression] ICE in set_ptr_info_alignment with -O2 and __builtin_assume_aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94163
--- Comment #3 from Richard Biener ---
From
/* There's no CCP pass after PRE which would re-compute alignment
information so make sure we re-materialize this here. */
if (gimple_call_builtin_p (call, BUILT_IN_ASSUME_ALIGNED)
&& args.length () - 2 <= 1
&& tree_fits_uhwi_p (args[1])
&& (args.length () != 3 || tree_fits_uhwi_p (args[2])))
{
unsigned HOST_WIDE_INT halign = tree_to_uhwi (args[1]);
unsigned HOST_WIDE_INT hmisalign
= args.length () == 3 ? tree_to_uhwi (args[2]) : 0;
if ((halign & (halign - 1)) == 0
&& (hmisalign & ~(halign - 1)) == 0)
set_ptr_info_alignment (get_ptr_info (forcedname),
halign, hmisalign);
}
where set_ptr_info_alignment ICEs for align == 0. set_ptr_info_alignment
takes unsigned int args but the above computes HWI quantities that get
truncated here.
[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94138 --- Comment #12 from Laurent Stacul --- Ok I think we will not waste time on this one. Actually, the build system allows to force the standard version to build the libfolly.so (in out case gnu++20) but somehow the tests are build with -std=gnu++14. (If I twaek the whole build system to use gnu++20, the tests do no compile because GTest is not C++20-ready). So I think this ticket is invalid since we have to ensure some flags consistency between each compilation units of a project. For information, tt seems there is no problem in this situation if LTO is deactivated. Sorry for inconvenience and thanks for your investigation. Stac
[Bug middle-end/92071] [10 regression] ICE in gen_movsi, at config/arm/arm.md:5378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Summary|[10 regression][ARM] ice in |[10 regression] ICE in |gen_movsi, at |gen_movsi, at |config/arm/arm.md:5378 |config/arm/arm.md:5378 URL||https://gcc.gnu.org/piperma ||il/gcc-cvs/2020-March/27168 ||1.html Resolution|--- |FIXED --- Comment #15 from Eric Botcazou --- Fixed in r10-7151.
[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94138 Martin Liška changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #13 from Martin Liška --- Thank you, let's close it then.
[Bug libstdc++/94164] New: [Regression 10] std::unintialized_fill_n fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94164
Bug ID: 94164
Summary: [Regression 10] std::unintialized_fill_n fails to
compile
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: laurent.stacul at gmail dot com
Target Milestone: ---
Hello,
I have this piece of code:
#include
template
struct ref {
typedef T value_type;
typedef T* pointer;
typedef T& reference;
typedef ptrdiff_t difference_type;
typedef std::random_access_iterator_tag iterator_category;
int d;
explicit ref(int =0): d(-1) {}
operator pointer() {
if (d == -1) {
return 0;
}
else
{
return reinterpret_cast(this + d);
}
}
ref& operator++() {
d += sizeof(value_type);
return *this;
}
};
int main(int, const char *[])
{
ref r;
std::uninitialized_fill_n(r, 10, 'a');
return 0;
}
I compile it with the following command (the -std option is not important):
$ g++ -Wall -Wextra -std=gnu++2a -c -o main.o main.cpp
When I compile it with gcc (GCC) 10.0.1 20200305, if fails with the following
error:
/x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h: In instantiation of
'constexpr _OutputIterator std::__fill_n_a(_OutputIterator, _Size, const _Tp&,
std::random_access_iterator_tag) [with _OutputIterator = ref; _Size =
int; _Tp = char]':
/x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:1085:29: required
from 'constexpr _OI std::fill_n(_OI, _Size, const _Tp&) [with _OI = ref;
_Size = int; _Tp = char]'
/x86_64-v20.0.13/include/c++/10.0.1/bits/stl_uninitialized.h:254:29: required
from 'static _ForwardIterator
std::__uninitialized_fill_n::__uninit_fill_n(_ForwardIterator, _Size,
const _Tp&) [with _ForwardIterator = ref; _Size = int; _Tp = c
har]'
/x86_64-v20.0.13/include/c++/10.0.1/bits/stl_uninitialized.h:289:17: required
from '_ForwardIterator std::uninitialized_fill_n(_ForwardIterator, _Size, const
_Tp&) [with _ForwardIterator = ref; _Size = int; _Tp = char]'
main.cpp:32:41: required from here
/x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:1056:20: error: no
matching function for call to '__fill_a(ref&, ref::pointer, const
char&)'
1056 | std::__fill_a(__first, __first + __n, __value);
| ~^
/x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:904:5: note: candidate:
'template constexpr void std::__fill_a(_FIte, _FIte,
const _Tp&)'
904 | __fill_a(_FIte __first, _FIte __last, const _Tp& __value)
| ^~~~
/x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:904:5: note: template
argument deduction/substitution failed:
/x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:1056:20: note:
deduced conflicting types for parameter '_FIte' ('ref' and 'char*')
1056 | std::__fill_a(__first, __first + __n, __value);
| ~^
/x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:909:5: note: candidate:
'template void
std::__fill_a(const __gnu_debug::_Safe_iterator<_Ite, _Seq, _Cat>&, const
__gnu_debug::_Safe_iterator<_Ite, _Seq
, _Cat>&, const _Tp&)'
909 | __fill_a(const ::__gnu_debug::_Safe_iterator<_Ite, _Seq, _Cat>&,
| ^~~~
/x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:909:5: note: template
argument deduction/substitution failed:
/x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:1056:20: note:
'ref' is not derived from 'const __gnu_debug::_Safe_iterator<_Ite, _Seq,
_Cat>'
1056 | std::__fill_a(__first, __first + __n, __value);
| ~^
/x86_64-v20.0.13/include/c++/10.0.1/bits/stl_algobase.h:1057:22: error: could
not convert '(__first.ref::operator ref::pointer() +
((sizetype)__n))' from 'ref::pointer' {aka 'char*'} to 'ref'
1057 | return __first + __n;
| ^
| |
| ref::pointer {aka char*}
make: *** [Makefile:6: main.o] Error 1
Conversely, this code compiles with gcc (GCC) 9.2.1.
Maybe is it related to
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6004c17b4d1a2dd1e1936b2e705a5ccfb6e48ab2
but I don' t know if the current bahviour is expected.
Stac
[Bug tree-optimization/94163] [8/9 Regression] ICE in set_ptr_info_alignment with -O2 and __builtin_assume_aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94163 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- So, either we can set the alignment to (unsigned) INT_MAX + 1 in that case, or throw the info away. Doesn't seem to be useful to enlarge ptr_info_def because of this. Perhaps the set_ptr_info_alignment could take unsigned HOST_WIDE_INT argument and do this saturation inside of it.
[Bug tree-optimization/94163] [8/9 Regression] ICE in set_ptr_info_alignment with -O2 and __builtin_assume_aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94163
--- Comment #5 from Jakub Jelinek ---
E.g. in tree-ssa-ccp.c, we drop very large alignments on the floor.
/* Trailing mask bits specify the alignment, trailing value
bits the misalignment. */
tem = val->mask.to_uhwi ();
align = least_bit_hwi (tem);
int *
foo (int *p)
{
p = (int *) ((__UINTPTR_TYPE__) p & 0xfff0ULL);
(*p)++;
return p;
}
because tem is unsigned int and so will be 0, align 0 too and so align > 1 will
not be true.
[Bug target/87560] ICE in curr_insn_transform, at lra-constraints.c:3892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87560 --- Comment #12 from Martin Liška --- commit r9-8370-gde8e3b71c8bec6dde60e6ee70c73d6895c67d782 Author: Bill Schmidt Date: Thu Mar 12 15:28:50 2020 -0500 rs6000: Fix -mpower9-vector -mno-altivec ICE (PR87560) PR87560 reports an ICE when a test case is compiled with -mpower9-vector and -mno-altivec. This patch terminates compilation with an error when this combination (and other unreasonable ones) are requested. Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions. Reported error is now: f951: Error: '-mno-altivec' turns off '-mpower9-vector' 2020-03-12 Bill Schmidt Backport from master 2020-03-02 Bill Schmidt PR target/87560 * rs6000-cpus.def (OTHER_ALTIVEC_MASKS): New #define. * rs6000.c (rs6000_disable_incompatible_switches): Add table entry for OPTION_MASK_ALTIVEC.
[Bug rtl-optimization/94119] [8/9/10 regression] invalid filling of branch delay slots leads to corrupt jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #7 from Martin Liška --- commit r9-8372-g593e47a6134085e9b856c62f98f72acd4446ba7c Author: Eric Botcazou Date: Fri Mar 13 09:58:44 2020 +0100 Fix incorrect filling of delay slots in branchy code at -O2 The issue is that relax_delay_slots can streamline the CFG in some cases, in particular remove BARRIERs, but removing BARRIERs changes the way the instructions are associated with (basic) blocks by the liveness analysis code in resource.c (find_basic_block) and thus can cause entries in the cache maintained by resource.c to become outdated, thus producing wrong answers downstream. The fix is to invalidate the cache entries affected by the removal of BARRIERs in relax_delay_slots, i.e. for the instructions down to the next BARRIER. PR rtl-optimization/94119 * resource.h (clear_hashed_info_until_next_barrier): Declare. * resource.c (clear_hashed_info_until_next_barrier): New function. * reorg.c (add_to_delay_list): Fix formatting. (relax_delay_slots): Call clear_hashed_info_until_next_barrier on the next instruction after removing a BARRIER.
[Bug rtl-optimization/94119] [8/9/10 regression] invalid filling of branch delay slots leads to corrupt jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119 --- Comment #8 from Martin Liška --- commit r10-7152-g3e6ab5cefa81165e90fb62abf50e515f85a17e9a Author: Eric Botcazou Date: Fri Mar 13 09:58:44 2020 +0100 Fix incorrect filling of delay slots in branchy code at -O2 The issue is that relax_delay_slots can streamline the CFG in some cases, in particular remove BARRIERs, but removing BARRIERs changes the way the instructions are associated with (basic) blocks by the liveness analysis code in resource.c (find_basic_block) and thus can cause entries in the cache maintained by resource.c to become outdated, thus producing wrong answers downstream. The fix is to invalidate the cache entries affected by the removal of BARRIERs in relax_delay_slots, i.e. for the instructions down to the next BARRIER. PR rtl-optimization/94119 * resource.h (clear_hashed_info_until_next_barrier): Declare. * resource.c (clear_hashed_info_until_next_barrier): New function. * reorg.c (add_to_delay_list): Fix formatting. (relax_delay_slots): Call clear_hashed_info_until_next_barrier on the next instruction after removing a BARRIER.
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #40 from Martin Liška --- commit r10-7151-g82f620e2ba4c440c5e89bb1f73d10a11ed0f2eb4 Author: Eric Botcazou Date: Fri Mar 13 09:16:29 2020 +0100 Fix unaligned load with small memcpy on the ARM store_integral_bit_field is ready to handle BLKmode fields, there is even a subtlety with their handling on big-endian targets, see e.g. PR middle-end/50325, but not if they are unaligned, so the fix is simply to call extract_bit_field for them in order to generate an unaligned load. As a bonus, this subsumes the big-endian specific path that was added under PR middle-end/50325. PR middle-end/92071 * expmed.c (store_integral_bit_field): For fields larger than a word, call extract_bit_field on the value if the mode is BLKmode. Remove specific path for big-endian targets and tidy things up a little bit.
[Bug middle-end/92071] [10 regression] ICE in gen_movsi, at config/arm/arm.md:5378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #16 from Martin Liška --- commit r10-7151-g82f620e2ba4c440c5e89bb1f73d10a11ed0f2eb4 Author: Eric Botcazou Date: Fri Mar 13 09:16:29 2020 +0100 Fix unaligned load with small memcpy on the ARM store_integral_bit_field is ready to handle BLKmode fields, there is even a subtlety with their handling on big-endian targets, see e.g. PR middle-end/50325, but not if they are unaligned, so the fix is simply to call extract_bit_field for them in order to generate an unaligned load. As a bonus, this subsumes the big-endian specific path that was added under PR middle-end/50325. PR middle-end/92071 * expmed.c (store_integral_bit_field): For fields larger than a word, call extract_bit_field on the value if the mode is BLKmode. Remove specific path for big-endian targets and tidy things up a little bit.
[Bug rtl-optimization/90275] [8/9 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #13 from Martin Liška --- commit r10-7149-g4aded535ea6ad7c362ab62d99af70e53c186d582 Author: Richard Sandiford Date: Thu Mar 12 16:09:27 2020 -0600 Remove no-op register to register copies in CSE just like we remove no-op memory to memory copies. PR rtl-optimization/90275 * cse.c (cse_insn): Delete no-op register moves too. PR rtl-optimization/90275 * gcc.c-torture/compile/pr90275.c: New test.
[Bug rtl-optimization/94119] [8/9/10 regression] invalid filling of branch delay slots leads to corrupt jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119 --- Comment #9 from Martin Liška --- commit r8-10121-g92902501c2ad030d56fd3347defd00e79187c51f Author: Eric Botcazou Date: Fri Mar 13 09:58:44 2020 +0100 Fix incorrect filling of delay slots in branchy code at -O2 The issue is that relax_delay_slots can streamline the CFG in some cases, in particular remove BARRIERs, but removing BARRIERs changes the way the instructions are associated with (basic) blocks by the liveness analysis code in resource.c (find_basic_block) and thus can cause entries in the cache maintained by resource.c to become outdated, thus producing wrong answers downstream. The fix is to invalidate the cache entries affected by the removal of BARRIERs in relax_delay_slots, i.e. for the instructions down to the next BARRIER. PR rtl-optimization/94119 * resource.h (clear_hashed_info_until_next_barrier): Declare. * resource.c (clear_hashed_info_until_next_barrier): New function. * reorg.c (add_to_delay_list): Fix formatting. (relax_delay_slots): Call clear_hashed_info_until_next_barrier on the next instruction after removing a BARRIER.
[Bug tree-optimization/94163] [8/9 Regression] ICE in set_ptr_info_alignment with -O2 and __builtin_assume_aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94163 --- Comment #6 from Richard Biener --- The patch in testing does the same as CCP. I agree that we possibly want saturation behavior but that can be done separately for GCC 11.
[Bug rtl-optimization/94119] [8/9/10 regression] invalid filling of branch delay slots leads to corrupt jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Eric Botcazou --- Fixed on all active branches.
[Bug libstdc++/94164] [10 Regression] std::unintialized_fill_n fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94164 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0 Summary|[Regression 10] |[10 Regression] |std::unintialized_fill_n|std::unintialized_fill_n |fails to compile|fails to compile
[Bug target/94154] AArch64: Add parameters to tune the precision of reciprocal div
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94154 Bu Le changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Bu Le --- The patch has been reviewed and merged to master by Richard. Fixed and close.
[Bug c++/94162] ICE [neg] bad return type in defaulted <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94162
--- Comment #1 from Jakub Jelinek ---
It isn't clear to me what exactly disallows it, perhaps
http://eel.is/c++draft/class.spaceship#2.2
?
For auto return type
http://eel.is/c++draft/class.spaceship#4
defines what return type it should have.
If the explicit return type isn't auto, but is one of the
std::{strong,weak,partial}_ordering, we don't ICE and accept it, should we and
what behavior should it have?
#include
struct S {
float a;
std::strong_ordering operator<=>(const S&) const = default;
};
bool b = S{} < S{};
struct T {
std::partial_ordering operator<=>(const T&) const = default;
};
bool c = T{} < T{};
For S, the auto return type would be std::partial_ordering and in the generated
body we just assume the floats will not be unordered.
So, for bool, shall it be accepted and handled some way, or shall it be
deleted, or result in immediate error (ill-formed)?
What about even weirder types (say float or int * or some arbitrary class)?
[Bug libstdc++/94164] [10 Regression] std::unintialized_fill_n fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94164 --- Comment #1 from Jonathan Wakely --- That's not an iterator.
[Bug target/89229] Incorrect xmm16-xmm31/ymm16-ymm31 in vector move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89229 --- Comment #31 from Martin Liška --- commit r10-7154-gfd8679974b2ded884ffd7d912efef7fe13e4ff4f Author: H.J. Lu Date: Fri Mar 13 02:48:59 2020 -0700 i386: Use ix86_output_ssemov for DFmode TYPE_SSEMOV There is no need to set mode attribute to XImode nor V8DFmode since ix86_output_ssemov can properly encode xmm16-xmm31 registers with and without AVX512VL. gcc/ PR target/89229 * config/i386/i386.c (ix86_output_ssemov): Handle MODE_DF. * config/i386/i386.md (*movdf_internal): Call ix86_output_ssemov for TYPE_SSEMOV. Remove TARGET_AVX512F, TARGET_PREFER_AVX256, TARGET_AVX512VL and ext_sse_reg_operand check. gcc/testsuite/ PR target/89229 * gcc.target/i386/pr89229-4a.c: New test. * gcc.target/i386/pr89229-4b.c: Likewise. * gcc.target/i386/pr89229-4c.c: Likewise.
[Bug target/94154] AArch64: Add parameters to tune the precision of reciprocal div
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94154 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- commit r10-7153-gdbf3dc75888623e9d4bb7cc5e9c30caa9b24ffe7 Author: Bu Le Date: Thu Mar 12 22:39:12 2020 + aarch64: Add --params to control the number of recip steps [PR94154] -mlow-precision-div hard-coded the number of iterations to 2 for double and 1 for float. This patch adds a --param to control the number. 2020-03-13 Bu Le gcc/ PR target/94154 * config/aarch64/aarch64.opt (-param=aarch64-float-recp-precision=) (-param=aarch64-double-recp-precision=): New options. * doc/invoke.texi: Document them. * config/aarch64/aarch64.c (aarch64_emit_approx_div): Use them instead of hard-coding the choice of 1 for float and 2 for double.
[Bug libstdc++/94164] [10 Regression] std::unintialized_fill_n fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94164 --- Comment #2 from Laurent Stacul --- (In reply to Jonathan Wakely from comment #1) > That's not an iterator. Yes sure. I reduced my example to have the minimal example. I will add all de needed requirement of an iterator if needed.
[Bug rtl-optimization/92303] [10 regression] gcc.target/sparc/ultrasp12.c times out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303 Eric Botcazou changed: What|Removed |Added Component|target |rtl-optimization --- Comment #12 from Eric Botcazou --- Recategorizing.
[Bug other/94165] New: Wrong "warning: this statement may fall through" after __builtin_unreachable().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94165
Bug ID: 94165
Summary: Wrong "warning: this statement may fall through" after
__builtin_unreachable().
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Created attachment 48026
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48026&action=edit
C/C++ test case.
The compiler gcc, g++ incorrectly complain about fall-through case after
__builtin_unreachable().
Compiler test case with
$ g++ -c -W -Wall
w.c: In function ‘int func(int, int)’:
w.c:7:15: warning: this statement may fall through [-Wimplicit-fallthrough=]
(__extension__({\
~
int _r = error_at (msg);\
~
__builtin_unreachable();\
~
_r; \
~~^~~
}))
~~~
w.c:15:9: note: in expansion of macro ‘error’
error ("bug");
^
w.c:16:5: note: here
case 1: case 2:
^~~~
The only route to the fall-through is via __builtin_unreachable(), thus this
warning is wrong.
[Bug target/94121] ICE on aarch64-linux-gnu: in abs_hwi, at hwint.h:324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94121 --- Comment #7 from Martin Liška --- commit r10-7155-g7aa605c9d4643dc6e0a0460e5697c02457cd7278 Author: Jakub Jelinek Date: Fri Mar 13 11:33:16 2020 +0100 aarch64: Fix another bug in aarch64_add_offset_1 [PR94121] > I'm getting this ICE with -mabi=ilp32: > > during RTL pass: fwprop1 > /opt/gcc/gcc-20200312/gcc/testsuite/gcc.dg/pr94121.c: In function 'bar': > /opt/gcc/gcc-20200312/gcc/testsuite/gcc.dg/pr94121.c:16:1: internal compiler error: in decompose, at rtl.h:2279 That is a preexisting issue, caused by another bug in the same function. When mode is SImode and moffset is 0x8000 (or anything else with the bit 31 set), we need to sign-extend it. 2020-03-13 Jakub Jelinek PR target/94121 * config/aarch64/aarch64.c (aarch64_add_offset_1): Use gen_int_mode instead of GEN_INT.
[Bug middle-end/93566] [8/9/10 Regression] tree-nested.c ICE on C OpenMP array section reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93566 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 48027 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48027&action=edit gcc10-pr93566.patch Untested fix.
[Bug other/94165] Wrong "warning: this statement may fall through" after __builtin_unreachable().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94165
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
This warning is an early warning (during gimplification) and can handle only
some constructs that clearly can't fall thru.
E.g. we do warn for:
extern void foo (const char *) __attribute__((noreturn));
int
bar (int x)
{
switch (x)
{
default:
foo ("bug");
x++;
case 1:
return x + 2;
}
}
but if you take the unreachable code after the noreturn call, we won't warn.
The expression statement is similar, there is code after the noreturn call.
Finding noreturn stuff in the middle of sequences would be difficult and
expensive. Only the cfg pass is then able to figure out that some code is
unreachable.
[Bug tree-optimization/94166] New: [10 Regression] random -fcompare-debug failures since r10-1913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94166
Bug ID: 94166
Summary: [10 Regression] random -fcompare-debug failures since
r10-1913
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhroma at gcc dot gnu.org
CC: jakub at redhat dot com, linkw at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-*-linux-gnu
I've regtested recent r10-7146 version on powerpc64le with -fcompare-debug.
pr88497-*.c and pr92618.c tests give some kind of random results - they may
fail or pass.
So, after running one compilation manually several times like this:
gcc -O2 -fcompare-debug gcc/testsuite/gcc.c-torture/execute/pr92618.c
--save-temps
I finally managed to see final-dumps with difference like "a=b+c" vs "a=c+b".
Than I've added -fdump-tree-all and than found that the difference starts from
'reassoc1' dump. Investigation shows r10-1913 causes that. I've checked that
reverting r10-1913 and related r10-4930 (but without removing their tests,
which were actually under investigation) solved the problem.
I think the problem is using
for(hash_map::iterator it = v_info_map.begin ) {
...
valid_vecs.quick_push (cand_vec);
}
That loop gives unpredictable order in hash_map iterator and we got random
order of elements in valid_vecs. Later we sort it, but in pr92618.c example it
seems there are two elements are their comparison result is 'equal'.
PS. Actually, I've checked the difference between usual regtest results and
-fcompare-debug and there are a lot of other "more stable" failures, I'll also
file another PR.
[Bug lto/94157] [10 Regression] error: lto-wrapper failed with -Wa,--noexecstack -Wa,--noexecstack since r10-6807-gf1a681a174cdfb82
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94157 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Liška --- commit r10-7157-g98ff89d1ac5872f29020fe5b5edfdf5abce59014 Author: Martin Liska Date: Fri Mar 13 13:50:01 2020 +0100 Do not strcat to result of getenv. PR lto/94157 * lto-wrapper.c (run_gcc): Use concat for appending to collect_gcc_options. PR lto/94157 * gcc.dg/lto/pr94157_0.c: New test.
[Bug testsuite/93935] [9/10 regression] gcc.dg/vect/bb-slp-over-widen-2.c fails starting with r262371 (r10-6856)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93935 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- commit r10-7156-g43d513af3f2026420312cc709dd729c81862de0c Author: Kewen Lin Date: Fri Mar 13 05:51:21 2020 -0500 [testsuite] Fix PR93935 to guard case under vect_hw_misalign This patch is to apply the same fix as r267528 to another similar case bb-slp-over-widen-2.c which requires misaligned vector access. gcc/testsuite/ChangeLog PR testsuite/93935 * gcc.dg/vect/bb-slp-over-widen-2.c: Expect basic block vectorized messages only on vect_hw_misalign targets.
[Bug tree-optimization/94166] [10 Regression] random -fcompare-debug failures since r10-1913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94166 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Priority|P3 |P1 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-03-13 Target Milestone|--- |10.0 --- Comment #1 from Jakub Jelinek --- Indeed: --- pr92618.c.123t.reassoc1_2020-03-13 13:58:06.494566731 +0100 +++ pr92618.c.123t.reassoc1 2020-03-13 13:58:33.151172526 +0100 @@ -88,8 +88,8 @@ foo (long long unsigned int * x) [local count: 1073741824]: c_6 = bar (); d_8 = bar (); - _19 = VIEW_CONVERT_EXPR(c_6); - _18 = VIEW_CONVERT_EXPR(d_8); + _19 = VIEW_CONVERT_EXPR(d_8); + _18 = VIEW_CONVERT_EXPR(c_6); _17 = _18 + _19; _21 = BIT_FIELD_REF <_17, 64, 0>; _20 = BIT_FIELD_REF <_17, 64, 64>;
[Bug tree-optimization/94163] [8/9 Regression] ICE in set_ptr_info_alignment with -O2 and __builtin_assume_aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94163 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Richard Biener --- Fixed everywhere.
[Bug tree-optimization/94166] [10 Regression] random -fcompare-debug failures since r10-1913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94166 --- Comment #2 from Jakub Jelinek --- This fixes it, but will try to find a testcase that fails more reliably: --- gcc/tree-ssa-reassoc.c.jj 2020-01-12 11:54:38.510381771 +0100 +++ gcc/tree-ssa-reassoc.c 2020-03-13 14:06:32.358085863 +0100 @@ -1793,8 +1793,11 @@ sort_by_mach_mode (const void *p_i, cons return 1; else if (mode1 < mode2) return -1; - else -return 0; + if (SSA_NAME_VERSION (tr1) < SSA_NAME_VERSION (tr2)) +return -1; + else if (SSA_NAME_VERSION (tr1) > SSA_NAME_VERSION (tr2)) +return 1; + return 0; } /* Cleanup hash map for VECTOR information. */
[Bug tree-optimization/94167] New: pr71109.c -fcompare-debug failures on x86_64 and powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94167 Bug ID: 94167 Summary: pr71109.c -fcompare-debug failures on x86_64 and powerpc64le Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zhroma at gcc dot gnu.org Target Milestone: --- Running gcc -O2 -fcompare-debug gcc/testsuite/gcc.c-torture/compile/pr71109.c fails with recent master on powerpc64le. I also checked that same happens on x86 with recent 9.3.0 and old 5.5.0 ubuntu. On master, first dump file with difference is fixup_cfg3 -- I've compared (on powerpc64le) usual regtest results and '-fcompare-debug' results and there are like ~10 more failures, two of them already reported as PR94166. Certainly, there are actually a lot of cases when -fcompare-debug dumps differs, but .o files have same code, so that can only be catched "manually" (e.g. using RUNTESTFLAGS="--target_board=unix/-fcompare-debug" or bootstrapping --with-build-config=bootstrap-debug-lean). And I'm not sure how much community bothers about fixing issues like this one.
[Bug c++/94044] [10 Regression] internal compiler error: in comptypes, at cp/typeck.c:1490 on riscv64-unknown-linux-gnu and arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044 --- Comment #4 from Nathan Sidwell --- I cannot reproduce this with the cross or native compilers I've tried: native: x86_64-linux, aarch64-linux cross: arm-eabi riscv64-unknown-linux The cross compilers are hosted on x86_64-linux
[Bug driver/87161] if -Werror appear after -Wmissing-prototypes the warning is not turn into error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87161 Simon Marchi changed: What|Removed |Added CC||simon.marchi at polymtl dot ca --- Comment #6 from Simon Marchi --- I also encountered this inconsistency when running g++ under ccache. I can't tell if this is a ccache or a gcc problem. Running the exact same command with and without ccache gives two different results: $ ccache g++ -c -Werror -Wmissing-prototypes test.cpp cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ $ g++ -c -Werror -Wmissing-prototypes test.cpp cc1plus: error: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ [-Werror]
[Bug preprocessor/94168] New: [10 Regression] error: extended character § is not valid in an identifier since r10-3309-g7d112d6670a0e0e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94168 Bug ID: 94168 Summary: [10 Regression] error: extended character § is not valid in an identifier since r10-3309-g7d112d6670a0e0e6 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- I see the following regression: $ cat red.cc #ifdef WINDOWS § #endif $ g++-9 red.cc -c $ g++ red.cc -c red.cc:2:1: error: extended character § is not valid in an identifier 2 | �� | ^
[Bug tree-optimization/94166] [10 Regression] random -fcompare-debug failures since r10-1913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94166 --- Comment #3 from Jakub Jelinek --- Created attachment 48028 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48028&action=edit gcc10-pr94166.patch Untested fix.
[Bug preprocessor/94168] [10 Regression] error: extended character § is not valid in an identifier since r10-3309-g7d112d6670a0e0e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94168 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-03-13 Target Milestone|--- |10.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to fail||10.0 Known to work||9.3.0 CC||lhyatt at gmail dot com --- Comment #1 from Martin Liška --- It's reduced from hfst-ospell package.
[Bug rtl-optimization/90378] [9/10 regression] -Os -flto miscompiles 454.calculix after r266385 on Arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90378 --- Comment #10 from Christophe Lyon --- I checked the stack settings on the ARMv7 and ARMv8 machines: ARMv7: beced000-bed0e000 rw-p 00:00 0 [stack] ARMv8: fff12000-fff33000 rw-p 00:00 0 [stack] In both cases ulimit -a says: stack size (kbytes, -s) 8192 I recompiled with "-Os -flto -g -mthumb" (ie. I added -g) and execution sometimes reaches iteration 2, sometimes not. Using gdb I got a bit more info: Program received signal SIGSEGV, Segmentation fault. _int_free (av=0xc59a20, p=, have_lock=12975032) at malloc.c:4088 4088malloc.c: No such file or directory. But this is random too, another run gave: Program received signal SIGSEGV, Segmentation fault. __brk (addr=0x1) at ../sysdeps/unix/sysv/linux/arm/brk.c:31 31 ../sysdeps/unix/sysv/linux/arm/brk.c: No such file or directory. Other runs from the same gdb gave no backtrace at all, and at least one of them reached iteration 4.
[Bug tree-optimization/94163] [8/9 Regression] ICE in set_ptr_info_alignment with -O2 and __builtin_assume_aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94163 --- Comment #9 from Martin Liška --- commit r9-8373-gdb3584552871c8caccdc22e97ea1573da9458253 Author: Richard Biener Date: Fri Mar 13 13:56:26 2020 +0100 tree-optimization/94163 constrain alignment set by PRE This avoids HWI -> unsigned truncation to end up with zero alignment which set_ptr_info_alignment ICEs on. 2020-03-13 Richard Biener PR tree-optimization/94163 * tree-ssa-pre.c (create_expression_by_pieces): Check whether alignment would be zero.
[Bug tree-optimization/94163] [8/9 Regression] ICE in set_ptr_info_alignment with -O2 and __builtin_assume_aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94163 --- Comment #10 from Martin Liška --- commit r10-7158-g3604480a6fe493c51d6ebd53d9b1abee828f Author: Richard Biener Date: Fri Mar 13 13:56:26 2020 +0100 tree-optimization/94163 constrain alignment set by PRE This avoids HWI -> unsigned truncation to end up with zero alignment which set_ptr_info_alignment ICEs on. 2020-03-13 Richard Biener PR tree-optimization/94163 * tree-ssa-pre.c (create_expression_by_pieces): Check whether alignment would be zero.
[Bug tree-optimization/94163] [8/9 Regression] ICE in set_ptr_info_alignment with -O2 and __builtin_assume_aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94163 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #8 from Martin Liška --- commit r8-10122-g8c55e44368d639849b28484f2c7842f4265b33c8 Author: Richard Biener Date: Fri Mar 13 13:56:26 2020 +0100 tree-optimization/94163 constrain alignment set by PRE This avoids HWI -> unsigned truncation to end up with zero alignment which set_ptr_info_alignment ICEs on. 2020-03-13 Richard Biener PR tree-optimization/94163 * tree-ssa-pre.c (create_expression_by_pieces): Check whether alignment would be zero.
[Bug debug/94167] [8/9/10 Regression] pr71109.c -fcompare-debug failures on x86_64 and powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94167 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-13 Target Milestone|--- |8.5 Ever confirmed|0 |1 Component|tree-optimization |debug Summary|pr71109.c -fcompare-debug |[8/9/10 Regression] |failures on x86_64 and |pr71109.c -fcompare-debug |powerpc64le |failures on x86_64 and ||powerpc64le CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r0-111525-gd7da5cc85cdef4207d10e8b79dce79ed12353fb9 Will try to have a quick look.
[Bug c/84919] [8/9 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919 --- Comment #23 from Martin Sebor --- I think that's a question for the release managers. I thought they like to keep regressions open until all the affected branches have closed, but I could be wrong. One way to find out is to close it and let them reopen it :)
[Bug debug/94167] [8/9/10 Regression] pr71109.c -fcompare-debug failures on x86_64 and powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94167 --- Comment #2 from Jakub Jelinek --- The first changes seems to appear in the inline ipa dump: -bar/5 (bar) @0x7face3ee7000 +bar/5 (bar) @0x7f637349f438 Type: function definition analyzed Visibility: externally_visible public + Address is taken. References: - Referring: + Referring: foo.constprop.0/8 (addr) ... -foo.constprop.0/8 (foo.constprop) @0x7face3ee75a0 +foo.constprop.0/8 (foo.constprop) @0x7f63734ab2d0 Type: function definition analyzed Visibility: artificial - References: a/0 (write)c/1 (write)a/0 (read)b/3 (read) + References: bar/5 (addr)a/0 (write)c/1 (write)a/0 (read)b/3 (read) which means something is pushing &bar from # DEBUG D#2 => (int) bar which doesn't appear in any non-debug stmts.
[Bug c++/67960] [8/9 Regression] Prefixing a function with [[deprecated]] produces multiple warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67960 Patrick Palka changed: What|Removed |Added Status|REOPENED|ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Known to fail|10.0| Summary|[8/9/10 Regression] |[8/9 Regression] Prefixing |Prefixing a function with |a function with |[[deprecated]] produces |[[deprecated]] produces |multiple warnings |multiple warnings --- Comment #7 from Patrick Palka --- I have a patch. --- Comment #8 from Patrick Palka --- Fixed on trunk by r10-7159.
[Bug debug/94167] [8/9/10 Regression] pr71109.c -fcompare-debug failures on x86_64 and powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94167 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 48029 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48029&action=edit gcc10-pr94167.patch Untested fix.
[Bug middle-end/94169] New: warn for modifying getenv() result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94169 Bug ID: 94169 Summary: warn for modifying getenv() result Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Bug 94157 was caused by modifying the string pointed to by the value returned from getenv(), which is undefined according to both C and POSIX. C11 says in 7.22.4.8, p4: The getenv function returns a pointer to a string associated with the matched list member. The string pointed to shall not be modified by the program, but may be overwritten by a subsequent call to the getenv function. It would be helpful if GCC issued a warning for attempts to modify the returned string. This could be done by extending -Wstringop-overflow.
您為什麼抗疫失據？
您為什麼抗疫失據？ 您為什麼抗疫失據？ 我們香港護老易有限公司是金利通上市公司的子公司。 你帶口罩保護了直接的飛沫傳染。但是一點都不足夠，你仍然讓病毒存活在你的辦公室和家居環境。其實最有效消滅病毒的手段是消毒酒精，漂白水。 專家表示，細菌在金屬、塑膠等光滑材質的物件上更容易殘留，因此對機不離手的香港人來說，智能手機缺乏定時清潔的話，可能會黏附著大量細菌！因此正確的消毒手機方法尤其重要。 無論在辦公室或者家居，你有沒有把漂白水或酒精放在門口的地氈及把稀釋的漂白水倒在座廁及U形聚水渠？和人握手及與小孩子接觸之後有沒有用酒精擦手？ 病毒在我們周圍，單憑口罩，只是防範了一部份。我相信受感染的病人，絕大多數都有口罩！ 如果你告訴我，你買不到酒精，或者漂白水，收到這個信息是你的福氣。金利通上市公司全資附屬的金十字抗疫產品系列提供以下產品: 1. Alcohol Swab 酒精消毒棉片 2. 84消毒液(漂白水) 3. 酒精消毒濕紙巾 請立即和我們聯絡! 查詢及訂購請致電或WhatsApp: 9309 3281 / 2510 0200 Should you wish not to receive any promotional email in the future, please click UNSUBSCRIBE.如閣下不欲收到本公司的宣傳郵件，請按不訂閱。
[Bug c++/94044] [10 Regression] internal compiler error: in comptypes, at cp/typeck.c:1490 on riscv64-unknown-linux-gnu and arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044 --- Comment #5 from Kito Cheng --- Hi Nathan: Double confirmed again, it still ICE to me, but I might miss some info so I post my env and configure option: GCC: g:b73f69020f08208d2d969fcf8879bd294a6e3596 Host: x86_64-linux (Ubuntu 18.04) Target: arm-eabi Configure option: --target=arm-eabi --enable-languages=c,c++ Bootstrap gcc only $ arm-eabi-g++ ../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/testsuite/g++.dg/cpp0x/variadic-sizeof4.C -std=c++14 reduced cc1plus command: $ /scratch1/kitoc/riscv-gnu-workspace/pr94044/arm-eabi/install/bin/../libexec/gcc/arm-eabi/10.0.1/cc1plus -quiet ../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/testsuite/g++.dg/cpp0x/variadic-sizeof4.C -quiet -mcpu=arm7tdmi -marm -march=armv4t -std=c++14 -o - debug info: #6 0x008abd8b in comptypes (t1=0x76964f18, t2=, strict=) at ../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/typeck.c:1489 1489 gcc_checking_assert (TREE_CODE (t1) != TYPE_ARGUMENT_PACK (gdb) call debug_tree(t1)
[Bug rtl-optimization/94119] [8/9/10 regression] invalid filling of branch delay slots leads to corrupt jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119 --- Comment #11 from d.dorau at avm dot de --- (In reply to Eric Botcazou from comment #10) > Fixed on all active branches. Thanky you very much for the quick fix! To verify I cherry-picked your commit onto our 8.3 build and the result looks fine so far. I noticed that you accidentially put the wrong year into the ChangeLog.
[Bug c/94040] [9 Regression] ICE on a call to an invalid redeclaration of strftime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94040 Martin Sebor changed: What|Removed |Added Known to fail|10.0, 9.2.0 |9.3.0 Summary|[9/10 Regression] ICE on a |[9 Regression] ICE on a |call to an invalid |call to an invalid |redeclaration of strftime |redeclaration of strftime Known to work||10.0 --- Comment #6 from Martin Sebor --- Fixed for GCC 10 via r10-7162: https://gcc.gnu.org/g:f2e9fe5f97d88fc876c44e6ffa57a2e85150adf9 commit r10-7162-gf2e9fe5f97d88fc876c44e6ffa57a2e85150adf9 Author: Martin Sebor Date: Fri Mar 13 10:28:26 2020 -0600 PR c/94040 - ICE on a call to an invalid redeclaration of strftime gcc/c/ChangeLog: PR c/94040 * c-decl.c (builtin_structptr_type_count): New constant. (match_builtin_function_types): Reject decls that are incompatible in types pointed to by pointers. (diagnose_mismatched_decls): Adjust comments. gcc/testsuite/ChangeLog: PR c/94040 * gcc.dg/Wbuiltin-declaration-mismatch-12.c: Relax test to look for warning name rather than the exact text. * gcc.dg/Wbuiltin-declaration-mismatch-14.c: New test. * gcc.dg/Wbuiltin-declaration-mismatch-15.c: New test. * gcc.dg/pr62090.c: Prune expected warning. * gcc.dg/pr89314.c: Look for warning name rather than text.
[Bug preprocessor/94168] [10 Regression] error: extended character § is not valid in an identifier since r10-3309-g7d112d6670a0e0e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94168
--- Comment #2 from Lewis Hyatt ---
(In reply to Martin Liška from comment #0)
> I see the following regression:
>
> $ cat red.cc
> #ifdef WINDOWS
> §
> #endif
>
> $ g++-9 red.cc -c
> $ g++ red.cc -c
> red.cc:2:1: error: extended character § is not valid in an identifier
> 2 | ��
> | ^
The corrupted colorization in the diagnostics is a bug that I submitted a patch
for already. David prefers that fix to wait for GCC 11.
Regarding the behavior, if you replace the § with the equivalent UCN:
#ifdef WINDOWS
\u00A7
#endif
then you will get the same behavior with older GCC before my patch too. My
patch causes the UTF-8 to be interpreted as an identifier rather than a stray
token, hence it ends up with the same error.
As it happens, if you compile your test in C mode, it will succeed, because the
UTF-8 logic for C mode treats the invalid character as a stray token rather
than part of an identifier, then it gets compiled out fine. In C++, it is
rather a syntax error by design so it triggers this error. When switching to
UCN syntax, it is an error for both C and C++ so fails either way.
Looking at the relevant code in charset.c (_cpp_valid_ucn and _cpp_valid_utf8)
... I think it is probably just a matter of checking pfile->state.skipping in
more places. I made _cpp_valid_utf8 so as to preserve all the analogous
behavior of the existing _cpp_valid_ucn. It seems that _cpp_valid_ucn checks
pfile->state.skipping in some cases, like for $ in identifiers, but not for
others, such as the invalid character case.
I am happy to submit a patch to fix this, but I am not sure in what all cases
it is correct to skip the error. For instance, this code can be made to trigger
an error too, in C90 mode:
$ cat t.c
#ifdef WINDOWS
int \u00E4;
#endif
$ gcc-8 -c t.c -std=c90 -fextended-identifiers
t.c:2:5: warning: universal character names are only valid in C++ and C99
int \u00E4;
^
That is because _cpp_valid_ucn doesn't check pfile->state.skipping for this
case either. I think, especially in C++, there are probably at least some cases
where an error should be triggered even in conditionally compiled code, but I
don't know enough off hand to say for sure.
FWIW, the below patch fixes the present issue, but it doesn't tackle equivalent
UCN behavior or fix the related issues... I just need some guidance as to the
expected behavior to do that.
-Lewis
diff --git a/libcpp/charset.c b/libcpp/charset.c
index d9281c5fb97..129f234349e 100644
--- a/libcpp/charset.c
+++ b/libcpp/charset.c
@@ -1260,7 +1260,7 @@ _cpp_valid_utf8 (cpp_reader *pfile,
way). In C, this byte rather becomes grammatically a separate
token. */
- if (CPP_OPTION (pfile, cplusplus))
+ if (!pfile->state.skipping && CPP_OPTION (pfile, cplusplus))
cpp_error (pfile, CPP_DL_ERROR,
"extended character %.*s is not valid in an identifier",
(int) (*pstr - base), base);
@@ -1273,7 +1273,7 @@ _cpp_valid_utf8 (cpp_reader *pfile,
break;
case 2:
- if (identifier_pos == 1)
+ if (!pfile->state.skipping && identifier_pos == 1)
{
/* This is treated the same way in C++ or C99 -- lexed as an
identifier which is then invalid because an identifier is
[Bug fortran/94170] New: gfortran segfault on object oriented code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94170 Bug ID: 94170 Summary: gfortran segfault on object oriented code Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: r.dilz at tue dot nl Target Milestone: --- Created attachment 48030 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48030&action=edit The part of the code that crashes the gfortran I have some code that doesn't work on some gfortran compilers. gfortran-4.8 Works ifort (15.0.0) Works gfortran-5 segfaults gfortran-7 segfaults gfortan-9 (9.2.1) segfaults Since I am new to object oriented fortran, I am not completely sure whether my code is correct. But since it works on some compilers, I suspect it is correct. The code is simply built with: gfortran -c crashgfortran.f90 (see attachment) The goal of the code is to recursively build arrays of classes.
[Bug rtl-optimization/94119] [8/9/10 regression] invalid filling of branch delay slots leads to corrupt jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119 --- Comment #12 from Eric Botcazou --- > I noticed that you accidentially put the wrong year into the ChangeLog. Thanks, fixed.
[Bug rtl-optimization/94148] The DF framework uses bb->aux, which is for passes only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148 --- Comment #3 from Segher Boessenkool --- Fixed on trunk so far.
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 Segher Boessenkool changed: What|Removed |Added Target|powerpc64-suse-linux|powerpc* Host|powerpc64-suse-linux| Build|powerpc64-suse-linux| --- Comment #48 from Segher Boessenkool --- Solved on trunk
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #49 from Segher Boessenkool --- Fixed.
[Bug preprocessor/94168] [10 Regression] error: extended character § is not valid in an identifier since r10-3309-g7d112d6670a0e0e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94168 --- Comment #3 from joseph at codesourcery dot com --- The reasoning for rejecting this (for UCNs in both C and C++, for other characters in C++ because of the C++ rule that such characters get converted to UCNs) is that the constraints on permitted characters in identifiers appear to me to apply to any pp-token that matches the syntax productions for "identifier", whether or not that pp-token ends up getting converted to a token. This is similar to #if 0 "multiline string" #endif being disallowed as well.
[Bug c++/93248] [8/9/10 Regression] ICE in decltype of template constructor with default argument within a class template since r8-2712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93248 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/94044] [10 Regression] internal compiler error: in comptypes, at cp/typeck.c:1490 on riscv64-unknown-linux-gnu and arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044 --- Comment #6 from Nathan Sidwell --- Still no luck. I'm at cb99630f254 2020-03-11 | fold undefined pointer offsetting Configured with ../../src/configure '--with-mpfr=/data/users/nathans/tools' '--with-mpc=/data/users/nathans/tools' '--enable-checking=yes' --disable-multilib --disable-bootstrap '--enable-languages=c,c++,lto' '--target=arm-eabi' devvm2772+2:5>./cc1plus -quiet variadic-sizeof4.C -quiet -mcpu=arm7tdmi -marm -march=armv4t -std=c++14 -o - ... assembly emitted ... I'm using a fresh binutils cross toolchain I understand where the compiler got to from your traceback. I don't understand what constructed the trees that got it there!
[Bug c++/92909] [8/9/10 Regression] ICE on incorrect lambda inside variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92909 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/90995] [8/9/10 Regression] ICE in grokdeclarator, at cp/decl.c:12024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90995 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 48031 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48031&action=edit gcc10-pr90995.patch Untested fix.
[Bug d/93038] Missing dependencies in depfile for imported files at compilation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93038 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-03-13 Status|UNCONFIRMED |ASSIGNED CC||ibuclaw at gcc dot gnu.org --- Comment #1 from ibuclaw at gcc dot gnu.org --- Yes, I have too noticed this and have a fix in the gdc development branch, will backport it to gcc trunk as soon as I cherry-pick out parts not related to supporting the self-hosted front-end.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #29 from Jakub Jelinek --- Friday 13th's test.
[Bug c/94171] New: attribute silently ignored on redeclarations of a typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94171
Bug ID: 94171
Summary: attribute silently ignored on redeclarations of a
typedef
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The attribute machinery silently drops attributes from subsequent type
definitions. The test case below shows this with attribute nonnull but other
attributes that apply to types are affected as well.
Intel ICC behaves correctly and diagnoses all seven instances of passing a null
to a nonnull argument.
$ cat x.c && gcc -S -Wall -Wextra x.c
extern int a[];
typedef __attribute__ ((nonnull (1))) void F1 (void*, void*);
void f1 (F1 *p)
{
p (a, 0);
p (0, a);// -Wnonnull (good)
}
typedef __attribute__ ((nonnull (1))) void F1_2 (void*, void*);
typedef __attribute__ ((nonnull (2))) void F1_2 (void*, void*);
void f12 (F1_2 *p)
{
p (a, 0);// missing -Wnonnull
p (0, a);// -Wnonnull (good)
}
typedef __attribute__ ((nonnull (2))) void F2_1 (void*, void*);
typedef __attribute__ ((nonnull (1))) void F2_1 (void*, void*);
void f21 (F2_1 *p)
{
p (a, 0);// -Wnonnull (good)
p (0, a);// missing -Wnonnull
}
typedef void Fx_1_2 (void*, void*);
typedef __attribute__ ((nonnull (1))) void Fx_1_2 (void*, void*);
typedef __attribute__ ((nonnull (2))) void Fx_1_2 (void*, void*);
void fx12 (Fx_1_2 *p)
{
p (a, 0);// missing -Wnonnull
p (0, a);// missing -Wnonnull
}
x.c: In function ‘f1’:
x.c:8:3: warning: null argument where non-null required (argument 1)
[-Wnonnull]
8 | p (0, a);// -Wnonnull (good)
| ^
x.c: In function ‘f12’:
x.c:17:3: warning: null argument where non-null required (argument 1)
[-Wnonnull]
17 | p (0, a);// -Wnonnull (good)
| ^
x.c: In function ‘f21’:
x.c:25:3: warning: null argument where non-null required (argument 2)
[-Wnonnull]
25 | p (a, 0);// -Wnonnull (good)
| ^
[Bug d/93038] Missing dependencies in depfile for imported files at compilation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93038 --- Comment #2 from Pierrick Bouvier --- (In reply to ibuclaw from comment #1) > Yes, I have too noticed this and have a fix in the gdc development branch, > will backport it to gcc trunk as soon as I cherry-pick out parts not related > to supporting the self-hosted front-end. Very good news. Hope it will land in first release of gcc-10 first release.
[Bug rtl-optimization/94148] The DF framework uses bb->aux, which is for passes only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148 --- Comment #4 from Segher Boessenkool --- Fixed on trunk so far.
[Bug rtl-optimization/94148] The DF framework uses bb->aux, which is for passes only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148 --- Comment #5 from Segher Boessenkool --- commit 5c7e6d4bdf879b437b43037e10453275acabf521 Author: Segher Boessenkool Date: Thu Mar 12 07:12:50 2020 + df: Don't abuse bb->aux (PR94148, PR94042) The df dataflow solvers use the aux field in the basic_block struct, although that is reserved for any use by passes. And not only that, it is required that you set all such fields to NULL before calling the solvers, or you quietly get wrong results. This changes the solvers to use a local array for last_change_age instead, just like it already had a local array for last_visit_age. PR rtl-optimization/94148 PR rtl-optimization/94042 * df-core.c (BB_LAST_CHANGE_AGE): Delete. (df_worklist_propagate_forward): New parameter last_change_age, use that instead of bb->aux. (df_worklist_propagate_backward): Ditto. (df_worklist_dataflow_doublequeue): Use a local array last_change_age.
[Bug analyzer/94099] ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874 since r10-7023-g3d66e153b40ed000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94099 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from David Malcolm --- Should be fixed by g:5c048755ec98645f8436b630df3f9294ca9cbc2a.
[Bug analyzer/94105] ICE in get_region, at analyzer/region-model.h:1744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94105 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from David Malcolm --- Should be fixed by g:5c048755ec98645f8436b630df3f9294ca9cbc2a.
[Bug rtl-optimization/90706] [9/10 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 --- Comment #8 from Berni --- I just compiled AVR gcc 9.3.0 and tested the code again. Still no improvement!
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #10 from Rich Felker --- This is a rather huge bug to have been fixed silently. Could someone who knows the commit that fixed it and information on what versions are affected attach the info to the tracker here? And ideally some information on working around it for older GCCs? >From what I can tell experimenting so far, adding a dummy "0"(r0) constraint, or using + instead of =, makes the problem go away, but potentially has other ill effects from use of an uninitialized object..?
[Bug c++/92068] [8/9/10 Regression] ICE on invalid in process_partial_specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92068 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/91966] [8/9/10 Regression] pack expansion for Cartesian product breaks if certain indirections are involved since r6-1487-g1a4cd2cd7e7266b0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91966 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug middle-end/94172] New: [arm-none-eabi] ICE in expand_debug_locations, at cfgexpand.c:5403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94172
Bug ID: 94172
Summary: [arm-none-eabi] ICE in expand_debug_locations, at
cfgexpand.c:5403
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dtaubert at atmosic dot com
Target Milestone: ---
Created attachment 48032
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48032&action=edit
gcc -v output
extern enum my_enum_type extern_enum;
extern void bar(int a);
enum my_enum_type {
my_entry
};
void foo(int a)
{
int local_enum = extern_enum;
if (a) {
__asm volatile ("bkpt 0");
local_enum = 0;
}
bar(local_enum);
}
arm/gcc-arm-none-eabi-8-2019-q3-update/bin/arm-none-eabi-gcc -o foo.o -c
-mcpu=cortex-m0 -mthumb -Os -g3 foo.c
during RTL pass: expand
foo.c: In function 'foo':
foo.c:8:6: internal compiler error: in expand_debug_locations, at
cfgexpand.c:5403
void foo(int a)
^~~
Also seen with releases/gcc-9.2.0 from git://gcc.gnu.org/git/gcc.git
during RTL pass: expand
foo.c: In function ?foo?:
foo.c:8:6: internal compiler error: in expand_debug_locations, at
cfgexpand.c:5460
8 | void foo(int a)
| ^~~
0x67cb6b expand_debug_locations
../../gcc/cfgexpand.c:5456
0x67cb6b execute
../../gcc/cfgexpand.c:6516
gcc_assert (mode == GET_MODE (val)
|| (GET_MODE (val) == VOIDmode
&& (CONST_SCALAR_INT_P (val)
|| GET_CODE (val) == CONST_FIXED
|| GET_CODE (val) == LABEL_REF)));
[Bug middle-end/94172] [arm-none-eabi] ICE in expand_debug_locations, at cfgexpand.c:5403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94172 --- Comment #1 from Andrew Pinski --- >GNU Tools for Arm Embedded Processors 8-2019-q3-update You should report this to ARM really.
[Bug c++/94044] [10 Regression] internal compiler error: in comptypes, at cp/typeck.c:1490 on riscv64-unknown-linux-gnu and arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #7 from Jim Wilson ---
I made an attempt to reproduce this. I wasn't able to reproduce with an
arm-eabi build. I was able to reproduce with a riscv64-linux build. The funny
part is that I was able to build two compilers from the same gcc sources, one
which reproduces and one which does not, which differ only in exactly how I did
the build. For the failing build, I had a complete riscv-gnu-toolchain build
available when configuring. For the working build it was just binutils and gcc
without glibc/linux header files, and a top-of-tree binutils version unlike the
first build.
Debugging the two side by side, I see that execution diverges at line 9680 in
cp/pt.c
entry = type_specializations->find_with_hash (&elt, hash);
The working compiler has no hash hit and returns zero. The failing compiler
has a hash hit, and then dies inside spec_hasher::equal.
In the spec_hasher::equal function I see
(gdb) print *e1
$29 = {tmpl = ,
args = , spec = }
(gdb) print *e2
$30 = {tmpl = ,
args = , spec = }
(gdb) pt
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x75deb7e0 precision:64 min max
pointer_to_this >
readonly
arg:0 elt:1 >
type_0 type_6 VOID
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x75ef4540>
tmp.C:13:23 start: tmp.C:13:23 finish: tmp.C:13:35>>
(gdb) print e2->args
$32 =
(gdb) pt
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x75deb7e0 precision:64 min max
pointer_to_this >
readonly
arg:0 elt:1 >
type_0 type_6 VOID
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x75efa2a0>
tmp.C:13:23 start: tmp.C:13:23 finish: tmp.C:13:35>>
(gdb)
It then eventually dies inside comptypes because TREE_CODE (t1) is
type_pack_expansion. And also TREE_CODE (t2) is type_pack_expansion. This is
called from the SIZEOF_EXPR case in cp_tree_equal.
If tree addresses are being used for the hash codes, this could just be bad
luck whether it fails or not.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #30 from CVS Commits --- PR c/93218 - Testing
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #31 from CVS Commits --- PR c/93218 - Testing
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #32 from CVS Commits --- PR c/93218 - Testing
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #33 from CVS Commits --- PR c/93218 - Testing
[Bug target/92318] Nondeterministic ICE with -mcmodel=large -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92318 --- Comment #8 from cgf at gcc dot gnu.org --- email from sourceware
[Bug target/92318] Nondeterministic ICE with -mcmodel=large -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92318 --- Comment #9 from cgf-use-the-mailinglist-please at gnu dot org --- email from cgf.cx
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #34 from CVS Commits --- PR c/93218 - Testing
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #35 from CVS Commits --- PR c/93218 - Testing
