[Bug c++/99910] [11/12 Regression] g++.dg/modules/xtreme-header-2_b.C ICE

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

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

--- Comment #9 from Andrew Pinski  ---
I am reducing a similar bug via PR 100129, I think this is all GC related which
is why header changes and other non-looking changes in the front-end make it
come and go.

[Bug c++/100052] [11/12 regression] ICE in compiling g++.dg/modules/xtreme-header-3_b.C after r11-8118

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||GC, ice-on-valid-code

--- Comment #5 from Andrew Pinski  ---
I am reducing a similar bug via PR 100129, I think this is all GC related which
is why header changes and other non-looking changes in the front-end make it
come and go.

[Bug rtl-optimization/63281] powerpc64le creates 64 bit constants from scratch instead of loading them

[amodra at gmail dot com via Gcc-bugs]

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

--- Comment #15 from Alan Modra  ---
(In reply to Jiu Fu Guo from comment #14)
> It would be a way to keep the data in memory(.rodata) through adjusting the
> cost of constant.

Yes, I posted a series of patches that fix this problem and other rtx costs. 
Look for patches with "rs6000_rtx_costs" in the subject.  Some of the patches
were even approved, but not all in the series.  I am disillusioned enough with
gcc that I won't be pushing those patches or attempting any future gcc work. 
You or anyone else are welcome to pick up the pieces.

[Bug tree-optimization/95424] Failure to optimize division with numerator of 1

[zhaoweiliew at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Zhao Wei Liew  ---
Created attachment 52091
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52091&action=edit
Tested patch for the case of unsigned integer X

I tried to tackle the unsigned integer X case by adding an optimization in
match.pd. I suppose it can be done similarly for the signed integer X case as
well, but I'll need more time to look into that.

I've attached the proposed patch. With this patch, GCC generates the same
assembly output as Clang.

int f(unsigned int x) {
return 1 / x;
}


.LFB0:
.cfi_startproc
xorl%eax, %eax
cmpl$1, %edi
sete%al
ret

[Bug c++/100129] [modules] ICE free(): invalid pointer

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

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

--- Comment #4 from Andrew Pinski  ---
It is Looking tuple/template parameter pack/specialization related.

[Bug tree-optimization/103864] [11/12 Regression] ICE in vect_transform_reduction, at tree-vect-loop.c:7389

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||10.3.0
  Known to fail||11.1.0, 11.2.0, 12.0
 Ever confirmed|0   |1
   Last reconfirmed||2021-12-30
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/103864] [11/12 Regression] ICE in vect_transform_reduction, at tree-vect-loop.c:7389

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.3

[Bug tree-optimization/103864] New: [11/12 Regression] ICE in vect_transform_reduction, at tree-vect-loop.c:7389

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 103864
   Summary: [11/12 Regression] ICE in vect_transform_reduction, at
tree-vect-loop.c:7389
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: aarch64-linux-gnu

gcc 12.0.0 20211226 (g:d87483015d476a95f521f0c9dcf6988ca889063b) ICEs when
compiling the following testcase, reduced from
gcc/testsuite/gcc.dg/vect/pr103544.c, w/ -O3 -fno-tree-reassoc:

void
crash_me (short int *crash_me_result, int i, char crash_me_ptr_0)
{
  while (i < 1)
{
  int j;

  for (j = 0; j < 2; ++j)
crash_me_result[j] += crash_me_ptr_0 + 1;

  i += 3;
}
}

% aarch64-linux-gnu-gcc-12.0.0 -O3 -fno-tree-reassoc -c iyhuldkz.c
during GIMPLE pass: vect
iyhuldkz.c: In function 'crash_me':
iyhuldkz.c:2:1: internal compiler error: in vect_transform_reduction, at
tree-vect-loop.c:7389
2 | crash_me (short int *crash_me_result, int i, char crash_me_ptr_0)
  | ^~~~
0x7b8353 vect_transform_reduction(_loop_vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, gimple**, _slp_tree*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211226/work/gcc-12-20211226/gcc/tree-vect-loop.c:7389
0x1bf70c0 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211226/work/gcc-12-20211226/gcc/tree-vect-stmts.c:11255
0x1193427 vect_schedule_slp_node
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211226/work/gcc-12-20211226/gcc/tree-vect-slp.c:7270
0x11a53ac vect_schedule_scc
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211226/work/gcc-12-20211226/gcc/tree-vect-slp.c:7514
0x11a6417 vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211226/work/gcc-12-20211226/gcc/tree-vect-slp.c:7579
0x117fa10 vect_transform_loop(_loop_vec_info*, gimple*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211226/work/gcc-12-20211226/gcc/tree-vect-loop.c:9625
0x11b273f vect_transform_loops
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211226/work/gcc-12-20211226/gcc/tree-vectorizer.c:1003
0x11b273f try_vectorize_loop_1
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211226/work/gcc-12-20211226/gcc/tree-vectorizer.c:1133
0x11b273f try_vectorize_loop
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211226/work/gcc-12-20211226/gcc/tree-vectorizer.c:1162
0x11b2f84 execute
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211226/work/gcc-12-20211226/gcc/tree-vectorizer.c:1278

[Bug c++/100129] [modules] ICE free(): invalid pointer

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

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

--- Comment #3 from Andrew Pinski  ---
Add --param=ggc-min-expand=1 we get:
hash table checking failed: equal operator returns true for a pair of values
with a different hash value
In file included from /home/apinski/upstream-gcc/include/c++/12.0.0/future:44:
/home/apinski/upstream-gcc/include/c++/12.0.0/bits/atomic_futex.h:76:5:
internal compiler error: in hashtab_chk_error, at hash-table.c:137
   76 | atomic _M_data;
  | ^~
0x9bab97 hashtab_chk_error()
/home/apinski/src/upstream-gcc/gcc/gcc/hash-table.c:137
0xbd7e85 hash_table::verify(spec_entry*
const&, unsigned int)
/home/apinski/src/upstream-gcc/gcc/gcc/hash-table.h:1036
0xbd840c hash_table::find_slot_with_hash(spec_entry* const&, unsigned int,
insert_option)
/home/apinski/src/upstream-gcc/gcc/gcc/hash-table.h:971
0xb93d0b match_mergeable_specialization(bool, spec_entry*)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/pt.c:30400
0xb0531c trees_in::key_mergeable(int, merge_kind, tree_node*, tree_node*,
tree_node*, tree_node*, bool)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/module.cc:10683
0xb0925e trees_in::decl_value()
/home/apinski/src/upstream-gcc/gcc/gcc/cp/module.cc:7911
0xb02147 trees_in::tree_node(bool)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/module.cc:9164
0xb0864b module_state::read_cluster(unsigned int)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/module.cc:14830
0xb08be5 module_state::load_section(unsigned int, binding_slot*)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/module.cc:18101
0xb08d9e lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/module.cc:18792
0xb1abed name_lookup::search_namespace_only(tree_node*)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/name-lookup.c:927
0xb1c0f3 name_lookup::search_unqualified(tree_node*, cp_binding_level*)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/name-lookup.c:1157
0xb1de2d lookup_name(tree_node*, LOOK_where, LOOK_want)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/name-lookup.c:7739
0xb2f229 lookup_name(tree_node*, LOOK_want)
/home/apinski/src/upstream-gcc/gcc/gcc/cp/name-lookup.h:401
0xb2f229 cp_parser_lookup_name
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:30528
0xb5adf8 cp_parser_template_name
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:18539
0xb5b409 cp_parser_template_id
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:18143
0xb5bd6b cp_parser_class_name
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:25640
0xb5271e cp_parser_qualifying_entity
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:7061
0xb5271e cp_parser_nested_name_specifier_opt
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:6743
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

I am going to assume this is the same bug when I reducing it but if it is not
then I will deal with it later.

[Bug rtl-optimization/63281] powerpc64le creates 64 bit constants from scratch instead of loading them

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

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

--- Comment #14 from Jiu Fu Guo  ---
For constant like 0x0008411, which is using 5 insns, at 'expand' pass,
it is treated as preferred to save in memory, while at cse1 pass, it was
replaced back to constant.

expand:
7: r119:DI=[unspec[`*.LC0',%r2:DI] 47]
  REG_EQUAL 0x8411
8: [r117:DI]=r119:DI

cse1:
7: r119:DI=0x8411
  REG_EQUAL 0x8411
8: [r117:DI]=r119:DI

This is because:
expand_assignment invoke force_const_mem/gen_const_mem under the condition:
(num_insns_constant (operands[1], mode) > (TARGET_CMODEL != CMODEL_SMALL ? 3 :
2))

At cse1, when comparing the cost between 'fold_const' and 'src', 'fold_const'
is selected
'preferable (src_folded_cost, src_folded_regcost, src_cost, src_regcost) <= 0'

src:
(mem/u/c:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC0") [flags 0x82])
(reg:DI 2 2)
] UNSPEC_TOCREL) [2  S8 A8])
fold_const:
(const_int 140737556512769 [0x8411])

It would be a way to keep the data in memory(.rodata) through adjusting the
cost of constant.

[Bug driver/103863] We need a warning for loss of no-exec stacks

[noloader at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Jeffrey Walton  ---
(In reply to Andrew Pinski from comment #1)
> I think the warning needs to be implemented in the linker rather than in GCC
> because the linker is what decides if there are executable stacks are needed
> or not.

Thanks Andrew.

I thought about a linker warning, too. Do they have to be mutually exclusive
(warning in compiler vs warning in linker)?

I also asked the Binutil folks for some feedback:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103863.

[Bug driver/103863] We need a warning for loss of no-exec stacks

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug driver/103863] We need a warning for loss of no-exec stacks

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|c   |driver

--- Comment #1 from Andrew Pinski  ---
I think the warning needs to be implemented in the linker rather than in GCC
because the linker is what decides if there are executable stacks are needed or
not.

[Bug c/103863] New: We need a warning for loss of no-exec stacks

[noloader at gmail dot com via Gcc-bugs]

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

Bug ID: 103863
   Summary: We need a warning for loss of no-exec stacks
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

Hello,

This is a feature request.

For targets that support no-exec stacks, we need a warning when GCC generates
code or drives the linker with loss of no-exec stacks.

The warning would be beneficial for most builds nowadays since no-exec stacks
are part of most distro hardening. For example, Debian and Fedora both
incorporate it into their build system; and special steps must be taken to
avoid no-exec stacks out of the box.

The warning would also be beneficial in cases like
https://bugzilla.redhat.com/show_bug.cgi?id=2035802. In the 2035802 bug, an ARM
machine failed to boot because libz contained executable stacks even though
they were not needed.

A specific warning for no-exec stacks is slightly different than -Wtrampolines.
While trampolines resulted in executable stacks in the past, that may not hold
in the future as lambdas are added to the language. And trampolines are not a
necessary precondition to get in an insecure state like the 2035802 bug shows.

It is most unfortunate that ASM files need special handling because the object
files are marked with executable stacks by default. Maybe that should be
another bug report to change default behavior since the strategy nowadays is:
no-exec stacks by default, do something special for executable stacks.

Thanks in advance.

[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module

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

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

--- Comment #13 from kargl at gcc dot gnu.org ---
(In reply to ally.alto.0z from comment #12)
> Bill you say you are a “master engineer” and have 25 years of Fortran
> experience and are a principal member of a Fortran committee.
> 
> Would it be unexpected for someone with that experience to offer a fix
> themselves rather than treating this like a free source of labor for their
> lucrative support contracts?

I'm not Bill.  Bill is employed by Cray to work on the Cray Fortran
compiler.  He has been quite helpful in reporting gfortran issues
found either by Cray or by Cray users.

That said, I see that you forgot to attach the patch that you have
developed to fix this issue.  For the record, the patch in comment 
#9 is mine.

[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module

[ally.alto.0z at icloud dot com via Gcc-bugs]

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

ally.alto.0z at icloud dot com changed:

   What|Removed |Added

 CC||ally.alto.0z at icloud dot com

--- Comment #12 from ally.alto.0z at icloud dot com ---
Bill you say you are a “master engineer” and have 25 years of Fortran
experience and are a principal member of a Fortran committee.

Would it be unexpected for someone with that experience to offer a fix
themselves rather than treating this like a free source of labor for their
lucrative support contracts?

[Bug c++/100129] [modules] ICE free(): invalid pointer

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #2 from Andrew Pinski  ---
Trying to reduce this.

[Bug libstdc++/100057] There are no freestanding C++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #36 from cqwrteur  ---
(In reply to Nicolas Noble from comment #34)
> After some digging, I found out this in the acinclude.m4 file of the
> libstdc++-v3 folder:
> 
> AC_DEFUN([GLIBCXX_ENABLE_HOSTED], [
>   AC_ARG_ENABLE([hosted-libstdcxx],
> AC_HELP_STRING([--disable-hosted-libstdcxx],
>[only build freestanding C++ runtime support]),,
> [case "$host" in
> arm*-*-symbianelf*)
> enable_hosted_libstdcxx=no
> ;;
> *)
> enable_hosted_libstdcxx=yes
> ;;
>  esac])
> 
> 
> Basically, it looks like the "disable hosted libstdc++" flag is only honored
> when building on a host triple that's arm + symbian. The documentation +
> reporting for this is extremely misguiding. The documentation should at
> least specify this only works in a very narrow context, and the configure
> script should probably error out if the user asks for a feature it can't
> actually provide.

DEATH TO WG21

[Bug libstdc++/100057] There are no freestanding C++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #35 from cqwrteur  ---
(In reply to Nicolas Noble from comment #34)
> After some digging, I found out this in the acinclude.m4 file of the
> libstdc++-v3 folder:
> 
> AC_DEFUN([GLIBCXX_ENABLE_HOSTED], [
>   AC_ARG_ENABLE([hosted-libstdcxx],
> AC_HELP_STRING([--disable-hosted-libstdcxx],
>[only build freestanding C++ runtime support]),,
> [case "$host" in
> arm*-*-symbianelf*)
> enable_hosted_libstdcxx=no
> ;;
> *)
> enable_hosted_libstdcxx=yes
> ;;
>  esac])
> 
> 
> Basically, it looks like the "disable hosted libstdc++" flag is only honored
> when building on a host triple that's arm + symbian. The documentation +
> reporting for this is extremely misguiding. The documentation should at
> least specify this only works in a very narrow context, and the configure
> script should probably error out if the user asks for a feature it can't
> actually provide.

wg21 just did a crappy job on this shit and GCC does not give a shit on
freestanding either.

You do not have std::addressof, std::move, std::array but the fucking ISO
forces you to use EH and RTTI.

C++ considered harmful for embedded and kernel.

[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

https://gcc.gnu.org/g:62c3f75fd29e93054f3aeb8a623fd52c98c3db0b

commit r12-6147-g62c3f75fd29e93054f3aeb8a623fd52c98c3db0b
Author: Ian Lance Taylor 
Date:   Wed Dec 29 15:08:32 2021 -0800

compiler, libgo: don't pad sparc64-linux epollevent

Change the compiler to not add zero padding because of zero-sized
fields named "_", since those can't be referenced anyhow.

Change the sparc-linux64 epollevent struct to name the alignment
field "_", to avoid zero padding.

Fixes PR go/103847

PR go/103847
* godump.c (go_force_record_alignment): Name the alignment
field "_".

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/374914

[Bug c++/103862] Regression: -Wold-style-cast warns about system macros

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Carlos Galvez  ---
Interesting, thanks for the quick reply! In case it helps, if I include the
header as a regular header, I do get the "note" referring to the system header:

# g++-11 -I include -Wold-style-cast main.cpp
In file included from main.cpp:1:
main.cpp: In function 'int main()':
main.cpp:5:21: warning: use of old-style cast to 'int' [-Wold-style-cast]
5 | int x = MY_CAST(123);
  | ^~~
include/third_party.h:3:26: note: in definition of macro 'MY_CAST'
3 | #define MY_CAST(x) ((int)x)
  |

[Bug c++/103862] Regression: -Wold-style-cast warns about system macros

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #2 from Andrew Pinski  ---
(In reply to Carlos Galvez from comment #0)
> Hi,
> 
> I thought this problem was solved by reading this: 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12258

That is a different issue, there the expression is fully from the system header
while here the constant is from a non-system header.

It looks like the warning is being based on where the inner expression is from
rather than where the cast is located.

[Bug c++/103862] Regression: -Wold-style-cast warns about system macros

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Carlos Galvez  ---
The problem exists also in GCC 9.4.0

[Bug preprocessor/12258] -Wold-style-cast triggers on casts in macros from system headers

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

Carlos Galvez  changed:

   What|Removed |Added

 CC||carlosgalvezp at gmail dot com

--- Comment #6 from Carlos Galvez  ---
Hi,

This problem seems to be back in GCC 9 and 11:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103862

[Bug c++/103862] New: Regression: -Wold-style-cast warns about system macros

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

Bug ID: 103862
   Summary: Regression: -Wold-style-cast warns about system macros
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlosgalvezp at gmail dot com
  Target Milestone: ---

Hi,

I thought this problem was solved by reading this: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12258

But I can still find it on GCC 11.1:

// include/third_party.h
#pragma once

#define MY_CAST(x) ((int)x)

// main.cpp
#include 

int main() 
{
int x = MY_CAST(123);
return x;
}

# g++-11 -isystem include -Wold-style-cast main.cpp
In file included from main.cpp:1:
main.cpp: In function 'int main()':
main.cpp:5:21: warning: use of old-style cast to 'int' [-Wold-style-cast]
5 | int x = MY_CAST(123);
  | ^~~

# g++-11 --version
g++-11 (Ubuntu 11.1.0-1ubuntu1~20.04) 11.1.0

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 99222 Summary: [modules] system header-unit ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99222

   What|Removed |Added

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

[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files

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

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

Bug 99222 Summary: [modules] system header-unit ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99222

   What|Removed |Added

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

[Bug c++/99245] [modules] ICE in write_cluster, at cp/module.cc:14600

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

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

--- Comment #5 from Andrew Pinski  ---
*** Bug 99222 has been marked as a duplicate of this bug. ***

[Bug c++/99222] [modules] system header-unit ICEs

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 99245.

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

[Bug libstdc++/100057] There are no freestanding C++

[pixel--- via Gcc-bugs]

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

--- Comment #34 from Nicolas Noble  ---
After some digging, I found out this in the acinclude.m4 file of the
libstdc++-v3 folder:

AC_DEFUN([GLIBCXX_ENABLE_HOSTED], [
  AC_ARG_ENABLE([hosted-libstdcxx],
AC_HELP_STRING([--disable-hosted-libstdcxx],
   [only build freestanding C++ runtime support]),,
[case "$host" in
arm*-*-symbianelf*)
enable_hosted_libstdcxx=no
;;
*)
enable_hosted_libstdcxx=yes
;;
 esac])


Basically, it looks like the "disable hosted libstdc++" flag is only honored
when building on a host triple that's arm + symbian. The documentation +
reporting for this is extremely misguiding. The documentation should at least
specify this only works in a very narrow context, and the configure script
should probably error out if the user asks for a feature it can't actually
provide.

[Bug libstdc++/100057] There are no freestanding C++

[pixel--- via Gcc-bugs]

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

Nicolas Noble  changed:

   What|Removed |Added

 CC||pi...@nobis-crew.org

--- Comment #33 from Nicolas Noble  ---
I'll echo a bit the sentiment in this thread, with a nuance: there's definitely
documentation needed around how to make a freestanding libstdc++, or how to use
the --disable-hosted-libstdcxx flag properly.

I've been trying to make a bare metal mips compiler out of gcc 11.2.0 using the
following flags:

../configure --target=mipsel-none-elf --without-isl --disable-nls
--disable-threads --disable-shared --disable-libssp --disable-libstdcxx-pch
--disable-libgomp --disable-werror --without-headers
--with-as=/usr/local/bin/mipsel-none-elf-as
--with-ld=/usr/local/bin/mipsel-none-elf-ld --enable-languages=c,c++
--disable-hosted-libstdcxx

This works with the following make statements:

make all-gcc
make install-strip-gcc
make all-target-libgcc
make install-strip-target-libgcc

This makes and installs a proper compiler for C, and some basic C++, but
without bare metal C++ headers such as type traits.

When trying to do run:

make all-target-libstdc++-v3

Then we end up with the error

checking for shl_load... configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.

At the moment, I don't understand if it's possible to spawn a cross compiler
with a freestanding libc and libstdc++.

[Bug c++/100129] [modules] ICE free(): invalid pointer

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||GC, ice-on-valid-code

--- Comment #1 from Andrew Pinski  ---
apinski@xeond:~/src/pr100129$ g++ --param=hash-table-verification-limit=1000
-std=c++20 -fmodules-ts -x c++-system-header condition_variable
apinski@xeond:~/src/pr100129$ g++ --param=hash-table-verification-limit=1000
-std=c++20 -fmodules-ts -x c++-system-header future
free(): invalid pointer
malloc(): memory corruption (fast)
g++: internal compiler error: Aborted signal terminated program cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Is enough to reproduce the failure.

#0  __memset_avx2_erms () at
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:145
#1  0x00cda0fa in clear_marks() () at
/home/apinski/src/upstream-gcc/gcc/gcc/ggc-page.c:1901
#2  0x00cdb6bd in ggc_collect(ggc_collect) () at
/home/apinski/src/upstream-gcc/gcc/gcc/ggc-page.c:2226
#3  0x00bf2477 in expand_or_defer_fn_1(tree_node*) () at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/semantics.c:4707
#4  0x00bf2579 in expand_or_defer_fn(tree_node*) () at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/semantics.c:4779
#5  0x00b6d448 in
cp_parser_function_definition_after_declarator(cp_parser*, bool) () at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:31188
#6  0x00b6d8cd in cp_parser_late_parsing_for_member(cp_parser*,
tree_node*) () at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:32096
#7  0x00b4632c in cp_parser_class_specifier_1(cp_parser*) () at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:26116
#8  0x00b4731f in cp_parser_class_specifier (parser=) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:26140
#9  cp_parser_type_specifier(cp_parser*, int, cp_decl_specifier_seq*, bool,
int*, bool*) () at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:19293
#10 0x00b48274 in cp_parser_decl_specifier_seq(cp_parser*, int,
cp_decl_specifier_seq*, int*) () at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:15856
#11 0x00b75db7 in cp_parser_single_declaration(cp_parser*,
vec*, bool, bool, bool*) () at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:31580
#12 0x00b76217 in
cp_parser_template_declaration_after_parameters(cp_parser*, tree_node*, bool)
() at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:31243
#13 0x00b76aa1 in cp_parser_explicit_template_declaration(cp_parser*,
bool) () at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:31509
#14 0x00b77228 in cp_parser_template_declaration_after_export
(member_p=, parser=) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:31528
#15 cp_parser_template_declaration(cp_parser*, bool) () at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:17407
#16 0x00b79452 in cp_parser_declaration(cp_parser*, tree_node*) () at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:14849
#17 0x00b789fa in cp_parser_toplevel_declaration
(parser=0x76d3a000) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:14939
#18 cp_parser_declaration_seq_opt (parser=parser@entry=0x76d3a000) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:14692
#19 0x00b78e65 in cp_parser_namespace_body (parser=) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:21323
#20 cp_parser_namespace_definition(cp_parser*) () at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:21301
#21 0x00b79588 in cp_parser_declaration(cp_parser*, tree_node*) () at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:14898
#22 0x00b79f03 in cp_parser_toplevel_declaration
(parser=0x76d3a000) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:14939
#23 cp_parser_translation_unit (parser=0x76d3a000, parser@entry=) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:4987
#24 c_parse_file() () at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:47946
#25 0x00caa8de in c_common_parse_file () at
/home/apinski/src/upstream-gcc/gcc/gcc/c-family/c-opts.c:1238
#26 0x011e752e in compile_file () at
/home/apinski/src/upstream-gcc/gcc/gcc/toplev.c:452
#27 0x009bed04 in do_compile (no_backend=false) at
/home/apinski/src/upstream-gcc/gcc/gcc/toplev.c:2158
#28 toplev::main(int, char**) () at
/home/apinski/src/upstream-gcc/gcc/gcc/toplev.c:2310
#29 0x009c041b in main (argc=21, argv=0x7fffdd58) at
/home/apinski/src/upstream-gcc/gcc/gcc/main.c:39

[Bug tree-optimization/103856] ICE during GIMPLE pass: hardcmp since r12-4759-g95bb87b2458bfab4

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-12-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed, unlike PR 103024, this one has a PHI node for the successor of the
bb containing the comparison at the end.

[Bug tree-optimization/103024] ICE in execute, at gimple-harden-conditionals.cc:424 with -fnon-call-exceptions -fharden-compares -fsignaling-nans

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug debug/103742] [12 Regression] '-fcompare-debug' failure (length) with -O2 -fnon-call-exceptions --param=early-inlining-insns=82 since r12-5301-g045206450386bcd7

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug debug/103742] [12 Regression] '-fcompare-debug' failure (length) with -O2 -fnon-call-exceptions --param=early-inlining-insns=82 since r12-5301-g045206450386bcd7

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

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

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

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

commit r12-6146-ge5acfcad98f3fa33e141f4e6bc06f7d7c13496e1
Author: Jakub Jelinek 
Date:   Wed Dec 29 21:46:21 2021 +0100

tree-ssa-dce: Fix up -fcompare-debug failures in
make_forwarders_with_degenerate_phis [PR103742]

make_forwarders_with_degenerate_phis causes a -fcompare-debug failure on
the
following testcase.
The problem is that on:
  # iftmp.4_8 = PHI <&D.2582(6), &D.2583(4), &D.2582(7), &D.2583(5)>
the exact DECL_UIDs are different between -g and -g0 (which is ok, with -g
the decls can have larger gaps in between the uids), which means
iterative_hash_expr is different and because there are 2 pairs of edges
with matching phi arguments, the function processes them in different
orders.
The following patch fixes it by using the iterative_hash_expr order
only to determine which arguments are the same, then replaces the hashes
with the minimum dest_idx in the set of matching arguments and qsorts
again (which makes it stable for -fcompare-debug) and only splits edges
etc.
on that stable order.
As a small optimization, if no arguments are equal, it doesn't do the
second qsort and continues, and if all arguments of the PHI are
constants or SSA_NAMEs (I think that is a pretty common case for many
PHIs), then it doesn't do the second qsort either, because in that case
the hash values will be stable, only computed from the constant values or
SSA_NAME_VERSIONs.

2021-12-29  Jakub Jelinek  

PR debug/103742
* tree-ssa-dce.c (make_forwarders_with_degenerate_phis): If any phi
argument is not CONSTANT_CLASS_P or SSA_NAME and any arguments are
equal, change second from hash value to lowest dest_idx from the
edges which have equal argument and resort to ensure
-fcompare-debug
stability.

* g++.dg/opt/pr103742.C: New test.

[Bug target/103861] [i386] vectorize v2qi vectors

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Last reconfirmed||2021-12-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #4 from Andrew Pinski  ---
Confirmed.

[Bug objc/103639] [11/12 Regression] switch case with break in fast enumeration loop generates wrong code

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

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

--- Comment #16 from Iain Sandoe  ---
(In reply to Jakub Jelinek from comment #15)
> Yeah, and probably no need for the printf calls...

indeed.

works for me on x86_64-darwin18 and powerpc-darwin9 (m32, m64, NeXT and GNU
runtimes)
I can cover more cases later in the week - but if it DTRT on Linux too I'd say
LGTM.

[Bug objc/103639] [11/12 Regression] switch case with break in fast enumeration loop generates wrong code

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

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

--- Comment #15 from Jakub Jelinek  ---
Yeah, and probably no need for the printf calls...

[Bug rtl-optimization/103860] [9/10/11/12 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

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

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

--- Comment #7 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 52089 [details]
> gcc12-pr103860.patch
> 
> Not sure I understand what you'd like to see.

Exactly what you did :-)  Well, I didn't see you could fold it all up like
that, wow.

> But, thinking more about it, we can easily avoid all the code duplication by
> moving the vec.is_empty () test out of the while loop condition, right
> before we pop from the stack.  That way this can_get_prologue check is done
> on pro not just before we pop something from the stack, but also after the
> last iteration
> when there is nothing further on the stack.

Yup.

> If we wanted to avoid calling can_get_prologue that often (if pro doesn't
> change we call it again and again already before my patch), we could also
> add a var to hold the last pro we've successfully checked and only do this
> checking if we get a new pro.

How can pro not change?  It is important that can_get_prologue is called at
most once for every block, so that this is O(n) for every function (in number
of edges in this case).  All of this is linear, I'd like to keep it that way!

[Bug objc/103639] [11/12 Regression] switch case with break in fast enumeration loop generates wrong code

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

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

--- Comment #14 from Iain Sandoe  ---
I suppose

+check += 1;
+printf ("foo\n");
+  }
+
+  if (check != 2)


would be a more picky test.

[Bug tree-optimization/103857] implement ternary without jump (and comparison)

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> Reduced testcase:
> int f(int a, int b, int c)
> {
>   if (a != b && a != c) __builtin_unreachable();
>   return a == b ? b : c;
> }
> 
> This should just translate into:
> int f1(int a, int b, int c)
> {
>   if (a != b && a != c) __builtin_unreachable();
>   return a;
> }
> 
> The ^ part is not needed really if it is just selecting between two values.

Oh it was swapping around the two values:

int f(int a, int b, int c)
{
  if (a != b && a != c) __builtin_unreachable();
  return a == b ? c : b;
}
int f1(int a, int b, int c)
{
  if (a != b && a != c) __builtin_unreachable();
  return a ^ b ^ c;
}

And then the ^ are needed.

[Bug tree-optimization/103857] implement ternary without jump (and comparison)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
 Ever confirmed|0   |1
   Severity|normal  |enhancement
   Last reconfirmed||2021-12-29

--- Comment #3 from Andrew Pinski  ---
Reduced testcase:
int f(int a, int b, int c)
{
  if (a != b && a != c) __builtin_unreachable();
  return a == b ? b : c;
}

This should just translate into:
int f1(int a, int b, int c)
{
  if (a != b && a != c) __builtin_unreachable();
  return a;
}

The ^ part is not needed really if it is just selecting between two values.

[Bug middle-end/103770] [11 Regression] ICE related to VLA

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dtorrance at piedmont dot edu

--- Comment #4 from Andrew Pinski  ---
*** Bug 103859 has been marked as a duplicate of this bug. ***

[Bug c/103859] [11 Regression] ICE when function declaration parameter list contains sized arrays

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|WAITING |RESOLVED

--- Comment #4 from Andrew Pinski  ---
Dup of bug 103770.

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

[Bug c/103859] [11 Regression] ICE when function declaration parameter list contains sized arrays

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

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

--- Comment #3 from Andrew Pinski  ---
I think there is a dup of this bug already and was already fixed for gcc
11.3.0.

[Bug objc/103639] [11/12 Regression] switch case with break in fast enumeration loop generates wrong code

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

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

--- Comment #13 from Iain Sandoe  ---
Created attachment 52090
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52090&action=edit
patch with test case

this is what I'm going to test (it passes for NeXT and GNU runtimes on
x86_64-darwin18, but needs wider testing) -- it should work also on Linux.

[Bug rtl-optimization/103860] [9/10/11/12 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #52088|0   |1
is obsolete||

--- Comment #6 from Jakub Jelinek  ---
Created attachment 52089
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52089&action=edit
gcc12-pr103860.patch

Not sure I understand what you'd like to see.
But, thinking more about it, we can easily avoid all the code duplication by
moving the vec.is_empty () test out of the while loop condition, right before
we pop from the stack.  That way this can_get_prologue check is done on pro not
just before we pop something from the stack, but also after the last iteration
when there is nothing further on the stack.

If we wanted to avoid calling can_get_prologue that often (if pro doesn't
change we call it again and again already before my patch), we could also add a
var to hold the last pro we've successfully checked and only do this checking
if we get a new pro.

[Bug libffi/102923] [12 Regression] powerpc64 (BE) linux all languages bootstrap broken after libffi 3.4.2 import.

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #10 from Segher Boessenkool  ---
Yes.  At the time I considered it more a bandaid than a fix, but it
obviously is the right thing to do no matter what :-)  Closing as fixed,
thanks!

[Bug rtl-optimization/103860] [9/10/11/12 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

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

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

--- Comment #5 from Segher Boessenkool  ---
That looks good.  But can you always set maybe_check_pro to true (and then
optimise it away of course)?

[Bug libbacktrace/103822] libbacktrace make check fails with GNU Make 3.81

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |12.0

--- Comment #2 from Francois-Xavier Coudert  ---
Fixed by
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0ac7bab6181cf3400ba1f53fd6aac92900eef1e5

[Bug testsuite/47334] g++.dg/torture/pr31863.C -O2 -flto FAILs without visibility

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #6 from Francois-Xavier Coudert  ---
Fixed by
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=05edf6c470ae0ab50d42f16e78e476dbcc774842

[Bug testsuite/103823] g++.dg/torture/pr31863.C fails on darwin with "using serial compilation of 2 LTRANS jobs"

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #11 from Francois-Xavier Coudert  ---
Fixed by
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=05edf6c470ae0ab50d42f16e78e476dbcc774842

[Bug rtl-optimization/103860] [9/10/11/12 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 52088
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52088&action=edit
gcc12-pr103860.patch

Untested fix.

[Bug target/103861] [i386] vectorize v2qi vectors

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Uroš Bizjak  ---
The patched compiler compiles the testcase from Comment #0 on x86_64 with -O2
to:

plus:
movl%edi, %edx
movl%esi, %eax
addb%sil, %dl
addb%ah, %dh
movl%edx, %eax
ret

and the testcase from Comment #1 to:

foo:
movzwl  a(%rip), %edx
movzwl  b(%rip), %eax
addb%dl, %al
addb%dh, %ah
movw%ax, r(%rip)
ret

Some additional examples:

char r[2], a[2], b[2];

void maxs (void)
{
  int i;

  for (i = 0; i < 2; i++)
r[i] = a[i] > b[i] ? a[i] : b[i];
}

compiles with -O2 -msse4 to:

maxs:
pinsrw  $0, b(%rip), %xmm0
pinsrw  $0, a(%rip), %xmm1
pmaxsb  %xmm1, %xmm0
pextrw  $0, %xmm0, r(%rip)
ret

[Bug fortran/102332] ICE in select_type_set_tmp, at fortran/match.c:6366

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r12-6143-gd8f6c48ccb85ecc0d97a84c32b7a1b8f43c64fe4
Author: Harald Anlauf 
Date:   Mon Dec 27 23:06:18 2021 +0100

Fortran: avoid several NULL pointer dereferences during error recovery

gcc/fortran/ChangeLog:

PR fortran/102332
* expr.c (gfc_get_variable_expr): Avoid NULL pointer dereferences
during handling of errors with invalid uses of CLASS variables.
* match.c (select_type_set_tmp): Likewise.
* primary.c (gfc_match_varspec): Likewise.
* resolve.c (resolve_variable): Likewise.
(resolve_select_type): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/102332
* gfortran.dg/pr102332.f90: New test.

[Bug target/103861] [i386] vectorize v2qi vectors

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Uroš Bizjak  ---
Created attachment 52087
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52087&action=edit
Protorypw patch to vectorize with v2qi vectors

Patch that implmenents V2QI moves, logic and basic arithmetic operations.

[Bug target/103861] [i386] vectorize v2qi vectors

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Uroš Bizjak  ---
Also:

char r[2], a[2], b[2];

void foo (void)
{
  int i;

  for (i = 0; i < 2; i++)
r[i] = a[i] + b[i];
}

[Bug rtl-optimization/103860] [9/10/11/12 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

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

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

--- Comment #3 from Jakub Jelinek  ---
In the:
  while (!vec.is_empty () && pro != entry)
{
  while (pro != entry && !can_get_prologue (pro, prologue_clobbered))
{
  pro = get_immediate_dominator (CDI_DOMINATORS, pro);

  if (bitmap_set_bit (bb_with, pro->index))
vec.quick_push (pro);
}

  basic_block bb = vec.pop ();
  if (!can_dup_for_shrink_wrapping (bb, pro, max_grow_size))
while (!dominated_by_p (CDI_DOMINATORS, bb, pro))
  {
gcc_assert (pro != entry);

pro = get_immediate_dominator (CDI_DOMINATORS, pro);

if (bitmap_set_bit (bb_with, pro->index))
  vec.quick_push (pro);
  }

  FOR_EACH_EDGE (e, ei, bb->succs)
if (e->dest != EXIT_BLOCK_PTR_FOR_FN (cfun)
&& bitmap_set_bit (bb_with, e->dest->index))
  vec.quick_push (e->dest);
}
loop, initially we try as pro bb 7 for which can_get_prologue (pro,
prologue_clobbered) is true.
We iterate for a while, until bb_with is 3, 4, 5, 6, 7, 8, pro still 7,
and we pop bb 6, for which can_dup_for_shrink_wrapping is false.
vec at this point is empty.  As bb 6 isn't dominated by pro 7, we change
pro to the immediate dominator of bb 7 which is bb 5, and as it already is in
bb_with bitmap, we don't push anything.  bb 6 also has no successors (it traps
at the end), so we don't push there anything either.  And because vec.is_empty
() is true, the outer loop doesn't iterate any longer and so nothing checks if
can_get_prologue (pro, prologue_clobbered) (which is false for bb 5).

[Bug target/103861] New: [i386] vectorize v2qi vectors

[ubizjak at gmail dot com via Gcc-bugs]

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

Bug ID: 103861
   Summary: [i386] vectorize v2qi vectors
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following testcase:

typedef char __v2qi __attribute__ ((__vector_size__ (2)));

__v2qi plus  (__v2qi a, __v2qi b) { return a + b; };

should be vectorized.

[Bug fortran/89639] FAIL: gfortran.dg/ieee/ieee_9.f90 -O0 (test for excess errors)

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #11 from dave.anglin at bell dot net ---
On 2021-12-29 12:26 p.m., fxcoudert at gcc dot gnu.org wrote:
> David, could you kindly test the attached patch, to see if it fixes things?
Added patch to my build tree.

[Bug rtl-optimization/103860] [9/10/11/12 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

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

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

--- Comment #2 from Jakub Jelinek  ---
This seems to be clearly a shrink-wrapping bug.
Before pro_and_epilogue we have in RTL:
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 4 3 2 NOTE_INSN_FUNCTION_BEG)
(insn 3 2 34 2 (set (reg/v:QI 0 ax [orig:84 l ] [84])
(const_int -1 [0x])) "pr103860.c":14:10 83
{*movqi_internal}
 (expr_list:REG_EQUAL (const_int -1 [0x])
(nil)))

(code_label 34 3 6 3 7 (nil) [1 uses])
(note 6 34 7 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(note 7 6 10 3 NOTE_INSN_DELETED)
(insn 10 7 11 3 (set (reg:CCGOC 17 flags)
(compare:CCGOC (mem/c:SI (symbol_ref:DI ("d") [flags 0x2]  ) [1 d+0 S4 A32])
(const_int 0 [0]))) 7 {*cmpsi_ccno_1}
 (nil))
(jump_insn 11 10 13 3 (set (pc)
(if_then_else (ge (reg:CCGOC 17 flags)
(const_int 0 [0]))
(label_ref 16)
(pc))) 873 {*jcc}
 (int_list:REG_BR_PROB 118111604 (nil))
 -> 16)

(code_label 13 11 12 5 5 (nil) [1 uses])
(note 12 13 52 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(jump_insn 52 12 53 5 (set (pc)
(label_ref 13)) 874 {jump}
 (nil)
 -> 13)

(barrier 53 52 16)

(code_label 16 53 17 6 4 (nil) [1 uses])
(note 17 16 19 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(jump_insn 19 17 20 6 (set (pc)
(if_then_else (eq (reg:CCGOC 17 flags)
(const_int 0 [0]))
(label_ref 27)
(pc))) "pr103860.c":18:10 873 {*jcc}
 (int_list:REG_BR_PROB 536870916 (nil))

The problem is that shrink-wrapping decides to put the
(insn/f 55 77 56 12 (parallel [
(set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int -8 [0xfff8])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0  A8]))
]) "pr103860.c":12:1 -1
 (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int -8 [0xfff8])))
(nil)))
instruction on the edge in between bb3 and bb6, but that isn't correct, because
the flags register is live on that edge (set in insn 10, used in insns 11 and
19) and the prologue instruction clobbers it.

So we end up with:
main:
movld(%rip), %edx
movl$-1, %eax
testl   %edx, %edx
jns .L12
.L11:
jmp .L11
.L12:
subq$8, %rsp
.L4:
je  .L6
movqf@GOTPCREL(%rip), %rax
movl$0, (%rax)
movl$0, 0
ud2
.L6:
(.palign* and .cfi* directives and useless labels manually elided), which is
wrong, because je .L6 is done depending on whether %rsp was 8 before the
subtration (pretty much never), rather than depending on whether %edx is 0.

[Bug fortran/89639] FAIL: gfortran.dg/ieee/ieee_9.f90 -O0 (test for excess errors)

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

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

--- Comment #10 from Francois-Xavier Coudert  ---
Created attachment 52086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52086&action=edit
adjust testcase

David, could you kindly test the attached patch, to see if it fixes things?

[Bug rtl-optimization/103860] [9/10/11/12 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2021-12-29
Summary|wrong code at -O3 with  |[9/10/11/12 Regression]
   |-fPIC on x86_64-linux-gnu   |wrong code at -O3 with
   ||-fPIC on x86_64-linux-gnu
 CC||jakub at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
  Component|tree-optimization   |rtl-optimization
 Ever confirmed|0   |1
   Target Milestone|--- |9.5
Version|unknown |12.0
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jakub Jelinek  ---
Started with r6-5224-g82ad51444ff2a9faf3e019b07c98fbae0e753a0f

[Bug target/103676] [10/11/12 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671

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

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

--- Comment #20 from Jakub Jelinek  ---
BTW, I needed -mcpu=cortex-m7 -mthumb -O2 to reproduce the ICE.

[Bug target/103676] [10/11/12 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #19 from Jakub Jelinek  ---
r10-3981-gf6ff841bc8dd87ce364deb217dc6d1ec5dc31de8 still doesn't ICE,
r10-3984-g22060d0e575e7754eb1355763d22bbe37c3caa13 already ICEs.

I guess there is a disagreement between LRA and recog on how exactly they treat
register constraints.
"=lh" for TARGET_THUMB means LO_REGS or HI_REGS classes for the output, bet LRA
sees that LO_REGS or HI_REGS is together GENERAL_REGS and picks a GENERAL_REGS
(reg:DI 7 r7 [orig:119 tmp ] [119]).  But that one has one half in LO_REGS and
another half in HI_REGS and so extract_constrain_insn -> constrain_operands
doesn't consider it as matching.

[Bug c/103859] [11 Regression] ICE when function declaration parameter list contains sized arrays

[dtorrance at piedmont dot edu via Gcc-bugs]

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

--- Comment #2 from Doug Torrance  ---
Created attachment 52085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52085&action=edit
preprocessed source for bug 103859

[Bug c++/94276] [9/10/11/12 Regression] g++: error: gcc/testsuite/g++.dg/ext/stmtexpr3.C: -fcompare-debug failure since r9-3352-g87bd153645f393a1

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

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #3)
> @Jakub: Will you cook a patch?

No, I have tried multiple times and I don't really have a good solution for the
statement frontiers parsing differences.

[Bug c/103859] [11 Regression] ICE when function declaration parameter list contains sized arrays

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2021-12-29

--- Comment #1 from Martin Liška  ---
Please attach pre-processed source code (-E option).

[Bug objc/103639] [11/12 Regression] switch case with break in fast enumeration loop generates wrong code

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

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

--- Comment #12 from Jakub Jelinek  ---
Likely, but with something that will easily detect miscompilation at runtime
(checking dg-output is too ugly) and I don't have much experience with objc.dg/
dg- directives etc.

[Bug tree-optimization/103860] New: wrong code at -O3 with -fPIC on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 103860
   Summary: wrong code at -O3 with -fPIC on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a regression from GCC 5.4, and impact GCC 6.1 and later. 

[591] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211228 (experimental) (GCC) 
[592] % 
[592] % gcctk -O3 small.c; ./a.out
[593] % gcctk -O2 -fPIC small.c; ./a.out
[594] % 
[594] % gcctk -O3 -fPIC small.c
[595] % ./a.out
Segmentation fault
[596] % 
[596] % cat small.c
char a(char b, char c) { return b + c; }
static int d, *e;
int f;
int main() {
  char l = -1;
  for (; l; l = a(l, 1)) {
while (d < 0)
  ;
if (d > 0) {
  f = 0;
  *e = 0;
}
  }
  d = 0;
  return 0;
}

[Bug fortran/82968] gfortran.dg/ieee/ieee_6.f90 fails at -O0

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

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

--- Comment #4 from Francois-Xavier Coudert  ---
Specifying specific alignment in Fortran code is not directly possibly, sadly.
The only way I see how of this is to make that variable an integer, instead of
char array.

Eric, could you kindly test the patch attached, and let me know if it fixes
gfortran.dg/ieee/ieee_6.f90? Does it introduce any other failure?

I am wondering if this is breaking libgfortran ABI. I think not, but not 100%
sure.

[Bug fortran/82968] gfortran.dg/ieee/ieee_6.f90 fails at -O0

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

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

--- Comment #3 from Francois-Xavier Coudert  ---
Created attachment 52084
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52084&action=edit
Tentative patch

[Bug objc/103639] [11/12 Regression] switch case with break in fast enumeration loop generates wrong code

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

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

--- Comment #11 from Iain Sandoe  ---
(In reply to Jakub Jelinek from comment #10)
> Created attachment 52083 [details]
> gcc12-pr103639.patch
> 
> Untested fix.  I'll defer the testcase for the testsuite to somebody who
> speaks ObjC.

thanks. I'll try this on my next build cycle (the code in comment #8 should be
usable as a basis for a suitable test - but I'll check that too).

[Bug libffi/102923] [12 Regression] powerpc64 (BE) linux all languages bootstrap broken after libffi 3.4.2 import.

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

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

--- Comment #9 from Jakub Jelinek  ---
Isn't this fixed by r12-4693-g90205f67e465ae7dfcf733c2b2b177ca7ff68da0 ?

[Bug objc/103639] [11/12 Regression] switch case with break in fast enumeration loop generates wrong code

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Created attachment 52083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52083&action=edit
gcc12-pr103639.patch

Untested fix.  I'll defer the testcase for the testsuite to somebody who speaks
ObjC.

[Bug c/103859] New: [11 Regression] ICE when functional declaration parameter list contains sized arrays

[dtorrance at piedmont dot edu via Gcc-bugs]

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

Bug ID: 103859
   Summary: [11 Regression] ICE when functional declaration
parameter list contains sized arrays
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dtorrance at piedmont dot edu
  Target Milestone: ---

I'm getting the following internal compiler error when compiling
ts_interpolation.c from PHCpack [1] in Debian unstable using gcc 11.2.0 on a
number of architectures (armel, armhf, i386, mipsel, s390x, powerpc, and
ppc64).  This isn't a problem using gcc 10.3.1.

A simple workaround is to switch from p[n] to *p in the function declaration.

I've simplified the failing code down to a few lines:

$ gcc -c test.c
during RTL pass: expand
test.c: In function 'main':
test.c:16:3: internal compiler error: Segmentation fault
   16 |   horner(n + 1, f, x[i]);
  |   ^~
0x8ae09e6 internal_error(char const*, ...)
???:0
0x8b5d8c3 get_size_range(range_query*, tree_node*, gimple*, tree_node**, int)
???:0
0x8be739c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/cc2JQxrQ.out file, please attach this to
your bugreport.
=== BEGIN GCC DUMP ===
72708: // Target: i686-linux-gnu
72708: // Configured with: ../src/configure -v --with-pkgversion='Debian
11.2.0-13' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=i686-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-targets=all --enable-multiarch --disable-werror
--with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=i686-linux-gnu
--host=i686-linux-gnu --target=i686-linux-gnu
72708: // Thread model: posix
72708: // Supported LTO compression algorithms: zlib zstd
72708: // gcc version 11.2.0 (Debian 11.2.0-13) 
72708: // 
72708: // during RTL pass: expand
72708: // test.c: In function 'main':
72708: // test.c:16:3: internal compiler error: Segmentation fault
72708: //16 |   horner(n + 1, f, x[i]);
72708: //   |   ^~
72708: // 0x8ae09e6 internal_error(char const*, ...)
72708: //   ???:0
72708: // 0x8b5d8c3 get_size_range(range_query*, tree_node*, gimple*,
tree_node**, int)
72708: //   ???:0
72708: // 0x8be739c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
72708: //   ???:0
72708: // Please submit a full bug report,
72708: // with preprocessed source if appropriate.
72708: // Please include the complete backtrace with any bug report.
72708: // See  for instructions.
72708: 
72708: // /usr/lib/gcc/i686-linux-gnu/11/cc1 -quiet -imultiarch i386-linux-gnu
test.c -quiet -dumpbase test.c -dumpbase-ext .c -mtune=generic -march=i686
-fasynchronous-unwind-tables -o - -frandom-seed=0 -fdump-noaddr
72708: 
72708: # 0 "test.c"
72708: # 0 ""
72708: # 0 ""
72708: # 1 "/usr/include/stdc-predef.h" 1 3 4
72708: # 0 "" 2
72708: # 1 "test.c"
72708: typedef struct dcmplx dcmplx;
72708: 
72708: struct dcmplx {
72708:   double re;
72708:   double im;
72708: };
72708: 
72708: dcmplx horner(int n, dcmplx p[n], dcmplx x);
72708: 
72708: int main(void)
72708: {
72708: 
72708:   int i, n;
72708:   dcmplx x[n + 1], f[n + 1];
72708: 
72708:   horner(n + 1, f, x[i]);
72708: 
72708:   return 0;
72708: }
=== END GCC DUMP ===

[1]
https://github.com/janverschelde/PHCpack/blob/master/src/Feedback/ts_interpolation.c

[Bug objc/103639] [11/12 Regression] switch case with break in fast enumeration loop generates wrong code

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||sandra at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Most likely caused by r11-3302-g3696a50beeb73f4ded8a584e76ee16f0bde109b9

[Bug fortran/91690] Slow IEEE intrinsics

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #8 from Francois-Xavier Coudert  ---
I think things are a little more complicated that they appear. The function
IEEE_IS_NAN, in itself, is not the problem: it is not slow, and does not
store/restore the floating-point state. If you take the demo program, and
replace the call to the contained function IS_NAN_IEEE directly by the
IEEE_IS_NAN function, you will actually see that it is faster (50% faster) than
the bit-checking function.

The problem is in the contained function IS_NAN_IEEE. By my reading of the
Fortran standard, that function is required to save its floating-point state on
entry, and restore it on exit. This is regardless of what happens inside the
function, and this is what is slowing things done.

Of course, we can still consider this a "missed optimisation": the compiler
could in theory determine that absolutely no floating-point operation is being
done, and optimise away the save/restore calls. But it is a tricky thing to do,
and would have no value for "real" functions, that actually perform
floating-point operations.

[Bug preprocessor/89971] [9/10/11/12 Regression] ICE: unspellable token PADDING

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 52082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52082&action=edit
gcc12-pr89971.patch

Untested fix.

[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #13 from Francois-Xavier Coudert  ---
Let's have a try at fixing this.

[Bug fortran/57042] Strange typespec with -fdump-parse-tree

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |diagnostic
 CC||fxcoudert at gcc dot gnu.org
Version|4.9.0   |12.0

--- Comment #14 from Francois-Xavier Coudert  ---
The bug in the parse tree dump is still present, as ADJUSTL and TRIM have
unknown type:


$ cat s.f90 
program main
  implicit none
  print *, adjustl("   a   ")
  print *, trim("   a   ")
end

$ gfortran -fdump-fortran-original s.f90 

Namespace: A-Z: (UNKNOWN 0)
procedure name = main
  symtree: 'adjustl' || symbol: 'adjustl'  
type spec : (UNKNOWN 0)
attributes: (PROCEDURE INTRINSIC-PROC  FUNCTION ARRAY-OUTER-DEPENDENCY)
result: adjustl
  symtree: 'main'|| symbol: 'main' 
type spec : (UNKNOWN 0)
attributes: (PROGRAM PUBLIC  SUBROUTINE IS-MAIN-PROGRAM)
  symtree: 'trim'|| symbol: 'trim' 
type spec : (UNKNOWN 0)
attributes: (PROCEDURE INTRINSIC-PROC  FUNCTION ARRAY-OUTER-DEPENDENCY)
result: trim

  code:
  WRITE UNIT=6 FMT=-1
  TRANSFER 'a  '
  DT_END
  WRITE UNIT=6 FMT=-1
  TRANSFER '   a'
  DT_END

--

[Bug tree-optimization/103857] implement ternary without jump (and comparison)

[drepper.fsp+rhbz at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Ulrich Drepper  ---
(In reply to Jakub Jelinek from comment #1)
> I don't think that's equivalent.

You're right, I tried to generalize the code and failed.  I my actual case this
was a single variable the compiler saw the assignments of.  Adding

  if (a[i] != 42 && a[i] != 10)
__builtin_unreachable();

etc could simulate this.

[Bug tree-optimization/102725] -fno-builtin leads to call of strlen since r12-4283-g6f966f06146be768

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||dani at danielbertalan dot dev

--- Comment #5 from Martin Liška  ---
*** Bug 103858 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/103858] [12 Regression] strlen() implementation is optimized into a call to strlen() at -O2, causing infinite recursion

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Martin Liška  ---
Dup.

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

[Bug tree-optimization/103857] implement ternary without jump (and comparison)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I don't think that's equivalent.  For a[i] equal to b it will be and similarly
it will be for a[i] equal to c, but not for all the other values.
E.g. 13 == 42 ? 24 : 42 is 42, but 13 ^ (24 ^ 42) is 63.
So, we could do this only if something assures us that a[i] only has 2 possible
values, either equal to b or to c.  So that would rule out non-constant b or c,
perhaps it could be done if value range is two adjacent constants equal to b
and c, or perhaps if the non-zero bits has a single bit and one of b or c is 0
and the other one is that non-zero bitmask of the other comparison operand.

[Bug tree-optimization/103858] New: [12 Regression] strlen() implementation is optimized into a call to strlen() at -O2, causing infinite recursion

[dani at danielbertalan dot dev via Gcc-bugs]

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

Bug ID: 103858
   Summary: [12 Regression] strlen() implementation is optimized
into a call to strlen() at -O2, causing infinite
recursion
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dani at danielbertalan dot dev
  Target Milestone: ---

Compiler Explorer link: https://godbolt.org/z/h419G55P4

The following function is folded into a call to strlen() by gcc 12 (commit
61e53698a08dc1d9a54d785218af687a6751c1b3) at -O2, unless -fno-builtin-strlen is
specified. This function is taken from a (naive) libc implementation, where
this is the only definition of strlen(), so it ends up calling itself
recursively, overflowing the stack.

#include 

size_t strlen(const char* str)
{
size_t len = 0;
while (*(str++))
++len;
return len;
}

x86_64 assembly output:
strlen:
cmp BYTE PTR [rdi], 0
je  .L3
lea rax, [rdi+1]
sub rsp, 8
mov rdi, rax
callstrlen
add rsp, 8
add rax, 1
ret
.L3:
xor eax, eax
ret

My workaround is to compile our libc with -ffreestanding/-fno-builtin, but I'd
like to avoid that, as it might prevent other (valid) optimizations from being
performed on our code.

[Bug tree-optimization/103857] New: implement ternary without jump (and comparison)

[drepper.fsp+rhbz at gmail dot com via Gcc-bugs]

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

Bug ID: 103857
   Summary: implement ternary without jump (and comparison)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drepper.fsp+rhbz at gmail dot com
  Target Milestone: ---

This test case is derived from actual code and I expect it to be not uncommon
in general.  Maybe not exactly in this form but perhaps the matcher can catch a
few more cases.

Take this code:

extern void g(int);
void f1(int* a, int b, int c)
{
  for (unsigned i = 0; i < 100; ++i)
g(a[i] == b ? c : b);
}
void f2(int* a)
{
  for (unsigned i = 0; i < 100; ++i)
g(a[i] == 42 ? 10 : 42);
}


The function 'g' is called in each loop with one of two values which is the
opposite from the one that is match in the condition of the ternary operation. 
This allows the respective loops to be rewritten as

  for (unsigned i = 0; i < 100; ++i)
g(a[i] ^ c ^ b);

and

  for (unsigned i = 0; i < 100; ++i)
g(a[i] ^ 10 ^ 42);

In the former case the c ^ b operation can be hoisted.

This should be faster and smaller in pretty much all situations and on all
platforms.

[Bug middle-end/103770] [11 Regression] ICE related to VLA

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #3 from Martin Uecker  ---
Here is another example which fails on armel


extern _Complex float g(int N, int dims[N]);

void f(void)
{
int dims[1];
_Complex float val = g(1, dims);
}

during RTL pass: expand
BUG.c: In function 'f':
BUG.c:10:30: internal compiler error: Segmentation fault
   10 | _Complex float val = g(1, dims);
  |  ^~

0xb1393f crash_signal
../../src/gcc/toplev.c:327
0x708398 get_size_range(range_query*, tree_node*, gimple*, tree_node**, int)
../../src/gcc/calls.c:1274
0x70c4d4 get_size_range(range_query*, tree_node*, gimple*, tree_node**, int)
../../src/gcc/calls.c:1266
0x70c4d4 get_size_range(tree_node*, tree_node**, int)
../../src/gcc/calls.c:1401
0x70c4d4 maybe_warn_rdwr_sizes
../../src/gcc/calls.c:2034
0x70dcb1 initialize_argument_information
../../src/gcc/calls.c:2626
0x70dcb1 expand_call(tree_node*, rtx_def*, int)
../../src/gcc/calls.c:4010
0x8210ce expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../src/gcc/expr.c:11287
0x82a9ce expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../src/gcc/expr.c:8519
0x82a9ce store_expr(tree_node*, rtx_def*, int, bool, bool)
../../src/gcc/expr.c:5886
0x82be69 expand_assignment(tree_node*, tree_node*, bool)
../../src/gcc/expr.c:5622
0x720bf9 expand_call_stmt
../../src/gcc/cfgexpand.c:2838
0x720bf9 expand_gimple_stmt_1
../../src/gcc/cfgexpand.c:3871
0x720bf9 expand_gimple_stmt
../../src/gcc/cfgexpand.c:4035
0x726b97 expand_gimple_basic_block
../../src/gcc/cfgexpand.c:6077
0x726b97 execute
../../src/gcc/cfgexpand.c:6761
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


arm-linux-gnueabi-gcc (Debian 11.2.0-9) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug tree-optimization/103856] New: ICE during GIMPLE pass: hardcmp since r12-4759-g95bb87b2458bfab4

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

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

Bug ID: 103856
   Summary: ICE during GIMPLE pass: hardcmp since
r12-4759-g95bb87b2458bfab4
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ cat ice.ii
struct S {
  S(float);
  S();
  operator float();
  ~S() {}
};

int
main() {
  S s_arr[]{2};
  S var1;
  if (var1)
;
}

$ g++ -Og -fnon-call-exceptions -fsignaling-nans -fharden-compares -c ice.ii
ice.ii: In function ‘int main()’:
ice.ii:9:1: error: missing ‘PHI’ def
9 | main() {
  | ^~~~
_5 = PHI <&MEM  [(void *)&s_arr + 1B](4), &MEM 
[(void *)&s_arr + 1B](2), &MEM  [(void *)&s_arr + 1B](3), (5)>
during GIMPLE pass: hardcmp
ice.ii:9:1: internal compiler error: verify_gimple failed
0x1289035 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5578
0x114f4ee execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:2084
0x114fb0b execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2138
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/103854] ICE in generate_finalization_wrapper, at fortran/class.c:1618 since r8-4344-gaea5e9327a49bc73

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
Summary|ICE in  |ICE in
   |generate_finalization_wrapp |generate_finalization_wrapp
   |er, at fortran/class.c:1618 |er, at fortran/class.c:1618
   ||since
   ||r8-4344-gaea5e9327a49bc73
   Last reconfirmed||2021-12-29
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r8-4344-gaea5e9327a49bc73.

[Bug driver/93645] Support Clang 12 --ld-path=

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

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

--- Comment #16 from Martin Liška  ---
Note -fuse-ld=mold was added in: g:ad964f7eaef9c03ce68a01cfdd7fde9d56524868

[Bug libstdc++/103853] std::forward_list::merge should check if __list != this

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

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

--- Comment #2 from Jonathan Wakely  ---
The new test should also check the overload taking a comparison function.

And if we do want to add the check for the rvalue overloads (which isn't
required, but might be more user friendly, with a small overhead) those should
be checked in the test as well.

[Bug libstdc++/103853] std::forward_list::merge should check if __list != this

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-12-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Pavel I. Kryukov from comment #0)
> C++ standard does not require 'do nothing' if std::forward_list::merge
> argument equals to 'this', however it does not say 'undefined behavior' or
> 'infinite loop' too.

It does say undefined behaviour for the overload your patch changes.

[res.on.arguments] says:

> If a function argument is bound to an rvalue reference parameter, the
> implementation may assume that this parameter is a unique reference to this
> argument, except that the argument passed to a move-assignment operator may
> be a reference to *this ([lib.types.movedfrom]).

Passing *this as the first parameter of merge(forward_list&&) or
merge(forward_list&&, Comp) breaks this assumption, resulting in undefined
behaviour.

The check is only needed for the overloads taking forward_list& parameters:

--- a/libstdc++-v3/include/bits/forward_list.h
+++ b/libstdc++-v3/include/bits/forward_list.h
@@ -1267,7 +1267,12 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER

   void
   merge(forward_list& __list)
-  { merge(std::move(__list)); }
+  {
+   if (std::__addressof(__list) == this)
+ return;
+
+   merge(std::move(__list));
+  }

   /**
*  @brief  Merge sorted lists according to comparison function.
@@ -1287,7 +1292,12 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   template
void
merge(forward_list& __list, _Comp __comp)
-   { merge(std::move(__list), __comp); }
+   {
+ if (std::__addressof(__list) == this)
+   return;
+
+ merge(std::move(__list), __comp);
+   }

   /**
*  @brief  Sort the elements of the list.


> I've attached my patch to fix and test it, but since I'm not an experienced
> GCC contributor, I don't know how to run the tests. Following instructions
> on CONTRIBUTING page builds whole GCC ending with some problems with my
> machine. I would be grateful if you tell how I can test only libstdc++.

You need to build the whole of GCC to test libstdc++, so if you can't get that
working, you should fix that first.

Testing libstdc++ is documented at
https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html#test.run

[Bug tree-optimization/103855] Missed optimization: 64bit division used instead of 32bit division

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
vect_get_range_info is meant for the vectorizer only, what you want is I think
get_min_precision which would need to be exported out of internal-fn.c.
In any case, it needs to be called still on the trees (SSA_NAMEs or
INTEGER_CSTs etc.) during expansion.
expand_expr_divmod already performs a different optimization - if both operands
are known to have the most significant bit clear (checked with
get_range_pos_neg), then it expands it as both signed and unsigned division or
modulo and checks if one of them isn't cheaper.

[Bug tree-optimization/103855] Missed optimization: 64bit division used instead of 32bit division

[zhaoweiliew at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Zhao Wei Liew  ---
I see that the vect_get_range_info(tree, wide_int*, wide_int*) function returns
the range of a tree type, but in expand_divmod(), the operands are of rtx type.
Is there still a way to extract the range information from an rtx type?

[Bug tree-optimization/103855] Missed optimization: 64bit division used instead of 32bit division

[zhaoweiliew at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Zhao Wei Liew  ---
Thanks for your guidance. I'm looking into adding a fix in expmed.c, but I
can't figure out how to get the range of op1 and op0 from within
expand_divmod().