[Bug debug/112703] [13/14 Regression] -fcompare-debug failure at -O1 and above

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-11-27
   Target Milestone|--- |13.3

--- Comment #1 from Richard Biener  ---
Confirmed with the C++ frontend.  -gno-statement-frontiers avoids this.

[Bug preprocessor/112701] wrong type inference for ternary operator with `0/0u` in preprocessing context

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

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

--- Comment #3 from Richard Biener  ---
Heh, I didn't know ?: is valid as preprocessor conditional.

[Bug c/112720] New: ICE: Segmentation fault during IPA pass: tmipa

[iamanonymous.cs at gmail dot com via Gcc-bugs]

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

Bug ID: 112720
   Summary: ICE: Segmentation fault during IPA pass: tmipa
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/root/gcc_set/202311021000/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/202311021000/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/202311021000
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leak
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231102 (experimental) (GCC)

git version: d508a94167c186b2baacc679896e2809554c0b99
***
Program:
$ cat mutant.c
typedef struct S {
  int * val;
  struct S *next;
} s;

s *next;
int a;

static int func(int * val)
{
  int b;
  int * v;
  __transaction_relaxed {
v = next->val;
b = (v == val);
if (b)
  b = 2;
  }
  return b;
}

void test(void *data)
{
  extern void bark(void);
  if (func(0))
bark();
  a = 99;
}

***
Command Lines:
$ gcc -fgnu-tm -c -fsanitize=undefined mutant.c
during IPA pass: tmipa
mutant.c: In function ‘func’:
mutant.c:29:1: internal compiler error: Segmentation fault
   29 | }
  | ^
0xffebdf crash_signal
../../gcc/gcc/toplev.cc:315
0x1004fd0 is_tm_irrevocable
../../gcc/gcc/trans-mem.cc:237
0x100720e ipa_tm_scan_irr_block
../../gcc/gcc/trans-mem.cc:4396
0x100720e ipa_tm_scan_irr_blocks
../../gcc/gcc/trans-mem.cc:4464
0x1007683 ipa_tm_scan_irr_function
../../gcc/gcc/trans-mem.cc:4643
0x1008ae7 ipa_tm_execute
../../gcc/gcc/trans-mem.cc:5526
0x1008ae7 execute
../../gcc/gcc/trans-mem.cc:5686
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/110062] missed vectorization in graphicsmagick

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

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

--- Comment #12 from Richard Biener  ---
(In reply to Jan Hubicka from comment #11)
> trunk -O3 -flto -march=native -fopenmp
> Operation: Sharpen:
> 257
> 256
> 256
> 
> Average: 256 Iterations Per Minute
> GCC13 -O3 -flto -march=native -fopenmp
> 257
> 256
> 256
> 
> Average: 256 Iterations Per Minute
> clang17 O3 -flto -march=native -fopenmp
>Operation: Sharpen:
> 257
> 256
> 256
> Average: 256 Iterations Per Minute
> 
> So I guess I will need to try on zen3 to see if there is any difference.
> 
> the internal loop is:
>   0.00 │460:┌─→movzbl  0x2(%rdx,%rax,4),%esi ▒
>   0.02 ││  vmovss  (%r8,%rax,4),%xmm2▒
>   0.95 ││  vcvtsi2ss   %esi,%xmm0,%xmm1  ▒
>  20.22 ││  movzbl  0x1(%rdx,%rax,4),%esi ▒
>   0.01 ││  vfmadd231ss %xmm1,%xmm2,%xmm3 ▒
>  11.97 ││  vcvtsi2ss   %esi,%xmm0,%xmm1  ▒
>  18.76 ││  movzbl  (%rdx,%rax,4),%esi▒
>   0.00 ││  inc %rax  ▒
>   0.72 ││  vfmadd231ss %xmm1,%xmm2,%xmm4 ▒
>  12.55 ││  vcvtsi2ss   %esi,%xmm0,%xmm1  ▒
>  14.95 ││  vfmadd231ss %xmm1,%xmm2,%xmm5 ▒
>  15.93 │├──cmp %rax,%r13 ▒
>   0.35 │└──jne 460  
> 
> 
> so it still does not get

As said the VF is going to be prohibitively large, likely the vector code
is never entered and the above is the scalar "epilogue".

[Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming

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

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

--- Comment #27 from Richard Biener  ---
(In reply to Eric Gallager from comment #26)
> (In reply to Richard Biener from comment #20)
> > Unfortunately there isn't a knob to diagnose late inlined always-inline
> > functions.
> 
> Is there a separate bug for this?

I don't think so.

[Bug middle-end/112653] PTA should handle correctly escape information of values returned by a function

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
Mine.

[Bug middle-end/112653] PTA should handle correctly escape information of values returned by a function

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #9 from rguenther at suse dot de  ---
On Fri, 24 Nov 2023, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
> 
> --- Comment #8 from Jan Hubicka  ---
> On ARM32 and other targets methods returns this pointer.  Togher with making
> return value escape this probably completely disables any chance for IPA
> tracking of C++ data types...

Note that all call and global var escapes would also go to
"return escape", so the only extra bit you get is the reverse,
what escapes the explicit return doesn't escape through calls.
We'd have

RETURN_ESCAPE = ESCAPED

And handle return by adding to RETURN_ESCAPED but not ESCAPED.
Then for example DSE needs to properly query whether sth escaped
through function return (ptr_deref_may_alias_global_p & friends).

The cost is an extra bitmap in struct function.

I will have a look if it's reasonably easy to implement.

[Bug target/112719] New: [14 Regression] ICE: in decompose, at wide-int.h:1049 with -O -msse4 and __builtin_popcountl()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112719
   Summary: [14 Regression] ICE: in decompose, at wide-int.h:1049
with -O -msse4 and __builtin_popcountl()
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 56693
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56693&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -msse4 testcase.c 
during GIMPLE pass: forwprop
testcase.c: In function 'foo':
testcase.c:5:1: internal compiler error: in decompose, at wide-int.h:1049
5 | }
  | ^
0xda660c wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
/repo/gcc-trunk/gcc/wide-int.h:1049
0xda6dc9 wi::int_traits >::decompose(long*,
unsigned int, generic_wide_int const&)
/repo/gcc-trunk/gcc/tree.h:3748
0xda6dc9 wide_int_ref_storage::wide_int_ref_storage
>(generic_wide_int const&, unsigned int)
/repo/gcc-trunk/gcc/wide-int.h:1099
0xda6dc9 generic_wide_int
>::generic_wide_int
>(generic_wide_int const&, unsigned int)
/repo/gcc-trunk/gcc/wide-int.h:855
0xda6dc9 wi::binary_traits,
generic_wide_int,
wi::int_traits >::precision_type,
wi::int_traits
>::precision_type>::result_type wi::bit_and,
generic_wide_int >(generic_wide_int const&,
generic_wide_int const&)
/repo/gcc-trunk/gcc/wide-int.h:2756
0xda6dc9 gimple_simplify_71(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node*, tree_node**, combined_fn)
/repo/build-gcc-trunk-amd64/gcc/gimple-match-2.cc:580
0x1af1419 gimple_simplify_PLUS_EXPR(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*)
/repo/build-gcc-trunk-amd64/gcc/gimple-match-9.cc:12234
0x1b2ec8a gimple_resimplify2
/repo/gcc-trunk/gcc/gimple-match-exports.cc:1008
0x1b2f917 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
/repo/gcc-trunk/gcc/gimple-match-exports.cc:875
0x114d4ac fold_stmt_1
/repo/gcc-trunk/gcc/gimple-fold.cc:6353
0x162f7dd execute
/repo/gcc-trunk/gcc/tree-ssa-forwprop.cc:3950
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-5865-20231127072427-gb6db325ac3e-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-5865-20231127072427-gb6db325ac3e-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231127 (experimental) (GCC)

[Bug debug/112718] New: [11/12/13/14 Regression] ICE: in add_dwarf_attr, at dwarf2out.cc:4501 with -g -fdebug-types-section -flto -fno-use-linker-plugin

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112718
   Summary: [11/12/13/14 Regression] ICE: in add_dwarf_attr, at
dwarf2out.cc:4501 with -g -fdebug-types-section -flto
-fno-use-linker-plugin
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 56692
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56692&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -g -fdebug-types-section -flto -fno-use-linker-plugin
testcase.c
testcase.c:8:1: internal compiler error: in add_dwarf_attr, at
dwarf2out.cc:4501
8 | } _EC_X9_62_PRIME_192V3;
  | ^
0x73f5ce add_dwarf_attr
/repo/gcc-trunk/gcc/dwarf2out.cc:4501
0x74151f add_dwarf_attr
/repo/gcc-trunk/gcc/vec.h:715
0x74151f add_AT_die_ref
/repo/gcc-trunk/gcc/dwarf2out.cc:4925
0x74151f add_sibling_attributes
/repo/gcc-trunk/gcc/dwarf2out.cc:8983
0x101524b add_sibling_attributes
/repo/gcc-trunk/gcc/dwarf2out.cc:8985
0x1051b4f dwarf2out_finish
/repo/gcc-trunk/gcc/dwarf2out.cc:32318
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-5865-20231127072427-gb6db325ac3e-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-5865-20231127072427-gb6db325ac3e-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231127 (experimental) (GCC)

[Bug target/107844] error: argument is not a field access for __builtin_preserve_field_info

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

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

Jose E. Marchesi  changed:

   What|Removed |Added

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

--- Comment #7 from Jose E. Marchesi  ---
This is fixed by the commit above.

[Bug target/112675] [14 Regression] r14-5385-g0a140730c97087 caused regression on testcases for i386

[haochen.jiang at intel dot com via Gcc-bugs]

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

Haochen Jiang  changed:

   What|Removed |Added

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

--- Comment #2 from Haochen Jiang  ---
Aha, it has been fixed on trunk. I will close that.

Thanks!

[Bug testsuite/112689] [14 Regression] gcc.dg/tree-prof/time-profiler-[237].c fail

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

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

--- Comment #1 from Andrew Pinski  ---
Wait -3 was caused by g:41aacdea55c5d795a7aa195357d966645845d00e  :
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638207.html

So maybe all 3 were.

[Bug target/112598] RISC-V regression testsuite errors with rv64gcv_zvl512b

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #10 from Li Pan  ---
Link to one similar issue as below.

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

[Bug target/112707] [14 regression] gcc 14 outputs invalid assembly on ppc: Error: unrecognized opcode: `fctid'

[csfore at posteo dot net via Gcc-bugs]

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

--- Comment #7 from Christopher Fore  ---
Created attachment 56691
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56691&action=edit
build log of the original compile

[Bug target/112707] [14 regression] gcc 14 outputs invalid assembly on ppc: Error: unrecognized opcode: `fctid'

[csfore at posteo dot net via Gcc-bugs]

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

--- Comment #6 from Christopher Fore  ---
The original example in the wild was with -mcpu=7450 -O2 -maltivec
-mabi=altivec -pipe, plus the flags the build system added, then I minimised it
to the attachment above, where I only needed: -O3 -ffast-math.

[Bug target/112707] [14 regression] gcc 14 outputs invalid assembly on ppc: Error: unrecognized opcode: `fctid'

[csfore at posteo dot net via Gcc-bugs]

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

--- Comment #5 from Christopher Fore  ---
It's a PowerPC 7447A and the assembler version is:

GNU assembler version 2.40.0 (powerpc-unknown-linux-gnu) using BFD version
(Gentoo 2.40 p5) 2.40.0

[Bug target/112707] [14 regression] gcc 14 outputs invalid assembly on ppc: Error: unrecognized opcode: `fctid'

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

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

HaoChen Gui  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org

--- Comment #4 from HaoChen Gui  ---
I can't reproduce it on my env. Could you inform me the assembler version and
CPU type you used or the default CPU type. Thanks.

[Bug gcov-profile/112717] .gcda profiles compatibility guarantees between GCC versions

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

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

--- Comment #4 from Andrew Pinski  ---
My suggestion is only do profiling build right before release. And never store
the files in a repo at all. Any changes to the source base will cause the
profile to be wrong.

Maybe do it as part of a CI instead of storing around them.

[Bug gcov-profile/112717] .gcda profiles compatibility guarantees between GCC versions

[zamazan4ik at tut dot by via Gcc-bugs]

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

--- Comment #3 from Alexander Zaitsev  ---
> I thought this was documented but I don't see. There is no guarantee for 
> forward or backwards compatibility at all. In fact iirc there is a version 
> stored in the files to make sure the correct version is used with the version 
> of tools/compiler.

Could we add this information to the documentation? Would be really helpful to
the users to know this detail.

Since your answer am I right that right now it's a strong
recommendation/requirement to regenerate PGO profiles with each GCC update?

[Bug gcov-profile/112717] .gcda profiles compatibility guarantees between GCC versions

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #2 from Sam James  ---
Related but a different problem:
https://github.com/llvm/llvm-project/issues/52683.

[Bug gcov-profile/112717] .gcda profiles compatibility guarantees between GCC versions

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

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

--- Comment #1 from Andrew Pinski  ---
I thought this was documented but I don't see. There is no guarantee for
forward or backwards compatibility at all. In fact iirc there is a version
stored in the files to make sure the correct version is used with the version
of tools/compiler.

Plus not only different versions of the compiler changes profile data but also
different preprocessed sources could change the profile data (that even means
compiler options which change macros, e.g. -D* and even some -f/-m options
define some macros that could change the sources being processed).

[Bug gcov-profile/112717] New: .gcda profiles compatibility guarantees between GCC versions

[zamazan4ik at tut dot by via Gcc-bugs]

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

Bug ID: 112717
   Summary: .gcda profiles compatibility guarantees between GCC
versions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zamazan4ik at tut dot by
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hi. I have several questions regarding .gcda profiles re-usage between GCC
versions for Profile-Guided Optimization (PGO) purposes.

The first question goes about forward and backward guarantees .gcda profiles. I
didn't find related information in the GCC documentation. Are there guarantees
in this area? Like "it's guaranteed that .gcda profiles from GCC version N will
be always readable by GCC version N+1", where N is a minor/major GCC version.
For us it's an important question since we are thinking about caching .gcda
profiles in storage so PGO profiles can be reused later probably with a newer
compiler. This goes in another direction too in the case if we generated the
PGO profile with GCC 10 and some time later decided to revert the compiler to
GCC 9. If there are some guarantees in this area, would be great to see them
documented somewhere in the documentation (probably in a place like
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html).

The second question is about PGO profiles reusability between GCC versions. As
far as I understand, PGO profiles track some "counters" about the code.
Possibly these counters can rely somehow on the performed by GCC optimizations
(it's just my guess). Let's imagine that GCC 11 added more optimization passes
that affect somehow generated code (e.g. much more aggressive inlining compared
to GCC 10). In this case, probably, PGO profiles from GCC 10 wouldn't be useful
anymore and we will need to regenerate them once again but with GCC 11. Is this
scenario real? If yes, are there ways to mitigate it somehow?

For LLVM I have the same questions that are discussed here:
https://discourse.llvm.org/t/profile-guided-optimization-pgo-related-questions-and-suggestions/75232
. As far as I understand, GCC also implements PGO on something like "IR" (don't
know how it's called properly in GCC - "Generic" or "GIMPLE"?), so probably
some answers from LLVM would be applicable to GCC as well.

[Bug target/112454] csinc (csel is though) is not being used when there is matches twice

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

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

--- Comment #4 from Andrew Pinski  ---
So it looks like this is not only a cost issue. I have to look into forwprop to
see if it can handle this. Note the cost issue does need to be fixed anyways
since it will be needed there; otherwise forwprop might reject it.

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b since r14-5101-g60034ecf25597b

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

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

Richard Sandiford  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |rsandifo at gcc dot 
gnu.org

--- Comment #15 from Richard Sandiford  ---
Sure.  SVE doesn't exhibit the ICE as far as I can tell, but a modified
version passes testing on SVE, and seems to fix an XFAIL.  I'll test
more widely overnight and post tomorrow.

[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu

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

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

--- Comment #10 from Jakub Jelinek  ---
With the above commands, r14-4258 ICEs in libcody build, r14-4650 builds ok,
r14-4846, r14-5043, r14-5829 ICE during the PCH libstdc++ compilation, will
continue bisecting that.

[Bug fortran/100651] [11/12/13/14 Regression] Bad handling of optional, allocatable character argument

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

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

--- Comment #14 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #12)
> Created attachment 56690 [details]
> Draft patch

Regtests cleanly btw.

[Bug fortran/100651] [11/12/13/14 Regression] Bad handling of optional, allocatable character argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||10.5.0, 11.4.1, 12.3.1,
   ||13.2.1, 14.0, 7.5.0, 8.5.0,
   ||9.5.0

--- Comment #13 from anlauf at gcc dot gnu.org ---
Updating the known-to-fail versions.

I have doubts that this is a regression.  The dump-tree even of 7.5.0
shows the same problem as the other listed versions.

[Bug fortran/100651] [11/12/13/14 Regression] Bad handling of optional, allocatable character argument

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

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
Created attachment 56690
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56690&action=edit
Draft patch

Very rough patch that fixes this PR and also pr93762.
Need more thorough testing.

[Bug fortran/90608] Inline non-scalar minloc/maxloc calls

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

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

--- Comment #17 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #16)
> This missed the gcc stage 1 deadline, but I'm still working on it.

I always thought that the Fortran FE does not fall under this rule.

Why don't you proceed, and let's discuss later whether your patch is
safe enough for gcc-14?

Or are you touching parts outside of gcc/fortran/ ?

[Bug fortran/111880] [11/12/13/14] False positive warning of obsolescent COMMON block with Fortran submodule

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r14-5859-gc9d029ba2ceb435e31492c1f3f0fd3edf0e386be
Author: Harald Anlauf 
Date:   Thu Nov 23 22:48:38 2023 +0100

Fortran: avoid obsolescence warning for COMMON with submodule [PR111880]

gcc/fortran/ChangeLog:

PR fortran/111880
* resolve.cc (resolve_common_vars): Do not call gfc_add_in_common
for symbols that are USE associated or used in a submodule.

gcc/testsuite/ChangeLog:

PR fortran/111880
* gfortran.dg/pr111880.f90: New test.

[Bug fortran/90608] Inline non-scalar minloc/maxloc calls

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

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #16 from Mikael Morin  ---
This missed the gcc stage 1 deadline, but I'm still working on it.

[Bug lto/112716] LTO optimization with struct of variable ssize

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

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

--- Comment #3 from Sam James  ---
No warning from -Wlto-type-mismatch.

[Bug lto/112716] LTO optimization with struct of variable ssize

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||uecker at gcc dot gnu.org

--- Comment #2 from uecker at gcc dot gnu.org ---
.
Inside the same TU there are different types.  But note that this is across TUs
where the structs with same tag and and compatible members are supposed to be
compatible (they could come from a shared header).  I would assume these rules
hold also for the GNU extension.  In C23 the structs will be compatible also
inside a TU (without GNU extensions, but I I think the same rules should then
also apply to structs with the GNU extension).

[Bug lto/112716] LTO optimization with struct of variable ssize

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||alias

--- Comment #1 from Andrew Pinski  ---
I am 99% sure they are different types and have different aliasing  sets which
case this is undefined.


That is struct foo inside foo and struct foo inside bar are 2 totally different
types and therefor a store to one won't change a store to another.

[Bug lto/112716] New: LTO optimization with struct of variable ssize

[muecker at gwdg dot de via Gcc-bugs]

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

Bug ID: 112716
   Summary: LTO optimization with struct of variable ssize
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: muecker at gwdg dot de
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

The following code using a GNU extension gets miscompiled due to incorrect
aliasing assumptions with -flto and -O2: 

gcc -flto -O2 y.c y2.c  -DT1="int[n]" -DT2="int[n]"
// y.c
void bar(void*);

[[gnu::noinline,gnu::noipa]]
int foo(void *p, void *q)
{
int n = 5;
struct foo { int x; typeof(T1) y; } *p2 = p;
p2->x = 1;
bar(q);
return p2->x;
}

int main()
{
int n = 5;
void *p = __builtin_malloc(sizeof(struct foo { int x; typeof(T1) y;
}));

if (!p)
return 0;

if (2 != foo(p, p))
__builtin_abort();

return 0;
}
// y2
void bar(void* q)
{   
int n = 5;
struct foo { int x; typeof(T2) y; } *q2 = q;
q2->x = 2;
}

[Bug target/112712] Crash when compiling g++ -m68020-60 -O2

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
I can reproduce with a gcc-13.2 cross to m68k-elf w/ c++:

during RTL pass: reload
similar/main/multi.cpp: In function 'void d1x::multi_object_to_object_rw(const
object&, object_rw*)':
similar/main/multi.cpp:6167:1: internal compiler error: in push_reload, at
reload.cc:1124
0x422a9d push_reload(rtx_def*, rtx_def*, rtx_def**, rtx_def**, reg_class,
machine_mode, machine_mode, int, int, int, reload_type)
/mnt/scratch/cross/downloads/gcc-mirror-gcc.git/gcc/reload.cc:1124
0xabcda1 find_reloads(rtx_insn*, int, int, int, short*)
/mnt/scratch/cross/downloads/gcc-mirror-gcc.git/gcc/reload.cc:4049
0xaca6ea calculate_needs_all_insns
/mnt/scratch/cross/downloads/gcc-mirror-gcc.git/gcc/reload1.cc:1469
0xaca6ea reload(rtx_insn*, int)
/mnt/scratch/cross/downloads/gcc-mirror-gcc.git/gcc/reload1.cc:983
0x96f784 do_reload
/mnt/scratch/cross/downloads/gcc-mirror-gcc.git/gcc/ira.cc:5975
0x96f784 execute
/mnt/scratch/cross/downloads/gcc-mirror-gcc.git/gcc/ira.cc:6149

The given test case doesn't compile with older g++ versions so I can't bisect.

[Bug tree-optimization/91029] missed optimization regarding value of modulo operation

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug target/106326] _m and _z version of SVE instrinsics not optimized to predicate-free version

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

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

Richard Sandiford  changed:

   What|Removed |Added

   Assignee|prathamesh3492 at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 CC||rsandifo at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-11-26
 Ever confirmed|0   |1

--- Comment #1 from Richard Sandiford  ---
Agreed with Prathamesh that I'd take this.  Testing a patch.

[Bug target/112599] RISC-V regression testsuite errors with rv64gcv_zvl1024b

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Pan Li :

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

commit r14-5851-gec84a1e7a18f65858a1b129ff80cb32e64cf151b
Author: Juzhe-Zhong 
Date:   Sun Nov 26 17:13:55 2023 +0800

RISC-V: Disable AVL propagation of slidedown instructions

Re-check again RVV ISA, I find that we can't allow AVL propagation not only
for vrgather, but also slidedown instructions.

Committed.

PR target/112599

gcc/ChangeLog:

* config/riscv/riscv-avlprop.cc (avl_can_be_propagated_p): Add
slidedown.
(vlmax_ta_p): Ditto.
(pass_avlprop::get_vlmax_ta_preferred_avl): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/vf_avl-1.c: Adapt test.
* gcc.target/riscv/rvv/autovec/pr112599-3.c: New test.