[Bug libstdc++/110574] --enable-cstdio=stdio_pure is incompatible with LFS

2023-07-06 Thread keithp at keithp dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110574

--- Comment #5 from keithp at keithp dot com  ---
Seems like using fseeko would be a reasonable choice here -- while it's not in
ISO C, it is in POSIX 2017.

[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914

--- Comment #12 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #11)
> But I don't have any other notes on my change (nor a testcase).

So I found some notes and it is similar but still different.
We were expanding:
;; insn.j_format.target = D.21597_19;
Into
(insn 25 24 26 (set (reg:DI 220)
(lshiftrt:DI (reg:DI 196 [ D.21584 ])
(const_int 2 [0x2]))) arch/mips/kernel/jump_label.c:56 -1
 (nil))

(insn 26 25 0 (set (zero_extract:SI (reg/v:SI 208 [ insn ])
(const_int 26 [0x1a])
(const_int 6 [0x6]))
(subreg:SI (reg:DI 220) 4)) arch/mips/kernel/jump_label.c:56 -1
 (nil))

But the subreg there was incorrect.

In this case of this bug, the reg is DI rather than SI. I wonder why we have
that in the first place even though val is the size of SImode ...

[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #10)
> Created attachment 55496 [details]
> old patch against GCC 4.7
> 
> I am trying to find my notes on this old patch but our internal bug system
> has moved a few times and the project looks archived even.
> But I am pretty sure this is related to the problem at hand.

(note I had another patch before that which renamed store_bit_field_1 to
store_bit_field_2).

The code is now in store_bit_field_using_insv.
Here:
  else
{
  tmp = gen_lowpart_if_possible (op_mode, value1);
  if (! tmp)
tmp = gen_lowpart (op_mode, force_reg (value_mode, value1));
}
  value1 = tmp;
}

But I don't have any other notes on my change (nor a testcase).

[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914

--- Comment #10 from Andrew Pinski  ---
Created attachment 55496
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55496=edit
old patch against GCC 4.7

I am trying to find my notes on this old patch but our internal bug system has
moved a few times and the project looks archived even.
But I am pretty sure this is related to the problem at hand.

[Bug rtl-optimization/67736] Wrong optimization with -fexpensive-optimizations on mips64el

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67736

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.3

[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=67736

--- Comment #9 from Andrew Pinski  ---
(In reply to YunQiang Su from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > The initial RTL has a signed extend in there:
> > 
> > 
> > (insn 20 19 23 2 (set (reg/v:DI 200 [ val+-4 ])
> > (sign_extend:DI (subreg:SI (reg/v:DI 200 [ val+-4 ]) 4)))
> > "/app/example.cpp":7:29 -1
> >  (nil))
> > (jump_insn 23 20 24 2 (set (pc)
> > (if_then_else (le (subreg/s/u:SI (reg/v:DI 200 [ val+-4 ]) 4)
> > (const_int 0 [0]))
> > (label_ref 32)
> > (pc))) "/app/example.cpp":8:5 -1
> >  (int_list:REG_BR_PROB 440234148 (nil))
> >  -> 32)
> > 
> > 
> > Before combine also looks fine:
> > (insn 20 19 23 2 (set (reg/v:DI 200 [ val+-4 ])
> > (sign_extend:DI (subreg:SI (reg/v:DI 200 [ val+-4 ]) 4)))
> > "/app/example.cpp":7:29 235 {extendsidi2}
> >  (nil))
> 
> Yes. I noticed it. while in mips.md,  extendsidi2 is expanded to no
> instructions at all.

Right then the le should had a truncation before the use of SI mode here ...

[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value

2023-07-06 Thread syq at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914

--- Comment #8 from YunQiang Su  ---
(In reply to Andrew Pinski from comment #7)
> The initial RTL has a signed extend in there:
> 
> 
> (insn 20 19 23 2 (set (reg/v:DI 200 [ val+-4 ])
> (sign_extend:DI (subreg:SI (reg/v:DI 200 [ val+-4 ]) 4)))
> "/app/example.cpp":7:29 -1
>  (nil))
> (jump_insn 23 20 24 2 (set (pc)
> (if_then_else (le (subreg/s/u:SI (reg/v:DI 200 [ val+-4 ]) 4)
> (const_int 0 [0]))
> (label_ref 32)
> (pc))) "/app/example.cpp":8:5 -1
>  (int_list:REG_BR_PROB 440234148 (nil))
>  -> 32)
> 
> 
> Before combine also looks fine:
> (insn 20 19 23 2 (set (reg/v:DI 200 [ val+-4 ])
> (sign_extend:DI (subreg:SI (reg/v:DI 200 [ val+-4 ]) 4)))
> "/app/example.cpp":7:29 235 {extendsidi2}
>  (nil))

Yes. I noticed it. while in mips.md,  extendsidi2 is expanded to no
instructions at all.




```
;; Extension insns.
;; Those for integer source operand are ordered widest source type first.

;; When TARGET_64BIT, all SImode integer and accumulator registers
;; should already be in sign-extended form (see TARGET_TRULY_NOOP_TRUNCATION
;; and truncdisi2).  We can therefore get rid of register->register
;; instructions if we constrain the source to be in the same register as
;; the destination.
;;
;; Only the pre-reload scheduler sees the type of the register alternatives;
;; we split them into nothing before the post-reload scheduler runs.
;; These alternatives therefore have type "move" in order to reflect
;; what happens if the two pre-reload operands cannot be tied, and are
;; instead allocated two separate GPRs.  We don't distinguish between
;; the GPR and LO cases because we don't usually know during pre-reload
;; scheduling whether an operand will be LO or not.
(define_insn_and_split "extendsidi2"
  [(set (match_operand:DI 0 "register_operand" "=d,l,d")
(sign_extend:DI (match_operand:SI 1 "nonimmediate_operand" "0,0,m")))]
  "TARGET_64BIT"
  "@
   #
   #
   lw\t%0,%1"
  "&& reload_completed && register_operand (operands[1], VOIDmode)"
  [(const_int 0)]
{
  emit_note (NOTE_INSN_DELETED);
  DONE;
}
  [(set_attr "move_type" "move,move,load")
   (set_attr "mode" "DI")])
```

[Bug tree-optimization/110538] [14 Regression] Dead Code Elimination Regression since r14-368-ge1366a7e4ce

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110538

--- Comment #2 from Andrew Pinski  ---
So dom3 was able to optimize that via a jump threading before in GCC 13 but no
longer on the trunk (I don't understand why though).

Anyways the only pass which is able to optimize:
```
int f123(int a, int c, int i)
{
  int *d;
  if (a) d =  else d = 
  int e = d == 
  int f = d == 
  return e | f;
}
```
to `1` is PRE ...

But note
```
int g123();
int h123();
int f123_1(int a, int c, int i)
{
  int *d;
  if (a) d =  else d = 
  int e = d == 
  int f = d == 
  if (e | f)
return h123();
  return g123();
}
```
Still can be optimized by dom2 on the trunk (via jump threading).

So how did dom3 miss the original testcase 

[Bug tree-optimization/110538] [14 Regression] Dead Code Elimination Regression since r14-368-ge1366a7e4ce

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110538

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-07-07
 Status|UNCONFIRMED |NEW

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

In .optimized we get:
  # j_24 = PHI <(7), (3)>
  _2 = j_24 == 
  _22 =  == j_24;
  _23 = _2 | _22;

Obvious _23 is always 1.

[Bug target/106895] powerpc64 unable to specify even/odd register pairs in extended inline asm

2023-07-06 Thread npiggin at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

--- Comment #11 from Nicholas Piggin  ---
(In reply to Segher Boessenkool from comment #10)
> (In reply to Nicholas Piggin from comment #9)
> > I don't know why constraint is wrong and mode is right
> 
> Simple: you would need O(2**T*N) constraints for our existing N register
> constraints, together with T features like this.  But only O(2**T) modes at
> most.

I guess that would be annoying if you couldn't have modifiers on constraints or
a bad algorithm for working them out. Fair enough.

> 
> > or why TI doesn't work but PTI apparently would,
> 
> Because this is exactly what PTImode is *for*!

Right I accept it is, I meant I just would not have been able to work it out
(assuming if PTI was documented it would be "Partial Tetra Integer" and be no
more useful than the other P?I type documentation.

> 
> > but I'll take anything that works. Could we
> > get PTI implemented? Does it need a new issue opened?
> 
> It was implemented in 2013.  The restriction to only even pairs was a bugfix,
> also from 2013.
> 
> If you have code like
> 
>   typedef __int128 __attribute__((mode(PTI))) even;
> 
> you get an error like
> 
>   error: no data type for mode 'PTI'
> 
> This needs fixing.  You can keep it in this PR?

Sure,  that would be much appreciated.

[Bug rtl-optimization/110573] branch delay slots are not filled with atomic stores

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110573

--- Comment #6 from Andrew Pinski  ---
(In reply to Luke Geeson from comment #4)
> I understand treating atomics as volatile has historical precedent but a
> case can be made, at least on modern architectures and with improved
> understanding of models, that atomics are not volatile and more
> optimisations can be applied.
> What do you think?

Not really. The problem is you will need to add a new kind of memory access
type on the RTL level, this is not something which can be done without getting
things wrong and/or forgetting to update every place that might change
volatileness (including the scheduler which itself getting right is hard).
So treating them as volatile memory access on the RTL level is the easiest and
best form here.

Now on the gimple level, they are treated as a function call which itself is
another can of worms.

[Bug rtl-optimization/110573] branch delay slots are not filled with atomic stores

2023-07-06 Thread luke.geeson at cs dot ucl.ac.uk via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110573

--- Comment #5 from Luke Geeson  ---
For the record the %registers are symbolic - simply replace them with concrete
ones containing the location x,y,etc...

[Bug rtl-optimization/110573] branch delay slots are not filled with atomic stores

2023-07-06 Thread luke.geeson at cs dot ucl.ac.uk via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110573

--- Comment #4 from Luke Geeson  ---
Ah so since atomics are treated as volatile (like LLVM) instructions that
access them cannot inhabit a delay slot. Is it still valid to treat atomics as
volatile?

Consider the following MIPS litmus test:
```
{ %x0=x; %y0=y; %y1=y; %x1=x; }
 P0   | P1   ;
 lw $2,0(%x0) | lw $2,0(%y1) ;
 ori $3,$0,1  | ori $3,$0,1  ;
 sw $3,0(%y0) | sw $3,0(%x1) ;

exists (0:$2=1 /\ 1:$2=1)
```
When run under the mips model we do not observe the outcome in the exists
clause:
```
0:$2=0; 1:$2=0;
0:$2=0; 1:$2=1;
0:$2=1; 1:$2=0;
```
That is, from an ordering perspective it is unlikely that unexpected behaviours
can occur - in this case putting sw in a delay slot should be ok (the same
doesn't hold for RISC-V/Arm models of course).

I understand treating atomics as volatile has historical precedent but a case
can be made, at least on modern architectures and with improved understanding
of models, that atomics are not volatile and more optimisations can be applied.
What do you think?

[Bug tree-optimization/110539] [14 Regression] Dead Code Elimination Regression at since r14-338-g1dd154f6407

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> yes adding:
> /* (convert)(zeroone != 0) into (convert)zeroone */
> /* (convert)(zeroone == 0) into ((convert)zeroone)^1 */
> (for neeq (ne eq)
>  (simplify
>   (convert (neeq zero_one_valued_p@0 integer_zerop))
>   (if (neeq == NE_EXPR)
>(convert @0)
>(bit_xor (convert @0) { build_one_cst (type); } 
> 
> 
> Fixes the original testcase.

One simple regression:
/* { dg-final { scan-tree-dump-times "Folded to: _\[0-9\]+ = 1;" 1 "dom3"} } */
/* { dg-final { scan-tree-dump-times "Folded to: _\[0-9\]+ = 0;" 1 "dom3"} } */

fail now but that is they just don't match the above on accident.

Before:
  Replaced 'bufferstep_36' with constant '0'
gimple_simplified to _5 = 1;
  Folded to: _5 = 1;
After:
  Replaced 'bufferstep_36' with constant '0'
gimple_simplified to bufferstep_23 = 1;
  Folded to: bufferstep_23 = 1;

[Bug tree-optimization/110539] [14 Regression] Dead Code Elimination Regression at since r14-338-g1dd154f6407

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539

--- Comment #4 from Andrew Pinski  ---
yes adding:
/* (convert)(zeroone != 0) into (convert)zeroone */
/* (convert)(zeroone == 0) into ((convert)zeroone)^1 */
(for neeq (ne eq)
 (simplify
  (convert (neeq zero_one_valued_p@0 integer_zerop))
  (if (neeq == NE_EXPR)
   (convert @0)
   (bit_xor (convert @0) { build_one_cst (type); } 


Fixes the original testcase.

[Bug c++/81880] thread_local static member template initialisation fails

2023-07-06 Thread ttimo at valvesoftware dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81880

Timothee Besset  changed:

   What|Removed |Added

 CC||ttimo at valvesoftware dot com

--- Comment #5 from Timothee Besset  ---
we are observing this with gcc 10.3.0

[Bug c++/110580] New: [14 Regression] gcc fails to typecheck nix-2.16.1 source: error: invalid initialization of reference of type

2023-07-06 Thread slyfox at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110580

Bug ID: 110580
   Summary: [14 Regression] gcc fails to typecheck nix-2.16.1
source: error: invalid initialization of reference of
type
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55495
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55495=edit
nar-accessor.cc.cc.xz

Originally observed the build failure on nix-2.16.1 source when building with
gcc r14-2344-g9f4f833455bb35.

I suspect it might be a form of https://gcc.gnu.org/PR110523 regression. But
filing just in case.

Attached unmodified preprocessed example.

The build succeeds on gcc-13:

$ g++-13 -c nar-accessor.cc.cc -std=c++2a
# ok

$ g++-14 -c nar-accessor.cc.cc -std=c++2a
nar-accessor.cc.cc: In instantiation of 'std::pair, std::_Select1st >,
_Compare, typename
__gnu_cxx::__alloc_traits<_Allocator>::rebind
>::other>::iterator, bool> std::map<_Key, _Tp, _Compare,
_Alloc>::emplace(_Args&& ...) [with _Args = {std::basic_string_view >, nix::NarMember}; _Key =
std::__cxx11::basic_string; _Tp = nix::NarMember; _Compare =
std::less >; _Alloc =
std::allocator,
nix::NarMember> >; typename std::_Rb_tree<_Key, std::pair,
std::_Select1st >, _Compare, typename
__gnu_cxx::__alloc_traits<_Allocator>::rebind
>::other>::iterator = std::_Rb_tree_iterator, nix::NarMember> >; typename
__gnu_cxx::__alloc_traits<_Allocator>::rebind
>::other = std::allocator,
nix::NarMember> >; typename
__gnu_cxx::__alloc_traits<_Allocator>::rebind > =
__gnu_cxx::__alloc_traits, nix::NarMember> >, std::pair, nix::NarMember> >::rebind, nix::NarMember> >; typename
_Allocator::value_type = std::pair,
nix::NarMember>]':
nar-accessor.cc.cc:126951:62:   required from here
nar-accessor.cc.cc:33745:23: error: invalid initialization of reference of type
'const std::map, nix::NarMember>::key_type&'
{aka 'const std::__cxx11::basic_string&'} from expression of type
'std::basic_string_view'
33745 |   const key_type& __k = __a;
  |   ^~~

$ g++ -v |& unnix
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0  (experimental) (GCC)

[Bug tree-optimization/110539] [14 Regression] Dead Code Elimination Regression at since r14-338-g1dd154f6407

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539

--- Comment #3 from Andrew Pinski  ---
Here is a testcase for the missing optimization (at -O1) which is optimized at
the RTL level (for some targets but not all):
```
int f(int a)
{
int b = a & 1;
int c = b != 0;
return c == b;
}
```

Though it does optimize at -O2 because VRP changes: `b != 0` into `(_Bool)
b_4`.

[Bug tree-optimization/110539] [14 Regression] Dead Code Elimination Regression at since r14-338-g1dd154f6407

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539

--- Comment #2 from Andrew Pinski  ---
So the difference comes from the order. Before in phiopt we had:
-  /* Defer boolean x ? 0 : {1,-1} or x ? {1,-1} : 0 to
- match_simplify_replacement.  */
-  if (TREE_CODE (TREE_TYPE (lhs)) == BOOLEAN_TYPE
-  && (integer_zerop (arg0)
- || integer_zerop (arg1)
- || TREE_CODE (TREE_TYPE (arg0)) == BOOLEAN_TYPE
- || (TYPE_PRECISION (TREE_TYPE (arg0))
- <= TYPE_PRECISION (TREE_TYPE (lhs)
-return false;

But now the order is such that `?0:{1,-1}`, `?{1,-1}:0` is handled first.

So what we need to pattern match here is `(convert)zero_one_value_p@0!=0` and
simplify that into just (convert)@0

(for neeq (ne eq)
 (simplify
  (convert (neeq zero_one_value_p@0 integer_zerop))
  (if (neeq == NE_EXPR))
   (convert @0)
   (bit_xor (convert @0) { build_one_cst (type); } ))

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

2023-07-06 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #48 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #47)
> However, when I use -O2 together with an -march= flag, the code works.
> I've tested -march=sandybridge, -march=haswell, -march=skylake,
> -march=native.
> It FPEs without.

And it FPEs with core2,nehalem,westmere!

Next I tried:

-march=sandybridge -mno-avx  # FPE!
-march=sandybridge   # OK.

[Bug tree-optimization/110539] [14 Regression] Dead Code Elimination Regression at since r14-338-g1dd154f6407

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Last reconfirmed||2023-07-06

--- Comment #1 from Andrew Pinski  ---

  # RANGE [irange] int [0, 1] NONZERO 0x1
  i_7 = a.0_1 & 1;

  _17 = i_7 != 0;
  _12 = (int) _17;
  if (i_7 == _12)


So this should have been optimized to _17 = (bool) i_7;
and then if (1)

Maybe it is an order of the stuff in match.pd ...

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

2023-07-06 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #47 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #46)
> The issue goes away with -O0, with -O1 and with -O2 -fno-tree-vectorize. 
> I might want to find the offending commit in the week of June 12-19 in the
> tree-optimizer, but I don't know whether I have time to do so. Hopefully,
> with this 
> smaller reproducer you can figure out what happens (and help solving it)

I recommend adding -ffpe-trap=zero,overflow,invalid to the flags.

It is code2.f90 that is sensible to -ftree-vectorize; the two other files
can be compiled even with -O3.

However, when I use -O2 together with an -march= flag, the code works.
I've tested -march=sandybridge, -march=haswell, -march=skylake, -march=native.
It FPEs without.

Do you see the same?

[Bug tree-optimization/110540] [14 Regression] Dead Code Elimination Regression since r14-1163-gd8b058d3ca4

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110540

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-07-06
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

After threadfull2 we have:
  # VUSE <.MEM_17>
  _6 = *f.3_5;
  # VUSE <.MEM_17>
  _7 = *_6;
  if (_7 <= 0)
goto ; [5.50%]
  else
goto ; [94.50%]

   [local count: 55807731]:
  # .MEM_19 = VDEF <.MEM_17>
  *_6 = 0;
  # VUSE <.MEM_19>
  _10 = *f.3_5;
  if (_10 != 0B)
goto ; [0.00%]
  else
goto ; [100.00%]


But there is nothing which will optimize the load of *f.3_5 to be _6 before
vrp2 (which is the next pass).

There seems to be some other issues earlier on which gets us to that IR that
late but I am not sure how ...

[Bug tree-optimization/110579] O2, O1 opmtimizations cause a buffer overflow panic during a strcpy

2023-07-06 Thread gabriel.torres at ll dot mit.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110579

--- Comment #5 from Gabriel  ---
I see. That makes sense.

Our research project has a dataset with tar 1.14. Our plan is to compare our
work with existing work in the dataset and to be consistent, use tar 1.14. We
noticed our binary compiled with gcc would abort when creating an archive while
using clang was fine.

[Bug tree-optimization/110501] Invalid use-after-free / realloc with a store/load happening

2023-07-06 Thread cheyenne.wills at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110501

--- Comment #6 from Cheyenne Wills  ---
Just another bit of information.

Specifying just -Werror=use-after-free appears to be not not enough to trigger
the problem.  Using -Wall however does trigger the problem.

(tried on gcc-12 and gcc-13)

[Bug tree-optimization/110579] O2, O1 opmtimizations cause a buffer overflow panic during a strcpy

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110579

--- Comment #4 from Andrew Pinski  ---
All of these FORTIFY issues have been fixed for a long time now (over 10
years).

Why are you trying to use an old version of gnu tar?

e.g. https://lists.gnu.org/archive/html/bug-tar/2010-02/msg00010.html

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 110579, which changed state.

Bug 110579 Summary: O2, O1 opmtimizations cause a buffer overflow panic during 
a strcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110579

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

[Bug tree-optimization/110579] O2, O1 opmtimizations cause a buffer overflow panic during a strcpy

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110579

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Andrew Pinski  ---
The warning:
In function ‘strcpy’,
inlined from ‘start_header’ at create.c:695:7:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:79:10: warning:
‘__builtin___strcpy_chk’ writing 8 bytes into a region of size 6
[-Wstringop-overflow=]
   79 |   return __builtin___strcpy_chk (__dest, __src, __glibc_objsize
(__dest));
  | 
^~~~

Which comes from:

  strcpy (header->header.magic, "ustar  "); //8


The code is not _FORTIFY_SOURCE=2 safe which requires strcpy to only write
exactly the amount to those fields and not combine character fields as
different.


  char magic[6];
  char version[2];

[Bug tree-optimization/110579] O2, O1 opmtimizations cause a buffer overflow panic during a strcpy

2023-07-06 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110579

--- Comment #2 from Sam James  ---
Could you give us a backtrace with -ggdb3 when it aborts at runtime?

[Bug c/110579] O2, O1 opmtimizations cause a buffer overflow panic during a strcpy

2023-07-06 Thread gabriel.torres at ll dot mit.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110579

--- Comment #1 from Gabriel  ---
Created attachment 55494
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55494=edit
Processed *.i files

[Bug c/110579] New: O2, O1 opmtimizations cause a buffer overflow panic during a strcpy

2023-07-06 Thread gabriel.torres at ll dot mit.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110579

Bug ID: 110579
   Summary: O2, O1 opmtimizations cause a buffer overflow panic
during a strcpy
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabriel.torres at ll dot mit.edu
  Target Milestone: ---

Created attachment 55493
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55493=edit
Output of compiling the source code.

O2, O1 opmtimizations of the attached .i file trigger a buffer overflow panic
during a strcpy.
The project being compiled is tar 1.14.
The unoptimzed version does not panic and performs the expected behavior,
creating an archive.

* the exact version of GCC;
  - 11.3.0, 12.1.0, 9.5.0
* the system type;
  - Ubuntu 22.04.1
* the options given when GCC was configured/built;
  - 11.3.0: Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.3.0-1ubuntu1~22.04.1' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-aYxV0E/gcc-11-11.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-aYxV0E/gcc-11-11.3.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
  - 9.5.0: Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.5.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-9-5Q4PKF/gcc-9-9.5.0/debian/tmp-nvptx/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-mutex
  - 12.1.0: Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12.1.0-2ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
* the complete command line that triggers the bug;
 - ./tar cf foo.tar bar
* the compiler output (error messages, warnings, etc.); and
 - See make_output file
* the preprocessed file (*.i*) that triggers the bug

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

2023-07-06 Thread juergen.reuter at desy dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #46 from Jürgen Reuter  ---
(In reply to Jürgen Reuter from comment #45)
> Created attachment 55492 [details]
> Smaller stand-alone reproducer
> 
> I will give more information in a comment, this contains 3 files and a
> Makefile.

This is a standalone reproducer with a total of 8k lines. It needs to be in
three different files, as fusing the 2nd and 3rd file eliminates the optimizer
problem of this issue, while fusing the 1st and the 2nd leeds to an ICE in
trans-array.c (reported separately) and is independent of this problem here.
The issue goes away with -O0, with -O1 and with -O2 -fno-tree-vectorize. 
I might want to find the offending commit in the week of June 12-19 in the
tree-optimizer, but I don't know whether I have time to do so. Hopefully, with
this 
smaller reproducer you can figure out what happens (and help solving it)

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

2023-07-06 Thread juergen.reuter at desy dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #45 from Jürgen Reuter  ---
Created attachment 55492
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55492=edit
Smaller stand-alone reproducer

I will give more information in a comment, this contains 3 files and a
Makefile.

[Bug analyzer/110578] New: Support dynamic_cast within the analyzer

2023-07-06 Thread vultkayn at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110578

Bug ID: 110578
   Summary: Support dynamic_cast within the analyzer
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: vultkayn at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55491
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55491=edit
First draft of a test case for dynamic_cast

In the attached file you will find a first draft of test cases toward
supporting dynamic_cast in the analyzer. We [the analyzer] have already gained
RTTI capabilities thanks to PR97114, so supporting dynamic_cast no longer feels
that far away.
Test cases currently failing have been marked 'xfail'.

I didn't add any test case about dynamic_cast failure given reference to types,
but rather stuck to pointers, since we don't support exceptions whatsoever.

  "If the cast fails and target-type is a reference type, it throws an
exception
   that matches a handler of type std::bad_cast."

  https://en.cppreference.com/w/cpp/language/dynamic_cast

What are your thoughts on these tests ? Do they feel complete enough for a
first implementation
of dynamic_cast into the analyzer ?

[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |rtl-optimization
 Ever confirmed|0   |1
   Last reconfirmed||2023-07-06
 Status|UNCONFIRMED |NEW
  Known to fail||11.2.0

--- Comment #7 from Andrew Pinski  ---
The initial RTL has a signed extend in there:


(insn 20 19 23 2 (set (reg/v:DI 200 [ val+-4 ])
(sign_extend:DI (subreg:SI (reg/v:DI 200 [ val+-4 ]) 4)))
"/app/example.cpp":7:29 -1
 (nil))
(jump_insn 23 20 24 2 (set (pc)
(if_then_else (le (subreg/s/u:SI (reg/v:DI 200 [ val+-4 ]) 4)
(const_int 0 [0]))
(label_ref 32)
(pc))) "/app/example.cpp":8:5 -1
 (int_list:REG_BR_PROB 440234148 (nil))
 -> 32)


Before combine also looks fine:
(insn 20 19 23 2 (set (reg/v:DI 200 [ val+-4 ])
(sign_extend:DI (subreg:SI (reg/v:DI 200 [ val+-4 ]) 4)))
"/app/example.cpp":7:29 235 {extendsidi2}
 (nil))
(jump_insn 23 20 24 2 (set (pc)
(if_then_else (le (subreg/s/u:SI (reg/v:DI 200 [ val+-4 ]) 4)
(const_int 0 [0]))
(label_ref 32)
(pc))) "/app/example.cpp":8:5 471 {*branch_ordersi}
 (expr_list:REG_DEAD (reg/v:DI 200 [ val+-4 ])
(int_list:REG_BR_PROB 440234148 (nil)))
 -> 32)

But combine does the wrong thing:
Trying 20 -> 23:
   20: r200:DI=sign_extend(r200:DI#4)
   23: pc={(r200:DI#4<=0)?L32:pc}
  REG_DEAD r200:DI
  REG_BR_PROB 440234148
Successfully matched this instruction:
(set (pc)
(if_then_else (le (subreg:SI (reg/v:DI 200 [ valD.1959+-4 ]) 4)
(const_int 0 [0]))
(label_ref 32)
(pc)))
allowing combination of insns 20 and 23
original costs 4 + 16 = 20
replacement cost 16
deferring deletion of insn with uid = 20.
modifying insn i323: pc={(r200:DI#4<=0)?L32:pc}
  REG_BR_PROB 440234148
  REG_DEAD r200:DI
deferring rescan insn with uid = 23.

Instead of a subreg here, it should have been a truncate.

[Bug target/110577] New: s390x: Some tests fail with -march=z13

2023-07-06 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110577

Bug ID: 110577
   Summary: s390x: Some tests fail with -march=z13
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

These tests:

gcc.dg/vect/vect-cond-reduc-4.c
g++.dg/vect/pr89653.cc
gfortran.dg/vect/fast-math-pr38968.f90
gfortran.dg/vect/fast-math-rnflow-trs2a2.f90
gfortran.dg/vect/pr62283.f 
gcc.target/s390/vector/partial/s390-vec-length-epil-1.c
gcc.target/s390/vector/partial/s390-vec-length-epil-2.c
gcc.target/s390/vector/partial/s390-vec-length-epil-3.c
gcc.target/s390/vector/partial/s390-vec-length-full-1.c
gcc.target/s390/vector/partial/s390-vec-length-full-2.c
gcc.target/s390/vector/partial/s390-vec-length-full-3.c

work with -march=z14, but fail with -march=z13.  E.g.,

# gcc vect-cond-reduc-4.c -fdiagnostics-plain-output --param
min-vect-loop-bound=1 --param max-unrolled-insns=200 --param max-unroll-times=8
--param max-completely-peeled-insns=200 --param max-completely-peel-times=16
-march=z13 -mzarch -ftree-vectorize -fno-tree-loop-distribute-patterns
-fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details --param
vect-epilogues-nomask=0 -march=z14 ; grep "LOOP VECTORIZED"
a-vect-cond-reduc-4.c.172t.vect
vect-cond-reduc-4.c:19:21: note:  LOOP VECTORIZED
vect-cond-reduc-4.c:19:21: note:  LOOP VECTORIZED
# gcc vect-cond-reduc-4.c -fdiagnostics-plain-output --param
min-vect-loop-bound=1 --param max-unrolled-insns=200 --param max-unroll-times=8
--param max-completely-peeled-insns=200 --param max-completely-peel-times=16
-march=z13 -mzarch -ftree-vectorize -fno-tree-loop-distribute-patterns
-fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details --param
vect-epilogues-nomask=0 -march=z13 ; grep "LOOP VECTORIZED"
a-vect-cond-reduc-4.c.172t.vect
#

or

# gcc s390-vec-length-epil-1.c -fdiagnostics-plain-output  -O2 -ftree-vectorize
-fno-vect-cost-model -fno-unroll-loops -fno-trapping-math
--param=vect-partial-vector-usage=1 --param=min-vect-loop-bound=0
-ffat-lto-objects -fno-ident -S -march=z13 -o s390-vec-length-epil-1.s
# grep vll s390-vec-length-epil-1.s | wc -l
12
# grep vstl s390-vec-length-epil-1.s | wc -l
6
# gcc s390-vec-length-epil-1.c -fdiagnostics-plain-output  -O2 -ftree-vectorize
-fno-vect-cost-model -fno-unroll-loops -fno-trapping-math
--param=vect-partial-vector-usage=1 --param=min-vect-loop-bound=0
-ffat-lto-objects -fno-ident -S -march=z14 -o s390-vec-length-epil-1.s
# grep vll s390-vec-length-epil-1.s | wc -l
14
# grep vstl s390-vec-length-epil-1.s | wc -l
7

[Bug libstdc++/110574] --enable-cstdio=stdio_pure is incompatible with LFS

2023-07-06 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110574

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-07-06
 Ever confirmed|0   |1
   Target Milestone|--- |11.5

--- Comment #4 from Jonathan Wakely  ---
I have a patch ...

[Bug middle-end/110573] MIPS64: Enhancement PR of load of pointer to atomic

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110573

--- Comment #3 from Andrew Pinski  ---
See
https://inbox.sourceware.org/gcc/d7787b3f-9450-5642-ffac-21cf36176...@redhat.com/
also.

[Bug middle-end/110573] MIPS64: Enhancement PR of load of pointer to atomic

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110573

--- Comment #2 from Andrew Pinski  ---
volatile (atomics) stores are not considered for branch delay slots.

https://inbox.sourceware.org/gcc/3077458.gu9dx72...@arcturus.home/

[Bug c/110575] gcc: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in build_aligned_type

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110575

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-07-06
 Ever confirmed|0   |1

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

[Bug tree-optimization/22401] DOM messes up the profiling info

2023-07-06 Thread hubicka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22401

--- Comment #5 from Jan Hubicka  ---
This is now threaded by threadfull2:

Checking profitability of path (backwards):  bb:3 (2 insns) bb:2
  Control statement insns: 2
  Overall: 0 insns

path: 2->3->xx REJECTED
Checking profitability of path (backwards):  bb:3 (2 insns) bb:5 (latch)
  Control statement insns: 2
  Overall: 0 insns

Checking profitability of path (backwards):
  [1] Registering jump thread: (5, 3) incoming edge;  (3, 5) nocopy;
path: 5->3->5 SUCCESS
Merging blocks 2 and 3
Merging blocks 5 and 6
fix_loop_structure: fixing up loops for function
fix_loop_structure: removing loop 1
flow_loops_find: discovered new loop 2 with header 3

and we get correct profile:

void __show_backtrace (void * rw)
{
;;   basic block 2, loop depth 0, count 118111600 (estimated locally), maybe
hot
;;prev block 0, next block 3, flags: (NEW, REACHABLE, VISITED)
;;pred:   ENTRY [always]  count:118111600 (estimated locally)
(FALLTHRU,EXECUTABLE)
  if (rw_1(D) != 0B)
goto ; [0.00%]
  else
goto ; [100.00%]
;;succ:   3 [never (guessed)]  count:0 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
;;4 [always (guessed)]  count:118111600 (estimated locally)
(FALSE_VALUE,EXECUTABLE)

;;   basic block 3, loop depth 1, count 955630224 (estimated locally), maybe
hot
;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED)
;;pred:   2 [never (guessed)]  count:0 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
;;3 [always]  count:955630224 (estimated locally)
(FALLTHRU,DFS_BACK)
  goto ; [100.00%]
;;succ:   3 [always]  count:955630224 (estimated locally)
(FALLTHRU,DFS_BACK)

;;   basic block 4, loop depth 0, count 118111600 (estimated locally), maybe
hot
;;prev block 3, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred:   2 [always (guessed)]  count:118111600 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
  return;
;;succ:   EXIT [always]  count:118111600 (estimated locally)
(EXECUTABLE) q.c:4:1

}

[Bug tree-optimization/25623] jump threading/cfg cleanup messes up "incoming counts" for some BBs

2023-07-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25623

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

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

commit r14-2369-g3a61ca1b9256535e1bfb19b2d46cde21f3908a5d
Author: Jan Hubicka 
Date:   Thu Jul 6 18:56:22 2023 +0200

Improve profile updates after loop-ch and cunroll

Extend loop-ch and loop unrolling to fix profile in case the loop is
known to not iterate at all (or iterate few times) while profile claims it
iterates more.  While this is kind of symptomatic fix, it is best we can do
incase profile was originally esitmated incorrectly.

In the testcase the problematic loop is produced by vectorizer and I think
vectorizer should know and account into its costs that vectorizer loop
and/or
epilogue is not going to loop after the transformation.  So it would be
nice
to fix it on that side, too.

The patch avoids about half of profile mismatches caused by cunroll.

Pass dump id and name|static mismatcdynamic mismatch
 |in count |in count
107t cunrolli|  3+3|17251   +17251
115t threadfull  |  3  |14376-2875
116t vrp |  5+2|30908   +16532
117t dse |  5  |30908
118t dce |  3-2|17251   -13657
127t ch  | 13   +10|17251
131t dom | 39   +26|17251
133t isolate-paths   | 47+8|17251
134t reassoc | 49+2|17251
136t forwprop| 53+4|   202501  +185250
159t cddce   | 61+8|   216211   +13710
161t ldist   | 62+1|   216211
172t ifcvt   | 66+4|   373711  +157500
173t vect|143   +77|  9802097 +9428386
176t cunroll |221   +78| 15639591 +5837494
183t loopdone|218-3| 15577640   -61951
195t fre |214-4| 15577640
197t dom |213-1| 16671606 +1093966
199t threadfull  |215+2| 16879581  +207975
200t vrp |217+2| 17077750  +198169
204t dce |215-2| 17004486   -73264
206t sink|213-2| 17004486
211t cddce   |219+6| 17005926+1440
255t optimized   |217-2| 17005926
256r expand  |210-7| 19571573 +2565647
258r into_cfglayout  |208-2| 19571573
275r loop2_unroll|212+4| 22992432 +3420859
291r ce2 |210-2| 23011838
312r pro_and_epilogue|230   +20| 23073776   +61938
315r jump2   |236+6| 27110534 +4036758
323r bbro|229-7| 21826835 -5283699

W/o the patch cunroll does:

176t cunroll |294  +151|126548439   +116746342

and we end up with 291 mismatches at bbro.

Bootstrapped/regtested x86_64-linux. Plan to commit it after the
scale_loop_frequency patch.

gcc/ChangeLog:

PR middle-end/25623
* tree-ssa-loop-ch.cc (ch_base::copy_headers): Scale loop frequency
to maximal number
of iterations determined.
* tree-ssa-loop-ivcanon.cc (try_unroll_loop_completely): Likewise.

gcc/testsuite/ChangeLog:

PR middle-end/25623
* gfortran.dg/pr25623-2.f90: New test.

[Bug fortran/110576] New: ICE on compilation

2023-07-06 Thread juergen.reuter at desy dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576

Bug ID: 110576
   Summary: ICE on compilation
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

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

The following reproducer leads to an ICE which I see already with gfortran
11.3. It was intended to become a reproducer for the optimization bug in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
but this is a separate issue. I will work around this one in the reproducer for 
110311.
In the most recent master branch, 14.0.0, it leads to
internal compiler error: Segmentation fault
0xd6eabf crash_signal
../../gcc/toplev.cc:314
0x7fe2411f151f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x844f2b structure_alloc_comps
../../gcc/fortran/trans-array.cc:9228
0x8459bf structure_alloc_comps
../../gcc/fortran/trans-array.cc:9167
0x847e8c gfc_deallocate_alloc_comp(gfc_symbol*, tree_node*, int, int)
../../gcc/fortran/trans-array.cc:10265
0x86980a gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.cc:6940
0x8b1952 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../gcc/fortran/trans-stmt.cc:424
0x82f93b trans_code
../../gcc/fortran/trans.cc:2297
0x8b5c30 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.cc:2351
0x82f887 trans_code
../../gcc/fortran/trans.cc:2325
0x85da69 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7717
0x833ec1 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.cc:2651
0x7d42f5 translate_all_program_units
../../gcc/fortran/parse.cc:6914
0x7d42f5 gfc_parse_file()
../../gcc/fortran/parse.cc:7233
0x82c6ef gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.

[Bug tree-optimization/110557] [13/14 Regression] Wrong code for x86_64-linux-gnu with -O3 -mavx2: vectorized loop mishandles signed bit-fields

2023-07-06 Thread xry111 at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110557

--- Comment #6 from Xi Ruoyao  ---
(In reply to avieira from comment #5)
> Hi Xi,
> 
> Feel free to test your patch and submit it to the list for review. I had a
> look over and it looks correct to me.

https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623782.html

The changes from the version posted here:

1. Add a test case (I already made it sandwiched because a very first, not
posted version of the patch failed with sandwiched cases).
2. Slightly adjusted the comment.

There is another issue: if mask_width + shift_n == prec, we should omit the
AND_EXPR even for unsigned bit-field.  For example

movq$-256, %rax
vmovq   %rax, %xmm1
vpunpcklqdq %xmm1, %xmm1, %xmm1
vpand   (%rcx,%rdi,8), %xmm1, %xmm1
vpsrlq  $8, %xmm1, %xmm1

can be just

vmovdqu (%rcx,%rdi,8), %xmm1
vpsrlq  $8, %xmm1, %xmm1

But it's a different issue so we can fix it in a different patch.

[Bug libstdc++/110574] --enable-cstdio=stdio_pure is incompatible with LFS

2023-07-06 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110574

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> Using --enable-cstdio=stdio_pure on x86_64-pc-linux-gnu results in test
> failures:
> 
> FAIL: 27_io/basic_filebuf/imbue/char/13171-2.cc execution test
> FAIL: 27_io/basic_filebuf/seekoff/12790-3.cc execution test
> FAIL: 27_io/basic_filebuf/seekoff/45628-2.cc execution test
> FAIL: 27_io/basic_filebuf/seekoff/char/1-in.cc execution test
> FAIL: 27_io/basic_filebuf/seekoff/char/1-io.cc execution test
> FAIL: 27_io/basic_filebuf/seekoff/char/1-out.cc execution test
> FAIL: 27_io/basic_filebuf/seekoff/char/2-in.cc execution test
> FAIL: 27_io/basic_filebuf/seekoff/char/2-io.cc execution test
> FAIL: 27_io/basic_filebuf/seekoff/char/2-out.cc execution test
> FAIL: 27_io/basic_filebuf/seekoff/char/26777.cc execution test
> FAIL: 27_io/basic_filebuf/seekoff/char/4.cc execution test
> FAIL: 27_io/basic_filebuf/seekoff/wchar_t/4.cc execution test
> FAIL: 27_io/basic_filebuf/seekpos/12790-2.cc execution test
> FAIL: 27_io/basic_filebuf/seekpos/12790-3.cc execution test
> FAIL: 27_io/basic_filebuf/seekpos/char/1-in.cc execution test
> FAIL: 27_io/basic_filebuf/seekpos/char/1-io.cc execution test
> FAIL: 27_io/basic_filebuf/seekpos/char/1-out.cc execution test
> FAIL: 27_io/basic_filebuf/seekpos/char/2-in.cc execution test
> FAIL: 27_io/basic_filebuf/seekpos/char/2-io.cc execution test
> FAIL: 27_io/basic_filebuf/seekpos/char/2-out.cc execution test
> FAIL: 27_io/basic_filebuf/seekpos/wchar_t/9874.cc execution test
> FAIL: 27_io/basic_filebuf/seekpos/wchar_t/9875_seekpos.cc execution test
> FAIL: 27_io/basic_filebuf/sgetn/char/2-in.cc execution test
> FAIL: 27_io/basic_filebuf/sgetn/char/2-io.cc execution test
> FAIL: 27_io/basic_filebuf/sputbackc/char/1-io.cc execution test
> FAIL: 27_io/basic_filebuf/sputbackc/char/2-io.cc execution test
> FAIL: 27_io/basic_filebuf/sungetc/char/1-io.cc execution test
> FAIL: 27_io/basic_filebuf/sungetc/char/2-io.cc execution test
> FAIL: 27_io/basic_filebuf/underflow/char/10097.cc execution test
> FAIL: 27_io/basic_filebuf/underflow/wchar_t/5.cc execution test
> FAIL: 27_io/basic_fstream/53984.cc execution test
> FAIL: 27_io/basic_istream/peek/char/6414.cc execution test
> FAIL: 27_io/basic_istream/peek/wchar_t/6414.cc execution test
> FAIL: 27_io/basic_istream/seekg/char/fstream.cc execution test
> FAIL: 27_io/basic_istream/seekg/wchar_t/fstream.cc execution test
> FAIL: 27_io/basic_istream/tellg/char/fstream.cc execution test
> FAIL: 27_io/basic_istream/tellg/wchar_t/fstream.cc execution test
> FAIL: 27_io/objects/wchar_t/12.cc execution test
> 
> This seems to be because of code like:
> 
>   streamoff
>   __basic_file::seekoff(streamoff __off, ios_base::seekdir __way)
> throw ()
>   {
> #ifdef _GLIBCXX_USE_LFS
> return lseek64(this->fd(), __off, __way);
> #else
> if (__off > numeric_limits::max()
>   || __off < numeric_limits::min())
>   return -1L;
> #ifdef _GLIBCXX_USE_STDIO_PURE
> return fseek(this->file(), __off, __way);

Oh, and fseek returns 0 or -1, not the position, so we shouldn't return its
value here.

[Bug tree-optimization/110557] [13/14 Regression] Wrong code for x86_64-linux-gnu with -O3 -mavx2: vectorized loop mishandles signed bit-fields

2023-07-06 Thread xry111 at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110557

Xi Ruoyao  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-July/62
   ||3782.html
   Keywords||patch
 Status|NEW |ASSIGNED

[Bug tree-optimization/110449] Vect: use a small step to calculate the loop induction if the loop is unrolled during loop vectorization

2023-07-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110449

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

https://gcc.gnu.org/g:224fd59b2dc8a5fa78a309a09863afe9b3cf2111

commit r14-2367-g224fd59b2dc8a5fa78a309a09863afe9b3cf2111
Author: Hao Liu OS 
Date:   Thu Jul 6 10:04:46 2023 -0600

Vect: use a small step to calculate induction for the unrolled loop (PR
tree-optimization/110449)

If a loop is unrolled by n times during vectoriation, two steps are used to
calculate the induction variable:
  - The small step for the unrolled ith-copy: vec_1 = vec_iv + (VF/n *
Step)
  - The large step for the whole loop: vec_loop = vec_iv + (VF * Step)

This patch calculates an extra vec_n to replace vec_loop:
  vec_n = vec_prev + (VF/n * S) = vec_iv + (VF/n * S) * n = vec_loop.

So that we can save the large step register and related operations.

gcc/ChangeLog:

PR tree-optimization/110449
* tree-vect-loop.cc (vectorizable_induction): use vec_n to replace
vec_loop for the unrolled loop.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr110449.c: New testcase.

[Bug c++/110555] internal compiler error: Segmentation fault when using std::ranges::range auto as a template parameter

2023-07-06 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110555

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2023-07-06
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Confirmed, even 11 ICEs.

[Bug libstdc++/104299] Doc: stdio is not the only option in --enable-cstdio=XXX

2023-07-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104299

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

https://gcc.gnu.org/g:67bda4331dc4f548820ed2f3138aa7f64fd4c77d

commit r12-9757-g67bda4331dc4f548820ed2f3138aa7f64fd4c77d
Author: Jonathan Wakely 
Date:   Thu Jul 6 16:25:47 2023 +0100

libstdc++: Document --enable-cstdio=stdio_pure [PR104299]

libstdc++-v3/ChangeLog:

PR libstdc++/104299
* doc/xml/manual/configure.xml: Describe stdio_pure argument to
--enable-cstdio.
* doc/html/manual/configure.html: Regenerate.

(cherry picked from commit b90a70984a9beee39b41f842b56926f9db2069ca)

[Bug libstdc++/104299] Doc: stdio is not the only option in --enable-cstdio=XXX

2023-07-06 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104299

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |11.5

[Bug libstdc++/104299] Doc: stdio is not the only option in --enable-cstdio=XXX

2023-07-06 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104299

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk and gcc-13 so far.

[Bug libstdc++/104299] Doc: stdio is not the only option in --enable-cstdio=XXX

2023-07-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104299

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

https://gcc.gnu.org/g:94d24f1af684d37b9e1c6ad9b54c98609140eb1f

commit r13-7537-g94d24f1af684d37b9e1c6ad9b54c98609140eb1f
Author: Jonathan Wakely 
Date:   Thu Jul 6 16:25:47 2023 +0100

libstdc++: Document --enable-cstdio=stdio_pure [PR104299]

libstdc++-v3/ChangeLog:

PR libstdc++/104299
* doc/xml/manual/configure.xml: Describe stdio_pure argument to
--enable-cstdio.
* doc/html/manual/configure.html: Regenerate.

(cherry picked from commit b90a70984a9beee39b41f842b56926f9db2069ca)

[Bug libstdc++/110574] --enable-cstdio=stdio_pure is incompatible with LFS

2023-07-06 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110574

--- Comment #2 from Jonathan Wakely  ---
Doh, I put the wrong PR number in that commit, it's meant to be for PR 104299

[Bug libstdc++/110574] --enable-cstdio=stdio_pure is incompatible with LFS

2023-07-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110574

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r14-2366-gb90a70984a9beee39b41f842b56926f9db2069ca
Author: Jonathan Wakely 
Date:   Thu Jul 6 16:25:47 2023 +0100

libstdc++: Document --enable-cstdio=stdio_pure [PR110574]

libstdc++-v3/ChangeLog:

PR libstdc++/110574
* doc/xml/manual/configure.xml: Describe stdio_pure argument to
--enable-cstdio.
* doc/html/manual/configure.html: Regenerate.

[Bug c/110575] New: gcc: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in build_aligned_type

2023-07-06 Thread 141242068 at smail dot nju.edu.cn via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110575

Bug ID: 110575
   Summary: gcc: internal compiler error: tree check: expected
class 'type', have 'exceptional' (error_mark) in
build_aligned_type
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

The testcase:
```
void __GIMPLE(ssa, startwith("slp")) bar() {
  a = __MEM((int *restrict)b(c));
}
```

When attempting to compile this program using `gcc-14` with option `-O0`, gcc
reports internal compiler error as below:
```
:1:6: error: '__GIMPLE' only valid with '-fgimple'
1 | void __GIMPLE(ssa, startwith("slp")) bar() {
  |  ^~~~
: In function 'bar':
:2:3: error: 'a' undeclared (first use in this function)
2 |   a = __MEM((int *restrict)b(c));
  |   ^
:2:3: note: each undeclared identifier is reported only once for each
function it appears in
:2:13: error: unknown type name 'v16si'
2 |   a = __MEM((int *restrict)b(c));
  | ^
:2:3: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in build_aligned_type, at tree.cc:5700
2 |   a = __MEM((int *restrict)b(c));
  |   ^
0x213983e internal_error(char const*, ...)
???:0
0x8959fe tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
???:0
0xa7aeae c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il,
profile_count)
???:0
0xa71add c_parse_file()
???:0
0xae1149 c_common_parse_file()
???:0
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.
Compiler returned: 1
```

This behavior can be verified by visiting the CompilerExplorer: 
https://gcc.godbolt.org/z/8d8GGaPze

[Bug libstdc++/104299] Doc: stdio is not the only option in --enable-cstdio=XXX

2023-07-06 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104299

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110574
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-07-06

--- Comment #1 from Jonathan Wakely  ---
stdio_posix is a synonym of stdio, but we should document stdio_pure

[Bug libstdc++/110574] New: --enable-cstdio=stdio_pure is incompatible with LFS

2023-07-06 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110574

Bug ID: 110574
   Summary: --enable-cstdio=stdio_pure is incompatible with LFS
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: keithp at keithp dot com
  Target Milestone: ---

Using --enable-cstdio=stdio_pure on x86_64-pc-linux-gnu results in test
failures:

FAIL: 27_io/basic_filebuf/imbue/char/13171-2.cc execution test
FAIL: 27_io/basic_filebuf/seekoff/12790-3.cc execution test
FAIL: 27_io/basic_filebuf/seekoff/45628-2.cc execution test
FAIL: 27_io/basic_filebuf/seekoff/char/1-in.cc execution test
FAIL: 27_io/basic_filebuf/seekoff/char/1-io.cc execution test
FAIL: 27_io/basic_filebuf/seekoff/char/1-out.cc execution test
FAIL: 27_io/basic_filebuf/seekoff/char/2-in.cc execution test
FAIL: 27_io/basic_filebuf/seekoff/char/2-io.cc execution test
FAIL: 27_io/basic_filebuf/seekoff/char/2-out.cc execution test
FAIL: 27_io/basic_filebuf/seekoff/char/26777.cc execution test
FAIL: 27_io/basic_filebuf/seekoff/char/4.cc execution test
FAIL: 27_io/basic_filebuf/seekoff/wchar_t/4.cc execution test
FAIL: 27_io/basic_filebuf/seekpos/12790-2.cc execution test
FAIL: 27_io/basic_filebuf/seekpos/12790-3.cc execution test
FAIL: 27_io/basic_filebuf/seekpos/char/1-in.cc execution test
FAIL: 27_io/basic_filebuf/seekpos/char/1-io.cc execution test
FAIL: 27_io/basic_filebuf/seekpos/char/1-out.cc execution test
FAIL: 27_io/basic_filebuf/seekpos/char/2-in.cc execution test
FAIL: 27_io/basic_filebuf/seekpos/char/2-io.cc execution test
FAIL: 27_io/basic_filebuf/seekpos/char/2-out.cc execution test
FAIL: 27_io/basic_filebuf/seekpos/wchar_t/9874.cc execution test
FAIL: 27_io/basic_filebuf/seekpos/wchar_t/9875_seekpos.cc execution test
FAIL: 27_io/basic_filebuf/sgetn/char/2-in.cc execution test
FAIL: 27_io/basic_filebuf/sgetn/char/2-io.cc execution test
FAIL: 27_io/basic_filebuf/sputbackc/char/1-io.cc execution test
FAIL: 27_io/basic_filebuf/sputbackc/char/2-io.cc execution test
FAIL: 27_io/basic_filebuf/sungetc/char/1-io.cc execution test
FAIL: 27_io/basic_filebuf/sungetc/char/2-io.cc execution test
FAIL: 27_io/basic_filebuf/underflow/char/10097.cc execution test
FAIL: 27_io/basic_filebuf/underflow/wchar_t/5.cc execution test
FAIL: 27_io/basic_fstream/53984.cc execution test
FAIL: 27_io/basic_istream/peek/char/6414.cc execution test
FAIL: 27_io/basic_istream/peek/wchar_t/6414.cc execution test
FAIL: 27_io/basic_istream/seekg/char/fstream.cc execution test
FAIL: 27_io/basic_istream/seekg/wchar_t/fstream.cc execution test
FAIL: 27_io/basic_istream/tellg/char/fstream.cc execution test
FAIL: 27_io/basic_istream/tellg/wchar_t/fstream.cc execution test
FAIL: 27_io/objects/wchar_t/12.cc execution test

This seems to be because of code like:

  streamoff
  __basic_file::seekoff(streamoff __off, ios_base::seekdir __way) throw
()
  {
#ifdef _GLIBCXX_USE_LFS
return lseek64(this->fd(), __off, __way);
#else
if (__off > numeric_limits::max()
|| __off < numeric_limits::min())
  return -1L;
#ifdef _GLIBCXX_USE_STDIO_PURE
return fseek(this->file(), __off, __way);
#else
return lseek(this->fd(), __off, __way);
#endif
#endif

If LFS is being used then the STDIO_PURE config is ignored, and we use lseek64
on the file descriptor unconditionally. Then when we read we do respect the
STDIO_PURE config:

  streamsize
  __basic_file::xsgetn(char* __s, streamsize __n)
  {
streamsize __ret;
do
#ifdef _GLIBCXX_USE_STDIO_PURE
  __ret = fread(__s, 1, __n, this->file());
#else
  __ret = read(this->fd(), __s, __n);
#endif
while (__ret == -1L && errno == EINTR);
return __ret;
  }

But now we're seeking on the file descriptor and reading from the FILE. We need
to use fseek before fread.

[Bug tree-optimization/110557] [13/14 Regression] Wrong code for x86_64-linux-gnu with -O3 -mavx2: vectorized loop mishandles signed bit-fields

2023-07-06 Thread avieira at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110557

--- Comment #5 from avieira at gcc dot gnu.org ---
Hi Xi,

Feel free to test your patch and submit it to the list for review. I had a look
over and it looks correct to me.

I feel like it also addresses the cases where the bitfield is 'sandwiched'
like:
int x : 7;
ptrdiff_t y : 56;
long long z: 1;

As you left-shift it, and it also addresses the case where you have both
sign-extension and have to widen-it, because you still transform the type into
signed.

But it might be nice to add tests to cover those two, just in case someone
changes this.

In the future, if you do plan to work on something it would be nice to let
people know on the bugzilla ticket (preferably by assigning it to yourself) so
that multiple people don't end up working on the same thing, I had started to
write a patch, but wasn't as far as you and I like your approach :)

[Bug gcov-profile/110545] gcda files not generated for some shared libs

2023-07-06 Thread gejoed at rediffmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110545

--- Comment #2 from Gejoe  ---
No, they are not using dlopen.

The shared libraries are built and loaded during the program (image) loading.

[Bug target/54089] [SH] Refactor shift patterns

2023-07-06 Thread olegendo at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089

--- Comment #95 from Oleg Endo  ---
(In reply to Oleg Endo from comment #93)
> (In reply to Alexander Klepikov from comment #92)
> > I remembered why I used two different insns - first to eliminate infinite
> > loop with help of marking insn with attribute, and second because I could
> > not set attribute when emitting insn from C code. Whe have 'get_attr_*'
> > functions but we have not 'set_attr_*'.
> 
> Yes, I thought so.  I'll give it a try myself with your patch ... please
> hold on.

Finally could have a look at it, sorry for the delay.

The infinite loop is in splitting of the 'ashrsi3_n_call' pattern with the
constant 1.  This is because 'ashrsi3_n_call' match overlaps with the 'shar'
pattern.

One quick fix is to put the condition into the first string.  A nicer way would
be to use a predicate which would constrain the operand[2] to "not 1".  But
it's the first and only use so quick version is OK.

In addition, that pattern (not only the split condition) should be matched only
before register allocation, so the 'can_create_pseudo_p' check is moved.

Another point is that you had the 'cfun->machine->ashrsi3_libcall_expanded++;'
in the wrong place.  It was counting up even if it wouldn't have emitted the
libcall.

This seems to work:

(define_insn_and_split "ashrsi3_n_call"
  [(set (match_operand:SI 0 "arith_reg_dest")
(ashiftrt:SI (match_operand:SI 1 "arith_reg_operand")
 (match_operand:SI 2 "const_int_operand")))
(clobber (reg:SI T_REG))]
  "TARGET_SH1 && can_create_pseudo_p () && operands[2] != const1_rtx"
  "#"
  "&& 1"
  [(const_int 0)]
{
  if (expand_ashiftrt (operands))
DONE;

  if (dump_file)
fprintf(dump_file, "ashrsi3_n_call: Expanding ashrsi3 libcall\n");

  cfun->machine->ashrsi3_libcall_expanded++;

  int value = INTVAL (operands[2]) & 31;

  char func[18];
  sprintf (func, "__ashiftrt_r4_%d", value);

  emit_move_insn (gen_rtx_REG (SImode, 4), operands[1]);

  rtx wrk = gen_reg_rtx (Pmode);
  rtx lab = function_symbol (wrk, func, SFUNC_STATIC).lab;
  emit_insn (gen_ashrsi3_n (GEN_INT (value), wrk, lab));
  emit_move_insn (operands[0], gen_rtx_REG (SImode, 4));
  DONE;
})


However, there is one case from  your previous posts in PR 49263:

int f_rshift(char v){
return v >> S;
}

This will not work on SH2 and expand to a libcall.  On SH4 the combine pass
converts it into:

Successfully matched this instruction:
(set (reg:SI 166)
(ashiftrt:SI (reg/v:SI 164 [ v ])
(const_int 31 [0x1f])))

But it doesn't even try to do so with the 'ashrsi3_n_call' pattern.  Not sure
why ...

[Bug middle-end/110573] MIPS64: Enhancement PR of load of pointer to atomic

2023-07-06 Thread luke.geeson at cs dot ucl.ac.uk via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110573

--- Comment #1 from Luke Geeson  ---
My apologies - I should have put the ld on the line with L7:
```
.L7:ld  $3,%got_disp(P1_r0)($5). 

```

[Bug middle-end/110573] New: MIPS64: Enhancement PR of load of pointer to atomic

2023-07-06 Thread luke.geeson at cs dot ucl.ac.uk via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110573

Bug ID: 110573
   Summary: MIPS64: Enhancement PR of load of pointer to atomic
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luke.geeson at cs dot ucl.ac.uk
CC: luke.geeson at cs dot ucl.ac.uk
  Target Milestone: ---
Target: MIPS64

This is my first report for GCC so please forgive me if I make a mistake. This
is an enhancement report - the behaviour of the program is ok, but an
instruction could be removed to be consistent with the non-atomic variant of
the below code.

Consider the code in GCC 13.1.0 built for MIPS64
(https://godbolt.org/z/as68sEWda)

```
void P1() {
  int r0;
  r0 = *y;
  if(r0 == (1))   {
atomic_store_explicit(x,1,memory_order_release);  }

  *P1_r0 = r0;
}
```
When compiled using `-O1 -pthread -std=c11 -g -c` the branch to label L7 loads
a pointer to `P1_r0` using the delay slot. Likewise `P1_r0` is loaded the line
above L7 when the branch is taken. 


```
#... (code in if branch)
ld  $3,%got_disp(x)($5)

ld  $3,%got_disp(P1_r0)($5).# ld P1_r0 on branch taken
.L7:
ld  $3,0($3)
jr  $31
sw  $2,0($3)

.L6:
ld  $3,0($3)
sync
li  $4,1# 0x1
sw  $4,0($3)
b   .L7
ld  $3,%got_disp(P1_r0)($5).  # ld P1_r0 on branch not taken
```


The ld could be moved into L7, thus saving one instruction:


```
#... (code in if branch)
ld  $3,%got_disp(x)($5)
.L7:
ld  $3,0($3)
jr  $31
sw  $2,0($3)

.L6:ld  $3,%got_disp(P1_r0)($5). 
ld  $3,0($3)
sync
li  $4,1# 0x1
b   .L7
sw  $4,0($3)
```

The above optimisation already occurs if x is non-atomic (see
https://godbolt.org/z/8dhxvsE18)

The optimisation can also be applied for `-O2`
(https://godbolt.org/z/8aMj6xqTq)
as well.

I hope this helps.

[Bug target/106895] powerpc64 unable to specify even/odd register pairs in extended inline asm

2023-07-06 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

--- Comment #10 from Segher Boessenkool  ---
(In reply to Nicholas Piggin from comment #9)
> I don't know why constraint is wrong and mode is right

Simple: you would need O(2**T*N) constraints for our existing N register
constraints, together with T features like this.  But only O(2**T) modes at
most.

> or why TI doesn't work but PTI apparently would,

Because this is exactly what PTImode is *for*!

> but I'll take anything that works. Could we
> get PTI implemented? Does it need a new issue opened?

It was implemented in 2013.  The restriction to only even pairs was a bugfix,
also from 2013.

If you have code like

  typedef __int128 __attribute__((mode(PTI))) even;

you get an error like

  error: no data type for mode 'PTI'

This needs fixing.  You can keep it in this PR?

[Bug tree-optimization/110556] [12/13/14 Regression] division of INT_MIN and -1 happening incorrectly with -fno-delete-dead-exceptions -fnon-call-exceptions

2023-07-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110556

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

https://gcc.gnu.org/g:7b16686ef882ab141276f0e36a9d4ce1d755f64a

commit r14-2363-g7b16686ef882ab141276f0e36a9d4ce1d755f64a
Author: Richard Biener 
Date:   Thu Jul 6 13:51:55 2023 +0200

tree-optimization/110556 - tail merging still pre-tuples

The stmt comparison function for GIMPLE_ASSIGNs for tail merging
still looks like it deals with pre-tuples IL.  The following
attempts to fix this, not only comparing the first operand (sic!)
of stmts but all of them plus also compare the operation code.

PR tree-optimization/110556
* tree-ssa-tail-merge.cc (gimple_equal_p): Check
assign code and all operands of non-stores.

* gcc.dg/torture/pr110556.c: New testcase.

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

2023-07-06 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572

--- Comment #3 from Jonathan Wakely  ---
N.B. this can be reproduced without clang, just by using -std=c++20
-static-libstdc++

/usr/bin/x86_64-w64-mingw32-ld:
/home/jwakely/gcc/mingw/lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../x86_64-w64-mingw32/lib/../lib/libstdc++.a(tinfo.o):
in function `std::type_info::operator==(std::type_info const&) const':
/home/jwakely/src/gcc/build-mingw64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/../../../../gcc/libstdc++-v3/libsupc++/tinfo.cc:61:
multiple definition of `std::type_info::operator==(std::type_info const&)
const';
/tmp/ccmMqprE.o:/home/jwakely/gcc/mingw/x86_64-w64-mingw32/include/c++/13.0.1/typeinfo:194:
first defined here
collect2: error: ld returned 1 exit status

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

2023-07-06 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |12.4
   Last reconfirmed||2023-07-06
 Status|UNCONFIRMED |NEW
   Keywords||ABI

--- Comment #2 from Jonathan Wakely  ---
Prior to r12-6266-g3633cc54284450 making the definition in tinfo.cc inline
would have meant it is never emitted into tinfo.o (unless __attribute__((used))
was added to it).

Since the __equal alias, the operator== definition is always used, so it will
still generate a symbol even if it's an inline function. But I'm not sure
adding 'inline' there will actually fix anything. I still see it produce the
same symbol whether inline or not:

 T _ZNKSt9type_info7__equalERKS_
 T _ZNKSt9type_infoeqERKS_

I'm also concerned that the __equal function could end up in infinite
recursion. If you compile C++20 code then the inline definition of
type_info::operator== in the header is used, which calls type_info::__equal,
which is an alias for type_info::operator==. If the alias doesn't bind locally
then it could call the inline definition from the header again, and recurse.

I think a better fix would be to declare the operator== in the header with
__attribute__((__always_inline__)). That will ensure there is never a symbol
emitted for that inline definition, and so no multiple definition errors.

[Bug tree-optimization/110362] Range information on lower bytes of __uint128_t

2023-07-06 Thread roger at nextmovesoftware dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110362

Roger Sayle  changed:

   What|Removed |Added

  Component|rtl-optimization|tree-optimization
 CC||roger at nextmovesoftware dot 
com

--- Comment #2 from Roger Sayle  ---
The good news is that this has been fixed in the RTL optimizers/x86 backend,
and GCC-14 currently produces the optimal "mov rax, rdx".  However, I agree
with Richard Biener that could/should also be fixed (earlier) at the
tree-level.

[Bug target/110533] [x86-64] naked with -O0 and register-passed struct/int128 clobbers parameters/callee-saved regs

2023-07-06 Thread roger at nextmovesoftware dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110533

Roger Sayle  changed:

   What|Removed |Added

   Last reconfirmed||2023-07-06
 Ever confirmed|0   |1
 CC||roger at nextmovesoftware dot 
com
 Status|UNCONFIRMED |NEW

--- Comment #3 from Roger Sayle  ---
The patch recently proposed at
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623756.html would resolve
this issue.

[Bug tree-optimization/110556] [12/13/14 Regression] division of INT_MIN and -1 happening incorrectly with -fno-delete-dead-exceptions -fnon-call-exceptions

2023-07-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110556

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Biener  ---
The issue is tail merging and I think we have a duplicate bug for this.

find_duplicates:  duplicate of 
Removing basic block 7
;; basic block 7, loop depth 0
;;  pred:
_27 = -9223372036854775808 / si2_15(D);
goto ; [100.00%]

and we have

   [local count: 268435457]:
  _5 = si2_15(D) > 0;
  _6 = _1 | _5;
  if (_6 != 0)
goto ; [20.00%]
  else
goto ; [80.00%]

   [local count: 214748365]:
  _13 = -9223372036854775808 / si1_14(D);
  goto ; [100.00%]

   [local count: 301989889]:
  _7 = si1_14(D) > 0;
  _9 = _2 | _7;
  if (_9 != 0)
goto ; [0.00%]
  else
goto ; [100.00%]

   [local count: 301989888]:
  _27 = -9223372036854775808 / si2_15(D);
  goto ; [100.00%]

oddly enough gimple_equal_p looks strange:

case GIMPLE_ASSIGN:
  lhs1 = gimple_get_lhs (s1);
  lhs2 = gimple_get_lhs (s2);
  if (TREE_CODE (lhs1) != SSA_NAME
  && TREE_CODE (lhs2) != SSA_NAME)
return (operand_equal_p (lhs1, lhs2, 0)
&& gimple_operand_equal_value_p (gimple_assign_rhs1 (s1),
 gimple_assign_rhs1 (s2)));
  else if (TREE_CODE (lhs1) == SSA_NAME
   && TREE_CODE (lhs2) == SSA_NAME)
return operand_equal_p (gimple_assign_rhs1 (s1),
gimple_assign_rhs1 (s2), 0);

that looks pre-tuplish to me.

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

2023-07-06 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572

--- Comment #1 from Jonathan Wakely  ---
I would argue that the root cause is that Clang does not conform to the
platform ABI for mingw-w64, which requires __GXX_TYPEINFO_EQUALITY_INLINE=0 to
be defined.

[Bug tree-optimization/110557] [13/14 Regression] Wrong code for x86_64-linux-gnu with -O3 -mavx2: vectorized loop mishandles signed bit-fields

2023-07-06 Thread xry111 at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110557

--- Comment #4 from Xi Ruoyao  ---
Untested patch:

diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
index de20e9d59cb..01df568ee61 100644
--- a/gcc/tree-vect-patterns.cc
+++ b/gcc/tree-vect-patterns.cc
@@ -2566,7 +2566,7 @@ vect_recog_widen_sum_pattern (vec_info *vinfo,
Widening with mask first, shift later:
container = (type_out) container;
masked = container & (((1 << bitsize) - 1) << bitpos);
-   result = patt2 >> masked;
+   result = masked >> bitpos;

Widening with shift first, mask last:
container = (type_out) container;
@@ -2578,6 +2578,15 @@ vect_recog_widen_sum_pattern (vec_info *vinfo,
result = masked >> bitpos;
result = (type_out) result;

+   If the bitfield is signed and the its width is greater than the width
+   of type_out, we need to perform a sign-extension:
+   container = (type) container;
+   masked = container << (prec - bitsize - bitpos);
+   result = (type_out) (masked >> (prec - bitsize));
+
+   Here type is the signed variant of the wider of type_out and the type
+   of container.
+
The shifting is always optional depending on whether bitpos != 0.

 */
@@ -2636,14 +2645,22 @@ vect_recog_bitfield_ref_pattern (vec_info *vinfo,
stmt_vec_info stmt_info,
   if (BYTES_BIG_ENDIAN)
 shift_n = prec - shift_n - mask_width;

+  bool sign_ext = !TYPE_UNSIGNED (TREE_TYPE (bf_ref)) &&
+ TYPE_PRECISION (ret_type) > mask_width;
+  bool widening = ((TYPE_PRECISION (TREE_TYPE (container)) <
+   TYPE_PRECISION (ret_type))
+  && !useless_type_conversion_p (TREE_TYPE (container),
+ ret_type));
+
   /* We move the conversion earlier if the loaded type is smaller than the
  return type to enable the use of widening loads.  */
-  if (TYPE_PRECISION (TREE_TYPE (container)) < TYPE_PRECISION (ret_type)
-  && !useless_type_conversion_p (TREE_TYPE (container), ret_type))
+  if (sign_ext || widening)
 {
-  pattern_stmt
-   = gimple_build_assign (vect_recog_temp_ssa_var (ret_type),
-  NOP_EXPR, container);
+  tree type = widening ? ret_type : container_type;
+  if (sign_ext)
+   type = gimple_signed_type (type);
+  pattern_stmt = gimple_build_assign (vect_recog_temp_ssa_var (type),
+ NOP_EXPR, container);
   container = gimple_get_lhs (pattern_stmt);
   container_type = TREE_TYPE (container);
   prec = tree_to_uhwi (TYPE_SIZE (container_type));
@@ -2671,7 +2688,7 @@ vect_recog_bitfield_ref_pattern (vec_info *vinfo,
stmt_vec_info stmt_info,
 shift_first = true;

   tree result;
-  if (shift_first)
+  if (shift_first && !sign_ext)
 {
   tree shifted = container;
   if (shift_n)
@@ -2694,14 +2711,27 @@ vect_recog_bitfield_ref_pattern (vec_info *vinfo,
stmt_vec_info stmt_info,
 }
   else
 {
-  tree mask = wide_int_to_tree (container_type,
-   wi::shifted_mask (shift_n, mask_width,
- false, prec));
-  pattern_stmt
-   = gimple_build_assign (vect_recog_temp_ssa_var (container_type),
-  BIT_AND_EXPR, container, mask);
-  tree masked = gimple_assign_lhs (pattern_stmt);
+  tree temp = vect_recog_temp_ssa_var (container_type);
+  if (!sign_ext)
+   {
+ tree mask = wide_int_to_tree (container_type,
+   wi::shifted_mask (shift_n,
+ mask_width,
+ false, prec));
+ pattern_stmt = gimple_build_assign (temp, BIT_AND_EXPR,
+ container, mask);
+   }
+  else
+   {
+ HOST_WIDE_INT shl = prec - shift_n - mask_width;
+ shift_n += shl;
+ pattern_stmt = gimple_build_assign (temp, LSHIFT_EXPR,
+ container,
+ build_int_cst (sizetype,
+shl));
+   }

+  tree masked = gimple_assign_lhs (pattern_stmt);
   append_pattern_def_seq (vinfo, stmt_info, pattern_stmt, vectype);
   pattern_stmt
= gimple_build_assign (vect_recog_temp_ssa_var (container_type),

[Bug target/106895] powerpc64 unable to specify even/odd register pairs in extended inline asm

2023-07-06 Thread npiggin at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

--- Comment #9 from Nicholas Piggin  ---
(In reply to Segher Boessenkool from comment #8)
> (In reply to Peter Bergner from comment #6)
> > (In reply to Segher Boessenkool from comment #5)
> > > Constraints are completely the wrong tool for this.  Just use modes, which
> > > *are* the right tool?
> > 
> > Well you cannot specify modes in the asm, so I think you're saying we need
> > use the correct type that maps to a internal to GCC mode that has the
> > even/odd register behavior, so something like:
> > 
> >   unsigned int foo __attribute__ ((mode (XX)));
> > 
> > ...where XXmode is the new integer mode that gives us even/odd register
> > pairs?  Of course we have to be careful about how this all works wrt -m32
> > versus -m64.
> 
> No, the type there is "unsigned int".  I meant to say exactly what I did say:
> just use modes.  Which you indeed do in user code by the mode attribute, yes.
> 
> And you do not need a new mode: PTImode should just work.  But the user
> specifying that is currently broken it seems?

I don't know why constraint is wrong and mode is right or why TI doesn't work
but PTI apparently would, but I'll take anything that works. Could we get PTI
implemented? Does it need a new issue opened?

> 
> Without -mpowerpc64 you cannot *have* 128-bit integers in registers.  That
> should be
> fixed, but you cannot have it in just *two* registers, which is what is
> required
> here.  For most targets that then means -m64 is required.

[Bug libstdc++/110572] New: ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

2023-07-06 Thread arndtthomas at gmx dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572

Bug ID: 110572
   Summary: ld.lld: error: duplicate symbol:
std::type_info::operator==(std::type_info const&)
const
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arndtthomas at gmx dot de
  Target Milestone: ---

Created attachment 55489
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55489=edit
example to reproduce the error

I've filed the issue since it's a problem with libstdc++/tinfo.o.
It seems there is a missing inline if macro __GXX_TYPEINFO_EQUALITY_INLINE is
unset or set to 1.

It happens if clang is used under mingw-w64 in combination with the libstdc++
(msys2 default).
Since gcc defines the macro explicitly (built-in) to
_GXX_TYPEINFO_EQUALITY_INLINE=0 (see gcc/config/i386/cygming.h).
Clang doesn't define this macro at all, so it gets defined within typeinfo
while compiling user code. Thus there are one operator== defined within tinfo.o
and another within the user archive.

During linking the following error pops up:

ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info
const&) const
>>> defined at ../../../../libstdc++-v3/libsupc++/tinfo.cc:38
>>>libstdc++.a(tinfo.o)
>>> defined at libclang_lld_error.a(comp_unit.o)
clang++: error: linker command failed with exit code 1 (use -v to see
invocation)

Here is the full example to reproduce:
https://github.com/msys2/MINGW-packages/issues/17730

I fully agree, it's a issue which is more related to mingw-w64 and clang but
the root cause is unfortunately the libstdc++.

[Bug c/54179] please split insn-emit.c !

2023-07-06 Thread mmokrejs at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179

mmokrejs at gmail dot com changed:

   What|Removed |Added

 CC||mmokrejs at gmail dot com

--- Comment #31 from mmokrejs at gmail dot com ---
Still happens with gcc-12.3.1_p20230526 on Gentoo Linux on a 2 GB RAM virtual
server running out of memory due to -O2 and triggers Oom killer. I tried -O1
but it was not enough. However, -O0 worked for me. The problem is that the
bootstrapping check failed, probably because of some differences.

/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build/./prev-gcc/xg++
-B/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build/./prev-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
 -isystem
/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
 -isystem
/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
 -isystem
/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/libstdc++-v3/libsupc++
-L/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c -fno-PIE-m64 -pipe -march=x86-64 -O0 -fno-checking -gtoggle
-DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/gcc
-I/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/gcc/.
-I/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/gcc/../include
-I/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/gcc/../libcpp/include
-I/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/gcc/../libcody

-I/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/gcc/../libdecnumber
-I/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/gcc/../libdecnumber/bid
-I../libdecnumber
-I/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/gcc/../libbacktrace
  -o insn-emit.o -MT insn-emit.o -MMD -MP -MF ./.deps/insn-emit.TPo
insn-emit.cc


make[3]: Entering directory
'/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build'
rm -f stage_current
make[3]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build'
Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/insn-emit.o differs
make[2]: *** [Makefile:24126: compare] Error 1
make[2]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build'

[Bug tree-optimization/110563] [14 regression] Many ICEs after r14-2281

2023-07-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110563

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Should be fixed now.

[Bug tree-optimization/110563] [14 regression] Many ICEs after r14-2281

2023-07-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110563

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

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

commit r14-2354-gdeebf06a1207bf7d84f4bebc462137d9436ee6dd
Author: Richard Biener 
Date:   Thu Jul 6 09:56:23 2023 +0200

tree-optimization/110563 - simplify epilogue VF checks

The following consolidates an assert that now hits for ppc64le
with an earlier check we already do, simplifying
vect_determine_partial_vectors_and_peeling and getting rid of
its now redundant argument.

PR tree-optimization/110563
* tree-vectorizer.h (vect_determine_partial_vectors_and_peeling):
Remove second argument.
* tree-vect-loop.cc (vect_determine_partial_vectors_and_peeling):
Remove for_epilogue_p argument.  Merge assert ...
(vect_analyze_loop_2): ... with check done before determining
partial vectors by moving it after.
* tree-vect-loop-manip.cc (vect_do_peeling): Adjust.

[Bug tree-optimization/110557] [13/14 Regression] Wrong code for x86_64-linux-gnu with -O3 -mavx2: vectorized loop mishandles signed bit-fields

2023-07-06 Thread xry111 at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110557

--- Comment #3 from Xi Ruoyao  ---
It looks like if !UNSIGNED_TYPE (TREE_TYPE (bf_ref)), we need to generate
something like:

masked = (the signed variant of the wider type in {type_out, type_container})
container << (bitpos + bitsize);
result = (type_out) >> bitpos;

[Bug tree-optimization/110557] [13/14 Regression] Wrong code for x86_64-linux-gnu with -O3 -mavx2: vectorized loop mishandles signed bit-fields

2023-07-06 Thread avieira at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110557

avieira at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from avieira at gcc dot gnu.org ---
I'll have a look.

[Bug tree-optimization/110571] New: vect_determine_partial_vectors_and_peeling required at vect_do_peeling time

2023-07-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110571

Bug ID: 110571
   Summary: vect_determine_partial_vectors_and_peeling required at
vect_do_peeling time
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

When one removes the seemingly no-op call of
vect_determine_partial_vectors_and_peeling in vect_do_peeling you run into
execute FAILs of for example gcc.dg/vect/vect-peel-1-epilogue.c because
that call does

  LOOP_VINFO_PEELING_FOR_NITER (loop_vinfo)
= (!LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo)
   && need_peeling_or_partial_vectors_p);

which due to vect_need_peeling_or_partial_vectors_p looking at
LOOP_VINFO_INT_NITERS needs to behave differently for the case of
the known number of iterations when falling through from the vector
loop as opposed to when coming around the skip edge.

The caller in vect_do_peeling immediately before adjusts niter:

  /* Subtract the number of iterations performed by the vectorized loop
 from the number of total iterations.  */
  tree epilogue_niters = fold_build2 (MINUS_EXPR, TREE_TYPE (niters),
  before_loop_niters,
  niters);

  LOOP_VINFO_NITERS (epilogue_vinfo) = epilogue_niters;
  LOOP_VINFO_NITERSM1 (epilogue_vinfo)
= fold_build2 (MINUS_EXPR, TREE_TYPE (epilogue_niters),
   epilogue_niters,
   build_one_cst (TREE_TYPE (epilogue_niters)));

and then gets the correct answer.

The LOOP_VINFO_NITERS is arguably wrong during most parts of the re-analysis
of the loop as epilogue leading to these kind of issues.

While I think we apply peeling for alignment before going the skip edge way
there is LOOP_VINFO_PEELING_FOR_GAPS which can differ between main and
epilogue.  I think we need to know whether we are going to have a skip
edge or not and compute vect_need_peeling_or_partial_vectors_p for the
epilog for both niter kinds.

It's arguably main loop analysis that should compute a (bound) for the
epilogue number of iterations.

[Bug middle-end/110515] [12/13 Regression] llvm-15.0.7 possibly invalid code on -O3

2023-07-06 Thread slyfox at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110515

--- Comment #13 from Sergei Trofimovich  ---
I confirm the change fixed llvm-15.0.7 test suite. Thank you!

[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails

2023-07-06 Thread mikael at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419

--- Comment #14 from Mikael Morin  ---
The tree optimized dumps are almost the same for 32 and 64 bits.

The expand dumps show more significant differences.


The 64 bits dump shows the register r4 is saved to memory  with:

(insn 3 2 4 2 (set (mem/c:QI (plus:DI (reg/f:DI 111 virtual-incoming-args)
(const_int 8 [0x8])) [10 c+0 S1 A64])
(reg:QI 4 4 [ c ])) "pr110419_comment4.f90":6:16 -1
 (nil))


The 32 bits dump shows:

(insn 3 2 4 2 (set (reg/v:SI 119)
(reg:SI 4 4)) "pr110419_comment4.f90":6:16 -1
 (nil))
(insn 4 3 5 2 (set (reg:QI 120)
(mem/c:QI (reg/v:SI 119) [10 c+0 S1 A8])) "pr110419_comment4.f90":6:16
-1
 (nil))

[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails

2023-07-06 Thread mikael at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419

--- Comment #13 from Mikael Morin  ---
Created attachment 55488
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55488=edit
-m64 rtl final dump at -O0

[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails

2023-07-06 Thread mikael at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419

--- Comment #12 from Mikael Morin  ---
Created attachment 55487
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55487=edit
-m64 rtl expand dump at -O0

[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails

2023-07-06 Thread mikael at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419

--- Comment #11 from Mikael Morin  ---
Created attachment 55486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55486=edit
-m64tree optimized (at -O0) dump

[Bug c/110568] ftrivial-auto-var-init= has no effect on return values in C

2023-07-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110568

Richard Biener  changed:

   What|Removed |Added

  Component|middle-end  |c

--- Comment #1 from Richard Biener  ---
Well, the return is missing here ... if the frontend would emit

int f (void)
{
  return D.1234; // uninitialized
}

then it would work.  The C++ FE emits __builtin_unreachable traps () instead.
I think this should be addressed in the frontend.

[Bug c++/110566] [13/14 Regression] ICE when instantiating function template with template template parameter with 2 or more auto parameters with a dependent member template, ICE in tsubst, at cp/pt.c

2023-07-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110566

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/110565] [10/11/12/13/14 Regression] Incomplete note on why initializing int& with int is ill-formed

2023-07-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110565

Richard Biener  changed:

   What|Removed |Added

Version|unknown |13.1.1
   Target Milestone|--- |10.5

[Bug tree-optimization/110557] [13/14 Regression] Wrong code for x86_64-linux-gnu with -O3 -mavx2: vectorized loop mishandles signed bit-fields

2023-07-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110557

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/110556] [12/13/14 Regression] division of INT_MIN and -1 happening incorrectly with -fno-delete-dead-exceptions -fnon-call-exceptions

2023-07-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110556

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #10 from Richard Biener  ---
Needs investigation on what actually does an invalid transform. 
-fno-thread-jumps avoids the issue.

[Bug c++/110570] New: Error reading mutable subobject in constexpr when object lifetime began within the evaluation of E

2023-07-06 Thread fchelnokov at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110570

Bug ID: 110570
   Summary: Error reading mutable subobject in constexpr when
object lifetime began within the evaluation of E
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This program

struct S {
mutable int i = 2;
};

constexpr auto f = []{
constexpr S s;
s.i = 3;
return s.i;
};

static_assert( f() == 3 );

is accepted in Clang, MSVC and ICC.

But GCC rejects the code with the error

  in 'constexpr' expansion of 'f.()'
error: mutable 'S::i' is not usable in a constant expression

Online demo: https://gcc.godbolt.org/z/Wsfeah3hq

It seems wrong, since lifetime of object s begins within the evaluation of
constant expression, see
https://timsong-cpp.github.io/cppwp/n4861/expr.const#5.16

Clang developers think that GCC is wrong here:
https://github.com/llvm/llvm-project/issues/63695

SO question: https://stackoverflow.com/q/76608087/7325599

[Bug middle-end/110515] [12/13 Regression] llvm-15.0.7 possibly invalid code on -O3

2023-07-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110515

Richard Biener  changed:

   What|Removed |Added

Summary|[12/13/14 Regression]   |[12/13 Regression]
   |llvm-15.0.7 possibly|llvm-15.0.7 possibly
   |invalid code on -O3 |invalid code on -O3
  Known to work||14.0

--- Comment #12 from Richard Biener  ---
Fixed on trunk sofar.

[Bug middle-end/110515] [12/13/14 Regression] llvm-15.0.7 possibly invalid code on -O3

2023-07-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110515

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

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

commit r14-2344-g9f4f833455bb35c11d03e93f802604ac7cd8b740
Author: Richard Biener 
Date:   Wed Jul 5 15:57:49 2023 +0200

tree-optimization/110515 - wrong code with LIM + PRE

In this PR we face the issue that LIM speculates a load when
hoisting it out of the loop (since it knows it cannot trap).
Unfortunately this exposes undefined behavior when the load
accesses memory with the wrong dynamic type.  This later
makes PRE use that representation instead of the original
which accesses the same memory location but using a different
dynamic type leading to a wrong disambiguation of that
original access against another and thus a wrong-code transform.

Fortunately there already is code in PRE dealing with a similar
situation for code hoisting but that left a small gap which
when fixed also fixes the wrong-code transform in this bug even
if it doesn't address the underlying issue of LIM speculating
that load.

The upside is this fix is trivially safe to backport and chances
of code generation regressions are very low.

PR tree-optimization/110515
* tree-ssa-pre.cc (compute_avail): Make code dealing
with hoisting loads with different alias-sets more
robust.

* g++.dg/opt/pr110515.C: New testcase.

[Bug tree-optimization/110563] [14 regression] Many ICEs after r14-2281

2023-07-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110563

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2023-07-06
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

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

[Bug tree-optimization/110544] [14 regression] gcc.dg/vect/pr71264.c ICEs after r14-2150

2023-07-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110544

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

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

commit r14-2342-g2ab065c3e6950bc4995fcb16cebc5164d6213708
Author: Richard Biener 
Date:   Thu Jul 6 08:52:46 2023 +0200

Fix expectation on gcc.dg/vect/pr71264.c

With the recent change to more reliably not vectorize code already
using vector types we run into FAILs of gcc.dg/vect/pr71264.c
The testcase was added for fixing an ICE and possible (re-)vectorization
of the code isn't really supported and I suspect might even go
wrong for non-bitops.

The following leaves the testcase as just testing for an ICE.

PR tree-optimization/110544
* gcc.dg/vect/pr71264.c: Remove scan for vectorization.

[Bug tree-optimization/110544] [14 regression] gcc.dg/vect/pr71264.c ICEs after r14-2150

2023-07-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110544

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug tree-optimization/110554] veclowering introduces invalid wide Boolean values

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110554

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
Fixed.

[Bug middle-end/88670] [meta-bug] generic vector extension issues

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670
Bug 88670 depends on bug 110554, which changed state.

Bug 110554 Summary: veclowering introduces invalid wide Boolean values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110554

   What|Removed |Added

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

[Bug tree-optimization/110554] veclowering introduces invalid wide Boolean values

2023-07-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110554

--- Comment #8 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r14-2338-ga73b65b74105e76473cc2825bb4e7253deaf18b3
Author: Andrew Pinski 
Date:   Tue Jul 4 20:38:06 2023 -0700

Fix PR 110554: vec lowering introduces scalar signed-boolean:32 comparisons

So the problem is vector generic decided to do comparisons in
signed-boolean:32
types but the rest of the middle-end was not ready for that. Since we are
building
the comparison which will feed into a cond_expr here, using
boolean_type_node is
better and also correct. The rest of the compiler thinks the ranges for
comparison is always [0,1] too.

Note this code does not currently lowers bigger vector sizes into smaller
vector sizes so using boolean_type_node here is better.

OK? bootstrapped and tested on x86_64-linux-gnu with no regressions.

gcc/ChangeLog:

PR middle-end/110554
* tree-vect-generic.cc (expand_vector_condition): For comparisons,
just build using boolean_type_node instead of the cond_type.
For non-comparisons/non-scalar-bitmask, build a ` != 0` gimple
that will feed into the COND_EXPR.

[Bug tree-optimization/110252] [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110252

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

[Bug tree-optimization/110569] [14 Regression] Different results among -O0, -O1 and -Os

2023-07-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110569

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
   Keywords||wrong-code
 Status|UNCONFIRMED |RESOLVED

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

phiopt match-simplify trying:
_4 > 1 ? 1 : iftmp.3_32
Matching expression match.pd:1991, gimple-match-5.cc:23
Matching expression match.pd:1991, gimple-match-5.cc:23
Applying pattern match.pd:4763, gimple-match-7.cc:16232
Folded into the sequence:
_15 = _4 > 1;
_10 = (unsigned int) _15;
_9 = _10 | iftmp.3_32;
statement un-sinked:
iftmp.3_32 = (unsigned int) _4;

  # RANGE [irange] unsigned int [0, 1] NONZERO 0x1
  iftmp.3_32 = (unsigned intD.9) _4;

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

  1   2   >