[Bug libstdc++/110574] --enable-cstdio=stdio_pure is incompatible with LFS
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[Bug libstdc++/104299] Doc: stdio is not the only option in --enable-cstdio=XXX
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 !
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ***
