[Bug objc++/99056] NIOS GCC optimizaton issue with memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99056 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #3 from Richard Biener --- Fixed.
[Bug ipa/97346] IPA reference reference_vars_to_consider leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Fixed.
[Bug c/99100] New: Inconsistent vector length used in autovectorizer for AVX-512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99100
Bug ID: 99100
Summary: Inconsistent vector length used in autovectorizer for
AVX-512
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shibatch.sf.net at gmail dot com
Target Milestone: ---
When AVX512 instruction is available, the auto-vectorizer in gcc
sometimes generates calls to AVX2 functions instead of AVX512 functions.
-mprefer-vector-width=512 does not affect the result.
$ cat vabitest.c
#include
#include
_Pragma ("omp declare simd simdlen(8) notinbranch")
__attribute__((const)) double myfunc(double x);
#define N 1024
__attribute__ ((__aligned__(256))) double a[N], b[N], c[N];
int main(void) {
for (int i = 0; i < N; i++) a[i] = myfunc(b[i]);
for (int i = 0; i < N; i++) c[i] = sin(b[i]);
}
$ gcc-10 -ffast-math -O3 -mavx512f -fopenmp vabitest.c -S -o- | grep _ZGV
call_ZGVdN8v_myfunc@PLT
call_ZGVeN8v_sin@PLT
[Bug ada/99099] bogus error on generic formal derived tagged type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99099 --- Comment #1 from Stephen Leake --- Created attachment 50183 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50183=edit all source files
[Bug ada/99099] New: bogus error on generic formal derived tagged type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99099 Bug ID: 99099 Summary: bogus error on generic formal derived tagged type Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: stephen_le...@stephe-leake.org Target Milestone: --- Created attachment 50182 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50182=edit source file The attached code compiles with GNAT Community 2019 and 2020, but fails with gcc 10.2: $ gprbuild -p -P work.gpr Setup [mkdir]object directory for project work Compile [Ada] wisi.ads [Ada] test_gen_emacs.adb gen_emacs_wisi_lr_parse.ads:3:52: missing ";" gprbuild: *** compilation phase failed
[Bug target/68485] ICE while building gpsd package on microblaze
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485 Giulio Benetti changed: What|Removed |Added CC||giulio.benetti@micronovasrl ||.com --- Comment #9 from Giulio Benetti --- Hello, bug still exists on gcc 10.2, is there any news about it? Thanks in advance
[Bug middle-end/80922] #pragma diagnostic ignored not honoured with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98465 --- Comment #6 from Martin Sebor --- We should make sure the suppression works the same way with and without -flto.
[Bug middle-end/80922] #pragma diagnostic ignored not honoured with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922 Martin Sebor changed: What|Removed |Added Blocks||99098 Known to fail||10.2.0, 11.0, 7.3.0, 8.3.0, ||9.2.0 CC||msebor at gcc dot gnu.org Last reconfirmed|2017-05-31 00:00:00 |2021-2-14 --- Comment #5 from Martin Sebor --- No change in GCC 11. FWIW, I tried the patch for pr98465 but it doesn't help: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564060.html here. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99098 [Bug 99098] invalid/missing -Wfree-nonheap-object warnings
[Bug middle-end/99098] invalid/missing -Wfree-nonheap-object warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99098 Bug 99098 depends on bug 93873, which changed state. Bug 93873 Summary: gcc or lto-wrapper does not consider individual bitfield values on static analysis and instead tests the whole value of all bitfield bits combined https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93873 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/93873] gcc or lto-wrapper does not consider individual bitfield values on static analysis and instead tests the whole value of all bitfield bits combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93873 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Known to work||10.2.0, 11.0 Known to fail||6.3.0, 7.5.0, 8.4.0, 9.3.0 CC||msebor at gcc dot gnu.org Blocks||99098 --- Comment #7 from Martin Sebor --- I can reproduce the warning with versions up to 9, at -O2 (or -O3) and both with and without -flto. GCC 10 doesn't issue it. Bisection points to r276416 as the fix. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99098 [Bug 99098] invalid/missing -Wfree-nonheap-object warnings
[Bug ipa/96252] [10/11 Regression] mis-optimization where identical functions have very different codegen since gcc 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96252
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||hubicka at gcc dot gnu.org
Last reconfirmed||2021-02-14
--- Comment #5 from Jan Hubicka ---
This looks like missed memory copy propagation to me.
We inline the icfed function back but for some reason we end up with all those
extra moves, so it does not seem to be problem with missed tailcall
IPA function summary for bool cmp_y(cmp, cmp)/767 inlinable
global time: 92.095312
self size: 13
global size: 14
min size: 11
self stack: 0
global stack:0
size:11.00, time:90.095312
size:3.00, time:2.00, executed if:(not inlined)
calls:
bool cmp_x(cmp, cmp)/804 inlined
freq:1.00
Stack frame offset 0, callee self size 0
__lexicographical_compare_impl.isra/803 inlined
freq:1.00
Stack frame offset 0, callee self size 0
Funny thing is that inliner seems to believe it is going to reduce code size:
Considering bool cmp_x(cmp, cmp)/766 with 10 size
to be inlined into bool cmp_y(cmp, cmp)/767 in unknown:0
Estimated badness is -inf, frequency 1.00.
Badness calculation for bool cmp_y(cmp, cmp)/767 -> bool cmp_x(cmp,
cmp)/766
size growth -3, time 16.00 unspec 18.00 big_speedup
-inf: Growth -3 <= 0
Adjusted by hints -inf
The body is:
bool cmp_y (struct cmp l, struct cmp r)
{
int * __first1;
int * __first2;
struct cmp l;
struct cmp r;
int _8;
int _9;
bool _17;
[local count: 1073741824]:
l = l;
r = r;
goto ; [100.00%]
[local count: 9416790681]:
if (_8 > _9)
goto ; [3.66%]
else
goto ; [96.34%]
[local count: 9072136140]:
__first1_11 = __first1_21 + 4;
__first2_13 = __first2_2 + 4;
if ( [(void *) + 256B] != __first2_13)
goto ; [95.91%]
else
goto ; [4.09%]
[local count: 9774538809]:
# __first1_21 = PHI <__first1_11(4), _M_elems(2)>
# __first2_2 = PHI <__first2_13(4), _M_elems(2)>
_8 = MEM[(int *)__first1_21];
_9 = MEM[(int *)__first2_2];
if (_8 < _9)
goto ; [3.66%]
else
goto ; [96.34%]
[local count: 1073741824]:
# _17 = PHI <0(3), 1(5), 0(4)>
[local count: 1073741824]:
# _17 = PHI <0(3), 1(5), 0(4)>
l ={v} {CLOBBER};
r ={v} {CLOBBER};
return _17;
}
Richi,
in any case, we may want to avoid creating wrappers for functions with very
large parameters?
[Bug middle-end/99098] invalid/missing -Wfree-nonheap-object warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99098 Martin Sebor changed: What|Removed |Added Ever confirmed|0 |1 Alias||Wfree-nonheap-object Last reconfirmed||2021-02-14 Version|11.0|4.7.0 Status|UNCONFIRMED |NEW Keywords||diagnostic, meta-bug --- Comment #1 from Martin Sebor --- -Wfree-nonheap-object was introduced in r178004 (in GCC 4.7.0).
[Bug middle-end/99098] New: invalid/missing -Wfree-nonheap-object warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99098 Bug ID: 99098 Summary: invalid/missing -Wfree-nonheap-object warnings Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- This is a meta-bug to track false positives and negatives in the -Wfree-nonheap-object warning.
[Bug ipa/98265] [10/11 Regression] gcc-10 has significantly worse code generated with -O2 compared to -O1 (or gcc-9 -O2) when using the Eigen C++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98265
--- Comment #6 from Jan Hubicka ---
I am testing
diff --git a/gcc/cif-code.def b/gcc/cif-code.def
index 2f430cf1c39..39b89da155f 100644
--- a/gcc/cif-code.def
+++ b/gcc/cif-code.def
@@ -125,7 +125,7 @@ DEFCIFCODE(OPTIMIZATION_MISMATCH, CIF_FINAL_ERROR,
N_("optimization level attribute mismatch"))
/* We can't inline because the callee refers to comdat-local symbols. */
-DEFCIFCODE(USES_COMDAT_LOCAL, CIF_FINAL_ERROR,
+DEFCIFCODE(USES_COMDAT_LOCAL, CIF_FINAL_NORMAL,
N_("callee refers to comdat-local symbols"))
/* We can't inline because of mismatched caller/callee
[Bug ipa/98265] [10/11 Regression] gcc-10 has significantly worse code generated with -O2 compared to -O1 (or gcc-9 -O2) when using the Eigen C++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98265 --- Comment #5 from Jan Hubicka --- We do not inline CwiseNullaryOp because it uses comdat local symbols. This is because we do split the function and the .part stays local. At least we should recompute if function calls comdat local after comdat local function is inlined. IPA function summary for Eigen::Matrix should_inline(float, float, float, float)/2 inlinable fp_expression global time: 36.00 self size: 21 global size: 29 min size: 24 self stack: 16 global stack:20 size:19.00, time:18.50 size:4.50, time:3.50, executed if:(not inlined) calls: operator*.isra/90 inlined freq:1.00 Stack frame offset 16, callee self size 4 Eigen::CwiseNullaryOp< , >::CwiseNullaryOp(long int, long int, Eigen::scalar_constant_op) [with = Eigen::scalar_constant_op; PlainObjectType = Eigen::Matrix]/20 callee refers to comdat-local symbols freq:1.00 loop depth: 0 size: 5 time: 14 callee size: 6 stack: 0 op0 is compile time invariant op0 points to local or readonly memory op1 is compile time invariant op2 is compile time invariant op2 points to local or readonly memory
[Bug tree-optimization/99082] manual bit-field creation followed by manual extraction does not always produce good code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99082 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-14 Ever confirmed|0 |1 --- Comment #1 from Hans-Peter Nilsson --- Confirmed at 4e3590d06cf8a0 for cris-elf at -O2, where bar also needs a non-empty stack-frame, but I'm pretty sure that's not the target you had in mind.
[Bug bootstrap/98338] [10/11 Regression] profiledbootstrap failure on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338
--- Comment #17 from Jan Hubicka ---
I am testing
diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c
index e32e69cd3ad..612880240dc 100644
--- a/gcc/ipa-fnsummary.c
+++ b/gcc/ipa-fnsummary.c
@@ -3137,11 +3137,18 @@ compute_fn_summary (struct cgraph_node *node, bool
early)
info->estimated_stack_size = size_info->estimated_self_stack_size;
/* Code above should compute exactly the same result as
- ipa_update_overall_fn_summary but because computation happens in
- different order the roundoff errors result in slight changes. */
+ ipa_update_overall_fn_summary except for case when speculative
+ edges are present since these are accounted to size but not
+ self_size. Do not compare time since different order the roundoff
+ errors result in slight changes. */
ipa_update_overall_fn_summary (node);
- /* In LTO mode we may have speculative edges set. */
- gcc_assert (in_lto_p || size_info->size == size_info->self_size);
+ if (flag_checking)
+{
+ for (e = node->indirect_calls; e; e = e->next_callee)
+ if (e->speculative)
+ break;
+ gcc_assert (e || size_info->size == size_info->self_size);
+}
}
[Bug ipa/97346] IPA reference reference_vars_to_consider leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346 --- Comment #9 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:9966699d7a9d8e35c0c4cf9a945bcf90ef874f2d commit r11-7240-g9966699d7a9d8e35c0c4cf9a945bcf90ef874f2d Author: Jan Hubicka Date: Sun Feb 14 23:24:44 2021 +0100 Fix memory leak in ipa-refernece 2021-02-14 Jan Hubicka Richard Biener PR ipa/97346 * ipa-reference.c (ipa_init): Only conditinally initialize reference_vars_to_consider. (propagate): Conditionally deninitialize reference_vars_to_consider. (ipa_reference_write_optimization_summary): Sanity check that reference_vars_to_consider is not allocated.
[Bug c++/99086] including and defaulting spaceship operator causes compiler segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99086
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to crillion from comment #0)
> > #include
> >
> > class value_wrapper
> > {
> > public :
> >
> > bool operator<=>(const value_wrapper& rhs) const = default;
>
> This is a bug, the spaceship operator has to return one of
> std::strong_ordering, std::weak_ordering or std::partial_ordering.
That's not quite true, it can be something that std::strong_ordering is
convertible to. But it can't be bool.
If you're defaulting it, you probably want to just return auto and let the
compiler get the type right.
[Bug c++/99086] including and defaulting spaceship operator causes compiler segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99086
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Keywords||ice-on-invalid-code
Known to work||11.0
Known to fail||10.2.1
Last reconfirmed||2021-02-14
CC||jason at gcc dot gnu.org
--- Comment #1 from Jonathan Wakely ---
(In reply to crillion from comment #0)
> #include
>
> class value_wrapper
> {
> public :
>
> bool operator<=>(const value_wrapper& rhs) const = default;
This is a bug, the spaceship operator has to return one of
std::strong_ordering, std::weak_ordering or std::partial_ordering.
GCC's crash on the invalid code has already been fixed in r11-5866:
c++: Fix defaulted <=> fallback to < and == [PR96299]
I don't know if there are plans to backport that.
[Bug libstdc++/99096] Several failures in the libstdc++-v3 test suite for x86_64-apple-darwin20.3.0 after r11-7220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99096 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- Those tests should be OK again now.
[Bug libstdc++/99096] Several failures in the libstdc++-v3 test suite for x86_64-apple-darwin20.3.0 after r11-7220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99096 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4e3590d06cf8a06fcc460ccda6150483a0311bae commit r11-7239-g4e3590d06cf8a06fcc460ccda6150483a0311bae Author: Jonathan Wakely Date: Sun Feb 14 20:38:32 2021 + libstdc++: Restore in testsuite_fs.h header [PR 99096] libstdc++-v3/ChangeLog: PR libstdc++/99096 * testsuite/util/testsuite_fs.h: Always include .
[Bug fortran/98686] Namelist group objects shall be defined before appearing in namelist for -std=f2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98686
--- Comment #4 from Jerry DeLisle ---
One of this difficulties here is:
"If a namelist group object is typed by the implicit typing rules, its
appearance in any subsequent type declaration statement shall confirm the
implied type and type parameters."
If one takes away the IMPLICIT NONE in the example given, it would be valid
only if the subsequent explicit declarations agreed with the IMPLICIT. As far
as I know, there is no checking that explicit declarations confirm IMPLICIT.
My thinking is to add the check I have so far and defer the confirmatory checks
elsewhere, maybe as a warning. Otherwise I think it is can of worms. I do
think it might be useful to warn people about not confirming an implicit type
since it is conceivable that someone might contradict themselves while
modifying legacy codes. This is why we always recommend IMPLICIT NONE
regardless.
The patch at this point regressions tests OK.
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 2df6191d7e6..2e6d1db515a 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -5536,6 +5536,17 @@ gfc_match_namelist (void)
if (m == MATCH_ERROR)
goto error;
+ /* It is required that members of a namelist be declared
+before the namelist. We check this by checking if the
+symbol has a defined type. */
+ if (gfc_current_ns->seen_implicit_none &&
+ sym->ts.type == BT_UNKNOWN)
+ {
+ gfc_error ("Symbol %qs in namelist %qs at %C must be "
+"declared before the namelist is declared.",
+sym->name, group_name->name);
+ goto error;
+ }
if (sym->attr.in_namelist == 0
&& !gfc_add_in_namelist (>attr, sym->name, NULL))
goto error;
[Bug fortran/96418] Test coarray_alloc_comp_4.f08 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96418 Dominique d'Humieres changed: What|Removed |Added CC||dominiq at lps dot ens.fr --- Comment #7 from Dominique d'Humieres --- *** Bug 98764 has been marked as a duplicate of this bug. ***
[Bug fortran/98764] ICE for the test gfortran.dg/coarray_alloc_comp_3.f08 with -fcoarray=single since r7-5021-gba85c8c3fcb19c77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98764 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Dominique d'Humieres --- Dup. *** This bug has been marked as a duplicate of bug 96418 ***
[Bug libstdc++/99096] Several failures in the libstdc++-v3 test suite for x86_64-apple-darwin20.3.0 after r11-7220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99096 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-02-14 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |11.0 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jonathan Wakely --- Oops, unistd.h is always needed.
[Bug fortran/95304] Clean up some code for finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95304 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-02-14 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Dominique d'Humieres --- What cleanup do you expect?
[Bug fortran/94446] Bogus "type mismatch" with TYPE(c_ptr) and sizeof()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94446 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-14 --- Comment #1 from Dominique d'Humieres --- Confirmed since at least GCC7.
[Bug fortran/97592] Incorrectly set pointer remapping with array pointer argument to CONTIGUOUS dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97592 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-02-14 --- Comment #2 from Dominique d'Humieres --- > Workaround: add CONTIGUOUS to the declaration of B_2D. Confirmed for GCC9 up to GCC11. Note that GCC7 and GCC8 give the expected result without the CONTIGUOUS attribute.
[Bug middle-end/99097] profiledbootstrap fails with LTO and disabled plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99097 --- Comment #1 from Jan Hubicka --- Also linker used is gold which may be a problem since: So the problem ssems to be wrong call to strcmp: Program received signal SIGSEGV, Segmentation fault. 0x77886372 in __strcmp_avx2 () from /lib64/libc.so.6 (gdb) bt #0 0x77886372 in __strcmp_avx2 () from /lib64/libc.so.6 #1 0x0149fcc8 in ix86_option_override_internal (main_args_p=, opts=0x3396c60 , opts_set=0x33d4fe0 ) at ../../gcc/config/i386/i386-options.c:2045 #2 0x014a3c30 in ix86_option_override () at ../../gcc/config/i386/i386-options.c:3046 #3 0x00e41832 in process_options () at ../../gcc/toplev.c:1247 #4 0x0047f3d5 in do_compile () at ../../gcc/toplev.c:2119 #5 toplev::main (this=0x7fffe0de, argc=, argv=) at ../../gcc/toplev.c:2336 #6 0x00486caf in main (argc=1, argv=0x7fffe1e8) at ../../gcc/main.c:39 (gdb) up #1 0x0149fcc8 in ix86_option_override_internal (main_args_p=, opts=0x3396c60 , opts_set=0x33d4fe0 ) at ../../gcc/config/i386/i386-options.c:2045 2045if (! strcmp (opts->x_ix86_arch_string, processor_alias_table[i].name)) (gdb) p opts->x_ix86_arch_string $1 = 0x23896fb "x86-64" (gdb) p processor_alias_table[i].name $2 = 0x0 (gdb) p i $3 = 0 processor alias table is const so i do not see how that can happen legally...
[Bug fortran/98014] [Fortran OpenACC] Empty '!$acc' continuation line rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98014 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-02-14 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug middle-end/99097] New: profiledbootstrap fails with LTO and disabled plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99097 Bug ID: 99097 Summary: profiledbootstrap fails with LTO and disabled plugin Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- Configuring with ../configure --disable-multilib --prefix=/home/jan/trunk-install --with-build-config=bootstrap-lto --enable-checking=release --disable-plugin I get on x86-64: cc1: internal compiler error: Segmentation fault 0xe3ae79 crash_signal ../../gcc/toplev.c:327 0x149fcc7 ix86_option_override_internal ../../gcc/config/i386/i386-options.c:2045 0x14a3c2f ix86_option_override() ../../gcc/config/i386/i386-options.c:3046 0xe41831 process_options ../../gcc/toplev.c:1247 0x47f3d4 do_compile ../../gcc/toplev.c:2119
[Bug libstdc++/99096] New: Several failures in the libstdc++-v3 test suite for x86_64-apple-darwin20.3.0 after r11-7220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99096 Bug ID: 99096 Summary: Several failures in the libstdc++-v3 test suite for x86_64-apple-darwin20.3.0 after r11-7220 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: iains at gcc dot gnu.org, redi at gcc dot gnu.org Target Milestone: --- After r11-7220 I see the following failures FAIL: 27_io/filesystem/iterators/caching.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/iterators/caching.cc compilation failed to produce executable FAIL: 27_io/filesystem/operations/absolute.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/operations/absolute.cc compilation failed to produce executable FAIL: 27_io/filesystem/operations/copy.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/operations/copy.cc compilation failed to produce executable FAIL: 27_io/filesystem/operations/copy_file.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/operations/copy_file.cc compilation failed to produce executable FAIL: 27_io/filesystem/operations/current_path.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/operations/current_path.cc compilation failed to produce executable FAIL: 27_io/filesystem/operations/equivalent.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/operations/equivalent.cc compilation failed to produce executable FAIL: 27_io/filesystem/operations/last_write_time.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/operations/last_write_time.cc compilation failed to produce executable FAIL: 27_io/filesystem/operations/permissions.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/operations/permissions.cc compilation failed to produce executable FAIL: 27_io/filesystem/operations/relative.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/operations/relative.cc compilation failed to produce executable FAIL: 27_io/filesystem/operations/resize_file.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/operations/resize_file.cc compilation failed to produce executable FAIL: 27_io/filesystem/operations/space.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/operations/space.cc compilation failed to produce executable FAIL: 27_io/filesystem/operations/weakly_canonical.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/operations/weakly_canonical.cc compilation failed to produce executable FAIL: 27_io/filesystem/path/append/source.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/path/append/source.cc compilation failed to produce executable FAIL: 27_io/filesystem/path/assign/assign.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/path/assign/assign.cc compilation failed to produce executable FAIL: 27_io/filesystem/path/assign/copy.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/path/assign/copy.cc compilation failed to produce executable FAIL: 27_io/filesystem/path/concat/92853.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/path/concat/92853.cc compilation failed to produce executable FAIL: 27_io/filesystem/path/construct/copy.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/path/construct/copy.cc compilation failed to produce executable FAIL: 27_io/filesystem/path/construct/range.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/path/construct/range.cc compilation failed to produce executable FAIL: 27_io/filesystem/path/construct/string_view.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/path/construct/string_view.cc compilation failed to produce executable FAIL: 27_io/filesystem/path/generation/normal.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/path/generation/normal.cc compilation failed to produce executable FAIL: 27_io/filesystem/path/generation/normal2.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/path/generation/normal2.cc compilation failed to produce executable FAIL: 27_io/filesystem/path/generic/generic_string.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/path/generic/generic_string.cc compilation failed to produce executable FAIL: 27_io/filesystem/path/modifiers/clear.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/path/modifiers/clear.cc compilation failed to produce executable FAIL: 27_io/filesystem/path/modifiers/make_preferred.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/path/modifiers/make_preferred.cc compilation failed to produce executable FAIL: 27_io/filesystem/path/modifiers/remove_filename.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/path/modifiers/remove_filename.cc compilation failed to produce executable FAIL: 27_io/filesystem/path/modifiers/replace_extension.cc (test for excess errors) UNRESOLVED: 27_io/filesystem/path/modifiers/replace_extension.cc compilation failed to
[Bug analyzer/96894] Analyzer assumes pointer is NULL, even if pointer was tested to be non-null before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96894 Dmitry G. Dyachenko changed: What|Removed |Added CC||dimhen at gmail dot com --- Comment #2 from Dmitry G. Dyachenko --- gcc version 11.0.0 20210212 (experimental) [master revision 0c27fe96f81:d6ccd7dde1c:8c4137c7ead515baaf1ac8340edeb3a442388b5b] PASS for me
[Bug tree-optimization/92539] [8/9/10/11 Regression] -Warray-bounds false positive with -O3 (loop unroll?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92539 --- Comment #6 from Jeffrey A. Law --- I wonder if we're looking at this the wrong way. We have several blocks with this kind of structure: [local count: 30530247]: if (last_12 != [(void *)"aa" + 3B]) goto ; [54.59%] else goto ; [45.41%] The key point being that the RHS of the conditional is a bogus pointer. Nothing can ever be equal to that pointer. So we should be able to determine the result of the conditional in all those blocks. I suspect that alone is sufficient to make the false positive go away.
[Bug fortran/93787] Rejects non-ambigous specific in generic –
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93787 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-02-14 --- Comment #3 from Dominique d'Humieres --- Confirmed.
[Bug fortran/98408] Character lengths for allocatable character arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98408 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-02-14 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Compiling the test with -Wall gives 2 | character (len=:), allocatable :: a(:) |^ Warning: '.a' is used uninitialized [-Wuninitialized] > Not so much a bug as a 'feature', I'm afraid. Does it mean "another false positive for -Wuninitialized"?
[Bug lto/41565] using -m32 with LTO causes an ICE when the object files were compiled with 64bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41565 Eric Gallager changed: What|Removed |Added Keywords||lto Summary|-m32 causes an ICE when the |using -m32 with LTO causes |object files were compiled |an ICE when the object |with 64bit |files were compiled with ||64bit CC||egallager at gcc dot gnu.org --- Comment #15 from Eric Gallager --- retitling to make a bit clearer
[Bug tree-optimization/99091] constexpr variable evaluated at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99091
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Component|c++ |tree-optimization
--- Comment #1 from Jakub Jelinek ---
I don't see anything wrong on that, the constexpr var is not evaluated at
runtime, it has a constant initializer.
So in the end it is
static const int doy1[] = { 306, 337, 31, 61, 92, 122, 153, 184, 214, 245, 275
};
int foo1(int m) { return doy1[m]; }
int foo2(int m) {
static const int doy2[] = { 306, 337, 31, 61, 92, 122, 153, 184, 214, 245,
275 };
return doy2[m];
}
int foo3(int m) {
const int doy3[] = { 306, 337, 31, 61, 92, 122, 153, 184, 214, 245, 275 };
return doy3[m];
}
and there is nothing C++ specific on it.
The compiler may promote the doy3 variable from automatic variable into static
variable if it can prove
it is safe to do so (it would be unsafe e.g. if foo3 could be called
recursively and compare the addresses of the var between
the recursive invocations). GCC does that early (during gimplification) if the
variable is not address taken, but
the array reference implies address taking. And, especially for the original
testcase where operator[] is overloaded,
it really can't do better early, so we'd need an optimization that would
promote automatic vars to static when possible later (e.g. after inlining) if
it can prove it is safe to do so.
[Bug ada/99095] New: Unconstrained array of limited records results in a bounds bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99095 Bug ID: 99095 Summary: Unconstrained array of limited records results in a bounds bug. Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: rodakay5 at gmail dot com Target Milestone: --- Created attachment 50181 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50181=edit Contains 2 minimal test procedures. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.0 (GCC) $ gnatmake -vh test_bug_box.adb GNATMAKE 10.2.0 Copyright (C) 1992-2020, Free Software Foundation, Inc. "test_bug_box.ali" being checked ... -> "test_bug_box.ali" missing. gcc -c test_bug_box.adb +===GNAT BUG DETECTED==+ | 10.2.0 (x86_64-pc-linux-gnu) Storage_Error stack overflow or erroneous memory access| | Error detected at test_bug_box.adb:16:4 | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). test_bug_box.adb compilation abandoned End of compilation gnatmake: "test_bug_box.adb" compilation error The attached file contains 2 test procedures ... 'Test_Bug_Box' contains code which results in a gnat bug box. The procedure itself prints out no output. 'Test_Buggy_Bounds' builds without a bug box. The expected output is ... a) First => 1 a) Last => 2 b) First => 1 b) Last => 2 The actual output is ... a) First => 1 a) Last =>-1171747055 b) First => 1326201608 b) Last => 32767 The 'a) First' value is always 1. The others values are random. The code contains some commented out lines which I hope are helpful. The problem appears to have been introduced in 'GCC version 10.1.0'. The problem does not occur in GCC 9.3.0 or lower. A (naive) guess might be that the secondary stack pointer becomes corrupted or is wrongly positioned. Regards.
