[Bug tree-optimization/103182] [12 Regression] Recent change causes code correctness regression

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
That commit also causes ice-on-valid for c++ and fortran.

[Bug ipa/103171] [12 Regression] ICE Segmentation fault since r12-2523-g13586172d0b70c9d

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526

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

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

--- Comment #21 from Aldy Hernandez  ---
Should be fixed. Can someone verify the object size on arm is as expected?

[Bug tree-optimization/103182] [12 Regression] Recent change causes code correctness regression

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

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

--- Comment #1 from Andrew Pinski  ---
Note I think the testcase that is failing is gcc.dg/torture/pr45967-2.c (as
pr45962-2.c does not exist).

[Bug tree-optimization/103182] [12 Regression] Recent change causes code correctness regression

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |12.0
 Target||or1k-elf

[Bug tree-optimization/103182] New: [12 Regression] Recent change causes code correctness regression

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

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

Bug ID: 103182
   Summary: [12 Regression] Recent change causes code correctness
regression
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
  Target Milestone: ---

This change:

d70ef65692fced7ab72e0aceeff7407e5a34d96d is the first bad commit
commit d70ef65692fced7ab72e0aceeff7407e5a34d96d
Author: Jan Hubicka 
Date:   Wed Nov 10 13:08:41 2021 +0100

Make EAF flags more regular (and expressive)

I hoped that I am done with EAF flags related changes, but while looking
into
the Fortran testcases I noticed that I have designed them in unnecesarily
restricted way.  I followed the scheme of NOESCAPE and NODIRECTESCAPE which
is
however the only property tht is naturally transitive.

This patch replaces the existing flags by 9 flags:

[ ... ]

Is causing gcc.dg/torture/pr45962-2.c to fail on or1k-elf and a few other
platforms at -O2.

You should be able to reproduce this with just a cross compiler since the
.optimized dump after the change above just calls "foo" then aborts.  The check
for the value of i after the call to foo has been eliminated.

There's a bit of dodgy code in foo() from an aliasing standpoint.  I haven't
looked at it real closely though.

[Bug tree-optimization/103181] [9/10/11/12 Regression] wrong code at -O1 due to conditional division by 0 being executed

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  ---
The problem is in gimple.c:
  return (operation_could_trap_p (op, FLOAT_TYPE_P (t),
  (INTEGRAL_TYPE_P (t)
   && TYPE_OVERFLOW_TRAPS (t)),
  div));


We only check for scalar integer types ...

[Bug tree-optimization/103181] [9/10/11/12 Regression] wrong code at -O1 due to conditional division by 0 being executed

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.5
   Last reconfirmed||2021-11-11
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirm, reassoc1 is converting this into straight line code 

[Bug tree-optimization/103181] [9/10/11/12 Regression] wrong code at -O1 due to conditional division by 0 being executed

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---
Adding -fno-inline causes the failure at -O2 and above.

[Bug tree-optimization/103181] New: [9/10/11/12 Regression] wrong code at -O1 due to conditional division by 0 being executed

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 103181
   Summary: [9/10/11/12 Regression] wrong code at -O1 due to
conditional division by 0 being executed
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

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

Output:
$ x86_64-pc-linux-gnu-gcc testcase.c -O0 && ./a.out
$ x86_64-pc-linux-gnu-gcc testcase.c -O1 && ./a.out 
Floating point exception
$ x86_64-pc-linux-gnu-gcc testcase.c -O2 && ./a.out
$ x86_64-pc-linux-gnu-gcc testcase.c -O3 && ./a.out

The right hand operand of || in
  v += __builtin_bswap16 (s) || (S) (a / ((U){3, 0}));
is executed, even though s != 0 and it may trap.

$ 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-r12-5136-2020203027-gabc2f01914d-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.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
--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-r12-5136-2020203027-gabc2f01914d-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 2020 (experimental) (GCC)

[Bug target/103151] ICE in extract_insn with __m256h and variable vec insert and -O1 -mavx512fp16 -mxop since r12-3407-g9e2a82e1f9d2c4af

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

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

[Bug c/103180] casting char * to any type did not report the warning message

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80593
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
Yes this was changed on purpose in GCC 7.2.0+, See PR 80593.

[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
I'm seeing these failures in my nios2-elf test results today too.  :-(

[Bug c/103180] New: casting char * to any type did not report the warning message

[jie.luo--- via Gcc-bugs]

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

Bug ID: 103180
   Summary: casting char * to any type did not report the warning
message
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jie@compiler-dev.com
  Target Milestone: ---

When using gcc-9.3.0 to compile the test case with -fstrict-aliasing
-Wstrict-aliasing=1,gcc did not report the strict aliasing violation warning
message.
The test case is as follows: 

char aa[100];
int *ptr;
int main()
{
ptr = (int *) aa;
return ptr[0];
}

[Bug target/103151] ICE in extract_insn with __m256h and variable vec insert and -O1 -mavx512fp16 -mxop since r12-3407-g9e2a82e1f9d2c4af

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
Fixed in GCC12.

[Bug target/103151] ICE in extract_insn with __m256h and variable vec insert and -O1 -mavx512fp16 -mxop since r12-3407-g9e2a82e1f9d2c4af

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r12-5141-ge166cada0813f8b382bacb7f01e1d8d235bf3b0f
Author: liuhongt 
Date:   Wed Nov 10 12:53:43 2021 +0800

Extend vpcmov to handle V8HF/V16HFmode under TARGET_XOP.

gcc/ChangeLog:

PR target/103151
* config/i386/sse.md (V_128_256): Extend to V8HF/V16HF.
(avxsizesuffix): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr103151.c: New test.

[Bug c++/58071] Premature instantiation of default argument

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2021-11-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Marek Polacek  ---
Still rejected.

[Bug c++/61850] g++ crashes (SEGV) on the following endless template instantiation

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to fail||6.4.0
 Status|UNCONFIRMED |RESOLVED
   Keywords||ice-on-invalid-code
  Known to work||8.1.0
   Target Milestone|--- |8.0

--- Comment #2 from Andrew Pinski  ---
GCC 8 and above produces:
: In instantiation of 'struct join_impl':
:41:1:   required by substitution of 'template
typename join_impl::type>::type, typename std::remove_cv::type>::type>::type join(V1, V2) [with V1 = int; V2 =
float]'
:52:3:   required from here
:29:36: error: no type named 'type' in 'struct join_impl'
   using type = typename super::type;
^

GCC 7 produces:
: In substitution of 'template struct join_impl::forward>::type> [with T1 = int;
T2 = float]':
:41:1:   recursively required by substitution of 'template struct join_impl::forward>::type> [with T1 = int; T2 = float]'
:41:1:   required by substitution of 'template
typename join_impl::type>::type, typename std::remove_cv::type>::type>::type join(V1, V2) [with V1 = int; V2
= float]'
:52:3:   required from here
:41:1: fatal error: template instantiation depth exceeds maximum of 900
(use -ftemplate-depth= to increase the maximum)
 join(V1 v1, V2 v2)
 ^~~~

So fixed for GCC 8.

[Bug c++/61850] g++ crashes (SEGV) on the following endless template instantiation

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

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

--- Comment #1 from Andrew Pinski  ---
I don't think this is valid code.

[Bug middle-end/101955] (signed<<

[navidrahimi at microsoft dot com via Gcc-bugs]

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

navidrahimi  changed:

   What|Removed |Added

 CC||navidrahimi at microsoft dot 
com

--- Comment #5 from navidrahimi  ---
I think rather than just 

int f(int b)
{
return (((b)<<31)>>31);
}

We should optimize long too:
int f(int b)
{
return (((b)<<63)>>63);
}


1) https://compiler-explorer.com/z/dnrr54v4r

[Bug c++/51304] gcc segfaults for large -ftemplate-depth values (if depth is reached)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Andrew Pinski  ---
ICC Produces:
(3): internal error: bad pointer
static unsigned long long const result =
Ackermann<(m-1),Ackermann::result>::result;
  ^


There is not much to fix here. The limit is there to give a reasonable limit so
you don't run into problems like this.

[Bug c++/103177] incorrect error message for ambiguous lookup with a static member function from a private base

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|incorrect error message for |incorrect error message for
   |ambiguous lookup|ambiguous lookup with a
   ||static member function from
   ||a private base

--- Comment #1 from Andrew Pinski  ---
So if I remove static from B::foo, the inaccessible error message is gone.

[Bug testsuite/103179] [12 regression] Excess errors in gfortran.dg/do_subscript_3.f90 after r12-5126

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|other   |testsuite
   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Novembe
   ||r/584015.html

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584015.html

[Bug tree-optimization/103175] [12 Regression] internal compiler error: in handle_call_arg, at tree-ssa-structalias.c:4139

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

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

[Bug tree-optimization/103178] [12 regression] several test case ICEs after r12-5113

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 103175.

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

[Bug other/103179] New: [12 regression] Excess errors in gfortran.dg/do_subscript_3.f90 after r12-5126

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

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

Bug ID: 103179
   Summary: [12 regression] Excess errors in
gfortran.dg/do_subscript_3.f90 after r12-5126
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:992644c3511acd58248db784f1ac43e2f053ebcc, r12-5126
make  -k check-gcc-fortran RUNTESTFLAGS="dg.exp=gfortran.dg/do_subscript_3.f90"
FAIL: gfortran.dg/do_subscript_3.f90   -O  (test for excess errors)
# of expected passes4
# of unexpected failures1


Excess errors:
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/do_subscript_3.f90:19:50:
Warning: iteration 5 invokes undefined behavior
[-Waggressive-loop-optimizations]

[Bug tree-optimization/103178] New: [12 regression] several test case ICEs after r12-5113

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

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

Bug ID: 103178
   Summary: [12 regression] several test case ICEs after r12-5113
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:d70ef65692fced7ab72e0aceeff7407e5a34d96d, r12-5113

FAIL: 18_support/nested_exception/rethrow_if_nested.cc (test for excess errors)
FAIL: 20_util/variant/exception_safety.cc (test for excess errors)
FAIL: 20_util/variant/run.cc (test for excess errors)
FAIL: gfortran.dg/inline_matmul_17.f90   -O   scan-tree-dump-times optimized
"matmul_r4" 2
FAIL: std/ranges/adaptors/join.cc (test for excess errors)

/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/18_support/nested_exception/rethrow_if_nested.cc:
In function 'void test04()':^M
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/18_support/nested_exception/rethrow_if_nested.cc:129:
internal compiler error: in handle_call_arg, at tree-ssa-structalias.c:4139^M
0x112b8e8b handle_call_arg^M
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-structalias.c:4139^M
0x112b92ff handle_rhs_call^M
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-structalias.c:4335^M
0x112bba93 find_func_aliases_for_call^M
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-structalias.c:5009^M
0x112bba93 find_func_aliases^M
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-structalias.c:5112^M
0x112bea4b compute_points_to_sets^M
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-structalias.c:7528^M
0x112bea4b compute_may_aliases()^M
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-structalias.c:8036^M
0x10e609e3 execute_function_todo^M
/home/seurer/gcc/git/gcc-test/gcc/passes.c:2014^M
0x10e61d8b do_per_function^M
/home/seurer/gcc/git/gcc-test/gcc/passes.c:1687^M
0x10e61fab execute_todo^M
/home/seurer/gcc/git/gcc-test/gcc/passes.c:2096^M

[Bug c++/54367] [meta-bug] lambda expressions

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

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

Bug 80587 Summary: Incorrect type from outer scope inside lambda under some 
conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80587

   What|Removed |Added

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

[Bug c++/80587] Incorrect type from outer scope inside lambda under some conditions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81045
   Target Milestone|--- |7.2
 Resolution|--- |FIXED

--- Comment #2 from Andrew Pinski  ---
Fixed in GCC 7.2.0+ and GCC 8+.
I suspect the fix for PR 81045 which fixed this one.

[Bug tree-optimization/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526

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

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

--- Comment #20 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

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

commit r12-5138-ge82c382971664d6fd138cc36020db4b1a91885c6
Author: Aldy Hernandez 
Date:   Wed Nov 10 13:21:59 2021 +0100

Allow loop header copying when first iteration condition is known.

As discussed in the PR, the loop header copying pass avoids doing so
when optimizing for size.  However, sometimes we can determine the
loop entry conditional statically for the first iteration of the loop.

This patch uses the path solver to determine the outgoing edge
out of preheader->header->xx.  If so, it allows header copying.  Doing
this in the loop optimizer saves us from doing gymnastics in the
threader which doesn't have the context to determine if a loop
transformation is profitable.

I am only returning true in entry_loop_condition_is_static for
a true conditional.  Technically a false conditional is also
provably static, but allowing any boolean value causes a regression
in gfortran.dg/vector_subscript_1.f90.

I would have preferred not passing around the query object, but the
layout of pass_ch and should_duplicate_loop_header_p make it a bit
awkward to get it right without an outright refactor to the
pass.

Tested on x86-64 Linux.

gcc/ChangeLog:

PR tree-optimization/102906
* tree-ssa-loop-ch.c (entry_loop_condition_is_static): New.
(should_duplicate_loop_header_p): Call
entry_loop_condition_is_static.
(class ch_base): Add m_ranger and m_query.
(ch_base::copy_headers): Pass m_query to
entry_loop_condition_is_static.
(pass_ch::execute): Allocate and deallocate m_ranger and
m_query.
(pass_ch_vect::execute): Same.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr102906.c: New test.

[Bug target/103170] [12 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%s'

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed, thanks for the report.

[Bug target/103170] [12 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%s'

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

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

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

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

commit r12-5137-gc744ae0897957def0cd798399ef8ed6dc0d23811
Author: Andrew Pinski 
Date:   Wed Nov 10 18:37:22 2021 +

[COMMITTED] aarch64: [PR103170] Fix aarch64_simd_dup

The problem here is aarch64_simd_dup use
the vw iterator rather than vwcore iterator.  This causes
problems for the V4SF and V2DF modes. I changed both of
aarch64_simd_dup patterns to be consistent.

Committed as obvious after a bootstrap/test on aarch64-linux-gnu.

PR target/103170

gcc/ChangeLog:

* config/aarch64/aarch64-simd.md (aarch64_simd_dup):
Use vwcore iterator for the r constraint output string.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/vector-dup-1.c: New test.

[Bug libgcc/103004] [12 regression] r12-4416 breaks backtrace on PPC64 Big-endian

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

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

--- Comment #4 from Raphael M Zinsly  ---
On a system with an old toolchain I'm seeing (In reply to Jakub Jelinek from
comment #3)
> I think the warning should be fixed with following, just need to test it:
> 
> --- libgcc/config/rs6000/linux-unwind.h.jj2021-10-15 11:59:16.227682621
> +0200
> +++ libgcc/config/rs6000/linux-unwind.h   2021-11-09 11:42:06.840353422 
> +0100
> @@ -395,7 +395,8 @@ struct frame_layout
>  };
>  
>  
> -void ppc_backchain_fallback (struct _Unwind_Context *context, void *a)
> +static void
> +ppc_backchain_fallback (struct _Unwind_Context *context, void *a)
>  {
>struct frame_layout *current;
>struct trace_arg *arg = a;

That works, I included in the proposed patch
(https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584043.html), thanks!

[Bug tree-optimization/92879] [10/11 Regression] incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization

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

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

--- Comment #12 from Martin Sebor  ---
The test fails everywhere.  It regressed with r12-5107 (see pr102690).  The
solution was to xfail it (to your point in pr101674).

[Bug tree-optimization/103175] [12 Regression] internal compiler error: in handle_call_arg, at tree-ssa-structalias.c:4139

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

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

--- Comment #2 from Jonathan Wakely  ---
FAIL: 18_support/nested_exception/rethrow_if_nested.cc (test for excess errors)
FAIL: 20_util/variant/exception_safety.cc (test for excess errors)
FAIL: 20_util/variant/run.cc (test for excess errors)
FAIL: std/ranges/adaptors/join.cc (test for excess errors)

[Bug fortran/99036] [11/12 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699

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

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

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #5)
> Another try with a case that is probably/hopefully related.
> The following example with a module and submodule in different files
> is valid for e.g. -std=f2008, but invalid for -std=f2003 or -std=f95 :
> 

Patch posted in comment #1 allows this case to compile.

[Bug fortran/101919] Inconsistent -Wstringop-overread warning with -flto

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> This fixes comment#2:

but "regresses" on gfortran.dg/transfer_intrinsic_1.f90 due to an additional
MIN_EXPR.

I haven't found the spot yet that needs to be addressed for comment#0.

[Bug tree-optimization/92879] [10/11 Regression] incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #11 from sandra at gcc dot gnu.org ---
The new testcase is failing on nios2-elf.

$ nios2-elf-g++  src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C
-O2 -fdump-tree-optimized -S -Wall
In constructor 'S::S(int)',
inlined from 'void __static_initialization_and_destruction_0(int, int)' at
src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C:26:7,
inlined from '(static initializers for
src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C)' at
src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C:26:8:
src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C:22:7: warning:
array subscript [0, 536870911] is outside array bounds of 'void [0]'
[-Warray-bounds]
   22 |   new (p + i) int ();
  |   ^~
src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C:19:51: note:
object of size 0 allocated by 'operator new []'
   19 | p = (int*) new unsigned char [sizeof (int) * m];
  |   ^


This is what I see in the .optimized dump file:

;; Function _GLOBAL__sub_I_a (_GLOBAL__sub_I_a, funcdef_no=5, decl_uid=1975,
cgraph_uid=6, symbol_order=6) (executed once)

Removing basic block 5
void _GLOBAL__sub_I_a ()
{
  int _2;
  void * _5;
  sizetype _12;
  sizetype _20;

   [local count: 1073741824]:
  a ={v} {CLOBBER};
  a.m = 0;
  _5 = operator new [] (0);
  a.p = _5;
  _2 = a.m;
  if (_2 > 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 955630224]:
  _20 = (sizetype) _2;
  _12 = _20 * 4;
  __builtin_memset (_5, 0, _12); [tail call]

   [local count: 1073741825]:
  return;

}

[Bug fortran/101919] Inconsistent -Wstringop-overread warning with -flto

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
This fixes comment#2:

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index e7aec3845d3..f7e2a0dba57 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -8102,10 +8102,12 @@ gfc_trans_string_copy (stmtblock_t * block, tree
dlength, tree dest,
   tmp3 = gfc_finish_block (&tempblock);

   /* The truncated memmove if the slen >= dlen.  */
+  tmp2 = fold_build2_loc (input_location, MIN_EXPR,
+ TREE_TYPE (slen), slen, dlen);
   tmp2 = build_call_expr_loc (input_location,
  builtin_decl_explicit (BUILT_IN_MEMMOVE),
  3, dest, src,
- fold_convert (size_type_node, dlen));
+ fold_convert (size_type_node, tmp2));

   /* The whole copy_string function is there.  */
   tmp = fold_build3_loc (input_location, COND_EXPR, void_type_node, cond2,

[Bug tree-optimization/96779] Failure to optimize comparison of negative version of self

[navidrahimi at microsoft dot com via Gcc-bugs]

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

--- Comment #5 from navidrahimi  ---
And this is the behavior of different compilers for this optimization:

https://compiler-explorer.com/z/ahdEzxxTv

[Bug tree-optimization/96779] Failure to optimize comparison of negative version of self

[navidrahimi at microsoft dot com via Gcc-bugs]

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

navidrahimi  changed:

   What|Removed |Added

 CC||navidrahimi at microsoft dot 
com

--- Comment #4 from navidrahimi  ---
Hi Andrew,

I just used your code and added a check to check whether the type is wrapping
type:


(for cmp (eq ne)
 (simplify
  (cmp:c @0 (negate @0))
   (if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))
&& !TYPE_OVERFLOW_WRAPS (type))
(cmp:c @0 { build_zero_cst (TREE_TYPE(@0)); })

This should work.

[Bug fortran/103137] [12 Regression] ICE in gfc_simplify_transpose, at fortran/simplify.c:8181 since r12-4967-gbcf3728abe848888

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r12-5136-gabc2f01914d6c4703de26c402fb579a9a2d0dba4
Author: Harald Anlauf 
Date:   Wed Nov 10 20:30:27 2021 +0100

Fortran: avoid NULL pointer dereferences

CLASS(), PARAMETER is not yet properly implemented in gfortran.  Using it
in declarations could lead to subsequent NULL pointer dereferences during
checking or simplification of expressions involving those CLASS variables.

gcc/fortran/ChangeLog:

PR fortran/103137
PR fortran/103138
* check.c (gfc_check_shape): Avoid NULL pointer dereference on
missing ref.
* simplify.c (gfc_simplify_cshift): Avoid NULL pointer dereference
when shape not set.
(gfc_simplify_transpose): Likewise.

[Bug fortran/103138] [12 Regression] ICE in gfc_simplify_cshift, at fortran/simplify.c:2139 since r12-4967-gbcf3728abe848888

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r12-5136-gabc2f01914d6c4703de26c402fb579a9a2d0dba4
Author: Harald Anlauf 
Date:   Wed Nov 10 20:30:27 2021 +0100

Fortran: avoid NULL pointer dereferences

CLASS(), PARAMETER is not yet properly implemented in gfortran.  Using it
in declarations could lead to subsequent NULL pointer dereferences during
checking or simplification of expressions involving those CLASS variables.

gcc/fortran/ChangeLog:

PR fortran/103137
PR fortran/103138
* check.c (gfc_check_shape): Avoid NULL pointer dereference on
missing ref.
* simplify.c (gfc_simplify_cshift): Avoid NULL pointer dereference
when shape not set.
(gfc_simplify_transpose): Likewise.

[Bug c++/103177] incorrect error message for ambiguous lookup

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-10

[Bug tree-optimization/102892] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r12-5135-gb83705b477858ba683b99fa61ff9ff83bc5be265
Author: H.J. Lu 
Date:   Wed Nov 10 11:24:44 2021 -0800

Add a testcase for PR tree-optimization/102892

PR tree-optimization/102892 is fixed by

commit 4b3a325f07acebf47e82de227ce1d5ba62f5bcae
Author: Aldy Hernandez 
Date:   Thu Oct 28 15:35:21 2021 +0200

Remove VRP threader passes in exchange for better threading pre-VRP.

PR tree-optimization/102892
* gcc.dg/pr102892-1.c: New file.
* gcc.dg/pr102892-2.c: Likewise.

[Bug tree-optimization/103173] strncpy output may be truncated copying 32 bytes from a string of length 1439 (bogus) [-Werror=stringop-truncation]

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-10
   Keywords||diagnostic
 Blocks||88781

--- Comment #1 from Martin Sebor  ---
Confirmed.  The warning here is the result of the limits of the representation
GCC uses for the source argument.  The warning sees the following IL:

  strncpy (&dest, &MEM  [(void *)&data], 32);

and uses the size of data as the upper bound on the length of the string stored
in it.  That obviously doesn't correspond to the source code which is more
closely represented by this IL:

  j = 0;
  _1 = &data[j].name;
  strncpy (&dest, _1, 32);

But as the IL changes from the original representation above to the &MEM thing
to make it easier for optimizers to work with, it loses that important detail
and causes the false positive.

The "fix" is to either try to undo the IL change and reconstruct the original
(which is never going to be perfect) or to run the warnings on the IL before it
loses the important detail.  The latter will mean that the warning will not
benefit from some of the optimizing transformations that depend on the MEM
representation.  All solutions involve trade-offs between false positives and
false negatives.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781
[Bug 88781] [meta-bug] bogus/missing -Wstringop-truncation warnings

[Bug c++/103177] New: incorrect error message for ambiguous lookup

[jens.maurer at gmx dot net via Gcc-bugs]

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

Bug ID: 103177
   Summary: incorrect error message for ambiguous lookup
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.maurer at gmx dot net
  Target Milestone: ---

This is clearly a case of ambiguous lookup:

struct B {
   static int foo(int);
};

struct B2 {
   int foo();
};

struct D : private B, public B2 {
};

void f()
{
   D d;
   d.foo();
}

Yet, gcc complains about an inaccessible member. (Note that access is checked
at the end of overload resolution, but we should never get to that point.)

g++ -Wfatal-errors x.cc

x.cc: In function ‘void f()’:
x.cc:18:5: error: ‘static int B::foo(int)’ is inaccessible within this 
context
18 |   d.foo();
   | ^~~
compilation terminated due to -Wfatal-errors.

[Bug tree-optimization/103176] -foptimize-strlen causes stringop-overflow warning

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2021-11-10
 Ever confirmed|0   |1
 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
Historically, flow-dependent warnings in GCC have relied on optimization.  Some
work without it and just yield better results with it (e.g., -Wuninitialized),
others require it and won't do anything otherwise (e.g., -Warray-bounds).  This
is starting to change so that more warnings are useful even without
optimization, but only slowly, and to a limited extent (e.g., to see across
function call boundaries requires inlining and likely will for the foreseeable
future).  Some warnings like -Wstringop-overflow are a hybrid: some instances
are issued only during the strlen optimization, others at other times.  None of
these warnings are free of false positives (in fact, none ever are).  Some are
unavoidable due to limits inherent in computing, some due to design trade-offs,
others are incidental (i.e., bugs).  To tell where the instances in comment #0
fall we ask for a test case, or at least the translation unit, so that we can
easily reproduce and analyze them (see https://gcc.gnu.org/bugs/).  I set the
status to WAITING until you have provided one.

[Bug tree-optimization/103176] -foptimize-strlen causes stringop-overflow warning

[josiah_vanderzee at mediacombb dot net via Gcc-bugs]

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

Josiah VanderZee  changed:

   What|Removed |Added

URL||https://github.com/minetest
   ||/irrlicht

--- Comment #1 from Josiah VanderZee  
---
Correction: the note should say flattenFilename(), not flattenFilepath

[Bug target/103170] [12 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%s'

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 51761
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51761&action=edit
Patch which I will be committing

Patch which I will be committing once I finish testing it.

[Bug tree-optimization/103176] New: -foptimize-strlen causes stringop-overflow warning

[josiah_vanderzee at mediacombb dot net via Gcc-bugs]

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

Bug ID: 103176
   Summary: -foptimize-strlen causes stringop-overflow warning
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: josiah_vanderzee at mediacombb dot net
  Target Milestone: ---

The following warning appears while compiling
https://github.com/minetest/irrlicht with at least -O2. Compiling with
-fno-optimize-strlen makes the warning disappear. Diffing a binary compiled
with the optimization and one compiled without show that there is no difference
in the generated code.The relevant functions are inlined (and I verified this
by hand) so all of it is present in the binary. The warning follows.

I have considered the view that the warning is desirable; the code is very
dangerous; and I am not claiming that the warning is incorrect. The problem
here is that for some reason the warning only occurs when strlen optimizations
are enabled. This doesn't seem logical to me.

NOTE: The binaries I diffed were generated by compiling the flattenFilepath()
function as a unit test.

[49/99] ccache /usr/bin/c++ -DIRRLICHT_EXPORTS -D_IRR_STATIC_LIB_ -I../include
-I../source/Irrlicht -O3 -fPIC -Wall -pipe -fno-exceptions -fno-rtti
-std=gnu++11 -MD -MT source/Irrlicht/CMakeFiles/IRRIOOBJ.dir/CFileSystem.cpp.o
-MF source/Irrlicht/CMakeFiles/IRRIOOBJ.dir/CFileSystem.cpp.o.d -o
source/Irrlicht/CMakeFiles/IRRIOOBJ.dir/CFileSystem.cpp.o -c
../source/Irrlicht/CFileSystem.cpp
In file included from ../include/coreutil.h:8,
 from ../include/IReadFile.h:9,
 from ../include/IFileArchive.h:8,
 from ../include/IFileSystem.h:9,
 from ../source/Irrlicht/CFileSystem.h:8,
 from ../source/Irrlicht/CFileSystem.cpp:7:
In member function ‘irr::core::string irr::core::string::subString(irr::u32, irr::s32, bool) const [with T = char; TAlloc =
irr::core::irrAllocator]’,
inlined from ‘virtual irr::io::path&
irr::io::CFileSystem::flattenFilename(irr::io::path&, const path&) const’ at
../source/Irrlicht/CFileSystem.cpp:679:58:
../include/irrString.h:937:19: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
  937 |   o.array[length] = 0;
  |   ^~~
In file included from ../include/irrString.h:9,
 from ../include/coreutil.h:8,
 from ../include/IReadFile.h:9,
 from ../include/IFileArchive.h:8,
 from ../include/IFileSystem.h:9,
 from ../source/Irrlicht/CFileSystem.h:8,
 from ../source/Irrlicht/CFileSystem.cpp:7:
../include/irrAllocator.h: In member function ‘virtual irr::io::path&
irr::io::CFileSystem::flattenFilename(irr::io::path&, const path&) const’:
../include/irrAllocator.h:60:22: note: at offset [1, -1] to an object with size
1 allocated by ‘operator new’ here
   60 |   return operator new(cnt);
  |  ^
In file included from ../include/coreutil.h:8,
 from ../include/IReadFile.h:9,
 from ../include/IFileArchive.h:8,
 from ../include/IFileSystem.h:9,
 from ../source/Irrlicht/CFileSystem.h:8,
 from ../source/Irrlicht/CFileSystem.cpp:7:
In member function ‘irr::core::string irr::core::string::subString(irr::u32, irr::s32, bool) const [with T = char; TAlloc =
irr::core::irrAllocator]’,
inlined from ‘virtual irr::io::path
irr::io::CFileSystem::getFileBasename(const path&, bool) const’ at
../source/Irrlicht/CFileSystem.cpp:655:73:
../include/irrString.h:937:19: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
  937 |   o.array[length] = 0;
  |   ^~~
In file included from ../include/irrString.h:9,
 from ../include/coreutil.h:8,
 from ../include/IReadFile.h:9,
 from ../include/IFileArchive.h:8,
 from ../include/IFileSystem.h:9,
 from ../source/Irrlicht/CFileSystem.h:8,
 from ../source/Irrlicht/CFileSystem.cpp:7:
../include/irrAllocator.h: In member function ‘virtual irr::io::path
irr::io::CFileSystem::getFileBasename(const path&, bool) const’:
../include/irrAllocator.h:60:22: note: at offset [1, -1] to an object with size
1 allocated by ‘operator new’ here
   60 |   return operator new(cnt);
  |  ^
In file included from ../include/coreutil.h:8,
 from ../include/IReadFile.h:9,
 from ../include/IFileArchive.h:8,
 from ../include/IFileSystem.h:9,
 from ../source/Irrlicht/CFileSystem.h:8,
 from ../source/Irrlicht/CFileSystem.cpp:7:
In member function ‘irr::core::string irr::core::string::subString(irr::u32, irr::s32, bool) co

[Bug testsuite/103161] [12 Regression] Better ranges cause builtin-sprintf-warn-16.c failure

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Sebor  ---
Fixed.

[Bug testsuite/103161] [12 Regression] Better ranges cause builtin-sprintf-warn-16.c failure

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

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

commit r12-5134-g7c8a416da86c175bcb5fa7b49abf3cf343bc068f
Author: Martin Sebor 
Date:   Wed Nov 10 11:36:16 2021 -0700

Adjust test to avoid target-specific failures [PR103161].

Resolves:
PR testsuite/103161 - Better ranges cause builtin-sprintf-warn-16.c failure

gcc/testsuite:
PR testsuite/103161
* gcc.dg/tree-ssa/builtin-sprintf-warn-16.c: Avoid relying on
argument evaluation order.  Cast width and precision to signed
to avoid undefined behavior.

[Bug fortran/103174] ICE in gfc_match_varspec, at fortran/primary.c:2154

[gscfq--- via Gcc-bugs]

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

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

spartan :

module m
   interface
  module function f()
 class(*), allocatable :: f
  end
   end interface
end
submodule(m) m2
contains
   module function f()
  class(*), allocatable :: f
   end
end

[Bug tree-optimization/103175] [12 Regression] internal compiler error: in handle_call_arg, at tree-ssa-structalias.c:4139

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|internal compiler error: in |[12 Regression] internal
   |handle_call_arg, at |compiler error: in
   |tree-ssa-structalias.c:4139 |handle_call_arg, at
   ||tree-ssa-structalias.c:4139
  Known to work||11.2.1
  Build|powerpc64le-unknown-linux-g |
   |nu  |
  Known to fail||12.0
 Target|powerpc64le-unknown-linux-g |
   |nu  |
   Host|powerpc64le-unknown-linux-g |
   |nu  |
 CC||hubicka at gcc dot gnu.org
   Last reconfirmed||2021-11-10
   Target Milestone|--- |12.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
Affects at least powerpc64le-unknown-linux-gnu and x86_64-pc-linux-gnu

Started with g:d70ef65692fced7ab72e0aceeff7407e5a34d96d
"Make EAF flags more regular (and expressive)"

[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #6 from sandra at gcc dot gnu.org ---
Also fails for nios2 (line 20, same as powerpc64).  Are we really just xfailing
this everywhere instead of fixing the bug and/or testcase?  That kind of seems
like sweeping the whole mess under the rug, to me.  :-S

[Bug tree-optimization/103175] New: internal compiler error: in handle_call_arg, at tree-ssa-structalias.c:4139

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

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

Bug ID: 103175
   Summary: internal compiler error: in handle_call_arg, at
tree-ssa-structalias.c:4139
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
 Build: powerpc64le-unknown-linux-gnu

Several libstdc++ tests are failing on trunk with this ICE:

during GIMPLE pass: ealias
/home/test/src/gcc/libstdc++-v3/testsuite/std/ranges/adaptors/join.cc:223:
internal compiler error: in handle_call_arg, at tree-ssa-structalias.c:4139
0x11273dfb handle_call_arg
/home/test/src/gcc/gcc/tree-ssa-structalias.c:4139
0x11274bdb handle_rhs_call
/home/test/src/gcc/gcc/tree-ssa-structalias.c:4335
0x112787fb find_func_aliases_for_call
/home/test/src/gcc/gcc/tree-ssa-structalias.c:5009
0x112787fb find_func_aliases
/home/test/src/gcc/gcc/tree-ssa-structalias.c:5112
0x1127aa8b compute_points_to_sets
/home/test/src/gcc/gcc/tree-ssa-structalias.c:7528
0x1127aa8b compute_may_aliases()
/home/test/src/gcc/gcc/tree-ssa-structalias.c:8036
0x10e27d03 execute_function_todo
/home/test/src/gcc/gcc/passes.c:2014
0x10e289db do_per_function
/home/test/src/gcc/gcc/passes.c:1687
0x10e28c47 execute_todo
/home/test/src/gcc/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/103174] New: ICE in gfc_match_varspec, at fortran/primary.c:2154

[gscfq--- via Gcc-bugs]

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

Bug ID: 103174
   Summary: ICE in gfc_match_varspec, at fortran/primary.c:2154
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r6 (valid, in contrast to pr95710) :
(line f = 'abc' is not neccessary to create an ICE)


$ cat z1.f90
module m
   interface
  module function f(x)
 integer, intent(in) :: x
 class(*), allocatable :: f
  end
   end interface
end
submodule(m) m2
contains
   module function f(x)
  integer, intent(in) :: x
  class(*), allocatable :: f
  f = 'abc'
   end
end


$ gfortran-12-20211107 -c z1.f90
f951: internal compiler error: Segmentation fault
0xd4f7bf crash_signal
../../gcc/toplev.c:322
0x7fc775 gfc_match_varspec(gfc_expr*, int, bool, bool)
../../gcc/fortran/primary.c:2154
0x7fd502 match_variable
../../gcc/fortran/primary.c:4141
0x7c6726 gfc_match(char const*, ...)
../../gcc/fortran/match.c:1137
0x7c7fed gfc_match_assignment()
../../gcc/fortran/match.c:1315
0x7f1210 match_word
../../gcc/fortran/parse.c:67
0x7f1210 decode_statement
../../gcc/fortran/parse.c:363
0x7f2d0a next_free
../../gcc/fortran/parse.c:1388
0x7f2d0a next_statement
../../gcc/fortran/parse.c:1620
0x7f442b parse_spec
../../gcc/fortran/parse.c:4159
0x7f779c parse_progunit
../../gcc/fortran/parse.c:6170
0x7f7b81 parse_contained
../../gcc/fortran/parse.c:6071
0x7f8597 parse_module
../../gcc/fortran/parse.c:6444
0x7f88c7 gfc_parse_file()
../../gcc/fortran/parse.c:6751
0x845d3f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug target/103170] [12 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%s'

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

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

--- Comment #3 from Andrew Pinski  ---
The problem was caused by r12-4828 which added that alternative.

[Bug fortran/99036] [11/12 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699

[gscfq--- via Gcc-bugs]

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

--- Comment #5 from G. Steinmetz  ---

Another try with a case that is probably/hopefully related.
The following example with a module and submodule in different files
is valid for e.g. -std=f2008, but invalid for -std=f2003 or -std=f95 :


$ cat z2.f90
module m
   interface
  module logical function f(x)
 character(*), intent(in) :: x
  end
   end interface
end


$ cat z3.f90
submodule(m) m2
contains
   module procedure f
  inquire (file=x, exist=f)
   end procedure
end


$ gfortran-12-20211107 -c z2.f90 z3.f90
$
$ gfortran-12-20211107 -c z2.f90 z3.f90 -std=f2003
z2.f90:3:14:

3 |   module logical function f(x)
  |  1
Error: Fortran 2008: MODULE prefix at (1)
z2.f90:4:38:

4 |  character(*), intent(in) :: x
  |  1
Error: Unexpected data declaration statement in INTERFACE block at (1)
z2.f90:5:9:

5 |   end
  | 1
Error: END INTERFACE statement expected at (1)
z3.f90:1:10:

1 | submodule(m) m2
  |  1
Error: Fortran 2008: SUBMODULE declaration at (1)
f951: internal compiler error: in gfc_current_interface_head, at
fortran/interface.c:4842
0x7e9464 gfc_current_interface_head()
../../gcc/fortran/interface.c:4842
0x7c4385 gfc_match_modproc()
../../gcc/fortran/decl.c:9978
0x82d421 match_word
../../gcc/fortran/parse.c:67
0x832630 decode_statement
../../gcc/fortran/parse.c:524
0x83317a next_free
../../gcc/fortran/parse.c:1388
0x83317a next_statement
../../gcc/fortran/parse.c:1620
0x837f6c parse_contained
../../gcc/fortran/parse.c:6017
0x837e96 parse_progunit
../../gcc/fortran/parse.c:6242
0x838c4c gfc_parse_file()
../../gcc/fortran/parse.c:6763
0x886d7f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug target/103170] [12 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%s'

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE: output_operand:|[12 Regression] ICE:
   |incompatible floating point |output_operand:
   |/ vector register operand   |incompatible floating point
   |for '%s'|/ vector register operand
   ||for '%s'
   Target Milestone|--- |12.0

--- Comment #2 from Andrew Pinski  ---
Here is a GNU C testcase which shows the error:
#define vector __attribute__((vector_size(4*sizeof(float

typedef vector float v4sf;

v4sf f(int t)
{
  float tt = *(float*)&t;
  float t1 = tt;
  asm("":"+r"(t1));
  return (v4sf){t1,t1,t1,t1};
}

And it shows it is a regression from GCC 11 too.

Also vwcore fixes the issue.

[Bug tree-optimization/93150] (A&N) == CST1 &( ((A&M)==CST2) | ((A&O)==CST3) ) is not simplified

[navidrahimi at microsoft dot com via Gcc-bugs]

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

navidrahimi  changed:

   What|Removed |Added

 CC||navidrahimi at microsoft dot 
com

--- Comment #1 from navidrahimi  ---
I was just checking this bug and I don't see how this can be a win though: 

Expression: (x&N) == CST1 & ( ((x&M)==CST2) | ((x&O)==CST3))
Number of operations: 
&:4
|:1
==:3

Expression: ((x&(N|M)) == (CST1|CST2)) | ((x&(N|O)==(CST1|CST3))
Number of operations: 
&:2
|:5
==:2

P.S. I might be missing something here though.

[Bug fortran/98203] [11/12 Regression] ICE in gfc_trans_omp_do, at fortran/trans-openmp.c:4665 since r11-349-gf884bef21cccc05d

[gscfq--- via Gcc-bugs]

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

--- Comment #6 from G. Steinmetz  ---

This variant started between 20210808 (error) and 20210822 (ICE) :

$ cat z2.f90
program p
   integer :: i, j
   !$omp parallel masked taskloop simd collapse(2)
   do j = 1, 4
  do i = 1, 4, 2
  end do
   end do
end

[Bug fortran/95710] ICE in gfc_type_is_extensible, at fortran/resolve.c:8848

[gscfq--- via Gcc-bugs]

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

--- Comment #3 from G. Steinmetz  ---

A few more related test files :


$ cat zz1.f90
module m
   interface
  module subroutine s
  end
   end interface
end
submodule(m) m2
contains
   subroutine s
  class(*), allocatable :: x
  class(*), allocatable :: x
   end
end


$ cat zz2.f90
module m
   interface
  module function s()
  end
   end interface
end
submodule(m) m2
contains
   function s()
  class(*), allocatable :: x
  class(*), allocatable :: x
   end
end


$ cat zz3.f90
program p
   interface
  module function s()
 class(*), allocatable :: s
 class(*), allocatable :: s
  end
   end interface
end


$ gfortran-12-20211107 -c zz3.f90
f951: internal compiler error: Segmentation fault
0xd4f7bf crash_signal
../../gcc/toplev.c:322
0x811d2e resolve_symbol
../../gcc/fortran/resolve.c:15582
0x830df2 do_traverse_symtree
../../gcc/fortran/symbol.c:4172
0x815254 resolve_types
../../gcc/fortran/resolve.c:17453
0x81081c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17568
0x7f8ae4 resolve_all_program_units
../../gcc/fortran/parse.c:6564
0x7f8ae4 gfc_parse_file()
../../gcc/fortran/parse.c:6820
0x845d3f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug testsuite/103161] [12 Regression] Better ranges cause builtin-sprintf-warn-16.c failure

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

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

--- Comment #9 from Martin Sebor  ---
Aaah, never mind.  The test depends on the unspecified order of argument
evaluation.  Doh!

[Bug testsuite/103161] [12 Regression] Better ranges cause builtin-sprintf-warn-16.c failure

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

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

--- Comment #8 from Aldy Hernandez  ---
https://en.cppreference.com/w/cpp/language/eval_order

[Bug target/103170] ICE: output_operand: incompatible floating point / vector register operand for '%s'

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-11-10
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
(insn 312 277 365 (set (reg:V4SF 32 v0 [179])
(vec_duplicate:V4SF (reg:SF 4 x4 [185]))) 1129 {aarch64_simd_dupv4sf}
 (nil))


#7  0x00a583e4 in output_asm_insn (templ=0x1f1f7f0 "dup\t%0.4s, %s1",
operands=0x24f6760 ) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/final.c:3570


(define_insn "aarch64_simd_dup"
  [(set (match_operand:VDQF_F16 0 "register_operand" "=w,w")
(vec_duplicate:VDQF_F16
  (match_operand: 1 "register_operand" "w,r")))]
  "TARGET_SIMD"
  "@
   dup\\t%0., %1.[0]
   dup\\t%0., %1"
  [(set_attr "type" "neon_dup, neon_from_gp")]

;; Define corresponding core/FP element mode for each vector mode.
(define_mode_attr vw [(V8QI "w") (V16QI "w")
  (V4HI "w") (V8HI "w")
  (V2SI "w") (V4SI "w")
  (DI   "x") (V2DI "x")
  (V2SF "s") (V4SF "s")
  (V2DF "d")])

Confirmed. This is definitely a target issue. The asm template is wrong, it
should be vwcore instead.

;; Corresponding core element mode for each vector mode.  This is a
;; variation on  mapping FP modes to GP regs.
(define_mode_attr vwcore [(V8QI "w") (V16QI "w")
  (V4HI "w") (V8HI "w")
  (V2SI "w") (V4SI "w")
  (DI   "x") (V2DI "x")
  (V4HF "w") (V8HF "w")
  (V4BF "w") (V8BF "w")
  (V2SF "w") (V4SF "w")
  (V2DF "x")
  (VNx16QI "w") (VNx8QI "w") (VNx4QI "w") (VNx2QI "w")
  (VNx8HI "w") (VNx4HI "w") (VNx2HI "w")
  (VNx8HF "w") (VNx4HF "w") (VNx2HF "w")
  (VNx8BF "w") (VNx4BF "w") (VNx2BF "w")
  (VNx4SI "w") (VNx2SI "w")
  (VNx4SF "w") (VNx2SF "w")
  (VNx2DI "x")
  (VNx2DF "x")])

I will see if changing will fix it.

[Bug testsuite/103161] [12 Regression] Better ranges cause builtin-sprintf-warn-16.c failure

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

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

--- Comment #7 from Martin Sebor  ---
I bet you can't see the failures because they depend on fixes in a patch that
hasn't been committed yet:
  https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583735.html

But I wonder if there actually is something else wrong besides the test making
bad assumptions.  I glossed over an important detail in the test and reduced it
too far to capture the difference between the or1k-elf and x86_64 IL.  This is
closer to what the test does:

extern char a[1];

int f (void);

int g (void)
{
  extern unsigned w;

  if (w < 5)
w = 5;

  return __builtin_sprintf (a + 1, "%*i", w, f ());   <<< call f() to get value
}

The call to f() is what in x86_64 resets w's range (because w is extern and the
call to f() might overwrite it).  But with the or1k-elf target, that's not what
happens.  The IL shows that the call is made after the store to w and the value
used for the width in the sprintf() call is the one before the call.  That
seems like a bug, and that's the reason for the difference in the warning on
the two targets:

int g ()
{
  unsigned int w.0_1;
  int _3;
  int _9;
  unsigned int prephitmp_10;

   [local count: 1073741824]:
  w.0_1 = w;
  if (w.0_1 <= 4)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  w = 5;

   [local count: 1073741824]:
  # prephitmp_10 = PHI<<< w used in sprintf()
  _3 = f ();  <<< call to f() might
clobber w
  _9 = __builtin_sprintf (&MEM  [(void *)&a + 1B], "%*i",
prephitmp_10, _3);
  return _9;

}

The x86_64 IL looks correct:

   [local count: 1073741824]:
  _2 = f ();
  w.1_3 = w;
  _9 = __builtin_sprintf (&MEM  [(void *)&a + 1B], "%*i", w.1_3, _2);
  return _9;

[Bug fortran/102043] Wrong array types used for negative stride accesses

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

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu.org

--- Comment #9 from Bernhard Reutner-Fischer  ---
yes i've been looking into that too and it seems rather involved to switch the
addressing away from array_ref.

[Bug testsuite/103051] [12 regression] new test case gcc.dg/vect/tsvc/vect-tsvc-s112.c fails in r12-4840

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

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

--- Comment #8 from Segher Boessenkool  ---
Note that the -mcpu= in use can be set by compiler defaults as well (which
can be set at build time, --with-cpu=), or commonly in RUNTESTFLAGS (to test
a bunch of different -mcpu= settings at the same time, say).

[Bug testsuite/103051] [12 regression] new test case gcc.dg/vect/tsvc/vect-tsvc-s112.c fails in r12-4840

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

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

--- Comment #7 from Segher Boessenkool  ---
(In reply to Martin Liška from comment #4)
> Shouldn't the function check_effective_target_has_arch_pwr7 pass
> -mcpu=native?

No.  It checks if the effective target (set by options elsewhere!) is
power7 (or up).  It does not test a feature of the hardware.

[Bug fortran/102043] Wrong array types used for negative stride accesses

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #8 from Mikael Morin  ---
It comes from gfc_conv_expr_descriptor:

/* Point the data pointer at the 1st element in the section.  */
gfc_get_dataptr_offset (&loop.pre, parm, desc, base,
subref_array_target, expr);

where base has been calculated as the index of the first element.

I’ve tried doing a mere "if (forward) start else end" in the calculation of
base, but then I needed to add an offset (i.e. array index offset) to vector
subscript accesses, and then a delta was missing (i.e. loop index offset) as
the descriptor is one-based, but I don’t know how to fix the latter without
impacting all the vector subscript handling which seems to rely on quite a few
assumptions (no delta, no offset, zero-based loop?, forward loop?).

[Bug testsuite/103161] [12 Regression] Better ranges cause builtin-sprintf-warn-16.c failure

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

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

--- Comment #6 from Aldy Hernandez  ---
(In reply to Martin Sebor from comment #5)
> Great!  With the strlen conversion to ranger
> (g:6b8b959675a3e14cfdd2145bd62e4260eb193765) the test now fails on x86_64 as
> well:

I didn't see any regressions on x86-64 testing, except
builtin-sprintf-warn-22.c which I xfailed.

> I think the test unwittingly depends on GCC not inferring a range from a
> conditional (although the intent is clearly that it does).  It uses an
> unsigned int as the width argument to sprintf which is undefined, but I
> suspect it does it as an attempt to create a signed anti-range.  So this

If the code uses multi-ranges there should be no anti-ranges.  Anti-ranges do
not exist in the new world, and reference to them should be removed.

I still see them in:
gimple-ssa-warn-restrict.c
tree-ssa-strlen.c
builtins.c
ipa-fnsummary.c

(well and in ipa-prop.c, but they're kinda hijacking it for their own
purposes).

The remaining uses are internal to the legacy implementation (vrvalues,
tree-vrp, etc) so they're ok.

[Bug tree-optimization/102232] Missed arithmetic fold

[navidrahimi at microsoft dot com via Gcc-bugs]

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

--- Comment #7 from navidrahimi  ---
The new version of the patch I attached to this bug has been approved by
Richard Biener in this thread [1]. 



1) https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583935.html

[Bug testsuite/103161] [12 Regression] Better ranges cause builtin-sprintf-warn-16.c failure

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

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

Martin Sebor  changed:

   What|Removed |Added

  Component|tree-optimization   |testsuite

--- Comment #5 from Martin Sebor  ---
Great!  With the strlen conversion to ranger
(g:6b8b959675a3e14cfdd2145bd62e4260eb193765) the test now fails on x86_64 as
well:

Excess errors:
/src/gcc/master/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-16.c:142:5:
warning: '%*u' directive writing 5 or more bytes into a region of size 0
[-Wformat-overflow=]

while on or1k-elf:

Excess errors:
/src/gcc/master/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-16.c:142:5:
warning: '%*u' directive writing 5 or more bytes into a region of size 0
[-Wformat-overflow=]
/src/gcc/master/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-16.c:243:5:
warning: '%.*u' directive writing 7 or more bytes into a region of size 0
[-Wformat-overflow=]

I think the test unwittingly depends on GCC not inferring a range from a
conditional (although the intent is clearly that it does).  It uses an unsigned
int as the width argument to sprintf which is undefined, but I suspect it does
it as an attempt to create a signed anti-range.  So this might simply be a
problem with the test.  The difference between EVRP and Ranger can be seen in
the test case below (function g() corresponds to what the test does, and with
EVRP the range for w in it is the same as in f() on some targets like or1k-elf
and on others it's varying):

$ cat pr103161.c && gcc-11 -O2 -S -Wall -fdump-tree-strlen=/dev/stdout
pr103161.c
extern char a[1];

int f (int i, unsigned w)
{
  if (w < 5)
w = 5;

  return __builtin_sprintf (a + 1, "%*i", w, i);   // w's range is [5, INT_MAX]
}

int g (int i)
{
  extern unsigned w;

  if (w < 5)
w = 5;

  return __builtin_sprintf (a + 1, "%*i", w, i);   // w's range is [0, INT_MAX]
}

;; Function f (f, funcdef_no=0, decl_uid=1945, cgraph_uid=1, symbol_order=0)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }
pr103161.c:8: __builtin_sprintf: objsize = 0, fmtstr = "%*i"
  Directive 1 at offset 0: "%*i", width in range [5, 4294967295]
pr103161.c: In function ‘f’:
pr103161.c:8:37: warning: ‘%*i’ directive writing 5 or more bytes into a region
of size 0 [-Wformat-overflow=]
8 |   return __builtin_sprintf (a + 1, "%*i", w, i);   // w's range is [5,
INT_MAX]
  | ^~~
Result: 5, 5, -1, 4294967295 (5, 5, -1, -1)
  Directive 2 at offset 3: "", length = 1
pr103161.c:8:10: note: ‘__builtin_sprintf’ output 6 or more bytes into a
destination of size 0
8 |   return __builtin_sprintf (a + 1, "%*i", w, i);   // w's range is [5,
INT_MAX]
  |  ^~
  Discarding out-of-bounds return value 0.

int f (int i, unsigned int w)
{
  unsigned int _2;
  int _6;

   [local count: 1073741824]:
  _2 = MAX_EXPR ;
  _6 = __builtin_sprintf (&MEM  [(void *)&a + 1B], "%*i", _2, i_4(D));
  return _6;

}



;; Function g (g, funcdef_no=1, decl_uid=1948, cgraph_uid=2, symbol_order=1)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4
;; 2 succs { 3 4 }
;; 3 succs { 4 }
;; 4 succs { 1 }
pr103161.c:18: __builtin_sprintf: objsize = 0, fmtstr = "%*i"
  Directive 1 at offset 0: "%*i", width in range [0, 2147483648]
pr103161.c: In function ‘g’:
pr103161.c:18:37: warning: ‘%*i’ directive writing between 1 and 2147483648
bytes into a region of size 0 [-Wformat-overflow=]
   18 |   return __builtin_sprintf (a + 1, "%*i", w, i);   // w's range is [0,
INT_MAX]
  | ^~~
Result: 1, 1, 2147483648, 2147483648 (1, 1, 2147483648, 2147483648)
  Directive 2 at offset 3: "", length = 1
pr103161.c:18:10: note: ‘__builtin_sprintf’ output between 2 and 2147483649
bytes into a destination of size 0
   18 |   return __builtin_sprintf (a + 1, "%*i", w, i);   // w's range is [0,
INT_MAX]
  |  ^~
  Discarding out-of-bounds return value 0.

int g (int i)
{
  unsigned int w.0_1;
  int _8;
  unsigned int prephitmp_9;

   [local count: 1073741824]:
  w.0_1 = w;
  if (w.0_1 <= 4)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  w = 5;

   [local count: 1073741824]:
  # prephitmp_9 = PHI 
  _8 = __builtin_sprintf (&MEM  [(void *)&a + 1B], "%*i", prephitmp_9,
i_6(D));
  return _8;

}

While with today's trunk:

$ gcc-12 -O2  -S -Wall -fdump-tree-strlen=/dev/stdout pr103161.c
extern char a[1];

int f (int i, unsigned w)
{
  if (w < 5)
w = 5;

  return __builtin_sprintf (a + 1, "%*i", w, i);   // w's range is [5, INT_MAX]
}

int g (int i)
{
  extern unsigned w;

  if (w < 5)
w = 5;

  return __builtin_sprintf (a + 1, "%*i", w, i);   // w's range is [5, INT_MAX]
}

;; Function f (f, funcdef_no=0, decl_uid=1980, cg

[Bug tree-optimization/102232] Missed arithmetic fold

[navidrahimi at microsoft dot com via Gcc-bugs]

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

--- Comment #6 from navidrahimi  ---
Created attachment 51760
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51760&action=edit
[PATCH] PR tree-optimization/102232 Adding a missing pattern to match.pd

[Bug tree-optimization/102232] Missed arithmetic fold

[navidrahimi at microsoft dot com via Gcc-bugs]

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

navidrahimi  changed:

   What|Removed |Added

  Attachment #51752|0   |1
is obsolete||

--- Comment #5 from navidrahimi  ---
Comment on attachment 51752
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51752
[PATCH] PR tree-optimization/102232

>From 7c2abb0eab05766ab879066b000c13de827e3b3d Mon Sep 17 00:00:00 2001
>From: Navid Rahimi 
>Date: Mon, 8 Nov 2021 13:57:19 -0800
>Subject: [PATCH] PR tree-optimization/102232
>
>   * match.pd (x * (1 + y / x) - y) -> (x - y % x): New optimization.
>   * gcc.dg/tree-ssa/pr102232.c: testcase for this optimization.
>---
> gcc/match.pd |  7 
> gcc/testsuite/gcc.dg/tree-ssa/pr102232.c | 52 
> 2 files changed, 59 insertions(+)
> create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr102232.c
>
>diff --git a/gcc/match.pd b/gcc/match.pd
>index 71cf6f9df0a..37c01e79d97 100644
>--- a/gcc/match.pd
>+++ b/gcc/match.pd
>@@ -1295,6 +1295,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>  (bit_xor (bit_ior:c (bit_not @0) @1) (bit_ior:c @0 (bit_not @1)))
>  (bit_xor @0 @1))
> 
>+/* x * (1 + y / x) - y -> x - y % x */
>+(simplify
>+ (minus (mult:cs @0 (plus:cs integer_onep (trunc_div:s @1 @0))) @1)
>+ (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
>+  && types_match (@0, @1))
>+  (minus @0 (trunc_mod @1 @0
>+
> /* ((x & y) - (x | y)) - 1 -> ~(x ^ y) */
> (simplify
>  (plus (nop_convert1? (minus@2 (nop_convert2? (bit_and:c @0 @1))
>diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr102232.c 
>b/gcc/testsuite/gcc.dg/tree-ssa/pr102232.c
>new file mode 100644
>index 000..e7485cf24e9
>--- /dev/null
>+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr102232.c
>@@ -0,0 +1,52 @@
>+/* PR tree-optimization/102232 */
>+/* { dg-do run } */
>+/* { dg-options "-O3 -fdump-tree-optimized" } */
>+
>+int __attribute__ ((noipa)) foo (int a, int b)
>+{
>+  return b * (1 + a / b) - a;
>+}
>+
>+int
>+main (void)
>+{
>+  // few randomly generated test cases
>+  if (foo (71856034, 238) != 212)
>+{
>+  return 1;
>+}
>+  if (foo (71856034, 10909) != 1549)
>+{
>+  return 1;
>+}
>+  if (foo (20350, 1744) != 578)
>+{
>+  return 1;
>+}
>+  if (foo (444813, 88563) != 86565)
>+{
>+  return 1;
>+}
>+  if (foo (112237, 63004) != 13771)
>+{
>+  return 1;
>+}
>+  if (foo (68268386, 787116) != 210706)
>+{
>+  return 1;
>+}
>+  if (foo (-444813, 88563) != 90561)
>+{
>+  return 1;
>+}
>+  if (foo (-68268386, 787116) != 1363526)
>+{
>+  return 1;
>+}
>+
>+  return 0;
>+}
>+
>+/* Verify that multiplication and division has been removed.  */
>+/* { dg-final { scan-tree-dump-not " \\* " "optimized" } } */
>+/* { dg-final { scan-tree-dump-not " / " "optimized" } } */
>\ No newline at end of file
>-- 
>2.25.1
>

[Bug libstdc++/103162] overconstrained std::pmr::memory_resource allocate/deallocate methods

[florin.iucha at amd dot com via Gcc-bugs]

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

--- Comment #13 from Florin Iucha  ---
(In reply to Jonathan Wakely from comment #11)
> I'm going to get the standard clarified instead (and then cppreference will
> probably follow suit).

That will be great!

[Bug libstdc++/103162] overconstrained std::pmr::memory_resource allocate/deallocate methods

[florin.iucha at amd dot com via Gcc-bugs]

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

--- Comment #12 from Florin Iucha  ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Florin Iucha from comment #2)
> > It indicates that it reports errors via exceptions.
> 
> Yes, but that doesn't mean 0 is a valid return value. The non-nothrow forms
> of operator new also use exceptions to report errors, but that doesn't mean
> that they can return 0 as a valid pointer. pmr::memory_resource is intended
> to work the same way: either return a valid pointer to dereferencable
> memory, or throw an exception. There is no third alternative, of returning
> an invalid or null pointer value.

Well, bitten by a co-variant of Hyrum's law - the documentation doesn't
explicitly say "0 is not a valid return", and I was relying on the
documentation and my reading of the spec, without having access to the mental
model of the authors. Thank you again for acting as a conduit and clarifying
the design intent.

[Bug libstdc++/103162] overconstrained std::pmr::memory_resource allocate/deallocate methods

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

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

--- Comment #11 from Jonathan Wakely  ---
I'm going to get the standard clarified instead (and then cppreference will
probably follow suit).

[Bug libstdc++/103162] overconstrained std::pmr::memory_resource allocate/deallocate methods

[florin.iucha at amd dot com via Gcc-bugs]

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

--- Comment #10 from Florin Iucha  ---
(In reply to Jonathan Wakely from comment #8)
> > There are uses for the memory_resources pattern, outside of its current
> > application in the standard library - for example allocating ranges in a
> > file, or in a shared memory segment. 0 is valid allocation, although
> > obviously not directly dereferenceable.
> 
> Well then it's not a valid use of pmr::memory_resource. It needs to return a
> pointer to dereferenceable memory (after casting it from void* to something
> else of course).
>
... 
>
> If you're abusing the pmr::memory_resource interface to return a uintptr_t
> disguised a a void*, well that's abusing the API and not intended to be
> supported (according to the author of the proposal that added it to C++).

Thank you for taking the time to consider this - I will create the "abstract
integer range" allocator and use that for the other use cases.

It might be good though to update the documentation - perhaps even on
cppreference if you have access - to explicitly indicate these constraints as
following from the design intent.

[Bug libstdc++/103162] overconstrained std::pmr::memory_resource allocate/deallocate methods

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

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Florin Iucha from comment #2)
> It indicates that it reports errors via exceptions.

Yes, but that doesn't mean 0 is a valid return value. The non-nothrow forms of
operator new also use exceptions to report errors, but that doesn't mean that
they can return 0 as a valid pointer. pmr::memory_resource is intended to work
the same way: either return a valid pointer to dereferencable memory, or throw
an exception. There is no third alternative, of returning an invalid or null
pointer value.

[Bug libstdc++/103162] overconstrained std::pmr::memory_resource allocate/deallocate methods

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

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Florin Iucha from comment #7)
> There are uses for the memory_resources pattern, outside of its current
> application in the standard library - for example allocating ranges in a
> file, or in a shared memory segment. 0 is valid allocation, although
> obviously not directly dereferenceable.

Well then it's not a valid use of pmr::memory_resource. It needs to return a
pointer to dereferenceable memory (after casting it from void* to something
else of course).

If you have a scenario where you are doing some additional step to convert the
returned value into a dereferenceable pointer, can't you just adjust the
returned values to make that work?

e.g. set the most significant bit in the returned value, and clear it when
converting it to a pointer, or add a constant offset to every returned value
and then subtract that again when converting it to a pointer.

If you're abusing the pmr::memory_resource interface to return a uintptr_t
disguised a a void*, well that's abusing the API and not intended to be
supported (according to the author of the proposal that added it to C++).

[Bug tree-optimization/102892] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

--- Comment #6 from Aldy Hernandez  ---
(In reply to Martin Liška from comment #5)
> Fixed on master with r12-4790-g4b3a325f07acebf4.

Wadayaknow...I fixed it and didn't even know it :)

Thanks.

[Bug tree-optimization/102892] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #5 from Martin Liška  ---
Fixed on master with r12-4790-g4b3a325f07acebf4.

[Bug tree-optimization/102892] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #4 from Aldy Hernandez  ---
There's no call to foo in current trunk.

It seems to be gone in the .ccp4 dump which runs after vrp2.  This probably
went away with VRP2's switch to ranger.

Ideally we should add a testcase to the suite.  Could someone take care of
this?

Anywhoo, fixed.

[Bug tree-optimization/103173] New: strncpy output may be truncated copying 32 bytes from a string of length 1439 (bogus) [-Werror=stringop-truncation]

[patrickdepinguin at gmail dot com via Gcc-bugs]

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

Bug ID: 103173
   Summary: strncpy output may be truncated copying 32 bytes from
a string of length 1439 (bogus)
[-Werror=stringop-truncation]
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrickdepinguin at gmail dot com
  Target Milestone: ---

gcc 11.2.0 gives a bogus warning of type 'stringop-truncation' on below reduced
test case.

.../arm-cortex_a53-linux-gnueabi-gcc -O2 -Wall -Werror -c /tmp/test.c -o
/tmp/foo.o  
/tmp/test.c: In function 'func':
/tmp/test.c:22:5: error: 'strncpy' output may be truncated copying 32 bytes
from a string of length 1439 [-Werror=stringop-truncation]
   22 | strncpy(dest, data[j].name, sizeof(dest));
  | ^
cc1: all warnings being treated as errors


-

#include 

struct data_struct {
char name[32];
int bar;
};

void func()
{
extern struct data_struct data[40];
extern char dest[32];

int j=0;
strncpy(dest, data[j].name, sizeof(dest));
};

-


Here 'dest' is correctly interpreted as an array of size 32, but 'data[j].name'
is interpreted as having size 1439 which is incorrect, as it should also have
size 32 (name member of struct data_struct).

Following factors influence the reported size 1439:
* if data_struct is given more or less additional members, like 'bar'
* if the array length of 'data' (40) is changed
* if the length of the 'name' array in data_struct is changed

If 'j' is replaced by 0 directly, as in:
strncpy(dest, data[0].name, sizeof(dest));
the error disappears.


This problem did not occur on our previous toolchain with gcc 7.4.0 for the
same architecture, nor for x86_64 with gcc 7.5.0.

Info from gcc -v:

Using built-in specs.
COLLECT_GCC=.../buildroot-toolchains/output/host/opt/ext-toolchain/bin/arm-cortex_a53-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=.../buildroot-toolchains/output/host/opt/ext-toolchain/arm/bin/../libexec/gcc/arm-cortex_a53-linux-gnueabi/11.2.0/lto-wrapper
Target: arm-cortex_a53-linux-gnueabi
Configured with:
.../crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=arm-cortex_a53-linux-gnueabi
--prefix=.../crosstool-ng/targets/arm-cortex_a53-linux-gnueabi
--exec_prefix=.../crosstool-ng/targets/arm-cortex_a53-linux-gnueabi
--with-sysroot=.../crosstool-ng/targets/arm-cortex_a53-linux-gnueabi/arm-cortex_a53-linux-gnueabi/sysroot
--enable-languages=c,c++,fortran --with-cpu=cortex-a53 --with-fpu=neon-fp-armv8
--with-float=hard --with-pkgversion='crosstool-NG 1.24.0.487_10ac846'
--enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp
--disable-libquadmath --disable-libquadmath-support --disable-libsanitizer
--disable-libmpx
--with-gmp=.../crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-mpfr=.../crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-mpc=.../crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-isl=.../crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--disable-lto --without-zstd --enable-threads=posix --enable-target-optspace
--disable-plugin --disable-nls --disable-multilib
--with-local-prefix=.../crosstool-ng/targets/arm-cortex_a53-linux-gnueabi/arm-cortex_a53-linux-gnueabi/sysroot
--enable-long-long
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (crosstool-NG 1.24.0.487_10ac846)

[Bug libbacktrace/103167] UBSAN error since g:05f40bc4c116ba48843728201bc7290a5e518598

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug c++/99911] C++20 adl issue

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-10
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102760
 Status|UNCONFIRMED |ASSIGNED

--- Comment #6 from Patrick Palka  ---
Reduced rejects-valid testcase:

namespace N {
  struct A { };
  template void get(A);
};

template
auto tuple_flatten() {
  return []  (U) { get(T{}); };
}

int main() {
  tuple_flatten()(0);
}

[Bug c++/103057] [11/12 Regression] Internal compiler error: Error reporting routines re-entered since r11-291-g0f50f6daa140186a

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[11/12 Regression] Internal |[11/12 Regression] Internal
   |compiler error: Error   |compiler error: Error
   |reporting routines  |reporting routines
   |re-entered  |re-entered since
   ||r11-291-g0f50f6daa140186a
   Keywords|ice-on-invalid-code |ice-on-valid-code

--- Comment #6 from Martin Liška  ---
Thank you for the test-case. It started with r11-291-g0f50f6daa140186a with
-std=gnu2a.

[Bug c++/103057] [11/12 Regression] Internal compiler error: Error reporting routines re-entered

[plasmahh at gmx dot net via Gcc-bugs]

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

--- Comment #5 from Dennis Lubert  ---
Created attachment 51759
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51759&action=edit
cvise generated compling testcase

This one is pretty big but compiles with -w but ICEs without it. Differently to
my original code, here there is no unused argument that when being used
silences the warning and so circumvents the ICE. So I am not totally sure if
there maybe a third bug lurking somewhere...

Currently our code to be able to not ICE disables Wunused-parameter and
Wunused-value for the functions in question.

[Bug libstdc++/103162] overconstrained std::pmr::memory_resource allocate/deallocate methods

[florin.iucha at amd dot com via Gcc-bugs]

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

--- Comment #7 from Florin Iucha  ---
That is most unfortunate because it will force us to duplicate the library used
for resource management. Not only that, but if I were to implement the
pmr::memory_resource interface in terms of the other library which returns
uintptr_t/size_t (including the occasional 0), I would have to pay an
additional virtual method call just to wrap a static_cast / bit_cast.

There are uses for the memory_resources pattern, outside of its current
application in the standard library - for example allocating ranges in a file,
or in a shared memory segment. 0 is valid allocation, although obviously not
directly dereferenceable.

Also -fno-delete-null-pointer-checks is not helping me (I mistakenly thought it
silenced the sanitizer) because I am not directly dereferencing the result.
However the error I am getting is when I run the undefined behavior sanitizer
and it notices that the values returned from allocate() (retrieved from my
do_allocate) or passed back to deallocate() violate the attributes.

So I am left with three unsavory choices:
   1. patch the standard library to remove the checks;
   2. do not run undefined behavior sanitizer, or figure out some way to
distribute suppression files with the binaries;
   3. internally fork the libraries, with one flavor to be used with real
memory and real objects, the other with abstract "address ranges", and delegate
one implementation to the other, paying an extra virtual method call.

[Bug testsuite/103051] [12 regression] new test case gcc.dg/vect/tsvc/vect-tsvc-s112.c fails in r12-4840

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

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

Will Schmidt  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org

--- Comment #6 from Will Schmidt  ---
(In reply to Martin Liška from comment #4)
> All right, so I would ideally use:
> 
> /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target
> { has_arch_pwr7 } } } } */
> 
> but I see the following problem with detection of the target:
> 
>  78 Executing on host: /dev/shm/objdir/gcc/xgcc -B/dev/shm/objdir/gcc/
> arch_pwr759296.c  -fdiagnostics-plain-output  -S   -o arch_pwr759296.s   
> (timeout = 300)
>  79 spawn -ignore SIGHUP /dev/shm/objdir/gcc/xgcc -B/dev/shm/objdir/gcc/
> arch_pwr759296.c -fdiagnostics-plain-output -S -o arch_pwr759296.s^M
>  80 arch_pwr759296.c:3:18: error: #error does not have power7 support.^M
> 
>  81 compiler exited with status 1   
> 
>  82 output is:  
> 
>  83 arch_pwr759296.c:3:18: error: #error does not have power7 support.^M
> 
> 
> Note the 
> 
> #ifndef _ARCH_PWR7
> 
> only works when one uses -mcpu=native (or a corresponding -mflag), am I
> right?
> Shouldn't the function check_effective_target_has_arch_pwr7 pass
> -mcpu=native?

I would expect it to pass with -mcpu=native.   
Needs a closer look, not sure if I can get to it in short order.  Added Bill
and Segher to cc.

[Bug fortran/103172] ICE in gfc_check_init_expr, at fortran/expr.c:3014

[wileamyp at outlook dot com via Gcc-bugs]

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

--- Comment #2 from Wileam Yonatan Phan  ---
Comment on attachment 51758
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51758
Source code for minimal reproducer

>function assumed_rank_crash ( arr ) result( res )
>  implicit none
>
>  ! Arguments
>  real, intent(in) :: arr(..)
>  integer :: shparr = SHAPE(arr)
>  real :: res(shparr)
>
>  return
>end function assumed_rank_crash

Here's a condensed version that still reproduces the ICE.

function assumed_rank_crash ( arr )
  real :: arr(..)
  integer :: shparr = SHAPE(arr)
end function assumed_rank_crash

[Bug libbacktrace/103167] UBSAN error since g:05f40bc4c116ba48843728201bc7290a5e518598

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Martin Liška from comment #6)
> > Andrew, are you planning sending a patch candidate for this, please?
> 
> I doubt it, I have so many other things on my plate right now.

All right, lemme finish the patch.

[Bug fortran/96727] ICE with character length specified using specification function on assumed-rank array

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||wileamyp at outlook dot com

--- Comment #5 from Martin Liška  ---
*** Bug 103172 has been marked as a duplicate of this bug. ***

[Bug fortran/103172] ICE in gfc_check_init_expr, at fortran/expr.c:3014

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Liška  ---
Thanks for the report, it's a known issue.

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

[Bug fortran/103172] New: ICE in gfc_check_init_expr, at fortran/expr.c:3014

[wileamyp at outlook dot com via Gcc-bugs]

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

Bug ID: 103172
   Summary: ICE in gfc_check_init_expr, at fortran/expr.c:3014
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wileamyp at outlook dot com
  Target Milestone: ---

Created attachment 51758
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51758&action=edit
Source code for minimal reproducer

Hi,

I'd like to report an internal compiler error (ICE) when using the SHAPE
intrinsic on assumed-rank arrays on GFortran 10.3.0 (Ubuntu
10.3.0-1ubuntu1~20.04). I have tested the code on godbolt.org for various
versions of GFortran. Version 11 and newer seem to correctly produce an error
message instead of producing an ICE, but all older versions reproduce the ICE.

A minimal reproducer is attached here.

Thanks,
Wileam Y. Phan

[Bug c++/71740] [9/10 Regression] ICE when defining a pointer to the `memcpy()` function with namespace scope using `auto` targeting i686

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed on master with r11-4391-g4f8cfb42883cc247.

[Bug c++/101680] [9/10 Regression] spurious error: use of ‘this’ in a constant expression

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed on master with r11-6878-ga8cef3cba6945730 and the regression was
introduced in r9-5972-g10839133ce6c196c.