[Bug fortran/103368] [11/12 Regression] ICE in gimplify_expr, at gimplify.c:15668 since r12-4464-g017665f63047ce47

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-23
 Status|UNCONFIRMED |NEW
Summary|[11/12 Regression] ICE in   |[11/12 Regression] ICE in
   |gimplify_expr, at   |gimplify_expr, at
   |gimplify.c:15668|gimplify.c:15668 since
   ||r12-4464-g017665f63047ce47
 Ever confirmed|0   |1
 CC||burnus at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r12-4464-g017665f63047ce47.

[Bug fortran/103367] [11/12 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377 since r12-4278-g74ccca380cde5e79

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|[11/12 Regression] ICE in   |[11/12 Regression] ICE in
   |gfc_conv_array_initializer, |gfc_conv_array_initializer,
   |at  |at
   |fortran/trans-array.c:6377  |fortran/trans-array.c:6377
   ||since
   ||r12-4278-g74ccca380cde5e79
 CC||anlauf at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2021-11-23

--- Comment #1 from Martin Liška  ---
Started with r12-4278-g74ccca380cde5e79.

[Bug fortran/103366] [12 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.c:5647

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-23
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r9-5372-gbbf18dc5d248a79a.

[Bug middle-end/103365] ICE in register_scoped_attribute, with attribute starting with underscore: -Wno-attributes=n::_a or #pragma GCC diagnostic ignored_attributes "n::_a"

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r12-5123-ga1ad0d84d7fcbcaa.

[Bug middle-end/103374] sorry, unimplemented: __builtin_clear_padding not supported for variable length aggregates

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

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|ada |middle-end
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org
Summary|gcc/ada/exp_ch4.adb:7165:10 |sorry, unimplemented:
   |: sorry, unimplemented: |__builtin_clear_padding not
   |__builtin_clear_padding not |supported for variable
   |supported for variable  |length aggregates
   |length aggregates   |
   Last reconfirmed||2021-11-23

--- Comment #1 from Eric Botcazou  ---
Recategorizing.

[Bug tree-optimization/103168] Value numbering for PRE of pure functions can be improved

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

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

--- Comment #17 from Jan Hubicka  ---
Created attachment 51853
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51853=edit
Updated patch

Patch attached.  Indeed the oracle ICEs on ref=base=NULL. I also checked that
during cc1plus build we eliminate 187 calls.

[Bug target/103271] ICE in assign_stack_temp_for_type with -ftrivial-auto-var-init=pattern and VLAs and -mno-strict-align on riscv64

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #3 from rguenther at suse dot de  ---
On Mon, 22 Nov 2021, qinzhao at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
> 
> qinzhao at gcc dot gnu.org changed:
> 
>What|Removed |Added
> 
>  CC||qinzhao at gcc dot gnu.org
> 
> --- Comment #1 from qinzhao at gcc dot gnu.org ---
> was not able to repeat this failure yet due to:
> 
> 1. cannot find a riscv machine either in my company or in gcc farm.
> 2. tried to build a cross-compiler on riscv64 from a x86 platform, but always
> failed.
> 
> is there a good documentation to build cross-compiler?

You should be able to simply do

 ../configure --target=riscv64-linux
 make all-gcc

and use the built gcc/cc1 to debug such ICEs.

[Bug tree-optimization/103168] Value numbering for PRE of pure functions can be improved

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

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

--- Comment #16 from Richard Biener  ---
(In reply to Jan Hubicka from comment #13)
> Concerning comment #10, the problem was that the loop walking all accesses
> was missing loads->every_base check.  This is used to represent that we
> track no useful info about loads performed at all.
> 
> Anyway if I read the code correctly, it does nothing useful if the access
> tree contains any access for which we can not construct ref and thus one can
> simply check global_memory_access and do not care about
> every_base/every_ref/every_access since these must be all false.
> 
> I simplified the walk a bit and added code pre-computing number of accesses
> in the tree into the summary.
> 
> What we can also do is, when hitting access for which we can not construct
> ref, or when hitting every_ref/every_acccess, is to construct ref with
> base_alias_set/ref_alias_set as given by the access tree but with base=NULL,
> offset=0 and size=max_size=-1. This should still let the basic TBAA oracle
> to disambiguate.

I don't think we support base = NULL in the oracle (ref = NULL is supported
though).  Can you attach your patch instead of cut so I can take it
from there?  Thanks.

[Bug ada/103374] New: gcc/ada/exp_ch4.adb:7165:10: sorry, unimplemented: __builtin_clear_padding not supported for variable length aggregates

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

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

Bug ID: 103374
   Summary: gcc/ada/exp_ch4.adb:7165:10: sorry, unimplemented:
__builtin_clear_padding not supported for variable
length aggregates
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: qing.zhao at oracle dot com
  Target Milestone: ---

I tried bootstrapping GCC with -ftrivial-auto-var-init=pattern but it fails
here:

[  978s]
/home/abuild/rpmbuild/BUILD/gcc-12.0.0+git189862/obj-i586-suse-linux/./prev-gcc/xgcc
-B/home/abuild/rpmbuild/BUILD/gcc-12.0.0+git189862/obj-i586-suse-linux/./prev-gcc/
-B/usr/i586-suse-linux/bin/ -B/usr/i586-suse-linux/bin/
-B/usr/i586-suse-linux/lib/ -isystem /usr/i586-suse-linux/include -isystem
/usr/i586-suse-linux/sys-include   -fno-checking -c -fomit-frame-pointer -O3
-D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -Werror=return-type -Wno-error
-ftrivial-auto-var-init=pattern -g -U_FORTIFY_SOURCE -fno-checking -gtoggle
-fprofile-generate  -gnatpg  -W -Wall -nostdinc -I- -I. -Iada/generated -Iada
-I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat -Iada/gcc-interface
-I../../gcc/ada/gcc-interface ../../gcc/ada/exp_ch4.adb -o ada/exp_ch4.o
[  979s] ../../gcc/ada/exp_ch4.adb: In function
'Exp_Ch4.Expand_N_Indexed_Component':
[  979s] ../../gcc/ada/exp_ch4.adb:7165:10: sorry, unimplemented:
__builtin_clear_padding not supported for variable length aggregates
[  979s] make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:167:
ada/exp_ch4.o] Error 1

[Bug tree-optimization/103088] [12 regression] 500.perlbench from spec 2017 fails since r12-4698

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

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

--- Comment #23 from Tamar Christina  ---
Thanks Aldy!

[Bug target/103370] [12 Regression] Assembler error building glibc for ColdFire soft-float

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug fortran/103368] [11/12 Regression] ICE in gimplify_expr, at gimplify.c:15668

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Priority|P3  |P4
   Keywords||ice-on-invalid-code

[Bug target/103271] ICE in assign_stack_temp_for_type with -ftrivial-auto-var-init=pattern and VLAs and -mno-strict-align on riscv64

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

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

--- Comment #2 from Martin Liška  ---
(In reply to qinzhao from comment #1)
> was not able to repeat this failure yet due to:
> 
> 1. cannot find a riscv machine either in my company or in gcc farm.
> 2. tried to build a cross-compiler on riscv64 from a x86 platform, but
> always failed.

It's as simple as:

$ ../configure --enable-languages=c,c++ --disable-multilib
--disable-libsanitizer --disable-bootstrap --target=riscv64-linux-gnu
$ make all-host

> 
> is there a good documentation to build cross-compiler?

https://gcc.gnu.org/install/build.html#Building-a-cross-compiler

[Bug fortran/103367] [11/12 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |11.3

[Bug fortran/103366] [12 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.c:5647

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Priority|P3  |P4

[Bug tree-optimization/103361] [12 Regression] ICE in adjust_unroll_factor, at gimple-loop-jam.c:407 since r12-3677-gf92901a508305f29

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/103359] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/103168] Value numbering for PRE of pure functions can be improved

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #15 from hubicka at kam dot mff.cuni.cz ---
The patch passed testing on x86_64-linux.

Re: [Bug tree-optimization/103168] Value numbering for PRE of pure functions can be improved

[Jan Hubicka via Gcc-bugs]

The patch passed testing on x86_64-linux.

[Bug middle-end/103364] s390x: TLS reference in /usr/lib64/libLLVM.so mismatches non-TLS reference in /usr/lib64/libLLVM.so

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=12323

--- Comment #5 from Andrew Pinski  ---
Looks like bfd ld is still broken:
https://sourceware.org/bugzilla/show_bug.cgi?id=12323

[Bug middle-end/103364] s390x: TLS reference in /usr/lib64/libLLVM.so mismatches non-TLS reference in /usr/lib64/libLLVM.so

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

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

--- Comment #4 from Andrew Pinski  ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375#c11

[Bug middle-end/103364] s390x: TLS reference in /usr/lib64/libLLVM.so mismatches non-TLS reference in /usr/lib64/libLLVM.so

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

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

--- Comment #3 from Andrew Pinski  ---
I really doubt this would be a gcc issue.

Binutils has check is:
  if (oldbfd != NULL
  && (oldbfd->flags & BFD_PLUGIN) == 0
  && (abfd->flags & BFD_PLUGIN) == 0
  && ELF_ST_TYPE (sym->st_info) != h->type
  && (ELF_ST_TYPE (sym->st_info) == STT_TLS || h->type == STT_TLS))

[Bug middle-end/103364] s390x: TLS reference in /usr/lib64/libLLVM.so mismatches non-TLS reference in /usr/lib64/libLLVM.so

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-23

--- Comment #2 from Andrew Pinski  ---
I wonder if this was caused by the known bug in GCC 11.1.0 where some
thread_local (and __thread) variables lose they are TLS variables with the C++
front-end.

Can you supply what version of GCC you are using?
And try to see if openSUSE has a new one and if they have a new version of LLVM
that is compiled with the new version of GCC?

[Bug c/103373] New: ICE in add_constraint, at cp/constraint.cc:1077

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 103373
   Summary: ICE in add_constraint, at cp/constraint.cc:1077
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-12.0.0-alpha20211121 snapshot (g:da17c304e22ba256eba0b03710aa329115163b08)
ICEs when compiling the following testcase, reduced from
test/CXX/temp/temp.constr/temp.constr.normal/p1.cpp from the clang 13.0.0 test
suite, w/ -std=c++20:

template concept True = true;
template concept True2 = sizeof(T) >= 0;
template concept Foo2 = True2;
template concept Bar2 = Foo2;

namespace type_pack {
  template
  concept C1 = ((sizeof(Args) >= 0) && ...);

  template
  concept C2 = C1;

  template
  constexpr void foo() requires C2 { }

  template
  constexpr void foo() requires C1 && true { }

  static_assert((foo(), true));
}

namespace PR47174 {
template 
requires true struct S3;

template 
requires true struct S3;
}

% g++-12.0.0 -std=c++20 -c cmqenks0.cpp
cmqenks0.cpp:27:22: error: forming pointer to reference type 'T&'
   27 | requires true struct S3;
  |  ^~~~
cmqenks0.cpp:27:22: internal compiler error: in add_constraint, at
cp/constraint.cc:1077
0x67e3d6 add_constraint
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/constraint.cc:1077
0x988ab2 add_constraint
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/constraint.cc:1070
0x988ab2 add_constraint
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/constraint.cc:1070
0x988b67 iterative_hash_constraint(tree_node*, unsigned int)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/constraint.cc:1090
0xa2e2a1 subsumption_hasher::hash(subsumption_entry*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/logic.cc:737
0xa2e2a1 hash_table::find(subsumption_entry* const&)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/hash-table.h:430
0xa2e2a1 lookup_subsumption
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/logic.cc:763
0xa2e2a1 subsumes_constraints_nonnull
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/logic.cc:795
0xa2e2a1 subsumes(tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/logic.cc:842
0x98cc7d strictly_subsumes(tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/constraint.cc:3488
0xb3e4db process_partial_specialization
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/pt.c:5131
0xb41265 push_template_decl(tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/pt.c:5711
0xb41265 maybe_process_partial_specialization(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/pt.c:1042
0x9e0ae0 shadow_tag(cp_decl_specifier_seq*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/decl.c:5409
0xae7883 cp_parser_single_declaration
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/parser.c:31538
0xae7ba5 cp_parser_template_declaration_after_parameters
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/parser.c:31162
0xae8450 cp_parser_explicit_template_declaration
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/parser.c:31428
0xaeaf21 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/parser.c:14786
0xaea4f9 cp_parser_toplevel_declaration
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/parser.c:14876
0xaea4f9 cp_parser_declaration_seq_opt
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cp/parser.c:14629

[Bug c/103372] New: Warning on failure order defaulting to SEQ_CST if not a compile time constant

[doodspav at gmail dot com via Gcc-bugs]

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

Bug ID: 103372
   Summary: Warning on failure order defaulting to SEQ_CST if not
a compile time constant
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doodspav at gmail dot com
  Target Milestone: ---

The following code:

#include 

_Bool test(memory_order failure)
{
  volatile _Atomic(int) object = 5;
  int expected = 5;
  int desired = 10;
  memory_order success = memory_order_relaxed;

  return atomic_compare_exchange_strong_explicit(
,
,
desired,
success,
failure
  );
}

generates this error:

:10:10: error: failure memory model cannot be stronger than success
memory model for '__atomic_compare_exchange' [-Werror=invalid-memory-model]
   10 |   return atomic_compare_exchange_strong_explicit(
  |  ^~~

when compiled on Godbolt with GCC4.9.0+ and '-std=c11 -O3 -Werror
-Winvalid-memory-model'.

GCC implements atomics using the builtins, which convert any memory order
parameter to `SEQ_CST` if it's not a compile time constant. This is fine,
except in the case of __atomic_compare_exchange(_n) where there are 2 memory
orders.

An acceptable fix would be that GCC should not warn about the failure memory
order being weaker than the success memory order if the failure order is not
known at compile time.
Since GCC sets failure order to SEQ_CST in this case, it will need to also set
success order to SEQ_CST.
This is permitted and, under the current system, is the only success order
which won't cause the above issue (any other success order would currently
warn/error).

[Bug testsuite/103270] [12 regression] gcc.dg/vect/pr96698.c inner loop turned from hot to cold after r12-4526

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

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

--- Comment #5 from luoxhu at gcc dot gnu.org ---
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4 5 6 11 7 8 10 9
;;
;; Loop 1
;;  header 8, latch 7
;;  depth 1, outer 0
;;  nodes: 8 7 6 10 5 4 11 3
;;
;; Loop 2
;;  header 6, latch 5
;;  depth 2, outer 1
;;  nodes: 6 5 4 11 3
;;
;; Loop 3
;;  header 4, latch 3
;;  depth 3, outer 2
;;  nodes: 4 3
;; 2 succs { 8 }
;; 3 succs { 4 }
;; 4 succs { 3 5 }
;; 5 succs { 6 }
;; 6 succs { 11 7 }
;; 11 succs { 4 }
;; 7 succs { 8 }
;; 8 succs { 10 9 }
;; 10 succs { 6 }
;; 9 succs { 1 }

The CFG is:

2
|
8<
| \  |
10 9 |
||
67
6<
|| 
11   | 
||
4<-  | 
| \| |
5  3 |
||
--

When iterating loop 3 in predict_extra_loop_exits, exit edge is 4->5, it finds
edge 3->4 for statement "if (d_8 == 0)", and set all e->src->preds with
"predict_paths_leading_to_edge (e1, PRED_LOOP_EXTRA_EXIT, NOT_TAKEN);".

(gdb) pbb 3
;; basic block 3, loop depth 3
;;  pred:   4
_1 = *i_19(D);
_2 = a_4 & c_6;
_3 = _1 + _2;
*i_19(D) = _3;
;;  succ:   4

(gdb) pbb 4
;; basic block 4, loop depth 3
;;  pred:   11
;;  3
# c_6 = PHI 
# d_8 = PHI <0(11), 1(3)>
if (d_8 == 0)
  goto ; [INV]
else
  goto ; [INV]
;;  succ:   3
;;  5 
(gdb) p e->src->preds
$16 = 0x74fba140 = { 3)>}

[Bug tree-optimization/102216] [12 Regression] missed optimization causing Warray-bounds

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
   |il/gcc-patches/2021-October |il/gcc-patches/2021-Novembe
   |/582684.html|r/585194.html

--- Comment #12 from Andrew Pinski  ---
New patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585194.html

[Bug fortran/103371] New: f951: internal compiler error: Aborted (free(): double free detected in tcache 2) when giving diagnostics on type of a parameter expression

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 103371
   Summary: f951: internal compiler error: Aborted (free(): double
free detected in tcache 2) when giving diagnostics on
type of a parameter expression
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: error-recovery
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

Created attachment 51852
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51852=edit
Testcase

gfortran-12.0.0-alpha20211121 snapshot
(g:da17c304e22ba256eba0b03710aa329115163b08) ICEs when compiling
test/Semantics/resolve92.f90 from the flang 13.0.0 test suite:

% gfortran-12.0.0 -c flang/test/Semantics/resolve92.f90
flang/test/Semantics/resolve92.f90:21:14:

   21 | integer(t) :: n
  |  1
Error: Function 't' requires an argument list at (1)
free(): double free detected in tcache 2
f951: internal compiler error: Aborted
0xf2fc4f crash_signal
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/toplev.c:322
0x889ed8 gfc_free_actual_arglist(gfc_actual_arglist*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/fortran/expr.c:547
0x878bc9 gfc_match_data_decl()
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/fortran/decl.c:6340
0x8ebb04 match_word
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/fortran/parse.c:67
0x8ebb04 decode_statement
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/fortran/parse.c:378
0x8f28c4 next_free
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/fortran/parse.c:1397
0x8f28c4 next_statement
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/fortran/parse.c:1629
0x8f4fe4 parse_derived
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/fortran/parse.c:3588
0x8f4fe4 parse_spec
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/fortran/parse.c:4129
0x8f9428 parse_module
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/fortran/parse.c:6443
0x8f999f gfc_parse_file()
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/fortran/parse.c:6760
0x94c16f gfc_be_parse_file
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/fortran/f95-lang.c:216

==1403603== Invalid read of size 8
==1403603==at 0x889EB3: gfc_free_actual_arglist(gfc_actual_arglist*)
(expr.c:545)
==1403603==by 0x878BC9: gfc_match_data_decl() (decl.c:6340)
==1403603==by 0x8EBB04: match_word (parse.c:67)
==1403603==by 0x8EBB04: decode_statement() (parse.c:378)
==1403603==by 0x8F28C4: next_free (parse.c:1397)
==1403603==by 0x8F28C4: next_statement() (parse.c:1629)
==1403603==by 0x8F4FE4: parse_derived (parse.c:3588)
==1403603==by 0x8F4FE4: parse_spec(gfc_statement) (parse.c:4129)
==1403603==by 0x8F9428: parse_module() (parse.c:6443)
==1403603==by 0x8F999F: gfc_parse_file() (parse.c:6760)
==1403603==by 0x94C16F: gfc_be_parse_file() (f95-lang.c:216)
==1403603==by 0xF2FD40: compile_file() (toplev.c:452)
==1403603==by 0x849580: do_compile (toplev.c:2156)
==1403603==by 0x849580: toplev::main(int, char**) (toplev.c:2308)
==1403603==by 0x84B19B: main (main.c:39)
==1403603==  Address 0x50bdf38 is 24 bytes inside a block of size 48 free'd
==1403603==at 0x4840CDB: free (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1403603==by 0x889ED8: gfc_free_actual_arglist(gfc_actual_arglist*)
(expr.c:547)
==1403603==by 0x870EFB: gfc_get_pdt_instance(gfc_actual_arglist*,
gfc_symbol**, gfc_actual_arglist**) (decl.c:4165)
==1403603==by 0x90C454: resolve_structure_cons(gfc_expr*, int)
(resolve.c:1279)
==1403603==by 0x90F23A: resolve_generic_f (resolve.c:2806)
==1403603==by 0x90F23A: resolve_function (resolve.c:3321)
==1403603==by 0x90F23A: gfc_resolve_expr(gfc_expr*) [clone .part.0]
(resolve.c:7166)
==1403603==by 0x88D595: gfc_reduce_init_expr(gfc_expr*) (expr.c:3130)
==1403603==by 0x891002: gfc_match_init_expr(gfc_expr**) (expr.c:3178)
==1403603==by 0x879A9E: variable_decl (decl.c:3004)
==1403603==by 0x879A9E: gfc_match_data_decl() (decl.c:6297)
==1403603==by 0x8EBB04: match_word (parse.c:67)
==1403603==by 0x8EBB04: decode_statement() (parse.c:378)
==1403603==by 0x8F28C4: next_free (parse.c:1397)
==1403603==by 0x8F28C4: next_statement() (parse.c:1629)
==1403603==by 0x8F4FE4: parse_derived (parse.c:3588)
==1403603==by 0x8F4FE4: parse_spec(gfc_statement) (parse.c:4129)
==1403603==by 0x8F9428: 

[Bug testsuite/103270] [12 regression] gcc.dg/vect/pr96698.c inner loop turned from hot to cold after r12-4526

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

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

--- Comment #4 from luoxhu at gcc dot gnu.org ---
Created attachment 51851
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51851=edit
Fix incorrect loop exit edge probability

[Bug testsuite/103270] [12 regression] gcc.dg/vect/pr96698.c inner loop turned from hot to cold after r12-4526

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

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

--- Comment #3 from luoxhu at gcc dot gnu.org ---
The profile count is correct but something wrong with edge probability, and it
turns out that r12-4526 exposes a long-existing issue in
profile_estimate:predict_extra_loop_exits, when searching extra exit edges for
inner loop, it goes out and find a edge belongs to *outer loop*, setting that
edge with predict value 33%, then predict_loops won't reset that edge for outer
loop.
I drafted a patch to ignore EDGE_DFS_BACK edges when iterating in
predict_extra_loop_exits, then inner loop becomes hot again.

diff base/pr103270.c.047t.profile_estimate
patched/pr103270.c.047t.profile_estimate  -U15

 Predictions for bb 5
 1 edges in bb 5 predicted to even probabilities
 Predictions for bb 6
-  first match heuristics: 33.00%
-  combined heuristics: 33.00%
+  first match heuristics: 91.67%
+  combined heuristics: 91.67%
   opcode values nonequal (on trees) heuristics of edge 6->11 (ignored): 66.00%
-  extra loop exit heuristics of edge 6->11: 33.00%
+  loop iterations heuristics of edge 6->7: 8.33%
 Predictions for bb 11
 1 edges in bb 11 predicted to even probabilities
 Predictions for bb 7
 1 edges in bb 7 predicted to even probabilitie

…

-   [local count: 88915474]:
+   [local count: 6029625]:
   goto ; [100.00%]

-   [local count: 354334800]:
+   [local count: 536870913]:
   _1 = *i_19(D);
   _2 = a_4 & c_6;
   _3 = _1 + _2;
   *i_19(D) = _3;

-   [local count: 708669601]:
+   [local count: 1073741824]:
   # c_6 = PHI 
   # d_8 = PHI <0(11), 1(3)>
   if (d_8 == 0)
 goto ; [50.00%]
   else
 goto ; [50.00%]

-   [local count: 354334800]:
+   [local count: 536870913]:
   # c_21 = PHI 
   b_18 = b_5 + -1;

-   [local count: 1073741824]:
+   [local count: 585656064]:
   # b_5 = PHI <0(10), b_18(5)>
   # c_7 = PHI <0(10), c_21(5)>
   if (b_5 != -11)
-goto ; [33.00%]
+goto ; [91.67%]
   else
-goto ; [67.00%]
+goto ; [8.33%]

-   [local count: 354334800]:
+   [local count: 536870913]:
   goto ; [100.00%]

-   [local count: 719407024]:
+   [local count: 48785151]:
   a_16 = a_4 + 1;

-   [local count: 808322498]:
+   [local count: 54814777]:
   # a_4 = PHI 
   if (a_4 <= 4)
 goto ; [89.00%]
   else
 goto ; [11.00%]

-   [local count: 719407024]:
+   [local count: 48785151]:
   goto ; [100.00%]

-   [local count: 88915474]:
+   [local count: 6029625]:
   return;

[Bug c/102979] GCC gives wrong error for struct definitions without semicolon, despite G++ already giving correct one

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/103278] [12 Regression] Recent change to cddce inhibits switch optimization

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

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

--- Comment #8 from Jeffrey A. Law  ---
Adjusting the threshold didn't help the tests on the other targets.  I'll have
to dig a little deeper into those.

[Bug tree-optimization/102232] Missed arithmetic fold

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Jeff Law :

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

commit r12-5460-gdf1a0d526e2e4c75311345c0b73ce8483e243899
Author: Navid Rahimi 
Date:   Mon Nov 22 22:07:35 2021 -0500

Re: [PATCH] PR tree-optimization/102232 Adding a missing pattern to
match.pd

PR tree-optimization/102232

gcc/
* match.pd (x * (1 + y / x) - y) -> (x - y % x): New optimization.

gcc/testsuite/

* gcc.dg/tree-ssa/pr102232.c: Testcase for this optimization.

[Bug target/93453] PPC: rldimi not taken into account to avoid shift+or

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

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

--- Comment #6 from HaoChen Gui  ---
Sehger,
  Yes, I found that the nonzero_bits doesn't return exact value in other pass.
So calling nonzero_bits in md file is bad as it can't be recognized in other
pass. 
  Right now I want to convert a single pseudo to the pseudo AND with a mask in
combine pass if its nonzero_bits is less than its mode mask and the outer
operation is plus/ior/xor and its one of inner operation is
ashift/lshiftrt/and. Thus it is possible to match rotate and insert pattern.
What's your opinion? Thanks a lot.

(ior:DI (ashift:DI (reg:DI 125)
(const_int 32 [0x20]))
(reg:DI 126)))

is converted to

(ior:DI (ashift:DI (reg:DI 125)
   (const_int 32 [0x20]))
(and:DI (reg:DI 126)
(const_int 4294967295 [0xfff]


patch.diff

diff --git a/gcc/combine.c b/gcc/combine.c
index 892c834a160..8b72a5ec831 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -11539,6 +11539,26 @@ change_zero_ext (rtx pat)
   return changed;
 }

+/* Convert a psuedo to psuedo AND with a mask if its nonzero_bits is less
+   than its mode mask.  */
+static bool
+pseudo_and_with_mask (rtx *reg)
+{
+  bool changed = false;
+  gcc_assert (REG_P (*reg));
+
+  machine_mode mode = GET_MODE (*reg);
+  unsigned HOST_WIDE_INT nonzero = nonzero_bits (*reg, mode);
+  if (nonzero < GET_MODE_MASK (mode))
+{
+  rtx x = gen_rtx_AND (mode, *reg, GEN_INT (nonzero));
+  SUBST (*reg, x);
+  changed = true;
+  //fprintf (stdout, "PIX optimization\n");
+}
+  return changed;
+}
+
 /* Like recog, but we receive the address of a pointer to a new pattern.
We try to match the rtx that the pointer points to.
If that fails, we may try to modify or replace the pattern,
@@ -11565,9 +11585,34 @@ recog_for_combine (rtx *pnewpat, rtx_insn *insn, rtx
*pnotes)

   void *marker = get_undo_marker ();
   bool changed = false;
+  //bool PIX_opt = false;

   if (GET_CODE (pat) == SET)
-changed = change_zero_ext (pat);
+{
+  rtx src = SET_SRC (pat);
+  if ((GET_CODE (src) == IOR
+  || GET_CODE (src) == XOR
+  || GET_CODE (src) == PLUS)
+ && (((GET_CODE (XEXP (src, 0)) == ASHIFT
+   || GET_CODE (XEXP (src, 0)) == LSHIFTRT
+   || GET_CODE (XEXP (src, 0)) == AND)
+  && REG_P (XEXP (src, 1)))
+ || ((GET_CODE (XEXP (src, 1)) == ASHIFT
+  || GET_CODE (XEXP (src, 1)) == LSHIFTRT
+  || GET_CODE (XEXP (src, 1)) == AND)
+ && REG_P (XEXP (src, 0)
+   {
+ changed = REG_P (XEXP (src, 0))
+   ? pseudo_and_with_mask ( (SET_SRC (pat), 0))
+   : pseudo_and_with_mask ( (SET_SRC (pat), 1));
+ if (changed)
+   {
+ maybe_swap_commutative_operands (SET_SRC (pat));
+ //PIX_opt = true;
+   }
+   }
+  changed |= change_zero_ext (pat);
+}
   else if (GET_CODE (pat) == PARALLEL)
 {
   int i;
@@ -11585,6 +11630,8 @@ recog_for_combine (rtx *pnewpat, rtx_insn *insn, rtx
*pnotes)

   if (insn_code_number < 0)
undo_to_marker (marker);
+  //else if (PIX_opt)
+   //fprintf (stdout, "PIX applied\n");
 }

   return insn_code_number;

[Bug preprocessor/103355] libcpp/lex.c:1289:9: warning: use of the 'likely' attribute is a C++20 extension [-Wc++20-extensions]

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Fixed.

[Bug preprocessor/103355] libcpp/lex.c:1289:9: warning: use of the 'likely' attribute is a C++20 extension [-Wc++20-extensions]

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

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

--- Comment #5 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:630686f93f0018fa1ef128aa673fddd302cc83e1

commit r12-5459-g630686f93f0018fa1ef128aa673fddd302cc83e1
Author: Marek Polacek 
Date:   Mon Nov 22 11:29:40 2021 -0500

libcpp: Use [[likely]] conditionally

Let's hide [[likely]] behind a macro, to suppress warnings if the
compiler doesn't support it.

Co-authored-by: Jonathan Wakely 

PR preprocessor/103355

libcpp/ChangeLog:

* lex.c: Use ATTR_LIKELY instead of [[likely]].
* system.h (ATTR_LIKELY): Define.

[Bug c++/77781] [DR 1315] Some valid cases of partial specialization not accepted

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Marek Polacek  ---
Fixed by 9b94785dedb08b006419bec1a402614d9241317a.

[Bug tree-optimization/102216] [12 Regression] missed optimization causing Warray-bounds

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #10)
> Created attachment 51850 [details]
> Updated patch

Note this patch is broken but I have the corrected patch which I am testing
now.

[Bug c++/92145] -Wdeprecated-copy false-positive when inheriting base assignment operators

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Fixed?

[Bug tree-optimization/102216] [12 Regression] missed optimization causing Warray-bounds

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #51424|0   |1
is obsolete||

--- Comment #10 from Andrew Pinski  ---
Created attachment 51850
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51850=edit
Updated patch

Updated patch based on the feedback, still need to add back the testcase
though.

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

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

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

Bug 96779 Summary: Failure to optimize comparison of negative version of self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96779

   What|Removed |Added

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

[Bug tree-optimization/96779] Failure to optimize comparison of negative version of self

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||law at gcc dot gnu.org
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Jeffrey A. Law  ---
Should be fixed by Navid's patch on the trunk.

[Bug tree-optimization/96779] Failure to optimize comparison of negative version of self

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jeff Law :

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

commit r12-5458-ge888bea2384a0d8d29a6545c4f57f41cb49df0a6
Author: Navid Rahimi 
Date:   Mon Nov 22 19:46:17 2021 -0500

Re: [PATCH] PR tree-optimization/96779 Adding a missing pattern to match.pd

PR tree-optimization/96779
gcc/
* match.pd (-x == x) -> (x == 0): New optimization.

gcc/testsuite
* gcc.dg/tree-ssa/pr96779.c: Testcase for this optimization.
* gcc.dg/tree-ssa/pr96779-disabled.c: Testcase for this
optimization
when -fwrapv passed.

[Bug tree-optimization/103168] Value numbering for PRE of pure functions can be improved

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #14 from hubicka at kam dot mff.cuni.cz ---
This is bit modified patch I am testing.  I added pre-computation of the
number of accesses, enabled the path for const functions (in case they
have memory operand), initialized alias sets and clarified the logic
around every_* and global_memory_accesses

PR tree-optimization/103168
(modref_summary::finalize): Initialize load_accesses.
* ipa-modref.h (struct modref_summary): Add load_accesses.
* tree-ssa-sccvn.c (visit_reference_op_call): Use modref
info to walk the virtual use->def chain to CSE pure
function calls.

* g++.dg/tree-ssa/pr103168.C: New testcase.

diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 4f9323165ea..595eb6e0d8f 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -725,6 +727,23 @@ modref_summary::finalize (tree fun)
break;
}
 }
+  if (loads->every_base)
+load_accesses = 1;
+  else
+{
+  load_accesses = 0;
+  for (auto base_node : loads->bases)
+   {
+ if (base_node->every_ref)
+   load_accesses++;
+ else
+   for (auto ref_node : base_node->refs)
+ if (ref_node->every_access)
+   load_accesses++;
+ else
+   load_accesses += ref_node->accesses->length ();
+   }
+}
 }

 /* Get function summary for FUNC if it exists, return NULL otherwise.  */
diff --git a/gcc/ipa-modref.h b/gcc/ipa-modref.h
index f868eb6de07..a7937d74945 100644
--- a/gcc/ipa-modref.h
+++ b/gcc/ipa-modref.h
@@ -53,6 +53,8 @@ struct GTY(()) modref_summary

   /* Flags coputed by finalize method.  */

+  /* Total number of accesses in loads tree.  */
+  unsigned int load_accesses;
   /* global_memory_read is not set for functions calling functions
  with !binds_to_current_def which, after interposition, may read global
  memory but do nothing useful with it (except for crashing if some
diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr103168.C
b/gcc/testsuite/g++.dg/tree-ssa/pr103168.C
new file mode 100644
index 000..82924a3e3ce
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr103168.C
@@ -0,0 +1,24 @@
+// { dg-do compile }
+// { dg-options "-O2 -fdump-tree-fre1-details" }
+
+struct a
+{
+  int a;
+  static __attribute__ ((noinline))
+  int ret (int v) {return v;}
+
+  __attribute__ ((noinline))
+  int inca () {return a++;}
+};
+
+int
+test()
+{
+  struct a av;
+  av.a=1;
+  int val = av.ret (0) + av.inca();
+  av.a=2;
+  return val + av.ret(0) + av.inca();
+}
+
+/* { dg-final { scan-tree-dump-times "Replaced a::ret" 1 "fre1" } } */
diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 149674e6a16..719f5184654 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -71,6 +71,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-ssa-loop-niter.h"
 #include "builtins.h"
 #include "fold-const-call.h"
+#include "ipa-modref-tree.h"
+#include "ipa-modref.h"
 #include "tree-ssa-sccvn.h"

 /* This algorithm is based on the SCC algorithm presented by Keith
@@ -5084,12 +5086,118 @@ visit_reference_op_call (tree lhs, gcall *stmt)
   struct vn_reference_s vr1;
   vn_reference_t vnresult = NULL;
   tree vdef = gimple_vdef (stmt);
+  modref_summary *summary;

   /* Non-ssa lhs is handled in copy_reference_ops_from_call.  */
   if (lhs && TREE_CODE (lhs) != SSA_NAME)
 lhs = NULL_TREE;

   vn_reference_lookup_call (stmt, , );
+
+  /* If the lookup did not succeed for pure functions try to use
+ modref info to find a candidate to CSE to.  */
+  const int accesses_limit = 8;
+  if (!vnresult
+  && !vdef
+  && lhs
+  && gimple_vuse (stmt)
+  && (((summary = get_modref_function_summary (stmt, NULL))
+  && !summary->global_memory_read
+  && summary->load_accesses < accesses_limit)
+ || gimple_call_flags (stmt) & ECF_CONST))
+{
+  /* First search if we can do someting useful and build a
+vector of all loads we have to check.  */
+  bool unknown_memory_access = false;
+  auto_vec accesses;
+
+  if (summary)
+   {
+ for (auto base_node : summary->loads->bases)
+   if (unknown_memory_access)
+ break;
+   else for (auto ref_node : base_node->refs)
+ if (unknown_memory_access)
+   break;
+ else for (auto access_node : ref_node->accesses)
+   {
+ accesses.quick_grow (accesses.length () + 1);
+ if (!access_node.get_ao_ref (stmt,  ()))
+   {
+ /* We could use get_call_arg (...) and initialize
+a ref based on the argument and unknown offset in
+some cases, but we have to get a ao_ref to
+disambiguate against other stmts.  */
+ unknown_memory_access = true;
+ 

Re: [Bug tree-optimization/103168] Value numbering for PRE of pure functions can be improved

[Jan Hubicka via Gcc-bugs]

This is bit modified patch I am testing.  I added pre-computation of the
number of accesses, enabled the path for const functions (in case they
have memory operand), initialized alias sets and clarified the logic
around every_* and global_memory_accesses

PR tree-optimization/103168
(modref_summary::finalize): Initialize load_accesses.
* ipa-modref.h (struct modref_summary): Add load_accesses.
* tree-ssa-sccvn.c (visit_reference_op_call): Use modref
info to walk the virtual use->def chain to CSE pure
function calls.

* g++.dg/tree-ssa/pr103168.C: New testcase.

diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 4f9323165ea..595eb6e0d8f 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -725,6 +727,23 @@ modref_summary::finalize (tree fun)
break;
}
 }
+  if (loads->every_base)
+load_accesses = 1;
+  else
+{
+  load_accesses = 0;
+  for (auto base_node : loads->bases)
+   {
+ if (base_node->every_ref)
+   load_accesses++;
+ else
+   for (auto ref_node : base_node->refs)
+ if (ref_node->every_access)
+   load_accesses++;
+ else
+   load_accesses += ref_node->accesses->length ();
+   }
+}
 }
 
 /* Get function summary for FUNC if it exists, return NULL otherwise.  */
diff --git a/gcc/ipa-modref.h b/gcc/ipa-modref.h
index f868eb6de07..a7937d74945 100644
--- a/gcc/ipa-modref.h
+++ b/gcc/ipa-modref.h
@@ -53,6 +53,8 @@ struct GTY(()) modref_summary
 
   /* Flags coputed by finalize method.  */
 
+  /* Total number of accesses in loads tree.  */
+  unsigned int load_accesses;
   /* global_memory_read is not set for functions calling functions
  with !binds_to_current_def which, after interposition, may read global
  memory but do nothing useful with it (except for crashing if some
diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr103168.C 
b/gcc/testsuite/g++.dg/tree-ssa/pr103168.C
new file mode 100644
index 000..82924a3e3ce
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr103168.C
@@ -0,0 +1,24 @@
+// { dg-do compile }
+// { dg-options "-O2 -fdump-tree-fre1-details" }
+
+struct a
+{
+  int a;
+  static __attribute__ ((noinline))
+  int ret (int v) {return v;}
+
+  __attribute__ ((noinline))
+  int inca () {return a++;}
+};
+
+int
+test()
+{
+  struct a av;
+  av.a=1;
+  int val = av.ret (0) + av.inca();
+  av.a=2;
+  return val + av.ret(0) + av.inca();
+}
+
+/* { dg-final { scan-tree-dump-times "Replaced a::ret" 1 "fre1" } } */
diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 149674e6a16..719f5184654 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -71,6 +71,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-ssa-loop-niter.h"
 #include "builtins.h"
 #include "fold-const-call.h"
+#include "ipa-modref-tree.h"
+#include "ipa-modref.h"
 #include "tree-ssa-sccvn.h"
 
 /* This algorithm is based on the SCC algorithm presented by Keith
@@ -5084,12 +5086,118 @@ visit_reference_op_call (tree lhs, gcall *stmt)
   struct vn_reference_s vr1;
   vn_reference_t vnresult = NULL;
   tree vdef = gimple_vdef (stmt);
+  modref_summary *summary;
 
   /* Non-ssa lhs is handled in copy_reference_ops_from_call.  */
   if (lhs && TREE_CODE (lhs) != SSA_NAME)
 lhs = NULL_TREE;
 
   vn_reference_lookup_call (stmt, , );
+
+  /* If the lookup did not succeed for pure functions try to use
+ modref info to find a candidate to CSE to.  */
+  const int accesses_limit = 8;
+  if (!vnresult
+  && !vdef
+  && lhs
+  && gimple_vuse (stmt)
+  && (((summary = get_modref_function_summary (stmt, NULL))
+  && !summary->global_memory_read
+  && summary->load_accesses < accesses_limit)
+ || gimple_call_flags (stmt) & ECF_CONST))
+{
+  /* First search if we can do someting useful and build a
+vector of all loads we have to check.  */
+  bool unknown_memory_access = false;
+  auto_vec accesses;
+
+  if (summary)
+   {
+ for (auto base_node : summary->loads->bases)
+   if (unknown_memory_access)
+ break;
+   else for (auto ref_node : base_node->refs)
+ if (unknown_memory_access)
+   break;
+ else for (auto access_node : ref_node->accesses)
+   {
+ accesses.quick_grow (accesses.length () + 1);
+ if (!access_node.get_ao_ref (stmt,  ()))
+   {
+ /* We could use get_call_arg (...) and initialize
+a ref based on the argument and unknown offset in
+some cases, but we have to get a ao_ref to
+disambiguate against other stmts.  */
+ unknown_memory_access = true;
+ break;
+   }
+ else
+   {
+ 

[Bug c++/96507] missing -Waddress for member references

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

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585178.html

[Bug tree-optimization/103215] [12 regression] gcc generates unexpected warnings on libx11-1.7.2: error: array subscript -2 is outside array bounds of since r12-3124-g820f0940d7ace130

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #7 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585180.html

[Bug target/103370] [12 Regression] Assembler error building glibc for ColdFire soft-float

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

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

--- Comment #2 from Andrew Pinski  ---
case OPTION_PCREL:  /* --pcrel means never turn PC-relative
   branches into absolute jumps.  */
  flag_keep_pcrel = 1;
  break;


--pcrel is passed to the assembler for -fPIC/-fpic code.

[Bug target/103370] [12 Regression] Assembler error building glibc for ColdFire soft-float

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

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

--- Comment #1 from Andrew Pinski  ---
  if (!HAVE_LONG_BRANCH (current_architecture))
{
  if (flag_keep_pcrel)
as_fatal (_("Tried to convert PC relative branch to absolute jump"));


#define HAVE_LONG_BRANCH(x) \
((x) & (m68020|m68030|m68040|m68060|cpu32|fido_a|mcfisa_b))

[Bug target/103370] New: [12 Regression] Assembler error building glibc for ColdFire soft-float

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

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

Bug ID: 103370
   Summary: [12 Regression] Assembler error building glibc for
ColdFire soft-float
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: assemble-failure
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: m68k*-*-*

Created attachment 51849
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51849=edit
preprocessed source

Compile and assemble the attached preprocessed source (from glibc) with -O2
-fPIC -c, using a compiler configured for m68k-linux-gnu --with-arch=cf
--with-cpu=54455 --disable-multilib (this is m68k-linux-gnu-coldfire-soft in
build-many-glibcs.py).  This produces an assembler error:

/tmp/cctaeK7A.s: Assembler messages:
/tmp/cctaeK7A.s: Fatal error: Tried to convert PC relative branch to absolute
jump

This appeared with

commit 045206450386bcd774db3bde0c696828402361c6
Author: Richard Biener 
Date:   Fri Nov 12 10:21:22 2021 +0100

tree-optimization/102880 - improve CD-DCE

though I'm guessing it was most likely to have been latent before then.

[Bug target/103271] ICE in assign_stack_temp_for_type with -ftrivial-auto-var-init=pattern and VLAs and -mno-strict-align on riscv64

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #1 from qinzhao at gcc dot gnu.org ---
was not able to repeat this failure yet due to:

1. cannot find a riscv machine either in my company or in gcc farm.
2. tried to build a cross-compiler on riscv64 from a x86 platform, but always
failed.

is there a good documentation to build cross-compiler?

[Bug tree-optimization/93051] Wrong optimizations for pointers: `if (p == q) use p` -> `if (p == q) use q`

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gabravier at gmail dot com

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

[Bug c/103343] Invalid codegen when comparing pointer to one past the end and then dereferencing that pointer

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

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

--- Comment #5 from Andrew Pinski  ---
> The only thing that is questionable is the comparison with pointer past the 
> end of an object, which is merely unspecified.

Ok, it is a dup of bug 93051.

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

[Bug tree-optimization/103168] Value numbering for PRE of pure functions can be improved

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

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

--- Comment #13 from Jan Hubicka  ---
Concerning comment #10, the problem was that the loop walking all accesses was
missing loads->every_base check.  This is used to represent that we track no
useful info about loads performed at all.

Anyway if I read the code correctly, it does nothing useful if the access tree
contains any access for which we can not construct ref and thus one can simply
check global_memory_access and do not care about
every_base/every_ref/every_access since these must be all false.

I simplified the walk a bit and added code pre-computing number of accesses in
the tree into the summary.

What we can also do is, when hitting access for which we can not construct ref,
or when hitting every_ref/every_acccess, is to construct ref with
base_alias_set/ref_alias_set as given by the access tree but with base=NULL,
offset=0 and size=max_size=-1. This should still let the basic TBAA oracle to
disambiguate.

[Bug c/103343] Invalid codegen when comparing pointer to one past the end and then dereferencing that pointer

[leni536 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Lénárd Szolnoki  ---
A complete program example:

f.h:
```
#pragma once
extern int x[1];
extern int y;

int f(int* p, int* q);
```

f.cpp:
```
#include "f.h"

int f(int* p, int* q) {
*q = y;
if (p == (x + 1)) {
*p = 2;
return y;
}
return 0;
}
```

x_y.cpp:
```
#include "f.h"

int y;
int x[1];
```

main.cpp:
```
#include "f.h"

int main() {
y=1;
int i;
return f(, );
}
```

Compile with `g++ -o main main.cpp f.cpp x_y.cpp`.
https://godbolt.org/z/G4KTKc7hE

The well-formed program above has two possible evaluations, due to the
unspecified comparison. In one evaluation `main` returns 0, in the other it
returns 2. Compiled with g++ the program returns 1.

Within the single invocation of `f` `p` is pointer to an object, namely `y`.
Even after the unspecified comparison evaluates to true, `p` remains a pointer
to `y`. Therefore dereferencing `p` is still valid in that branch.

I don't think that it is a duplicate of bug 61502. The program does not rely on
the object representation of the pointer objects, their printed value or their
value converted to uintptr_t. The only thing that is questionable is the
comparison with pointer past the end of an object, which is merely unspecified.

[Bug driver/100937] configure: Add --enable-default-semantic-interposition

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #12 from hubicka at kam dot mff.cuni.cz ---
> (The -fno-semantic-interposition thing is probably the biggest performance gap
> between gcc -fpic and clang -fpic.)
Yep, it is often confusing to users (who do not understand what ELF
interposition is) that clang and gcc disagree on default flags here.
Recently -Ofast was extended to imply -fno-semantic-interposition that
will hopefully make more people notice this.

While doing that I have added per-symbol flag about interposition to the
symbol table, so we can also support 

__atttribute__ ((semantic_interposition))

and

__attribute__((no_semantic_interpoition))

if that would be useful for something.

Re: [Bug driver/100937] configure: Add --enable-default-semantic-interposition

[Jan Hubicka via Gcc-bugs]

> (The -fno-semantic-interposition thing is probably the biggest performance gap
> between gcc -fpic and clang -fpic.)
Yep, it is often confusing to users (who do not understand what ELF
interposition is) that clang and gcc disagree on default flags here.
Recently -Ofast was extended to imply -fno-semantic-interposition that
will hopefully make more people notice this.

While doing that I have added per-symbol flag about interposition to the
symbol table, so we can also support 

__atttribute__ ((semantic_interposition))

and

__attribute__((no_semantic_interpoition))

if that would be useful for something.

[Bug fortran/102043] Wrong array types used for negative stride accesses

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

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #25 from Jan Hubicka  ---
*** Bug 103369 has been marked as a duplicate of this bug. ***

[Bug fortran/103369] [12 Regression] gfortran.dg/vector_subscript_1.f90

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

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Hubicka  ---
This is tracked as PR102043 (it is long lasting bug which was earlier
manifesting itself only with -fipa-pta, but now it also gets exposed by modref)

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

[Bug fortran/103369] [12 Regression] gfortran.dg/vector_subscript_1.f90

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||102043

--- Comment #1 from Andrew Pinski  ---
I think this is the same as PR 102043 as described in PR 86389 .


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
[Bug 102043] Wrong array types used for negative stride accesses

[Bug tree-optimization/103359] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

--- Comment #2 from Andrew Pinski  ---
The other thing is:

-ftree-bit-ccp
Visiting statement:
_4 = _3 & 1;
which is likely CONSTANT
Applying pattern match.pd:1641, gimple-match.c:23146
Lattice value changed to CONSTANT 0x0 (0x1).  Adding SSA edges to worklist.
marking stmt to be not simulated again

vs

-fno-tree-bit-ccp
_4 = _3 & 1;
which is likely CONSTANT
Applying pattern match.pd:1641, gimple-match.c:23146
Lattice value changed to VARYING.  Adding SSA edges to worklist.

In the first case we mark the stmt as not be simulated again while in the
second case we didn't.

Someone who understands ccp better should look into this.

[Bug fortran/103369] New: [12 Regression] gfortran.dg/vector_subscript_1.f90

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

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

Bug ID: 103369
   Summary: [12 Regression] gfortran.dg/vector_subscript_1.f90
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

I see the following unexpected failures with today's build of GCC 12:

FAIL: gfortran.dg/vector_subscript_1.f90   -O1  execution test
FAIL: gfortran.dg/vector_subscript_1.f90   -O2  execution test
FAIL: gfortran.dg/vector_subscript_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/vector_subscript_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/vector_subscript_1.f90   -Os  execution test

The output just before each failure looks like this:

Execution timeout is: 300
spawn [open ...]
STOP 12
FAIL: gfortran.dg/vector_subscript_1.f90   -O1  execution test

I didn't investigate beyond that so I don't know if the problem is in the front
end or elsewhere.  The test hasn't changed since February 2018 so I'm guessing
it's not the cause of the problem.

[Bug tree-optimization/103359] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-22
   Keywords||missed-optimization
   Target Milestone|--- |12.0

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

In CCP1 on the trunk:
Visiting statement:
f_18 = (short intD.25) _6;
which is likely CONSTANT
Lattice value changed to CONSTANT 0x4 (0x1).  Adding SSA edges to worklist.



In ccp1 on the trunk with -fno-tree-bit-ccp:
Visiting statement:
f_18 = (short intD.25) _6;
which is likely CONSTANT
Applying pattern match.pd:3663, gimple-match.c:42920
Applying pattern match.pd:3580, gimple-match.c:42859
Match-and-simplified (short int) _6 to _5
Lattice value changed to CONSTANT _5.  Adding SSA edges to worklist.
marking stmt to be not simulated again

So ccp1 sometimes applies match and simplify and sometimes does not 

[Bug preprocessor/103165] [12 Regression] ICE unspellable token PRAGMA since r12-4797-g0078a058a5693871

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

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

[Bug preprocessor/103165] [12 Regression] ICE unspellable token PRAGMA since r12-4797-g0078a058a5693871

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

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

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

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

commit r12-5454-ga6e0d593707ae44dec0bdf2bcdc4f539050b46db
Author: Jakub Jelinek 
Date:   Mon Nov 22 22:29:20 2021 +0100

libcpp: Fix _Pragma stringification [PR103165]

As the testcase show, sometimes _Pragma is turned into CPP_PRAGMA
.. CPP_PRAGMA_EOL tokens, even when it might still need to be
stringized later on.  We are then ICEing because we don't handle
stringification of CPP_PRAGMA or CPP_PRAGMA_EOL, but trying to
reconstruct the exact tokens with exact spacing after it has been
lowered is very hard.  So, instead this patch ensures we don't
lower _Pragma during expand_arg calls, but only later when
cpp_get_token_1 is called outside of expand_arg.

2021-11-22  Jakub Jelinek  
Tobias Burnus  

PR preprocessor/103165
libcpp/
* internal.h (struct lexer_state): Add ignore__Pragma field.
* macro.c (builtin_macro): Don't interpret _Pragma if
pfile->state.ignore__Pragma.
(expand_arg): Temporarily set pfile->state.ignore__Pragma to 1.
gcc/testsuite/
* c-c++-common/gomp/pragma-3.c: New test.
* c-c++-common/gomp/pragma-4.c: New test.
* c-c++-common/gomp/pragma-5.c: New test.

Co-Authored-By: Tobias Burnus 

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com via Gcc-bugs]

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

Tomas Kalibera  changed:

   What|Removed |Added

 CC||tomas.kalibera at gmail dot com

--- Comment #2 from Tomas Kalibera  ---
My apologies if this is obvious, but please let me note this issue means that
one cannot print(f) a 64-bit integer without a compile-time warning with UCRT
on Windows. It would be a great help if this could somehow be fixed.

In the example below, lines (1) and (2) work without a warning with MSVCRT.
But, all three issue a warning with UCRT.

#include 
#include 

int main(int argc, char **argv) {
  long long unsigned x = 112;

  printf("Hello %"PRIu64"\n", x); // 1
  printf("Hello %I64u\n", x); // 2
  printf("Hello %llu\n", x);  // 3
  return 0;
}

[Bug middle-end/103365] ICE in register_scoped_attribute, at attribs.c:390

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[12 Regression] ICE in  |ICE in
   |register_scoped_attribute,  |register_scoped_attribute,
   |at attribs.c:390|at attribs.c:390
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
   Last reconfirmed||2021-11-22
 Ever confirmed|0   |1
  Component|c   |middle-end

--- Comment #1 from Andrew Pinski  ---
#pragma GCC diagnostic ignored_attributes "n::_a"

There is a check to make sure the attribute isn't named __a__ but the assert
only checks that the attribute starts with _.

Note you can also reproduce the ICE with the following option passed to GCC:
-Wno-attributes=n::_a

Confirmed, not a regression as the warning option is new.

[Bug driver/103362] -m option is not ignored when is immediately preceded by -o option

[egor_suvorov at mail dot ru via Gcc-bugs]

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

--- Comment #2 from Egor Suvorov  ---
Thank you very much, sent a report there:
https://sourceware.org/bugzilla/show_bug.cgi?id=28619

[Bug c/103343] Invalid codegen when comparing pointer to one past the end and then dereferencing that pointer

[gabravier at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Gabriel Ravier  ---
Well the code does not invoke undefined behavior here, it just so happens that
`p == (x + 1)` because `y` happens to be laid out in memory after `x` (note:
this isn't a guarantee, of course, but GCC can't prove this isn't the case as
it's defined in another TU and it's quite easy to make this happen). The
comparison doesn't imply the pointers have the same provenance, and the
standard has a specific provision for this exact comparison:

"If one pointer represents the address of a complete object, and another
pointer represents the address one past the last element of a different
complete object,72 the result of the comparison is unspecified."
- [expr.eq] (https://eel.is/c++draft/expr.eq#3.1)

Also, `y` isn't accessed through a pointer to `x`: I've already said the case
where the function is incorrect is when `f` is called with `` as the first
argument. If doing `p == (x + 1)` implied they derived from the same object,
then that would imply after doing ` == (x + 1)` doing `*` would invoke
undefined behavior which is obviously ridiculous.

Although there is a case to be made that this code is stupid and deserves a
warning, though... I won't argue with that, this code is just something I wrote
to test things after a 3 hour long conversation about DR 260
() and a lot of
standardese lawyering, so it's not intended to be real life code. I'd say,
though, that the warning is quite inaccurate in the details of what it's
saying, as `p` isn't actually equivalent to `(x + 1)` just because `p == (x +
1)`.

[Bug driver/103362] -m option is not ignored when is immediately preceded by -o option

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
/usr/bin/ld -plugin /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
-plugin-opt=-fresolution=/tmp/cc0czmWl.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -pie -z now -z relro -o -main
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/7
-L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. /tmp/ccz74klC.o -v -lgcc
--push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed
-lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o

Please report this to binutils (http://sourceware.org/bugzilla/).  GCC's driver
is doing the correct thing and producing "-o -main".

[Bug fortran/99061] [10/11/12 Regression] ICE in gfc_conv_intrinsic_atan2d, at fortran/trans-intrinsic.c:4728

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Fixed for gcc-12, and on 11- and 10-branch.  Closing.

Thanks for the report!

[Bug fortran/99061] [10/11/12 Regression] ICE in gfc_conv_intrinsic_atan2d, at fortran/trans-intrinsic.c:4728

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

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

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

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

commit r10-10287-g3eeda9a3b5e932bad28ca870077185ced67eb27e
Author: Harald Anlauf 
Date:   Sun Nov 21 19:29:27 2021 +0100

Fortran: fix lookup for gfortran builtin math intrinsics used by DEC
extensions

gcc/fortran/ChangeLog:

PR fortran/99061
* trans-intrinsic.c (gfc_lookup_intrinsic): Helper function for
looking up gfortran builtin intrinsics.
(gfc_conv_intrinsic_atrigd): Use it.
(gfc_conv_intrinsic_cotan): Likewise.
(gfc_conv_intrinsic_cotand): Likewise.
(gfc_conv_intrinsic_atan2d): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/99061
* gfortran.dg/dec_math_5.f90: New test.

Co-authored-by: Steven G. Kargl 
(cherry picked from commit 8fef6f720a5a0a056abfa986ba870bb406ab4716)

[Bug fortran/99061] [10/11/12 Regression] ICE in gfc_conv_intrinsic_atan2d, at fortran/trans-intrinsic.c:4728

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

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

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

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

commit r11-9263-gc224f21418e105e5dbbcec98018d9329970afd84
Author: Harald Anlauf 
Date:   Sun Nov 21 19:29:27 2021 +0100

Fortran: fix lookup for gfortran builtin math intrinsics used by DEC
extensions

gcc/fortran/ChangeLog:

PR fortran/99061
* trans-intrinsic.c (gfc_lookup_intrinsic): Helper function for
looking up gfortran builtin intrinsics.
(gfc_conv_intrinsic_atrigd): Use it.
(gfc_conv_intrinsic_cotan): Likewise.
(gfc_conv_intrinsic_cotand): Likewise.
(gfc_conv_intrinsic_atan2d): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/99061
* gfortran.dg/dec_math_5.f90: New test.

Co-authored-by: Steven G. Kargl 
(cherry picked from commit 8fef6f720a5a0a056abfa986ba870bb406ab4716)

[Bug driver/100937] configure: Add --enable-default-semantic-interposition

[i at maskray dot me via Gcc-bugs]

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

--- Comment #11 from Fangrui Song  ---
To enable interposition on Mach-O, one needs a non-default configuration like:
ld -interposable, DYLD_FORCE_FLAT_NAMESPACE or
__attribute__((section("__DATA,__interpose"))).
On PE/COFF, such interposition just doesn't exist.

Having an option for -fno-semantic-interposition will actually improve
portability.

(The -fno-semantic-interposition thing is probably the biggest performance gap
between gcc -fpic and clang -fpic.)

As I said previously, -fvisibility=protected cannot be used because protected
visibility is very broken in the GCC/GNU ld system and there is no signal it
will be fixed anytime soon:
https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected#summary

[Bug target/93453] PPC: rldimi not taken into account to avoid shift+or

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

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

--- Comment #5 from Segher Boessenkool  ---
(In reply to HaoChen Gui from comment #4)
> (define_insn_and_split "*rotl3_insert_8"
>   [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
> (plus_ior_xor:GPR (ashift:GPR (match_operand:GPR 1 "gpc_reg_operand" 
> "r")
>   (match_operand:SI 2 "const_int_operand" 
> "n"))
>   (match_operand:GPR 3 "gpc_reg_operand" "0")))]
>   "INTVAL (operands[2]) > 0
>&& (nonzero_bits (operands[3], mode)
>< HOST_WIDE_INT_1U << INTVAL (operands[2]))"
> {
>   if (mode == SImode)
> return "rlwimi %0,%1,%h2,0,31-%h2";
>   else
> return "rldimi %0,%1,%H2,0";
> }
>   "&& 1"
>   [(set (match_dup 0)
> (ior:GPR (and:GPR (match_dup 3)
>   (match_dup 4))
>  (ashift:GPR (match_dup 1)
>  (match_dup 2]
> {
>   operands[4] = GEN_INT ((HOST_WIDE_INT_1U << INTVAL (operands[2])) - 1);
> }
>   [(set_attr "type" "insert")])
> 
> But I found that nonzero_bits can't return an exact value except in combine
> pass.

It can return a different value after the combine pass, yes.  But making the
version of nonzero_bits used by combine be the generic version would be a big
regression, and the version used by combine cannot be used anywhere else (it
was an extension of flow.c originally, but this wasn't ported to the dataflow
framework).

I planned to fix this for GCC 12, but we are in stage 3 already :-)

> So the pattern finally can't be split to pattern of
> 'rotl3_insert_3'. Also if the pass after combine changes the insn, it
> can't be recognized as the nonzero_bits doesn't return exact value in that
> pass.
> 
> I am thinking if we can convert third operand to "reg and a mask" when the
> nonzero_bits is known in combine pass. Thus the pattern can be directly
> combined to 'rotl3_insert_3'.  
> 
> (set (reg:DI 123)
> (ior:DI (ashift:DI (reg:DI 125)
> (const_int 32 [0x20]))
> (reg:DI 126)))
> 
> (set (reg:DI 123)
> (ior:DI (ashift:DI (reg:DI 125)
>(const_int 32 [0x20]))
> (and:DI (reg:DI 126)
> (const_int 4294967295 [0xfff]

Will nothing modify it back?

[Bug fortran/103368] New: [11/12 Regression] ICE in gimplify_expr, at gimplify.c:15668

[gscfq--- via Gcc-bugs]

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

Bug ID: 103368
   Summary: [11/12 Regression] ICE in gimplify_expr, at
gimplify.c:15668
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20211017 and 20211024 :


$ cat z1.f90
program p
   type t
   end type
   type t2
  class(*), allocatable :: a
   end type
   type(t) :: x
   call sub (t2(x))
end


$ gfortran-12-20211017 -c z1.f90
z1.f90:8:16:

8 |call sub (t2(x))
  |1
Error: Cannot convert TYPE(t) to CLASS(*) at (1)


$ gfortran-12-20211121 -c z1.f90
z1.f90:8:19:

8 |call sub (t2(x))
  |   ^
internal compiler error: in gimplify_expr, at gimplify.c:15668
0xad2dc5 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:15668
0xad862b gimplify_modify_expr
../../gcc/gimplify.c:5983
0xad019a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14666
0xad2df8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:7024
0xad0a6b gimplify_statement_list
../../gcc/gimplify.c:2012
0xad0a6b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:15111
0xad2df8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:7024
0xad3351 gimplify_bind_expr
../../gcc/gimplify.c:1426
0xad060a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14867
0xad2df8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:7024
0xad0a6b gimplify_statement_list
../../gcc/gimplify.c:2012
0xad0a6b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:15111
0xad2df8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:7024
0xad3351 gimplify_bind_expr
../../gcc/gimplify.c:1426
0xad060a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14867
0xad2df8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:7024
0xad3351 gimplify_bind_expr
../../gcc/gimplify.c:1426
0xad060a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14867
0xad2df8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:7024
0xad3e6b gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:15912

[Bug fortran/103367] New: [11/12 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377

[gscfq--- via Gcc-bugs]

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

Bug ID: 103367
   Summary: [11/12 Regression] ICE in gfc_conv_array_initializer,
at fortran/trans-array.c:6377
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20211003 and 20211010 :
(follow-up of pr102817)


$ cat z1.f90
program p
   type t
  integer :: a(1,2) = 3
   end type
   type(t), parameter :: x(1) = t(4)
   integer :: y(1,2) = (x(b)%a)
   print *, y
end


$ gfortran-12-20211121 -c z1.f90
z1.f90:6:26:

6 |integer :: y(1,2) = (x(b)%a)
  |  1
Warning: Legacy Extension: REAL array index at (1)
z1.f90:1:9:

1 | program p
  | 1
internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:6377
0x865e1a gfc_conv_array_initializer(tree_node*, gfc_expr*)
../../gcc/fortran/trans-array.c:6377
0x893b60 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:8375
0x874f2b gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1941
0x87770f generate_local_decl
../../gcc/fortran/trans-decl.c:5848
0x833a42 do_traverse_symtree
../../gcc/fortran/symbol.c:4174
0x87884c generate_local_vars
../../gcc/fortran/trans-decl.c:6054
0x87884c gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:7579
0x7fbd3e translate_all_program_units
../../gcc/fortran/parse.c:6638
0x7fbd3e gfc_parse_file()
../../gcc/fortran/parse.c:6925
0x848a6f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug fortran/103366] New: [12 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.c:5647

[gscfq--- via Gcc-bugs]

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

Bug ID: 103366
   Summary: [12 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc,
at fortran/trans-expr.c:5647
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This changed between 20211017 and 20211024 :


$ cat z1.f90
program p
contains
   subroutine s(x) bind(c)
  type(*) :: x(..)
   end
   subroutine u(x)
  class(*) :: x(..)
  call s(x)
   end
end


$ gfortran-12-20211017 -c z1.f90
$
$ gfortran-12-20211121 -c z1.f90
z1.f90:8:15:

8 |   call s(x)
  |   1
internal compiler error: in gfc_conv_gfc_desc_to_cfi_desc, at
fortran/trans-expr.c:5647
0x886d7e gfc_conv_gfc_desc_to_cfi_desc
../../gcc/fortran/trans-expr.c:5647
0x88bf87 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.c:6802
0x8c6f90 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../gcc/fortran/trans-stmt.c:422
0x84fb38 trans_code
../../gcc/fortran/trans.c:1984
0x8789fe gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:7644
0x87882c gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5772
0x87882c gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:7576
0x7fbd3e translate_all_program_units
../../gcc/fortran/parse.c:6638
0x7fbd3e gfc_parse_file()
../../gcc/fortran/parse.c:6925
0x848a6f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug c/103365] New: [12 Regression] ICE in register_scoped_attribute, at attribs.c:390

[gscfq--- via Gcc-bugs]

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

Bug ID: 103365
   Summary: [12 Regression] ICE in register_scoped_attribute, at
attribs.c:390
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20211107 and 2024  :


$ cat z1.c
#pragma GCC diagnostic ignored_attributes "c1::_attr"


$ gcc-12-20211121 -c z1.c
z1.c:1:9: internal compiler error: in register_scoped_attribute, at
attribs.c:390
1 | #pragma GCC diagnostic ignored_attributes "c1::_attr"
  | ^~~
0x74a559 register_scoped_attribute
../../gcc/attribs.c:390
0x74a640 register_scoped_attributes(attribute_spec const*, char const*, bool)
../../gcc/attribs.c:164
0x74acbd handle_ignored_attributes_option(vec*)
../../gcc/attribs.c:315
0x80bd84 handle_pragma_diagnostic
../../gcc/c-family/c-pragma.c:826
0x791881 c_parser_pragma
../../gcc/c/c-parser.c:12616
0x7b7135 c_parser_external_declaration
../../gcc/c/c-parser.c:1761
0x7b79fb c_parser_translation_unit
../../gcc/c/c-parser.c:1653
0x7b79fb c_parse_file()
../../gcc/c/c-parser.c:23280
0x808eb2 c_common_parse_file()
../../gcc/c-family/c-opts.c:1240

[Bug c/103364] s390x: TLS reference in /usr/lib64/libLLVM.so mismatches non-TLS reference in /usr/lib64/libLLVM.so

[sarah.kriesch at opensuse dot org via Gcc-bugs]

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

--- Comment #1 from Sarah Julia Kriesch  ---
gcc version: 11-4.1
operating system: openSUSE Tumbleweed (build process of PostgreSQL14 and
Rust1.54)
architecture: s390x

options at PostgreSQL:
 CFLAGS=-Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard
-Wno-format-truncation -Wno-stringop-truncation -O2 -g -m64 -fmessage-length=0
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables
CPPFLAGS= -D_GNU_SOURCE -I/usr/include/libxml2 
LDFLAGS=-flto=auto -ffat-lto-objects -L/usr/lib64  -Wl,--as-needed
CXX=g++ 
CXXFLAGS=-Wall -Wpointer-arith -Wendif-labels -Wmissing-format-attribute
-Wimplicit-fallthrough=3 -Wcast-function-type -Wformat-security
-fno-strict-aliasing -fwrapv -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2
-fstack-protector -funwind-tables -fasynchronous-unwind-tables
CLANG=/usr/bin/clang
BITCODE_CFLAGS= -fno-strict-aliasing -fwrapv -O2 
BITCODE_CXXFLAGS= -fno-strict-aliasing -fwrapv -O2 

make -C backend/jit/llvm all
[  655s] make[2]: Entering directory
'/home/abuild/rpmbuild/BUILD/postgresql-14.1/src/backend/jit/llvm'
[  655s] gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard
-Wno-format-truncation -Wno-stringop-truncation -O2 -g -m64 -fmessage-length=0
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables  -fPIC -D__STDC_LIMIT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_CONSTANT_MACROS -D_GNU_SOURCE -I/usr/include 
-I../../../../src/include  -D_GNU_SOURCE -I/usr/include/libxml2   -c -o
llvmjit.o llvmjit.c
[  655s] g++ -Wall -Wpointer-arith -Wendif-labels -Wmissing-format-attribute
-Wimplicit-fallthrough=3 -Wcast-function-type -Wformat-security
-fno-strict-aliasing -fwrapv -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2
-fstack-protector -funwind-tables -fasynchronous-unwind-tables -std=c++14 -fPIC
-D__STDC_LIMIT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_CONSTANT_MACROS
-D_GNU_SOURCE -I/usr/include  -I../../../../src/include  -D_GNU_SOURCE
-I/usr/include/libxml2   -c -o llvmjit_error.o llvmjit_error.cpp
[  656s] g++ -Wall -Wpointer-arith -Wendif-labels -Wmissing-format-attribute
-Wimplicit-fallthrough=3 -Wcast-function-type -Wformat-security
-fno-strict-aliasing -fwrapv -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2
-fstack-protector -funwind-tables -fasynchronous-unwind-tables -std=c++14 -fPIC
-D__STDC_LIMIT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_CONSTANT_MACROS
-D_GNU_SOURCE -I/usr/include  -I../../../../src/include  -D_GNU_SOURCE
-I/usr/include/libxml2   -c -o llvmjit_inline.o llvmjit_inline.cpp
[  656s] g++ -Wall -Wpointer-arith -Wendif-labels -Wmissing-format-attribute
-Wimplicit-fallthrough=3 -Wcast-function-type -Wformat-security
-fno-strict-aliasing -fwrapv -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2
-fstack-protector -funwind-tables -fasynchronous-unwind-tables -std=c++14 -fPIC
-D__STDC_LIMIT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_CONSTANT_MACROS
-D_GNU_SOURCE -I/usr/include  -I../../../../src/include  -D_GNU_SOURCE
-I/usr/include/libxml2   -c -o llvmjit_wrap.o llvmjit_wrap.cpp
[  659s] gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard
-Wno-format-truncation -Wno-stringop-truncation -O2 -g -m64 -fmessage-length=0
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables  -fPIC -D__STDC_LIMIT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_CONSTANT_MACROS -D_GNU_SOURCE -I/usr/include 
-I../../../../src/include  -D_GNU_SOURCE -I/usr/include/libxml2   -c -o
llvmjit_deform.o llvmjit_deform.c
[  660s] gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard
-Wno-format-truncation -Wno-stringop-truncation -O2 -g -m64 -fmessage-length=0
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables  -fPIC -D__STDC_LIMIT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_CONSTANT_MACROS -D_GNU_SOURCE -I/usr/include 
-I../../../../src/include  -D_GNU_SOURCE -I/usr/include/libxml2   -c -o
llvmjit_expr.o llvmjit_expr.c
[  662s] /usr/bin/clang -Wno-ignored-attributes -fno-strict-aliasing -fwrapv
-O2  -D__STDC_LIMIT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_CONSTANT_MACROS
-D_GNU_SOURCE -I/usr/include  -I../../../../src/include  -D_GNU_SOURCE
-I/usr/include/libxml2  -flto=thin 

[Bug c/103364] New: s390x: TLS reference in /usr/lib64/libLLVM.so mismatches non-TLS reference in /usr/lib64/libLLVM.so

[sarah.kriesch at opensuse dot org via Gcc-bugs]

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

Bug ID: 103364
   Summary: s390x: TLS reference in /usr/lib64/libLLVM.so
mismatches non-TLS reference in /usr/lib64/libLLVM.so
   Product: gcc
   Version: og11 (devel/omp/gcc-11)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sarah.kriesch at opensuse dot org
  Target Milestone: ---

We are building applications with gcc and LLVM at openSUSE and receiving these
problems with multiple packages, as PostgreSQL14 and Rust1.54:

Postgresql:
/usr/lib64/gcc/s390x-suse-linux/11/../../../../s390x-suse-linux/bin/ld:
@GLIBCXX_3.4.11: TLS reference in /usr/lib64/libLLVM.so mismatches non-TLS
reference in /usr/lib64/libLLVM.so
 /usr/lib64/gcc/s390x-suse-linux/11/../../../../s390x-suse-linux/bin/ld:
/usr/lib64/libLLVM.so: error adding symbols: bad value
 collect2: error: ld returned 1 exit status
make[2]: *** [../../../../src/Makefile.shlib:309: llvmjit.so] Error 1

Rust during the compilation of the rustc driver:
 Compiling rustc_driver v0.0.0
(/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/compiler/rustc_driver)
[15144s] error: linking with `cc` failed: exit status: 1
[15144s]   |
[15144s]   = note: "cc" "-Wl,--version-script=/tmp/rustcma3zqW/list"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.rustc_driver.crh42kxm-cgu.0.rcgu.o"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.rustc_driver.crh42kxm-cgu.1.rcgu.o"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.rustc_driver.crh42kxm-cgu.10.rcgu.o"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.rustc_driver.crh42kxm-cgu.11.rcgu.o"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.rustc_driver.crh42kxm-cgu.12.rcgu.o"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.rustc_driver.crh42kxm-cgu.13.rcgu.o"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.rustc_driver.crh42kxm-cgu.14.rcgu.o"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.rustc_driver.crh42kxm-cgu.15.rcgu.o"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.rustc_driver.crh42kxm-cgu.2.rcgu.o"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.rustc_driver.crh42kxm-cgu.3.rcgu.o"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.rustc_driver.crh42kxm-cgu.4.rcgu.o"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.rustc_driver.crh42kxm-cgu.5.rcgu.o"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.rustc_driver.crh42kxm-cgu.6.rcgu.o"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.rustc_driver.crh42kxm-cgu.7.rcgu.o"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.rustc_driver.crh42kxm-cgu.8.rcgu.o"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.rustc_driver.crh42kxm-cgu.9.rcgu.o"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps/rustc_driver-d0ee8343640437f6.4pgekasbeabawr2j.rcgu.o"
"-Wl,--as-needed" "-L"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/s390x-unknown-linux-gnu/release/deps"
"-L"
"/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/build/s390x-unknown-linux-gnu/stage1-rustc/release/deps"
"-L"

[Bug c++/103347] [9/10/11/12 Regression] Non-static data member initialization is erroneously allowed in C++03 with assignment to NULL

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #8)
> And grokdeclarator isn't called with the actual initializer (DEFERRED_PARSE)
> from which we could dig up the location of the first token.

True, though cp_parser_member_declaration has initializer_token_start which
carries the location of the '='.  I suppose we could add another location_t to
cp_declarator for init-declarators, and then just use it.

For which I have a patch:

$ ./cc1plus -quiet 103347.C -std=c++03 
103347.C:3:13: warning: non-static data member initializers only available with
‘-std=c++11’ or ‘-std=gnu++11’ [-Wc++11-extensions]
3 | void *x = NULL; //invalid in C++03 mode
  | ^

[Bug target/103074] [11/12 Regression] ICE in lra_assign, at lra-assigns.c:1649 since r11-5066-gbe39636d9f68c437

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

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

--- Comment #3 from Jakub Jelinek  ---
Ah, actually what I see is that sched1 swaps the order of:
(insn 22 21 23 4 (parallel [
(set (reg:SI 88)
(ashiftrt:SI (reg/v:SI 84 [ a ])
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) "pr103074.c":10:7 735 {*ashrsi3_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 23 22 24 4 (set (reg:SI 2 cx)
(reg/v:SI 84 [ a ])) "pr103074.c":10:7 77 {*movsi_internal}
 (expr_list:REG_DEAD (reg/v:SI 84 [ a ])
(nil)))
and doing a shift when cx is live isn't an option because the shift needs the
hard register for this shift amount (the constraints are Ic and I is 0..31
constant, c is %cx register).

[Bug tree-optimization/98953] Failure to optimize two reads from adjacent addresses into one

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

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

commit r12-5453-ga944b5dec3adb28ed199234d2116145ca9010d6a
Author: Roger Sayle 
Date:   Mon Nov 22 18:15:36 2021 +

tree-optimization/103345: Improved load merging.

This patch implements PR tree-optimization/103345 to merge adjacent
loads when combined with addition or bitwise xor.  The current code
in gimple-ssa-store-merging.c's find_bswap_or_nop alreay handles ior,
so that all that's required is to treat PLUS_EXPR and BIT_XOR_EXPR in
the same way at BIT_IOR_EXPR.  Many thanks to Andrew Pinski for
pointing out that this also resolves PR target/98953.

2021-11-22  Roger Sayle  

gcc/ChangeLog
PR tree-optimization/98953
PR tree-optimization/103345
* gimple-ssa-store-merging.c (find_bswap_or_nop_1): Handle
BIT_XOR_EXPR and PLUS_EXPR the same as BIT_IOR_EXPR.
(pass_optimize_bswap::execute): Likewise.

gcc/testsuite/ChangeLog
PR tree-optimization/98953
PR tree-optimization/103345
* gcc.dg/tree-ssa/pr98953.c: New test case.
* gcc.dg/tree-ssa/pr103345.c: New test case.

[Bug tree-optimization/103345] missed optimization: add/xor individual bytes to form a word

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

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

commit r12-5453-ga944b5dec3adb28ed199234d2116145ca9010d6a
Author: Roger Sayle 
Date:   Mon Nov 22 18:15:36 2021 +

tree-optimization/103345: Improved load merging.

This patch implements PR tree-optimization/103345 to merge adjacent
loads when combined with addition or bitwise xor.  The current code
in gimple-ssa-store-merging.c's find_bswap_or_nop alreay handles ior,
so that all that's required is to treat PLUS_EXPR and BIT_XOR_EXPR in
the same way at BIT_IOR_EXPR.  Many thanks to Andrew Pinski for
pointing out that this also resolves PR target/98953.

2021-11-22  Roger Sayle  

gcc/ChangeLog
PR tree-optimization/98953
PR tree-optimization/103345
* gimple-ssa-store-merging.c (find_bswap_or_nop_1): Handle
BIT_XOR_EXPR and PLUS_EXPR the same as BIT_IOR_EXPR.
(pass_optimize_bswap::execute): Likewise.

gcc/testsuite/ChangeLog
PR tree-optimization/98953
PR tree-optimization/103345
* gcc.dg/tree-ssa/pr98953.c: New test case.
* gcc.dg/tree-ssa/pr103345.c: New test case.

[Bug c++/103333] [accepts-invalid] function template argument deduction for incompatible 'transformed A' / 'deduced A' pair

[leni536 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Lénárd Szolnoki  ---
This can be turned into wrong-code.

C++11 example without includes:

```
template 
struct enable_if {};

template 
struct enable_if {
using type = T;
};

template 
using enable_if_t = typename enable_if::type;

template 
struct type_identity {
using type = T;
};

template 
using type_identity_t = typename type_identity::type;

template 
struct is_const {
static constexpr bool value = false;
};

template 
struct is_const {
static constexpr bool value = true;
};

template
struct S{
template::value>>
operator S() { return {}; }

operator int() { return 0; }
};

inline int f(int, int) {
return 1;
}

template
int f(S, b1>,
   S) {
return 2;
}

int main() {
S s1{};
S s2{};
return f(s1, s2); // returns 2, should return 1
}
```

https://godbolt.org/z/h8b75P7GK

[Bug target/103074] [11/12 Regression] ICE in lra_assign, at lra-assigns.c:1649 since r11-5066-gbe39636d9f68c437

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
The comment above ix86_hardreg_mov_ok doesn't match the implementation, it
doesn't prevent it before reload but before and during reload (LRA).  So I'd
have expected:
--- gcc/config/i386/i386.c  2021-11-22 10:07:01.336225481 +0100
+++ gcc/config/i386/i386.c  2021-11-22 18:54:22.288643063 +0100
@@ -19367,7 +19367,8 @@ ix86_hardreg_mov_ok (rtx dst, rtx src)
   ? standard_sse_constant_p (src, GET_MODE (dst))
   : x86_64_immediate_operand (src, GET_MODE (dst)))
   && ix86_class_likely_spilled_p (REGNO_REG_CLASS (REGNO (dst)))
-  && !reload_completed)
+  && !reload_completed
+  && !lra_in_progress)
 return false;
   return true;
 }
but, that doesn't really fix it and it is unclear what LRA is unhappy about to
me.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug testsuite/103264] [12 regression] gcc.dg/tree-prof/merge_block.c fails after r12-5236

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

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

[Bug c++/103363] confusing -Wnonnull-compare testing a reference argument for equality to null

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

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.3.0, 11.2.0, 12.0,
   ||6.5.0, 7.5.0, 8.5.0, 9.3.0
   Keywords||diagnostic

--- Comment #1 from Martin Sebor  ---
Both warnings started to be issued in GCC 6.

[Bug c++/103363] New: confusing -Wnonnull-compare testing a reference argument for equality to null

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

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

Bug ID: 103363
   Summary: confusing -Wnonnull-compare testing a reference
argument for equality to null
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Since the conversion of the address of a reference to bool is diagnosed by
-Waddress, issuing a second warning for it isn't necessary.  Mentioning
attribute nonnull where there is one in the source code seems confusing.

$ cat t.C && gcc -O2 -S -Wall t.C
struct S { int i; };

bool f (const S )
{
  return 
}
t.C: In function ‘bool f(const S&)’:
t.C:5:10: warning: the compiler can assume that the address of ‘s’ will never
be NULL [-Waddress]
5 |   return 
  |  ^~
t.C:3:18: note: ‘s’ declared here
3 | bool f (const S )
  | ~^
t.C:5:11: warning: ‘nonnull’ argument ‘s’ compared to NULL [-Wnonnull-compare]
5 |   return 
  |   ^


Clang issues just one warning (though the wording doesn't seem ideal either:
there's no evidence of dereferencing a null pointer so assuming that's what
necessarily led the programmer to the test doesn't seem warranted):
warning: reference cannot be bound to dereferenced null pointer in well-defined
C++ code; pointer may be assumed to always convert to true
[-Wundefined-bool-conversion]
  return 

[Bug c++/103329] [11/12 Regression] Code divergence in debug info with -fdump-tree-original since r11-291-g0f50f6daa140186a

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The problem seems that in order to print the *.original dump (but apparently
also in order to emit some warnings), we trigger:
#0  used_types_insert (t=) at
../../gcc/function.c:6422
#1  0x00c26eb6 in mark_used (decl=,
complain=0) at ../../gcc/cp/decl2.c:5681
#2  0x00dee6f0 in tsubst_qualified_id (qualified_id=, args=, complain=0, in_decl=, 
done=true, address_p=false) at ../../gcc/cp/pt.c:16460
#3  0x00e03d01 in tsubst_copy_and_build (t=,
args=, complain=0, in_decl=, 
function_p=false, integral_constant_expression_p=true) at
../../gcc/cp/pt.c:20046
#4  0x00e0041a in tsubst_expr (t=,
args=, complain=0, in_decl=, 
integral_constant_expression_p=true) at ../../gcc/cp/pt.c:19228
#5  0x00dd88cf in tsubst_template_arg (t=,
args=, complain=0, in_decl=)
at ../../gcc/cp/pt.c:12342
#6  0x00ddcca6 in tsubst_template_args (t=,
args=, complain=0, in_decl=)
at ../../gcc/cp/pt.c:13433
#7  0x00ddd9e7 in tsubst_aggr_type (t=, args=, complain=0, in_decl=, 
entering_scope=0) at ../../gcc/cp/pt.c:13637
#8  0x00deaa22 in tsubst (t=,
args=, complain=0, in_decl=)
at ../../gcc/cp/pt.c:15527
#9  0x00de7c32 in tsubst_decl (t=, args=, complain=0) at
../../gcc/cp/pt.c:14825
#10 0x00dea26e in tsubst (t=,
args=, complain=0, in_decl=)
at ../../gcc/cp/pt.c:15447
#11 0x00e0ac1c in instantiate_template_1 (tmpl=, orig_args=, complain=0)
at ../../gcc/cp/pt.c:21337
#12 0x00e0b2f2 in instantiate_template (tmpl=, orig_args=, complain=0)
at ../../gcc/cp/pt.c:21396
#13 0x00e0b466 in instantiate_alias_template (tmpl=, args=, complain=0) at
../../gcc/cp/pt.c:21434
#14 0x00dea49d in tsubst (t=,
args=, complain=0, in_decl=) at
../../gcc/cp/pt.c:15472
#15 0x00c2e7e1 in dump_template_bindings (pp=0x3e0c5a0
, parms=, args=,
typenames=0x7fffea1dbd98 = {...})
at ../../gcc/cp/error.c:482
#16 0x00c34a2f in dump_substitution (pp=0x3e0c5a0
, t=,
template_parms=, 
template_args=, flags=4) at
../../gcc/cp/error.c:1638
#17 0x00c365d1 in dump_function_decl (pp=0x3e0c5a0
, t=, flags=4) at
../../gcc/cp/error.c:1797
#18 0x00c33917 in dump_decl (pp=0x3e0c5a0 ,
t=, flags=4) at ../../gcc/cp/error.c:1369
#19 0x00c3cf88 in decl_as_string (decl=, flags=4) at ../../gcc/cp/error.c:3118
#20 0x00c3d060 in lang_decl_name (decl=, v=2, translate=false) at ../../gcc/cp/error.c:3153
#21 0x00e8b59f in cxx_printable_name_internal (decl=, v=2, translate=false) at ../../gcc/cp/tree.c:2678
#22 0x00e8b63c in cxx_printable_name (decl=, v=2) at ../../gcc/cp/tree.c:2687
#23 0x00f4f4c3 in c_genericize (fndecl=) at ../../gcc/c-family/c-gimplify.c:587
where when trying to print the pow decl into the dump file, we instantiate the
template and that
leads to adding the anonymous enum to types_used_by_cur_var_decl vector (or
attached to current function).
Later on we do in cp_finish_decl
8260/* So decl is a global variable or a static member of a
8261   non local class. Record the types it uses
8262   so that we can decide later to emit debug info for them.  */
8263record_types_used_by_current_var_decl (decl);
and attach those types to a random unrelated decl (a guard variable in this
case).
Similarly, without -fdump-tree-original and without -w, we trigger it during:
#0  used_types_insert (t=) at
../../gcc/function.c:6422
#1  0x00c26eb6 in mark_used (decl=,
complain=0) at ../../gcc/cp/decl2.c:5681
#2  0x00dee6f0 in tsubst_qualified_id (qualified_id=, args=, complain=0, in_decl=, 
done=true, address_p=false) at ../../gcc/cp/pt.c:16460
#3  0x00e03d01 in tsubst_copy_and_build (t=,
args=, complain=0, in_decl=, 
function_p=false, integral_constant_expression_p=true) at
../../gcc/cp/pt.c:20046
#4  0x00e0041a in tsubst_expr (t=,
args=, complain=0, in_decl=, 
integral_constant_expression_p=true) at ../../gcc/cp/pt.c:19228
#5  0x00dd88cf in tsubst_template_arg (t=,
args=, complain=0, in_decl=)
at ../../gcc/cp/pt.c:12342
#6  0x00ddcca6 in tsubst_template_args (t=,
args=, complain=0, in_decl=)
at ../../gcc/cp/pt.c:13433
#7  0x00ddd9e7 in tsubst_aggr_type (t=, args=, complain=0, in_decl=, 
entering_scope=0) at ../../gcc/cp/pt.c:13637
#8  0x00deaa22 in tsubst (t=,
args=, complain=0, in_decl=)
at ../../gcc/cp/pt.c:15527
#9  0x00de7c32 in tsubst_decl (t=, args=, complain=0) at
../../gcc/cp/pt.c:14825
#10 0x00dea26e in tsubst (t=,
args=, complain=0, in_decl=)
at ../../gcc/cp/pt.c:15447
#11 0x00e0ac1c in 

[Bug c++/103362] New: -m option is not ignored when is immediately preceded by -o option

[egor_suvorov at mail dot ru via Gcc-bugs]

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

Bug ID: 103362
   Summary: -m option is not ignored when is immediately preceded
by -o option
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egor_suvorov at mail dot ru
  Target Milestone: ---

Here is an issue that one of my students encountered today:
https://stackoverflow.com/questions/70069809/unrecognized-emulation-mode-ain-when-compiling-with-gcc-on-ubuntu/70069810

Consider any simple C++ program in a file named `main.cpp`. I compile it with
`g++ main.cpp -o main`, but I accidentally add a dash before `main`:

g++ main.cpp -o -main

Expected behavior: the program is compiled to a file named `-main`.

Real behavior:
/usr/bin/ld: unrecognised emulation mode: ain
Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu elf_l1om
elf_k1om i386pep i386pe
collect2: error: ld returned 1 exit status

My understanding: GCC treats `-main` as both `-m` option (targeting some
unexisting `ain` architecture) AND name for the output file.

For example, on my 64-bit Ubuntu I can write

g++ main.cpp -o -melf_x86_64

and it will produce a binary named `-melf_x86_64`. However, the following
command fails because I don't have 32-bit standard library installed:

g++ main.cpp -o -melf_i386

yields:

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/9/libstdc++.so
when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/9/libstdc++.a
when searching for -lstdc++
/usr/bin/ld: cannot find -lstdc++
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.so when
searching for -lm
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.a when searching
for -lm
/usr/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libm.so when searching
for -lm
/usr/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libm.a when searching
for -lm
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.so when
searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.a when
searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.so when
searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.a when
searching for -lm
/usr/bin/ld: cannot find -lm
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libgcc_s.so.1 when
searching for libgcc_s.so.1
/usr/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libgcc_s.so.1 when
searching for libgcc_s.so.1
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 when
searching for libgcc_s.so.1
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a
when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
collect2: error: ld returned 1 exit status

I suspect some other options may be be affected as well. `-m` here is special
only because `main` start with `m`.

Being able to read the option in two different ways simultaneously looks like a
bug in my world.

I can reproduce the behavior on a wide range of OSes: msys2 on Windows 10 (g++
11.2.0), g++ 9.3.0 on 64-bit Ubuntu 20.04.3 LTS, as well as trunk version on
Godbolt.

[Bug tree-optimization/103361] [12 Regression] ICE in adjust_unroll_factor, at gimple-loop-jam.c:407 since r12-3677-gf92901a508305f29

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |12.0
Summary|[12 Regression] ICE in  |[12 Regression] ICE in
   |adjust_unroll_factor, at|adjust_unroll_factor, at
   |gimple-loop-jam.c:407   |gimple-loop-jam.c:407 since
   ||r12-3677-gf92901a508305f29
  Known to fail||12.0
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Last reconfirmed||2021-11-22
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Thanks for the report, started with r12-3677-gf92901a508305f29

[Bug c++/96507] missing -Waddress for member references

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

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|Feature request: improve|missing -Waddress for
   |"-Waddress" (or equivalent) |member references
   |for function references |
   |inside structs  |
 CC||msebor at gcc dot gnu.org
   Last reconfirmed||2021-11-22

--- Comment #1 from Martin Sebor  ---
Confirmed with GCC 12.  Since the warning is issued for non-member references
(the first case below) but not for members (the second case) I would consider
this a bug rather than an enhancement request.

$ cat pr96507.C && gcc -S -Wall pr96507.C
typedef void F ();

extern F 
extern int 

bool gfun ()
{
  return  != 0;   // -Waddress (expected)
}

bool gvar ()
{
  return  != 0;   // -Waddress (expected)
}


struct S
{
  F 
  int 
};

extern S s;

bool hfun ()
{
  return  != 0; // missing warning
}

bool hvar ()
{
  return  != 0; // missing warning
}

pr96507.C: In function ‘bool gfun()’:
pr96507.C:8:14: warning: the compiler can assume that the address of ‘fr’ will
never be NULL [-Waddress]
8 |   return  != 0;   // -Waddress (expected)
  |  ^~~~
pr96507.C:3:11: note: ‘fr’ declared here
3 | extern F 
  |   ^~
pr96507.C: In function ‘bool gvar()’:
pr96507.C:13:14: warning: the compiler can assume that the address of ‘ir’ will
never be NULL [-Waddress]
   13 |   return  != 0;   // -Waddress (expected)
  |  ^~~~
pr96507.C:4:13: note: ‘ir’ declared here
4 | extern int 
  | ^~

[Bug tree-optimization/103361] New: ICE in adjust_unroll_factor, at gimple-loop-jam.c:407

[vsevolod.livinskij at frtk dot ru via Gcc-bugs]

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

Bug ID: 103361
   Summary: ICE in adjust_unroll_factor, at gimple-loop-jam.c:407
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

Link to the Compiler Explorer: https://godbolt.org/z/jbKEn7Tdq

Reproducer:
char a, b;
extern unsigned short c[];
extern bool d[];
const unsigned short (const unsigned short , const unsigned short ) {
  if (g < f)
return g;
  return f;
}
void k() {
  for (int h = 0; b; h += 3)
for (unsigned long i = 0; i < 11104842004558084287ULL;
 i += -11104842004558084300ULL)
  for (bool j(e(6, e(6, c[h + i]))); j < (bool)a; j = 7)
d[7] = 0;
}

Error:
>$ g++ -O3 -c func.cpp
during GIMPLE pass: unrolljam
func.cpp: In function 'void k()':
func.cpp:9:6: internal compiler error: in adjust_unroll_factor, at
gimple-loop-jam.c:407
9 | void k() {
  |  ^
0x93ebce adjust_unroll_factor
/testing/gcc/gcc_src_master/gcc/gimple-loop-jam.c:407
0x93ebce tree_loop_unroll_and_jam
/testing/gcc/gcc_src_master/gcc/gimple-loop-jam.c:551
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

gcc version 12.0.0 20211121 (8fef6f720a5a0a056abfa986ba870bb406ab4716) (GCC)

[Bug c++/103347] [9/10/11/12 Regression] Non-static data member initialization is erroneously allowed in C++03 with assignment to NULL

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Perhaps a faster way to fix this would be to try to warn on the = token rather
than on input_location which happens to be the location of NULL after
cp_parser_cache_defarg went through it.
For
struct test {
int x = 1 + 2; //invalid in C++03 mode
};
we strangely warn with caret on the 2, for int x = (1 + 2); with caret on )
etc.
maybe_warn_cpp0x doesn't really take a location_t though, probably it should.
And grokdeclarator isn't called with the actual initializer (DEFERRED_PARSE)
from which we could dig up the location of the first token.

[Bug c/103343] Invalid codegen when comparing pointer to one past the end and then dereferencing that pointer

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
(In reply to Gabriel Ravier from comment #0)
> PS: This also results in plenty of invalid warnings when compiling with
> -Wall:
> 
> : In function 'f':
> :6:9: warning: array subscript 1 is outside array bounds of 'int[1]'
> [-Warray-bounds]
> 6 | *p = 2;
>   | ^~
> :1:12: note: at offset 4 into object 'x' of size 4
> 1 | extern int x[1], y;
>   |^

The warning in this case is valid and helpful: it's undefined to attempt to
access an object using a pointer derived from a pointer to an unrelated object
(the equality between pointers to adjacent objects notwithstanding).

[Bug c++/101731] [9/10/11 Regression] ICE in cp_parser_skip_to_pragma_eol, at cp/parser.c:4055

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE in
   |in  |cp_parser_skip_to_pragma_eo
   |cp_parser_skip_to_pragma_eo |l, at cp/parser.c:4055
   |l, at cp/parser.c:4055  |

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/101731] [9/10/11/12 Regression] ICE in cp_parser_skip_to_pragma_eol, at cp/parser.c:4055

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

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

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

https://gcc.gnu.org/g:1aedb3920a45bfe75db4514502b4e7f83e108f63

commit r12-5451-g1aedb3920a45bfe75db4514502b4e7f83e108f63
Author: Jakub Jelinek 
Date:   Mon Nov 22 17:06:12 2021 +0100

openacc: Fix up C++ #pragma acc routine handling [PR101731]

The following testcase ICEs because two function declarations are nested in
each other and the acc routine handling code isn't prepared to put the
pragma on both.

The fix is similar to what #pragma omp declare {simd,variant} does,
in particular set the fndecl_seen flag already in cp_parser_late_parsing*
when we encounter it rather than only after we finalize it.

In cp_finalize_oacc_routine I had to move the fndecl_seen diagnostics to
non-FUNCTION_DECL block, because for FUNCTION_DECLs the flag is already
known to be set from cp_parser_late_parsing_oacc_routine, but can't be
removed altogether, because that regresses quality of 2 goacc/routine-5.c
diagnostics - we drop "a single " from the
'#pragma acc routine' not immediately followed by a single function
declaration or definition
diagnostic say on
 #pragma acc routine
 int foo (), b;
if we drop it altogether.

2021-11-22  Jakub Jelinek  

PR c++/101731
* parser.c (cp_parser_late_parsing_oacc_routine): Set
parser->oacc_routine->fndecl_seen here, rather than ...
(cp_finalize_oacc_routine): ... here.  Don't error if
parser->oacc_routine->fndecl_seen is set for FUNCTION_DECLs.

* c-c++-common/goacc/routine-6.c: New test.