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

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> 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).

So I looked and it looks like I was wrong about the (old) java front-end, it
defaulted to always calling the function to do the divison and just throw in
those functions.

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

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

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).

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

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

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

--- Comment #3 from Andrew Pinski  ---
(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.

[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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
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.

So do we, with -fnon-call-exceptions, make division by zero throw an exception
instead of invoking undefined behavior?  (that is, on the non-exceptional
path we can still assume the divisor is not zero after the division)

Our docs say

@item -fnon-call-exceptions
@opindex fnon-call-exceptions
Generate code that allows trapping instructions to throw exceptions.
Note that this requires platform-specific runtime support that does
not exist everywhere.  Moreover, it only allows @emph{trapping}
instructions to throw exceptions, i.e.@: memory references or floating-point
instructions.  It does not allow exceptions to be thrown from
arbitrary signal handlers such as @code{SIGALRM}.  This enables
@option{-fexceptions}.

which doesn't mention integer division by zero or arbitrary instructions
of the ISA that may raise an exception under some circumstances (IIRC some
x86 ones raise exceptions on overflow for example).  Like the C standard
would allow the CPU to raise an exception on out-of-bound shifts (since
those invoke undefined behavior) - if the CPU would, would
-fnon-call-exceptions
imply it's now implementation defined (throw an exception?)?


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...).

[Bug target/104335] [12 regression] build failure if go is included in languages after r12-6747

[rdapp at linux dot ibm.com via Gcc-bugs]

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

--- Comment #4 from rdapp at linux dot ibm.com ---
Hi Segher,

originally ifcvt would only pass e.g.

(unle (reg:SF 129 [ _29 ])
(reg/v:SF 118 [ highScore ]))

as condition to rs6000_emit_cmove via emit_conditional_move ().  (This is the
example from the ICE).

  dest = (reg/f:DI 122 [ bestFuzz$__object ])

The check 

  if (FLOAT_MODE_P (compare_mode) && !FLOAT_MODE_P (result_mode))

fails and we return false i.e. the expander fails and returns NULL_RTX. This is
fine as we will just not do anything with it in ifcvt.

Now with the patch rs6000_emit_cmove is passed

  (unle (reg:CCFP 153)
  (const_int 0 [0])).

This CC comparison has already been computed before so the backend actually
needs to do less work and could just use it without preparing a comparison.
This helps costing on the ifcvt side.

dest is the same as before but now we have

  FLOAT_MODE_P (compare_mode) == false

and

  if (FLOAT_MODE_P (compare_mode) && !FLOAT_MODE_P (result_mode))

not causing a return false.

We then call rs6000_emit_int_cmove which in turn calls rs6000_generate_compare.
There we try to

  emit_insn (gen_rtx_SET (compare_result,   
  gen_rtx_COMPARE (comp_mode, op0, op1)));

but ICE since the modes don't match or make sense.

>From an ifcvt point of view we would just expect a NULL_RTX if something cannot
be handled.  We did not pass CC compares to backends before, so I don't know
how reasonable this assumption is :)

[Bug target/104090] [10/11/12 Regression] powerpc: asm machine directive wrong for FSL processors

[sebastian.huber--- via Gcc-bugs]

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

Sebastian Huber  changed:

   What|Removed |Added

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

--- Comment #5 from Sebastian Huber  ---
Fixed on all relevant branches.

[Bug target/104090] [10/11/12 Regression] powerpc: asm machine directive wrong for FSL processors

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Sebastian Huber
:

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

commit r10-10435-gd568abb25fc799123168aac840372b28bb81f85d
Author: Sebastian Huber 
Date:   Tue Jan 18 12:44:53 2022 +0100

powerpc: Fix asm machine directive for some CPUs

For some CPUs, the assembler machine directive cannot be determined by ISA
flags.

gcc/

PR target/104090
* config/rs6000/rs6000.c (rs6000_machine_from_flags): Use also
rs6000_cpu.

[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 #5 from Andreas Krebbel  ---
Yes, that's the right fix I think. Thanks!
MVCLE is a shorter version of a loop doing MVCs but has some startup overhead.

[Bug c++/88164] Lambda is allowed to capture any constexpr variable without specifying any captures

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-02-03
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|Copy initialization of  |Lambda is allowed to
   |function argument not   |capture any constexpr
   |performed inside lambda |variable without specifying
   |when the argument is a  |any captures
   |constexpr block scope   |
   |variable.   |

--- Comment #3 from Andrew Pinski  ---
Confirmed. Though I don't know 100% this is invalid code.

[Bug c++/88164] Copy initialization of function argument not performed inside lambda when the argument is a constexpr block scope variable.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dragondreamer at live dot com

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

[Bug c++/95269] Lambda is allowed to capture any constexpr variable without specifying any captures

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 88164.

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

[Bug c++/88164] Copy initialization of function argument not performed inside lambda when the argument is a constexpr block scope variable.

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

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

--- Comment #1 from Andrew Pinski  ---
For test, clang rejects it with:
:15:18: error: variable 'a' cannot be implicitly captured in a lambda
with no capture-default specified
return f(a); // Unexpected: does not call the copy constructor, 
 ^
:13:17: note: 'a' declared here
constexpr A a{};
^
:14:19: note: lambda expression begins here
auto lambda = []{
  ^
:14:20: note: capture 'a' by value
auto lambda = []{
   ^
   a
:14:20: note: capture 'a' by reference
auto lambda = []{
   ^
   
:14:20: note: default capture by value
auto lambda = []{
   ^
   =
:14:20: note: default capture by reference
auto lambda = []{
   ^
   &

[Bug tree-optimization/50856] ARM: suboptimal code for absolute difference calculation

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #2 from Andrew Pinski  ---
This is a generic issue and not really arm related.
In phiopt4 for absolute_difference1 we have:
  _14 = (int) b_7(D);
  _12 = (int) a_6(D);
  if (a_6(D) > b_7(D))
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  iftmp.0_9 = _12 - _14;
  goto ; [100.00%]

   [local count: 536870913]:
  iftmp.0_8 = _14 - _12;

   [local count: 1073741824]:
  # iftmp.0_5 = PHI 



While for absolute_difference2 we have in phiopt1
  tmp_4 = (int) a_3(D);
  _1 = (int) b_5(D);
  tmp_6 = tmp_4 - _1;
  if (tmp_6 < 0)
goto ; [INV]
  else
goto ; [INV]

   :
  tmp_8 = _1 - tmp_4;

   :
  # tmp_2 = PHI 

absolute_difference2 is easier to handle, let me try to handle both cases/
The second case we have:

(a - b) < 0 ? (b - a) : (a - b)
Or:
(cond (lt (minus@0 @1 @2) zero_p) (minus @2 @1) @0)


The first case we have is more complex.

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

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
Instead of casting to long, wouldn't it be better just to use the proper format
for size_t, i.e. %zu?

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

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

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

Jason Merrill  changed:

   What|Removed |Added

 Depends on||55227
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Jason Merrill  ---
Fixed.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227
[Bug 55227] designated initializer for char array by string constant

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

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:501c4ee9fad68716497db4d96b63b801cc57b4a1

commit r12-7010-g501c4ee9fad68716497db4d96b63b801cc57b4a1
Author: Jason Merrill 
Date:   Wed Feb 2 17:49:02 2022 -0500

c++: dependent array bounds completion [PR104302]

The patch for PR55227 changed the minimal init-list handling in
cp_complete_array_type to a call to reshape_init, which broke on the
dependent initializer.  It occurred to me that trying to deduce the array
size from a dependent init-list is wrong in general, so let's just not.  I
also limited the reshape_init call to the case of a char array, as before
the patch for 55227; that's the only case where we want to strip a level of
braces from an array.

PR c++/104302

gcc/cp/ChangeLog:

* decl.cc (maybe_deduce_size_from_array_init): Give up
on type-dependent init.
(cp_complete_array_type): Only call reshape_init for character
array.

gcc/testsuite/ChangeLog:

* g++.dg/template/array35.C: New test.
* g++.dg/template/array36.C: New test.

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Closing as requested.

[Bug tree-optimization/104360] Failure to optimize abs pattern (x^(x<0?-1:0)) - (x<0?-1:0)

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

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

--- Comment #2 from Andrew Pinski  ---
Note it is easier to detect the vector version of this though:
  isN_3 = x_2(D) < { 0, 0, 0, 0, 0, 0, 0, 0 };
  x_4 = x_2(D) ^ isN_3;
  _5 = x_4 - isN_3;


Pattern here:
(minus @0 (bit_xor:c @0 (lt@1 @0 vertor_zero_p)))

than the scalar version:
  _10 = x_6(D) < 0;
  _11 = (int) _10;
  _12 = -_11;
  _1 = (short int) _12;
  x_7 = _1 ^ x_6(D);
  x.1_2 = (unsigned short) x_7;
  _3 = (unsigned short) _12;
  _4 = x.1_2 - _3;
  _8 = (i16) _4;

Because of the overflow and such.

If we used -fwrapv we get:
  _7 = x_3(D) < 0;
  _8 = (int) _7;
  _9 = -_8;
  _1 = (short int) _9;
  x_4 = _1 ^ x_3(D);
  _5 = x_4 - _1;

Where we could reduce _1 to just:
t = (short int) _7;
_1 = -t;


And then it is just pattern matching.

For int we get:
  _6 = x_2(D) < 0;
  _7 = (int) _6;
  _8 = -_7;
  x_3 = x_2(D) ^ _8;
  _4 = x_3 + _7;
Which should be easy to pattern match.

(plus:c (bit_xor:c @0 (neg (convert@1 (lt @0 zero_p @1)

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

[will at willusher dot io via Gcc-bugs]

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

--- Comment #2 from Will Usher  ---
Oh gotcha, then this can be closed.

[Bug tree-optimization/104360] Failure to optimize abs pattern (x^(x<0?-1:0)) - (x<0?-1:0)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Severity|normal  |enhancement
Summary|Failure to optimize abs |Failure to optimize abs
   |pattern on vector types |pattern (x^(x<0?-1:0)) -
   ||(x<0?-1:0)
   Keywords||missed-optimization
   Last reconfirmed||2022-02-03
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Even the scalar version is not optimized:
typedef short i16;

i16 abs_i16(i16 x)
{
auto isN = -(x < 0);

x ^= isN;
return x - isN;
}

Shouldn't be too hard to optimize for both.

What is funny is clang/LLVM does not catch the scalar version either unless you
do:
(x < i16{}) ? -1 : 0

[Bug tree-optimization/104360] New: Failure to optimize abs pattern on vector types

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 104360
   Summary: Failure to optimize abs pattern on vector types
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

#include 

typedef int16_t v8i16 __attribute__((vector_size(16)));

v8i16 abs_i16(v8i16 x)
{
auto isN = x < v8i16{};

x ^= isN;
return x - isN;
}

This (although I think v8i16 could be replaced with any integer vector type and
it still would work) can be optimized to using an abs instruction where
possible (such as `pabsw` on x86-64, or `abs` on aarch64)

PS: this doesn't even necessarily require an abs instruction. on standard
x86-64 with -O3, GCC manages just this:

abs_i16(short __vector(8)):
  pxor xmm1, xmm1
  pcmpgtw xmm1, xmm0
  pxor xmm0, xmm1
  psubw xmm0, xmm1
  ret

whereas LLVM outputs this:

abs_i16(short __vector(8)):
  pxor xmm1, xmm1
  psubw xmm1, xmm0
  pmaxsw xmm0, xmm1
  ret

which I'm pretty sure is better.

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is undefined behavior so anything can happen.
Why do you think GCC should act consistent here?

Using -fsanitize=undefined, I get:
/app/example.cpp:9:9: runtime error: load of value 255, which is not a valid
value for type 'bool'
/app/example.cpp:14:5: runtime error: load of value 255, which is not a valid
value for type 'bool'

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

[will at willusher dot io via Gcc-bugs]

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

Bug ID: 104359
   Summary: GCC Treats bool with value != 1 as falsey when picking
branches
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: will at willusher dot io
  Target Milestone: ---

The following code when compiled with -O0 (or no -O option), will incorrectly
take both if branches:

#include 
#include 

int main() {
bool b = false;
std::memset(, 255, 1);

if (!b) {
std::cout << "!b = true branch\n";
} else {
std::cout << "!b = false branch\n";
}
if (b) {
std::cout << "b = true branch\n";
} else {
std::cout << "b = false branch\n";
}
return 0;
}

the resulting incorrect output is:

!b = true branch
b = true branch

However, b's "value" is 255, which should evaluate to "true". Recompiling the
program with -O1 or higher results in the correct output:

!b = false branch
b = true branch

Looking at compiler explorer: https://godbolt.org/z/TeMvMEc19 , it looks like
the if (!b) branch is compiled to:

movzx   eax, BYTE PTR [rbp-1]
xor eax, 1
testal, al
je  .L2

Which will evaluate to true for values != 1

This version of the code: https://godbolt.org/z/rhrP5W36v adds a loop and we
can see in -O1 and higher, the condition looks to just be a comparison vs. 0:

cmp BYTE PTR [rbp+0+rbx], 0
jne .L2

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

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from qingzhe huang  ---
But clang can give similar clear message by pointing out the space.
Just like ">>" instead "> >" after c++98, I think GCC can do better to
recognize ">>=" is possible of "> >=". Just considering even though ">>" is one
token, still parser now consider the case of ">" and ">" as to two closing
brackets for two nested templates. 
My point is that even though ">>=" is one token, it doesn't prevent parser from
splitting the token into possible two tokens. Not always the longest match
algorithms in tokenization.

My suggestion is that how about we calculate all possible superset of all other
operators. For example, ">>=" is equivalent to ">" and ">=". Or ">>" and "=".
there are tokens who is using longest match to return only the longest ones. It
is just my naive thought.

[Bug c++/104358] New: Assignable template lambda as function parameter is incorrectly reduced to type of "int"

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

Bug ID: 104358
   Summary: Assignable template lambda as function parameter is
incorrectly reduced to type of "int"
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickhuang99 at hotmail dot com
  Target Milestone: ---

Please see code at https://www.godbolt.org/z/o3bxxsYPK
All other compilers parses this correctly.


#include 
#include 

using namespace std;

//1. I have a callback which happens to be an assignable lambda
template
using Lambda=decltype(+[](T){});
//  which is esstially a function pointer 
static_assert(is_same_v, void(*)(int)>);

//2. Here is my data handle function which takes a data and the callback 
template
auto foo(T&&, Lambda)->T;

//3. However, parser consider the callback as type of "int"
static_assert( ! is_same_v), int(*)(int&&, void(*)(int))>);
// lambda type is always considered as "int"
static_assert(is_same_v), int(*)(int&&, int)>);
static_assert(is_same_v), bool(*)(bool&&, int)>);

// this is impossible as callback CANNOT be "int"
static_assert( ! is_same_v, int>);



//4. This won't happen for a traditional function pointer
template
using FunPtr=void(*)(T);
static_assert(is_same_v, void(*)(int)>);

//5. let's define a similar function with callback
template
auto bar(T&&, FunPtr)->T;
// there is no way for parser to consider callback as type of "int"
static_assert(is_same_v), int(*)(int&&, void(*)(int))>);

[Bug tree-optimization/104357] Failure to use csinv instead of mvn+csel where possible

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[Aarch64] Failure to use|Failure to use csinv
   |csinv instead of mvn+csel   |instead of mvn+csel where
   |where possible  |possible

--- Comment #3 from Andrew Pinski  ---
Oh by the way it looks like LLVM does not do a good job on x86 either. But with
my idea, GCC will do better than LLVM on x86 even.

[Bug tree-optimization/104357] [Aarch64] Failure to use csinv instead of mvn+csel where possible

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #2 from Andrew Pinski  ---
One thing I should note:
  _7 = x_3(D) >= 0;
  _6 = (unsigned char) _7;
  _8 = -_6;

Should be done on the gimple level as:
t = x_3(D) >> (sizeof(x_3(D))*8 - 1)
_8 = (unsigned char)t;

And then we can factor out the cast and I think it will produce the same code.

And yes it does, that is:
unsigned char stbi__clamp(int x)
{
   int t = x;
   if ((unsigned)x > 255) {
  t = x >> 31;
   }
   return t;
}

So Mine for GCC 13.

[Bug tree-optimization/104357] [Aarch64] Failure to use csinv instead of mvn+csel where possible

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-02-02
  Component|target  |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
This will get GCC closer to what clang/LLVM produces:
unsigned char stbi__clamp(int x)
{
   int t = x;
   if ((unsigned)x > 255) {
  if (x < 0) t =  0;
  else if (x > 255) t =  -1;
   }
   return t;
}

 CUT 
The zero-extends are due to the cast not being outside of the csel and the RTL
level is not really good at cross bb optimizations.
The gimple level looks like:
   [local count: 1073741824]:
  x.0_1 = (unsigned int) x_3(D);
  if (x.0_1 > 255)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  _7 = x_3(D) >= 0;
  _6 = (unsigned char) _7;
  _8 = -_6;
  goto ; [100.00%]

   [local count: 536870913]:
  _4 = (unsigned char) x_3(D);

   [local count: 1073741824]:
  # _2 = PHI <_8(3), _4(4)>
  return _2;

Which in theory could be improved to the what I gave above.
The gimple level has no knowledge of the rtl/target level that to do - in
unsigned, you need to a zero extend still.

[Bug c++/100588] Destroying delete shouldn't be called if constructor throws

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

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||12.0

--- Comment #2 from Jason Merrill  ---
Fixed for GCC 12 so far.

[Bug target/104357] New: [Aarch64] Failure to use csinv instead of mvn+csel where possible

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 104357
   Summary: [Aarch64] Failure to use csinv instead of mvn+csel
where possible
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

unsigned char stbi__clamp(int x)
{
   if ((unsigned)x > 255) {
  if (x < 0) return 0;
  if (x > 255) return 255;
   }
   return x;
}

With -O3, GCC outputs this (on aarch64):

stbi__clamp(int):
  mvn w1, w0
  cmp w0, 256
  and w0, w0, 255
  asr w1, w1, 31
  and w1, w1, 255
  csel w0, w0, w1, cc
  ret

LLVM instead outputs this:

stbi__clamp(int):
  asr w8, w0, #31
  cmp w0, #255
  csinv w0, w0, w8, ls
  ret

I don't know if the `and`s are there because of ABI differences, but it seems
to me like the `mvn` can definitely be replaced by using `csinv` instead of
`csel`.

[Bug c++/104300] [12 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2977 since r12-6326-ge948436eab818c52

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
So let's guard the optimization on !flag_non_call_exceptions or so?
The libgcc2.c
  if (d0 == 0)
d0 = 1 / d0;/* Divide intentionally by zero.  */
cases IMHO just should hide it from the optimizers.

[Bug target/104335] [12 regression] build failure if go is included in languages after r12-6747

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

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

--- Comment #3 from Segher Boessenkool  ---
Hi Robin,

Can you please explain what really happens now?  What arguments
rs6000_emit_cmove
is called with, and when that goes wrong?

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

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

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

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

Bug ID: 104356
   Summary: [12 Regression] divide by zero trap is being removed
now when it should not be in some cases
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Created attachment 52335
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52335=edit
gnat.dg/div_zero.adb

>From https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589490.html

Right, for example in Ada where we now happily turn a division by zero, which 
should raise an exception with -gnatp, into nonsense.  Do we really need this 
rather useless optimization in GCC?  Blindly mimicing LLVM is not a reason...

I have installed the attached testcase, which now fails because of the change.

* gnat.dg/div_zero.adb: New test.

[Bug fortran/100196] [9/10/11/12 Regression] ICE in reduce_binary_ca, at fortran/arith.c:1364

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

[Bug fortran/91728] Accepts array with wrong shape in a structure constructor

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
   Priority|P3  |P4
   Target Milestone|--- |10.4

--- Comment #2 from anlauf at gcc dot gnu.org ---
Both testcases in comment#0 are now rejected on 10/11/12:

pr91728-z1.f90:7:8:

7 |   x = t([1.0])
  |1
Error: The shape of component 'a' in the structure constructor at (1) differs
from the shape of the declared component for dimension 1 (1/3)

I assume this PR is a duplicate of another one that got fixed recently.

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

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/104344] Suboptimal -Os code for manually unrolled loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug rtl-optimization/68212] Loop unroller breaks basic block frequencies

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

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

--- Comment #9 from pthaugen at gcc dot gnu.org ---
The problem can be seen in the loop2_unroll dump:

pthaugen@pike:~/temp/pr68212$ grep "Invalid sum of" simple.c.272r.loop2_unroll 
;; Invalid sum of incoming counts 285685646 (estimated locally), should be
212627725 (estimated locally)
;; Invalid sum of incoming counts 32061393 (estimated locally), should be
105119324 (estimated locally)

[Bug middle-end/95115] RISC-V 64: inf/inf division optimized out, invalid operation not raised

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.4
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
  Known to work||10.3.1, 11.2.1, 12.0

--- Comment #13 from Andrew Pinski  ---
Fixed so closing.

[Bug rtl-optimization/68212] Loop unroller breaks basic block frequencies

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

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

pthaugen at gcc dot gnu.org changed:

   What|Removed |Added

 CC||guojiufu at gcc dot gnu.org,
   ||pthaugen at gcc dot gnu.org

--- Comment #8 from pthaugen at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #7)
> (In reply to Pat Haugen from comment #4)
> > Author: pthaugen
> > Date: Fri Oct 14 17:10:18 2016
> > New Revision: 241170
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=241170=gcc=rev
> > Log:
> > PR rtl-optimization/68212
> > * cfgloopmanip.c (duplicate_loop_to_header_edge): Use preheader edge
> > frequency when computing scale factor for peeled copies.
> > * loop-unroll.c (unroll_loop_runtime_iterations): Fix freq/count
> > values for switch/peel blocks/edges.
> 
> Repeating Martin's question.  Pat, is this PR fixed with your patch or is
> there more to do?

No, there are still problems. The patch noted fixed the count/probability for
the peeled switch/case blocks created before entering the unrolled loop. But
the counts for the loop header/exit blocks are still incorrect. The last
activity I know of concerning that problem was the patch by Jiufu Guo here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-February/539594.html. Not sure
if he has any more input here.

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

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #4)
> No, whole >>= is one token (CPP_RSHIFT_EQ).

Oh you are correct, I misread/misremembered the tokens.

[Bug target/102584] [OpenRISC] backend generates wrong halfword constant

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

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

Stafford Horne  changed:

   What|Removed |Added

 CC||shorne at gcc dot gnu.org
   Last reconfirmed||2022-02-02
   Assignee|unassigned at gcc dot gnu.org  |shorne at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #2 from Stafford Horne  ---
I confirm this looks strange. It seems to be due to not handling some case for
HImode in or1k_expand_move, see below.

Is this causing any actual issue?  As I see it the result is that the registers
will be loaded with f123 instead of f123, but if using HImode only the
lower 16-bits will be used. I confirmed with some simple tests.

void
or1k_expand_move (machine_mode mode, rtx op0, rtx op1)
{
  if (MEM_P (op0))
{ 
  if (!const0_operand (op1, mode))
op1 = force_reg (mode, op1);
}
  else if (mode == QImode || mode == HImode)
{ 
  /* ??? Maybe promote MEMs and CONST_INT to SImode,
 and then squish back with gen_lowpart.  */
}
  else
{   
...
}
  // NOTE at this point op0 and op1 are, checked using print_rtl()
  // (reg:HI 3 r3)
  // (const_int -3805 [0xf123])
  emit_insn (gen_rtx_SET (op0, op1));
}

[Bug tree-optimization/104288] [11/12 Regression] EVRP null pointer check removal for strcmp (and maybe others) is not flow senative

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #9 from Andrew Macleod  ---
 risk/churn.
> >  At least that is what I'M currently trying.  would this be OK?
> 
> Let's see what you can come up with.


> (which is why I really did like to have the old EVRP since conceptually
> it's easy to have a very fine-grained "context")
> 
> Practically I think it's OK for true on-demand users to have the
> less precise per-BB non-NULL data.  But the value-range passes
> should really be able to keep a precise per-stmt "context".
> 
> Did I say I liked the old EVRP way of doing things? ;)

Intention has always been to introduce a range_after_stmt to the API for
side-effects, which would merge some aspects of the way EVRP did things.

I have a patchset which I will submit shortly.. once everything passes mustard.
Its actually not that significant of a change.

Ranger currently tracks non-null for an ssa-name in blocks with a single bit. 
I change that to 2 bits so we can tell if all uses in the block have the
non-null property, or if there are some uses which do not have the property.

range-on-entry is changed to only check the dominators, and range-of-expr is
changed to only apply the non-null property if the entire block has only uses
with the non-null property.

After trying to simply/fold each statement in the domwalk, I now check if the
statement sets the non-null property. If so, then mark this block as non-null
throughout, and any further queries through range_of_expr within this block
will now pick up the non-null property. 

This allows us the flexibility of EVRPs granular walk, while remaining
conservative with any on demand clients.  This also solves the problematic
testcase I showed earlier, producing the desired:
  _1 = p_3(D) == 0B;
  _2 = (int) _1;
  h (_2);
  foo (p_3(D));
  return;

Anyway, patch coming soon. I believe it to be low risk as the changes are all
localized, and results should always be more conservative with the additonal 
granularity.

[Bug analyzer/104270] -Wanalyzer-use-of-uninitialized-value is incorrectly suppressed by -ftrivial-auto-var-init=

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r12-7007-gfb45d8e692d41d0d5d0fea56791d5dca448009c5
Author: David Malcolm 
Date:   Wed Feb 2 16:45:29 2022 -0500

docs: mention analyzer interaction with -ftrivial-auto-var-init [PR104270]

gcc/ChangeLog:
PR analyzer/104270
* doc/invoke.texi (-ftrivial-auto-var-init=): Add reference to
-Wanalyzer-use-of-uninitialized-value to paragraph documenting that
-ftrivial-auto-var-init= doesn't suppress warnings.

Signed-off-by: David Malcolm 

[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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
No, whole >>= is one token (CPP_RSHIFT_EQ).
>=, >>= and >> are the only tokens that start with > character, and I think we 
>only handle >> specially (e.g. because in C++11 it is valid to have a>
instead of a > ).

[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

   Keywords||needs-bisection
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=103852

--- Comment #2 from Andrew Pinski  ---
But see PR 103852 (and CWG1286) of why this is still valid code.

So just need to find out which patch fixed the ICE then.

[Bug libstdc++/103934] std::atomic_flag: multiple C++20 functions missing

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rodgertq at gcc dot 
gnu.org
   Last reconfirmed||2022-02-02
 Status|UNCONFIRMED |ASSIGNED

[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 #1 from Andrew Pinski  ---
So the trunk, GCC is able to compile this.
clang gives the following error though:
:328:11: error: alias template 'SISpeed' requires template arguments;
argument deduction only allowed for class templates

[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 #4 from Jakub Jelinek  ---
The mvcle instructions actually aren't guarded by TARGET_MVCLE, they are
TARGET_64BIT || !TARGET_ZARCH
or
!TARGET_64BIT && TARGET_ZARCH
which means available everywhere, so TARGET_MVCLE seems just like an
optimization hint, defaulted for -Os, but which can be set separately.
So, I'd say we should use
  if ((caller_opts->x_target_flags
   & ~(MASK_SOFT_FLOAT | MASK_HARD_DFP | MASK_MVCLE))
  != (callee_opts->x_target_flags
  & ~(MASK_SOFT_FLOAT | MASK_HARD_DFP | MASK_MVCLE)))
ret = false;
or so.

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|better error message for|better error message for
   |parsing error when >= ends  |parsing error when >= or >>
   |a template variable.|ends a template variable.

--- Comment #3 from Andrew Pinski  ---
(In reply to qingzhe huang from comment #2)
> A slightly different case with operator ">=" after template-id causing
> identical error message is: https://www.godbolt.org/z/7ajvfM4rb
> 
> #include 
> 
> template
> constexpr std::size_t zero=0;
> 
> template
> constexpr bool Bool=zero>=0;

Right in this case >> is the token. these cases just need to be special cased
really in the parser itself which is what clang does.

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

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from qingzhe huang  ---
A slightly different case with operator ">=" after template-id causing
identical error message is: https://www.godbolt.org/z/7ajvfM4rb

#include 

template
constexpr std::size_t zero=0;

template
constexpr bool Bool=zero>=0;

:7:21: error: parse error in template argument list
7 | constexpr bool Bool=zero>=0;
  | ^~
Compiler returned: 1

[Bug c++/104343] improved error message for passing overloaded function to variadic-argument function

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
Summary|Too many arguments error|improved error message for
   |reported for a  |passing overloaded function
   |variadic-argument function  |to variadic-argument
   |if std::endl is passed  |function

[Bug middle-end/104355] Misleading -Warray-bounds documentation says "always out of bounds"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-02-02
 Ever confirmed|0   |1

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

[Bug fortran/100196] [9/10/11/12 Regression] ICE in reduce_binary_ca, at fortran/arith.c:1364

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
I do not see the ICE for current 12/11/10 but get:

pr100196-z1.f90:3:22:

3 |   real, parameter :: b = 1 + [a]
  |  1
Error: Incompatible ranks 0 and 1 in assignment at (1)

and

pr100196-z5.f90:3:25:

3 |   real, parameter :: b(1) = 1 + [a]
  | 1
Error: Different shape for array assignment at (1) on dimension 1 (1 and 0)

The issue is still present on 9-branch, though.

[Bug ada/104354] ICE with Partition_Elaboration_Policy (Sequential)

[simon at pushface dot org via Gcc-bugs]

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

--- Comment #1 from simon at pushface dot org ---
Created attachment 52334
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52334=edit
GCC 12-compatible RTS

[Bug middle-end/104355] New: Misleading -Warray-bounds documentation says "always out of bounds"

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

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

Bug ID: 104355
   Summary: Misleading -Warray-bounds documentation says "always
out of bounds"
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

-Warray-bounds
  -Warray-bounds=n
  This option is only active when -ftree-vrp is active
  (default for -O2 and above). It warns about subscripts
  to arrays that are always out of bounds. This warning
  is enabled by -Wall.

It's not true that it warns for "always out of bounds", as that implies no
false positives.

[Bug ada/104354] New: ICE with Partition_Elaboration_Policy (Sequential)

[simon at pushface dot org via Gcc-bugs]

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

Bug ID: 104354
   Summary: ICE with Partition_Elaboration_Policy (Sequential)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---

Created attachment 52333
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52333=edit
Demonstrator (needs RTS)

The attached ravenscar-sfp-stm32f4.zip contains a version of the Alire
gnat_arm_elf_11.2.1_9343d45f runtime, edited to build with GCC
12.0.1.

The attached sem_ch8.zip contains demo.ad[bs] and enough RTS code from
Cortex GNAT RTS at https://github.com/simonjwright/cortex-gnat-rts to
allow compiling demo.adb, which uses Ada.Containers.Bounded_Vectors,
to demonstrate the problem.

The command

   $ gprbuild -c -u -f demo.adb --target=arm-eabi
--RTS=/Users/simon/tmp/ravenscar-sfp-stm32f4

(note, the --RTS= switch will have to be changed) results in

   +===GNAT BUG DETECTED==+
   | 12.0.1 20220128 (experimental) (arm-eabi) Program_Error sem_ch8.adb:5773
explicit raise|
   | Error detected at demo.adb:21:14 |
   | Compiling /Users/simon/tmp/bugs/gcc12/sem_ch8/arm-eabi//demo.adb |
   | Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
   | Use a subject line meaningful to you and us to track the bug.|
   | Include the entire contents of this bug box in the report.   |
   | Include the exact command that you entered.  |
   | Also include sources listed below.   |
   +==+

This error does not occur if the line
   pragma Partition_Elaboration_Policy (Sequential);
is removed from demo.ads (the compilation fails because of other missing
components).

[Bug fortran/104331] [10/11 Regression] ICE in gfc_simplify_eoshift, at fortran/simplify.cc:2590

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed.

[Bug fortran/104331] [10/11 Regression] ICE in gfc_simplify_eoshift, at fortran/simplify.cc:2590

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

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

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

https://gcc.gnu.org/g:323e72a83d417b230c2d93455fa09a4b66614c2a

commit r10-10433-g323e72a83d417b230c2d93455fa09a4b66614c2a
Author: Harald Anlauf 
Date:   Tue Feb 1 21:36:42 2022 +0100

Fortran: error recovery when simplifying EOSHIFT

gcc/fortran/ChangeLog:

PR fortran/104331
* simplify.c (gfc_simplify_eoshift): Avoid NULL pointer
dereference when shape is not set.

gcc/testsuite/ChangeLog:

PR fortran/104331
* gfortran.dg/eoshift_9.f90: New test.

(cherry picked from commit 447047a8f95c6bf4b1873f390c833e91aa8af18c)

[Bug fortran/104331] [10/11 Regression] ICE in gfc_simplify_eoshift, at fortran/simplify.cc:2590

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

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

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

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

commit r11-9535-gf4aa5a3e95ba106f3149157a0278616f7a5fd192
Author: Harald Anlauf 
Date:   Tue Feb 1 21:36:42 2022 +0100

Fortran: error recovery when simplifying EOSHIFT

gcc/fortran/ChangeLog:

PR fortran/104331
* simplify.c (gfc_simplify_eoshift): Avoid NULL pointer
dereference when shape is not set.

gcc/testsuite/ChangeLog:

PR fortran/104331
* gfortran.dg/eoshift_9.f90: New test.

(cherry picked from commit 447047a8f95c6bf4b1873f390c833e91aa8af18c)

[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

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

Untested fix.

[Bug c/104353] New: ppc64le: Apparent reliance on undefined behavior of xvcvdpsxws

[ckk at kvr dot at via Gcc-bugs]

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

Bug ID: 104353
   Summary: ppc64le: Apparent reliance on undefined behavior of
xvcvdpsxws
   Product: gcc
   Version: 11.2.0
   URL: https://github.com/numpy/numpy/issues/20964#issuecomme
nt-1027865665
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ckk at kvr dot at
  Target Milestone: ---

Created attachment 52331
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52331=edit
Minimal test case for reproduction

I ran into a strange numpy error on ppc64le that only occurred inside a ppc64le
QEMU instance. In short, casting arrays of i doubles 1.0 to ints 1 worked as
expected on native hardware, but produced the following bogus results when
running inside a VM:

i = 1:   1
i = 2:   1 1
i = 3:   1 1 1
i = 4:   0 0 0 0
i = 5:   0 0 0 0 1
i = 6:   0 0 0 0 1 1
i = 7:   0 0 0 0 1 1 1
i = 8:   0 0 0 0 0 0 0 0
i = 9:   0 0 0 0 0 0 0 0 1
...


Guided by the numpy folks, a SIMD issue was suspected, and I managed to create
a minimal test case (attached here) with which this could be reproduced. It
only occurs with -O3.

I then filed an issue with QEMU, where the issue was quickly rejected. This led
to further analysis by the numpy folks. There, it was discovered that GCC is
apparently relying on undefined behavior of the xvcvdpsxws instruction, which
happened to work on native hardware because it happen to exhibit that behavior.

I'm only summarizing here; there's a great analysis in detail, and a much
better test case, on the GitHub issue, which I have linked in the URL as I'd
prefer not to reproduce the author's work here.

[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|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |12.0
 CC||jakub at gcc dot gnu.org
   Priority|P3  |P4

[Bug target/104090] [10/11/12 Regression] powerpc: asm machine directive wrong for FSL processors

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Sebastian Huber
:

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

commit r11-9534-g3cb53c10831be59d967d9dce8e7980fee4703500
Author: Sebastian Huber 
Date:   Tue Jan 18 12:44:53 2022 +0100

powerpc: Fix asm machine directive for some CPUs

For some CPUs, the assembler machine directive cannot be determined by ISA
flags.

gcc/

PR target/104090
* config/rs6000/rs6000.c (rs6000_machine_from_flags): Use also
rs6000_cpu.

[Bug middle-end/104076] bogus -Wdangling-pointer on a conditional

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

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

--- Comment #5 from Martin Sebor  ---
Unlike the false positive -Wuse-after-free in pr104232, the instance of
-Wdangling-pointer in this case (a PHI argument) is intentional so that we
diagnose problems like those in the request for it (pr63272), or in this more
involved test case:

void warn_cond_if (int i, int n)
{
  int *p;
  if (i)
{
  int a[] = { 1, 2 }; // { dg-message "'a' declared" "note" }
  sink (a);
  p = a;
}
  else
p = (int*)malloc (n);

  sink (p);   // { dg-warning "dangling pointer 'p' to 'a' may
be used" }
}

I could add another level to -Wdangling-pointer to separately control uses in
equality expressions, for consistency with -Wuse-after-free.

[Bug fortran/104352] ICE in gfc_conv_intrinsic_anyall, at fortran/trans-intrinsic.cc:4481 (etc.)

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

Intrinsic "any" in above test files can be replaced with e.g.

$ cat za1.f90
program p
   integer, parameter :: a(0) = 1
   print *, all(a(1:1) == 1)
   print *, any(a(1:1) == 1)
   print *, count(a(1:1) == 1)
   print *, is_contiguous(a(1:1) == 1)
   print *, parity(a(1:1) == 1)
   print *, shape(a(1:1) == 1)
   print *, size(a(1:1) == 1)
   print *, ubound(a(1:1) == 1)
end


Other variants also affect intrinsics like iany, iall, ...

$ cat zb1.f90
program p
   integer, parameter :: a(0) = 1
   print *, iall(a(1:1))
   print *, iany(a(1:1))
   print *, iparity(a(1:1))
   print *, maxval(a(1:1))
   print *, minval(a(1:1))
   print *, product(a(1:1))
   print *, sum(a(1:1))
end


Another modification pattern hits minloc, macloc, ...

$ cat zc1.f90
program p
   integer, parameter :: a(0) = 1
   print *, ibclr(a(1:1), 1)
   print *, ibset(a(1:1), 1)
   print *, max(a(1:1), 1)
   print *, max0(a(1:1), 1)
   print *, maxloc(a(1:1), 1)
   print *, min(a(1:1), 1)
   print *, min0(a(1:1), 1)
   print *, minloc(a(1:1), 1)
end


or ...

$ cat zd1.f90
program p
   real, parameter :: a(0) = 1
   print *, dot_product(a(1:1), a(1:1))
   print *, norm2(a(1:1))
end
subroutine s
   complex, parameter :: a(0) = 1
   print *, dot_product(a(1:1), a(1:1))
   print *, conjg(a(1:1))
end

[Bug fortran/104352] New: ICE in gfc_conv_intrinsic_anyall, at fortran/trans-intrinsic.cc:4481 (etc.)

[gscfq--- via Gcc-bugs]

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

Bug ID: 104352
   Summary: ICE in gfc_conv_intrinsic_anyall, at
fortran/trans-intrinsic.cc:4481 (etc.)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   integer, parameter :: a(0) = 1
   print *, any(a(1:1) == 1)
end

$ cat z2.f90
program p
   integer, parameter :: a(0) = 1
   print *, any(a(:1) == 1)
end


$ cat z3.f90
program p
   integer, parameter :: a(0) = 1
   print *, any(a(0:0) == 1)
end


$ cat z4.f90
program p
   integer, parameter :: a(0) = 1
   print *, any(a(0:1) == 1)
end


$ gfortran-12-20220130 -c z1.f90
z1.f90:3:18:

3 |print *, any(a(1:1) == 1)
  |  1
Warning: Lower array reference at (1) is out of bounds (1 > 0) in dimension 1
z1.f90:3:18:

3 |print *, any(a(1:1) == 1)
  |  1
Warning: Lower array reference at (1) is out of bounds (1 > 0) in dimension 1
z1.f90:3:28:

3 |print *, any(a(1:1) == 1)
  |1
internal compiler error: in gfc_conv_intrinsic_anyall, at
fortran/trans-intrinsic.cc:4481
0x7f5fb3 gfc_conv_intrinsic_anyall
../../gcc/fortran/trans-intrinsic.cc:4481
0x802c56 gfc_conv_intrinsic_anyall
../../gcc/fortran/trans-intrinsic.cc:4463
0x802c56 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.cc:10228
0x7d6dba gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.cc:9398
0x7de952 gfc_conv_expr_reference(gfc_se*, gfc_expr*, bool)
../../gcc/fortran/trans-expr.cc:9544
0x808f57 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.cc:2581
0x7a6067 trans_code
../../gcc/fortran/trans.cc:2136
0x806a3e build_dt
../../gcc/fortran/trans-io.cc:2025
0x7a6047 trans_code
../../gcc/fortran/trans.cc:2108
0x7cf19e gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7654
0x751efe translate_all_program_units
../../gcc/fortran/parse.cc:6651
0x751efe gfc_parse_file()
../../gcc/fortran/parse.cc:6938
0x79eecf gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:216

[Bug fortran/104351] ICE in gfc_generate_initializer, at fortran/expr.cc:5140

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

Without a result-name :


$ cat z2.f90
program p
   implicit none
   type t
   end type
   type(t) :: f
contains
   real function f()
  f = 0.0
   end
end


$ gfortran-12-20220130 -c z2.f90
z2.f90:7:20:

7 |real function f()
  |1
Error: Symbol 'f' at (1) already has basic type of DERIVED
z2.f90:8:8:

8 |   f = 0.0
  |1
Error: Symbol 'f' at (1) has already been host associated
z2.f90:1:9:

1 | program p
  | 1
..
   10 | end
  |   2
Error: Two main PROGRAMs at (1) and (2)

[Bug fortran/104351] New: ICE in gfc_generate_initializer, at fortran/expr.cc:5140

[gscfq--- via Gcc-bugs]

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

Bug ID: 104351
   Summary: ICE in gfc_generate_initializer, at
fortran/expr.cc:5140
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :
(name conflict)


$ cat z1.f90
program p
   implicit none
   type t
   end type
   type(t) :: f
contains
   real function f() result(z)
  z = 0.0
   end
end


$ gfortran-12-20220130 -c z1.f90
z1.f90:9:6:

9 |end
  |  1
internal compiler error: Segmentation fault
0xcc655f crash_signal
../../gcc/toplev.cc:322
0x6f484a gfc_generate_initializer(gfc_typespec*, bool)
../../gcc/fortran/expr.cc:5140
0x7d05b7 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7709
0x7cefcc gfc_generate_contained_functions
../../gcc/fortran/trans-decl.cc:5777
0x7cefcc gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7586
0x751efe translate_all_program_units
../../gcc/fortran/parse.cc:6651
0x751efe gfc_parse_file()
../../gcc/fortran/parse.cc:6938
0x79eecf gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:216

[Bug fortran/104350] New: ICE in gfc_array_dimen_size(): Bad dimension

[gscfq--- via Gcc-bugs]

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

Bug ID: 104350
   Summary: ICE in gfc_array_dimen_size(): Bad dimension
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   integer :: x(1) = 1
   integer :: k
   print *, product([(size(x, dim=k), k=0,rank(x))])
end


$ cat z2.f90
program p
   integer :: x(0) = 0
   integer :: k
   print *, product([(size(x, dim=k), k=0,rank(x))])
end


$ cat z3.f90
program p
   integer :: x(1) = 1
   integer :: k
   print *, product([(size(x, dim=k), k=1,2)])
end


$ cat z4.f90
program p
   integer :: x(1) = 1
   integer :: k
   print *, product([(size(x, dim=k), k=-3,3)])
end


$ gfortran-12-20220130 -c z1.f90
f951: internal compiler error: gfc_array_dimen_size(): Bad dimension
0x6ec739 gfc_report_diagnostic
../../gcc/fortran/error.cc:883
0x6ee2b7 gfc_internal_error(char const*, ...)
../../gcc/fortran/error.cc:1503
0x6bc99f gfc_array_dimen_size(gfc_expr*, int, __mpz_struct (*) [1])
../../gcc/fortran/array.cc:2574
0x77896f simplify_size
../../gcc/fortran/simplify.cc:7580
0x786995 gfc_simplify_size(gfc_expr*, gfc_expr*, gfc_expr*)
../../gcc/fortran/simplify.cc:7601
0x70276a do_simplify
../../gcc/fortran/intrinsic.cc:4676
0x70d538 gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.cc:4941
0x6f346c gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.cc:2220
0x6b9e11 expand_constructor
../../gcc/fortran/array.cc:1827
0x6ba0be expand_expr
../../gcc/fortran/array.cc:1685
0x6ba0be expand_iterator
../../gcc/fortran/array.cc:1755
0x6ba0be expand_constructor
../../gcc/fortran/array.cc:1798
0x6bc1f7 gfc_array_size(gfc_expr*, __mpz_struct (*) [1])
../../gcc/fortran/array.cc:2665
0x75e30f expression_shape
../../gcc/fortran/resolve.cc:5501
0x75e30f gfc_expression_rank(gfc_expr*)
../../gcc/fortran/resolve.cc:5575
0x75fbdf gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7205
0x763cbf gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:2217
0x763cbf resolve_actual_arglist
../../gcc/fortran/resolve.cc:2136
0x75f96e resolve_function
../../gcc/fortran/resolve.cc:3274
0x75f96e gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7169

[Bug fortran/104349] New: ICE in (tree_to_uhwi) gfc_conv_array_initializer, at fortran/trans-array.cc:6337

[gscfq--- via Gcc-bugs]

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

Bug ID: 104349
   Summary: ICE in (tree_to_uhwi) gfc_conv_array_initializer, at
fortran/trans-array.cc:6337
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :
(undefined value n)


$ cat z1.f90
module m
   character(n), parameter :: a(1) = 'a'
end


$ gfortran-12-20220130 -c z1.f90
f951: internal compiler error: in tree_to_uhwi, at tree.h:4677
0x7bca34 tree_to_uhwi(tree_node const*)
../../gcc/tree.h:4677
0x7bca34 gfc_conv_array_initializer(tree_node*, gfc_expr*)
../../gcc/fortran/trans-array.cc:6337
0x7ea120 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.cc:8379
0x7cb64b gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.cc:1944
0x7ce468 gfc_create_module_variable
../../gcc/fortran/trans-decl.cc:5244
0x789ca2 do_traverse_symtree
../../gcc/fortran/symbol.cc:4174
0x7cec6b gfc_generate_module_vars(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:5743
0x7a6544 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.cc:2309
0x751a9f translate_all_program_units
../../gcc/fortran/parse.cc:6638
0x751a9f gfc_parse_file()
../../gcc/fortran/parse.cc:6938
0x79eecf gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:216

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

[turningtides at outlook dot de via Gcc-bugs]

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

--- Comment #7 from Martin Turski  ---
ETA?

[Bug c++/104343] Too many arguments error reported for a variadic-argument function if std::endl is passed

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

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

--- Comment #5 from Jonathan Wakely  ---
Clang gives:

x.C:11:3: error: no matching function for call to 'Sprint'
  Sprint("B: off=", 2, " now=", 3, endl);
  ^~
x.C:5:13: note: candidate template ignored: substitution failure: deduced
incomplete pack 
for template parameter 'Args'
inline void Sprint(Args&&... args)
^
1 error generated.


The "(no value)" is the clue here.

EDG says:

"x.C", line 11: error: no instance of function template "Sprint" matches the
  argument list
argument types are: (const char [8], int, const char [6], int,
  )
Sprint("B: off=", 2, " now=", 3, endl);
^

1 error detected in the compilation of "x.C".


I'm surprised GCC doesn't say ""

[Bug c++/104343] Too many arguments error reported for a variadic-argument function if std::endl is passed

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

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

--- Comment #4 from Jonathan Wakely  ---
Further reduced:

void endl(char);
void endl(wchar_t);

template  inline void Sprint(Args&&...) { }

int main()
{
  Sprint("B: off=", 2, " now=", 3, endl);
}

[Bug c++/99859] constexpr evaluation with member function is incorrect

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||asorenji at gmail dot com

--- Comment #24 from Jonathan Wakely  ---
*** Bug 104348 has been marked as a duplicate of this bug. ***

[Bug c++/104348] Incorrect sorting in constexpr constructor

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is already fixed on the gcc-10 branch and in 11.1.0

Reduced to compile-time test:

#include
#include

class Test
{
public:
//for some reason, bug don't appear if std::string_view not wrapped in
another class
class Value
{
public:
constexpr Value(const char*str):data(str){}
constexpr bool operator<(const Value)const{return
data

[Bug fortran/104346] Problem with overloaded assignment when LHS is allocatable array

[vivekrao4 at yahoo dot com via Gcc-bugs]

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

--- Comment #1 from Vivek Rao  ---
It is explained at
https://community.intel.com/t5/Intel-Fortran-Compiler/Problem-with-overloaded-assignment-when-LHS-is-allocatable-array/m-p/1356757/highlight/true#M159812
that the code is not conforming, so this issue can be closed.

"In this case, the standard essentially places the onus on the program (and by
extension its author) to conform, the processor (compiler being part of it) is
not required to issue diagnostics.

And the issue is this: with the defined assignment as specified, the standard
semantics requires the 'ialloc` to be allocated to the right shape prior to
assignment on line 23: "ialloc = ["4","9"]".

You can retry with `allocate( ialloc(2) )` statement preceding the above
assignment and check the program response."

[Bug c++/104343] Too many arguments error reported for a variadic-argument function if std::endl is passed

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|WAITING |NEW

--- Comment #3 from Jonathan Wakely  ---
When creating the bug you were asked to read https://gcc.gnu.org/bugs which
makes it clear that a proper test case is required, not a snippet of incomplete
code.

Also, GCC 7 has been unsupported for a couple of years.

Here's a complete reproducer:

void endl(char);
void endl(wchar_t);

template 
inline Stream& Print(Stream& in) { return in;}

template 
inline Stream& Print(Stream& sout, Arg1&& arg1, Args&&... args)
{
return Print(sout, args...);
}

template 
inline void Sprint(Args&&... args)
{
int sout;
Print(sout, args...);
}

int main()
{
  Sprint("B: off=", 2, " now=", 3, endl);
}

x.C: In function ‘int main()’:
x.C:22:9: error: too many arguments to function ‘void Sprint(Args&& ...) [with
Args = {}]’
   22 |   Sprint("B: off=", 2, " now=", 3, endl);
  |   ~~^~~~
x.C:14:13: note: declared here
   14 | inline void Sprint(Args&&... args)
  | ^~

[Bug c++/104348] New: Incorrect sorting in constexpr constructor

[asorenji at gmail dot com via Gcc-bugs]

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

Bug ID: 104348
   Summary: Incorrect sorting in constexpr constructor
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asorenji at gmail dot com
  Target Milestone: ---

I have simple test code, that just sorting array of string_view wrapped in
another class. This array contain list of "1","2","3","4","5","6","7","8"
values and remains unchanged if code executed in runtime. Well, it's already
sorted from beginning. But if constexpr used and code executed it compile time,
I get 17256348 instead of 12345678. For very strangle reason, bug appear in
constexpr variable constructor, but disappear in constinit variable
constructor.

g++ --version - g++ (Debian 10.2.1-6) 10.2.1 20210110
Compile options - g++ -std=c++20 -Wall -Wextra main.cpp -o test
Code:

#include
#include
#include

class Test
{
public:
//for some reason, bug don't appear if std::string_view not wrapped in
another class
class Value
{
public:
constexpr Value(const char*str):data(str){}
constexpr bool operator<(const Value)const{return
data

[Bug c++/104343] Too many arguments error reported for a variadic-argument function if std::endl is passed

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

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

--- Comment #2 from Jonathan Wakely  ---
Your code is invalid. std::endl is an overloaded function, so you can't pass it
as an argument like that. The template argument cannot be deduced.

GCC's error could be improved though.

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

[dev at gutoehrlein dot eu via Gcc-bugs]

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

Bug ID: 104347
   Summary: internal compiler error-  default template arguments -
missing angle brackets
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dev at gutoehrlein dot eu
  Target Milestone: ---

Created attachment 52330
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52330=edit
code which crashes the compiler

command to compile:
g++ -o test -std=c++20 -O2 test.cpp
-
Version of g++: 11.2
OS: Ubuntu (Kernel: 5.13.0)
-
The code contains a missing "<>" in line 327. Line 328 (comment) contains the
correct code. g++ crashes with an internal compiler error instead of displaying
an error message.

Additional info:
* Can be also reproduced on https://godbolt.org/
* The current VS compiler also produces an internal compiler error.
* Clang 13 parses the file and displays the appropriate error message: 
  :327:11: error: alias template 'SISpeed' requires template arguments;
argument deduction only allowed for class templates
-
: In function 'int main(int, char**)':
:327:19: internal compiler error: Segmentation fault
  327 |   SISpeed v = l / t;
  |   ^
0x1786229 internal_error(char const*, ...)
???:0
0x7d2840 template_parms_to_args(tree_node*)
???:0
0x7d68ed do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
???:0
0x7002b6 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x7c47db c_parse_file()
???:0
0x896762 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

[Bug fortran/104346] New: Problem with overloaded assignment when LHS is allocatable array

[vivekrao4 at yahoo dot com via Gcc-bugs]

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

Bug ID: 104346
   Summary: Problem with overloaded assignment when LHS is
allocatable array
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

For the code 

module assignment_mod
implicit none
interface assignment(=)
   module procedure int_from_char
end interface
contains
elemental subroutine int_from_char(i,s)
integer, intent(out) :: i
character (len=*), intent(in) :: s
read (s,*) i
end subroutine int_from_char
end module assignment_mod
!
program test_assignment
use assignment_mod, only: assignment(=)
implicit none
integer :: j,k(2)
integer, allocatable :: ialloc(:)
j = "4"
print*,"j=",j
k = ["4","9"]
print*,"k=",k
ialloc = ["4","9"]
print*,"ialloc=",ialloc
end program test_assignment

compiling with GNU Fortran (GCC) 12.0.0 20211024 (experimental) from
equation.com and running gives

 j=   4
 k=   4   9

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Intel Fortran also has trouble with the code:
https://community.intel.com/t5/Intel-Fortran-Compiler/Problem-with-overloaded-assignment-when-LHS-is-allocatable-array/m-p/1356724/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufEtaNVBQV1dXUDkxOTBHfDEzNTY3MjR8U1VCU0NSSVBUSU9OU3xoSw#M159809
.

[Bug c/84052] Using Randomizing structure layout plugin in linux kernel compilation doesn't generate proper debuginfo

[mivicaf210 at mxclip dot com via Gcc-bugs]

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

Jordan Beaubien  changed:

   What|Removed |Added

 CC||mivicaf210 at mxclip dot com

--- Comment #6 from Jordan Beaubien  ---
This is a massive issue. https://www.plastererswollongong.com.au

[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

--- Comment #2 from Jakub Jelinek  ---
The first 2 testcases can be fixed with
--- openmp.cc.jj2   2022-01-21 11:01:12.458449420 +0100
+++ openmp.cc   2022-02-02 16:21:36.813563894 +0100
@@ -7757,6 +7757,7 @@ resolve_omp_atomic (gfc_code *code)
   if (code->op == EXEC_IF
  && code->block
  && code->block->op == EXEC_IF
+ && code->block->next
  && code->block->next->op == EXEC_ASSIGN)
{
  comp_cond = code->block->expr1;
The last 3 need other fixes.

[Bug c++/104255] parsing function signature fails when it uses a function parameter outside of an unevaluated context

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

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

--- Comment #5 from Patrick Palka  ---
(In reply to qingzhe huang from comment #4)
> (In reply to Patrick Palka from comment #2)
> 
> > 
> >   error: use of parameter outside function body before ‘)’ token
> > 
> > due to 'e' being used outside of an unevaluated context within the signature
> > of the function.
> 
> Sorry for my being unable to grasp your meaning before. Now I can see your
> point that the "e" of A is from declaration of parameter of function
> "g". Now that we agree the value from parameter clause should not be used in
> trailing return type, then it should also not be used in requires clause
> etc. 
> (https://eel.is/c++draft/basic.scope.param#1.3)
> But this works:
> 
> template
> auto f(int n) requires (n>0);

That's because the constraint-expression of a requires clause is an unevaluated
operand (wg21.link/temp.pre#9.sentence-4).  (Though I think this example is
strictly speaking ill-formed no diagnostic required because the constraint can
never be satisfied (wg21.link/temp.res.general#6.2).)

The check in question is in finish_id_expression_1:

  /* Also disallow uses of function parameters outside the function
 body, except inside an unevaluated context (i.e. decltype).  */
  if (TREE_CODE (decl) == PARM_DECL
  && DECL_CONTEXT (decl) == NULL_TREE
  && !cp_unevaluated_operand)
{
  *error_msg = G_("use of parameter outside function body");
  return error_mark_node;
}

> 
> This is violating our assumption. So, I am not convinced that 
> (https://eel.is/c++draft/basic.scope.param#note-1)
> "A function parameter cannot be used for its value within the
> parameter-declaration-clause" is really meaningful. Or I misunderstand it???

We should probably relax the above check to permit uses of function parameters
with empty types even outside of unevaluated contexts, since we don't really
care about the value of an empty type.

[Bug lto/104333] [11/12 Regression] ICE with -flto -Wl,-plugin-opt=debug

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed.

[Bug lto/104333] [11/12 Regression] ICE with -flto -Wl,-plugin-opt=debug

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Martin Liska
:

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

commit r11-9533-gfb812e0417adc20cac72986df3bf422ed007743c
Author: Martin Liska 
Date:   Wed Feb 2 14:21:51 2022 +0100

lto: fix error handling for -Wl,-plugin-opt=debug

When one uses something like: -Wl,-plugin-opt=debug,
we end up with lto1 WPA invocation that has 'debug'
on command line. We interpret that as input filename.

The patch moves resolution checking later so that we end up with
a reasonable error message:

lto1: fatal error: open debug failed: No such file or directory
compilation terminated.

PR lto/104333

gcc/lto/ChangeLog:

* lto-common.c (read_cgraph_and_symbols): Move resolution
checking for number of files later and report a reasonable
error message.
* lto-object.c (lto_obj_file_open): Make error fatal.

(cherry picked from commit 9a92e46c0e9a75cd14125493b8826d3e33dd0f67)

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

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

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

--- Comment #20 from rsandifo at gcc dot gnu.org  
---
(In reply to Jakub Jelinek from comment #19)
> Created attachment 52329 [details]
> gcc12-pr104334.patch
> 
> Patch doing ?h_range and related comparisons in widest_int.
Looks like a good approach to me FWIW.  You can use infix
operators instead of lts_p etc. for widest_ints, since widest_ints
always have enough bits for the sign.

[Bug lto/104333] [11/12 Regression] ICE with -flto -Wl,-plugin-opt=debug

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:9a92e46c0e9a75cd14125493b8826d3e33dd0f67

commit r12-7002-g9a92e46c0e9a75cd14125493b8826d3e33dd0f67
Author: Martin Liska 
Date:   Wed Feb 2 14:21:51 2022 +0100

lto: fix error handling for -Wl,-plugin-opt=debug

When one uses something like: -Wl,-plugin-opt=debug,
we end up with lto1 WPA invocation that has 'debug'
on command line. We interpret that as input filename.

The patch moves resolution checking later so that we end up with
a reasonable error message:

lto1: fatal error: open debug failed: No such file or directory
compilation terminated.

PR lto/104333

gcc/lto/ChangeLog:

* lto-common.cc (read_cgraph_and_symbols): Move resolution
checking for number of files later and report a reasonable
error message.
* lto-object.cc (lto_obj_file_open): Make error fatal.

[Bug analyzer/104270] -Wanalyzer-use-of-uninitialized-value is incorrectly suppressed by -ftrivial-auto-var-init=

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/104270] -Wanalyzer-use-of-uninitialized-value is incorrectly suppressed by -ftrivial-auto-var-init=

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:9b4eee5fd158c4ee75d1f1000debbf5082fb9b56

commit r12-6997-g9b4eee5fd158c4ee75d1f1000debbf5082fb9b56
Author: David Malcolm 
Date:   Fri Jan 28 11:02:09 2022 -0500

analyzer: stop -ftrivial-auto-var-init from suppressing uninit warnings
[PR104270]

GCC 12 has gained two features for dealing with uninitialized variables:

(a) a new -Wanalyzer-use-of-uninitialized-value warning within -fanalyzer
for interprocedural path-sensitive detection of ununit uses, and

(b) a new -ftrivial-auto-var-init option for mitigating some uses of
uninit variables

It turns out that using (b) was thwarting (a), as it led to -fanalyzer
seeing calls to IFN_DEFERRED_INIT, which -fanalyzer wasn't
special-casing, thus treating it as initializing the variables in
question, and thus silencing -Wanalyzer-use-of-uninitialized-value on
them.

invoke.texi says:

"GCC still considers an automatic variable that doesn't have an explicit
initializer as uninitialized, @option{-Wuninitialized} will still report
warning messages on such automatic variables."

and thus -Wanalyzer-use-of-uninitialized-value ought to as well.

This patch adds special-case handling to -fanalyzer for
IFN_DEFERRED_INIT,  so that -fanalyzer will warn on uninit uses of
variables that are mitigated by -ftrivial-auto-var-init.

gcc/analyzer/ChangeLog:
PR analyzer/104270
* region-model.cc (region_model::on_call_pre): Handle
IFN_DEFERRED_INIT.

gcc/testsuite/ChangeLog:
PR analyzer/104270
* gcc.dg/analyzer/uninit-trivial-auto-var-init-pattern.c: New
test.
* gcc.dg/analyzer/uninit-trivial-auto-var-init-uninitialized.c:
New test.
* gcc.dg/analyzer/uninit-trivial-auto-var-init-zero.c: New test.

Signed-off-by: David Malcolm 

[Bug tree-optimization/104344] Suboptimal -Os code for manually unrolled loop

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

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

--- Comment #3 from Richard Biener  ---
(In reply to Charles Nicholson from comment #2)
> For whatever it's worth, clang does recognize both forms and emit optimal
> assembly at -Os:
> 
> https://gcc.godbolt.org/z/sehxYb97E
> 
> cast_through_char_unrolled: # @cast_through_char_unrolled
>   movd eax, xmm0
>   ret
> cast_through_char_loop: # @cast_through_char_loop
>   movd eax, xmm0
>   ret

Yes, even with -fno-vectorize but not sure whether that disables all of it,
that is, not sure in which optimization phase it pattern matches this.

[Bug target/104345] nvptx: "regression" after "nvptx: Transition nvptx backend to STORE_FLAG_VALUE = 1"

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-02-02
 Ever confirmed|0   |1

--- Comment #1 from Roger Sayle  ---
Hi Torsten,
Thanks for the bug report.  The STORE_FLAG_VALUE=1 patch was one of a series to
dramatically improve the quality of nvptx code.  Alas not all of them have yet
been reviewed/approved, and it's likely these later improvements address the
quality regression you're seeing.

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

And one other related patch is that there's also a middle-end SUBREG
patch intended to improve code generation on nvptx is also pending at:

patchs: Simplify paradoxical subreg extensions of TRUNCATE
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578848.html



My guess is that patchq3+patchq4 above should (hopefully) resolve this
particular regression.  If you could give them a spin on your system
to see if they reduce register pressure sufficiently for this case,
that would be greatly appreciated.  As you can read in the above postings,
the total number of instructions/registers (after all of these changes)
should be dramatically reduced.

I'll see what I can do from my end.

[Bug tree-optimization/104344] Suboptimal -Os code for manually unrolled loop

[charles.nicholson at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Charles Nicholson  ---
For whatever it's worth, clang does recognize both forms and emit optimal
assembly at -Os:

https://gcc.godbolt.org/z/sehxYb97E

cast_through_char_unrolled: # @cast_through_char_unrolled
  movd eax, xmm0
  ret
cast_through_char_loop: # @cast_through_char_loop
  movd eax, xmm0
  ret

[Bug c++/104343] Too many arguments error reported for a variadic-argument function if std::endl is passed

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Please provide a full compilable testcase.

[Bug tree-optimization/104344] Suboptimal -Os code for manually unrolled loop

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-02-02
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
If you add -fopt-info to the compiler command you can see what happens:

> ./cc1 -quiet t.c -Os -fopt-info
t.c:21:21: optimized: Loop 1 distributed: split to 0 loops and 1 library calls.

we recognized the loop and made a memmove out of it which is then optimally
expanded

> ./cc1 -quiet t.c -O3 -fopt-info
t.c:10:10: optimized: basic block part vectorized using 16 byte vectors
t.c:21:21: optimized: Loop 1 distributed: split to 0 loops and 1 library calls.

here the same happens but in addition to that the unrolled stmts are
vectorized, producing the same effective result

Starting with GCC 12 vectorization will also happen at -O2 but not at -Os.
You can add -ftree-vectorize -fvect-cost-model=very-cheap to mimic what we
do at -O2 with -Os.

Note that vectorization can also increase code size, on x86 for example
because the instructions, even if there end up being less of them, have
a larger encoding.

Maybe also sth for -Oz vs. -Os and for general consideration of -O2 vs. -Os
and vectorization enablement.

The pattern itself could also be recognized by store-merging/bswap detection
(but the interleaving accesses can make the separate analysis of merging stores
and replacing the load difficult).

[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

--- Comment #19 from Jakub Jelinek  ---
Created attachment 52329
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52329=edit
gcc12-pr104334.patch

Patch doing ?h_range and related comparisons in widest_int.