[Bug c++/97438] [accepts-invalid] coroutines accepts prmomise type with both return_value() and return_void()

[avi--- via Gcc-bugs]

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

--- Comment #5 from Avi Kivity  ---
No pressing reason to backport (for me gcc coroutines are useless anyway due to
95137)

[Bug rtl-optimization/97497] gcse wrong code generation with partial register clobbers

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

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

--- Comment #3 from Andreas Krebbel  ---
Created attachment 49405
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49405=edit
testcase

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

[christophe.leroy at csgroup dot eu via Gcc-bugs]

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

--- Comment #24 from Christophe Leroy  ---
Created attachment 49403
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49403=edit
pipe.i from build of fs/pipe.o with GCC 9.2

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

[christophe.leroy at csgroup dot eu via Gcc-bugs]

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

--- Comment #25 from Christophe Leroy  ---
Created attachment 49404
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49404=edit
pipe.s from build of fs/pipe.o with GCC 9.2

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

[christophe.leroy at csgroup dot eu via Gcc-bugs]

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

--- Comment #23 from Christophe Leroy  ---
(In reply to Jan Hubicka from comment #19)
> 
> It is always possible to always_inline functions that are intended to be
> always inlined.
> Honza

Yes and I sent a patch for that to the Linux kernel, but what I would like to
understand is why does GCC 10 completely fails to inline that while GCC 9 was
doing things properly ?

Find attached the same temp files generated with GCC 9. GCC9 sees that
get_order() is not used and doesn't generate it.

[Bug c++/95310] [concepts] Unrelated template parameters printed in diagnostic

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

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

--- Comment #4 from Patrick Palka  ---
(In reply to ensadc from comment #3)
> When verifying the fix, I noticed a new bug:

Thanks for the heads up.

> 
> 
> template  requires true
> using iter_reference_t = decltype(*T{});
> 
> template 
> struct result {
>   using type = iter_reference_t;
> };
> 
> template 
> concept indirectly_writable = requires(Out&& o, T&& t) {
>   iter_reference_t(*o) = 0;
> };
> 
> template
> requires indirectly_writable>
> void copy(In in, Out out) {}
> 
> void test(const int* p, int* q) {
> copy(q, p);
> }
> 
> 
> : In function 'void test(const int*, int*)':
> :19:14: error: no matching function for call to 'copy(int*&, const
> int*&)'
>19 | copy(q, p);
>   |  ^
> :16:6: note: candidate: 'template  requires 
> indirectly_writable void copy(In, Out)'
>16 | void copy(In in, Out out) {}
>   |  ^~~~
> :16:6: note:   template argument deduction/substitution failed:
> :16:6: note: constraints not satisfied
> : In substitution of 'template  requires 
> indirectly_writable void copy(In, Out) [with In = int*;
> Out = const int*]':
> :19:14:   required from here
> :10:9:   required for the satisfaction of 'indirectly_writable iter_reference_t >' [with Out = const int*; In = int*]
> :10:31:   in requirements with 'Out&& o', 'T&& t' [with T = int&;
> Out = const int*]
> :11:29: note: the required expression 'decltype(*{})(*o)=0' is
> invalid
>11 |   iter_reference_t(*o) = 0;
>   |   ~~^~~
> cc1plus: note: set '-fconcepts-diagnostics-depth=' to at least 2 for more
> detail
> 
> 
> In
> 
>   :10:9:   required for the satisfaction of
> 'indirectly_writable >' [with Out = const int*; In
> = int*]
> 
> Note the mismatch between `F` and `In`.
> 
> GCC 10.2 prints `F = int*` instead of `In = int*`:
> 
>   :10:9:   required for the satisfaction of
> 'indirectly_writable >' [with Out = const int*; F =
> int*]
> 
> The name `F` comes from a completely unrelated class template, but at least
> the names match in GCC 10.2.
> 
> (Interestingly, the alias template is not expanded in this line.)

Hmm, so the r11-3373 patch fixed only the printing of template parameters
within the constraint's parameter mapping, i.e. within the [with ...] part of
the diagnostic.  But as your latest testcase shows, within the diagnostic the
constraint itself could also refer to an unrelated template parameter.  To fix
this part of the diagnostic I think we would have to more generally fix PR66968
once and for all..

[Bug c++/94799] [8/9/10 Regression] Calling a member template function fails

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

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

--- Comment #14 from Marek Polacek  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556517.html

[Bug bootstrap/97499] build dos cross compiler ICE

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #1 from fdlbxtqi  ---
/gcc_dos_build/./gcc/xgcc -B/gcc_dos_build/./gcc/
-B/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/bin/
-B/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/lib/ -isystem
/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/include -isystem
/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/sys-include-g -O2 -O2  -g -O2
-DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include   -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -I. -I. -I../.././gcc
-I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc
-I../../../gcc/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS
-Wno-missing-prototypes -Wno-type-limits -o fixunstfsi.o -MT fixunstfsi.o -MD
-MP -MF fixunstfsi.dep  -c ../../../gcc/libgcc/soft-fp/fixunstfsi.c
../../../gcc/libgcc/config/i386/sfp-exceptions.c: In function
'__sfp_handle_exceptions':
../../../gcc/libgcc/config/i386/sfp-exceptions.c:71:7: internal compiler error:
Segmentation fault
   71 |   float f = 1.0f, g = 0.0f;
  |   ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed sour/gcc_dos_build/./gcc/xgcc -B/gcc_dos_build/./gcc/
-B/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/bin/
-B/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/lib/ -isystem
/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/include -isystem
/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/sys-include-g -O2 -O2  -g -O2
-DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include   -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -I. -I. -I../.././gcc
-I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc
-I../../../gcc/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS
-Wno-missing-prototypes -Wno-type-limits -o floatsitf.o -MT floatsitf.o -MD -MP
-MF floatsitf.dep  -c ../../../gcc/libgcc/soft-fp/floatsitf.c
ce if appropriate.
See  for instructions.
/gcc_dos_build/./gcc/xgcc -B/gcc_dos_build/./gcc/
-B/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/bin/
-B/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/lib/ -isystem
/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/include -isystem
/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/sys-include-g -O2 -O2  -g -O2
-DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include   -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -I. -I. -I../.././gcc
-I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc
-I../../../gcc/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS
-Wno-missing-prototypes -Wno-type-limits -o floatunsitf.o -MT floatunsitf.o -MD
-MP -MF floatunsitf.dep  -c ../../../gcc/libgcc/soft-fp/floatunsitf.c
make[1]: *** [../../../gcc/libgcc/static-object.mk:17: sfp-exceptions.o] Error
1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory '/gcc_dos_build/i586-pc-msdosdjgpp/libgcc'
make: *** [Makefile:12394: all-target-libgcc] Error 2

[Bug bootstrap/97499] New: build dos cross compiler ICE

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 97499
   Summary: build dos cross compiler ICE
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

../../../gcc/libgcc/config/i386/sfp-exceptions.c: In function
'__sfp_handle_exceptions':
../../../gcc/libgcc/config/i386/sfp-exceptions.c:71:7: internal compiler error:
Segmentation fault
   71 |   float f = 1.0f, g = 0.0f;
  |   ^
libbacktrace could not find executable to open
Please submit a full bug report,

[Bug target/97473] Spilled function parameters not aligned properly on multiple non-x86 targets

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #4 from Hans-Peter Nilsson  ---
(In reply to Richard Biener from comment #3)
> To not disrupt the ABI such parameters have to be copied in the callee to
> appropriately aligned stack slots or (with disrupting the ABI), passed
> by reference.
> 
> I think separate bugs, one for each affected target, are appropriate here.

This definitely looks like a dup of PR84877.

If that one should be split into separate target-specific PRs, then that's a
separate issue.

[Bug preprocessor/97498] New: #pragma GCC diagnostic ignored "-Wunused-function" inconsistent

[matthewp515 at gmail dot com via Gcc-bugs]

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

Bug ID: 97498
   Summary: #pragma GCC diagnostic ignored "-Wunused-function"
inconsistent
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthewp515 at gmail dot com
  Target Milestone: ---

Ubuntu Linux 20.04


#define STR(x) #x
#define WIGNORE(x, instrs) \
_Pragma("GCC diagnostic push") \
_Pragma(STR(GCC diagnostic ignored #x)) \
instrs \
_Pragma("GCC diagnostic pop")

// REPLACE

int main(void) {return 1;}


When REPLACE is replaced with:

WIGNORE(-Wunused-function,
static int f(int a) {return a + 1;}
)

The command:

gcc main.c -Wall -Werror -Wextra

fails (-Werror=unused-function). However, breaking up the command into separate
preprocessing and compilation stages:

gcc -E main.c -Wall -Werror -Wextra | gcc -x c -

passes.

When the macro is unwound by REPLACE being replaced with:

_Pragma("GCC diagnostic push");
_Pragma("GCC diagnostic ignored \"-Wunused-function\"");
static int f(int p) {return p + 1;}
_Pragma("GCC diagnostic pop");

The first command then passes. By adding a single backslash (\) right after the
implementation of f, as is required to keep the WIGNORE macro all as one, the
command fails. But how else can the macro be constructed?

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #30 from Andrew Macleod  ---
On 10/19/20 6:40 PM, bergner at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
>
> --- Comment #28 from Peter Bergner  ---
> (In reply to Andrew Macleod from comment #25)
>> Wonder if it was suppose to be something like:
>>
>>
>> /* Vector pair and vector quad support.  */
>> if (TARGET_EXTRA_BUILTINS)
>>   {
>> -  tree oi_uns_type = make_unsigned_type (256);
>> -  vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
>> +  vector_pair_type_node = make_unsigned_type (256);
>> SET_TYPE_MODE (vector_pair_type_node, POImode);
>> layout_type (vector_pair_type_node);
>> lang_hooks.types.register_builtin_type (vector_pair_type_node,
>>"__vector_pair");
>>   
>> -  tree xi_uns_type = make_unsigned_type (512);
>> -  vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
>> +  vector_quad_type_node = make_unsigned_type (512);
>> SET_TYPE_MODE (vector_quad_type_node, PXImode);
>> layout_type (vector_quad_type_node);
>> lang_hooks.types.register_builtin_type (vector_quad_type_node,
> So this passed bootstrap and regtesting with no regressions.
>
> Is this really the correct fix?  Don't we want a distinct type compared to the
> unsigned type returned from make_unsigned_type()?
>
I actually dont know, Richi might have to comment on that.. Nothing was 
referring to the original unsigned_type that was created?  Its just 
orphaned?

tree
make_unsigned_type (int precision)
{
   tree type = make_node (INTEGER_TYPE);

   TYPE_PRECISION (type) = precision;

   fixup_unsigned_type (type);
   return type;
}


All it does is create a new node, then fixup goes and creates the MIN 
and MAX fields and sets a few other little things. The only reason 
we saw the old unsigned type is we were picking it up from the MAX and 
MIN fields,... which  were set to the original type.

it sure *seems* like that is a resonable fix.  Its not like that first 
node is creating a system wide node?

our type system is a bit, umm, flakey,  but it seems reasonable to me.   
:-)  And its in the spirit of what his patch was doing...

What could possibly go wrong? :-) :-)

Andrew

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

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

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

--- Comment #29 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

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

commit r11-4080-g6e02de946125c36871bd4d8eff21f7f88f01a8aa
Author: Andrew MacLeod 
Date:   Mon Oct 19 19:04:40 2020 -0400

Use precision and sign to compare types for ranges

Sanity check ranges by comparing just SIGN and PRECISION.

gcc/
PR tree-optimization/97360
* gimple-range.h (range_compatible_p): New.
* gimple-range-gori.cc (is_gimple_logical_p): Use
range_compatible_p.
(range_is_either_true_or_false): Ditto.
(gori_compute::outgoing_edge_range_p): Cast result to the correct
type if necessary.
(logical_stmt_cache::cacheable_p): Use range_compatible_p.
* gimple-range.cc (gimple_ranger::calc_stmt): Check
range_compatible_p
before casting the range.
(gimple_ranger::range_on_exit): Use range_compatible_p.
(gimple_ranger::range_on_edge): Ditto.

gcc/testsuite/
* gcc.dg/pr97360-2.c: New test.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

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

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

--- Comment #28 from Peter Bergner  ---
(In reply to Andrew Macleod from comment #25)
> Wonder if it was suppose to be something like:
> 
> 
>/* Vector pair and vector quad support.  */
>if (TARGET_EXTRA_BUILTINS)
>  {
> -  tree oi_uns_type = make_unsigned_type (256);
> -  vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
> +  vector_pair_type_node = make_unsigned_type (256);
>SET_TYPE_MODE (vector_pair_type_node, POImode);
>layout_type (vector_pair_type_node);
>lang_hooks.types.register_builtin_type (vector_pair_type_node,
>   "__vector_pair");
>  
> -  tree xi_uns_type = make_unsigned_type (512);
> -  vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
> +  vector_quad_type_node = make_unsigned_type (512);
>SET_TYPE_MODE (vector_quad_type_node, PXImode);
>layout_type (vector_quad_type_node);
>lang_hooks.types.register_builtin_type (vector_quad_type_node,

So this passed bootstrap and regtesting with no regressions.

Is this really the correct fix?  Don't we want a distinct type compared to the
unsigned type returned from make_unsigned_type()?

[Bug middle-end/94169] warn for modifying getenv() result

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

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

--- Comment #4 from Martin Sebor  ---
Yes.  The recent proposal to change their signature to return const char* was 
rejected in WG14 thanks to source compatibility concerns:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2526.htm
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2565.pdf

I'm thinking of extending attribute access to annotate function return types
similarly to function arguments.  Another useful attribute is one that says:
the function returns a pointer passed to it by argument N, plus some offset
(with the offset being optional, and also specified by an argument).

[Bug target/97481] GCC ice when build with RISCV on msys2

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #5 from fdlbxtqi  ---
(In reply to Jim Wilson from comment #2)
> riscv-unknown-linux-gnu is not a supported target.  You must use either
> riscv32-unknown-linux-gnu or riscv64-unknwon-linux-gnu.  Both compilers
> support both word sizes, the only difference is which is the default word
> size.  This may be part of the reason why it failed.
> 
> The attachment doesn't show any ICE.  It is just a config.log file, and I
> don't see anything interesting in there.
> 
> Note that mingw64 builds of a linux toolchain are unlikely to work as glibc
> requires a case sensitive file system.  I'd suggest using WSL2 as something
> more likely to work, but I haven't tried that myself.
> 
> It looks like you have a badly broken compiler build.  You will need to
> figure out why it is broken.  This doesn't seem to be a gcc problem, but
> rather a build problem on your side.


unlvs@DESKTOP-DFHPDC1 MINGW64 /glibc_riscv64_build
$ ../glibc_riscv64/configure --prefix=${PREFIX}/${TARGET} --build=$(gcc
-dumpmachine) --host=${TARGET} --target=${TARGET} --disable-multilib
--disable-werror libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes
--enable-add-ons
configure: loading site script /mingw64/etc/config.site
checking build system type... x86_64-w64-mingw32
checking host system type... riscv64-unknown-linux-gnu
checking for riscv64-linux-gcc... riscv64-linux-gcc
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether riscv64-linux-gcc accepts -g... yes
checking for gcc... gcc
checking for riscv64-linux-readelf... riscv64-linux-readelf
checking for riscv64-linux-g++... riscv64-linux-g++
checking whether we are using the GNU C++ compiler... yes
checking whether riscv64-linux-g++ accepts -g... yes
checking whether riscv64-linux-g++ can link programs... no
checking for sysdeps preconfigure fragments... aarch64 alpha arc arm csky hppa
i386 m68k microblaze checking for grep that handles long lines and -e...
/usr/bin/grep
checking for egrep... /usr/bin/grep -E
mips nios2 powerpc riscv : internal compiler error: Segmentation
fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
: internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
: internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
: internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Unable to determine XLEN

unlvs@DESKTOP-DFHPDC1 MINGW64 /glibc_riscv64_build

I have tried riscv64. same issues.

[Bug c++/93297] internal compiler error: in set_constraints, at cp/constraint.cc:

[john at mcfarlane dot name via Gcc-bugs]

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

--- Comment #8 from John McFarlane  ---
And this input can generate an ICE even with the -std=c++2a switch:

   template  class a;
   template  a()->a;
   template <2> using c a;
   static_assert(c{   }

CL: g++ -v -std=c++2a source.cpp
Online: https://godbolt.org/z/dh9bfc

[Bug libstdc++/55394] Using call_once without -lpthread compiles without warning

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

--- Comment #9 from Sergei Trofimovich  ---
*** Bug 97485 has been marked as a duplicate of this bug. ***

[Bug libstdc++/97485] std::call_once crashes at runtime on glibc if not linked to libpthread: terminate called after throwing an instance of 'std::system_error': what(): Unknown error -1

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Sergei Trofimovich  ---
Ah, yes!

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

[Bug c++/93297] internal compiler error: in set_constraints, at cp/constraint.cc:

[john at mcfarlane dot name via Gcc-bugs]

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

John McFarlane  changed:

   What|Removed |Added

 CC||john at mcfarlane dot name

--- Comment #7 from John McFarlane  ---
I'm seeing what appears to be the same ICE at head (SHA b003c4b1). This is
reproducible in CE (https://godbolt.org/z/MG1sax). Output with `-v` below.

Source file is:

template  class a;
template <2> using b a;
static_assert(b{   }

=
john@carbon:~/ws/c++20/cnl/build$ g++ -v reduceme.cpp
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/home/john/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib
--prefix=/home/john/gcc-head/ --enable-languages=c,c++,lto
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201019 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
'-dumpdir' 'a-'
 /home/john/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/cc1plus -quiet -v
-imultiarch x86_64-linux-gnu -D_GNU_SOURCE reduceme.cpp -quiet -dumpdir a-
-dumpbase reduceme.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -version
-o /tmp/ccBQ8tty.s
GNU C++17 (GCC) version 11.0.0 20201019 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.0.0 20201019 (experimental), GMP version
6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring non-existent directory "/usr/local/include/x86_64-linux-gnu"
ignoring non-existent directory
"/home/john/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/home/john/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0

/home/john/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/x86_64-pc-linux-gnu

/home/john/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/backward
 /home/john/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include
 /usr/local/include
 /home/john/gcc-head/include
 /home/john/gcc-head/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++17 (GCC) version 11.0.0 20201019 (experimental) (x86_64-pc-linux-gnu)
    compiled by GNU C version 11.0.0 20201019 (experimental), GMP version
6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 898bda479bba6f05660e15f0cb7d4838
reduceme.cpp:2:11: error: expected identifier before numeric constant
2 | template <2> using b a;
  |   ^
reduceme.cpp:2:11: error: expected ‘>’ before numeric constant
reduceme.cpp:2:22: error: expected ‘=’ before ‘a’
2 | template <2> using b a;
  |  ^
reduceme.cpp:3:52: warning: alias template deduction only available with
‘-std=c++20’ or ‘-std=gnu++20’
3 | static_assert(b{   }
  |^
reduceme.cpp:3:52: internal compiler error: in set_constraints, at
cp/constraint.cc:1192
0x63dc05 set_constraints(tree_node*, tree_node*)
../../gcc/gcc/cp/constraint.cc:1192
0xa37768 alias_ctad_tweaks
../../gcc/gcc/cp/pt.c:28819
0xa37768 deduction_guides_for
../../gcc/gcc/cp/pt.c:28934
0xa37a98 do_class_deduction
../../gcc/gcc/cp/pt.c:29042
0xa37a98 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/gcc/cp/pt.c:29211
0xa8b289 finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
../../gcc/gcc/cp/semantics.c:2934
0x9e7f7a cp_parser_functional_cast
../../gcc/gcc/cp/parser.c:29749
0xa005d7 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7251
0x9e229a cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9648
0x9e402e cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9953
0x9e2bad cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:10247
0x9e2f11 cp_parser_static_assert
../../gcc/gcc/cp/parser.c:14829
0xa1bfe6 cp_parser_declaration
../../gcc/gcc/cp/parser.c:13575
0xa1c63b cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4793
0xa1c63b c_parse_file()
../../gcc/gcc/cp/parser.c:44170
0xb3948d c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
=

[Bug rtl-optimization/97497] gcse wrong code generation with partial register clobbers

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
(In reply to Andreas Krebbel from comment #1)
> Created attachment 49402 [details]
> Proposed fix
> 
> With the patch only regs are considered which aren't "fixed" assuming that
> for fixed_regs the backend takes care of only actually using the
> well-defined part of the hard regs.
I don't think this is right.  The principle is the same for
all types of register.

The idea is that a partial clobber can conservatively be treated
as a read of the old value and a set of the new value.  That might
be suboptimal, but it should never lead to wrong code.  It sounds
like there's a deeper issue here.

(BTW, the testcase attachment seems to be missing.)

[Bug preprocessor/97471] [11 Regression] ICE on using function-like macro as a non function-like macro since r11-338-g2a0225e47868fbfc

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #3 from Nathan Sidwell  ---
he shoots, he misses :(

[Bug libstdc++/97132] assume_aligned is not constexpr

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |9.4
 Status|ASSIGNED|RESOLVED

--- Comment #8 from Jonathan Wakely  ---
Fixed for 9.4 and 10.3

[Bug tree-optimization/97474] [8/9/10/11 Regression] produces wrong code with references to another field

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #8 from joseph at codesourcery dot com  ---
p and p->p are two different pointer objects, the first restricted, so 
it's not valid to use p->p to access an object that's also accessed via p 
(and modified).

This is different from the case where there is one pointer object but 
multiple expressions, indirecting through multiple other pointer objects, 
that refer to it.  For that case, of multiple expressions that all end up 
referring to the same pointer object, see bug 14192 comment 8 where I 
discuss the rule about "restrict" when pointers to pointers are involved.

[Bug target/97481] GCC ice when build with RISCV on msys2

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #4 from fdlbxtqi  ---
(In reply to Jim Wilson from comment #2)
> riscv-unknown-linux-gnu is not a supported target.  You must use either
> riscv32-unknown-linux-gnu or riscv64-unknwon-linux-gnu.  Both compilers
> support both word sizes, the only difference is which is the default word
> size.  This may be part of the reason why it failed.
> 
> The attachment doesn't show any ICE.  It is just a config.log file, and I
> don't see anything interesting in there.
> 
> Note that mingw64 builds of a linux toolchain are unlikely to work as glibc
> requires a case sensitive file system.  I'd suggest using WSL2 as something
> more likely to work, but I haven't tried that myself.
> 
> It looks like you have a badly broken compiler build.  You will need to
> figure out why it is broken.  This doesn't seem to be a gcc problem, but
> rather a build problem on your side.

Maybe I should try riscv64-linux-gnu. Thank you

[Bug libstdc++/97132] assume_aligned is not constexpr

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

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

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

https://gcc.gnu.org/g:77923ad01415f6e72af844cbef5227f5b5a9fb4b

commit r9-9003-g77923ad01415f6e72af844cbef5227f5b5a9fb4b
Author: Jonathan Wakely 
Date:   Mon Sep 21 14:28:58 2020 +0100

libstdc++: Make std::assume_aligned a constexpr function [PR 97132]

The cast from void* to T* in std::assume_aligned is not valid in a
constexpr function. The optimization hint is redundant during constant
evaluation anyway (the compiler can see the object and knows its
alignment). Simply return the original pointer without applying the
__builtin_assume_aligned hint to it when doing constant evaluation.

libstdc++-v3/ChangeLog:

PR libstdc++/97132
* include/std/memory (assume_aligned): Do not use
__builtin_assume_aligned during constant evaluation.
* testsuite/20_util/assume_aligned/1.cc: Improve test.
* testsuite/20_util/assume_aligned/97132.cc: New test.

(cherry picked from commit f10ed928e2f8ecc2c859abff8f2f9296b11b8d95)

[Bug libstdc++/97132] assume_aligned is not constexpr

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

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

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

https://gcc.gnu.org/g:90c9484b12dd8a05b5314f5cb9847df46024a194

commit r10-8913-g90c9484b12dd8a05b5314f5cb9847df46024a194
Author: Jonathan Wakely 
Date:   Mon Sep 21 14:28:58 2020 +0100

libstdc++: Make std::assume_aligned a constexpr function [PR 97132]

The cast from void* to T* in std::assume_aligned is not valid in a
constexpr function. The optimization hint is redundant during constant
evaluation anyway (the compiler can see the object and knows its
alignment). Simply return the original pointer without applying the
__builtin_assume_aligned hint to it when doing constant evaluation.

libstdc++-v3/ChangeLog:

PR libstdc++/97132
* include/std/memory (assume_aligned): Do not use
__builtin_assume_aligned during constant evaluation.
* testsuite/20_util/assume_aligned/1.cc: Improve test.
* testsuite/20_util/assume_aligned/97132.cc: New test.

(cherry picked from commit f10ed928e2f8ecc2c859abff8f2f9296b11b8d95)

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

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

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

--- Comment #27 from Peter Bergner  ---
(In reply to Peter Bergner from comment #26)
> (In reply to Andrew Macleod from comment #25)
> > Wonder if it was suppose to be something like:
> 
> Maybe? :-)   I'll report back how the build does with this.

So far better results.  My debug non-bootstrap build actually finished and I
can confirm it fixes the ICE on the test in Comment #5.  My regtest is still
running.

[Bug libfortran/97063] [ MATMUL intrinsic] The value of result is wrong when vector (step size is negative) * matrix

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

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

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

https://gcc.gnu.org/g:53325dec8e01775af3eb9231d10f2afa1b8d5559

commit r10-8912-g53325dec8e01775af3eb9231d10f2afa1b8d5559
Author: Harald Anlauf 
Date:   Sun Oct 18 20:15:26 2020 +0200

PR libfortran/97063 - Wrong result for vector (step size is negative) *
matrix

The MATMUL intrinsic provided a wrong result for rank-1 times rank-2 array
when a negative stride was used for addressing the elements of the rank-1
array, because a check on strides was erroneously placed before the check
on the rank.  Interchange order of checks.

libgfortran/ChangeLog:

* m4/matmul_internal.m4: Move check for rank-1 times rank-2 before
checks on strides for rank-2 times rank-2.
* generated/matmul_c10.c: Regenerated.
* generated/matmul_c16.c: Likewise.
* generated/matmul_c4.c: Likewise.
* generated/matmul_c8.c: Likewise.
* generated/matmul_i1.c: Likewise.
* generated/matmul_i16.c: Likewise.
* generated/matmul_i2.c: Likewise.
* generated/matmul_i4.c: Likewise.
* generated/matmul_i8.c: Likewise.
* generated/matmul_r10.c: Likewise.
* generated/matmul_r16.c: Likewise.
* generated/matmul_r4.c: Likewise.
* generated/matmul_r8.c: Likewise.
* generated/matmulavx128_c10.c: Likewise.
* generated/matmulavx128_c16.c: Likewise.
* generated/matmulavx128_c4.c: Likewise.
* generated/matmulavx128_c8.c: Likewise.
* generated/matmulavx128_i1.c: Likewise.
* generated/matmulavx128_i16.c: Likewise.
* generated/matmulavx128_i2.c: Likewise.
* generated/matmulavx128_i4.c: Likewise.
* generated/matmulavx128_i8.c: Likewise.
* generated/matmulavx128_r10.c: Likewise.
* generated/matmulavx128_r16.c: Likewise.
* generated/matmulavx128_r4.c: Likewise.
* generated/matmulavx128_r8.c: Likewise.

gcc/testsuite/ChangeLog:

* gfortran.dg/matmul_20.f90: New test.

(cherry picked from commit cd6cd6aed195b4ec7d652e8b41d60b60e174304e)

[Bug c++/94799] [8/9/10 Regression] Calling a member template function fails

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

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

--- Comment #13 from Marek Polacek  ---
The fix may be as easy as this:

--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -23812,8 +23812,8 @@ cp_parser_class_name (cp_parser *parser,

   /* Any name names a type if we're following the `typename' keyword
  in a qualified name where the enclosing scope is type-dependent.  */
-  typename_p = (typename_keyword_p && scope && TYPE_P (scope)
-   && dependent_type_p (scope));
+  typename_p = (typename_keyword_p && parser->scope && TYPE_P (parser->scope)
+   && dependent_type_p (parser->scope));
   /* Handle the common case (an identifier, but not a template-id)
  efficiently.  */
   if (token->type == CPP_NAME

[Bug target/97481] GCC ice when build with RISCV on msys2

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #3 from fdlbxtqi  ---
(In reply to Jim Wilson from comment #2)
> riscv-unknown-linux-gnu is not a supported target.  You must use either
> riscv32-unknown-linux-gnu or riscv64-unknwon-linux-gnu.  Both compilers
> support both word sizes, the only difference is which is the default word
> size.  This may be part of the reason why it failed.
> 
> The attachment doesn't show any ICE.  It is just a config.log file, and I
> don't see anything interesting in there.
> 
> Note that mingw64 builds of a linux toolchain are unlikely to work as glibc
> requires a case sensitive file system.  I'd suggest using WSL2 as something
> more likely to work, but I haven't tried that myself.
> 
> It looks like you have a badly broken compiler build.  You will need to
> figure out why it is broken.  This doesn't seem to be a gcc problem, but
> rather a build problem on your side.

I have successfully built that by fixing problems by myself for both
x86_64-linux-gnu and aarch64-linux-gnu. While on riscv, it fails at the
configure for glibc since the compiler encounters ICE.

Here is the proof
https://gcc.gnu.org/pipermail/libstdc++/2020-October/051219.html
https://github.com/riscv/riscv-gnu-toolchain/issues/523#issuecomment-711457612

And this is my detailed building process.

https://github.com/expnkx/GCC-cross-compilation-scripts/blob/master/windows%20hosted/aarch64-linux-gnu.txt

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

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

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

--- Comment #26 from Peter Bergner  ---
(In reply to Andrew Macleod from comment #25)
> (In reply to Peter Bergner from comment #24)
> > (In reply to Richard Biener from comment #22)
> > >tree oi_uns_type = make_unsigned_type (256);
> > > -  vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
> > >SET_TYPE_MODE (vector_pair_type_node, POImode);
> > 
> > So this doesn't work.  Without that line vector_pair_type_node is
> > NULL and the SET_TYPE_MODE() usage on the next line ends up dereferencing it
> > and we SEGV.
> 
> Wonder if it was suppose to be something like:

Maybe? :-)   I'll report back how the build does with this.

[Bug middle-end/94169] warn for modifying getenv() result

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

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #3 from David Malcolm  ---
In terms of the history here, is it the case that all of these functions really
ought to return a "const char *" to the caller, but were already standardized
as returning plain "char *"?

[Bug fortran/97491] Wrong restriction for VALUE arguments of pure procedures

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
   Last reconfirmed||2020-10-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

I've looked at gfc_impure_variable, but do not understand it.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #25 from Andrew Macleod  ---
(In reply to Peter Bergner from comment #24)
> (In reply to Richard Biener from comment #22)
> >tree oi_uns_type = make_unsigned_type (256);
> > -  vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
> >SET_TYPE_MODE (vector_pair_type_node, POImode);
> 
> So this doesn't work.  Without that line vector_pair_type_node is
> NULL and the SET_TYPE_MODE() usage on the next line ends up dereferencing it
> and we SEGV.

Wonder if it was suppose to be something like:


   /* Vector pair and vector quad support.  */
   if (TARGET_EXTRA_BUILTINS)
 {
-  tree oi_uns_type = make_unsigned_type (256);
-  vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
+  vector_pair_type_node = make_unsigned_type (256);
   SET_TYPE_MODE (vector_pair_type_node, POImode);
   layout_type (vector_pair_type_node);
   lang_hooks.types.register_builtin_type (vector_pair_type_node,
  "__vector_pair");

-  tree xi_uns_type = make_unsigned_type (512);
-  vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
+  vector_quad_type_node = make_unsigned_type (512);
   SET_TYPE_MODE (vector_quad_type_node, PXImode);
   layout_type (vector_quad_type_node);
   lang_hooks.types.register_builtin_type (vector_quad_type_node,

[Bug c++/97438] [accepts-invalid] coroutines accepts prmomise type with both return_value() and return_void()

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Last reconfirmed||2020-10-19
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Iain Sandoe  ---
fixed on master, 
the general view is that this isn't critical to back port (if there is some
pressing reason it should be then please reopen the PR).

[Bug target/97481] GCC ice when build with RISCV on msys2

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

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #2 from Jim Wilson  ---
riscv-unknown-linux-gnu is not a supported target.  You must use either
riscv32-unknown-linux-gnu or riscv64-unknwon-linux-gnu.  Both compilers support
both word sizes, the only difference is which is the default word size.  This
may be part of the reason why it failed.

The attachment doesn't show any ICE.  It is just a config.log file, and I don't
see anything interesting in there.

Note that mingw64 builds of a linux toolchain are unlikely to work as glibc
requires a case sensitive file system.  I'd suggest using WSL2 as something
more likely to work, but I haven't tried that myself.

It looks like you have a badly broken compiler build.  You will need to figure
out why it is broken.  This doesn't seem to be a gcc problem, but rather a
build problem on your side.

[Bug c++/97438] [accepts-invalid] coroutines accepts prmomise type with both return_value() and return_void()

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

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

commit r11-4076-gb003c4b14b3f889e6707db68d2c6545eda7a203b
Author: Iain Sandoe 
Date:   Sat Oct 17 11:21:11 2020 +0100

coroutines: Emit error for invalid promise return types [PR97438].

At one stage, use cases were proposed for allowing the promise
type to contain both return_value and return_void.  That was
not accepted into C++20, so we should reject it as per the PR.

gcc/cp/ChangeLog:

PR c++/97438
* coroutines.cc (struct coroutine_info): Add a field to
record that we emitted a promise type error.
(coro_promise_type_found_p): Check for the case that the
promise type contains both return_void and return_value.
Emit an error if so, with information about the wrong
type methods.

gcc/testsuite/ChangeLog:

PR c++/97438
* g++.dg/coroutines/pr97438.C: New test.

[Bug sanitizer/97478] Cross Build from windows to linux. It looks like the sys/timeb.h header file does not exist in latest glibc any more

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

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

--- Comment #2 from Jakub Jelinek  ---
It breaks bootstrap on x86_64-linux and i686-linux too.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

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

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

--- Comment #24 from Peter Bergner  ---
(In reply to Richard Biener from comment #22)
>tree oi_uns_type = make_unsigned_type (256);
> -  vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
>SET_TYPE_MODE (vector_pair_type_node, POImode);

So this doesn't work.  Without that line vector_pair_type_node is
NULL and the SET_TYPE_MODE() usage on the next line ends up dereferencing it
and we SEGV.

[Bug middle-end/97487] [10/11 Regression] ICE in expand_simple_binop, at optabs.c:939 since r10-1420-g744fd446c321f78f

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
ifcvt throws random expressions as operand to expand_binop, which in turn
attempts to force_operand them, but force_operand handles only the most common
rtls (e.g. for binops only those that have corresponding binop optab, similarly
for unops etc.).
In this case the SET_SRC and thus if_info->b is a VEC_SELECT which
force_operand isn't able to handle (but there are many others that can't be
handled either).

[Bug bootstrap/97409] riscv cross toolchain build fails

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

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

Jim Wilson  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from Jim Wilson  ---
Apparent user error, and no response in several days, so closing.

[Bug tree-optimization/97456] [10/11 Regression] An incorrect optimization causes a function to always return the same value when using -flto

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:619f91eaa8c8a50f1f9d3e7b96ee837037f0e806

commit r11-4075-g619f91eaa8c8a50f1f9d3e7b96ee837037f0e806
Author: Martin Jambor 
Date:   Mon Oct 19 19:21:10 2020 +0200

cplxlower: Avoid a transform when looking at a default definition

In PR 97456, IPA-SRA triggers a bug in tree-complex.c where it
converts:

 
   a$_M_value_21 = COMPLEX_EXPR ;

(where ISRA.18 is IPA-SRA created PARM_DECL with DECL_IGNORED_P set,
which is why it only happens with IPA-SRA) into:

  
a$_M_value_21 = COMPLEX_EXPR ;

i.e. it replaces two uses of the parameter default-def with two
uninitialized default-defs of a new variable - all in hope to produce
code with better debug info.

This patch fixes it by avoiding the transform when the SSA_NAME to be
replaced is a default definition.

gcc/ChangeLog:

2020-10-19  Martin Jambor  

PR tree-optimization/97456
* tree-complex.c (set_component_ssa_name): Do not replace ignored
decl
default definitions with new component vars.  Reorder if
conditions.

gcc/testsuite/ChangeLog:

2020-10-19  Martin Jambor  

PR tree-optimization/97456
* gcc.dg/tree-ssa/pr97456.c: New test.

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #22 from Jan Hubicka  ---
> Maybe better just have a match.pd rule that would fold
> y = z binop cst;
> x = __builtin_constant_p (y);
> to
> x = __builtin_constant_p (z);
> and let SCCVN do the rest (or do it in fwprop or whatever else if we'd want to
> write it in C without having to enumerate all possible binops we want to do it
> for).
> 
> Not sure if we shouldn't stop on ops that could trap though, or on ops that
> could possibly be invalid...

We need to establish that z binop cst folds to a constant whenever z is
a constant or we may run into cases where we go into builtin_constant_p
== true case and then fail to fold the actual value.

Honza
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

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

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

--- Comment #21 from Jakub Jelinek  ---
(In reply to Jan Hubicka from comment #20)
> >   _2 = size_68(D) + 18446744073709551615;
> >   _3 = __builtin_constant_p (_2);
> Forgot to note, things would be easier if we folded this to _1 :)
> Among other we run on out of the limit on number of conditionals
> recorded by the fnsummary pass.

Maybe better just have a match.pd rule that would fold
y = z binop cst;
x = __builtin_constant_p (y);
to
x = __builtin_constant_p (z);
and let SCCVN do the rest (or do it in fwprop or whatever else if we'd want to
write it in C without having to enumerate all possible binops we want to do it
for).

Not sure if we shouldn't stop on ops that could trap though, or on ops that
could possibly be invalid...

[Bug rtl-optimization/97497] gcse wrong code generation with partial register clobbers

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

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

--- Comment #1 from Andreas Krebbel  ---
Created attachment 49402
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49402=edit
Proposed fix

With the patch only regs are considered which aren't "fixed" assuming that for
fixed_regs the backend takes care of only actually using the well-defined part
of the hard regs.

[Bug rtl-optimization/97497] New: gcse wrong code generation with partial register clobbers

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

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

Bug ID: 97497
   Summary: gcse wrong code generation with partial register
clobbers
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Compiling the attached testcase produces wrong code on IBM Z:

cc1 t.c -m31 -mzarch -march=z900 -O2 -fpic -o t.s

foo:
stm %r11,%r15,44(%r15)
larl%r12,_GLOBAL_OFFSET_TABLE_
lr  %r11,%r2
l   %r1,t@GOT(%r12)
ahi %r15,-96
lhi %r2,1
l   %r3,0(%r1)
brasl   %r14,bar@PLT
ltr %r11,%r11
jne .L8
lhi %r2,1
l   %r3,0 <--- dereference address 0
brasl   %r14,bar@PLT
l   %r4,152(%r15)
lm  %r11,%r15,140(%r15)
br  %r4
.L8:
lhi %r3,1
l   %r2,0 <--- dereference address 0
brasl   %r14,baz@PLT
lhi %r2,1
l   %r3,0
brasl   %r14,bar@PLT
l   %r4,152(%r15)
lm  %r11,%r15,140(%r15)
br  %r4


gcse decides to remove the load from t in the subsequent bbs but does not
generate the load into a temp reg in the first bb leaving the bbs loading from
an uninitialized pseudo.

With -mzarch -m31 we have the GOT pointer marked as partially clobbered. The
loads from t use the GOT pointer explicitly in the RTX. Since this patch r12 is
considered to be fully clobbered by call insns:

commit a4dfaad2e5594d871fe00a1116005e28f95d644e (refs/bisect/bad)
Author: Richard Sandiford 
Date:   Mon Sep 30 16:20:44 2019 +

Remove global call sets: gcse.c

This is another case in which we can conservatively treat partial
kills as full kills.  Again this is in principle a bug fix for
TARGET_HARD_REGNO_CALL_PART_CLOBBERED targets, but in practice
it probably doesn't make a difference.

2019-09-30  Richard Sandiford  

gcc/
* gcse.c: Include function-abi.h.
(compute_hash_table_work): Use insn_callee_abi to get the ABI of
the call insn target.  Invalidate partially call-clobbered
registers as well as fully call-clobbered ones.

From-SVN: r276323

Now the RTX for t which references r12 is considered to be not available
anymore in the later bbs due to r12 being clobbered by the calls. Hence no load
of the original expression is being emitted.

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #20 from Jan Hubicka  ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
> 
> --- Comment #19 from Jan Hubicka  ---
> get_order unwinds to:
> 
>[local count: 1073741824]:
>   _1 = __builtin_constant_p (size_68(D));
>   if (_1 != 0)
> goto ; [50.00%]
>   else
> goto ; [50.00%]
> 
>[local count: 536870913]:
>   if (size_68(D) == 0)
> goto ; [21.72%]
>   else
> goto ; [78.28%]
> 
>[local count: 420262548]:
>   if (size_68(D) <= 4095)
> goto ; [50.00%]
>   else
> goto ; [50.00%]
> 
>[local count: 210131274]:
>   _2 = size_68(D) + 18446744073709551615;
>   _3 = __builtin_constant_p (_2);
Forgot to note, things would be easier if we folded this to _1 :)
Among other we run on out of the limit on number of conditionals
recorded by the fnsummary pass.

Honza

[Bug tree-optimization/97496] [11 Regression] during during GIMPLE pass: cddce since r11-4005-g6c6e0cafa38cee83

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-10-19
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Priority|P3  |P1
  Known to fail||11.0
   Target Milestone|--- |11.0
   Keywords||ice-on-valid-code
  Component|c   |tree-optimization
  Known to work||10.2.0
Summary|ice during during GIMPLE|[11 Regression] during
   |pass: cddce |during GIMPLE pass: cddce
   ||since
   ||r11-4005-g6c6e0cafa38cee83

--- Comment #1 from Martin Liška  ---
Started with Richi's r11-4005-g6c6e0cafa38cee83.

[Bug tree-optimization/97496] [11 Regression] during during GIMPLE pass: cddce since r11-4005-g6c6e0cafa38cee83

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

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

--- Comment #2 from Martin Liška  ---
for SSA_NAME: vect__16.4_34 in statement:
# .MEM_29 = VDEF <.MEM_7(D)>
MEM  [(int *)] = vect__16.4_34;
during GIMPLE pass: slp
dump file: pr97496.c.169t.slp1
pr97496.c:3:6: internal compiler error: verify_ssa failed
vi 0xfcb522 verify_ssa(bool, bool)
/home/marxin/Programming/gcc/gcc/tree-ssa.c:1208
0xcda455 execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1999
0xcdb19c do_per_function
/home/marxin/Programming/gcc/gcc/passes.c:1640
0xcdb19c execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

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

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

--- Comment #19 from Jan Hubicka  ---
get_order unwinds to:

   [local count: 1073741824]:
  _1 = __builtin_constant_p (size_68(D));
  if (_1 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  if (size_68(D) == 0)
goto ; [21.72%]
  else
goto ; [78.28%]

   [local count: 420262548]:
  if (size_68(D) <= 4095)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 210131274]:
  _2 = size_68(D) + 18446744073709551615;
  _3 = __builtin_constant_p (_2);
  if (_3 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 105065637]:
  _4 = (signed long) _2;
  if (_4 >= 0)
goto ; [59.00%]
  else
goto ; [41.00%]

... [very long code]

   [local count: 105065637]:
  __asm__("bsrq %1,%q0" : "=r" bitpos_75 : "rm" _2, "0" -1);
  iftmp.1_73 = bitpos_75 + -11;

   [local count: 210131274]:
  # iftmp.1_67 = PHI <52(6), iftmp.1_73(69), 51(7), 50(8), 49(9), 48(10),
47(11), 46(12), 45(13), 44(14), 43(15), 42(16), 41(17), 40(18), 39(19), 38(20),
37(21), 36(22), 35(23), 34(24), 33(25), 32(26), 31(27), 30(28), 29(29), 28(30),
27(31), 26(32), 25(33), 24(34), 23(35), 22(36), 21(37), 20(38), 19(39), 18(40),
17(41), 16(42), 15(43), 14(44), 13(45), 12(46), 11(47), 10(48), 9(49), 8(50),
7(51), 6(52), 5(53), 4(54), 3(55), 2(56), 1(57), 0(58), -1(59), -2(60), -3(61),
-4(62), -5(63), -6(64), -7(65), -8(66), -10(68), -9(67)>
  goto ; [100.00%]

   [local count: 536870913]:
  size_69 = size_68(D) + 18446744073709551615;
  size_70 = size_69 >> 12;
  __asm__("bsrq %1,%q0" : "=r" bitpos_72 : "rm" size_70, "0" -1);
  _74 = bitpos_72 + 1;

   [local count: 1073741824]:
  # _66 = PHI <52(3), 0(4), iftmp.1_67(70), _74(71)>
  return _66;

We get summary:

IPA function summary for get_order/303 inlinable
  global time: 8.716289 
  self size:   201  
  global size: 201  
  min size:   4 
  self stack:  0
  global stack:0
size:4.00, time:3.00
size:3.00, time:2.00,  executed if:(not inlined)
size:4.00, time:2.00,  executed if:(op0 not constant)   
size:2.00, time:0.782800,  executed if:(op0 != 0)   
size:3.00, time:0.391400,  executed if:(op0 > 4095) && (op0 != 0)   
size:2.00, time:0.195700,  executed if:(op0 > 4095) && (op0 != 0) &&
(op0 not constant)
size:3.00, time:0.173194,  executed if:(op0,(# +
18446744073709551615),((signed long) #) >= 0) && (op0 > 4095) && (op0 != 0)
size:3.00, time:0.086597,  executed if:(op0,(# +
18446744073709551615),(# & 4611686018427387904) == 0) && (op0,(# +
18446744073709551615),((signed long) #) >= 0) && (op0 > 4095) && (op0 != 0)
size:3.00, time:0.043299,  executed if:(op0,(# +
18446744073709551615),(# & 2305843009213693952) == 0) && (op0,(# +
18446744073709551615),(# & 4611686018427387904) == 0) && (op0,(# +
18446744073709551615),((signed long) #) >= 0) && (op0 > 4095) && (op0 != 0)
size:3.00, time:0.021649,  executed if:(op0,(# +
18446744073709551615),(# & 1152921504606846976) == 0) && (op0,(# +
18446744073709551615),(# & 2305843009213693952) == 0) && (op0,(# +
18446744073709551615),(# & 4611686018427387904) == 0) && (op0,(# +
18446744073709551615),((signed long) #) >= 0) && (op0 > 4095) && (op0 != 0)
size:3.00, time:0.010825,  executed if:(op0,(# +
18446744073709551615),(# & 576460752303423488) == 0) && (op0,(# +
18446744073709551615),(# & 1152921504606846976) == 0) && (op0,(# +
18446744073709551615),(# & 2305843009213693952) == 0) && (op0,(# +
18446744073709551615),(# & 4611686018427387904) == 0) && (op0,(# +
18446744073709551615),((signed long) #) >= 0) && (op0 > 4095) && (op0 != 0)
size:168.00, time:0.010825,  executed if:(op0,(# +
18446744073709551615),(# & 288230376151711744) == 0) && (op0,(# +
18446744073709551615),(# & 576460752303423488) == 0) && (op0,(# +
18446744073709551615),(# & 1152921504606846976) == 0) && (op0,(# +
18446744073709551615),(# & 2305843009213693952) == 0) && (op0,(# +
18446744073709551615),(# & 4611686018427387904) == 0) && (op0,(# +
18446744073709551615),((signed long) #) >= 0) && (op0 > 4095) && (op0 != 0)
  calls:
__builtin_constant_p/4546 function body not available   
  freq:0.20 loop depth: 0 size: 0 time:  0 predicate: (op0 > 4095) && (op0
!= 0)
   op0 points to local or readonly memory   
__builtin_constant_p/4546 

[Bug c/97496] New: ice during during GIMPLE pass: cddce

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 97496
   Summary: ice during during GIMPLE pass: cddce
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

int a;
int b[];
void c(unsigned g) {
  if (a) {
long e = g, d = e;
int f = 0;
for (; f < 4; f++) {
  b[f] = d;
  d >>= 8;
}
  }
}

with compiler flag -O3, does this:

during GIMPLE pass: cddce
bug657.c: In function ‘c’:
bug657.c:3:6: internal compiler error: in mark_operand_necessary, at
tree-ssa-dce.c:173
3 | void c(unsigned g) {
  |  ^
0x5e63bd mark_operand_necessary
../../trunk.git/gcc/tree-ssa-dce.c:173
0x5e63bd propagate_necessity
../../trunk.git/gcc/tree-ssa-dce.c:775

The problem first seems to occur sometime between 20201016 and 20201017.

[Bug middle-end/97495] -Wstringop-overflow where -Warray-bounds would be more appropriate

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||mark at gcc dot gnu.org
   Last reconfirmed||2020-10-19

--- Comment #1 from Martin Sebor  ---
Confirmed on Mark's behalf (CC'd).

[Bug middle-end/97495] New: -Wstringop-overflow where -Warray-bounds would be more appropriate

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

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

Bug ID: 97495
   Summary: -Wstringop-overflow where -Warray-bounds would be more
appropriate
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

-Wstringop-overflow is documented to "Warn for calls to string manipulation
functions such as memcpy and strcpy that are determined to overflow the
destination buffer" but in GCC 11 it's issued even for user-defined functions
that don't manipulate strings.  GCC should issue -Warray-bounds for those
instead.  In addition, mentioning array indices rather than byte counts might
make the warnings easier to interpret.

$ cat z.c && gcc -O2 -S -Wall z.c
void f (int[static 4]);

void g (void)
{
  int a[2];
  f (a);
}

z.c: In function ‘g’:
z.c:6:3: warning: ‘f’ accessing 16 bytes in a region of size 8
[-Wstringop-overflow=]
6 |   f (a);
  |   ^
z.c:6:3: note: referencing argument 1 of type ‘int *’
z.c:1:6: note: in a call to function ‘f’
1 | void f (int[static 4]);
  |  ^


Clang issues -Warray-bounds as expected:

z.c:6:3: warning: array argument is too small; contains 2 elements, callee
  requires at least 4 [-Warray-bounds]
  f (a);
  ^  ~
z.c:1:12: note: callee declares array parameter as static here
void f (int[static 4]);
   ^~
1 warning generated.

[Bug middle-end/93232] std::array warning: writing 1 byte into a region of size 0 [ttps://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overflow=-Wstringop-overflow=m]

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #4 from Martin Sebor  ---
Closing due to no feedback/test case since January.  If the issue persists
please reopen the bug and provide a standalone test case along with the details
listed here: https://gcc.gnu.org/bugs/#need

[Bug rtl-optimization/97313] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-937-g5261cf8ce824bfc7

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

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

--- Comment #5 from Vladimir Makarov  ---
(In reply to Martin Liška from comment #4)
> Thank you Vladimir for the fix.
> Can we close it now?

There are no complaints about the patch for more a week.  So I guess the PR can
be closed.

[Bug c/97493] generate wrong code with "-Os -fno-toplevel-reorder -frename-registers"

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

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

--- Comment #3 from Jakub Jelinek  ---
I can't reproduce it with -fno-strict-aliasing, only when that option is
missing.

[Bug tree-optimization/80928] SLP vectorization does not handle induction in outer loop vectorization

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

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

--- Comment #30 from Richard Biener  ---
(In reply to Richard Biener from comment #29)
> So a testcase for missed outer loop induction SLP (and nested cycle SLP) is
> for example
> 
> int a[1024];
> void foo (unsigned n)
> {
>   for (int i = 0; i < 1020; i += 4)
> {
>   int suma = a[i];
>   int sumb = a[i+1];
>   int sumc = a[i+2];
>   int sumd = a[i+3];
>   for (unsigned j = 0; j < 17; ++j)
> {
>   suma = (suma ^ i) + 1;
>   sumb = (sumb ^ i) + 2;
>   sumc = (sumc ^ i) + 3;
>   sumd = (sumd ^ i) + 4;
> }
>   a[i] = suma;
>   a[i+1] = sumb;
>   a[i+2] = sumc;
>   a[i+3] = sumd;
> }
> }

Actually this is still not an inner loop induction in outer loop vectorization.
But missed nested cycle SLP handling.  I have a patch for this in testing.

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

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

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

--- Comment #18 from Martin Liška  ---
(In reply to Jan Hubicka from comment #17)
> > The following happens:
> > 
> > get_order is called by kmalloc_large which is called in kmalloc. And kmalloc
> > calls the function for larger allocations. Problem is that we eliminate all
> > calls to get_order late
> > 
> > pipe.i.108t.thread1:;; Function get_order (get_order, funcdef_no=295,
> > decl_uid=4528, cgraph_uid=300, symbol_order=303)
> > pipe.i.108t.thread1:get_order (long unsigned int size)
> > pipe.i.108t.thread1:  _125 = get_order (_114);
> > pipe.i.108t.thread1:  _67 = get_order (_56);
> > pipe.i.109t.cdce:;; Function get_order (get_order, funcdef_no=295,
> > decl_uid=4396, cgraph_uid=300, symbol_order=303)
> > pipe.i.109t.cdce:get_order (long unsigned int size)
> > 
> > so remove_unreachable_nodes is not called any more.
> Yep, that is by design - we are already outputting functions to
> assembler file, so there is not much we can do at this moent. Option
> wold be to do threading early of course.  How often this happen in
> practice?
> 
> Also note that -Winline outputs reasons why the static inline is not

You are right, this is printed:

gcc -O2 pipe.i -c -fdump-tree-all -Winline
In file included from ./arch/x86/include/asm/page.h:77,
 from ./arch/x86/include/asm/thread_info.h:12,
 from ./include/linux/thread_info.h:38,
 from ./arch/x86/include/asm/preempt.h:7,
 from ./include/linux/preempt.h:78,
 from ./include/linux/spinlock.h:51,
 from ./include/linux/mmzone.h:8,
 from ./include/linux/gfp.h:6,
 from ./include/linux/mm.h:10,
 from fs/pipe.c:8:
./include/linux/slab.h: In function ‘alloc_pipe_info’:
./include/asm-generic/getorder.h:29:146: warning: inlining failed in call to
‘get_order’: --param max-inline-insns-single limit reached [-Winline]
   29 | static inline __attribute_const__ int get_order(unsigned long size)
  |
 ^  
In file included from fs/pipe.c:11:
./include/linux/slab.h:482:30: note: called from here
  482 | unsigned int order = get_order(size);
  |  ^~~
In file included from ./arch/x86/include/asm/page.h:77,
 from ./arch/x86/include/asm/thread_info.h:12,
 from ./include/linux/thread_info.h:38,
 from ./arch/x86/include/asm/preempt.h:7,
 from ./include/linux/preempt.h:78,
 from ./include/linux/spinlock.h:51,
 from ./include/linux/mmzone.h:8,
 from ./include/linux/gfp.h:6,
 from ./include/linux/mm.h:10,
 from fs/pipe.c:8:
./include/linux/slab.h: In function ‘pipe_resize_ring’:
./include/asm-generic/getorder.h:29:146: warning: inlining failed in call to
‘get_order’: --param max-inline-insns-single limit reached [-Winline]
   29 | static inline __attribute_const__ int get_order(unsigned long size)
  |
 ^  
In file included from fs/pipe.c:11:
./include/linux/slab.h:482:30: note: called from here
  482 | unsigned int order = get_order(size);
  |  ^~~


> inlined (which is also by design a decision of the inliner heuristics).
> I suppose here the inliner sees the function called multiple times and
> since it is quite long it decides to keep it offline.  Opitmizing all
> references late if of course unfortunate.
> 
> Honza

[Bug c/97493] generate wrong code with "-Os -fno-toplevel-reorder -frename-registers"

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|RESOLVED|WAITING
   Last reconfirmed||2020-10-19
 Ever confirmed|0   |1
 Resolution|INVALID |---

--- Comment #2 from Richard Biener  ---
But he's using -fno-strict-aliasing so at least that part isn't relevant?
That said, the C rules still make it an INVALID testcase but I think
GCC-wise it could be well-defined, so understanding what goes wrong would be
nice.

[Bug tree-optimization/97494] [11 regression] several vector test case failures starting with r11-3966

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |11.0
   Last reconfirmed||2020-10-19
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Hmm, I'll have a look how/if to adjust testcases.  Help appreciated.

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #17 from Jan Hubicka  ---
> The following happens:
> 
> get_order is called by kmalloc_large which is called in kmalloc. And kmalloc
> calls the function for larger allocations. Problem is that we eliminate all
> calls to get_order late
> 
> pipe.i.108t.thread1:;; Function get_order (get_order, funcdef_no=295,
> decl_uid=4528, cgraph_uid=300, symbol_order=303)
> pipe.i.108t.thread1:get_order (long unsigned int size)
> pipe.i.108t.thread1:  _125 = get_order (_114);
> pipe.i.108t.thread1:  _67 = get_order (_56);
> pipe.i.109t.cdce:;; Function get_order (get_order, funcdef_no=295,
> decl_uid=4396, cgraph_uid=300, symbol_order=303)
> pipe.i.109t.cdce:get_order (long unsigned int size)
> 
> so remove_unreachable_nodes is not called any more.
Yep, that is by design - we are already outputting functions to
assembler file, so there is not much we can do at this moent. Option
wold be to do threading early of course.  How often this happen in
practice?

Also note that -Winline outputs reasons why the static inline is not
inlined (which is also by design a decision of the inliner heuristics).
I suppose here the inliner sees the function called multiple times and
since it is quite long it decides to keep it offline.  Opitmizing all
references late if of course unfortunate.

Honza

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #16 from Martin Liška  ---
The following happens:

get_order is called by kmalloc_large which is called in kmalloc. And kmalloc
calls the function for larger allocations. Problem is that we eliminate all
calls to get_order late

pipe.i.108t.thread1:;; Function get_order (get_order, funcdef_no=295,
decl_uid=4528, cgraph_uid=300, symbol_order=303)
pipe.i.108t.thread1:get_order (long unsigned int size)
pipe.i.108t.thread1:  _125 = get_order (_114);
pipe.i.108t.thread1:  _67 = get_order (_56);
pipe.i.109t.cdce:;; Function get_order (get_order, funcdef_no=295,
decl_uid=4396, cgraph_uid=300, symbol_order=303)
pipe.i.109t.cdce:get_order (long unsigned int size)

so remove_unreachable_nodes is not called any more.

[Bug tree-optimization/97494] New: [11 regression] several vector test case failures starting with r11-3966

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

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

Bug ID: 97494
   Summary: [11 regression] several vector test case failures
starting with r11-3966
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:429ad0bb0d3dc77e44f95620341da4938d49168e, r11-3966: 109 failures

On all powerpc64 both BE and LE:

FAIL: gcc.dg/vect/slp-11b.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorizing stmts using SLP" 0
FAIL: gcc.dg/vect/slp-11b.c scan-tree-dump-times vect "vectorizing stmts using
SLP" 0
FAIL: gcc.dg/vect/slp-21.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/slp-21.c scan-tree-dump-times vect "vectorizing stmts using
SLP" 2

Some extras on power7 BE:

FAIL: gcc.dg/vect/pr97428.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/pr97428.c scan-tree-dump-times vect "vectorizing stmts using
SLP" 2
FAIL: gcc.dg/vect/vect-complex-5.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/vect-complex-5.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 2


commit 429ad0bb0d3dc77e44f95620341da4938d49168e (HEAD)
Author: Richard Biener 
Date:   Thu Oct 15 11:55:53 2020 +0200

tree-optimization/97428 - split SLP groups for loop vectorization

This enables SLP store group splitting also for loop vectorization.
For the existing testcase gcc.dg/vect/vect-complex-5.c this then
generates much better code, likewise for the PR97428 testcase.

Both of those have a splitting opportunity splitting the group
into two equal (vector-sized) halves, still the patch enables
quite arbitrary splitting since generally the interleaving scheme
results in quite awkward code for even small groups.  If any
problems surface with this it's easy to restrict the splitting
to known-good cases.

2020-10-15  Richard Biener  

PR tree-optimization/97428
* tree-vect-slp.c (vect_analyze_slp_instance): Split store
groups also for loop vectorization.

* gcc.dg/vect/vect-complex-5.c: Expect to SLP.
* gcc.dg/vect/pr97428.c: Likewise.

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

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

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

--- Comment #15 from Martin Liška  ---
Created attachment 49401
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49401=edit
x86_64 pre-processed source file

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-10-19
 Status|UNCONFIRMED |NEW

--- Comment #14 from Martin Liška  ---
All right, I can reproduce it. I'm also attaching x86_64 pre-processes source
file.

[Bug preprocessor/97471] [11 Regression] ICE on using function-like macro as a non function-like macro since r11-338-g2a0225e47868fbfc

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed 5abe05b4331 2020-10-19 | preprocessor: Fix non-fn fn-like macro at EOF
[PR97471]

[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

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

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

--- Comment #10 from Martin Liška  ---
> Hmm, it seems to me that having some entries prealocated by default
> would be way to avoid this problem in majority cases w/o having to
> modify the upstream packages.

I tend to the same. I'm going to prepare a patch for it.

[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #9 from Jan Hubicka  ---
> 
> They have the very same problem when I disable a statically pre-allocated
> buffers with -mllvm -vp-static-alloc=0:
> 
> Program received signal SIGILL, Illegal instruction.
> 0x004014e6 in calloc (nmemb=1, size=8) at pr97461.c:103
> 103 if (malloc_depth != 0) __builtin_trap();
> (gdb) bt
> #0  0x004014e6 in calloc (nmemb=1, size=8) at pr97461.c:103
> #1  0x00401ae1 in allocateValueProfileCounters (Data=0x40a2c8) at
> /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:101
> #2  0x00401c45 in instrumentTargetValueImpl (CountValue=1,
> CounterIndex=0, Data=0x40a2c8, TargetValue=4199264) at
> /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:146
> #3  __llvm_profile_instrument_target (TargetValue=4199264, Data=0x40a2c8,
> CounterIndex=0) at
> /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:232
> #4  0x0040148f in malloc_impl (size=56) at pr97461.c:85
> #5  0x004013fe in malloc (size=56) at pr97461.c:95
> #6  0x77e048a3 in __add_to_environ (name=0x406138
> "__LLVM_PROFILE_RT_INIT_ONCE", value=, combined= out>,
> replace=) at setenv.c:215
> #7  0x00402ce4 in truncateCurrentFile ()
> #8  0x004039bc in parseAndSetFilename ()
> #9  0x00404134 in __llvm_profile_initialize ()
> #10 0x00405e95 in __libc_csu_init (argc=argc@entry=1,
> argv=argv@entry=0x7fffdfa8, envp=0x7fffdfb8) at elf-init.c:89
> #11 0x77decd9a in __libc_start_main (main=0x401580 , argc=1,
> argv=0x7fffdfa8, init=0x405e50 <__libc_csu_init>, fini=,
> rtld_fini=, stack_end=0x7fffdf98) at 
> ../csu/libc-start.c:270
> #12 0x004012aa in _start () at ../sysdeps/x86_64/start.S:120

Hmm, it seems to me that having some entries prealocated by default
would be way to avoid this problem in majority cases w/o having to
modify the upstream packages. 

Honza

Re: [Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

[Jan Hubicka]

> 
> They have the very same problem when I disable a statically pre-allocated
> buffers with -mllvm -vp-static-alloc=0:
> 
> Program received signal SIGILL, Illegal instruction.
> 0x004014e6 in calloc (nmemb=1, size=8) at pr97461.c:103
> 103 if (malloc_depth != 0) __builtin_trap();
> (gdb) bt
> #0  0x004014e6 in calloc (nmemb=1, size=8) at pr97461.c:103
> #1  0x00401ae1 in allocateValueProfileCounters (Data=0x40a2c8) at
> /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:101
> #2  0x00401c45 in instrumentTargetValueImpl (CountValue=1,
> CounterIndex=0, Data=0x40a2c8, TargetValue=4199264) at
> /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:146
> #3  __llvm_profile_instrument_target (TargetValue=4199264, Data=0x40a2c8,
> CounterIndex=0) at
> /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:232
> #4  0x0040148f in malloc_impl (size=56) at pr97461.c:85
> #5  0x004013fe in malloc (size=56) at pr97461.c:95
> #6  0x77e048a3 in __add_to_environ (name=0x406138
> "__LLVM_PROFILE_RT_INIT_ONCE", value=, combined= out>,
> replace=) at setenv.c:215
> #7  0x00402ce4 in truncateCurrentFile ()
> #8  0x004039bc in parseAndSetFilename ()
> #9  0x00404134 in __llvm_profile_initialize ()
> #10 0x00405e95 in __libc_csu_init (argc=argc@entry=1,
> argv=argv@entry=0x7fffdfa8, envp=0x7fffdfb8) at elf-init.c:89
> #11 0x77decd9a in __libc_start_main (main=0x401580 , argc=1,
> argv=0x7fffdfa8, init=0x405e50 <__libc_csu_init>, fini=,
> rtld_fini=, stack_end=0x7fffdf98) at 
> ../csu/libc-start.c:270
> #12 0x004012aa in _start () at ../sysdeps/x86_64/start.S:120

Hmm, it seems to me that having some entries prealocated by default
would be way to avoid this problem in majority cases w/o having to
modify the upstream packages. 

Honza

[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

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

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

--- Comment #8 from Martin Liška  ---
(In reply to Jan Hubicka from comment #7)
> > No. The only thing we support is a recursive malloc as seen in:
> > ./gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c
> > 
> > It was added in g:bc2b1a232b1825b421a1aaa21a0865b2d1e4e08c as we use a
> > statically allocated buffer when we recursively entry allocate_gcov_kvp.
> > 
> > However this is different as we can't call malloc/calloc from the function 
> > as
> > we're in code that initializes a memory allocator.
> > 
> > We can mitigate the issue with a pair of new functions __gcov_supress_malloc
> > and __gcov_alloc_malloc that will be called by a custom memory allocator.
> > 
> > What do you think about it?
> 
> How this works with the llvm implementation (that is very similar here,
> right?)
> 
> Honza

They have the very same problem when I disable a statically pre-allocated
buffers with -mllvm -vp-static-alloc=0:

Program received signal SIGILL, Illegal instruction.
0x004014e6 in calloc (nmemb=1, size=8) at pr97461.c:103
103 if (malloc_depth != 0) __builtin_trap();
(gdb) bt
#0  0x004014e6 in calloc (nmemb=1, size=8) at pr97461.c:103
#1  0x00401ae1 in allocateValueProfileCounters (Data=0x40a2c8) at
/home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:101
#2  0x00401c45 in instrumentTargetValueImpl (CountValue=1,
CounterIndex=0, Data=0x40a2c8, TargetValue=4199264) at
/home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:146
#3  __llvm_profile_instrument_target (TargetValue=4199264, Data=0x40a2c8,
CounterIndex=0) at
/home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:232
#4  0x0040148f in malloc_impl (size=56) at pr97461.c:85
#5  0x004013fe in malloc (size=56) at pr97461.c:95
#6  0x77e048a3 in __add_to_environ (name=0x406138
"__LLVM_PROFILE_RT_INIT_ONCE", value=, combined=,
replace=) at setenv.c:215
#7  0x00402ce4 in truncateCurrentFile ()
#8  0x004039bc in parseAndSetFilename ()
#9  0x00404134 in __llvm_profile_initialize ()
#10 0x00405e95 in __libc_csu_init (argc=argc@entry=1,
argv=argv@entry=0x7fffdfa8, envp=0x7fffdfb8) at elf-init.c:89
#11 0x77decd9a in __libc_start_main (main=0x401580 , argc=1,
argv=0x7fffdfa8, init=0x405e50 <__libc_csu_init>, fini=,
rtld_fini=, stack_end=0x7fffdf98) at ../csu/libc-start.c:270
#12 0x004012aa in _start () at ../sysdeps/x86_64/start.S:120

[Bug c++/97388] By-value function parameter changes are rolled back prior to destructor call during constant evaluation

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

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

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-10-19

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

Untested fix.

[Bug analyzer/97489] [11 Regression] ICE: Segmentation fault (in ana::supergraph::get_node_for_function_entry(function*) const) since r10-5950-g757bf1dff5e8cee3

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from David Malcolm  ---
Thanks; confirmed, though for me I see the ICE with
g:af66094d037793773eb8a49597866457f2f6a104, and do not see the ICE with its
predecessor; in particular the backtrace shows add_any_callbacks which I added
in that commit.

It's crashing on "__dt_comp ", finding the dtor in the vtable when building the
initial worklist, here:

96  return get_node_for_block (ENTRY_BLOCK_PTR_FOR_FN (fun));

where fun->cfg is NULL.  Working on a fix.

[Bug c/97493] generate wrong code with "-Os -fno-toplevel-reorder -frename-registers"

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Jakub Jelinek  ---
The testcase is invalid.  In standard C only one union member may be active at
a time, and while GCC as extension allows type puning through unions, the union
must be visible in the expressions accessing it, so taking addresses of the
union elts and dereferencing them through those pointers where the union is not
visible is UB.

[Bug c/97493] New: generate wrong code with "-Os -fno-toplevel-reorder -frename-registers"

[suochenyao at 163 dot com via Gcc-bugs]

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

Bug ID: 97493
   Summary: generate wrong code with "-Os -fno-toplevel-reorder
-frename-registers"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: suochenyao at 163 dot com
  Target Milestone: ---

Description:
I think gcc generates wrong code with -Os -fno-toplevel-reorder
-frename-registers.
But no difference is found with optimization levels.
No message and difference occurs with "gcc -Wall -Wextra" and
"-fno-strict-aliasing -fwrapv"
***
OS and Platform:
CentOS Linux release 7.8.2003 (Core), x86_64 GNU/Linux
***
Program:
int printf(const char *, ...);
union uuu{
  short a;
  long b;
} c={0};
long *d = 
short *e = 
short f=0;
int main() {
  *d = 3;
  f = ++*e;
  printf("%d\n", c.a);
}
***
Gcc Version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/home/suocy/bin/gcc-dev/bin/gcc
COLLECT_LTO_WRAPPER=/home/suocy/bin/gcc-dev/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/suocy/bin/gcc-dev
--disable-multilib --enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201018 (experimental) (GCC)
***
Command Line:
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -O0 a.c -o a.out0
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -O1 a.c -o a.out1
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -O2 a.c -o a.out2
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -O3 a.c -o a.out3
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -Os a.c -o a.outs
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -Os -fno-toplevel-reorder
-frename-registers a.c -o a.outf
$ ./a.out0 > out0
$ ./a.out1 > out1
$ ./a.out2 > out2
$ ./a.out3 > out3
$ ./a.outs > outs
$ ./a.outf > outf
$ diff out0 out1
$ diff out0 out2
$ diff out0 out3
$ diff out0 outs
$ diff out0 outf
1c1
< 4
---
> 1

Re: [Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

[Jan Hubicka]

> No. The only thing we support is a recursive malloc as seen in:
> ./gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c
> 
> It was added in g:bc2b1a232b1825b421a1aaa21a0865b2d1e4e08c as we use a
> statically allocated buffer when we recursively entry allocate_gcov_kvp.
> 
> However this is different as we can't call malloc/calloc from the function as
> we're in code that initializes a memory allocator.
> 
> We can mitigate the issue with a pair of new functions __gcov_supress_malloc
> and __gcov_alloc_malloc that will be called by a custom memory allocator.
> 
> What do you think about it?

How this works with the llvm implementation (that is very similar here,
right?)

Honza

[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #7 from Jan Hubicka  ---
> No. The only thing we support is a recursive malloc as seen in:
> ./gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c
> 
> It was added in g:bc2b1a232b1825b421a1aaa21a0865b2d1e4e08c as we use a
> statically allocated buffer when we recursively entry allocate_gcov_kvp.
> 
> However this is different as we can't call malloc/calloc from the function as
> we're in code that initializes a memory allocator.
> 
> We can mitigate the issue with a pair of new functions __gcov_supress_malloc
> and __gcov_alloc_malloc that will be called by a custom memory allocator.
> 
> What do you think about it?

How this works with the llvm implementation (that is very similar here,
right?)

Honza

[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

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

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

--- Comment #6 from Martin Liška  ---
(In reply to Richard Biener from comment #5)
> Hmm, is the TOPN allocation strathegy configurable?  I wonder whether we have
> to resort to an alternate allocation scheme (mmap/sbrk), avoiding libc?

No. The only thing we support is a recursive malloc as seen in:
./gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c

It was added in g:bc2b1a232b1825b421a1aaa21a0865b2d1e4e08c as we use a
statically allocated buffer when we recursively entry allocate_gcov_kvp.

However this is different as we can't call malloc/calloc from the function as
we're in code that initializes a memory allocator.

We can mitigate the issue with a pair of new functions __gcov_supress_malloc
and __gcov_alloc_malloc that will be called by a custom memory allocator.

What do you think about it?

>  At
> least
> I don't see a good way to force the gcov allocation to call the libc malloc
> rather than a user replacement that is being instrumented.  Of course the
> instrumentation code could do sth like
> 
>   if (is_allocated == 0)
> {
>   is_allocated = in_progress;
>   ... = malloc ();
>   is_allocated = 1;
> }
>   else if (is_allocted == in_progress)
> {
>   topn_mem = _garbage_space;
> }
> 
> but of course that's quite some overhead for a small benefit.  Maybe it
> could be hidden in gcov_malloc.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

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

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

--- Comment #23 from Peter Bergner  ---
(In reply to Richard Biener from comment #22)
> OK, so the fix here is quite obviously to simply drop the
> build_distinct_type_copy calls:

Thanks richi, I'll put the patch through a bootstrap/regtest cycle.

[Bug c++/97477] g++ doesn't accept __restrict keyword inside array function parameter

[dwwork at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Dalon Work  ---
(In reply to Richard Biener from comment #1)
> IIRC restrict is not official C++ but I agree it should be accepted.

You are correct, it is not official c++. g++ accepts and uses the '__restrict'
keyword in c++ to mean approximately the same thing as the 'restrict' keyword
in c. Not being a g++ developer, I cannot say to what degree this extension to
the c++ language is supported by the g++ compiler, so I'll leave it up to you
to decide what to do with this information.

[Bug other/97492] New: arm cortex-m0+ or constant value can use adds

[kjetilos at gmail dot com via Gcc-bugs]

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

Bug ID: 97492
   Summary: arm cortex-m0+ or constant value can use adds
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kjetilos at gmail dot com
  Target Milestone: ---

Given the following C code the compiler generates code that can be further
optimized.

void write_byte(void)
{
  unsigned *regs = (unsigned *) 0x421;
  *regs = (*regs & ~0xff) | (0x9 & 0xff);
}

In this code the first byte is cleared and a constant 9 is or'ed into the word.
This is compiled down to these instructions for cortex-m0+.

write_byte:
movsr3, #255
ldr r1, .L2
ldr r2, [r1]
bicsr2, r3
subsr3, r3, #246
orrsr3, r2
str r3, [r1]
bx  lr
.L3:
.align  2
.L2:
.word   69271552

In this case where a constant less than 255 is or'ed into the last byte of a
word then the subs + orrs instruction (or sometimes movs + orrs) sequence can
be replaced by a single adds instruction to save 2 bytes.

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

[christophe.leroy at csgroup dot eu via Gcc-bugs]

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

--- Comment #13 from Christophe Leroy  ---
(In reply to Christophe Leroy from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > What I was suggesting is build with make V=1 and copy/paste the command line
> > used to compile a particular source file and append -save-temps to those
> > options
> 
> That's exactly what I did, I built with V=1, then I copy/pasted the line and
> added  -save-temps at the end as you see in comment #8

This was a problem with PATH, when I was copying the command line, it was using
another (older) version of GCC which was the one in the PATH. Sorry.

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

[christophe.leroy at csgroup dot eu via Gcc-bugs]

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

--- Comment #12 from Christophe Leroy  ---
Created attachment 49399
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49399=edit
pipe.s from build of fs/pipe.o

fs/pipe.o includes an instance of get_order() allthouth get_order() is declared
static and not called from any function.

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

[christophe.leroy at csgroup dot eu via Gcc-bugs]

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

--- Comment #11 from Christophe Leroy  ---
Created attachment 49398
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49398=edit
Build of fs/pipe.o

[Bug libstdc++/97485] std::call_once crashes at runtime on glibc if not linked to libpthread: terminate called after throwing an instance of 'std::system_error': what(): Unknown error -1

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

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

--- Comment #3 from Jonathan Wakely  ---
Looks like a dup of PR 55394

[Bug fortran/97491] New: Wrong restriction for VALUE arguments of pure procedures

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

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

Bug ID: 97491
   Summary: Wrong restriction for VALUE arguments of pure
procedures
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

$ cat pure.f90 
pure function foo(x) result (ret)
  integer :: ret
  integer, value :: x
  x = x / 2
  ret = x
end function foo
$ gfortran pure.f90 
pure.f90:4:2:

4 |   x = x / 2
  |  1
Error: Variable 'x' cannot appear in a variable definition context (assignment)
at (1) in PURE procedure

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

[christophe.leroy at csgroup dot eu via Gcc-bugs]

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

--- Comment #10 from Christophe Leroy  ---
(In reply to Jakub Jelinek from comment #9)
> What I was suggesting is build with make V=1 and copy/paste the command line
> used to compile a particular source file and append -save-temps to those
> options

That's exactly what I did, I built with V=1, then I copy/pasted the line and
added  -save-temps at the end as you see in comment #8

[Bug tree-optimization/80928] SLP vectorization does not handle induction in outer loop vectorization

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

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

--- Comment #29 from Richard Biener  ---
So a testcase for missed outer loop induction SLP (and nested cycle SLP) is
for example

int a[1024];
void foo (unsigned n)
{
  for (int i = 0; i < 1020; i += 4)
{
  int suma = a[i];
  int sumb = a[i+1];
  int sumc = a[i+2];
  int sumd = a[i+3];
  for (unsigned j = 0; j < 17; ++j)
{
  suma = (suma ^ i) + 1;
  sumb = (sumb ^ i) + 2;
  sumc = (sumc ^ i) + 3;
  sumd = (sumd ^ i) + 4;
}
  a[i] = suma;
  a[i+1] = sumb;
  a[i+2] = sumc;
  a[i+3] = sumd;
}
}

[Bug tree-optimization/97488] [11 Regression] ICE: Segmentation fault (in wi::set_bit_large)

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #3 from Aldy Hernandez  ---
fixed

[Bug tree-optimization/97488] [11 Regression] ICE: Segmentation fault (in wi::set_bit_large)

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

https://gcc.gnu.org/g:2d2f4ffc97a8510e72a99ee106159aeae2627a42

commit r11-4070-g2d2f4ffc97a8510e72a99ee106159aeae2627a42
Author: Aldy Hernandez 
Date:   Mon Oct 19 06:18:46 2020 -0400

Gracefully handle right shifts larger than the precision.

gcc/ChangeLog:

PR tree-optimization/97488
* range-op.cc (operator_lshift::op1_range): Handle large right
shifts.

gcc/testsuite/ChangeLog:

* gcc.dg/pr97488.c: New test.

[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined

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

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

--- Comment #9 from Jakub Jelinek  ---
-fno-allow-store-data-races is fairly new option, previously it has been
--param=allow-store-data-races=0

I have no idea how you've tried to add -save-temps, so can't answer why you get
the error.
What I was suggesting is build with make V=1 and copy/paste the command line
used to compile a particular source file and append -save-temps to those
options

[Bug target/96684] arm: MVE intrinsics / __ARM_undef presence in f16 vector max routine

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

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

SRINATH PARVATHANENI  changed:

   What|Removed |Added

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

--- Comment #2 from SRINATH PARVATHANENI  ---
Committed patch to trunk and gcc-10 branch as below.

commit 251950d899bc3c18b5775fe9fe20bebbdc8d15cb
Author: Joe Ramsay 
Date:   Fri Oct 2 15:28:29 2020 +0100

commit e68d5be766d7b94f2cddb42cc0d62be9039f34e0
Author: Joe Ramsay 
Date:   Fri Oct 2 15:28:29 2020 +0100

arm: Remove coercion from scalar argument to vmin & vmax intrinsics

[Bug target/96683] Arm: MVE ACLE intrinsics vst1q_{s8|u8|s16|u16} is not supported by GCC.

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

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

SRINATH PARVATHANENI  changed:

   What|Removed |Added

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

--- Comment #3 from SRINATH PARVATHANENI  ---
Pushed patch to trunk and gcc-10 branch.

[Bug target/96682] Arm: Wrong code generated for MVE with -O1 and above optimization options.

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

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

SRINATH PARVATHANENI  changed:

   What|Removed |Added

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

--- Comment #2 from SRINATH PARVATHANENI  ---
Pushed fix to trunk and gcc-10 branches.

[Bug gcov-profile/91601] gcov: ICE in handle_cycle, at gcov.c:699 happen which get code coverage with lcov.

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

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

--- Comment #18 from Martin Liška  ---
(In reply to Fangrui Song from comment #17)
> The algorithm is Donald B. Johnson's "Finding all the elementary circuits of
> a directed graph" (1975). (Hawick and James's just implemented the same
> algorithm by changing the representation of graphs).
> 
> I am wondering why we enumerate every elementary cycle, find the minimum
> edge, reduce edge weighs, and repeat the process.

I basically taken the original patch submission and finished it.

> 
> What do we lose if we don't use the costly algorithm? (The time complexity
> is O(n*e*(c+1)). However, many implementations (Boost and gcov.c) do not use
> a hash set for the blocked list, and thus I suspect the actual complexity is
> higher). Do we have other low-cost approaches? (e.g. repeatedly finding
> strongly connected components and reducing)

Do you have a test-case where it is significant?
Feel free to provide a patch which can make it faster, I'll appreciate and
review it.

[Bug tree-optimization/80928] SLP vectorization does not handle induction in outer loop vectorization

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

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

--- Comment #28 from Richard Biener  ---
Yes, the original issue is still present.

[Bug analyzer/97489] [11 Regression] ICE: Segmentation fault (in ana::supergraph::get_node_for_function_entry(function*) const) since r10-5950-g757bf1dff5e8cee3

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-10-19
  Known to work||10.2.0
Summary|[11 Regression] ICE:|[11 Regression] ICE:
   |Segmentation fault (in  |Segmentation fault (in
   |ana::supergraph::get_node_f |ana::supergraph::get_node_f
   |or_function_entry(function* |or_function_entry(function*
   |) const)|) const) since
   ||r10-5950-g757bf1dff5e8cee3
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org
  Known to fail||11.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-5950-g757bf1dff5e8cee3.

[Bug middle-end/97487] [10/11 Regression] ICE in expand_simple_binop, at optabs.c:939 since r10-1420-g744fd446c321f78f

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE in   |[10/11 Regression] ICE in
   |expand_simple_binop, at |expand_simple_binop, at
   |optabs.c:939|optabs.c:939 since
   ||r10-1420-g744fd446c321f78f
   Last reconfirmed||2020-10-19
 Status|UNCONFIRMED |NEW
  Known to fail||10.2.0, 11.0
  Known to work||9.3.0
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-1420-g744fd446c321f78f.

[Bug sanitizer/97490] [10/11 Regression] false-positive -Wstringop-overflow= with address sanitizer since r10-5451-gef29b12cfbb4979a

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-10-19
Summary|[10/11 Regression]  |[10/11 Regression]
   |false-positive  |false-positive
   |-Wstringop-overflow= with   |-Wstringop-overflow= with
   |address sanitizer   |address sanitizer since
   ||r10-5451-gef29b12cfbb4979a
 Ever confirmed|0   |1
  Known to fail||10.2.0, 11.0
 Status|UNCONFIRMED |NEW
  Known to work||9.3.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with Martin's commit.

[Bug target/97327] -mcpu=cortex-m55 warns without -mfloat-abi=hard or -march=armv8.1-m.main

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

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

SRINATH PARVATHANENI  changed:

   What|Removed |Added

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

--- Comment #8 from SRINATH PARVATHANENI  ---
Committed patches to trunk and GCC-10 branches.