[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98615

Martin Liška  changed:

   What|Removed |Added

   Assignee|dmalcolm at gcc dot gnu.org|marxin at gcc dot 
gnu.org
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2021-01-11
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I can try to take a look.

[Bug sanitizer/98608] missing sanitizer detection for arrays with invalid length defind using typeof

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98608

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2021-01-11

--- Comment #1 from Martin Liška  ---
Confirmed.
@Marek: Can you please take a look?

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-01-11

--- Comment #1 from Martin Liška  ---
Confirmed.
@Marek: Can you please take a look?

[Bug fortran/64290] [F03] No finalization at deallocation of LHS

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64290

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
Created attachment 49936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49936&action=edit
Initial fix for the PR

Triggered by a recent thread on clf, I have made a first stab at this PR. This
patch is thus far perfect and has the following regressions:

FAIL: gfortran.dg/class_optional_1.f90   -O0  execution test
FAIL: gfortran.dg/dynamic_dispatch_6.f03   -O1  execution test
FAIL: gfortran.dg/finalize_15.f90   -O0  (internal compiler error)
FAIL: gfortran.dg/finalize_25.f90   -O0  execution test
FAIL: gfortran.dg/finalize_29.f08   -O0  execution test
plus
FAIL: gfortran.dg/prof/dynamic_dispatch_6.f03 execution,-fprofile-generate
-D_PROFILE_GENERATE

which is not too bad for a first attempt. Note that for arrays, finalization is
occurring before reallocation of the lhs contrary to the requirements of the
standard.

This test, based on the reporter's testcase, works as intended:
module testmode
  implicit none

  type :: simple
integer :: ind
  contains
final :: destruct1, destruct2
  end type simple

  integer :: check_scalar
  integer :: check_array(2)
  integer :: final_count = 0

contains

  subroutine destruct1(self)
type(simple), intent(inout) :: self

!print *, "DESTRUCTING SCALAR", self%ind
check_scalar = self%ind
check_array = 0
final_count = final_count + 1

  end subroutine destruct1

  subroutine destruct2(self)
type(simple), intent(inout) :: self(:)

!print *, "DESTRUCTING ARRAY", self%ind
check_scalar = 0
check_array = self%ind
final_count = final_count + 1

  end subroutine destruct2

  subroutine test (cnt, scalar, array, off)
integer :: cnt
integer :: scalar
integer :: array(:)
integer :: off
if (final_count .ne. cnt) stop 1 + off
if (check_scalar .ne. scalar) stop 2 + off
if (any (check_array .ne. array)) stop 3 + off
  end subroutine test

end module testmode

program test_final
  use testmode
  implicit none

  type(simple), allocatable :: myres, myres2
  type(simple), allocatable :: myarray(:)
  type(simple) :: thyres = simple(21), thyres2 = simple(22)

  allocate(myres)
  allocate(myres2)
  myres%ind = 1
  myres2%ind = 2
  myres = myres2
  call test(1, 1, [0,0], 10)

  allocate(myarray(2))
  myarray%ind = [42, 43]
  myarray = [thyres, thyres2]
  call test(2, 0, [42,43], 20)

  thyres2 = simple(99)
  call test(3, 22, [0,0], 30)

  thyres = thyres2
  call test(4, 21, [0,0], 40)

  deallocate (myres, myres2)
  call test(6, 2, [0,0], 100)

  deallocate (myarray)
  call test(7, 0, [21,22], 200)

end program test_final

Paul

[Bug c++/98611] [concepts] ICE in get_underlying_template, at cp/pt.c:6494 since r10-3735-gcb57504a55015891

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98611

Martin Liška  changed:

   What|Removed |Added

Summary|[concepts] internal |[concepts] ICE in
   |compiler error: in  |get_underlying_template, at
   |get_underlying_template, at |cp/pt.c:6494 since
   |cp/pt.c:6494|r10-3735-gcb57504a55015891
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r10-3735-gcb57504a55015891.

[Bug gcov-profile/98273] GCOV intermediate format is wrong when lambda functions (or nested functions) are used

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98273

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:4e275dccfc2467b3fe39012a3dd2a80bac257dd0

commit r11-6577-g4e275dccfc2467b3fe39012a3dd2a80bac257dd0
Author: Martin Liska 
Date:   Mon Dec 21 09:14:28 2020 +0100

Add pytest for a GCOV test-case

gcc/testsuite/ChangeLog:

PR gcov-profile/98273
* lib/gcov.exp: Add run-gcov-pytest function which runs pytest.
* g++.dg/gcov/pr98273.C: New test.
* g++.dg/gcov/gcov.py: New test.
* g++.dg/gcov/test-pr98273.py: New test.

[Bug target/98478] AVX512 refactoring integer mask with VnBImode

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98478

--- Comment #1 from Hongtao.liu  ---
according to sve-ieee-micro-2017.pdf predicate registers is 

Each predicate consists ofeight enable bits per 64-bit vector element, allowing
down to per byte-granularity. For any given element size only the
least significant bit is used as the enable. This is important
for vectorizing code containing multiple data types

predicates register are much more like vector mask in avx2, but not integer
mask in avx512.

[Bug target/98478] AVX512 refactoring integer mask with VnBImode

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98478

--- Comment #2 from Hongtao.liu  ---
> predicates register are much more like vector mask in avx2, but not integer
> mask in avx512.

So avx512 integer mask may not suitable to be represented by VnBImode.

[Bug objc++/98606] [10 regression] obj-c++.dg/template-4.mm fails erratically

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98606

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.3

[Bug c++/98611] [concepts] ICE in get_underlying_template, at cp/pt.c:6494 since r10-3735-gcb57504a55015891

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98611

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Does GCC9 work?

[Bug target/98612] _mm_comieq_sd has wrong semantics

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98612

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||uros at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
I guess some people might think intrinsics map to the underlying instruction
...
to me the intrinsics guide isn't sufficiently clear on the semantics.

[Bug c++/98611] [concepts][10/11 Regression] ICE in get_underlying_template, at cp/pt.c:6494 since r10-3735-gcb57504a55015891

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98611

Martin Liška  changed:

   What|Removed |Added

Summary|[concepts] ICE in   |[concepts][10/11
   |get_underlying_template, at |Regression] ICE in
   |cp/pt.c:6494 since  |get_underlying_template, at
   |r10-3735-gcb57504a55015891  |cp/pt.c:6494 since
   ||r10-3735-gcb57504a55015891

--- Comment #4 from Martin Liška  ---
(In reply to Richard Biener from comment #3)
> Does GCC9 work?

Yes.

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609

--- Comment #2 from Jakub Jelinek  ---
The sanitizers generally diagnose what the C or C++ language spec say, not what
the various extensions allow, it is the same also for shifts etc.
So I think it is correct that this is diagnosed by default.

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

[muecker at gwdg dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609

--- Comment #3 from Martin Uecker  ---
Fair enough. But there is also no way to selectively turn it off (or I am not
aware of it).  The warning for < 0 is important and useful while the warning
for == 0 is pedantic and not useful by itself when we generally allow zero
sized arrays elsewhere.

[Bug tree-optimization/98598] Missed opportunity to optimize dependent loads in loops

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98598

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #9 from Hongtao.liu  ---
It looks like a SOA/AOC opt opportunity which is discussed in
https://gcc.gnu.org/wiki/cauldron2015?action=AttachFile&do=view&target=Olga+Golovanevsky_+Memory+Layout+Optimizations+of+Structures+and+Objects.pdf

And i remember there's someone working on enabling SOA/AOS opt in GCC.

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609

--- Comment #4 from Jakub Jelinek  ---
I'd say it is similar with shifts, the diagnostics about the shift count being
negative or too large is highly useful, the diagnostics about the various
lshift properties shifting into sign bit or shifting left negative values etc.)
are pedantic, at least GCC doesn't really take any advantage of that, because
there are so many different variants of the restrictions.
But for shifts we indeed do have a way to selectively turn one or the other on
or off.
So perhaps -fsanitize=vla can be a union of two subooptions too.
Though, we can't really do anything about this until upstream libsanitizer is
changed, because the diagnostics comes from that library.
And it would be really confusing to just do this on the GCC side, allow
VLA checks of <= 0 (=vla), < 0 (=vla-negative), == 0 (=vla-zero) and use the
same library routine in all cases that would always talk about non-positive
value.

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609

--- Comment #5 from Martin Liška  ---
I would recommend changing just libsanitizer to allow something like
UBSAN_OPTIONS=vla_bounds_allow_zero=1. Should be relatively small change.

[Bug target/98478] AVX512 refactoring integer mask with VnBImode

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98478

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
If the selftests are the only problem, I don't see a reason why the self-test
shouldn't be skipped for V*BImode or perhaps skipped for V*BImode with some
extra conditions.
E.g. skip the test if the scalar mode doesn't have mov_optab insn?
 static void
 test_vector_ops ()
 {
   for (unsigned int i = 0; i < NUM_MACHINE_MODES; ++i)
 {
   machine_mode mode = (machine_mode) i;
-  if (VECTOR_MODE_P (mode))
+  if (VECTOR_MODE_P (mode)
+  && optab_handler (mov_optab, GET_MODE_INNER (mode)) !=
CODE_FOR_nothing)
?
I mean, simplify-rtx.c will not really try to do the VEC_SELECT etc.
simplifications on V*BImode if
something like that isn't present in the IL before the simplification, and I
seriously doubt it can
appear there when one even can't have a BImode pseudo and move it around.

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609

--- Comment #6 from Jakub Jelinek  ---
That is not really possible, as the compiler assumes for
-fno-sanitize-recover=vla that when we call the library routine, it never
returns (it is noreturn).

[Bug tree-optimization/95852] Failure to optimize __builtin_mul_overflow pattern

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95852

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:a2106317cd6673e110b347c70f21e25fbb23379e

commit r11-6579-ga2106317cd6673e110b347c70f21e25fbb23379e
Author: Jakub Jelinek 
Date:   Mon Jan 11 10:32:07 2021 +0100

widening_mul: Pattern recognize unsigned multiplication with overflow check
[PR95852]

The following patch pattern recognizes some forms of multiplication
followed
by overflow check through division by one of the operands compared to the
other one, with optional removal of guarding non-zero check for that
operand
if possible.  The patterns are replaced with effectively
__builtin_mul_overflow or __builtin_mul_overflow_p.  The testcases cover 64
different forms of that.

2021-01-11  Jakub Jelinek  

PR tree-optimization/95852
* tree-ssa-math-opts.c (maybe_optimize_guarding_check): New
function.
(uaddsub_overflow_check_p): Renamed to ...
(arith_overflow_check_p): ... this.  Handle also multiplication
with overflow check.
(match_uaddsub_overflow): Renamed to ...
(match_arith_overflow): ... this.  Add cfg_changed argument. 
Handle
also multiplication with overflow check.  Adjust function comment.
(math_opts_dom_walker::after_dom_children): Adjust callers.  Call
match_arith_overflow also for MULT_EXPR.

* gcc.target/i386/pr95852-1.c: New test.
* gcc.target/i386/pr95852-2.c: New test.

[Bug tree-optimization/95852] Failure to optimize __builtin_mul_overflow pattern

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95852

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:9febe9e4be7812519258ea3ed4f38bbc1a61624b

commit r11-6580-g9febe9e4be7812519258ea3ed4f38bbc1a61624b
Author: Jakub Jelinek 
Date:   Mon Jan 11 10:34:07 2021 +0100

widening_mul: Pattern recognize also signed multiplication with overflow
check [PR95852]

On top of the previous widening_mul patch, this one recognizes also
(non-perfect) signed multiplication with overflow, like:
int
f5 (int x, int y, int *res)
{
  *res = (unsigned) x * y;
  return x && (*res / x) != y;
}
The problem with such checks is that they invoke UB if x is -1 and
y is INT_MIN during the division, but perhaps the code knows that
those values won't appear.  As that case is UB, we can do for that
case whatever we want and handling that case as signed overflow
is the best option.  If x is a constant not equal to -1, then the checks
are 100% correct though.
Haven't tried to pattern match bullet-proof checks, because I really don't
know if users would write it in real-world code like that,
perhaps
  *res = (unsigned) x * y;
  return x && (x == -1 ? (*res / y) != x : (*res / x) != y);
?

   
https://wiki.sei.cmu.edu/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow
suggests to use twice as wide multiplication (perhaps we should handle that
too, for both signed and unsigned), or some very large code
with 4 different divisions nested in many conditionals, no way one can
match all the possible variants thereof.

2021-01-11  Jakub Jelinek  

PR tree-optimization/95852
* tree-ssa-math-opts.c (maybe_optimize_guarding_check): Change
mul_stmts parameter type to vec &.  Before cond_stmt
allow in the bb any of the stmts in that vector, div_stmt and
up to 3 cast stmts.
(arith_cast_equal_p): New function.
(arith_overflow_check_p): Add cast_stmt argument, handle signed
multiply overflow checks.
(match_arith_overflow): Adjust caller.  Handle signed multiply
overflow checks.

* gcc.target/i386/pr95852-3.c: New test.
* gcc.target/i386/pr95852-4.c: New test.

[Bug tree-optimization/95867] Failure to optimize successive multiplications of ___uint128_t

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95867

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:9a6c37e6ae520534993ef76dd45d016c8c86db21

commit r11-6581-g9a6c37e6ae520534993ef76dd45d016c8c86db21
Author: Jakub Jelinek 
Date:   Mon Jan 11 10:35:10 2021 +0100

reassoc: Reassociate integral multiplies [PR95867]

For floating point multiply, we have nice code in reassoc to reassociate
multiplications to almost optimal sequence of as few multiplications as
possible (or library call), but for integral types we just give up
because there is no __builtin_powi* for those types.

As there is no library routine we could use, instead of adding new internal
call just to hold it temporarily and then lower to multiplications again,
this patch for the integral types calls into the sincos pass routine that
expands it into multiplications right away.

2021-01-11  Jakub Jelinek  

PR tree-optimization/95867
* tree-ssa-math-opts.h: New header.
* tree-ssa-math-opts.c: Include tree-ssa-math-opts.h.
(powi_as_mults): No longer static.  Use build_one_cst instead of
build_real.  Formatting fix.
* tree-ssa-reassoc.c: Include tree-ssa-math-opts.h.
(attempt_builtin_powi): Handle multiplication reassociation without
powi_fndecl using powi_as_mults.
(reassociate_bb): For integral types don't require
-funsafe-math-optimizations to call attempt_builtin_powi.

* gcc.dg/tree-ssa/pr95867.c: New test.

[Bug tree-optimization/95852] Failure to optimize __builtin_mul_overflow pattern

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95852

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 95852, which changed state.

Bug 95852 Summary: Failure to optimize __builtin_mul_overflow pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95852

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/95867] Failure to optimize successive multiplications of ___uint128_t

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95867

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 95867, which changed state.

Bug 95867 Summary: Failure to optimize successive multiplications of 
___uint128_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95867

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609

--- Comment #7 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #6)
> That is not really possible, as the compiler assumes for
> -fno-sanitize-recover=vla

which is not the default value/

> that when we call the library routine, it never
> returns (it is noreturn).

Then it can be allowed only for recover UBSAN entry points.

[Bug bootstrap/98414] [11 Regression] UBSAN bootstrap is broken: ubsan/ubsan_type_hash_itanium.cpp:162: undefined reference to `__dynamic_cast' since r11-6083-gb7dfc2074c78415d451eb34d1608016c80b1c41a

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98414

--- Comment #11 from Martin Liška  ---
There's a self-container test-case:

$ cat resolver.ii
class Resolver {
  int GetCMIName();
  virtual char GetCMISuffix() { return 'c'; }
};
int Resolver::GetCMIName() { GetCMISuffix(); return 0; }

int main() {}

$ -static-libstdc++ -static-libgcc -fsanitize=undefined -static-libubsan
[fine]

$ g++ -fsanitize=undefined resolver.ii -static-libstdc++ -static-libubsan
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/usr/lib64/gcc/x86_64-suse-linux/10/libubsan.a(ubsan_type_hash_itanium.o): in
function `findBaseAtOffset(__cxxabiv1::__class_type_info const*, long)':
/home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1030/obj-x86_64-suse-linux/x86_64-suse-linux/libsanitizer/ubsan/../../../../libsanitizer/ubsan/ubsan_type_hash_itanium.cpp:161:
undefined reference to `__dynamic_cast'
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1030/obj-x86_64-suse-linux/x86_64-suse-linux/libsanitizer/ubsan/../../../../libsanitizer/ubsan/ubsan_type_hash_itanium.cpp:165:
undefined reference to `typeinfo for __cxxabiv1::__vmi_class_type_info'
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1030/obj-x86_64-suse-linux/x86_64-suse-linux/libsanitizer/ubsan/../../../../libsanitizer/ubsan/ubsan_type_hash_itanium.cpp:165:
undefined reference to `__dynamic_cast'
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/usr/lib64/gcc/x86_64-suse-linux/10/libubsan.a(ubsan_type_hash_itanium.o): in
function `isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*,
__cxxabiv1::__class_type_info const*, long)':
/home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1030/obj-x86_64-suse-linux/x86_64-suse-linux/libsanitizer/ubsan/../../../../libsanitizer/ubsan/ubsan_type_hash_itanium.cpp:124:
undefined reference to `__dynamic_cast'
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1030/obj-x86_64-suse-linux/x86_64-suse-linux/libsanitizer/ubsan/../../../../libsanitizer/ubsan/ubsan_type_hash_itanium.cpp:128:
undefined reference to `typeinfo for __cxxabiv1::__vmi_class_type_info'
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1030/obj-x86_64-suse-linux/x86_64-suse-linux/libsanitizer/ubsan/../../../../libsanitizer/ubsan/ubsan_type_hash_itanium.cpp:128:
undefined reference to `__dynamic_cast'
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/usr/lib64/gcc/x86_64-suse-linux/10/libubsan.a(ubsan_type_hash_itanium.o): in
function `__ubsan::checkDynamicType(void*, void*, unsigned long)':
/home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1030/obj-x86_64-suse-linux/x86_64-suse-linux/libsanitizer/ubsan/../../../../libsanitizer/ubsan/ubsan_type_hash_itanium.cpp:231:
undefined reference to `__dynamic_cast'
collect2: error: ld returned 1 exit status

[Bug bootstrap/98414] [11 Regression] UBSAN bootstrap is broken: ubsan/ubsan_type_hash_itanium.cpp:162: undefined reference to `__dynamic_cast' since r11-6083-gb7dfc2074c78415d451eb34d1608016c80b1c41a

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98414

--- Comment #12 from Martin Liška  ---
I've got it!
It can be fixed with -fno-rtti and apparently libcody's objects do miss that :)

[Bug bootstrap/98414] [11 Regression] UBSAN bootstrap is broken: ubsan/ubsan_type_hash_itanium.cpp:162: undefined reference to `__dynamic_cast' since r11-6083-gb7dfc2074c78415d451eb34d1608016c80b1c41a

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98414

--- Comment #13 from Jakub Jelinek  ---
Well, that is a fix for the bootstrap-ubsan issues, but not the above small
testcase showing the problems for users.
But sure, as this is a problem that exists many years and nobody reported it
before, it is enough to fix just the bootstrap-ubsan stuff for GCC 11.

[Bug tree-optimization/98526] [11 Regression] Double-counting of reduction cost

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98526

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

[Bug bootstrap/98414] [11 Regression] UBSAN bootstrap is broken: ubsan/ubsan_type_hash_itanium.cpp:162: undefined reference to `__dynamic_cast' since r11-6083-gb7dfc2074c78415d451eb34d1608016c80b1c41a

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98414

--- Comment #14 from Martin Liška  ---
When building GCC w/o bootstrap I see that libcody properly sets -fno-rtti:

g++ -std=c++11 -g -O2 -fno-enforce-eh-specs -fno-stack-protector
-fno-threadsafe-statics -fno-exceptions -fno-rtti
-fdebug-prefix-map=/home/marxin/Programming/gcc/libcody/= -W -Wall -include
config.h -I/home/marxin/Programming/gcc/libcody \
  -MMD -MP -MF packet.d -c -o packet.o
/home/marxin/Programming/gcc/libcody/packet.cc

But it's not true for --with-build-config=bootstrap-ubsan in stage2:

/home/mliska/Programming/gcc/objdir/./prev-gcc/xg++
-B/home/mliska/Programming/gcc/objdir/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu

-I/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
 -I/home/mliska/Programming/gcc/libstdc++-v3/libsupc++
-L/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-g -O2 -fno-checking -fsanitize=undefined -DUBSAN_BOOTSTRAP -include config.h
-I../../libcody
-I/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/mliska/Programming/gcc/libstdc++-v3/libsupc++ \
  -MMD -MP -MF packet.d -c -o packet.o ../../libcody/packet.cc

while other gcc/*.o objects have -fno-rtti:

/home/mliska/Programming/gcc/objdir/./prev-gcc/xg++
-B/home/mliska/Programming/gcc/objdir/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu

-I/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
 -I/home/mliska/Programming/gcc/libstdc++-v3/libsupc++
-L/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c   -g -O2 -fno-checking -fsanitize=undefined -DUBSAN_BOOTSTRAP 
-DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I.
-I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I../../gcc/../libcpp/include -I../../gcc/../libcody 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/../libbacktrace   -o ipa-icf.o -MT ipa-icf.o -MMD -MP -MF
./.deps/ipa-icf.TPo ../../gcc/ipa-icf.c

[Bug bootstrap/98414] [11 Regression] UBSAN bootstrap is broken: ubsan/ubsan_type_hash_itanium.cpp:162: undefined reference to `__dynamic_cast' since r11-6083-gb7dfc2074c78415d451eb34d1608016c80b1c41a

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98414

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #15 from Martin Liška  ---
I have a fix :)

[Bug tree-optimization/98560] [11 Regression] gimple-isel ICE with folded condition

[rsandifo at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98560

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Fixed by r11-6517 and r11-6518.

[Bug tree-optimization/98526] [11 Regression] Double-counting of reduction cost

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98526

--- Comment #2 from Richard Biener  ---
Created attachment 49937
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49937&action=edit
patch

Sth like this.  But I'm somewhat confused about the partial vector code in the
"else" branch:

  /* All but single defuse-cycle optimized, lane-reducing and fold-left
 reductions go through their own vectorizable_* routines.  */
  if (!single_defuse_cycle
  && code != DOT_PROD_EXPR
  && code != WIDEN_SUM_EXPR
  && code != SAD_EXPR
  && reduction_type != FOLD_LEFT_REDUCTION)
{
  stmt_vec_info tem
= vect_stmt_to_vectorize (STMT_VINFO_REDUC_DEF (phi_info));
  if (slp_node && REDUC_GROUP_FIRST_ELEMENT (tem))
{
  gcc_assert (!REDUC_GROUP_NEXT_ELEMENT (tem));
  tem = REDUC_GROUP_FIRST_ELEMENT (tem);
}
  STMT_VINFO_DEF_TYPE (vect_orig_stmt (tem)) = vect_internal_def;
  STMT_VINFO_DEF_TYPE (tem) = vect_internal_def;
}
  else if (loop_vinfo && LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo))
{
  vec_loop_masks *masks = &LOOP_VINFO_MASKS (loop_vinfo);

why is this only relevant when we go via vect_transform_reduction?  This looks
like a bit like a misplaced bunch of checks?

Anyway, will test the attached.

[Bug tree-optimization/98526] [10/11 Regression] Double-counting of reduction cost

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98526

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|11.0|10.3
Summary|[11 Regression] |[10/11 Regression]
   |Double-counting of  |Double-counting of
   |reduction cost  |reduction cost

--- Comment #3 from Richard Biener  ---
Also affects the GCC 10 branch.

[Bug target/98618] New: aarch64: oob adrp offset causes relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21

[nsz at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98618

Bug ID: 98618
   Summary: aarch64: oob adrp offset causes relocation truncated
to fit: R_AARCH64_ADR_PREL_PG_HI21
   Product: gcc
   Version: 8.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

gcc-8 and earlier can generate adrp with out of bounds offset
for hidden and local symbols.

i haven't yet found the change that fixed this in gcc-9.

this affects glibc since
https://sourceware.org/git/?p=glibc.git;a=commit;h=2f056e8a5dd4dc0f075413f931e82cede37d1057

$ cat bug.c
long n;
struct s { long a[100]; };
extern struct s obj __attribute__((visibility("hidden")));
void foo()
{
  long *a = obj.a;
  a[n - 0x7000 + 35] = n;
  a[0x6dff - n + 35 + 6 + 16 + 3] = n;
}

$ gcc -fPIC -O2 -c bug.c
$ objdump -rd bug.o

bug.o: file format elf64-littleaarch64


Disassembly of section .text:

 :
   0:   9000adrpx0, 8 
0: R_AARCH64_ADR_GOT_PAGE   n
   4:   9002adrpx2, 0 
4: R_AARCH64_ADR_PREL_PG_HI21   obj-0x37ee8
   8:   9142add x2, x2, #0x0
8: R_AARCH64_ADD_ABS_LO12_NCobj-0x37ee8
   c:   9001adrpx1, 0 
c: R_AARCH64_ADR_PREL_PG_HI21   obj+0x371d8
  10:   f940ldr x0, [x0]
10: R_AARCH64_LD64_GOT_LO12_NC  n
  14:   9121add x1, x1, #0x0
14: R_AARCH64_ADD_ABS_LO12_NC   obj+0x371d8
  18:   f940ldr x0, [x0]
  1c:   cb000fe3neg x3, x0, lsl #3
  20:   f8207840str x0, [x2, x0, lsl #3]
  24:   f8216860str x0, [x3, x1]
  28:   d65f03c0ret
$ gcc -shared bug.o obj.o
bug.o: In function `foo':
bug.c:(.text+0x4): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21
against symbol `obj' defined in .data section in obj.o
bug.c:(.text+0xc): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21
against symbol `obj' defined in .data section in obj.o
collect2: error: ld returned 1 exit status

[Bug tree-optimization/98221] [10 regression] Wrong unpack operation emitted in tree-ssa-forwprop.c

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|[10/11 regression] Wrong|[10 regression] Wrong
   |unpack operation emitted in |unpack operation emitted in
   |tree-ssa-forwprop.c |tree-ssa-forwprop.c
  Known to work||11.0
 Ever confirmed|0   |1
   Last reconfirmed||2021-01-11
 Status|UNCONFIRMED |ASSIGNED

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.

commit 300a3ce5c5695eb1a7c0476e9d1b45420a463248 (HEAD -> trunk, origin/master,
o
rigin/HEAD)
Author: Andreas Krebbel 
Date:   Mon Jan 11 10:59:43 2021 +0100

tree-optimization/98221 - fix wrong unpack operation used for big-endian

The vec-abi-varargs-1.c testcase on IBM Z currently fails.

While adding an SI mode vector to a DI mode vector the first is unpacked
using:

  _28 = BIT_INSERT_EXPR <{ 0, 0, 0, 0 }, _2, 0>;
  _34 = [vec_unpack_lo_expr] _28;

However, on big endian targets lo refers to the right hand side of the
vector - in this case the zeroes.

2021-01-11  Andreas Krebbel  

* tree-ssa-forwprop.c (simplify_vector_constructor): For
big-endian, use UNPACK[_FLOAT]_HI.

[Bug bootstrap/98414] [11 Regression] UBSAN bootstrap is broken: ubsan/ubsan_type_hash_itanium.cpp:162: undefined reference to `__dynamic_cast' since r11-6083-gb7dfc2074c78415d451eb34d1608016c80b1c41a

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98414

Martin Liška  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |nathan at gcc dot 
gnu.org

--- Comment #16 from Martin Liška  ---
Based on Jakub's review, leading that to Nathan.

[Bug target/98618] aarch64: oob adrp offset causes relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21

[fw at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98618

--- Comment #1 from Florian Weimer  ---
Is the test case really valid? It involves an out-of-bounds array access, after
all.

[Bug target/98618] aarch64: oob adrp offset causes relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21

[nsz at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98618

--- Comment #2 from nsz at gcc dot gnu.org ---
(In reply to Florian Weimer from comment #1)
> Is the test case really valid? It involves an out-of-bounds array access,
> after all.

no it doesn't, n is signed long and its value can be such that the access is in
bounds (and that's what the compiler must assume, so adrp must be anchored
accordingly).

[Bug tree-optimization/96834] [9/10/11 Regression] Segmentation fault signal terminated program cc1

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96834

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #8 from Richard Biener  ---
duplicate

*** This bug has been marked as a duplicate of bug 91403 ***

[Bug tree-optimization/91403] GCC fails with ICE.

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91403

Richard Biener  changed:

   What|Removed |Added

 CC||duanbo3 at huawei dot com

--- Comment #6 from Richard Biener  ---
*** Bug 96834 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 96834, which changed state.

Bug 96834 Summary: [9/10/11 Regression] Segmentation fault signal terminated 
program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96834

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

[Bug tree-optimization/91403] GCC fails with ICE.

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91403

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #7 from Richard Biener  ---
We can put a baind-aid in like for PR78699.

[Bug tree-optimization/98526] [10/11 Regression] Double-counting of reduction cost

[rsandifo at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98526

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #2)
> Created attachment 49937 [details]
> patch
> 
> Sth like this.  But I'm somewhat confused about the partial vector code in
> the
> "else" branch:
> 
>   /* All but single defuse-cycle optimized, lane-reducing and fold-left
>  reductions go through their own vectorizable_* routines.  */
>   if (!single_defuse_cycle
>   && code != DOT_PROD_EXPR
>   && code != WIDEN_SUM_EXPR
>   && code != SAD_EXPR
>   && reduction_type != FOLD_LEFT_REDUCTION)
> {
>   stmt_vec_info tem
> = vect_stmt_to_vectorize (STMT_VINFO_REDUC_DEF (phi_info));
>   if (slp_node && REDUC_GROUP_FIRST_ELEMENT (tem))
> {
>   gcc_assert (!REDUC_GROUP_NEXT_ELEMENT (tem));
>   tem = REDUC_GROUP_FIRST_ELEMENT (tem);
> }
>   STMT_VINFO_DEF_TYPE (vect_orig_stmt (tem)) = vect_internal_def;
>   STMT_VINFO_DEF_TYPE (tem) = vect_internal_def;
> }
>   else if (loop_vinfo && LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo))
> {
>   vec_loop_masks *masks = &LOOP_VINFO_MASKS (loop_vinfo);
> 
> why is this only relevant when we go via vect_transform_reduction?  This
> looks
> like a bit like a misplaced bunch of checks?
The code predates the rework of reductions, so it might not
be written in the most natural way for the current structure.
But the idea is that the analysis phase of each vectorizable_*
routine should do its own CAN_USE_PARTIAL_VECTORS_P checks,
based on what it needs to do during the transform phase.
So vectorizable_reduction should only test the stuff that the
vect_transform_reduction and the epilogue code need.

[Bug tree-optimization/98598] Missed opportunity to optimize dependent loads in loops

[jiangning.liu at amperecomputing dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98598

--- Comment #10 from Jiangning Liu  
---
(In reply to Hongtao.liu from comment #9)
> It looks like a SOA/AOC opt opportunity which is discussed in
> https://gcc.gnu.org/wiki/
> cauldron2015?action=AttachFile&do=view&target=Olga+Golovanevsky_+Memory+Layou
> t+Optimizations+of+Structures+and+Objects.pdf
> 
> And i remember there's someone working on enabling SOA/AOS opt in GCC.

No. The key difference is the optimization opportunity here doesn't rely on LTO
at all. It is purely a local optimization within a function instead.

[Bug target/98618] aarch64: oob adrp offset causes relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21

[wilco at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98618

Wilco  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||wilco at gcc dot gnu.org
   Last reconfirmed||2021-01-11
 Status|UNCONFIRMED |NEW

--- Comment #3 from Wilco  ---
I fixed this in GCC10:
https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=7d3b27ff12610fde9d6c4b56abc70c6ee9b6b3db

So this just needs to be backported.

[Bug tree-optimization/98526] [10/11 Regression] Double-counting of reduction cost

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98526

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:04bff1bbfc11a974342c0eb0c0d65d902e36e82e

commit r11-6587-g04bff1bbfc11a974342c0eb0c0d65d902e36e82e
Author: Richard Biener 
Date:   Mon Jan 11 11:47:46 2021 +0100

tree-optimization/98526 - fix vectorizer reduction cost

This fixes a double-counting in the reduction cost when vectorizing
the reduction through the regular vectorizable_* functions.

2021-01-11  Richard Biener  

PR tree-optimization/98526
* tree-vect-loop.c (vect_model_reduction_cost): Remove costing
of the actual reduction op for the regular case.
(vectorizable_reduction): Cost the stmts
vect_transform_reduction produces here.

[Bug rtl-optimization/98619] New: aarch64: ICE (verify_flow_info failed)

[acoplan at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98619

Bug ID: 98619
   Summary: aarch64: ICE (verify_flow_info failed)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ cat test.c
int a() {
  int *b;
  asm goto("" : "=mk"(b) : : : c);
d:
c:
}
$ aarch64-elf-gcc -c test.c
test.c: In function 'a':
test.c:6:1: error: too many outgoing branch edges from bb 2
6 | }
  | ^
during RTL pass: reload
test.c:6:1: internal compiler error: verify_flow_info failed
0x897451 verify_flow_info()
/home/alecop01/toolchain/src/gcc/gcc/cfghooks.c:269
0xcd9d55 execute_function_todo
/home/alecop01/toolchain/src/gcc/gcc/passes.c:2054
0xcd9e80 do_per_function
/home/alecop01/toolchain/src/gcc/gcc/passes.c:1687
0xcda01b execute_todo
/home/alecop01/toolchain/src/gcc/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/98598] Missed opportunity to optimize dependent loads in loops

[jiangning.liu at amperecomputing dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98598

--- Comment #11 from Jiangning Liu  
---
(In reply to rguent...@suse.de from comment #8)
> On Sat, 9 Jan 2021, jiangning.liu at amperecomputing dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98598
> > 
> > --- Comment #7 from Jiangning Liu  > com> ---
> > (In reply to rguent...@suse.de from comment #6)
> > > On January 9, 2021 4:17:17 AM GMT+01:00, "jiangning.liu at amperecomputing
> > > dot com"  wrote:
> > > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98598
> > > >
> > > >--- Comment #5 from Jiangning Liu  > > >com> ---
> > > >> It has to be done with care of course, cost modeling is difficult
> > > >> (we need to have a good estimate of n and m or need to version
> > > >> the whole nest).  That said, usually we attempt the reverse
> > > >transform.
> > > >
> > > >Before tuning the cost model good enough, we may implement this
> > > >optimization by
> > > >adding a new optimization command line option. This won't hurt gcc,
> > > >right?
> > > 
> > > New options not enabled by default tend to bitrot, be broken from the 
> > > start
> > > and won't be used by the lazy user. So I see no point in doing that. 
> > > 
> > 
> > Understand. I mean we can enable it by default eventually, but we need to
> > implement and tune it step by step. It is unrealistic to work out the best 
> > cost
> > model at the very beginning.
> 
> Sure.  The "easiest" thing is to rely on a profile from PGO, we did
> have some transforms only enabled by -fprofile-use by default.  That is,
> the cost model needs to be conservative, esp. if you introduce dynamic
> allocation for this.  In the end I guess only a variant that versions
> the nest on the size of the temporary will be good enough to not trigger
> OOM or excessive overhead for small sizes anyway.

People usually don't use PGO unless they can't find any better static compiler
switches. This optimization should always benefit performance if we can tune
the cost model good enough. It is true that the temp memory size needs to be
checked to avoid OOM, which is one of the runtime overheads.

[Bug rtl-optimization/98619] aarch64: ICE (verify_flow_info failed)

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98619

--- Comment #1 from Richard Biener  ---
We might be able to CFG cleanup this to a non-goto asm [unless the 'goto'
invokes
semantic differences elsewhere]

[Bug target/98618] aarch64: oob adrp offset causes relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21

[nsz at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98618

--- Comment #4 from nsz at gcc dot gnu.org ---
(In reply to Florian Weimer from comment #1)
> Is the test case really valid? It involves an out-of-bounds array access,
> after all.

sorry you are right the indexes are too far, a better test is

long n;
struct s { long a[100]; };
extern struct s obj __attribute__((visibility("hidden")));
void foo()
{
  long *a = obj.a;
  a[n - 0x7000] = n;
  a[0x7000 - n + 99] = n;
}

(i wanted to have an example with both + and - offset)
it compiles to

foo:
adrpx0, :got:n
adrpx2, obj-15032385536
add x2, x2, :lo12:obj-15032385536
adrpx1, obj+15032386328
ldr x0, [x0, #:got_lo12:n]
add x1, x1, :lo12:obj+15032386328
ldr x0, [x0]
neg x3, x0, lsl 3
str x0, [x2, x0, lsl 3]
str x0, [x3, x1]
ret

[Bug target/98618] aarch64: oob adrp offset causes relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21

[nsz at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98618

--- Comment #5 from nsz at gcc dot gnu.org ---
(In reply to Wilco from comment #3)
> I fixed this in GCC10:
> https://gcc.gnu.org/git/?p=gcc.git&a=commit;
> h=7d3b27ff12610fde9d6c4b56abc70c6ee9b6b3db
> 
> So this just needs to be backported.

thanks, i'll try that, i'm still looking for
a simple workaround in glibc, this affects
this code in elf_get_dynamic_info:

...
  63   else if ((d_tag_utype) DT_VERSIONTAGIDX (dyn->d_tag) <
DT_VERSIONTAGNUM)
  64 info[VERSYMIDX (dyn->d_tag)] = dyn;
  65   else if ((d_tag_utype) DT_EXTRATAGIDX (dyn->d_tag) < DT_EXTRANUM)
  66 info[DT_EXTRATAGIDX (dyn->d_tag) + DT_NUM + DT_THISPROCNUM
  67  + DT_VERSIONTAGNUM] = dyn;
  68   else if ((d_tag_utype) DT_VALTAGIDX (dyn->d_tag) < DT_VALNUM)
  69 info[DT_VALTAGIDX (dyn->d_tag) + DT_NUM + DT_THISPROCNUM
  70  + DT_VERSIONTAGNUM + DT_EXTRANUM] = dyn;
  71   else if ((d_tag_utype) DT_ADDRTAGIDX (dyn->d_tag) < DT_ADDRNUM)
  72 info[DT_ADDRTAGIDX (dyn->d_tag) + DT_NUM + DT_THISPROCNUM
  73  + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
...

[Bug middle-end/85811] Invalid optimization with fmax, fabs and nan

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85811

--- Comment #12 from Richard Biener  ---
Possibly could be backported even if not a regression but I guess the
wrong-code is really restricted to cases we don't hit in the wild.

That said, not objecting if anybody wants to backport to GCC 10.

[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225

--- Comment #19 from CVS Commits  ---
The master branch has been updated by Bernd Edlinger :

https://gcc.gnu.org/g:6ebf79fcd4cfb43353e6a000f700b07295e78026

commit r11-6588-g6ebf79fcd4cfb43353e6a000f700b07295e78026
Author: Bernd Edlinger 
Date:   Thu Jan 7 09:37:32 2021 +0100

testsuite: Fix test failures from outputs.exp [PR98225]

The .ld1_args file is not created when HAVE_GNU_LD is false.
The ltrans0.ltrans_arg file is not created when the make jobserver
is available, so remove the MAKEFLAGS variable.
Add an exception for *.gcc_args files similar to the
exception for *.cdtor.* files.
Limit both exceptions to targets that define EH_FRAME_THROUGH_COLLECT2.
That means although the test case does not use C++ constructors
or destructors it is still using dwarf2 frame info.

2021-01-11  Bernd Edlinger  

PR testsuite/98225
* gcc.misc-tests/outputs.exp: Unset MAKEFLAGS.
Expect .ld1_args only when GNU LD is used.
Add an exception for *.gcc_args files.

[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL

[edlinger at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225

Bernd Edlinger  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #20 from Bernd Edlinger  ---
should be fixed now.

Thanks!

[Bug tree-optimization/91403] GCC fails with ICE.

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91403

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:84684e0f78c20c51492722a5b95cda778ad77073

commit r11-6589-g84684e0f78c20c51492722a5b95cda778ad77073
Author: Richard Biener 
Date:   Mon Jan 11 12:04:32 2021 +0100

tree-optimization/91403 - avoid excessive code-generation

The vectorizer, for large permuted grouped loads, generates
inefficient intermediate code (cleaned up only later) that runs
into complexity issues in SCEV analysis and elsewhere.  For the
non-single-element interleaving case we already put a hard limit
in place, this applies the same limit to the missing case.

2021-01-11  Richard Biener  

PR tree-optimization/91403
* tree-vect-data-refs.c (vect_analyze_group_access_1): Cap
single-element interleaving group size at 4096 elements.

* gcc.dg/vect/pr91403.c: New testcase.

[Bug tree-optimization/91403] GCC fails with ICE.

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91403

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.0

--- Comment #9 from Richard Biener  ---
Fixed on trunk sofar.

[Bug analyzer/98599] fatal error: Cgraph edge statement index out of range with -Os -flto -fanalyzer

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599

--- Comment #3 from Martin Liška  ---
> 
> The analyzer updates the gimple stmt uids; if I disable this updating the
> crash doesn't happen.

Hm, why do you update them in LTO WPA phase?
Note that they are used by cgraph_edges to point to a proper GIMPLE statement.

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98615

--- Comment #2 from Martin Liška  ---
g:895fdc1f4c9

[Bug target/98612] _mm_comieq_sd has wrong semantics

[guillaume.piolat at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98612

--- Comment #5 from Guillaume Piolat  ---
My reasoning for reporting (while it is minor) is the following:
- it might not be a conscious choice from GCC developers
- this is the only intrinsics I've found in mmx/sse/sse2 for which GCC has
different semantics than ICC and clang. 
- clang wiki define intel intrinsics as the "portable API" between compilers
- people will copy/paste intel intrinsics code between compilers. So fixing it
is breaking, but leaving it is also breaking
- in any case it is surprising

[Bug bootstrap/98414] [11 Regression] UBSAN bootstrap is broken: ubsan/ubsan_type_hash_itanium.cpp:162: undefined reference to `__dynamic_cast' since r11-6083-gb7dfc2074c78415d451eb34d1608016c80b1c41a

[nathan at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98414

--- Comment #17 from Nathan Sidwell  ---
libcody should be being built with -fno-exceptions -fno-rtti, that it isn;t
suggests I'm configuring it wrong.

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98615

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

--- Comment #3 from Martin Liška  ---
I've got a patch candidate.
Thanks for the report!

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98615

--- Comment #4 from Andrea Corallo  ---
Thank you for looking into it!  I tried my self but with no success

Re: [Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

[Andrea Corallo via Gcc-bugs]

Thank you for looking into it!  I tried my self but with no success

[Bug tree-optimization/97623] [9/10 Regression] Extremely slow O2 compile (>>O(n^2))

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623

--- Comment #21 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:0fd6247a3014038af349db3a01748b5dc17d87a0

commit r10-9245-g0fd6247a3014038af349db3a01748b5dc17d87a0
Author: Richard Biener 
Date:   Fri Oct 30 13:32:32 2020 +0100

tree-optimization/97623 - avoid excessive insert iteration for hoisting

This avoids requiring insert iteration for back-to-back hoisting
opportunities as seen in the added testcase.  For the PR at hand
this halves the number of insert iterations retaining only
the hard to avoid PRE / hoist insert back-to-backs.

2020-10-30  Richard Biener  

PR tree-optimization/97623
* tree-ssa-pre.c (insert): First do hoist insertion in
a backward walk.

* gcc.dg/tree-ssa/ssa-hoist-7.c: New testcase.

(cherry picked from commit 82ff7e3426ea926d090777173977f8bedd086816)

[Bug tree-optimization/97623] [9/10 Regression] Extremely slow O2 compile (>>O(n^2))

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623

--- Comment #22 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:eddcb627ccfbd97e025cf366cc3f3bad76211785

commit r10-9246-geddcb627ccfbd97e025cf366cc3f3bad76211785
Author: Richard Biener 
Date:   Tue Nov 3 15:03:41 2020 +0100

tree-optimization/97623 - Avoid PRE hoist insertion iteration

We are not really interested in PRE opportunities exposed by
hoisting but only the other way around.  So this moves hoist
insertion after PRE iteration finished and removes hoist
insertion iteration alltogether.

It also guards access to NEW_SETS properly.

2020-11-11  Richard Biener  

PR tree-optimization/97623
* tree-ssa-pre.c (insert): Move hoist insertion after PRE
insertion iteration and do not iterate it.
(create_expression_by_pieces): Guard NEW_SETS access.
(insert_into_preds_of_block): Likewise.

* gcc.dg/tree-ssa/ssa-hoist-3.c: Adjust.
* gcc.dg/tree-ssa/ssa-hoist-7.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-30.c: Likewise.

[Bug tree-optimization/97623] [9 Regression] Extremely slow O2 compile (>>O(n^2))

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623

Richard Biener  changed:

   What|Removed |Added

  Known to fail||10.2.0
  Known to work||10.2.1
Summary|[9/10 Regression] Extremely |[9 Regression] Extremely
   |slow O2 compile (>>O(n^2))  |slow O2 compile (>>O(n^2))

--- Comment #23 from Richard Biener  ---
Backported to GCC 10 - I'm not planning to backport further.

[Bug c++/98620] New: SFINAE code in class specialization generate warnings

[m.cencora at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98620

Bug ID: 98620
   Summary: SFINAE code in class specialization generate warnings
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.cencora at gmail dot com
  Target Milestone: ---

Following code compiled in any gcc>=5, C++11 or higher, and
-Wmissing-field-initializers generate compiler warning:

g++ -std=c++20 -Wmissing-field-initializers

#include 

template 
struct TmpArray
{
   T arr[1];
};

template 
struct is_non_narrowing_conversion : std::false_type
{};

template 
struct is_non_narrowing_conversion<
Src, Dst,
decltype(void(TmpArray{{ std::declval() }}))
> : std::true_type
{};

struct mystruct
{
int a;
void * b;
};


void test_nok()
{
is_non_narrowing_conversion::type v;
}

SFINAE is used here only to detect if a code compiles, and code inside the
decltype should not generate warnings.

Also this is inconsistent, because when SFINAE is used in function template the
warning is not generated:
template 
auto is_non_narrowing_conversion_func_impl(Src&&, int)
   -> decltype((TmpArray{{ std::declval() }}, std::true_type{}));

template 
auto is_non_narrowing_conversion_func_impl(Src&&, ...)
   -> std::false_type;

template 
using is_non_narrowing_conversion_v2 =
decltype(is_non_narrowing_conversion_func_impl(std::declval(), 0));

void test_ok()
{
is_non_narrowing_conversion_v2 v;
}

[Bug tree-optimization/98117] [8/9/10 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98117

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:69894ce172412996c10c89838717980ede7c9003

commit r10-9247-g69894ce172412996c10c89838717980ede7c9003
Author: Richard Biener 
Date:   Mon Dec 7 10:29:07 2020 +0100

tree-optimization/98117 - fix range set by vectorization on niter IVs

This avoids the degenerate case of a TYPE_MAX_VALUE latch iteration
count value causing wrong range info for the vector IV.  There's
still the case of VF == 1 where if we don't know whether we hit the
above case we cannot emit a range.

2020-12-07  Richard Biener  

PR tree-optimization/98117
* tree-vect-loop-manip.c (vect_gen_vector_loop_niters):
Properly handle degenerate niter when setting the vector
loop IV range.

* gcc.dg/torture/pr98117.c: New testcase.

(cherry picked from commit cdcbef3c3310a14f2994982b44cb1f8e14c77232)

[Bug tree-optimization/98455] [11 Regression] ICE: verify_gimple failed (error: invalid 'PHI' argument; error: incompatible types in 'PHI' argument 2) since r11-5642-gc961e94901eb793b

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98455

Martin Liška  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
What happens here:

if-to-switch conversion happens:

(gdb) pcfun
void n4 (int io, int vb)
{
  double uc$1;
  double uc[2];

   :
  if (io_6(D) == 0)
goto ; [INV]
  else
goto ; [INV]

   :

   :
  # uc$1_12 = PHI <2.0e+0(3), uc$1_12(7), 2.0e+0(2), 0.0(9), uc$1_12(5),
uc$1_12(6)>
:
  if (io_6(D) == 0)
goto ; [INV]
  else
goto ; [INV]

   :
  switch (vb_8(D))  [INV], case 0:  [INV], case 1: 
[INV]>

   :
:
  goto ; [INV]

   :
:
  goto ; [INV]

}

as seen, uc$1_12 = PHI <..., uc$1_12(6), ...> is properly fixed.

The pass uses TODO_cleanup_cfg that corrupts the CFG in
gimple_make_forwarder_block

EMERGENCY DUMP:

void n4 (int io, int vb)
{
  double uc$1;
  double uc[2];

   :

   :
  # uc$1_12 = PHI <2.0e+0(2), uc$1_12(5), (4), uc$1_12(3), 0.0(6)> <- HERE
:
  if (io_6(D) == 0)
goto ; [INV]
  else
goto ; [INV]

   :
  switch (vb_8(D))  [INV], case 0:  [INV], case 1: 
[INV]>

   :
:
  goto ; [INV]

   :
:
  goto ; [INV]

}

@Richi: What am I doing wrong?

[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)

[emil at tywoniak dot eu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967

--- Comment #18 from Emil Jiří Tywoniak  ---
(In reply to Christophe Lyon from comment #17)
> Any chance you can try with a toolchain using binutils-2.35?
> 
> As I indicated in https://bugs.launchpad.net/gcc-arm-embedded/+bug/1747966
> there's a related bug fix in binutils-2.35, but Arm's 2020-q2 toolchain
> still uses 2.34.50.20200226.

Issue in my project is not present anymore with 2020 Q4 release, which packs
GNU ld (GNU Arm Embedded Toolchain 10-2020-q4-major) 2.35.1.20201028. Will test
example from Comment #11. My apologies for not reading threads more carefully

[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)

[emil at tywoniak dot eu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967

--- Comment #19 from Emil Jiří Tywoniak  ---
(In reply to Emil Jiří Tywoniak from comment #18)
> (In reply to Christophe Lyon from comment #17)
> > Any chance you can try with a toolchain using binutils-2.35?
> > 
> > As I indicated in https://bugs.launchpad.net/gcc-arm-embedded/+bug/1747966
> > there's a related bug fix in binutils-2.35, but Arm's 2020-q2 toolchain
> > still uses 2.34.50.20200226.
> 
> Issue in my project is not present anymore with 2020 Q4 release, which packs
> GNU ld (GNU Arm Embedded Toolchain 10-2020-q4-major) 2.35.1.20201028. Will
> test example from Comment #11. My apologies for not reading threads more
> carefully

I have now tested the bad branch from Comment #11 and did not replicate the bug
with the Q4 toolchain (specifically, the Systick handler in .lst is exactly the
same as in the good branch excerpt in Comment #11)

[Bug c/98621] New: ICE: x from g referenced in f

[acoplan at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98621

Bug ID: 98621
   Summary: ICE: x from g referenced in f
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

Here is an error-recovery ICE:

$ cat test.c
int f() {
  int g(x) int x;
  int a[x];
}
$ aarch64-elf-gcc -c test.c
test.c: In function 'g':
test.c:4:1: error: expected declaration specifiers before '}' token
4 | }
  | ^
test.c:3:7: error: declaration for parameter 'a' but no such parameter
3 |   int a[x];
  |   ^
test.c:5: error: expected '{' at end of input
test.c: In function 'f':
test.c:4:1: error: expected declaration or statement at end of input
4 | }
  | ^
test.c:1:5: internal compiler error: x from g referenced in f
1 | int f() {
  | ^
0xeae7e0 convert_nonlocal_reference_op
/home/alecop01/toolchain/src/gcc/gcc/tree-nested.c:1163
0x1181546 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/alecop01/toolchain/src/gcc/gcc/tree.c:12095
0xaa2a6c walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-walk.c:202
0xaa384e walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-walk.c:596
0xaa3b2c walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-walk.c:51
0xaa38ca walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-walk.c:605
0xaa3b2c walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-walk.c:51
0xea87ca walk_body
/home/alecop01/toolchain/src/gcc/gcc/tree-nested.c:811
0xea8857 walk_function
/home/alecop01/toolchain/src/gcc/gcc/tree-nested.c:822
0xea8857 walk_all_functions
/home/alecop01/toolchain/src/gcc/gcc/tree-nested.c:887
0xeb3bf1 lower_nested_functions(tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/tree-nested.c:3698
0x8d883b cgraph_node::analyze()
/home/alecop01/toolchain/src/gcc/gcc/cgraphunit.c:676
0x8db7d2 analyze_functions
/home/alecop01/toolchain/src/gcc/gcc/cgraphunit.c:1235
0x8dcc87 symbol_table::finalize_compilation_unit()
/home/alecop01/toolchain/src/gcc/gcc/cgraphunit.c:2513
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/95731] Failure to optimize a >= 0 && b >= 0 to (a | b) >= 0

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95731

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #5 from Jakub Jelinek  ---
Created attachment 49938
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49938&action=edit
gcc11-pr95731.patch

Untested fix.

[Bug tree-optimization/98455] [11 Regression] ICE: verify_gimple failed (error: invalid 'PHI' argument; error: incompatible types in 'PHI' argument 2) since r11-5642-gc961e94901eb793b

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98455

--- Comment #3 from Richard Biener  ---
The issue is you are leaving the virtual PHI arguments NULL and thus
ssa_redirect_edge runs into

if (def == NULL_TREE)
  continue;

but then later flush_pending_stmts expects a 1:1 correspondence of PHI
and argument per edge.  The fix is to either put in bare gimple_vop (cfun)
symbols (you'll rename later anyway) in the PHI argument place or try
to make the CFG workers deal with missing arguments.

Note missing args are not really valid.  After if-to-switch:

   :
  # .MEM_2 = PHI <.MEM_3(D)(3), .MEM_2(7), .MEM_3(D)(2), .MEM_2(9), .MEM_2(5),
(6)>
  # uc$1_12 = PHI <2.0e+0(3), uc$1_12(7), 2.0e+0(2), 0.0(9), uc$1_12(5),
uc$1_12(6)>
:
  if (io_6(D) == 0)

note the missing MEM argument in the edge from 6 to 5

[Bug c++/98620] SFINAE code in class specialization generates warnings

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98620

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-01-11
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||diagnostic

[Bug libstdc++/65480] libstdc++-prettyprinters/libfundts.cc test failures on powerpc64

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65480

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:4fd49da23bf579b84940bd96bf942bd99cfa187a

commit r10-9249-g4fd49da23bf579b84940bd96bf942bd99cfa187a
Author: Jonathan Wakely 
Date:   Wed Dec 2 21:39:08 2020 +

libstdc++: Fix std::any pretty printer [PR 68735]

This fixes errors seen on powerpc64 (big endian only) due to the
printers for std::any and std::experimental::any being unable to find
the manager function.

libstdc++-v3/ChangeLog:

PR libstdc++/65480
PR libstdc++/68735
* python/libstdcxx/v6/printers.py (function_pointer_to_name):
New helper function to get the name of a function from its
address.
(StdExpAnyPrinter.__init__): Use it.

(cherry picked from commit dc2b372ed1b1e9af6db45051cff95478c7616807)

[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68735

--- Comment #10 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:4fd49da23bf579b84940bd96bf942bd99cfa187a

commit r10-9249-g4fd49da23bf579b84940bd96bf942bd99cfa187a
Author: Jonathan Wakely 
Date:   Wed Dec 2 21:39:08 2020 +

libstdc++: Fix std::any pretty printer [PR 68735]

This fixes errors seen on powerpc64 (big endian only) due to the
printers for std::any and std::experimental::any being unable to find
the manager function.

libstdc++-v3/ChangeLog:

PR libstdc++/65480
PR libstdc++/68735
* python/libstdcxx/v6/printers.py (function_pointer_to_name):
New helper function to get the name of a function from its
address.
(StdExpAnyPrinter.__init__): Use it.

(cherry picked from commit dc2b372ed1b1e9af6db45051cff95478c7616807)

[Bug libstdc++/96083] Clang can't compile : error: use of undeclared identifier '__builtin_sprintf'

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96083

--- Comment #2 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:93beee71a5ba5ee97a072d94780b140ae159fd74

commit r10-9250-g93beee71a5ba5ee97a072d94780b140ae159fd74
Author: Jonathan Wakely 
Date:   Wed Dec 16 13:50:34 2020 +

libstdc++: Only use __builtin_sprintf if supported [PR 96083]

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprintf if necessary.

(cherry picked from commit 96d9670e88333d8896a5d2f2bb0403c1e2ad19ab)

[Bug libstdc++/91997] pretty printers: The __node_type type alias in _Hashtable is not available

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997

--- Comment #10 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:b1dba8a228e7d9497d2ddbd012b4343f99b87823

commit r9-9168-gb1dba8a228e7d9497d2ddbd012b4343f99b87823
Author: Jonathan Wakely 
Date:   Fri Nov 29 14:47:03 2019 +

libstdc++: improve how pretty printers find node types (PR 91997)

This fixes two related problems.

The iterators for node-based containers use nested typedefs such as
std::list::iterator::_Node to denote their node types. As reported in
https://bugzilla.redhat.com/show_bug.cgi?id=1053438 those typedefs are
not always present in the debug info. That means the pretty printers
cannot find them using gdb.lookup_type (via the find_type helper).
Instead of looking up the nested typedefs this patch makes the printers
look up the actual class templates directly.

A related problem (and the original topic of PR 91997) is that GDB fails
to find types via gdb.lookup_type when printing a backtrace from a
non-C++ functiion: https://sourceware.org/bugzilla/show_bug.cgi?id=25234
That is also solved by not looking up the nested typedef.

PR libstdc++/91997
* python/libstdcxx/v6/printers.py (find_type): Fail more gracefully
if we run out of base classes to look at.
(llokup_templ_spec, lookup_node_type): New utilities to find node
types for node-based containers.
(StdListPrinter.children, NodeIteratorPrinter.__init__)
(NodeIteratorPrinter.to_string, StdSlistPrinter.children)
(StdSlistIteratorPrinter.to_string,
StdRbtreeIteratorPrinter.__init__)
(StdMapPrinter.children, StdSetPrinter.children)
(StdForwardListPrinter.children): Use lookup_node_type instead of
find_type.
(StdListIteratorPrinter.__init__,
StdFwdListIteratorPrinter.__init__):
Pass name of node type to NodeIteratorPrinter constructor.
(Tr1HashtableIterator.__init__): Rename argument.
(StdHashtableIterator.__init__): Likewise. Use lookup_templ_spec
instead of find_type.
* testsuite/libstdc++-prettyprinters/59161.cc: Remove workaround
for
_Node typedef not being present in debuginfo.
* testsuite/libstdc++-prettyprinters/91997.cc: New test.

(cherry picked from commit 9d50a6a78509b42b3c2b2264da1a0d2c4b151d66)

[Bug testsuite/98622] New: [11 regression] new test case pr98273.C in r11-6577 doesn't work

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98622

Bug ID: 98622
   Summary: [11 regression] new test case pr98273.C in r11-6577
doesn't work
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:4e275dccfc2467b3fe39012a3dd2a80bac257dd0, r11-6577



UNRESOLVED: could not find Python interpreter and (or) pytest module for
pr98273.C

[Bug c++/98620] SFINAE code in class specialization generates warnings

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98620

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Can be fixed like this:

--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1563,6 +1563,7 @@ process_init_constructor_record (tree type, tree init,
int nested, int flags,

  /* Warn when some struct elements are implicitly initialized.  */
  if ((complain & tf_warning)
+ && !cp_unevaluated_operand
  && !EMPTY_CONSTRUCTOR_P (init))
warning (OPT_Wmissing_field_initializers,
 "missing initializer for member %qD", field);
@@ -1593,6 +1594,7 @@ process_init_constructor_record (tree type, tree init,
int nested, int flags,
  /* Warn when some struct elements are implicitly initialized
 to zero.  */
  if ((complain & tf_warning)
+ && !cp_unevaluated_operand
  && !EMPTY_CONSTRUCTOR_P (init))
warning (OPT_Wmissing_field_initializers,
 "missing initializer for member %qD", field);

[Bug c++/98481] [10/11 Regression] std::vector::size_type as return type gets tagged with abi:cxx11

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98481

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:3dd0d3ee1d2a988e7f3a3e8f009fcf328f16d2ed

commit r11-6592-g3dd0d3ee1d2a988e7f3a3e8f009fcf328f16d2ed
Author: Jakub Jelinek 
Date:   Thu Jan 7 17:47:18 2021 +0100

c++, abi: Fix abi_tag attribute handling [PR98481]

In GCC10 cp_walk_subtrees has been changed to walk template arguments.
As the following testcase, that changed the mangling of some functions.
I believe the previous behavior that find_abi_tags_r doesn't recurse into
template args has been the correct one, but setting *walk_subtrees = 0
for the types and handling the types subtree walking manually in
find_abi_tags_r looks too hard, there are a lot of subtrees and details
what
should and shouldn't be walked, both in tree.c (walk_type_fields there,
which is static) and in cp_walk_subtrees itself.

The following patch abuses the fact that *walk_subtrees is an int to
tell cp_walk_subtrees it shouldn't walk the template args.

Co-authored-by: Jason Merrill 

gcc/cp/ChangeLog:

PR c++/98481
* class.c (find_abi_tags_r): Set *walk_subtrees to 2 instead of 1
for types.
(mark_abi_tags_r): Likewise.
* decl2.c (min_vis_r): Likewise.
* tree.c (cp_walk_subtrees): If *walk_subtrees_p is 2, look through
typedefs.

gcc/testsuite/ChangeLog:

PR c++/98481
* g++.dg/abi/abi-tag24.C: New test.

[Bug fortran/93524] [ISO C Binding][F2018] CFI_allocate – elem_size mishandled + sm wrongly set?

[burnus at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93524

--- Comment #1 from Tobias Burnus  ---
Also related to this issue:
https://gcc.gnu.org/pipermail/fortran/2021-January/055581.html:

In my understanding (see linked email and spec quote in comment 0),
CFI_type_signed_char is an integer type – and, hence, it should not be handled
at the following place – as pointed out by Harris Snyder in that email:

'CFI_establish' in libgfortran/runtime/ISO_Fortran_binding.c, circa line 348:

  if (type == CFI_type_char || type == CFI_type_ucs4_char ||
  type == CFI_type_signed_char || type == CFI_type_struct ||
  type == CFI_type_other)
dv->elem_len = elem_len;


The value is later used for the stride multiplier (sm) – hence, it causes
problems if it is set wrongly (to 0).

TESTCASE: See linked email.

[Bug sanitizer/98623] New: sanitizer does not diagnose when passing pointers to arrays of incorrect run-time length

[muecker at gwdg dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98623

Bug ID: 98623
   Summary: sanitizer does not diagnose when passing pointers to
arrays of incorrect run-time length
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: muecker at gwdg dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

In the following example, there is no run-time error with -fsanitize=undefined
although the pointer types for the second argument are required to point to
compatible types and it is UB when variably modified types have non-matching
lengths when they are required to be compatible (6.7.6.2p6). From a practical
point of view, this would very desirable as it would close the last loop-hole
that prevents one from having proper bounds checking when using pointers to
VLAs.

(In this case, but not in general, it should also be possible to emit an error
at compile time.)


extern void f(int n, double (*x)[n]);

int main()
{
double a[10];
f(9, &a);
}

[Bug analyzer/98599] fatal error: Cgraph edge statement index out of range with -Os -flto -fanalyzer

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599

--- Comment #4 from David Malcolm  ---
I set them so that each stmt has a unique id, unique across all functions.  I
was assuming from the comments I quoted above in gimple.h that this is safe to
do, but it sounds like from your comment that WPA makes assumptions that the
uids don't change.  If that's the case, then I need to rethink things, and the
gimple.h comments probably need updating (or WPA needs to allow for uids to
change, but maybe that's hard to do?)

[Bug testsuite/98622] [11 regression] new test case pr98273.C in r11-6577 doesn't work

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98622

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Martin Liška  ---
Note that Python tests are optional and you likely see the UNRESOLVED message
as you don't have python3 (or pytest module) installed.

[Bug c++/98624] New: UBSAN: gcc/cp/module.cc:5895:29: runtime error: member call on null pointer of type 'struct module_state'

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98624

Bug ID: 98624
   Summary: UBSAN: gcc/cp/module.cc:5895:29: runtime error: member
call on null pointer of type 'struct module_state'
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
Blocks: 63426
  Target Milestone: ---

Seen with UBSAN compiler:

$ ./xg++ -B.
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/modules/align-type-1_a.C -c
-fmodules-ts
/home/marxin/Programming/gcc2/gcc/cp/module.cc:5895:29: runtime error: member
call on null pointer of type 'struct module_state'
#0 0xf56fc4 in trees_out::core_vals(tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:5895
#1 0xf67347 in trees_out::tree_node_vals(tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:7141
#2 0xf6cd92 in trees_out::decl_value(tree_node*, depset*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:7753
#3 0xfb2a97 in depset::hash::find_dependencies()
/home/marxin/Programming/gcc2/gcc/cp/module.cc:13199
#4 0xfd1f35 in module_state::write(elf_out*, cpp_reader*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:17568
#5 0xfe1ab8 in finish_module_processing(cpp_reader*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:19747
#6 0xdcc2d1 in c_parse_final_cleanups()
/home/marxin/Programming/gcc2/gcc/cp/decl2.c:5178
#7 0x15ae87f in c_common_parse_file()
/home/marxin/Programming/gcc2/gcc/c-family/c-opts.c:1233
#8 0x2ccb435 in compile_file /home/marxin/Programming/gcc2/gcc/toplev.c:457
#9 0x2cd3e17 in do_compile /home/marxin/Programming/gcc2/gcc/toplev.c:2193
#10 0x2cd441a in toplev::main(int, char**)
/home/marxin/Programming/gcc2/gcc/toplev.c:2332
#11 0x59b3bff in main /home/marxin/Programming/gcc2/gcc/main.c:39
#12 0x76ce5151 in __libc_start_main (/lib64/libc.so.6+0x28151)
#13 0xa82bdd in _start
(/home/marxin/Programming/gcc2/objdir/gcc/cc1plus+0xa82bdd)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined

[Bug c++/98625] New: UBSAN: gcc/cp/module.cc:977:15: runtime error: left shift of negative value -1

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98625

Bug ID: 98625
   Summary: UBSAN: gcc/cp/module.cc:977:15: runtime error: left
shift of negative value -1
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
Blocks: 63426
  Target Milestone: ---

Seen with:

$ ./xg++ -B.
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/modules/enum-1_a.C -c
-fmodules-ts
$ ./xg++ -B.
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/modules/enum-1_b.C -c
-fmodules-ts
...
/home/marxin/Programming/gcc2/gcc/cp/module.cc:977:15: runtime error: left
shift of negative value -1
#0 0xf3402f in bytes_in::wi()
/home/marxin/Programming/gcc2/gcc/cp/module.cc:977
#1 0xfeacc4 in bytes_in::wu()
/home/marxin/Programming/gcc2/gcc/cp/module.cc:997
#2 0xf5fa20 in trees_in::core_vals(tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:6537
#3 0xf673c7 in trees_in::tree_node_vals(tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:7148
#4 0xf7d365 in trees_in::tree_value()
/home/marxin/Programming/gcc2/gcc/cp/module.cc:8996
#5 0xf7f047 in trees_in::tree_node(bool)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:9214
#6 0xfa7a98 in trees_in::read_enum_def(tree_node*, tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:12203
#7 0xfa96dd in trees_in::read_definition(tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:12401
#8 0xfbe6df in module_state::read_cluster(unsigned int)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:14905
#9 0xfd59a9 in module_state::load_section(unsigned int, binding_slot*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:18036
#10 0xfdb7b7 in lazy_load_binding(unsigned int, tree_node*, tree_node*,
binding_slot*) /home/marxin/Programming/gcc2/gcc/cp/module.cc:18718
#11 0x101d434 in name_lookup::search_namespace_only(tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/name-lookup.c:918
#12 0x101f47f in name_lookup::search_unqualified(tree_node*,
cp_binding_level*) /home/marxin/Programming/gcc2/gcc/cp/name-lookup.c:1149
#13 0x1061c02 in lookup_name_1
/home/marxin/Programming/gcc2/gcc/cp/name-lookup.c:7910
#14 0x1061da7 in lookup_name(tree_node*, LOOK_where, LOOK_want)
/home/marxin/Programming/gcc2/gcc/cp/name-lookup.c:7930
#15 0xd8d60f in lookup_name(tree_node*, LOOK_want)
/home/marxin/Programming/gcc2/gcc/cp/name-lookup.h:413
#16 0x110d10c in cp_parser_lookup_name
/home/marxin/Programming/gcc2/gcc/cp/parser.c:29285
#17 0x10f7949 in cp_parser_class_name
/home/marxin/Programming/gcc2/gcc/cp/parser.c:24618
#18 0x110e73b in cp_parser_constructor_declarator_p
/home/marxin/Programming/gcc2/gcc/cp/parser.c:29636
#19 0x10ccefe in cp_parser_decl_specifier_seq
/home/marxin/Programming/gcc2/gcc/cp/parser.c:14988
#20 0x10c99dd in cp_parser_simple_declaration
/home/marxin/Programming/gcc2/gcc/cp/parser.c:14260
#21 0x10c9937 in cp_parser_block_declaration
/home/marxin/Programming/gcc2/gcc/cp/parser.c:14207
#22 0x10c907a in cp_parser_declaration
/home/marxin/Programming/gcc2/gcc/cp/parser.c:14078
#23 0x10c9381 in cp_parser_toplevel_declaration
/home/marxin/Programming/gcc2/gcc/cp/parser.c:14107
#24 0x109cc1e in cp_parser_translation_unit
/home/marxin/Programming/gcc2/gcc/cp/parser.c:4936
#25 0x116c842 in c_parse_file()
/home/marxin/Programming/gcc2/gcc/cp/parser.c:45121
#26 0x15ae6d5 in c_common_parse_file()
/home/marxin/Programming/gcc2/gcc/c-family/c-opts.c:1211
#27 0x2ccb435 in compile_file
/home/marxin/Programming/gcc2/gcc/toplev.c:457
#28 0x2cd3e17 in do_compile /home/marxin/Programming/gcc2/gcc/toplev.c:2193
#29 0x2cd441a in toplev::main(int, char**)
/home/marxin/Programming/gcc2/gcc/toplev.c:2332
#30 0x59b3bff in main /home/marxin/Programming/gcc2/gcc/main.c:39
#31 0x76ce5151 in __libc_start_main (/lib64/libc.so.6+0x28151)
#32 0xa82bdd in _start
(/home/marxin/Programming/gcc2/objdir/gcc/cc1plus+0xa82bdd)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined

[Bug c++/98625] UBSAN: gcc/cp/module.cc:977:15: runtime error: left shift of negative value -1

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98625

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=98624
   Last reconfirmed||2021-01-11
 Status|UNCONFIRMED |NEW

[Bug c++/98624] UBSAN: gcc/cp/module.cc:5895:29: runtime error: member call on null pointer of type 'struct module_state'

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98624

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-01-11

[Bug c++/98626] New: UBSAN: vec.h:591:30: runtime error: member access within null pointer of type 'struct vec'

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98626

Bug ID: 98626
   Summary: UBSAN: vec.h:591:30: runtime error: member access
within null pointer of type 'struct vec'
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
Blocks: 63426
  Target Milestone: ---

I see the following with UBSAN compiler:

$ ./xg++ -B.
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/modules/mod-decl-2_a.C -c
-fmodules-ts
...
$ ./xg++ -B.
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/modules/mod-decl-2_b.C -c
-fmodules-ts
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/modules/mod-decl-2_b.C:4:1:
error: cannot import module in its own purview
4 | import bob; // { dg-error "cannot import module.* in its own purview" }
  | ^~
In module imported at
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/modules/mod-decl-2_b.C:4:1:
bob: note: module ‘bob’ declared here
/home/marxin/Programming/gcc2/gcc/cp/typeck.c:4024:33: runtime error: member
call on null pointer of type 'struct vec'
#0 0x1403445 in cp_build_function_call_vec(tree_node*, vec**, int, tree_node*)
/home/marxin/Programming/gcc2/gcc/cp/typeck.c:4024
#1 0xfdd5bf in module_add_import_initializers()
/home/marxin/Programming/gcc2/gcc/cp/module.cc:18995
#2 0xdc20f9 in start_objects
/home/marxin/Programming/gcc2/gcc/cp/decl2.c:3745
#3 0xdc4b3b in generate_ctor_or_dtor_function
/home/marxin/Programming/gcc2/gcc/cp/decl2.c:4310
#4 0xdccb6c in c_parse_final_cleanups()
/home/marxin/Programming/gcc2/gcc/cp/decl2.c:5234
#5 0x15ae87f in c_common_parse_file()
/home/marxin/Programming/gcc2/gcc/c-family/c-opts.c:1233
#6 0x2ccb435 in compile_file /home/marxin/Programming/gcc2/gcc/toplev.c:457
#7 0x2cd3e17 in do_compile /home/marxin/Programming/gcc2/gcc/toplev.c:2193
#8 0x2cd441a in toplev::main(int, char**)
/home/marxin/Programming/gcc2/gcc/toplev.c:2332
#9 0x59b3bff in main /home/marxin/Programming/gcc2/gcc/main.c:39
#10 0x76ce5151 in __libc_start_main (/lib64/libc.so.6+0x28151)
#11 0xa82bdd in _start
(/home/marxin/Programming/gcc2/objdir/gcc/cc1plus+0xa82bdd)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined

[Bug c++/98626] UBSAN: vec.h:591:30: runtime error: member access within null pointer of type 'struct vec'

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98626

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-01-11
 Ever confirmed|0   |1

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98615

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:cbe9758ff494d55d558a2a0c5e8702c50fcebdf0

commit r11-6593-gcbe9758ff494d55d558a2a0c5e8702c50fcebdf0
Author: Martin Liska 
Date:   Mon Jan 11 14:01:07 2021 +0100

Properly release symtab::m_clones.

gcc/ChangeLog:

PR jit/98615
* symtab-clones.h (clone_info::release): Release
symtab::m_clones with ggc_delete as it's a GGC memory.

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98615

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Martin Liška  ---
Fixed.

[Bug c/98627] New: GCC emits unaligned memory access instructions causing address error exceptions with the 68000 architecture

[noring at nocrew dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98627

Bug ID: 98627
   Summary: GCC emits unaligned memory access instructions causing
address error exceptions with the 68000 architecture
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noring at nocrew dot org
  Target Milestone: ---

The 68000 architecture requires that (16-bit) word and (32-bit) long memory
accesses are aligned with even addresses, but GCC frequently emits code that
breaks this when compiling with optimisations (O1 or higher). This causes
address error exceptions, which are fatal errors that crash programs.

For example, consider

struct s { char a, b, c, d, e; };
struct s f(char a)
{
return (struct s) { .a = a, .d = 'd' };
}

that GCC with O1 will compile into

 :
   0:   2049moveal %a1,%a0
   2:   202f 0004   movel %sp@(4),%d0
   6:   42a9 0001   clrl %a1@(1)/* <<<--- unaligned long clear */
   a:   1280moveb %d0,%a1@
   c:   137c 0064 0003  moveb #100,%a1@(3)
  12:   4e75rts

where offset 6 has "clrl %a1@(1)", which is an unaligned 32-bit long clear. GCC
can emit several similar variants of this, for example unaligned 16-bit word
clears, and possibly others.

[Bug analyzer/98628] New: internal compiler error: in get_or_create_cluster, at analyzer/store.cc:2040

[ortmann at posteo dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98628

Bug ID: 98628
   Summary: internal compiler error: in get_or_create_cluster, at
analyzer/store.cc:2040
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: ortmann at posteo dot de
  Target Milestone: ---

Version: gcc (GCC) 11.0.0 20210110 (experimental)

System type: GNU/Linux kernel 5.10.5 glibc 2.32

Options given when GCC was configured/built:
--prefix=/home/michael/opt/gcc-11-20210110 --enable-languages=c
--disable-multilib --with-system-zlib

Trigger:

git clone https://github.com/eggheads/eggdrop.git
cd eggdrop/
git checkout 94d2a4fabfd47deb8d3ae59bea769eb3e792ef07
CC="/home/michael/opt/gcc-11-20210110/bin/gcc -fanalyzer" ./configure 
make config
make

Note: eggdrop requires tcl to be installed also.

Compiler output:

[...]
/home/michael/opt/gcc-11-20210110/bin/gcc -fanalyzer -g -O2 -pipe -Wall -I..
-I..  -DHAVE_CONFIG_H -I/usr/include -g3 -DDEBUG -DDEBUG_ASSERT -DDEBUG_MEM
-DDEBUG_DNS  -c misc.c
during IPA pass: analyzer
misc.c:958:25: internal compiler error: in get_or_create_cluster, at
analyzer/store.cc:2040
  958 | *writeidx++ = ' ';
  | ^
0x76f191 ana::store::get_or_create_cluster(ana::region const*)
../../gcc/analyzer/store.cc:2040
0x11b92f9 ana::binding_cluster::make_unknown_relative_to(ana::binding_cluster
const*, ana::store*, ana::store_manager*)
../../gcc/analyzer/store.cc:1326
0x11bac4e ana::binding_cluster::can_merge_p(ana::binding_cluster const*,
ana::binding_cluster const*, ana::binding_cluster*, ana::store*,
ana::store_manager*, ana::model_merger*)
../../gcc/analyzer/store.cc:1208
0x11bb746 ana::store::can_merge_p(ana::store const*, ana::store const*,
ana::store*, ana::store_manager*, ana::model_merger*)
../../gcc/analyzer/store.cc:2111
0x1189e4c ana::region_model::can_merge_with_p(ana::region_model const&,
ana::program_point const&, ana::region_model*) const
../../gcc/analyzer/region-model.cc:2954
0x117fa0a ana::program_state::can_merge_with_p(ana::program_state const&,
ana::program_point const&, ana::program_state*) const
../../gcc/analyzer/program-state.cc:1083
0x116f36d
ana::exploded_graph::maybe_process_run_of_before_supernode_enodes(ana::exploded_node*)
../../gcc/analyzer/engine.cc:2735
0x1170657 ana::exploded_graph::process_worklist()
../../gcc/analyzer/engine.cc:2443
0x11724bb ana::impl_run_checkers(ana::logger*)
../../gcc/analyzer/engine.cc:4739
0x11732ce ana::run_checkers()
../../gcc/analyzer/engine.cc:4810
0x1165c58 execute
../../gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[1]: *** [Makefile:83: misc.o] Error 1
make[1]: Leaving directory '/tmp/eggdrop/src'
make: *** [Makefile:251: debug] Error 2

[Bug analyzer/98628] internal compiler error: in get_or_create_cluster, at analyzer/store.cc:2040

[ortmann at posteo dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98628

--- Comment #1 from Michael Ortmann  ---
Created attachment 49939
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49939&action=edit
The preprocessed file (*.i*) that triggers the bug