[Bug fortran/104328] [12 Regression] ICE in resolve_omp_atomic, at fortran/openmp.cc:7760 (etc.) since r12-5793-g689407ef916503b2

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

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

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

https://gcc.gnu.org/g:54d21dd5b5c5c5539505b3e037cdecb3b0ab3918

commit r12-7011-g54d21dd5b5c5c5539505b3e037cdecb3b0ab3918
Author: Jakub Jelinek 
Date:   Thu Feb 3 09:01:07 2022 +0100

openmp, fortran: Improve !$omp atomic checks [PR104328]

The testcase shows some cases that weren't verified and we ICE on
invalid because of that.
One problem is that unlike before, we weren't checking if some expression
is EXPR_VARIABLE with non-NULL symtree in the case where there was
a conversion around it.
The other two issues is that we check that in an IF ->block is non-NULL
and then immediately dereference ->block->next->op, but on invalid
code with no statements in the then clause ->block->next might be NULL.

2022-02-02  Jakub Jelinek  

PR fortran/104328
* openmp.cc (is_scalar_intrinsic_expr): If must_be_var && conv_ok
and expr is conversion, verify it is a conversion from
EXPR_VARIABLE
with non-NULL symtree.  Check ->block->next before dereferencing
it.

* gfortran.dg/gomp/atomic-27.f90: New test.

[Bug fortran/104328] [12 Regression] ICE in resolve_omp_atomic, at fortran/openmp.cc:7760 (etc.) since r12-5793-g689407ef916503b2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed, thanks for the report.

[Bug libstdc++/104361] New: Biased Reference Counting for the standard library

[antoshkka at gmail dot com via Gcc-bugs]

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

Bug ID: 104361
   Summary: Biased Reference Counting for the standard library
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

There's a research named "Biased Reference Counting: Minimizing Atomic
Operations in Garbage Collection" that shows how to speed up reference counting
for some platforms for more than 20%
https://dl.acm.org/doi/pdf/10.1145/3243176.3243195 . 

The research does not talk about speedup of C++ but it is based on an
observation that most objects are only accessed by a single thread, which
allows most RC operations to be performed non-atomically. That observation fits
std::shared_ptr usage patterns.

Such a change seems to be an ABI break for shared_ptr, however may be it could
be used for stop_token and other new reference counted types.

[Bug target/104362] New: ICE in ix86_expand_epilogue, at config/i386/i386.c:9362 since r12-3433-ga25e0b5e6ac8a77a

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

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

Bug ID: 104362
   Summary: ICE in ix86_expand_epilogue, at
config/i386/i386.c:9362 since
r12-3433-ga25e0b5e6ac8a77a
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: qing.zhao at oracle dot com, rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu

The following ICEs since -ftrivial-auto-var-init=pattern was introduced:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/eh_return-1.c
-mavx512f -m32 -ftrivial-auto-var-init=pattern
during RTL pass: pro_and_epilogue
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/eh_return-1.c: In
function ‘_Unwind_RaiseException’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/eh_return-1.c:22:1:
internal compiler error: in ix86_expand_epilogue, at config/i386/i386.cc:9441
   22 | }
  | ^
0x1a585ef ix86_expand_epilogue(int)
/home/marxin/Programming/gcc/gcc/config/i386/i386.cc:9441
0x22a667a gen_split_487(rtx_insn*, rtx_def**)
/home/marxin/Programming/gcc/gcc/config/i386/i386.md:15561
0x2a59f29 split_insns(rtx_def*, rtx_insn*)
/home/marxin/Programming/gcc/gcc/config/i386/i386.md:15561
0xed9d97 try_split(rtx_def*, rtx_insn*, int)
/home/marxin/Programming/gcc/gcc/emit-rtl.cc:3795
0xfe18b3 thread_prologue_and_epilogue_insns()
/home/marxin/Programming/gcc/gcc/function.cc:6091
0xfe27dc rest_of_handle_thread_prologue_and_epilogue
/home/marxin/Programming/gcc/gcc/function.cc:6532
0xfe2a00 execute
/home/marxin/Programming/gcc/gcc/function.cc:6608
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #6 from rguenther at suse dot de  ---
On Thu, 3 Feb 2022, pinskia at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356
> 
> --- Comment #4 from Andrew Pinski  ---
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Richard Biener from comment #2)
> > > Of course integer division might be special enough to single out as IIRC
> > > all CPUs trap on that (I'm sure somebody knows one that does not...).
> > 
> > MIPS backend adds the trap (it can be turned off by a backend flag).
> > AARCH64 and PowerPC don't trap either.
> 
> The Java front-end used to have option which caused the front-end to emit the
> throw/trap for the division by zero which was turned off for a few targets (I
> can't remember if it was a hook or hard coded).

I suppose a set of [us]div_trap_on_zero patterns could be used to
merge a conditional trap with division during combine if we want to go
there.  But that suggests that if in Ada integer divide by zero is
something the language standard mandates special behavior for then
either the frontend (with help from the middle-end) or the
middle-end (by singling out integer division with -fnon-call-exceptions)
needs to make the operation well-defined - preferably in an explicit way.
These days we'd probably add IFN_TRUNC_DIV_OR_TRAP for this purpose.

I don't mind guarding the pattern for GCC 12 though, but I'd like
to clarify the semantic questions raised here.

[Bug target/104362] [12 Regression] ICE in ix86_expand_epilogue, at config/i386/i386.c:9362

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE in  |[12 Regression] ICE in
   |ix86_expand_epilogue, at|ix86_expand_epilogue, at
   |config/i386/i386.c:9362 |config/i386/i386.c:9362
   |since   |
   |r12-3433-ga25e0b5e6ac8a77a  |
   Keywords||ice-on-valid-code,
   ||needs-bisection
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-02-03
 Ever confirmed|0   |1
   Target Milestone|--- |12.0

--- Comment #1 from Andrew Pinski  ---
Reduced testcase without ftrivial-auto-var-init.


struct _Unwind_Context
{
  void *ra;
  char array[48];
};

extern long uw_install_context_1 (struct _Unwind_Context *);

void
_Unwind_RaiseException (void)
{
  struct _Unwind_Context this_context, cur_context;
  __builtin_memset(&this_context, 55, sizeof(this_context));
  long offset = uw_install_context_1 (&this_context);
  __builtin_memcpy (&this_context, &cur_context,
sizeof (struct _Unwind_Context));
  void *handler = __builtin_frob_return_addr ((&cur_context)->ra);
  uw_install_context_1 (&cur_context);
  __builtin_eh_return (offset, handler);
}

--- CUT ---
The options used with the above is just "-mavx512f -m32".

[Bug analyzer/104247] Compiler warnings on 32-bit system

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

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

--- Comment #5 from Martin Liška  ---
/home/marxin/Programming/gcc/gcc/analyzer/region-model-manager.cc: In
instantiation of ‘void ana::log_uniq_map(ana::logger*, bool, const char*, const
hash_map&) [with K = tree_node*; T = ana::string_region]’:
/home/marxin/Programming/gcc/gcc/analyzer/region-model-manager.cc:1684:16:  
required from here
/home/marxin/Programming/gcc/gcc/analyzer/region-model-manager.cc:1595:26:
warning: unknown conversion type character ‘z’ in format [-Wformat=]
 1595 |   logger->log ("  # %s: %zu", title, uniq_map.elements ());
  |  ^
/home/marxin/Programming/gcc/gcc/analyzer/region-model-manager.cc:1595:16:
warning: too many arguments for format [-Wformat-extra-args]
 1595 |   logger->log ("  # %s: %zu", title, uniq_map.elements ());
  |^

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e

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

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

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

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

commit r12-7012-gde67f943b858099b40f73632a51e66147ec79c9b
Author: Jakub Jelinek 
Date:   Thu Feb 3 09:45:16 2022 +0100

ranger: Fix up wi_fold_in_parts for small precision types [PR104334]

The wide-int.h templates expect that when an int/long etc. operand is used
it will be sign-extended based on the types precision.
wi_fold_in_parts passes 3 such non-zero constants to wi::lt_p, wi::gt_p
and wi::eq_p - 1, 3 and 4, which means it was doing weird things if either
some of 1, 3 or 4 weren't representable in type, or if type was unsigned 3
bit
type 4 should be written as -4.
The following patch promotes the subtraction operands to widest_int and
uses that as the type for ?h_range variables and compares them as such.
We don't need the overflow handling because there is never an overflow.

2022-02-02  Jakub Jelinek  

PR tree-optimization/104334
* range-op.cc (range_operator::wi_fold_in_parts): Change lh_range
and rh_range type to widest_int and subtract in widest_int.  Remove
ov_rh, ov_lh and sign vars, always perform comparisons as signed
and use >, < and == operators for it.

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

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/104327] [12 Regression] Inlining error on s390x since r12-1039

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
(In reply to Andreas Krebbel from comment #5)
> Yes, that's the right fix I think. Thanks!
> MVCLE is a shorter version of a loop doing MVCs but has some startup
> overhead.

I would factor it out a bit:

diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index 2db12d4ba4b..95351c8a002 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -16105,8 +16105,10 @@ s390_can_inline_p (tree caller, tree callee)
   struct cl_target_option *callee_opts = TREE_TARGET_OPTION (callee_tree);
   bool ret = true;

-  if ((caller_opts->x_target_flags & ~(MASK_SOFT_FLOAT | MASK_HARD_DFP))
-  != (callee_opts->x_target_flags & ~(MASK_SOFT_FLOAT | MASK_HARD_DFP)))
+  unsigned HOST_WIDE_INT inline_safe_mask
+= MASK_SOFT_FLOAT | MASK_HARD_DFP | MASK_MVCLE;
+  if ((caller_opts->x_target_flags & ~inline_safe_mask)
+  != (callee_opts->x_target_flags & ~inline_safe_mask))
 ret = false;

   /* Don't inline functions to be compiled for a more recent arch into a

@Andreas: Can you please add a test case for it, test it and finish the patch?
Thanks.

[Bug target/104362] [12 Regression] ICE in ix86_expand_epilogue, at config/i386/i386.c:9362 since r12-3117-g6e5401e87d02919b

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

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
   Keywords|needs-bisection |
Summary|[12 Regression] ICE in  |[12 Regression] ICE in
   |ix86_expand_epilogue, at|ix86_expand_epilogue, at
   |config/i386/i386.c:9362 |config/i386/i386.c:9362
   ||since
   ||r12-3117-g6e5401e87d02919b
 CC||hjl.tools at gmail dot com

--- Comment #2 from Martin Liška  ---
Started with r12-3117-g6e5401e87d02919b.

[Bug target/104327] [12 Regression] Inlining error on s390x since r12-1039

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

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

--- Comment #7 from Jakub Jelinek  ---
The testcase should be in a generic directory, so that we catch it on other
targets too.

Note, e.g. i386/ can_inline_p hook is quite different from this one.
E.g. for the ISA options it allows the caller to have a superset of the ISAs:
  /* Callee's isa options should be a subset of the caller's, i.e. a SSE4
 function can inline a SSE2 function but a SSE2 function can't inline
 a SSE4 function.  */
  if (((caller_opts->x_ix86_isa_flags & callee_opts->x_ix86_isa_flags)
   != callee_opts->x_ix86_isa_flags)
  || ((caller_opts->x_ix86_isa_flags2 & callee_opts->x_ix86_isa_flags2)
  != callee_opts->x_ix86_isa_flags2))
ret = false;
which is heavily relied on (e.g. most of the intrinsics have some ISA and
we allow inlining if the caller supports those), takes into account whether
it always_inline callee, etc.  Now, s390 does something like that e.g. with the
arch.

target_flags seem to be a mixed bag of features:
#define MASK_64BIT (1U << 0)
#define MASK_BACKCHAIN (1U << 1)
#define MASK_DEBUG_ARG (1U << 2)
#define MASK_ZARCH (1U << 3)
#define MASK_HARD_DFP (1U << 4)
#define MASK_SOFT_FLOAT (1U << 5)
#define MASK_OPT_HTM (1U << 6)
#define MASK_LONG_DOUBLE_128 (1U << 7)
#define MASK_MVCLE (1U << 8)
#define MASK_PACKED_STACK (1U << 9)
#define MASK_SMALL_EXEC (1U << 10)
#define MASK_OPT_VX (1U << 11)
#define MASK_ZVECTOR (1U << 12)

I'd say e.g. OPT_VX or OPT_HTM seem to me like ISA flags that could be treated
that way, MVCLE is an tuning option from what I understand (s390 doesn't check
*_tune at all, maybe it could for non-always_inline?), e.g. 64BIT or
LONG_DOUBLE_128 seems to be an ABI option so any changes should make code
uninlinable, ...

[Bug c++/104347] internal compiler error- default template arguments - missing angle brackets

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

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

Martin Liška  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102479
 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Fixed on master with r12-3906-g51018dd1395c72b3.

[Bug c++/104347] internal compiler error- default template arguments - missing angle brackets

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
This is an exact dup of bug 102479.
See bug 102479 comment #2 about the alias part.
So yes this is valid code.

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

[Bug c++/102479] segfault when deducing class template arguments for tuple with libc++-14

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dev at gutoehrlein dot eu

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

[Bug c++/104347] internal compiler error- default template arguments - missing angle brackets

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

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

--- Comment #5 from Andrew Pinski  ---
Oh clang does not implement alias deduction even in C++20 mode. So yes this is
still valid C++20.

[Bug c++/104302] [12 Regression] ICE Segmentation fault since r12-6825-g2da90ad39bf8fa9e

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

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

m.cencora at gmail dot com changed:

   What|Removed |Added

 CC||m.cencora at gmail dot com

--- Comment #4 from m.cencora at gmail dot com ---
FWIW sometimes array size deduction fails even if init-list is not dependent,
see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93259

[Bug libstdc++/104361] Biased Reference Counting for the standard library

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

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

--- Comment #1 from Jonathan Wakely  ---
Thanks for the link.

[Bug target/104362] [12 Regression] ICE in ix86_expand_epilogue, at config/i386/i386.c:9362 since r12-3117-g6e5401e87d02919b

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Uroš Bizjak  ---
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index ad5a5caa413..a61a5390127 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -7403,6 +7403,10 @@ find_drap_reg (void)
  || crtl->tail_call_emit)
return DI_REG;

+  if (crtl->calls_eh_return
+ && REGNO (EH_RETURN_STACKADJ_RTX) == CX_REG)
+   return DI_REG;
+
   /* Reuse static chain register if it isn't used for parameter
  passing.  */
   if (ix86_function_regparm (TREE_TYPE (decl), decl) <= 2)

[Bug target/104327] [12 Regression] Inlining error on s390x since r12-1039

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

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

--- Comment #8 from Andreas Krebbel  ---
I will work on a patch. Thanks for the hint!

I agree for HTM. VX is an ABI switch since it changes the calling conventions
for vector types.

[Bug target/104362] [12 Regression] ICE in ix86_expand_epilogue, at config/i386/i386.c:9362 since r12-3117-g6e5401e87d02919b

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Uroš Bizjak  ---
Or simply:

--cut here--
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index ad5a5caa413..dd5584fb8ed 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -7400,7 +7400,8 @@ find_drap_reg (void)
 register in such case.  */
   if (DECL_STATIC_CHAIN (decl)
  || cfun->machine->no_caller_saved_registers
- || crtl->tail_call_emit)
+ || crtl->tail_call_emit
+ || crtl->calls_eh_return)
return DI_REG;

   /* Reuse static chain register if it isn't used for parameter
--cut here--

[Bug c/104363] New: hppa: __asm__ directive .global and multiple .symver not supported

[mathieu.malaterre at gmail dot com via Gcc-bugs]

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

Bug ID: 104363
   Summary: hppa: __asm__ directive .global and multiple .symver
not supported
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mathieu.malaterre at gmail dot com
  Target Milestone: ---

It looks like there is a regression on gcc/11 branch on hppa.

Steps using gcc-10 (Debian/buster):

% sudo apt-get install g++-hppa-linux-gnu
% wget http://www.chronox.de/libkcapi/libkcapi-1.3.1.tar.xz
% tar xf libkcapi-1.3.1.tar.xz
% cd libkcapi-1.3.1
% autoreconf -i
% ./configure  --host=hppa-linux-gnu  --build=x86_64-linux-gnu 
--enable-kcapi-rngapp
% make -j8

=> success !

Compare now on Debian/sid:

% sudo apt-get install g++-hppa-linux-gnu
% wget http://www.chronox.de/libkcapi/libkcapi-1.3.1.tar.xz
% tar xf libkcapi-1.3.1.tar.xz
% cd libkcapi-1.3.1
% autoreconf -i
% ./configure  --host=hppa-linux-gnu  --build=x86_64-linux-gnu 
--enable-kcapi-rngapp
% make -j8
/bin/bash ./libtool  --tag=CC   --mode=link hppa-linux-gnu-gcc  -g -O2 -fpie
-fPIE -DPIE -Wl,-z,relro,-z,now -pie -o bin/kcapi-rng
apps/bin_kcapi_rng-kcapi-rng.o apps/bin_kcapi_rng-app-internal.o libkcapi.la
libtool: link: hppa-linux-gnu-gcc -g -O2 -fpie -fPIE -DPIE -Wl,-z -Wl,relro
-Wl,-z -Wl,now -pie -o bin/.libs/kcapi-rng apps/bin_kcapi_rng-kcapi-rng.o
apps/bin_kcapi_rng-app-internal.o  ./.libs/libkcapi.so
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
apps/bin_kcapi_rng-kcapi-rng.o: in function `main':
/tmp/libkcapi-1.3.1/apps/kcapi-rng.c:302: undefined reference to
`kcapi_rng_generate'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
/tmp/libkcapi-1.3.1/apps/kcapi-rng.c:328: undefined reference to
`kcapi_memset_secure'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
/tmp/libkcapi-1.3.1/apps/kcapi-rng.c:332: undefined reference to
`kcapi_memset_secure'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
/tmp/libkcapi-1.3.1/apps/kcapi-rng.c:328: undefined reference to
`kcapi_memset_secure'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
/tmp/libkcapi-1.3.1/apps/kcapi-rng.c:328: undefined reference to
`kcapi_memset_secure'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_aead_stream_init_enc'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_cipher_stream_init_enc'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_cipher_stream_init_dec'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_cipher_encrypt'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_md_final'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_pbkdf'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_cipher_stream_op'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_cipher_decrypt'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_aead_stream_op'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_aead_stream_update_last'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_aead_stream_init_dec'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_md_digest'
collect2: error: ld returned 1 exit status
make: *** [Makefile:953: bin/kcapi-rng] Error 1
make: *** Waiting for unfinished jobs
rm /tmp/tmp.b3eRUtQTiC

[Bug target/104363] hppa: __asm__ directive .global and multiple .symver not supported

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Target||hppa-linux-gnu
 Status|UNCONFIRMED |WAITING
  Component|c   |target
   Last reconfirmed||2022-02-03

--- Comment #1 from Andrew Pinski  ---
What binutils version is being used are they different?
Are you sure this is not a bug in binutils since that is what processes symver
assembly.

[Bug c++/104359] GCC Treats bool with value != 1 as falsey when picking branches

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Will Usher from comment #0)
> However, b's "value" is 255, which should evaluate to "true".

No. The only valid values of bool are true and false. If you set its bits to
some other value representation which does not correspond to either the 'true'
value or the 'false' value, you do not have an object of type bool, you have
garbage.

It's possible that a C++ implementation would use 0x for one of true or
false, in which case your memcpy would be valid. But that's not the case for
GCC.

[Bug target/104363] hppa: __asm__ directive .global and multiple .symver not supported

[mathieu.malaterre at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mathieu Malaterre  ---
I've downgraded binutils to version from bullseye, and I am getting the exact
same symptoms:

```
libtool: link: ( cd ".libs" && rm -f "libkcapi.la" && ln -s "../libkcapi.la"
"libkcapi.la" )
/bin/bash ./libtool  --tag=CC   --mode=link hppa-linux-gnu-gcc  -g -O2 -fpie
-fPIE -DPIE -Wl,-z,relro,-z,now -pie -o bin/kcapi-rng
apps/bin_kcapi_rng-kcapi-rng.o apps/bin_kcapi_rng-app-internal.o libkcapi.la
libtool: link: hppa-linux-gnu-gcc -g -O2 -fpie -fPIE -DPIE -Wl,-z -Wl,relro
-Wl,-z -Wl,now -pie -o bin/.libs/kcapi-rng apps/bin_kcapi_rng-kcapi-rng.o
apps/bin_kcapi_rng-app-internal.o  ./.libs/libkcapi.so
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
apps/bin_kcapi_rng-kcapi-rng.o: in function `main':
/tmp/libkcapi-1.3.1/apps/kcapi-rng.c:302: undefined reference to
`kcapi_rng_generate'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
/tmp/libkcapi-1.3.1/apps/kcapi-rng.c:328: undefined reference to
`kcapi_memset_secure'
```

 % apt-cache policy binutils-hppa-linux-gnu
binutils-hppa-linux-gnu:
  Installed: 2.35.2-2
  Candidate: 2.37.90.20220130-2
  Version table:
 2.37.90.20220130-2 500
500 http://deb.debian.org/debian sid/main amd64 Packages
 *** 2.35.2-2 100
100 /var/lib/dpkg/status

[Bug target/104363] hppa: __asm__ directive .global and multiple .symver not supported

[mathieu.malaterre at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Mathieu Malaterre  ---
Original description states:

> Steps using gcc-10 (Debian/buster):

This is a typo, it should states:

> Steps using gcc-10 (Debian/bullseye):

[Bug target/104364] New: [12 Regression] OpenMP/nvptx regressions after "[nvptx] Add some support for .local atomics"

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

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

Bug ID: 104364
   Summary: [12 Regression] OpenMP/nvptx regressions after
"[nvptx] Add some support for .local atomics"
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: vries at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

As we've (slightly) discussed before, I acknowledge that commit
r12-6966-ge0451f93d9faa13495132f4e246e9bef30b51417 "[nvptx] Add some support
for .local atomics" is a good idea, thanks!  (Though I wonder, wouldn't it be
possible for the Driver/JIT to handle that internally?  Aha, you had the same
comment; first sentence in
.)

For certain GPU/Driver combinations, this change however causes regressions in
OpenMP/nvptx testing:

PASS: libgomp.c/../libgomp.c-c++-common/for-11.c (test for excess errors)
[-PASS:-]{+WARNING: program timed out.+}
{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-11.c execution test

PASS: libgomp.c/../libgomp.c-c++-common/for-12.c (test for excess errors)
[-PASS:-]{+WARNING: program timed out.+}
{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-12.c execution test

PASS: libgomp.c/../libgomp.c-c++-common/for-3.c (test for excess errors)
[-PASS:-]{+WARNING: program timed out.+}
{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-3.c execution test

PASS: libgomp.c/../libgomp.c-c++-common/for-5.c (test for excess errors)
[-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-5.c execution test

PASS: libgomp.c/../libgomp.c-c++-common/for-6.c (test for excess errors)
[-PASS:-]{+WARNING: program timed out.+}
{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-6.c execution test

PASS: libgomp.c/../libgomp.c-c++-common/for-9.c (test for excess errors)
[-PASS:-]{+WARNING: program timed out.+}
{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-9.c execution test

But varying, not always all of these.

Sometimes with, sometimes without the timeout.

Similar for C++.

... but only seen regressing for:

  - Nvidia Tesla K20c, Driver Version: 346.46
  - Nvidia Tesla K20c, Driver Version: 455.38
  - Nvidia Tesla K40c, Driver Version: 455.38
  - Nvidia Tesla K80, Driver Version: 440.33.01

... and never seen regressing for:

  - Nvidia Quadro P1000, Driver Version: 450.119.03
  - Nvidia GeForce GTX 1080, Driver Version: 440.33.01
  - Nvidia TITAN V, Driver Version: 455.23.05

(What is the underlying characteristic here?)


I did notice that this change affects nvptx target libraries -- but OpenMP
'mgomp' multilib only -- as follows:

'nvptx-none/mgomp/libatomic/cas_1_.o' (complete diff):

@@ -113,7 +113,7 @@
 .loc 3 80 9
 or.b64 %r61,%r60,%r39;
 .loc 3 82 11
-@ %r71 atom.cas.b64 %r62,[%r35],%r29,%r61;
+atom.cas.b64 %r62,[%r35],%r29,%r61;
 mov.b64 {%r69,%r70},%r62;
 shfl.idx.b32 %r69,%r69,%r68,31;
 shfl.idx.b32 %r70,%r70,%r68,31;

Similar for 'nvptx-none/mgomp/libatomic/cas_2_.o'.

'nvptx-none/mgomp/libatomic/cas_4_.o' (complete diff):

@@ -50,9 +50,9 @@
 mov.u32 %r25,%ar2;
 .loc 2 41 12
 ld.u32 %r28,[%r24];
-@ %r37 membar.sys;
-@ %r37 atom.cas.b32 %r29,[%r23],%r28,%r25;
-@ %r37 membar.sys;
+membar.sys;
+atom.cas.b32 %r29,[%r23],%r28,%r25;
+membar.sys;
 shfl.idx.b32 %r29,%r29,%r36,31;
 setp.eq.u32 %r31,%r29,%r28;
 selp.u32 %r30,1,0,%r31;

Similar for 'nvptx-none/mgomp/libatomic/cas_8_.o'.

Simlarly for several others in 'nvptx-none/mgomp/libatomic/',
'nvptx-none/mgomp/libbacktrace/dwarf.o', 'nvptx-none/mgomp/libgcc/atomic.o',
'nvptx-none/mgomp/libgfortran/single.o', several in
'nvptx-none/mgomp/libgomp/'.

That is, remove predication from all the "atomic" instructions.  I of course do
see the code changes related to that in the commit, but I do wonder whether
that's all intentional/correct?  (Or, is the 'atom' provably a no-op if not '@
%r37'?)

And, in 'nvptx-none/mgomp/libgomp/task.o' we've got several things like:

-@ %r330 atom.cas.b32 %r208,[%frame+16],%r80,%r207;
-@ %r330 membar.sys;
+{
+.reg .pred %eq_p;
+.reg .u32 %val;
+ld.u32 %val,[%frame+16];
+setp.eq.u32 %eq_p,%val,%r80;
+@ %eq_p st.u32 [%frame+16],%r207;
+mov.u32 %r208,%val;
+}

So these are the non-'atom' replacement sequences that now get synthesized
(haven't verified) -- but again this one lost the '@ %r330' predication from
all the "atomic" instructions?

And, is it correct here to use the non-'atom' replacement, though?  '%frame'
comes from:

.visible .func GOMP_taskwait
{
.reg .u64 %stack;
.reg .u64 %frame;
.reg .u64 %sspslot;
.reg .u64 %sspprev;
{
.reg .u32 %fstmp0;
.reg .u6

[Bug c++/104365] New: Overload ambiguity not detected

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

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

Bug ID: 104365
   Summary: Overload ambiguity not detected
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andris at gcc dot gnu.org
  Target Milestone: ---

Created attachment 52336
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52336&action=edit
Test example

Overload ambiguity is not detected when 2 constructors with parameter types
- bool
- const std::string&
are available and string literal is provided as parameter. Compiler chooses
conversion to bool. Tested with versions gcc-11.2.0 (Arch Linux), gcc-8.5.0
(RHEL 8).

Test example attached

At least warning (or better an error) in this case would be nice as otherwise
failure to detected ambiguity causes difficult to find errors

[Bug target/104364] [12 Regression] OpenMP/nvptx regressions after "[nvptx] Add some support for .local atomics"

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

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

--- Comment #1 from Tom de Vries  ---
(In reply to Thomas Schwinge from comment #0)
> 'nvptx-none/mgomp/libatomic/cas_1_.o' (complete diff):
> 
> @@ -113,7 +113,7 @@
>  .loc 3 80 9
>  or.b64 %r61,%r60,%r39;
>  .loc 3 82 11
> -@ %r71 atom.cas.b64 %r62,[%r35],%r29,%r61;
> +atom.cas.b64 %r62,[%r35],%r29,%r61;
>  mov.b64 {%r69,%r70},%r62;
>  shfl.idx.b32 %r69,%r69,%r68,31;
>  shfl.idx.b32 %r70,%r70,%r68,31;
> 

Interesting.  This could be fallout from nvptx_reorg_uniform_simt.

Basically, the function assumes that atom.cas is predicable, which it's not
(anymore).

What is odd is that the resulting insn is still validated, I would have
expected that to fail.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-02-03
 CC||ebotcazou at gcc dot gnu.org

--- Comment #7 from Eric Botcazou  ---
> Hmm, but doesn't ada enable -fdelete-dead-exceptions?  That is, I'm not sure
> we make division by zero well-defined with -fnon-call-exceptions - the
> transform assumes the exception cannot happen (because undefinedness) and
> removes the exceptional path.

Yes, the division by zero can be optimized away in Ada if the result of the
operation is not used later, so we would need to add a pragma Volatile to the
gnat.dg/div_zero.adb testcase:

  D : Integer := Zero;
  pragma Volatile (D);

for strict semantics, but this usually does not matter at -O0 when the result
is assigned to a user variable:

  D := 1 / D;

[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.

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

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

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

Untested fix.
That said, now that I think about it, >>= doesn't need to be misspelling of
> >=, but can be also misspelling of >> = e.g. with nested template argument.

[Bug rtl-optimization/101885] [10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com
 Status|NEW |ASSIGNED
 CC||roger at nextmovesoftware dot 
com

--- Comment #11 from Roger Sayle  ---
Patch proposed
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589741.html

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #8 from rguenther at suse dot de  ---
On Thu, 3 Feb 2022, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356
> 
> Eric Botcazou  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>  Ever confirmed|0   |1
>Last reconfirmed||2022-02-03
>  CC||ebotcazou at gcc dot gnu.org
> 
> --- Comment #7 from Eric Botcazou  ---
> > Hmm, but doesn't ada enable -fdelete-dead-exceptions?  That is, I'm not sure
> > we make division by zero well-defined with -fnon-call-exceptions - the
> > transform assumes the exception cannot happen (because undefinedness) and
> > removes the exceptional path.
> 
> Yes, the division by zero can be optimized away in Ada if the result of the
> operation is not used later, so we would need to add a pragma Volatile to the
> gnat.dg/div_zero.adb testcase:
> 
>   D : Integer := Zero;
>   pragma Volatile (D);
> 
> for strict semantics, but this usually does not matter at -O0 when the result
> is assigned to a user variable:
> 
>   D := 1 / D;

So for Ada it would be valid to optimize it as

  tem = D;
  if (tem != 0)
D := 1 / tem;
  else
D = tem;

basically carrying out the division conditionally only?
(I've tried hard to preserve all volatile loads / stores, if not
volatile that can be elided)

Does Ada define what value D obtains when D is zero or does it
only allow the divison and the exceptional case to be optimized
together but not separate?  So optimization to

  tem = D;
  if (tem != 0)
D := 1 / tem;
  else
1/0;

and then optimizing the unused 1/0 "exceptional case" only is not
allowed?

[Bug c++/104365] Overload ambiguity not detected

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
I don't think this is ambigous as conversion from const char* to bool is better
than doing a copy constructor. 


Note only MSVC warns about the conversion:
(18): warning C4800: Implicit conversion from 'const char *' to bool.
Possible information loss
(18): note: consider using explicit cast or comparison to nullptr to
avoid this warning


No other compiler I tested warns though.

[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.

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

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

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

Improved patch.  The error recovery doesn't work well for some reason though as
can be seen on the spurious extra errors, unfortunately no idea why is that
because the ugly hack of overwriting token->type clearly works at least for the
supported C++11 and later case of z> = 0;
But at least the first errors are now clearer.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #9 from Eric Botcazou  ---
> So for Ada it would be valid to optimize it as
> 
>   tem = D;
>   if (tem != 0)
> D := 1 / tem;
>   else
> D = tem;
> 
> basically carrying out the division conditionally only?
> (I've tried hard to preserve all volatile loads / stores, if not
> volatile that can be elided)

No, the result of the operation is not dead here (modulo Volatile), so the
operation must be performed and therefore raise an exception.  To sum up,
either you optimize away the final assignment to D or you raise an exception,
i.e. D cannot contain a random value.

[Bug c++/104365] Overload ambiguity not detected

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

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

--- Comment #2 from Andris Pavenis  ---
OK. Then warning would be nice.

Otherwise it is a trap when one chooses to add bool parameter at end after
string 
parameter and other overloaded method with one more string parameter at end is
also present.

[Bug target/104363] hppa: __asm__ directive .global and multiple .symver not supported

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

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

--- Comment #4 from Andrew Pinski  ---
Can you provide an easier testcase that shows the issue?

[Bug target/104363] hppa: __asm__ directive .global and multiple .symver not supported

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Mathieu Malaterre from comment #2)
> I've downgraded binutils to version from bullseye, and I am getting the
> exact same symptoms:

Did you build from scratch or reuse the object files?

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #10 from Jakub Jelinek  ---
So what does Ada do on targets like powerpc that do not raise an exception?
>From what I can see, 1 / 0 yields 0 there.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #11 from Eric Botcazou  ---
> So what does Ada do on targets like powerpc that do not raise an exception?
> From what I can see, 1 / 0 yields 0 there.

It generates an explicit check for division-by-zero in the general case (remove
the pragma Suppress (All_Checks) and you'll see it) but we do not rely on it
everywhere, only where system.ads contains:

   Backend_Divide_Checks : constant Boolean := False;

In other words, when Backend_Divide_Checks is set to True, we need the divide
and it needs to trap (and pragma Suppress (All_Checks) emulates that, but I
certainly need to add a dg-skip for PowerPC here).

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #12 from Richard Biener  ---
(In reply to Eric Botcazou from comment #9)
> > So for Ada it would be valid to optimize it as
> > 
> >   tem = D;
> >   if (tem != 0)
> > D := 1 / tem;
> >   else
> > D = tem;
> > 
> > basically carrying out the division conditionally only?
> > (I've tried hard to preserve all volatile loads / stores, if not
> > volatile that can be elided)
> 
> No, the result of the operation is not dead here (modulo Volatile), so the
> operation must be performed and therefore raise an exception.  To sum up,
> either you optimize away the final assignment to D or you raise an
> exception, i.e. D cannot contain a random value.

OK, so a division by zero is not invoking undefined behavior but is
well-defined and traps.  And the idea is that -fnon-call-exceptions alone
carries this over to middle-end semantics?  (I don't think it does that at the
moment, with or without the rev. in question)

[Bug target/104364] [12 Regression] OpenMP/nvptx regressions after "[nvptx] Add some support for .local atomics"

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #13 from Jakub Jelinek  ---
Anyway, if integer division by zero is not considered UB in Ada, we need some
flag_whatever that will represent that to the middle-end and check it in all
places where we assume it is UB.  It can be of course set e.g. only if the
explicit checks aren't emitted.
And this optimization would be just one of the many places that would need to
be guarded by that flag.

[Bug c++/104365] Overload ambiguity not detected

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

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

Richard Biener  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #14 from Eric Botcazou  ---
> OK, so a division by zero is not invoking undefined behavior but is
> well-defined and traps.  And the idea is that -fnon-call-exceptions alone
> carries this over to middle-end semantics?  (I don't think it does that at
> the moment, with or without the rev. in question)

Why?  It's exactly like any other trapping operation, see the numerous
predicates in tree-eh.cc, most notably operation_could_trap_helper_p:

  switch (op)
{
case TRUNC_DIV_EXPR:
case CEIL_DIV_EXPR:
case FLOOR_DIV_EXPR:
case ROUND_DIV_EXPR:
case EXACT_DIV_EXPR:
case CEIL_MOD_EXPR:
case FLOOR_MOD_EXPR:
case ROUND_MOD_EXPR:
case TRUNC_MOD_EXPR:
  if (!TREE_CONSTANT (divisor) || integer_zerop (divisor))
return true;

[Bug target/104364] [12 Regression] OpenMP/nvptx regressions after "[nvptx] Add some support for .local atomics"

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

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

--- Comment #2 from Tom de Vries  ---
(In reply to Tom de Vries from comment #1)
> What is odd is that the resulting insn is still validated, I would have
> expected that to fail.

Ah, the change is just silently rejected, this makes the problem visible:
...
diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
index b3bb97c3c14d..9d083f46ce0a 100644
--- a/gcc/config/nvptx/nvptx.cc
+++ b/gcc/config/nvptx/nvptx.cc
@@ -3150,7 +3150,8 @@ nvptx_reorg_uniform_simt ()
   rtx pred = nvptx_get_unisimt_predicate ();
   pred = gen_rtx_NE (BImode, pred, const0_rtx);
   pat = gen_rtx_COND_EXEC (VOIDmode, pred, pat);
-  validate_change (insn, &PATTERN (insn), pat, false);
+  bool changed_p = validate_change (insn, &PATTERN (insn), pat, false);
+  gcc_assert (changed_p);
 }
 }
...

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #15 from Eric Botcazou  ---
And in rtlanal.cc, see may_trap_p_1:

  /* Division by a non-constant might trap.  */
case DIV:
case MOD:
case UDIV:
case UMOD:
  if (HONOR_SNANS (x))
return 1;
  if (FLOAT_MODE_P (GET_MODE (x)))
return flag_trapping_math;
  if (!CONSTANT_P (XEXP (x, 1)) || (XEXP (x, 1) == const0_rtx))
return 1;

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #16 from Richard Biener  ---
Related simplifications:

 /* X / bool_range_Y is X.  */
 (simplify
  (div @0 SSA_NAME@1)
  (if (INTEGRAL_TYPE_P (type) && ssa_name_has_boolean_range (@1))
   @0))

 /* X / abs (X) is X < 0 ? -1 : 1.  */
 (simplify
   (div:C @0 (abs @0))
   (if (INTEGRAL_TYPE_P (type)
&& TYPE_OVERFLOW_UNDEFINED (type))
(cond (lt @0 { build_zero_cst (type); })
  { build_minus_one_cst (type); } { build_one_cst (type); })))

 /* X / -X is -1.  */
 (simplify
   (div:C @0 (negate @0))
   (if ((INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (type))
&& TYPE_OVERFLOW_UNDEFINED (type))
{ build_minus_one_cst (type); })))

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #17 from Richard Biener  ---
(In reply to Eric Botcazou from comment #14)
> > OK, so a division by zero is not invoking undefined behavior but is
> > well-defined and traps.  And the idea is that -fnon-call-exceptions alone
> > carries this over to middle-end semantics?  (I don't think it does that at
> > the moment, with or without the rev. in question)
> 
> Why?  It's exactly like any other trapping operation, see the numerous
> predicates in tree-eh.cc, most notably operation_could_trap_helper_p:
> 
>   switch (op)
> {
> case TRUNC_DIV_EXPR:
> case CEIL_DIV_EXPR:
> case FLOOR_DIV_EXPR:
> case ROUND_DIV_EXPR:
> case EXACT_DIV_EXPR:
> case CEIL_MOD_EXPR:
> case FLOOR_MOD_EXPR:
> case ROUND_MOD_EXPR:
> case TRUNC_MOD_EXPR:
>   if (!TREE_CONSTANT (divisor) || integer_zerop (divisor))
> return true;

It's used for a different purpose as well, we of course have to avoid moving a
possibly trapping operation to a place where it was not executed
unconditionally.

But sure, so you say that -fnon-call-exceptions makes operations that
may trap according to the EH machinery well-defined, irrespective of what
the language standards say?  That certainly makes sense, it doesn't
make sense to create EH when the situation invokes undefined behavior.
(but as said above we have to avoid traps in non-EH context as well)

[Bug lto/104366] New: Regression: infinite loop in add_sibling_attributes

[bjorn--- via Gcc-bugs]

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

Bug ID: 104366
   Summary: Regression: infinite loop in add_sibling_attributes
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bj...@xn--rombobjrn-67a.se
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 52339
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52339&action=edit
source code for reproducing the problem

Compiling certain Ada source files with -g -flto -ffat-lto-objects triggers
what looks like infinite tail recursion in add_sibling_attributes in
dwarf2out.c. This began when GCC 12 landed in Fedora Rawhide. It does not
happen in GCC 11. Removing either -g, -flto or -ffat-lto-objects, or appending
-fno-lto, works around the problem.

It seems to be specific to 64-bit arches. Builds consistently continue running
indefinitely on all of Fedora's four 64-bit arches, but not on the two 32-bit
arches. I have investigated only on x86-64.

It's probably more or less specific to Ada, because otherwise it would have
caused lots and lots of failures in the recent Fedora mass rebuild.

# gcc --version
gcc (GCC) 12.0.1 20220129 (Red Hat 12.0.1-0)

# rpm -q gcc-gnat
gcc-gnat-12.0.1-0.4.fc36.x86_64

To reproduce:
gnatchop sources.ada
gcc -c -g -flto -ffat-lto-objects posix-process_environment.adb

[Bug tree-optimization/101340] SLP discovery via vect_slp_linearize_chain is imperfect

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Not sure if this is exactly the same issue (I can file a separate
PR if it's not), but there's a similar inefficiency in
gcc.dg/vect/pr97832-2.c.  There we unroll:

#pragma GCC unroll 4
for (int k = 0; k < 4; ++k) {
  double x_re = x[c+0+k];
  double x_im = x[c+4+k];
  double y_re = y[c+0+k];
  double y_im = y[c+4+k];
  y_re = y_re - x_re * f_re - x_im * f_im;;
  y_im = y_im + x_re * f_im - x_im * f_re;
  y[c+0+k] = y_re;
  y[c+4+k] = y_im;
}

The depth of the y_re and x_re calculations for k==0 are one
less than for k>0, due to the extra c+N additions for the latter.
k==0 therefore gets a lower reassociation rank, so we end
up with:

  _65 = f_re_34 * x_re_54;
  _66 = y_re_62 - _65;
  _67 = f_im_35 * x_im_60;
  y_re_68 = _66 - _67;

for k==0 but:

  _93 = f_re_34 * x_re_82;
  _95 = f_im_35 * x_im_88;
  _41 = _93 + _95;
  y_re_96 = y_re_90 - _41;

etc. for k>0.  This persists into the SLP code, where we use
the following load permutes:

  load permutation { 4 1 2 3 0 1 2 3 }
  load permutation { 0 5 6 7 4 5 6 7 }

With different reassociation we could have used:

  load permutation { 0 1 2 3 0 1 2 3 }
  load permutation { 4 5 6 7 4 5 6 7 }

instead.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #18 from Richard Biener  ---
So we'd add

  (!flag_non_call_exceptions || tree_expr_nonzero_p (@..))

to the offending and extra listed match.pd transforms.  I guess that works for
me.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #19 from Jakub Jelinek  ---
Those correctly say that division by zero may trap.  That doesn't tell that
division by zero is not undefined behavior, but well defined to trap.
This new optimization, or e.g. operator_div::wi_fold's
  // If we're definitely dividing by zero, there's nothing to do.
  if (wi_zero_p (type, divisor_min, divisor_max))
{
  r.set_undefined ();
  return;
}
but even that
  // Perform the division in 2 parts, [LB, -1] and [1, UB], which will
  // skip any division by zero.
following it, I'm afraid a few further spots in match.pd, e.g.
 /* X / bool_range_Y is X.  */
 (simplify
  (div @0 SSA_NAME@1)
  (if (INTEGRAL_TYPE_P (type) && ssa_name_has_boolean_range (@1))
   @0))
or
 /* X / X is one.  */
 (simplify
  (div @0 @0)
  /* But not for 0 / 0 so that we can get the proper warnings and errors.
 And not for _Fract types where we can't build 1.  */
  (if (!integer_zerop (@0) && !ALL_FRACT_MODE_P (TYPE_MODE (type)))
   { build_one_cst (type); }))
 /* X / abs (X) is X < 0 ? -1 : 1.  */
 (simplify
   (div:C @0 (abs @0))
   (if (INTEGRAL_TYPE_P (type)
&& TYPE_OVERFLOW_UNDEFINED (type))
(cond (lt @0 { build_zero_cst (type); })
  { build_minus_one_cst (type); } { build_one_cst (type); })))
 /* X / -X is -1.  */
 (simplify
   (div:C @0 (negate @0))
   (if ((INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (type))
&& TYPE_OVERFLOW_UNDEFINED (type))
{ build_minus_one_cst (type); })))
etc.
I'm afraid it is all over the middle-end.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #20 from Jakub Jelinek  ---
flag_non_call_exceptions can be used even in C/C++ and other languages, so I'd
strongly prefer a new flag which will e.g. make it clearer what is it about,
will make it easier for grep for such dependencies etc.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #21 from Eric Botcazou  ---
> But sure, so you say that -fnon-call-exceptions makes operations that
> may trap according to the EH machinery well-defined, irrespective of what
> the language standards say?  That certainly makes sense, it doesn't
> make sense to create EH when the situation invokes undefined behavior.
> (but as said above we have to avoid traps in non-EH context as well)

Of course, that's the very and only purpose of -fnon-call-exceptions, see
tree_could_throw_p:

/* Return true if expression T could throw an exception.  */

bool
tree_could_throw_p (tree t)
{
[...]
  if (cfun->can_throw_non_call_exceptions)
return tree_could_trap_p (t);
  return false;
}

With -fnon-call-exceptions, trapping operations are not UB but throw instead.
What the language (Java, Go, Ada) makes of this exception may vary, but I don't
think that they call it undefined behavior like in the C family of languages.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #22 from Eric Botcazou  ---
> So we'd add
> 
>   (!flag_non_call_exceptions || tree_expr_nonzero_p (@..))
> 
> to the offending and extra listed match.pd transforms.  I guess that works
> for me.

For me as well.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #23 from rguenther at suse dot de  ---
On Thu, 3 Feb 2022, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356
> 
> --- Comment #20 from Jakub Jelinek  ---
> flag_non_call_exceptions can be used even in C/C++ and other languages, so I'd
> strongly prefer a new flag which will e.g. make it clearer what is it about,
> will make it easier for grep for such dependencies etc.

But then it doesn't make sense to create EH edges from integer divisions
when the only exceptional case is invoking undefined behavior.

I think we need to align what is undefined and what is exceptional,
a new flag only makes the situation worse.

The option besides making -fnon-call-exceptions do it would be to
require the frontend to emit different GENERIC, aka some
.DIV_WITH_EH_ON_ZERO or however we want to represent that.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #24 from Richard Biener  ---
(In reply to Eric Botcazou from comment #22)
> > So we'd add
> > 
> >   (!flag_non_call_exceptions || tree_expr_nonzero_p (@..))
> > 
> > to the offending and extra listed match.pd transforms.  I guess that works
> > for me.
> 
> For me as well.

Oh, with the little detail that it should be
cfun->can_throw_non_call_exceptions
(with the unfortunate reference to cfun)

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #25 from Jakub Jelinek  ---
GENERIC folding can be done with NULL cfun too though.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #26 from Eric Botcazou  ---
> Oh, with the little detail that it should be
> cfun->can_throw_non_call_exceptions
> (with the unfortunate reference to cfun)

Yes, and note that this will also solve the libgcc2.c issue because of:

ifeq ($(LIB2_DIVMOD_EXCEPTION_FLAGS),)
# Provide default flags for compiling divmod functions, if they haven't been
# set already by a target-specific Makefile fragment.
LIB2_DIVMOD_EXCEPTION_FLAGS := -fexceptions -fnon-call-exceptions
endif

# Build LIB2_DIVMOD_FUNCS.
lib2-divmod-o = $(patsubst %,%$(objext),$(LIB2_DIVMOD_FUNCS))
$(lib2-divmod-o): %$(objext): $(srcdir)/libgcc2.c
$(gcc_compile) -DL$* -c $< \
  $(LIB2_DIVMOD_EXCEPTION_FLAGS) $(vis_hide)
libgcc-objects += $(lib2-divmod-o)

ifeq ($(enable_shared),yes)
lib2-divmod-s-o = $(patsubst %,%_s$(objext),$(LIB2_DIVMOD_FUNCS))
$(lib2-divmod-s-o): %_s$(objext): $(srcdir)/libgcc2.c
$(gcc_s_compile) -DL$* -c $< \
  $(LIB2_DIVMOD_EXCEPTION_FLAGS)
libgcc-s-objects += $(lib2-divmod-s-o)
endif

in libgcc/Makefile.in.

[Bug c++/104365] Overload ambiguity not detected

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2022-02-03
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
 Blocks||87403

--- Comment #3 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> I don't think this is ambigous as conversion from const char* to bool is
> better than doing a copy constructor. 

Right, a standard conversion sequence is better than a user-defined conversion.

I think if you want a new warning here you need to be very clear about exactly
what you're asking for.

MSVC warns about converting const char* to bool, but that's nothing to do with
ambiguous overloads, it warns when there is no overloading at all:

void f(bool);
void g(const char* s) { f(s); }

This is warning about narrowing, not confusing overloads.

So please explain precisely what you want to warn, when you *don't* want it to
warn, and how users can easily modify their code to avoid the warning if the
overload set is written exactly how they intend it to be written, and is
correct.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug c/104367] New: Possible improvements for -Wmisleading-indentation

[frantisek at sumsal dot cz via Gcc-bugs]

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

Bug ID: 104367
   Summary: Possible improvements for -Wmisleading-indentation
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frantisek at sumsal dot cz
  Target Milestone: ---

Hello!

Recently we encountered a pretty nasty bug in systemd[0], which makes me wonder
if this situation couldn't be prevented by throwing a compiler warning.

# cat /etc/redhat-release 
Fedora release 36 (Rawhide)
# gcc --version
gcc (GCC) 12.0.1 20220125 (Red Hat 12.0.1-0)

Reproducer:
#include 

void bar(int *x) {
printf("%d\n", *x);
}

void foo(int *x) {
if (!x)
return

bar(x);
}

int main(void) {
foo(NULL);

return 0;
}


The culprit here is, obviously, the missing semicolon after the return
statement, which currently leads to a segmentation fault:

# gcc -Wall -Wextra -Wmisleading-indentation -o main main.c
# ./main 
Segmentation fault (core dumped)

That is, however, silently accepted, since the resulting expression (return
bar(x);) is still valid in this context.

I wonder if this couldn't/shouldn't be detected by -Wmisleading-indentation
(since this definitely falls into that category).

Possibly related to other similar bugs like:
 - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66298
 - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70968
 - and others

[0] https://github.com/systemd/systemd/pull/22387/files

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #27 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:635504510a9410844991c68880f2e7352cacfd86

commit r12-7021-g635504510a9410844991c68880f2e7352cacfd86
Author: Eric Botcazou 
Date:   Thu Feb 3 13:12:37 2022 +0100

Skip gnat.dg/div_zero.adb on PowerPC

The hardware instruction does not trap on divide by zero there.

gcc/testsuite
PR tree-optimization/104356
* gnat.dg/div_zero.adb: Add dg-skip-if directive for PowerPC.

[Bug c++/104365] Overload ambiguity not detected

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

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

--- Comment #4 from Jonathan Wakely  ---
Your original testcase shows one example where you want a warning, but that's
not a specification. Should it only warn when std::string and bool are
involved, and there's a char* argument? Or should it be more general? How
general? What should the semantics be?

[Bug c/104367] Possible improvements for -Wmisleading-indentation

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||dmalcolm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2022-02-03

--- Comment #1 from Martin Liška  ---
It's something quite related to -Wmisleading-indentation, which is an
indentation warning.
What do you think David?

[Bug lto/104366] [12 Regression] Regression: infinite loop in add_sibling_attributes

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-02-03
   Keywords||needs-bisection,
   ||needs-reduction
Summary|Regression: infinite loop   |[12 Regression] Regression:
   |in add_sibling_attributes   |infinite loop in
   ||add_sibling_attributes
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Reproduced, bisecting that right now.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #28 from Eric Botcazou  ---
> Oh, with the little detail that it should be
> cfun->can_throw_non_call_exceptions
> (with the unfortunate reference to cfun)

We have global references to flag_trapping_math in match.pd so I think that
global references to flag_non_call_exceptions can do too.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #29 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #24)
> (In reply to Eric Botcazou from comment #22)
> > > So we'd add
> > > 
> > >   (!flag_non_call_exceptions || tree_expr_nonzero_p (@..))
> > > 
> > > to the offending and extra listed match.pd transforms.  I guess that works
> > > for me.
> > 
> > For me as well.
> 
> Oh, with the little detail that it should be
> cfun->can_throw_non_call_exceptions
> (with the unfortunate reference to cfun)

Why does cfun->can_throw_non_call_exceptions and
cfun->can_delete_dead_exceptions exist btw?  Now that both
flag_non_call_exceptions and flag_delete_dead_exceptions are Optimization,
set_cfun adjusts that on switching the function, so I think it be the same. 
Ok, {fn,fun,src_cfun}->can_throw_non_call_exceptions might be faster when it
looks at other functions than opt_for_fn.

[Bug target/104364] [12 Regression] OpenMP/nvptx regressions after "[nvptx] Add some support for .local atomics"

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

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

--- Comment #3 from Tom de Vries  ---
(In reply to Thomas Schwinge from comment #0)

> And, is it correct here to use the non-'atom' replacement, though?  '%frame'
> comes from:
> 
> .visible .func GOMP_taskwait
> {
> .reg .u64 %stack;
> .reg .u64 %frame;
> .reg .u64 %sspslot;
> .reg .u64 %sspprev;
> {
> .reg .u32 %fstmp0;
> .reg .u64 %fstmp1;
> .reg .u64 %fstmp2;
> mov.u32 %fstmp0,%tid.y;
> mul.wide.u32 %fstmp1,%fstmp0,8;
> mov.u64 %fstmp2,__nvptx_stacks;
> add.u64 %sspslot,%fstmp2,%fstmp1;
> ld.shared.u64 %sspprev,[%sspslot];
> sub.u64 %frame,%sspprev,32;
> sub.u64 %stack,%frame,16;
> st.shared.u64 [%sspslot],%stack;
> }
> [...]
> 
> ... which -- at least from my superficial look -- seems to be some kind of
> 'shared' location, thus mandating 'atom' access?  (But haven't looked in
> detail, so I may certainly be wrong, of course.)

Yeah, that's a mistake, when using -msoft-stack, we can't assume that
stack-related means local.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #30 from Eric Botcazou  ---
> Why does cfun->can_throw_non_call_exceptions and
> cfun->can_delete_dead_exceptions exist btw?

Jan asked me to create them when he was working on option merging for LTO.

> Now that both flag_non_call_exceptions and flag_delete_dead_exceptions are 
> Optimization, set_cfun adjusts that on switching the function, so I think it
> be the same. 

Good news then, thanks!

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #31 from Eric Botcazou  ---
Created attachment 52340
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52340&action=edit
Tentative fix

To be further tested.

[Bug c++/104079] [9/10/11/12 Regression] internal compiler error: in nothrow_spec_p, at cp/except.c:1192 since r9-4662-g0d699def39bb937e

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/104365] Overload ambiguity not detected

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

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

--- Comment #5 from Andris Pavenis  ---
The warning should be in case when both
1) there is preferred standard conversion sequence for parameter of one
overloaded method
2) there is other user defined conversion sequences for one more more other
overloaded methods

Message format could be similar as current ambiguity message only downgraded to
warning (maybe preferred conversion sequence could be marked in the message)

const char* -> bool and const char* -> std::string could be one example which
could likely cause problems

I could imagine similar situation with integer number conversion and some
extended precision number library.

[Bug target/104364] [12 Regression] OpenMP/nvptx regressions after "[nvptx] Add some support for .local atomics"

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

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

--- Comment #4 from Tom de Vries  ---
Created attachment 52341
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52341&action=edit
Tentative patch

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #32 from Jakub Jelinek  ---
Comment on attachment 52340
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52340
Tentative fix

For the X / bool_range_Y is X. case I think just !flag_non_call_exceptions
would be better.  If @1 has boolean range and is known to be non-zero, it is
known to be 1, so we should be optimizing it elsewhere, that is the constant
case.

Anyway, that's probably it in match.pd.
path isolation is already guarding is_divmod_with_given_divisor calls with
!cfun->can_throw_non_call_exceptions.
>From the to me known issues that leaves VRP.  As Ada expects the division by
zero to trap, I guess we don't care much about the range it emits for the
result, but it shouldn't be for cfun->can_throw_non_call_exceptions be
undefined or single value range, because then it would be just optimized into a
constant I bet.  But there is also the problem that ranger doesn't walk just
from stmts to its immediate uses, but also from stmts to their operand's def
stmts.
Can you try to rewrite the
unsigned
foo (unsigned x, unsigned y)
{   
  if (x >= 2)   
return 0;   
  if (x == 1)   
y += 4; 
  return y / x; 
}   
testcase I've posted into Ada and see if it will optimize away the division in
evrp or vrp?

[Bug fortran/91316] Derived type finalization failing

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
 Blocks||37336

--- Comment #1 from Paul Thomas  ---
I notice that this is missing from the list of dependencies of PR37336, for
which a wider fix will be submitted this afternoon.

Best regards

Paul


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug 37336] [F03] Finish derived-type finalization

[Bug lto/104366] [12 Regression] Regression: infinite loop in add_sibling_attributes

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||ebotcazou at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r12-3383-g81e9178fe7f8bae4609619b1195765b14eef35b7, before the
revision it was affected by the ICE mentioned in PR101947.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #33 from rguenther at suse dot de  ---
On Thu, 3 Feb 2022, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356
> 
> --- Comment #29 from Jakub Jelinek  ---
> (In reply to Richard Biener from comment #24)
> > (In reply to Eric Botcazou from comment #22)
> > > > So we'd add
> > > > 
> > > >   (!flag_non_call_exceptions || tree_expr_nonzero_p (@..))
> > > > 
> > > > to the offending and extra listed match.pd transforms.  I guess that 
> > > > works
> > > > for me.
> > > 
> > > For me as well.
> > 
> > Oh, with the little detail that it should be
> > cfun->can_throw_non_call_exceptions
> > (with the unfortunate reference to cfun)
> 
> Why does cfun->can_throw_non_call_exceptions and
> cfun->can_delete_dead_exceptions exist btw?  Now that both
> flag_non_call_exceptions and flag_delete_dead_exceptions are Optimization,
> set_cfun adjusts that on switching the function, so I think it be the same. 
> Ok, {fn,fun,src_cfun}->can_throw_non_call_exceptions might be faster when it
> looks at other functions than opt_for_fn.

I think ->can_throw_non_call_exceptions allows to optimize it based on
IL analysis.  But historically it was because of LTO and before we had
forced the "correct" set of options on all functions.

Btw, !cfun || cfun->... would work as well.

That said, we can probably remove both struct function "copies" of the
flags and replace fun->xxx with OPT_for_fn

[Bug fortran/91648] [9/10/11/12 Regression] ICE in generate_finalization_wrapper, at fortran/class.c:2009

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #8 from Paul Thomas  ---
This was fixed by Tobias Burnus with PR/92587

Paul

[Bug fortran/37336] [F03] Finish derived-type finalization

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

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

Bug 91648 Summary: [9/10/11/12 Regression] ICE in 
generate_finalization_wrapper, at fortran/class.c:2009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91648

   What|Removed |Added

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

[Bug target/104364] [12 Regression] OpenMP/nvptx regressions after "[nvptx] Add some support for .local atomics"

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

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

--- Comment #5 from Tom de Vries  ---
(In reply to Thomas Schwinge from comment #0)
> ... but only seen regressing for:
> 
>   - Nvidia Tesla K20c, Driver Version: 346.46
>   - Nvidia Tesla K20c, Driver Version: 455.38
>   - Nvidia Tesla K40c, Driver Version: 455.38
>   - Nvidia Tesla K80, Driver Version: 440.33.01
> 
> ... and never seen regressing for:
> 
>   - Nvidia Quadro P1000, Driver Version: 450.119.03
>   - Nvidia GeForce GTX 1080, Driver Version: 440.33.01
>   - Nvidia TITAN V, Driver Version: 455.23.05
> 
> (What is the underlying characteristic here?)

Good question.

I've tested this using (recommended) driver 470.94 on boards:
- Kepler (Geforce GT 710)
- Maxwell (Quadro K620)
- Pascal (Geforce GT 1030)
- Turing (T400)
while iterating over dimensions { -mptx=3.1 , -mptx=6.3 } x {
GOMP_NVPTX_JIT=-O0,  }.

So I'm slightly surprised that I didn't see any regressions.

[Bug c++/104365] Overload ambiguity not detected

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

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

--- Comment #6 from Andris Pavenis  ---
Suggested format (changed types to get real ambiguity and edited generated
message):

20220203-1.cpp: In function 'int main()':
20220203-1.cpp:19:24: warning: call of overloaded 'Test(const char [4],
unsigned 
char[4])' is ambiguous
   21 | Test test("foo", "bar");
      |  ^
20220203-1.cpp:12:5: note: chosen candidate: 'Test::Test(const string&, bool)'
   12 | Test(const std::string&, bool)
  | ^~~~
20220203-1.cpp:7:5: note: candidate: 'Test::Test(const string&, const
std::string&)'
7 | Test(const std::string&, const std::string&)
  | ^~~~

[Bug c++/104365] Overload ambiguity not detected

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

--- Comment #7 from Jonathan Wakely  ---
Thanks

[Bug c++/104365] Overload ambiguity not detected

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

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Andris Pavenis from comment #5)
> The warning should be in case when both
> 1) there is preferred standard conversion sequence for parameter of one
> overloaded method

Standard conversions include T -> const T&, and derived-to-base conversions,
and 
T* -> void*. I don't think anybody would be surprised that those conversions
beat a user-defined one.

> 2) there is other user defined conversion sequences for one more more other
> overloaded methods

And non-member functions?


(In reply to Andris Pavenis from comment #6)
> 20220203-1.cpp:19:24: warning: call of overloaded 'Test(const char [4],
> unsigned 
> char[4])' is ambiguous


"is ambiguous" is incorrect though, so it would have to be clear that there is
no ambiguity in C++ terms, just potential for confusion.

[Bug c++/104365] Overload ambiguity not detected

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

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

--- Comment #9 from Andris Pavenis  ---
>> The warning should be in case when both
>> 1) there is preferred standard conversion sequence for parameter of one
>> overloaded method
>
>Standard conversions include T -> const T&, and derived-to-base conversions, > 
>>and  T* -> void*. I don't think anybody would be surprised that those 
>>conversions beat a user-defined one.

Perhaps there should be no warning in these cases.
[const] char * -> bool is good example which would deserve warning. I do not
have other examples currently.

>> 2) there is other user defined conversion sequences for one more more other
>> overloaded methods
>
>And non-member functions?

Should be handled in the same way as member functions

>> 20220203-1.cpp:19:24: warning: call of overloaded 'Test(const char [4],
>> unsigned 
>> char[4])' is ambiguous
>
>"is ambiguous" is incorrect though, so it would have to be clear that there is 
>>no ambiguity in C++ terms, just potential for confusion.

Maybe 'suspicious use of overloaded ...' or something similar

[Bug target/104345] [12 Regression] "nvptx: Transition nvptx backend to STORE_FLAG_VALUE = 1" patch made some code generation worse

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

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

--- Comment #2 from Tom de Vries  ---
(In reply to Roger Sayle from comment #1)
> The other patches in the "nvptx Boolean" series are:
> patchq3: nvptx: Expand QI mode operations using SI mode instructions.
> https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587999.html
> 
> patchq4: nvptx: Fix and use BI mode logic instructions (e.g. and.pred).
> https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588555.html
> 
> [and purely for reference, my other outstanding nvptx patches are]
> patchn: nvptx: Improved support for HFMode including neghf2 and abshf2.
> https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587949.html
> 
> patchw: nvptx: Add support for 64-bit mul.hi (and other) instructions.
> https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588453.html

FYI, I'm currently testing these.

[Bug lto/104366] [12 Regression] Regression: infinite loop in add_sibling_attributes

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

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

--- Comment #3 from Martin Liška  ---
Created attachment 52342
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52342&action=edit
Reduced test-case

[Bug tree-optimization/104368] New: [12 Regression] Failure to vectorise conditional grouped accesses after PR102659

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

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

Bug ID: 104368
   Summary: [12 Regression] Failure to vectorise conditional
grouped accesses after PR102659
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

The following test regressed with PR102659, compiled with
-O3 -march=armv8.2-a+sve:

void f(int *restrict x, int *restrict y, int n)
{
  for (int i = 0; i < n; ++i)
if (x[i] > 0)
  x[i] = y[i * 2] + y[i * 2 + 1];
}

Previously we treated the y[] accesses as a linear group
and so could use LD2W.  Now we treat them as individual
gather loads instead:

.L3:
ld1wz1.s, p0/z, [x0, x3, lsl 2]
lsl z0.s, z2.s, #1
cmpgt   p0.s, p0/z, z1.s, #0
ld1wz1.s, p0/z, [x1, z0.s, sxtw 2]   // Gather
ld1wz0.s, p0/z, [x5, z0.s, sxtw 2]   // Gather
add z0.s, z1.s, z0.s
st1wz0.s, p0, [x0, x3, lsl 2]
incwz2.s
add x3, x3, x4
whilelo p0.s, w3, w2
b.any   .L3

[Bug analyzer/104369] New: False positive from -Wanalyzer-use-of-uninitialized-value with realloc moving buffer

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

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

Bug ID: 104369
   Summary: False positive from
-Wanalyzer-use-of-uninitialized-value with realloc
moving buffer
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 52343
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52343&action=edit
Reduced reproducer

The attached reproducer emits two false positives from
-Wanalyzer-use-of-uninitialized-value, both "when 'realloc' succeeds, moving
buffer", the first of which is:

: In function 'main':
:79:34: warning: use of uninitialized value '*pollfds.fd' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
   79 |   pollfds[nsockets - 1].fd = accept(pollfds[0].fd, &remote, &len);
  |  ^~~~
  'main': events 1-7
|
|   62 |   if (!pollfds) {
|  |  ^
|  |  |
|  |  (1) following 'false' branch (when 'pollfds' is non-NULL)...
|..
|   67 | rc = ppoll(pollfds, nsockets, NULL, NULL);
|  |  
|  |  |
|  |  (2) ...to here
|..
|   74 |   newpollfds = realloc(pollfds, nsockets * sizeof(*pollfds));
|  |~
|  ||
|  |(3) when 'realloc' succeeds, moving buffer
|  |(4) region created on heap here
|   75 |   if (!newpollfds) {
|  |  ~
|  |  |
|  |  (5) following 'false' branch (when 'newpollfds' is
non-NULL)...
|..
|   78 |   pollfds = newpollfds;
|  |   
|  |   |
|  |   (6) ...to here
|   79 |   pollfds[nsockets - 1].fd = accept(pollfds[0].fd, &remote,
&len);
|  | 

|  |  |
|  |  (7) use of uninitialized value
'*pollfds.fd' here
|

On Compiler Explorer:
  https://godbolt.org/z/EKrnsoaY4

>From downstream report:
  https://bugzilla.redhat.com/show_bug.cgi?id=2047926#c5

[Bug debug/104337] [9/10/11/12 Regression] ICE when compiling with optimize attribute and always_inline at -m32 -g3 -O0

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

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

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

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

commit r12-7026-g1d5c7584fd6e72bfdbede86cef5ff04ae35f9744
Author: Richard Biener 
Date:   Thu Feb 3 11:20:59 2022 +0100

debug/104337 - avoid messing with the abstract origin chain in NRV

The following avoids NRV from massaging DECL_ABSTRACT_ORIGIN after
variable creation since NRV runs _after_ the function was inlined and thus
affects the inlined variables copy indirectly.  We may adjust the abstract
origin of a variable only at the point we create it, not further along the
path since otherwise the (new) invariant that the abstract origin is always
the ultimate origin cannot be maintained.

The intent of what NRV does is OK I guess and it may improve the debug
experience.  But I also notice we do

  SET_DECL_VALUE_EXPR (found, result);
  DECL_HAS_VALUE_EXPR_P (found) = 1;

the code is there since the merge from tree-ssa which added tree-nrv.c.

Jakub added the DECL_VALUE_EXPR in
g:938650d8fddb878f623e315f0b7fd94b217efa96
and Jason added the abstract origin setting conditional in g:7716876bbd3a

The follwoing takes the radical approach and remove the attempt
to "optimize" the debug info.

The gdb testsuites show no regressions.

2022-02-03  Richard Biener  

PR debug/104337
* tree-nrv.cc (pass_nrv::execute): Remove tieing result and found
together via DECL_ABSTRACT_ORIGIN.

* gcc.dg/debug/pr104337.c: New testcase.

[Bug analyzer/104370] New: False positive from -Wanalyzer-mismatching-deallocation with reallocarray

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

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

Bug ID: 104370
   Summary: False positive from
-Wanalyzer-mismatching-deallocation with reallocarray
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 52344
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52344&action=edit
Reduced reproducer

>From downstream report here:
  https://bugzilla.redhat.com/show_bug.cgi?id=2047926#c0

Compiling the attachment with -fanalyzer gives:

: In function 'main':
:21:15: warning: 'foo' should have been deallocated with 'free' but was
deallocated with 'reallocarray' [CWE-762] [-Wanalyzer-mismatching-deallocation]
   21 | new_foo = reallocarray(foo, 201, 200);
  |   ^~~
  'main': events 1-5
|
|   17 | foo = calloc(200, 200);
|  |   ^~~~
|  |   |
|  |   (1) allocated here (expects deallocation with 'free')
|   18 | if (!foo)
|  |~   
|  ||
|  |(2) assuming 'foo' is non-NULL
|  |(3) following 'false' branch (when 'foo' is non-NULL)...
|..
|   21 | new_foo = reallocarray(foo, 201, 200);
|  |   ~~~
|  |   |
|  |   (4) ...to here
|  |   (5) deallocated with 'reallocarray' here; allocation
at (1) expects deallocation with 'free'
|

Compiler Explorer:
  https://godbolt.org/z/K7xaxrfcs

Recent glibc headers declare reallocarray twice, with different attributes:
 
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=c1760eaf3b575ad174fd88b252fd16bd525fa818

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

[svante.signell at gmail dot com via Gcc-bugs]

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

Svante Signell  changed:

   What|Removed |Added

 CC||svante.signell at gmail dot com

--- Comment #1 from Svante Signell  ---
Created attachment 52345
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52345&action=edit
Adding hurd to unixsock_readmsg_cloexec.go fixes the build of libgo

Hello,

The attached patch fixes the build of libgo for GNU/Hurd for gcc-12-20220126
when patching the generated libgo/Makefile as follows:

change
../libbacktrace/libbacktrace.la
to
../../libbacktrace/libbacktrace.la

and remove libatomic from the linkage:
LIBATOMIC = ../libatomic/libatomic_convenience.la
PTHREAD_CFLAGS = -pthread -L../libatomic/.libs
since libatomic is not built yet. It should built before libgo but does not.
Unknown why, it may be a problem with the Debian stuff.

Additionally, continuing, the build of gotools fails:
go1: error: '-fsplit-stack' currently only supported on GNU/Linux
go1: error: '-fsplit-stack' is not supported by this compiler configuration

The reason for this also unknown so far, libgo and gotools built fine with
split-stack on gcc-11. 

Is this problem related to that libatomic not yet has bee built??

Thanks!

[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.

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

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

--- Comment #9 from Jakub Jelinek  ---
Though, the cp_parser_next_token_ends_template_argument_p change can't be
right.
E.g.
struct  A{};
A<1>=2> a;
is not A<1> =2> a;
I bet we can't treat at least >= as terminating template argument, perhaps we
could go back to it if tentative parsing with >= didn't work out.
In any case, not a GCC 12 material as not a regression.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

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

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

--- Comment #34 from Eric Botcazou  ---
> For the X / bool_range_Y is X. case I think just !flag_non_call_exceptions
> would be better.  If @1 has boolean range and is known to be non-zero, it is
> known to be 1, so we should be optimizing it elsewhere, that is the constant
> case.

OK, adjusted and successfully tested on x86-64/Linux.

> path isolation is already guarding is_divmod_with_given_divisor calls with
> !cfun->can_throw_non_call_exceptions.

Indeed.

> Can you try to rewrite the
> unsigned
> foo (unsigned x, unsigned y)
> {   
>   if (x >= 2)   
> return 0;   
>   if (x == 1)   
> y += 4; 
>   return y / x; 
> }   
> 
> testcase I've posted into Ada and see if it will optimize away the division
> in evrp or vrp?

For:

with System.Unsigned_Types; use System.Unsigned_Types;

function F (X, Y : Unsigned) return Unsigned is
begin
  if X >=2 then
return 0;
  elsif X = 1 then
return 2 * Y;
  else
return Y / X;
  end if;
end;

I get with -O2 -gnatp:

_ada_f:
.LFB1:
.cfi_startproc
cmpl$1, %edi
ja  .L4
je  .L6
ud2
.p2align 4,,10
.p2align 3
.L4:
xorl%eax, %eax
ret
.p2align 4,,10
.p2align 3
.L6:
leal(%rsi,%rsi), %eax
ret

[Bug c++/104359] GCC Treats bool with value != 1 as falsey when picking branches

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
It is undefined but the issue/question keeps coming up.  The store that makes
the subsequent read undefined is clearly visible in the IL at all optimization
levels so it would be quite easy to issue a helpful warning for the code.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap incorrectly optimized away

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

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

--- Comment #35 from Jakub Jelinek  ---
I meant something like:
with System.Unsigned_Types; use System.Unsigned_Types;

function F (X, Y : Unsigned) return Unsigned is
  Z : Unsigned;
begin
  if X >=2 then
return 0;
  end if;
  Z := Y;
  if X = 1 then
Z := Y + 4;
  end if;
  return Z / X;
end;
and there evrp does with -O2 -gnatp optimize away the division.
Though that is likely the X / boolean_range_Y case which you've disabled.
In any case, I think you want to hear from Andrew/Aldy where exactly does
VRP/ranger assume UB on integer division by zero.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap incorrectly optimized away

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

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

--- Comment #36 from Eric Botcazou  ---
> with System.Unsigned_Types; use System.Unsigned_Types;
> 
> function F (X, Y : Unsigned) return Unsigned is
>   Z : Unsigned;
> begin
>   if X >=2 then
> return 0;
>   end if;
>   Z := Y;
>   if X = 1 then
> Z := Y + 4;
>   end if;
>   return Z / X;
> end;
> and there evrp does with -O2 -gnatp optimize away the division.

Indeed, I see this with GCC 11 & 12 (patched or not) but not with GCC 9 & 10.

> Though that is likely the X / boolean_range_Y case which you've disabled.
> In any case, I think you want to hear from Andrew/Aldy where exactly does
> VRP/ranger assume UB on integer division by zero.

Let's close this PR first, which is a 12 regression, and I'll open a PR for the
VRP issue in 11 & 12.

[Bug tree-optimization/104356] [12 Regression] divide by zero trap incorrectly optimized away

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #37 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #35)
> I meant something like:
>   return Z / X;

> and there evrp does with -O2 -gnatp optimize away the division.
> Though that is likely the X / boolean_range_Y case which you've disabled.
> In any case, I think you want to hear from Andrew/Aldy where exactly does
> VRP/ranger assume UB on integer division by zero.

That divide is remove by the simplifier because it determines that X has a
range of [0,1] and I believe the simplifer chooses to ignore the 0 under
various circumstances.

As for ranger, range-ops will return UNDEFINED for the range if x is known to
be [0,0].  This can be propagated around, and depending on how it ends up being
used as to what happens with it. 

This happens in range-ops.cc in operator_div::wi_fold()

  // If we're definitely dividing by zero, there's nothing to do.
  if (wi_zero_p (type, divisor_min, divisor_max))
{
  r.set_undefined ();
  return;
}

likewise the MOD operator does the same:

void
operator_trunc_mod::wi_fold (irange &r, tree type,
 const wide_int &lh_lb,
 const wide_int &lh_ub,
 const wide_int &rh_lb,
 const wide_int &rh_ub) const
{
  wide_int new_lb, new_ub, tmp;
  signop sign = TYPE_SIGN (type);
  unsigned prec = TYPE_PRECISION (type);

  // Mod 0 is undefined.
  if (wi_zero_p (type, rh_lb, rh_ub))
{
  r.set_undefined ();
  return;
}

[Bug tree-optimization/104356] [12 Regression] divide by zero trap incorrectly optimized away

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

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

--- Comment #38 from Jakub Jelinek  ---
(In reply to Andrew Macleod from comment #37)
> As for ranger, range-ops will return UNDEFINED for the range if x is known
> to be [0,0].  This can be propagated around, and depending on how it ends up
> being used as to what happens with it. 

Yeah, so e.g. with Eric's patch to disable the X / boolean_range_Y simplifier
in match.pd, won't the ranger perform the same optimization?
I mean with the wi_fold_in_parts, if range of the divisor has 2 values and one
of them is 0, won't it try to union range of X / 1 (range of X) and range of X
/ 0 (undefined) and yield range of X?  So say won't 7 / Y_with_bool_range yield
[7,7] ?