[Bug tree-optimization/98464] [11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in tree_nop_conversion_p, at tree.c:12825 by r11-4637

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

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

Kewen Lin  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Kewen Lin  ---
My commit exposed one issue in FRE. The reason why the ICE occurs is that one
SSA_NAME used in loop's nb_iterations is actually in free list.

(unsigned long) _54 - (unsigned long) v$ptr__25

arg:0 
nothrow
def_stmt
version:54 in-free-list>>

I noticed that FRE already has some codes to handle loop's nb_iterations, but
there are some inconsistence which cause FRE unable to replace the one in
loop's nb_iterations but later replace all uses of _54.

When FRE is processing BB 19, it's able to replace _54 with _53 like:

   [local count: 789698041]:
  ...
  if (_26 != v$D4172$_M_impl$D4082$_M_finish$ptr__54)
goto ; [89.00%]

=>

   [local count: 789698041]:
  ...
  if (_26 != __new_finish$ptr__53)
goto ; [89.00%]

since it calls eliminate_stmt which works with def_bb instead of current bb:

sprime = eliminate_avail (gimple_bb (SSA_NAME_DEF_STMT (use)), use)

while rpo_vn_valueize only works with vn_context_bb.

For this particular case, _54's def_bb is BB 13, _53's def_bb is BB 11, it's ok
for dominated_by_p_w_unex check. While vn_context_bb is BB 19,
dominated_by_p_w_unex check returns false for it.

[Bug fortran/98476] OpenMP offload syntax restriction

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The error is correct for OpenMP 4.5, !$omp target data there has the
restriction:
At least one map clause must appear on the directive.
and OpenMP 4.5 is what GCC 10 implements in Fortran mostly.
OpenMP 5.0 and 5.1 changes that restriction to:
At least one map, use_device_addr or use_device_ptr clause must appear on the
directive.
which is what you can see in the C and C++ FEs.
GCC 11 is going to implement the 5.0 behavior here even in Fortran.

[Bug fortran/98476] New: OpenMP offload syntax restriction

[xw111luoye at gmail dot com via Gcc-bugs]

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

Bug ID: 98476
   Summary: OpenMP offload syntax restriction
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xw111luoye at gmail dot com
  Target Milestone: ---

C version code works. The corresponding Fortran version is blocked by the
compiler errror.

C version:
#include 

int main()
{
  int a[1];
  int* b = a;
  a[0] = 0;
  #pragma omp target enter data map(to:b[:1])
  #pragma omp target data use_device_ptr(b)
  {
#pragma omp target is_device_ptr(b)
{
  b[0] = 1;
}
  }
  printf("value before exit data %d\n", b[0]);
  #pragma omp target exit data map(from:b[:1])
  printf("value after exit data %d\n", b[0]);
  return 0;
}


Fortran version, XL fortran compiler works with this case.
program abc
  implicit none
  integer a

  a = 0
  call test(a)

contains
  subroutine test(a)
implicit none
integer a

  !$omp target enter data map(to:a)
  !$omp target data use_device_ptr(a)
  ! Error: TARGET DATA must contain at least one MAP clause at (1)
  ! after adding map(to: a), the second printout is still wrong.
  !$omp target is_device_ptr(a)
a = 1
  !$omp end target
  !$omp end target data
  write(6,*) "before exit data a = ", a
  !$omp target exit data map(from:a)
  write(6,*) "after exit data a = ", a

  endsubroutine
end program

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[law at redhat dot com via Gcc-bugs]

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

--- Comment #10 from Jeffrey A. Law  ---
So if that bisection is accurate, the only way this could be failing would be
if something with a deprecated attribute is being used.

Maybe some printfs in warn_deprecated_use?  But again, I'm a bit surprised by
the bisection results.

http://3.14.90.209:8080/job/m68k-linux-gnu/

Has the most recent build results from my tester.  As you can see everything
built and regression tested on Dec 9.  Dec 15 had a successful bootstrap, but
glibc failed due to a relatively minor bug in glibc.

[Bug target/98461] Suboptimal codegen for negating a movemask

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Hongtao.liu  ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 49854 [details]
> gcc11-pr98461.patch
> 
> Untested fix.

+  if (GET_MODE_NUNITS (mode) == 32)

Yes, and i missed this part.

[Bug fortran/98458] PRINT the array constructed from implied do-loop throw ICE

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #6 from Steve Kargl  ---
On Wed, Dec 30, 2020 at 12:52:03AM +, xiao@compiler-dev.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98458
> 
> --- Comment #5 from xiao@compiler-dev.com  ---
> (In reply to Paul Thomas from comment #4)
> > Created attachment 49856 [details]
> > Fix for the PR
> > 
> > Thank you for the report on this problem.
> > 
> > The attached patch fixes the problem and regression tests OK. I need to do a
> > bit more thinking about it because I was unable to find a point in general
> > expression simplification where the fix could be applied. Instead, it only
> > seems to work in the simplification of intrinsic functions. Fortunately,
> > this seems to be the only place where it is needed.
> > 
> > Paul
> 
> As a beginner of FORTRAN, I am not sure about the result of implied do-loop
> which contains array section, so add "print" to check. Thanks for your
> attention on this problem.
> 

PRINT has nothing to do with the problem.  I simply
have no interest in fixing the changed and now misleading
subject line.  I've been asked to stop.

My proposed patch fixes the issue in one spot.  Paul's
patch fixes potentially many spots.  Unfortunately, the
handling of implied do-loops is done in an ad hoc fashion,
and is complicated by the potential problem of exhausting
the stack.

[Bug fortran/98458] PRINT the array constructed from implied do-loop throw ICE

[xiao.liu--- via Gcc-bugs]

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

--- Comment #5 from xiao@compiler-dev.com  ---
(In reply to Paul Thomas from comment #4)
> Created attachment 49856 [details]
> Fix for the PR
> 
> Thank you for the report on this problem.
> 
> The attached patch fixes the problem and regression tests OK. I need to do a
> bit more thinking about it because I was unable to find a point in general
> expression simplification where the fix could be applied. Instead, it only
> seems to work in the simplification of intrinsic functions. Fortunately,
> this seems to be the only place where it is needed.
> 
> Paul

As a beginner of FORTRAN, I am not sure about the result of implied do-loop
which contains array section, so add "print" to check. Thanks for your
attention on this problem.

[Bug c++/98475] New: Class template argument deduction for alias templates fails

[kimhappy at hanyang dot ac.kr via Gcc-bugs]

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

Bug ID: 98475
   Summary: Class template argument deduction for alias templates
fails
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kimhappy at hanyang dot ac.kr
  Target Milestone: ---

Created attachment 49857
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49857=edit
Example case

[Environment]
OS: Arch Linux on Windows 10 x86_64
Kernel: 4.19.128-microsoft-standard

[Compile command]
g++ -std=c++20 -Wall -Wextra

[Output]
test.cpp: In function ‘int main()’:
test.cpp:15:21: internal compiler error: Segmentation fault
   15 | auto o1 = SSS(10);
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Output of g++ -v]
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)

[Description]
Class template argument deduction for alias templates fails with some cases. I
tested it in various environments, but the results were the same.
In example case that I attached, if I replace T3 with a non-template template
argument or remove the second constructor of SS, it compiles fine.

[Bug target/64243] Passing and returning structures with single member of floating type via SSE registers is wrong on Windows x86-64 ABI

[bart at bartjanssens dot org via Gcc-bugs]

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

Bart Janssens  changed:

   What|Removed |Added

 CC||bart at bartjanssens dot org

--- Comment #3 from Bart Janssens  ---
We are still having this issue, it now manifests in cross-compiled binaries
used in the Julia ecosystem, see:
https://github.com/JuliaPackaging/BinaryBuilder.jl/issues/315

[Bug tree-optimization/98474] [8/9/10/11 Regression] incorrect results using __uint128_t

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-29
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug tree-optimization/98474] [8/9/10/11 Regression] incorrect results using __uint128_t

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|incorrect results using |[8/9/10/11 Regression]
   |__uint128_t |incorrect results using
   ||__uint128_t
 CC||jakub at gcc dot gnu.org
  Component|c++ |tree-optimization
   Target Milestone|--- |8.5

--- Comment #2 from Jakub Jelinek  ---
Started with r5-424-g807e902eea17f3132488c256c963823976b2348c
C testcase that just needs -O2:
__attribute__ ((noipa)) void
foo (__uint128_t *x)
{
  asm volatile ("" : : "r" (x) : "memory");
}

int
main ()
{
  __uint128_t a = ((__uint128_t) 1) << 65;
  __uint128_t b = a;
  __uint128_t n;
  foo ();
  n = b;
  while (n >= a)
n -= a;
  if ((int) (n >> 64) != 0)
__builtin_abort ();
  return 0;
}

Works fine with unsigned long long instead of __uint128_t and 33 instead of 65
and 32 instead of 64, so either a wide-int bug or number of loop iterations
bug.
On the ullong testcase, e.g. profile_estimate prints:
Analyzing # of iterations of loop 1
  exit condition 8589934591 < [n_8, + , 18446744065119617024]
  bounds on difference of bases: -8589934591 ... 18446744065119617024
  result:
# of iterations n_8 / 8589934592, bounded by 2147483647
but on the uint128_t testcase it prints:
Analyzing # of iterations of loop 1
  exit condition 0x1 < [n_8, + ,
0xfffe]
  bounds on difference of bases: -36893488147419103231 ...
-18446744073709551616
  result:
# of iterations n_8 / 0x2, bounded by 0

[Bug c++/98474] incorrect results using __uint128_t

[jeffhurchalla at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Jeff Hurchalla  ---
If I change only the optimization level in the compile command to -O1, then
echo prints the correct result 0.

I have a non-minimal (but still very small) test file on godbolt at
https://godbolt.org/z/4oqnYn
The godbolt link goes to two separate tests which produce the incorrect results
- you can toggle between them with the "#if 1".

There are two interesting things about the godbolt tests:
1. I get correct results when I choose "x86_64 gcc 4.9.3" and incorrect results
when I choose "x86_64 gcc 5.1".  The few earlier versions than 4.9.3 that I
tried were correct also, and the few later versions than 5.1 (including trunk)
that I tried were incorrect also.
2. Using "x86_64 gcc 10.2" (and I'd suspect any version >= 5.1), the tests
print to stdout
"inside 'if'"
but they do not print
"inside 'while'"
This should be impossible.

[Bug c++/98474] New: incorrect results using __uint128_t

[jeffhurchalla at gmail dot com via Gcc-bugs]

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

Bug ID: 98474
   Summary: incorrect results using __uint128_t
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeffhurchalla at gmail dot com
  Target Milestone: ---

g++ version: g++-10 (Ubuntu 10.1.0-2ubuntu1~18.04) 10.1.0
x64 CPU: Intel(R) Core(TM) i5-4570S CPU @ 2.90GH

Compile command used:
g++-10 -O3 -std="gnu++11" -v -save-temps -fsanitize=undefined -Wall -Wextra
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations test.cpp -o
testbug

It compiles cleanly for me, with no warnings or errors.  After compiling, I use
the following commands:
./testbug
echo $?

Echo prints 2 for me, but the result should be 0.
The preprocessed version of test.cpp is the same as the non-preprocessed
version.  It follows here:

__attribute__ ((noinline))
__uint128_t foo(__uint128_t& x)
{
return x;
}

int main()
{
using T = __uint128_t;
T two65 = static_cast(1) << 65;
T two65_copy = two65;

foo(two65_copy);
T n = two65_copy;

while (n >= two65)
n -= two65;

return static_cast(n >> 64);
}

[Bug libstdc++/98466] Debug Mode iterators for unordered containers do not implement N3644

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

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

François Dumont  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |fdumont at gcc dot 
gnu.org
   Last reconfirmed||2020-12-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

[Bug fortran/93685] [9/10/11 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Fixed on master for gcc-11, and on 10- and 9-branches.

Due to a glitch in the commit message for master no automatic commit message
was attached to this PR.  This was manually corrected for the branches.

Thanks for the report!

[Bug fortran/93685] [9/10/11 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

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

commit r9-9141-gfe37f4aac179e8a7489fa5492dd56dce95f094b2
Author: Harald Anlauf 
Date:   Fri Dec 25 15:40:39 2020 +0100

PR fortran/93685 - ICE in gfc_constructor_append_expr, at
fortran/constructor.c:135

Fix handling of F2018 enhancements to DATA statements that allows
initialization of pointer components to derived types, and adjust error
handling for the CHARACTER case.

gcc/fortran/ChangeLog:

* data.c (gfc_assign_data_value): Restrict use of
create_character_initializer to constant initializers.
* trans-expr.c (gfc_conv_initializer): Ensure that character
initializer is constant, otherwise fall through to get the same
error handling as for non-character cases.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr93685_1.f90: New test.
* gfortran.dg/pr93685_2.f90: New test.

(cherry picked from commit 6e36772ba6a8173318c173508bd3254e4140b726)

[Bug fortran/92736] [9 Regression] Error when using a variable from a module in a submodule and its parent module.

[mehdi.chinoune at hotmail dot com via Gcc-bugs]

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

--- Comment #9 from Chinoune  ---
Since no one is going to backport the fix, should we close it as "won't fix"?

[Bug c++/98441] [11 Regression] member function pointer incorrectly parsed as having trailing return type

[daniel.santos at pobox dot com via Gcc-bugs]

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

--- Comment #6 from Daniel Santos  ---
(In reply to Jonathan Wakely from comment #5)
> That's why you're asked to provide the output of 'gcc -v' by the
> instructions at https://gcc.gnu.org/bugs/ (because we can't guess that your
> 10.2.0 is different from ours).

You're correct; my apologies.  Sorry for the extra work!

[Bug libstdc++/98473] New: std::vector::insert(pos, first, last) doesn't compile for T which has a deleted assignment operator

[b.stanimirov at abv dot bg via Gcc-bugs]

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

Bug ID: 98473
   Summary: std::vector::insert(pos, first, last) doesn't
compile for T which has a deleted assignment operator
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.stanimirov at abv dot bg
  Target Milestone: ---

Create a class `X` which is copy-constructible but not copy-assignable

```
struct X {
X();
X(const X&);
X& operator=(const X&) = delete; // !!
X(X&&) noexcept;
X& operator=(X&&) noexcept;
int data = 54;
};
```

Have vectors of X `a` and `b`. Try to add all elements of b at the front of a:

```
void add_to_front(std::vector& a, const std::vector& b) {
a.insert(a.begin(), b.begin(), b.end());
}
```

Live demo: https://godbolt.org/z/K1WT8n

It doesn't compile. My guess is that code which will never get invoked, still
needs to compile (or, worse yet, copy assignment does get invoked?!)

The only way to achieve the desired behavior efficiently is to use a custom
vector implementation. There is a stackoverflow question which has some
workarounds *with worse performance*:
https://stackoverflow.com/questions/65489039/how-to-efficiently-insert-multiple-copy-constructible-but-not-copy-assignable-el

This does compile and work on msvc, so a compile-time check for the
copy-assignment code is possible.

As pointed out in the stackoverflow thread, copy-assignability is not listed
here: https://en.cppreference.com/w/cpp/container/vector/insert#Parameters

This looks like a bug in libstdc++ (as opposed to a omission by the standard)

[Bug fortran/97612] [F08] Structure constructor of type with nested allocatable array components fails to compile

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r11-6365-geeb145317b42d5203056851435457d9189a7303d
Author: Paul Thomas 
Date:   Tue Dec 29 17:44:48 2020 +

Fortran: Correct missing structure constructor comps. [PR97612].

2020-12-29  Paul Thomas  

gcc/fortran
PR fortran/97612
* primary.c (build_actual_constructor): Missing allocatable
components are set unallocated using EXPR_NULL. Then missing
components are tested for a default initializer.

gcc/testsuite/
PR fortran/97612
* gfortran.dg/structure_constructor_17.f90: New test.

[Bug fortran/93833] [8/9/10/11 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r11-6364-gfeae0af82753e06fbff6103da5fbb3b28e1ddbd7
Author: Paul Thomas 
Date:   Tue Dec 29 17:37:25 2020 +

Fortran: Fix deferred character lengths in array constructors [PR93833].

2020-12-29  Paul Thomas  

gcc/fortran
PR fortran/93833
* trans-array.c (get_array_ctor_var_strlen): If the character
length backend_decl cannot be found, convert the expression and
use the string length. Clear up some minor white space issues
in the rest of the file.

gcc/testsuite/
PR fortran/93833
* gfortran.dg/deferred_character_36.f90 : New test.

[Bug fortran/98458] PRINT the array constructed from implied do-loop throw ICE

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #4 from Paul Thomas  ---
Created attachment 49856
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49856=edit
Fix for the PR

Thank you for the report on this problem.

The attached patch fixes the problem and regression tests OK. I need to do a
bit more thinking about it because I was unable to find a point in general
expression simplification where the fix could be applied. Instead, it only
seems to work in the simplification of intrinsic functions. Fortunately, this
seems to be the only place where it is needed.

Paul

[Bug target/95361] Segfault when generating an epilogue for a partly-shrinked-wrapped SVE frame

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
The original testcase requires support for built-in SVE vector types,
which were only added in GCC 10.  I'm not planning to backport
further unless there's a different testcase that needs the
same fix.

[Bug tree-optimization/98467] gcc optimizes tapping code away

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
-fdelete-null-pointer-checks is generally an option that tells whether it is
possible to have objects at address 0 (-fno-delete-null-pointer-checks) or not.
So the use above seems to be correct.
Anything can happen on UB and NULL pointer dereference is UB, so I don't see
why you expect anything in particular.

[Bug fortran/98472] New: internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:7352

[ruicoelhopedro at hotmail dot com via Gcc-bugs]

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

Bug ID: 98472
   Summary: internal compiler error: in gfc_conv_expr_descriptor,
at fortran/trans-array.c:7352
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ruicoelhopedro at hotmail dot com
  Target Milestone: ---

This occurs during an allocation whose source is the result of an elemental
function in a polymorphic class.
Tested in versions 7.5.0, 9.2.1 and 10.2.0, report below is shown for version
10.2.0




$ cat mwe.f90
module a
type, abstract :: base
contains
procedure(elem_func), deferred, nopass :: add
end type base

type, extends(base) :: derived
contains
procedure, nopass :: add => add_derived
end type derived

abstract interface
elemental function elem_func(x, y) result(out)
integer, intent(in) :: x, y
integer :: out
end function elem_func
end interface

contains
elemental function add_derived(x, y) result(out)
integer, intent(in) :: x, y
integer :: out
out = x + y
end function add_derived
end module a

program main
use a
integer, dimension(:), allocatable :: vec
class(base), allocatable :: instance
allocate(derived :: instance)
allocate(vec, source=instance%add([1, 2], [1, 2]))
end program main




$ gfortran mwe.f90
mwe.f90:32:0:

   32 | allocate(vec, source=instance%add([1, 2], [1, 2]))
  | 
internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:7352
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.




$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)

[Bug tree-optimization/98467] gcc optimizes tapping code away

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #2 from Bernd Edlinger  ---
I debugged a bit in when we decide this function is const.
That appears to be in gcc/ipa-fnsummary.c:

/* Return true if T is a pointer pointing to memory location that is local
   for the function (that means, dead after return) or read-only.  */

bool
points_to_local_or_readonly_memory_p (tree t)
{
  /* See if memory location is clearly invalid.  */
  if (integer_zerop (t))
return flag_delete_null_pointer_checks;
  if (TREE_CODE (t) == SSA_NAME)
return !ptr_deref_may_alias_global_p (t);
  if (TREE_CODE (t) == ADDR_EXPR)
return refs_local_or_readonly_memory_p (TREE_OPERAND (t, 0));
  return false;
}



And indeed the "problem" can be fixed by using -fno-delete-null-pointer-checks.
>From the documentation in gcc/doc/invoke.texi I would never have guessed
what this option does here:

"@item -fdelete-null-pointer-checks
@opindex fdelete-null-pointer-checks
Assume that programs cannot safely dereference null pointers, and that
no code or data element resides at address zero.
This option enables simple constant
folding optimizations at all optimization levels.  In addition, other
optimization passes in GCC use this flag to control global dataflow
analyses that eliminate useless checks for null pointers; these assume
that a memory access to address zero always results in a trap, so
that if a pointer is checked after it has already been dereferenced,
it cannot be null."


It is only supposed to remove checks for null-pointer, not the other
way round...

[Bug sanitizer/98206] UBSan: Casting from multiple inheritance base to derived class triggers undefined behavior sanitizer

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 49855
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49855=edit
gcc11-pr98206.patch

Untested fix.

[Bug sanitizer/98206] UBSan: Casting from multiple inheritance base to derived class triggers undefined behavior sanitizer

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

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

--- Comment #3 from Jakub Jelinek  ---
Testcase without any headers:
template 
struct Base1
{
  char c1;
};

template 
struct Base2
{
  char c2;
  auto  () const { return static_cast (*this); }
};

struct X : public Base1, public Base2
{
  X (const char *d) : data{d} {}
  const char *data;
};

int
main ()
{
  X x = X{"cheesecake"};
  const char *p = x.get2 ().data;
}

The problem is that ubsan_maybe_instrument_reference is done only during
genericization, but we fold:
(const struct X &) ((const struct Base2 *) this + 18446744073709551615)
to
(const struct X &) this + 18446744073709551615
much earlier than that (during parsing even!), and if it wasn't during parsing,
it would be during fully folding of the function which is also before
genericization.
In fold-const.c, it is the:
  /* Convert (T1)(X p+ Y) into ((T1)X p+ Y), for pointer type, when the new
 cast (T1)X will fold away.  We assume that this happens when X itself
 is a cast.  */
  if (POINTER_TYPE_P (type)
  && TREE_CODE (arg0) == POINTER_PLUS_EXPR
  && CONVERT_EXPR_P (TREE_OPERAND (arg0, 0)))
{
  tree arg00 = TREE_OPERAND (arg0, 0);
  tree arg01 = TREE_OPERAND (arg0, 1);

  return fold_build_pointer_plus_loc
   (loc, fold_convert_loc (loc, type, arg00), arg01);
}
optimization that does that.
So, one way around this is for
!in_gimple_form && sanitize_flags_p (SANITIZE_ALIGNMENT)
to avoid the above optimization if type has higher alignment than the p+ first
operand's type.

[Bug c++/98463] [11 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:5491 by r11-2720

[romain.geissler at amadeus dot com via Gcc-bugs]

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

--- Comment #3 from Romain Geissler  ---
Hi,

While I initially flagged this as a regression in gcc 11, it's indeed a latent
gcc bug which predates gcc 11. What makes it for my specific test case a
regression is because now tuple use [[no_unique_address]] which seems to be
already identified as creating ICEs in issues #96863 and #97804.

Cheers,
Romain

[Bug libgcc/97543] powerpc64le: libgcc has unexpected long double in .gnu_attribute

[gustavowalbon at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Gustavo Walbon  ---
Michael,

Works with GCC v10.
I backported this patch for the Alpine[1] gcc v10 and then I used the libgcc
package to test. I have used the binutils v2.35.1 with the warning of the GNU
Attribute and the patch doesn't show the warning.


1 -
https://github.com/walbon/aports/commit/f188c0b799df8550c595d6a94ffc6dab0254d11a

Thanks Michael

[Bug rtl-optimization/98289] [8/9/10 Regression] [x86] Suboptimal optimization of stack usage when function call does not occur

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
Summary|[8/9/10/11 Regression]  |[8/9/10 Regression] [x86]
   |[x86] Suboptimal|Suboptimal optimization of
   |optimization of stack usage |stack usage when function
   |when function call does not |call does not occur
   |occur   |
   Target Milestone|8.5 |11.0
 Resolution|--- |FIXED

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk, no plans to backport.

[Bug target/98461] Suboptimal codegen for negating a movemask

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug libstdc++/93456] No overflow check in __atomic_futex_unsigned_base::_M_futex_wait_until

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

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #8 from Alexandre Oliva  ---
On arm-vxworks, that has 32-bit time_t, this also fails.  The initial
gthread_cond_timedwait sleeps for a second or two, then it times out and
returns.  However, the wider C++ types used in the
condition_variable::__wait_until_impl check for a timeout and decide we have
NOT timed out, so the __Predicate version of __wait_until sees the condition
it's waiting for hasn't been met, and attempts to wait again.  But since the
timeout has already been reached, gthread_cond_wait returns immediately, and we
busy-loop.  Since vxworks won't preempt threads, and we're not in a SMP
configuration, the async call never gets a chance to complete, and the test
runs till the rlimit runs out.

While investigating this, I noticed that adding __gthread_yield calls in the
__wait_until_impl loop, the other thread gets enough cycles to complete, and
the test passes, but I thought that would defeat the point of the test, right?

[Bug middle-end/56719] missed optimization: i > 0xffff || i*4 > 0xffff

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

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 49853
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49853=edit
gcc11-pr56719.patch

Untested patch to implement the #c8 optimization.

[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree

[mscfd at gmx dot net via Gcc-bugs]

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

--- Comment #3 from martin  ---
Sorry for the noise, but as this gives big reductions in compilation time it is
quite important to me (and probably other big module based projects).

I just realised that I mixed up gfc_symtree->name and gfc_symtree->n.sym->name.
The reason why find_symbol traverses the whole tree in the worst case is that
it is ordered by gfc_symtree->name but it looks for gfc_symtree->n.sym->name.

So far I got the impression that either gfc_symtree->name is a unique name
("@xxx") or equal to gfc_symtree->n.sym->name (if n.sym!=NULL). In this case,
the following patch should do the trick and traverse only log(N) of the tree:

diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 4c6ff22d5c1..8dc59e25d46 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -4659,10 +4659,20 @@ find_symbol (gfc_symtree *st, const char *name,
return st;
 }

+  c = strcmp (name, st->name);
+  if (c < 0)
+retval = find_symbol (st->left, name, module, generic);
+  else if (c > 0)
+retval = find_symbol (st->right, name, module, generic);
+  else
+retval = NULL;
+
+/* original traverse
   retval = find_symbol (st->left, name, module, generic);

   if (retval == NULL)
 retval = find_symbol (st->right, name, module, generic);
+*/

   return retval;
 }

[Bug target/97012] [SVE] Extend PR96357 to other aarch64-sve.md patterns

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Applied to GCC 10 as r10-9111.

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #9 from John Paul Adrian Glaubitz  ---
I have bisected this now and it turns out, the regression was introduced by:

commit eede1a6bf3a4f33fa5afef9e4dfc80c4dd89eeb3
Author: Nick Clifton 
Date:   Mon Jun 18 10:39:01 2018 +

Ensure that control characters in user supplied error and warning messages
are escaped.

PR 84195
* tree.c (escaped_string): New class.  Converts an unescaped
string into its escaped equivalent.
(warn_deprecated_use): Use the new class to convert the
deprecation message, if present.
(test_escaped_strings): New self test.
(test_c_tests): Add test_escaped_strings.

From-SVN: r261697

Interestingly, later SVN/git revisions still built fine, with 20191130 being
the last good one:

> https://buildd.debian.org/status/logs.php?pkg=gcc-snapshot=m68k

I am building with the following command line:

../configure --with-gcc-major-version-only --program-prefix= --enable-shared
--enable-linker-build-id --disable-nls --enable-clocale=gnu
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libssp --disable-libitm
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support
--enable-plugin --with-system-zlib --disable-libphobos --enable-objc-gc=auto
--enable-multiarch --disable-werror --disable-werror --disable-multilib
--enable-checking=yes --build=m68k-linux-gnu --host=m68k-linux-gnu
--target=m68k-linux-gnu --enable-languages=c++,jit --enable-host-shared
--disable-bootstrap && make -j64

from git. No local Debian patches applied.

My suspicion is that either this change triggers a bug in some external library
or a change in an external library made this bug visible.

Any suggestions? The only thing that it's odd on m68k is the 16-bit native
alignment, but I'm not sure whether that's relevant here.

[Bug libstdc++/98471] libstdc++ fails to build with clang on windows because of filesystem bug

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target|mingw-w64-x86_64, windows   |mingw-w64-x86_64
   |10. clang12 |
   Host|mingw-w64-x86_64, windows   |
   |10. clang12 |
 Ever confirmed|0   |1
   Last reconfirmed||2020-12-29
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug c++/98441] [11 Regression] member function pointer incorrectly parsed as having trailing return type

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Version|10.2.0  |11.0
  Known to work|10.1.0  |10.2.0

--- Comment #5 from Jonathan Wakely  ---
That's why you're asked to provide the output of 'gcc -v' by the instructions
at https://gcc.gnu.org/bugs/ (because we can't guess that your 10.2.0 is
different from ours).

[Bug c++/98469] ICE in cxx_eval_constant_expression, at cp/constexpr.c:6350

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2020-12-29

--- Comment #1 from Jakub Jelinek  ---
Created attachment 49852
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49852=edit
gcc11-pr98469.patch

Untested fix.  Though, can't really reproduce with std::bit_cast, so the
validity of the testcase is questionable.

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[bhavana.kilambi at blackfigtech dot com via Gcc-bugs]

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

--- Comment #12 from Bhavana Kilambi  
---
Created attachment 49851
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49851=edit
a tweak to fix the issue

Hi Martin, My sincere apologies for the delay in replying and also for
uploading a faulty patch. I have attached another patch for this issue. It is
more of a tweak than a straight-forward approach to fixing the issue. 
Kindly let me know if this is ok or if any modifications are required. 
It has been tested for regressions on trunk and no failures have been found. 

Thanks

[Bug c++/98441] [11 Regression] member function pointer incorrectly parsed as having trailing return type

[daniel.santos at pobox dot com via Gcc-bugs]

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

--- Comment #4 from Daniel Santos  ---
Created attachment 49850
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49850=edit
Gentoo gcc 10.2.0-r2 patches

(In reply to Jonathan Wakely from comment #3)
> (In reply to Daniel Santos from comment #0)
> > However, it builds on GCC 9 and is alleged to build on MSVC.  The above
> > example is simplified from the original sources:
> 
> Are you sure this fails with 10.2.0? I only see it fail with 11.0 and not
> gcc version 10.2.1 20201125 (but I didn't try a newer build from the gcc-10
> branch).

Well, yes, but this is Gentoo gcc-10.2.0-r2, so includes a patchset (attached).
 In that, 34_all_fundecl-ICE-PR95820.patch contains the following:

It's an unofficial backport of PR95820 where gcc ICEs on
invalid syntax. As creduce frequently end up in these ICEs
as in #730406 let's backport it to gcc-10.

https://gcc.gnu.org/PR95820
https://bugs.gentoo.org/730406
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -12029,14 +12029,11 @@ grokdeclarator (const cp_declarator *declarator,

/* Handle a late-specified return type.  */
tree late_return_type = declarator->u.function.late_return_type;
-   if (funcdecl_p
-   /* This is the case e.g. for
-  using T = auto () -> int.  */
-   || inner_declarator == NULL)
+   if (true)
  {
if (tree auto_node = type_uses_auto (type))
  {
-   if (!late_return_type)
+   if (!late_return_type && funcdecl_p)
  {
if (current_class_type
&& LAMBDA_TYPE_P (current_class_type))

[Bug c++/98461] Suboptimal codegen for negating a movemask

[denis.yaroshevskij at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Denis Yaroshevskiy  ---
(In reply to Hongtao.liu from comment #3)
> Could you mark this bug as blocks PR98375 

Done?

> ... waiting for Stage 1 of GCC 12 to be applied.)

So. the next gcc should have a fix? Fantastic! Will it also work for 128 bit
registers?

[Bug c++/98471] New: libstdc++ fails to build with clang on windows because of filesystem bug

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 98471
   Summary: libstdc++ fails to build with clang on windows because
of filesystem bug
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 49849
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49849=edit
working patch to fix the issue

#include

int main()
{

}

D:\hg\fast_io\.tmp>clang++ -o filesystem filesystem.cc -Ofast -std=c++20 -s
In file included from filesystem.cc:1:
In file included from D:\msys64\mingw64\include\c++\11.0.0\filesystem:45:
D:\msys64\mingw64\include\c++\11.0.0\bits/fs_path.h:252:15: error: invalid use
of incomplete type
  'std::filesystem::filesystem_error'
throw filesystem_error(
  ^
D:\msys64\mingw64\include\c++\11.0.0\bits/fs_fwd.h:58:9: note: forward
declaration of
  'std::filesystem::filesystem_error'
  class filesystem_error;
^
In file included from filesystem.cc:1:
In file included from D:\msys64\mingw64\include\c++\11.0.0\filesystem:45:
D:\msys64\mingw64\include\c++\11.0.0\bits/fs_path.h:252:9: error: cannot throw
object of incomplete type
  'std::filesystem::filesystem_error'
throw filesystem_error(
^ ~
D:\msys64\mingw64\include\c++\11.0.0\bits/fs_fwd.h:58:9: note: forward
declaration of
  'std::filesystem::filesystem_error'
  class filesystem_error;
^
2 errors generated.