[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr

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

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

--- Comment #12 from Richard Biener  ---
(In reply to Jeffrey A. Law from comment #11)
> We can assume that the result of a POINTER_PLUS is non-null if either
> argument is non-null.  So X + constant is always non-null.  X + Y would be
> non-null if either X or Y is known to be non-null.
> 
> If we know that X + Y is non-null via some mechanism (for example the result
> was dereferenced), then we know that X and Y are non-null.

Yes, that summarizes it.  Note this only applies when
!targetm.addr_space.zero_address_valid.  There non-null plus a negative offset
may yield null.

Btw, the old VRP did this already, so I wonder whether it isn't already handled
correctly (minus the addr space thing maybe).

[Bug tree-optimization/103977] [12 Regression] ice in try_vectorize_loop_1 since r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/42108] [4.9 Regression] 50% performance regression

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

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

Bug 42436 Summary: VRP should mark non-trapping integer divisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42436

   What|Removed |Added

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

[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases

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

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

Bug 42436 Summary: VRP should mark non-trapping integer divisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42436

   What|Removed |Added

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

[Bug tree-optimization/42436] VRP should mark non-trapping integer divisions

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
I think this was trying to cover things like

  if (d != 0)
tem = a / d;

where the non-zero range of d on the division cannot be put in global ranges
for its SSA name since that would be incorrect for uses not guarded by the
condition.  So it would ask for a new flag on GIMPLE statements to mark the
division not trapping (like we have TREE_THIS_NOTRAP).  Transforms like
PRE or LIM that do code motion of course have to be careful to not move
the stmt outside of the condition that made it not trapping - something which
would be as hard to guarantee as computing the non-trappingness in the first
place.

So yes, the case that made me file this bug is fixed with global ranges.

Let's close this bug since it's quite unspecific.

[Bug c++/88165] error: default member initializer for 'A::B::m' required before the end of its enclosing class

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Fedor Chelnokov  ---
This struct definition:
```
struct A {
struct B {
int i = 0;
B() {}
};
A(B = {});
};
```
is accepted by GCC, but another one ({} replaced with = default) is not:
```
struct C {
struct D {
int i = 0;
D() = default;
};
C(D = {});
};
```
Demo: https://gcc.godbolt.org/z/WTPdTn1Yf

Could you please explain why? I though that both must be same accepted or same
rejected.

[Bug c++/104000] New: Ordinary constructor cannot delegate to `consteval` constructor

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 104000
   Summary: Ordinary constructor cannot delegate to `consteval`
constructor
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This program
```
struct A {   
int i = 0;
consteval A() = default;
A(int) : A() {}
};
```
is accepted by Clang so I assume it is valid. But GCC complains: error: 'this'
is not a constant expression

Demo: https://gcc.godbolt.org/z/3T9Pxdoz1

[Bug rtl-optimization/94790] Failure to use andn in specific pattern in which it is available

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Hongtao.liu  ---
Fixed in GCC12 for x86.

[Bug rtl-optimization/94790] Failure to use andn in specific pattern in which it is available

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

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

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

https://gcc.gnu.org/g:5f19303ada7db92c155332e7ba317233ca05946b

commit r12-6538-g5f19303ada7db92c155332e7ba317233ca05946b
Author: Haochen Jiang 
Date:   Wed Jan 12 10:01:21 2022 +0800

Optimize a ^ ((a ^ b) & mask) to (~mask & a) | (b & mask).

From the perspective of the pipeline, `andn + and + ior` version take
2 cycles(AND and ANDN doesn't have dependence), but xor + and + xor
will take 3 cycles.

-   xorl%edi, %esi
andl%edx, %esi
-   movl%esi, %eax
-   xorl%edi, %eax
+   andn%edi, %edx, %eax
+   orl %esi, %eax

gcc/ChangeLog:

PR target/94790
* config/i386/i386.md (*xor2andn): New define_insn_and_split.

gcc/testsuite/ChangeLog:

PR target/94790
* gcc.target/i386/pr94790-1.c: New test.
* gcc.target/i386/pr94790-2.c: Ditto.

[Bug target/82028] Windows x86_64 should not pass float aggregates in xmm

[10walls at gmail dot com via Gcc-bugs]

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

--- Comment #4 from jon_y <10walls at gmail dot com> ---
I can't seem to change the bug status to confirmed.

[Bug tree-optimization/103998] [12 Regression] Recent vectorizer testsuite regressions on x86 since r12-6420 and r12-6523

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Hongtao.liu from comment #3)
> > It seems to be fixed on latest trunk, or maybe latent?
> 
> That was PR 103971 I think.

Which was fixed by g:016bd7523131b645bca5b5530c81ab5149922743 .

[Bug tree-optimization/103998] [12 Regression] Recent vectorizer testsuite regressions on x86 since r12-6420 and r12-6523

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Hongtao.liu from comment #3)
> It seems to be fixed on latest trunk, or maybe latent?

That was PR 103971 I think.

[Bug tree-optimization/103998] [12 Regression] Recent vectorizer testsuite regressions on x86 since r12-6420 and r12-6523

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #2)
> r12-6420 also causes
> FAIL: gcc.target/i386/pr94494.c (internal compiler error: in operator[], at
> vec.h:889)
> FAIL: gcc.target/i386/pr94494.c (test for excess errors)

It seems to be fixed on latest trunk, or maybe latent?

[Bug tree-optimization/103998] [12 Regression] Recent vectorizer testsuite regressions on x86 since r12-6420 and r12-6523

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #2 from Hongtao.liu  ---
r12-6420 also causes
FAIL: gcc.target/i386/pr94494.c (internal compiler error: in operator[], at
vec.h:889)
FAIL: gcc.target/i386/pr94494.c (test for excess errors)

[Bug regression/103997] [12 Regression] gcc.target/i386/pr88531-??.c scan-assembler-times FAILs

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #2)
> https://gcc.gnu.org/pipermail/gcc-regression/2022-January/076174.html
> between commit r12-6426 and commit r12-6419

Cause by r12-6420

[Bug regression/103997] [12 Regression] gcc.target/i386/pr88531-??.c scan-assembler-times FAILs

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #2 from Hongtao.liu  ---
https://gcc.gnu.org/pipermail/gcc-regression/2022-January/076174.html
between commit r12-6426 and commit r12-6419

[Bug tree-optimization/103999] Vectorizer failed to reduce sum with conversion.

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
the difference between sum_reduce_cd and sum_reduce is one is 1.0 which is
double and another is 1.0f which doesn't need any conversion and truncation.

[Bug tree-optimization/103999] New: Vectorizer failed to reduce sum with conversion.

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 103999
   Summary: Vectorizer failed to reduce sum with conversion.
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

Vectorizer failed for sum_reduce_cd, but ok for sum_reduce/sum_reduce_cint

float sum_reduce_cd (int n, float* array)
{
float ans = 0.0f, x;
for (int i = 0; i != n; i++)
  {
  x = array[i];
  ans += x + 1.0;
  }
return ans;
}

float sum_reduce (int n, float* array)
{
float ans = 0.0f, x;
for (int i = 0; i != n; i++)
  {
  x = array[i];
  ans += x + 1.0f;
  }
return ans;
}

float sum_reduce_cint (int n, float* array)
{
int ans = 0;
float x;
for (int i = 0; i != n; i++)
  {
  x = array[i];
  ans += (int)(x + 1.0);
  }
return ans;
}

https://godbolt.org/z/q3McP6d15

[Bug regression/103997] [12 Regression] gcc.target/i386/pr88531-??.c scan-assembler-times FAILs

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|gcc.target/i386/pr88531-??. |[12 Regression]
   |c scan-assembler-times  |gcc.target/i386/pr88531-??.
   |FAILs   |c scan-assembler-times
   ||FAILs
   Target Milestone|--- |12.0

[Bug tree-optimization/103998] [12 Regression] Recent vectorizer testsuite regressions on x86 since r12-6420 and r12-6523

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||103997

--- Comment #1 from Andrew Pinski  ---
pr88531-* is recorded as PR 103997.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
[Bug 103997] gcc.target/i386/pr88531-??.c scan-assembler-times FAILs

[Bug tree-optimization/103998] [12 Regression] Recent vectorizer testsuite regressions on x86

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||avieira at gcc dot gnu.org,
   ||hjl.tools at gmail dot com,
   ||rsandifo at gcc dot gnu.org
   Priority|P3  |P1
   Target Milestone|--- |12.0

[Bug tree-optimization/103998] New: [12 Regression] Recent vectorizer testsuite regressions on x86

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

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

Bug ID: 103998
   Summary: [12 Regression] Recent vectorizer testsuite
regressions on x86
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

I'm seeing on x86_64-linux:
make check-gcc RUNTESTFLAGS="--target_board=unix\{-m32,-m64\}
vect.exp=vect-tail-nomask-1.c i386.exp='pr88531* vect-reduc-1.c'"
rm -rf testsuite/gcc-parallel
make[1]: Entering directory '/usr/src/gcc/obj/gcc'
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ../../gcc; ${PWDCMD-pwd}` ; export srcdir ; \
if [ -n "" ] \
   && [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] \
   && [ -f testsuite/gcc-parallel/finished ]; then \
  rm -rf testsuite/gcc; \
else \
  cd testsuite/gcc; \
  rm -f tmp-site.exp; \
  sed '/set tmpdir/ s|testsuite$|testsuite/gcc|' \
< ../../site.exp > tmp-site.exp; \
  /bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
  EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo
${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
  if [ -f ${rootme}/../expect/expect ] ; then  \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ; \
export TCL_LIBRARY ; \
  fi ; \
  `if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo
${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool gcc
--target_board=unix\{-m32,-m64\} vect.exp=vect-tail-nomask-1.c
i386.exp='pr88531* vect-reduc-1.c'; \
  if [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] ; then \
touch ${rootme}/testsuite/gcc-parallel/finished; \
  fi ; \
fi )
WARNING: Couldn't find the global config file.
Test run by jakub on Wed Jan 12 23:52:59 2022
Native configuration is x86_64-pc-linux-gnu

=== gcc tests ===

Schedule of variations:
unix/-m32
unix/-m64

Running target unix/-m32
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /usr/src/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific
interface file.
Running /usr/src/gcc/gcc/testsuite/gcc.dg/vect/vect.exp ...
FAIL: gcc.dg/vect/vect-tail-nomask-1.c scan-tree-dump-times vect "LOOP EPILOGUE
VECTORIZED \\(MODE=V16QI\\)" 2
FAIL: gcc.dg/vect/vect-tail-nomask-1.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "LOOP EPILOGUE VECTORIZED \\(MODE=V16QI\\)" 2
Running /usr/src/gcc/gcc/testsuite/gcc.target/i386/i386.exp ...
FAIL: gcc.target/i386/pr88531-1b.c scan-assembler-times vgatherdpd 4
FAIL: gcc.target/i386/pr88531-1b.c scan-assembler-times vmulpd 4
FAIL: gcc.target/i386/pr88531-1c.c scan-assembler-times vgatherdpd 4
FAIL: gcc.target/i386/pr88531-1c.c scan-assembler-times vmulpd 4
FAIL: gcc.target/i386/pr88531-2b.c scan-assembler-times vmulps 2
FAIL: gcc.target/i386/pr88531-2c.c scan-assembler-times vmulps 2
FAIL: gcc.target/i386/vect-reduc-1.c scan-tree-dump vect "LOOP EPILOGUE
VECTORIZED"
FAIL: gcc.target/i386/vect-reduc-1.c scan-assembler-times padd 5

=== gcc Summary for unix/-m32 ===

# of expected passes16
# of unexpected failures10
Running target unix/-m64
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /usr/src/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific
interface file.
Running /usr/src/gcc/gcc/testsuite/gcc.dg/vect/vect.exp ...
FAIL: gcc.dg/vect/vect-tail-nomask-1.c scan-tree-dump-times vect "LOOP EPILOGUE
VECTORIZED \\(MODE=V16QI\\)" 2
FAIL: gcc.dg/vect/vect-tail-nomask-1.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "LOOP EPILOGUE VECTORIZED \\(MODE=V16QI\\)" 2
Running /usr/src/gcc/gcc/testsuite/gcc.target/i386/i386.exp ...
FAIL: gcc.target/i386/pr88531-1b.c scan-assembler-times vgatherqpd 4
FAIL: gcc.target/i386/pr88531-1b.c scan-assembler-times vmulpd 4
FAIL: gcc.target/i386/pr88531-1c.c scan-assembler-times vgatherqpd 4
FAIL: gcc.target/i386/pr88531-1c.c scan-assembler-times vmulpd 4
FAIL: gcc.target/i386/pr88531-2b.c scan-assembler-times vmulps 2
FAIL: gcc.target/i386/pr88531-2c.c scan-assembler-times vmulps 2
FAIL: gcc.target/i386/vect-reduc-1.c scan-tree-dump vect "LOOP EPILOGUE
VECTORIZED"
FAIL: gcc.target/i386/vect-reduc-1.c scan-assembler-times padd 5

=== gcc Summary for unix/-m64 ===

# of expected passes16
# of unexpected failures10

=== gcc Summary ===

# of expected passes32
# of unexpected failures20
/usr/src/gcc/obj/gcc/xgcc  version 12.0.0 20220112 (experimental) (GCC) 

make[1]: Leaving directory '/usr

[Bug libfortran/103985] segfault in finalize_transfer (fbuf_destroy) on (parallel) writing into character / string function argument

[thomas.orgis--- via Gcc-bugs]

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

--- Comment #4 from Dr. Thomas Orgis  ---
I can try to roll a build and squeeze some test runs in. Naturally, this will
take a few days to get some statistical confidence and it depends on cluster
load, too.

So a snapshot of 12 would be preferred?

But also: Is it settled that there should even be any locking in the code path
to basically do sprintf() using a write to a character variable?

[Bug tree-optimization/103995] [11/12 Regression] conj() ignored with tree loop vectorizer

[michelemartone at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #3 from Michele Martone  ---
Comment on attachment 52175
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52175
output by running 'make'

For reference, I add here the output of 'make' with the defect.
The program is being built and run with different flags (also clang, for
comparison).
Each run ends with a line beginning either with 'OK' or 'BUG'.
One can see in the 'BUG' cases, '(0 -12)' is being computed in place of '(12
0)'.

[Bug tree-optimization/103995] [11/12 Regression] conj() ignored with tree loop vectorizer

[michelemartone at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #2 from Michele Martone  ---
Created attachment 52175
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52175=edit
output by running 'make'

[Bug libstdc++/103992] common_iterator(const common_iterator<_It2, _Sent2>& __x) uses new instead of construct_at

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Target Milestone|--- |12.0

--- Comment #2 from Jonathan Wakely  ---
Patch incoming ...

[Bug tree-optimization/103221] evrp removes |SIGN but does not propagate the ssa name

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #7 from Andrew Macleod  ---
We probably do need to revisit some pass ordering.  I hope to do even less
propagation within the VRPs next release, so I would expect running copyprop
afterwards would be worthwhile.

[Bug tree-optimization/103221] evrp removes |SIGN but does not propagate the ssa name

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |WONTFIX

--- Comment #6 from Andrew Pinski  ---
This bug was asking explictly for evpr to do that. So closing as won't fix
then.
The reasoning why I filed this bug is because between evrp and phiopt1 there is
not a copy prop pass.  The next copy prop pass is not until after inlining so
we might not inline as much either. So either we need to reorder some passes
around or add a copy prop pass sooner.

[Bug other/103617] Debugging gcc: can't use 'pp' command for irange

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Macleod  ---
I don't think PP is suppose to work with class instances when their address
cannot be taken.

[Bug tree-optimization/103221] evrp removes |SIGN but does not propagate the ssa name

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Macleod  ---
We perform this optimization in appropriate places.

EVRP uses ranges to remove the | -128 leaving the statement as a copy.

Although we could then propagate the copy into the PHI node, I think we should
leave that to the copy propagation and PHIOPT passes, as we could also make
poor decisions since we are doing it with no context. 

EVRP is enabling the other passes to do their job, and GCC turns this into
"return a" as expected.

[Bug fortran/67804] ICE on data initialization of type(character) with wrong data

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-January/057373.html

[Bug c++/102401] std::bit_cast falls over, seemingly due to some invisible alignment requirements

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

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

--- Comment #7 from Jakub Jelinek  ---
Note, since r12-5789-gc57c910c945ac68ba9a7cda9b0f963173781d58c
GCC implements https://wg21.link/P1272 which clarifies that the #c0 testcase is
invalid.
With unsigned char or std::byte instead of char in Data definition actually
doing std::bit_cast(item) would be well defined, but not the copying
of those bytes to d.

[Bug c++/103991] [12 Regression] Bogus -Wreturn-type with constexpr if and local var with destructor

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

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #7)
> > Now, as Richi's warning isn't in GCC 12, quickest/safest temporary fix 
> > would be
> > to revert to previous behavior for IF_STMT_CONSTEXPR_P and 
> > IF_STMT_CONSTEVAL_P,
> >  if (IF_STMT_CONSTEVAL_P (stmt))
> >stmt = else_;
> >  else if (IF_STMT_CONSTEXPR_P (stmt))
> >stmt = integer_nonzerop (cond) ? then_ ? else_;
> >  else
> >stmt = build3 (COND_EXPR, void_type_node, cond, then_, else_);
> 
> I agree that reverting for GCC 12 is the most reasonable thing with adding a
> Testcase

The above isn't a full reversion, it keeps the normal if (which isn't
problematic) as is and just reverts behavior for the special const{expr,eval}
ifs.

[Bug tree-optimization/97953] [9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

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

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

--- Comment #30 from Andrew Pinski  ---
(In reply to Daniel Scharrer from comment #29)
> Hi, shouldn't this be
> 
>  Known to fail  10.3.**1**
>  Known to work  10.3.**2**

No, 10.3.1 means the development branch that the 10.4.0 release will come. See
https://gcc.gnu.org/develop.html#num_scheme for more details on that:
To summarize, the first release of GCC 5 will be GCC 5.1.0 while development
snapshots will be GCC 5.0.0 and snapshots from the release branch GCC 5.n.1.

Basically x.y.1 is just a snapshot from the release branch and never a release
itself.

[Bug tree-optimization/103941] uavgv2qi3_ceil is not used (SLP costing and patterns vs live stmts)

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r12-6535-gcb46559cea1d554cef1138db5bfbdd0647ffbc0d
Author: Uros Bizjak 
Date:   Wed Jan 12 20:57:12 2022 +0100

testsuite: Compile gcc.target/i386/pr103861-3.c with -fno-vect-cost-model
[PR103941]

2022-01-12  Uroš Bizjak  

gcc/testsuite/ChangeLog:

PR target/103941
* gcc.target/i386/pr103861-3.c (dg-options): Add
-fno-vect-cost-model.

[Bug tree-optimization/97953] [9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[daniel at constexpr dot org via Gcc-bugs]

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

--- Comment #29 from Daniel Scharrer  ---
Hi, shouldn't this be

 Known to fail  10.3.**1**
 Known to work  10.3.**2**

[Bug testsuite/103935] [12 regression] g++.dg/vect/slp-pr98855.cc fails after r12-6273

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Uroš Bizjak  ---
Fixed.

[Bug fortran/67804] ICE on data initialization of type(character) with wrong data

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 52174
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52174=edit
Tentative patch

This patch should improve error recovery for a bad structure constructor in
a DATA statement.

Regtesting...

[Bug regression/103997] gcc.target/i386/pr88531-??.c scan-assembler-times FAILs

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||x86
   Keywords||needs-bisection

--- Comment #1 from Uroš Bizjak  ---
Needs bisection to find the offending commit.

[Bug regression/103997] New: gcc.target/i386/pr88531-??.c scan-assembler-times FAILs

[ubizjak at gmail dot com via Gcc-bugs]

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

Bug ID: 103997
   Summary: gcc.target/i386/pr88531-??.c scan-assembler-times
FAILs
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Recent patch introduced following testsuite FAILs:

FAIL: gcc.target/i386/pr88531-1b.c scan-assembler-times vgatherqpd 4
FAIL: gcc.target/i386/pr88531-1b.c scan-assembler-times vmulpd 4
FAIL: gcc.target/i386/pr88531-1c.c scan-assembler-times vgatherqpd 4
FAIL: gcc.target/i386/pr88531-1c.c scan-assembler-times vmulpd 4
FAIL: gcc.target/i386/pr88531-2b.c scan-assembler-times vmulps 2
FAIL: gcc.target/i386/pr88531-2c.c scan-assembler-times vmulps 2

[Bug c++/103991] [12 Regression] Bogus -Wreturn-type with constexpr if and local var with destructor

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #7 from rguenther at suse dot de  ---
> Am 12.01.2022 um 17:33 schrieb jakub at gcc dot gnu.org 
> :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103991
> 
> Jakub Jelinek  changed:
> 
>   What|Removed |Added
> 
> CC||rguenth at gcc dot gnu.org
> 
> --- Comment #4 from Jakub Jelinek  ---
> For IF_STMT_CONSTEXPR_P and IF_STMT_CONSTEVAL_P IF_STMTs, it is unclear what 
> we
> should do, because in either case we throw away the other branch if any.
> Either we do for those what we used to do before r12-5638 and risk
> -Wunreachable-code warnings (when/if it is readded), e.g. on code like:
>  if constexpr (true)
>return 0;
>  some code;
> but we don't emit these -Wreturn-type false positives in cases where the
> untaken block of code doesn't fall through.
> Or the r12-5638 can result in such false positives.
> Or perhaps we should track if we had the other block of code at all (if not, 
> it
> is ok to do what we do right now) and if possible otherwise try to figure out
> if the other block could fall through and if it can't, perhaps replace the
> void_node with __builtin_unreachable () call?
> For IF_STMT_CONSTEVAL_P we still have the other branch around and could 
> perhaps
> call block_may_fallthru on it, but for IF_STMT_CONSTEXPR_P we discard it
> earlier,
> outside of templates already during parsing.
> 
> Now, as Richi's warning isn't in GCC 12, quickest/safest temporary fix would 
> be
> to revert to previous behavior for IF_STMT_CONSTEXPR_P and 
> IF_STMT_CONSTEVAL_P,
>  if (IF_STMT_CONSTEVAL_P (stmt))
>stmt = else_;
>  else if (IF_STMT_CONSTEXPR_P (stmt))
>stmt = integer_nonzerop (cond) ? then_ ? else_;
>  else
>stmt = build3 (COND_EXPR, void_type_node, cond, then_, else_);

I agree that reverting for GCC 12 is the most reasonable thing with adding a
Testcase

> Jason, thoughts on this?
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug testsuite/103935] [12 regression] g++.dg/vect/slp-pr98855.cc fails after r12-6273

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r12-6534-ge1503b9a3d2f480d3df42823cd47c3b6c12f5564
Author: Uros Bizjak 
Date:   Wed Jan 12 20:38:42 2022 +0100

testsuite: Compile g++.dg/vect/slp-pr98855.cc only for x86 targets
[PR103935]

The testcase is x86 specific, other targets have different costs defined.

2022-01-12  Uroš Bizjak  

gcc/testsuite/ChangeLog:

PR target/103935
* g++.dg/vect/slp-pr98855.cc: Compile only for x86 targets.

[Bug tree-optimization/98026] optimization dependant on condition order

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #3 from Andrew Macleod  ---
Although we are now adding relations for these expressions, onc extension we
have not gotten to apply ranges of relations. ie:


 :
_1 = j_5(D) > i_6(D);
_2 = i_6(D) > 100;
_3 = _1 | _2;
if (_3 != 0)
  goto ; [INV]
else
  goto ; [INV]

2->3  (T) _3 :  bool [1, 1]
2->4  (F) _1 :  bool [0, 0]
2->4  (F) _2 :  bool [0, 0]
2->4  (F) _3 :  bool [0, 0]
2->4  (F) i_6(D) :  int [-INF, 100]

Relational : (j_5(D) <= i_6(D))
 :
if (j_5(D) > 100)
  goto ; [INV]
else
  goto ; [INV]

4->5  (T) j_5(D) :  int [101, +INF]
4->6  (F) j_5(D) :  int [-INF, 100]

We know that j_5 is <= i_6 on the edge 2->4, but we do not apply any known
range of i_6 to j_5.

We do transitive between symbolics, ie (j < x &&  x < y means j < y)
We do not yet do that with a range as this requires. ie:
  j_5 <= i_6,  i_6 <= 100  means j <= 100

This will be an enhancement for the next release.

[Bug target/100637] [i386] Vectorize 4-byte vectors

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #14 from Uroš Bizjak  ---
Let's say this is done now.

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

[pavel.morozkin at gmail dot com via Gcc-bugs]

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

Pavel M  changed:

   What|Removed |Added

 CC||pavel.morozkin at gmail dot com

--- Comment #21 from Pavel M  ---
FYI: Rationale for C, Revision 5.10, April-2003:
> Even with an explicit cast, it is invalid to convert a function pointer to an 
> object pointer or a pointer to void, or vice versa.

[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr

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

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

--- Comment #11 from Jeffrey A. Law  ---
We can assume that the result of a POINTER_PLUS is non-null if either argument
is non-null.  So X + constant is always non-null.  X + Y would be non-null if
either X or Y is known to be non-null.

If we know that X + Y is non-null via some mechanism (for example the result
was dereferenced), then we know that X and Y are non-null.

[Bug tree-optimization/103995] [11/12 Regression] conj() ignored with tree loop vectorizer

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|conj() ignored with tree|[11/12 Regression] conj()
   |loop vectorizer |ignored with tree loop
   ||vectorizer
 Target||x86-64
   Target Milestone|--- |11.3
  Known to work||10.2.0
  Known to fail||11.2.0

[Bug tree-optimization/103989] [12 regression] std::optional and bogus -Wmaybe-unitialized at -Og since r12-1992-g6feb628a706e86eb

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #4 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #3)
> That IMHO bogus D.35417 = D.35181; statement comes from the inliner and it
> can be fixed easily:
> 
> --- gcc/tree-inline.c.jj  2022-01-11 23:11:23.422275652 +0100
> +++ gcc/tree-inline.c 2022-01-12 18:37:44.119950128 +0100
> @@ -3608,7 +3608,7 @@ setup_one_parameter (copy_body_data *id,
> init_stmt = gimple_build_assign (def, rhs);
>   }
>   }
> -  else
> +  else if (!is_empty_type (TREE_TYPE (var)))
>  init_stmt = gimple_build_assign (var, rhs);

We should do this patch no matter what, it will speed up the compiler I think
(there has been other issues in the past in ipa-modref even of handling such IR
too).

[Bug target/100637] [i386] Vectorize 4-byte vectors

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

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r12-6533-gb5193e352981fab8441c600b0a50efe1f30c1d30
Author: Uros Bizjak 
Date:   Wed Jan 12 19:59:57 2022 +0100

i386: Add CC clobber and splits for 32-bit vector mode logic insns
[PR100673, PR103861]

Add CC clobber to 32-bit vector mode logic insns to allow variants with
general-purpose registers.  Also improve ix86_sse_movcc to emit insn with
CC clobber for narrow vector modes in order to re-enable conditional moves
for 16-bit and 32-bit narrow vector modes with -msse2.

2022-01-12  Uroš Bizjak  

gcc/ChangeLog:

PR target/100637
PR target/103861
* config/i386/i386-expand.c (ix86_emit_vec_binop): New static
function.
(ix86_expand_sse_movcc): Use ix86_emit_vec_binop instead of
gen_rtx_X
when constructing vector logic RTXes.
(expand_vec_perm_pshufb2): Ditto.
* config/i386/mmx.md (negv2qi): Disparage GPR alternative a bit.
(v2qi3): Ditto.
(vcond): Re-enable for TARGET_SSE2.
(vcondu): Ditto.
(vcond_mask_): Ditto.
(one_cmpl2): Remove expander.
(one_cmpl2): Rename from one_cmplv2qi.
Use VI_16_32 mode iterator.
(one_cmpl2 splitters): Use VI_16_32 mode iterator.
Use lowpart_subreg instead of gen_lowpart to create subreg.
(*andnot3): Merge from "*andnot" and
"*andnotv2qi3" insn patterns using VI_16_32 mode iterator.
Disparage GPR alternative a bit.  Add CC clobber.
(*andnot3 splitters): Use VI_16_32 mode iterator.
Use lowpart_subreg instead of gen_lowpart to create subreg.
(*3): Merge from
"*" and "*v2qi3" insn
patterns
using VI_16_32 mode iterator.  Disparage GPR alternative a bit.
Add CC clobber.
(*3 splitters):Use VI_16_32 mode
iterator.  Use lowpart_subreg instead of gen_lowpart to create
subreg.

gcc/testsuite/ChangeLog:

PR target/100637
PR target/103861
* g++.target/i386/pr100637-1b.C (dg-options):
Use -msse2 instead of -msse4.1.
* g++.target/i386/pr100637-1w.C (dg-options): Ditto.
* g++.target/i386/pr103861-1.C (dg-options): Ditto.
* gcc.target/i386/pr100637-4b.c (dg-options): Ditto.
* gcc.target/i386/pr103861-4.c (dg-options): Ditto.
* gcc.target/i386/pr100637-1b.c: Remove scan-assembler
directives for logic instructions.
* gcc.target/i386/pr100637-1w.c: Ditto.
* gcc.target/i386/warn-vect-op-2.c:
Update dg-warning for vector logic operation.

[Bug target/103861] [i386] vectorize v2qi vectors

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r12-6533-gb5193e352981fab8441c600b0a50efe1f30c1d30
Author: Uros Bizjak 
Date:   Wed Jan 12 19:59:57 2022 +0100

i386: Add CC clobber and splits for 32-bit vector mode logic insns
[PR100673, PR103861]

Add CC clobber to 32-bit vector mode logic insns to allow variants with
general-purpose registers.  Also improve ix86_sse_movcc to emit insn with
CC clobber for narrow vector modes in order to re-enable conditional moves
for 16-bit and 32-bit narrow vector modes with -msse2.

2022-01-12  Uroš Bizjak  

gcc/ChangeLog:

PR target/100637
PR target/103861
* config/i386/i386-expand.c (ix86_emit_vec_binop): New static
function.
(ix86_expand_sse_movcc): Use ix86_emit_vec_binop instead of
gen_rtx_X
when constructing vector logic RTXes.
(expand_vec_perm_pshufb2): Ditto.
* config/i386/mmx.md (negv2qi): Disparage GPR alternative a bit.
(v2qi3): Ditto.
(vcond): Re-enable for TARGET_SSE2.
(vcondu): Ditto.
(vcond_mask_): Ditto.
(one_cmpl2): Remove expander.
(one_cmpl2): Rename from one_cmplv2qi.
Use VI_16_32 mode iterator.
(one_cmpl2 splitters): Use VI_16_32 mode iterator.
Use lowpart_subreg instead of gen_lowpart to create subreg.
(*andnot3): Merge from "*andnot" and
"*andnotv2qi3" insn patterns using VI_16_32 mode iterator.
Disparage GPR alternative a bit.  Add CC clobber.
(*andnot3 splitters): Use VI_16_32 mode iterator.
Use lowpart_subreg instead of gen_lowpart to create subreg.
(*3): Merge from
"*" and "*v2qi3" insn
patterns
using VI_16_32 mode iterator.  Disparage GPR alternative a bit.
Add CC clobber.
(*3 splitters):Use VI_16_32 mode
iterator.  Use lowpart_subreg instead of gen_lowpart to create
subreg.

gcc/testsuite/ChangeLog:

PR target/100637
PR target/103861
* g++.target/i386/pr100637-1b.C (dg-options):
Use -msse2 instead of -msse4.1.
* g++.target/i386/pr100637-1w.C (dg-options): Ditto.
* g++.target/i386/pr103861-1.C (dg-options): Ditto.
* gcc.target/i386/pr100637-4b.c (dg-options): Ditto.
* gcc.target/i386/pr103861-4.c (dg-options): Ditto.
* gcc.target/i386/pr100637-1b.c: Remove scan-assembler
directives for logic instructions.
* gcc.target/i386/pr100637-1w.c: Ditto.
* gcc.target/i386/warn-vect-op-2.c:
Update dg-warning for vector logic operation.

[Bug c/103996] Provide Better diagnostic for invalid reuse of a function name

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Enhancement: Better |Provide Better diagnostic
   |diagnostic for invalid  |for invalid reuse of a
   |reuse of a function name|function name
   Severity|normal  |enhancement

[Bug middle-end/103993] -Wismatched-new-delete due to difference in inlining decisions

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

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||100406
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=100861
Summary|Incorrect error generated   |-Wismatched-new-delete due
   |by mismatched-new-delete|to difference in inlining
   ||decisions
   Keywords||diagnostic
  Component|c++ |middle-end

--- Comment #2 from Martin Sebor  ---
The reported mismatch is between

  void operator delete [](void*)

and

  void* ACE_Svc_Handler::operator new(size_t)

i.e., the array form of the global operator delete is being called on the
result of a scalar member operator new.  The deallocation function
corresponding to a member array new is a member array delete, so the warning
isn't incorrect per se.

The warning is based on the compiler's view of the optimized code, after
inlining and other transformations.  If the program provides overloads of
operators new and delete for some type and GCC inlines a call to one but not
the other, the warning will trigger because it sees a mismatch.  To avoid this
problem either prevent the inlining of both the allocation and the deallocation
function (using attribute noinline), or force both to be inlined (by declaring
them inline and attribute always_inline).  The diff below shows the latter
solution.  It's possible for GCC do the former automatically (and it does that
for a subset of these cases) but given it's not without a performance cost it
seems preferable to leave the choice up to the programmer.  Another approach
was suggested in pr101829.  See also pr100861 for a discussions of another
similar issue.

(When reporting a problem it's helpful to explain why you think it's in GCC
rather than in the submitted test case so we don't have to guess.)

$ diff -u JSimpleProcess.C JSimpleProcess-fix.C
--- JSimpleProcess.C2022-01-12 11:06:52.787461649 -0700
+++ JSimpleProcess-fix.C2022-01-12 11:18:30.085356124 -0700
@@ -78365,7 +78365,8 @@
   ;
   return;
 }
-template  void *
+template 
+inline __attribute__ ((always_inline)) void *
 ACE_Svc_Handler::operator new (size_t n)
 {
   ;
@@ -78378,10 +78379,11 @@
   else
 {
   dynamic_instance->set ();
-  return ::new char[n];
+  return ::operator new (n);
 }
 }
-template  void *
+template 
+inline __attribute__ ((always_inline)) void *
 ACE_Svc_Handler::operator new (size_t n,
   const
::std::nothrow_t&) throw()
 {
@@ -78395,15 +78397,16 @@
   else
 {
   dynamic_instance->set ();
-  return ::new(::std::nothrow) char[n];
+  return ::operator new(n, ::std::nothrow);
 }
 }
-template  void
+template 
+inline __attribute__ ((always_inline)) void
 ACE_Svc_Handler::operator delete (void *p,
  const ::std::nothrow_t&) throw()
 {
   ;
-  ::delete [] static_cast  (p);
+  ::operator delete (p);
 }
 template  void
 ACE_Svc_Handler::destroy ()
@@ -78412,11 +78415,12 @@
   if (this->mod_ == 0 && this->dynamic_ && this->closing_ == false)
 delete this;
 }
-template  void
+template 
+inline __attribute__ ((always_inline)) void
 ACE_Svc_Handler::operator delete (void *obj)
 {
   ;
-  ::delete [] static_cast  (obj);
+  ::operator delete (obj);
 }
 template 
 ACE_Svc_Handler::ACE_Svc_Handler
(ACE_Thread_Manager *tm,


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100406
[Bug 100406] bogus/missing -Wmismatched-new-delete

[Bug c/103996] Enhancement: Better diagnostic for invalid reuse of a function name

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Simplified testcase:
void f(void);
int main(void)
{
f[0] = 0;
}
The C++ front-end for the above testcase produces:
: In function 'int main()':
:4:8: warning: pointer to a function used in arithmetic
[-Wpointer-arith]
4 | f[0] = 0;
  |^
:4:10: error: assignment of read-only location '* f'
4 | f[0] = 0;
  | ~^~~

For a slightly different one:
void f(void);
void f(int);
int main(void)
{
f[0] = 0;
}
The C++ fornt-end produces similar to what was done in the index case.

[Bug c/103996] Enhancement: Better diagnostic for invalid reuse of a function name

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

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

--- Comment #1 from Andrew Pinski  ---
C++ front-end produces:
: In function 'void f()':
:4:10: error: invalid types '[int]' for array subscript
4 | index[0] = 0;
  |  ^

Which seems better.

[Bug c/103996] New: Enhancement: Better diagnostic for invalid reuse of a function name

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 103996
   Summary: Enhancement: Better diagnostic for invalid reuse of a
function name
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

Related email thread:
https://gcc.gnu.org/pipermail/gcc-help/2022-January/141117.html

I recently hit this problem:

#include 
void f() {
index[0] = 0;
}

#gcc is 11.2.0
gcc -c a.c
a.c:4:7: error: subscripted value is neither array nor pointer nor vector
4 |  index[1] = 0;
  |   ^

I could not find a compiler option that would tell me what the root cause was. 
I wasn't getting a simple "undeclared" error, so I surmised the name must
already be in use, but I was confused as to how or where it was being used.  My
first thought was that maybe index was a global variable, so I tried using
-Wshadow.  Eventually, I found that it was a function from strings.h which was
included several layers down an include spiral.

I think an effective note from gcc such as "index was previously declared here
as a function", or something similar that often happens in other diagnostics,
would aid in finding the root cause of my bug.

Incidentally, in my actual scenario, the real bug was that I forgot to access
index as a member of a struct: x.index vs index.  But I'd wager that expecting
GCC to look for all nearby structs for a similarly named member is
unreasonable.  Simply telling me where index originates, though, would have
helped greatly.

[Bug target/103980] -Wdouble-promotion triggers on s390x when it shouldn't.

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Ryan from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > It might be the case Wdouble-promotion is just useless on s390 if you
> > configure your compiler with --enable-s390-excess-float-precision which was
> > only added for GCC11, so basically between GCC 7 and GCC 10.x, the default
> > was to promote all float to double for s390.
> 
> It still seems odd that the warning is only produced when the -std flag is
> set, and only when comparisons are made.

-std enables -fexcess-precision=standard option.

[Bug tree-optimization/103995] conj() ignored with tree loop vectorizer

[michelemartone at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #1 from Michele Martone  ---
Small correction: the URL in the link above should have been just
 https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Optimize-Options.html
(top of the page).

[Bug tree-optimization/103995] New: conj() ignored with tree loop vectorizer

[michelemartone at users dot sourceforge.net via Gcc-bugs]

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

Bug ID: 103995
   Summary: conj() ignored with tree loop vectorizer
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michelemartone at users dot sourceforge.net
  Target Milestone: ---

Created attachment 52173
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52173=edit
conj() ignored with tree loop vectorizer -- reproducer

Hi.

With gcc-11.2.0 on x86-64 and given certain flags, this program (see
attachment) computes wrong results. 
Specifically, it seems like a conj() is being ignored in a loop.
The buggy.c file contains the impacted function, but also a reference one;
their results are being compared in main.c.

Reproduces on arch x86-64 with 11.2.0 with:

gcc -c -O3 buggy.c && gcc -c -O0 main.c && gcc buggy.o main.o -o buggy
&& ./buggy

Using ASAN:

gcc -c -O3 -fsanitize=address -fno-omit-frame-pointer buggy.c && gcc -c
-O3 -fsanitize=address -fno-omit-frame-pointer main.c && gcc buggy.o -lasan
main.o -o buggy && ./buggy   

it does not reproduce.

Reproducer flags with lower optimization are:

gcc -c -O1 -ftree-loop-vectorize -ftree-slp-vectorize buggy.c && gcc -c
-O0 main.c && gcc -O0 buggy.o main.o -o buggy && ./buggy

This can be minimized further by deactivating the individual -O1 flags listed
on

https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Optimize-Options.html#index-ftree-dse
using (-fno-...), exception made for two flags: -ftree-ch and -ftree-forwprop.

Using:  

-O0 -ftree-ch -ftree-forwprop -ftree-loop-vectorize
-ftree-slp-vectorize

is not enough -- seems like some implicit -O1 option is needed.

Putting all the code in one file does not reproduce the problem.

The Makefile has a recipe building and running the program with decreasing
optimization level, stepwise.

make # will print BUG on mismatch, OK otherwise; make expected NOT to
fail on gcc-11.2.0

make dist # zip the whole
make clean # clean

It does not reproduce on x86-64 and 10.2.0.
On aarch64 tried only with 11.0.0 and it does not reproduce.

[Bug target/103980] -Wdouble-promotion triggers on s390x when it shouldn't.

[rmaguire314 at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Ryan  ---
(In reply to Andrew Pinski from comment #7)
> It might be the case Wdouble-promotion is just useless on s390 if you
> configure your compiler with --enable-s390-excess-float-precision which was
> only added for GCC11, so basically between GCC 7 and GCC 10.x, the default
> was to promote all float to double for s390.

It still seems odd that the warning is only produced when the -std flag is set,
and only when comparisons are made.

[Bug tree-optimization/103989] [12 regression] std::optional and bogus -Wmaybe-unitialized at -Og since r12-1992-g6feb628a706e86eb

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
That IMHO bogus D.35417 = D.35181; statement comes from the inliner and it can
be fixed easily:

--- gcc/tree-inline.c.jj2022-01-11 23:11:23.422275652 +0100
+++ gcc/tree-inline.c   2022-01-12 18:37:44.119950128 +0100
@@ -3608,7 +3608,7 @@ setup_one_parameter (copy_body_data *id,
  init_stmt = gimple_build_assign (def, rhs);
}
}
-  else
+  else if (!is_empty_type (TREE_TYPE (var)))
 init_stmt = gimple_build_assign (var, rhs);

   if (bb && init_stmt)

which I think matches what the gimplifier does with assignments of empty type
objects.
Unfortunately that patch doesn't do anything with these warnings.

[Bug c++/103831] non-dependent call to non-static member function not rejected ahead of time when there are dependent bases and no 'this'

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #6 from Patrick Palka  ---
Should be fixed for GCC 11.3/12

[Bug c++/103831] non-dependent call to non-static member function not rejected ahead of time when there are dependent bases and no 'this'

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

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

--- Comment #5 from Patrick Palka  ---
(In reply to 康桓瑋 from comment #2)
> Please let me add a digression, is the standard overconstrained the
> definition of tiny_range? 
> In the current standard, it seems that only single_view and empty_view
> satisfy tiny_range. However, std::array and span or even
> int[1], in my opinion, should be valid Pattern types when V is an
> input_range, because we can directly extract their size from the type, but
> none of the three have a static size() function. This also means that the
> constructor lazy_split_view(R&&, P&&) has an *extremely* limited set of P
> when R is an input_range.

That sounds reasonable to me FWIW.  I believe the process for making such a
change starts with sending a proposal paper to LEWG for consideration.  I'm not
sure if there are any existing papers about this.

[Bug c++/103831] non-dependent call to non-static member function not rejected ahead of time when there are dependent bases and no 'this'

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

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

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

https://gcc.gnu.org/g:614a9580d4463c4aefd74c40ed46bfab2bef65c7

commit r11-9456-g614a9580d4463c4aefd74c40ed46bfab2bef65c7
Author: Patrick Palka 
Date:   Tue Jan 11 13:00:48 2022 -0500

c++: dependent bases and 'this' availability [PR103831]

Here during satisfaction of B's constraints we're failing to reject the
object-less call to the non-static member function A::size ultimately
because satisfaction is performed in the (access) context of the class
template B, which has a dependent base, and so the any_dependent_bases_p
check within build_new_method_call causes us to not reject the call.
(Subsequent constexpr evaluation of the call succeeds since the function
is effectively static.)

This patch fixes this by refining the any_dependent_bases_p check within
build_new_method_call: if we're in a context where 'this' is unavailable,
then we cannot resolve the implicit object regardless of the presence of
a dependent base.  So let's also check current_class_ptr alongside a_d_b_p.

PR c++/103831

gcc/cp/ChangeLog:

* call.c (build_new_method_call): Consider dependent bases only
if 'this' is available.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-class3.C: New test.
* g++.dg/template/non-dependent18.C: New test.

(cherry picked from commit 0378f563b0321c44c4a9c98cf46d2a22b9160f76)

[Bug testsuite/102935] [12 regression] new test case gcc.target/powerpc/pr101384-1.c fails

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

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #5 from Michael Meissner  ---
Patch committed on January 12th, 2022.

[Bug c++/103991] [12 Regression] Bogus -Wreturn-type with constexpr if and local var with destructor

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

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

--- Comment #6 from Jakub Jelinek  ---
For consteval if I guess we could do:
--- gcc/cp/cp-objcp-common.c.jj 2022-01-11 23:11:22.091294356 +0100
+++ gcc/cp/cp-objcp-common.c2022-01-12 17:57:18.232202275 +0100
@@ -313,6 +313,13 @@ cxx_block_may_fallthru (const_tree stmt)
   return false;

 case IF_STMT:
+  if (IF_STMT_CONSTEXPR_P (stmt))
+   {
+ if (integer_nonzerop (IF_COND (stmt)))
+   return block_may_fallthru (THEN_CLAUSE (stmt));
+ if (integer_zerop (IF_COND (stmt)))
+   return block_may_fallthru (ELSE_CLAUSE (stmt));
+   }
   if (block_may_fallthru (THEN_CLAUSE (stmt)))
return true;
   return block_may_fallthru (ELSE_CLAUSE (stmt));
--- gcc/cp/cp-gimplify.c.jj 2022-01-11 23:11:22.090294370 +0100
+++ gcc/cp/cp-gimplify.c2022-01-12 17:53:57.431036236 +0100
@@ -166,8 +166,13 @@ genericize_if_stmt (tree *stmt_p)
  can contain unfolded immediate function calls, we have to discard
  the then_ block regardless of whether else_ has side-effects or not.  */
   if (IF_STMT_CONSTEVAL_P (stmt))
-stmt = build3 (COND_EXPR, void_type_node, boolean_false_node,
-  void_node, else_);
+{
+  if (block_may_fallthru (then_))
+   stmt = build3 (COND_EXPR, void_type_node, boolean_false_node,
+  void_node, else_);
+  else
+   stmt = else_;
+}
   else
 stmt = build3 (COND_EXPR, void_type_node, cond, then_, else_);
   protected_set_expr_location_if_unset (stmt, locus);

[Bug testsuite/102935] [12 regression] new test case gcc.target/powerpc/pr101384-1.c fails

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Michael Meissner :

https://gcc.gnu.org/g:18d88d11973c63bda4e586b979b71d48c1d9b78a

commit r12-6532-g18d88d11973c63bda4e586b979b71d48c1d9b78a
Author: Michael Meissner 
Date:   Wed Jan 12 11:56:22 2022 -0500

Fix pr101384-1.c code generation test.

Add support for the compiler using XXSPLTIB reg,255 to load all 1's into a
register on power9 and above instead of using VSPLTI{B,H,W} reg,-1.

gcc/testsuite/
2022-01-12  Michael Meissner  

PR testsuite/102935
* gcc.target/powerpc/pr101384-1.c: Update insn regexp for power9
and power10.

[Bug c++/103994] New: Module ICE in mark_by_value, at cp/module.cc:4772

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 103994
   Summary: Module ICE in mark_by_value, at cp/module.cc:4772
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 52172
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52172=edit
module ICE

module;

#include 

export module cfg;

namespace cfg
{
export struct cfg_vertex
{
gtirb::CfgNode const* cfg_node_ptr{};
struct edge
{
std::size_t to{};
gtirb::CfgNode const* cfg_node_ptr{};
};
std::vector edges;
};

export inline std::vector get_cfg()
{
return {};
}
}


g++ -c cfg.cc -O2 -std=c++20 -fmodules-ts

cfg.cc:5:8: internal compiler error: in mark_by_value, at cp/module.cc:4772
5 | export module cfg;
  |^
0x7f8092e45fcf __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f8092e4607c __libc_start_main_impl
../csu/libc-start.c:409

[Bug libstdc++/103992] common_iterator(const common_iterator<_It2, _Sent2>& __x) uses new instead of construct_at

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I meant to fix this as part of r12-6438 and forgot.

[Bug c++/103991] [12 Regression] Bogus -Wreturn-type with constexpr if and local var with destructor

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

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

--- Comment #5 from Jakub Jelinek  ---
For the more permanent solution, perhaps making the other branch
__builtin_unreachable() if it doesn't fall through is too expensive and we
should just arrange for the pre- r12-5638 behavior where we in GENERIC pretend
there wasn't an if at all.

[Bug c++/103993] Incorrect error generated by mismatched-new-delete

[jjlindal at gmail dot com via Gcc-bugs]

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

--- Comment #1 from JohnJiming Lindal  ---
Created attachment 52171
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52171=edit
preprocessed output

[Bug c++/103993] New: Incorrect error generated by mismatched-new-delete

[jjlindal at gmail dot com via Gcc-bugs]

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

Bug ID: 103993
   Summary: Incorrect error generated by mismatched-new-delete
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jjlindal at gmail dot com
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-11.2.1-20211203/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20211203 (Red Hat 11.2.1-7) (GCC) 

$ g++ -std=c++17 -D_J_HAS_PROC -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED
-D_XFT_NO_COMPAT_ -I/usr/include/freetype2  -D_J_UNIX -D_J_HAS_XINERAMA -Wall
-Werror -I../include -I/usr/include/freetype2 -I/usr/include/libxml2 -O2  -c -o
code/JSimpleProcess.o code/JSimpleProcess.cpp -save-temps
In file included from /usr/local/include/ace/Svc_Handler.h:344,
 from ../include/jx-af/jcore/JNetworkProtocolBase.h:11,
 from ../include/jx-af/jcore/JMessageProtocol.h:11,
 from ../include/jx-af/jcore/JSimpleProcess.h:16,
 from code/JSimpleProcess.cpp:18:
In static member function ‘static void ACE_Svc_Handler::operator delete(void*) [with PEER_STREAM = ACE_LSOCK_Stream;
SYNCH_TRAITS = ACE_MT_SYNCH]’,
inlined from ‘JSimpleProcess::JSimpleProcess(pid_t, int, bool)’ at
code/JSimpleProcess.cpp:322:30:
/usr/local/include/ace/Svc_Handler.cpp:117:3: error: ‘void operator delete
[](void*)’ called on pointer returned from a mismatched allocation function
[-Werror=mismatched-new-delete]
  117 |   ::delete [] static_cast  (obj);
  |   ^~
code/JSimpleProcess.cpp: In constructor ‘JSimpleProcess::JSimpleProcess(pid_t,
int, bool)’:
code/JSimpleProcess.cpp:322:37: note: returned from ‘static void*
ACE_Svc_Handler::operator new(size_t) [with
PEER_STREAM = ACE_LSOCK_Stream; SYNCH_TRAITS = ACE_MT_SYNCH]’
  322 | itsLink = new ProcessLink(fd);
  | ^
In file included from /usr/local/include/ace/Svc_Handler.h:344,
 from ../include/jx-af/jcore/JNetworkProtocolBase.h:11,
 from ../include/jx-af/jcore/JMessageProtocol.h:11,
 from ../include/jx-af/jcore/JSimpleProcess.h:16,
 from code/JSimpleProcess.cpp:18:
In static member function ‘static void ACE_Svc_Handler::operator delete(void*) [with PEER_STREAM = ACE_LSOCK_Stream;
SYNCH_TRAITS = ACE_MT_SYNCH]’,
inlined from ‘JSimpleProcess::JSimpleProcess(pid_t, int, bool)’ at
code/JSimpleProcess.cpp:322:30:
/usr/local/include/ace/Svc_Handler.cpp:117:3: error: ‘void operator delete
[](void*)’ called on pointer returned from a mismatched allocation function
[-Werror=mismatched-new-delete]
  117 |   ::delete [] static_cast  (obj);
  |   ^~
code/JSimpleProcess.cpp: In constructor ‘JSimpleProcess::JSimpleProcess(pid_t,
int, bool)’:
code/JSimpleProcess.cpp:322:37: note: returned from ‘static void*
ACE_Svc_Handler::operator new(size_t) [with
PEER_STREAM = ACE_LSOCK_Stream; SYNCH_TRAITS = ACE_MT_SYNCH]’
  322 | itsLink = new ProcessLink(fd);
  | ^
cc1plus: all warnings being treated as errors

[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #10 from Andrew Macleod  ---
We currently get everything except the last tidbit.

a_1(D)  int * VARYING
 :
x_2 = a_1(D) == 0B;
a_3 = a_1(D) + 40;
return x_2;

When we see
   a_3 = a_1(D) + 40;

Are we allowed to assume that a_1 is non-null, just like we do with *a_1? That
seems a little dicier

Because if that is a valid assumption, we can handle pointer_plus the same as
we do non-null pointer tracking of dereferences.  That alone might handle it. 
We could also consider recalculating x_2 at the return location if need be.

If we cant make that assumption, then there isn't much else to do here as the
rest of the PR is covered.

[Bug c++/103991] [12 Regression] Bogus -Wreturn-type with constexpr if and local var with destructor

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
For IF_STMT_CONSTEXPR_P and IF_STMT_CONSTEVAL_P IF_STMTs, it is unclear what we
should do, because in either case we throw away the other branch if any.
Either we do for those what we used to do before r12-5638 and risk
-Wunreachable-code warnings (when/if it is readded), e.g. on code like:
  if constexpr (true)
return 0;
  some code;
but we don't emit these -Wreturn-type false positives in cases where the
untaken block of code doesn't fall through.
Or the r12-5638 can result in such false positives.
Or perhaps we should track if we had the other block of code at all (if not, it
is ok to do what we do right now) and if possible otherwise try to figure out
if the other block could fall through and if it can't, perhaps replace the
void_node with __builtin_unreachable () call?
For IF_STMT_CONSTEVAL_P we still have the other branch around and could perhaps
call block_may_fallthru on it, but for IF_STMT_CONSTEXPR_P we discard it
earlier,
outside of templates already during parsing.

Now, as Richi's warning isn't in GCC 12, quickest/safest temporary fix would be
to revert to previous behavior for IF_STMT_CONSTEXPR_P and IF_STMT_CONSTEVAL_P,
  if (IF_STMT_CONSTEVAL_P (stmt))
stmt = else_;
  else if (IF_STMT_CONSTEXPR_P (stmt))
stmt = integer_nonzerop (cond) ? then_ ? else_;
  else
stmt = build3 (COND_EXPR, void_type_node, cond, then_, else_);

Jason, thoughts on this?

[Bug libstdc++/103992] New: common_iterator(const common_iterator<_It2, _Sent2>& __x) uses new instead of construct_at

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 103992
   Summary: common_iterator(const common_iterator<_It2, _Sent2>&
__x) uses new instead of construct_at
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

common_iterator(const common_iterator<_It2, _Sent2>& __x) and
common_iterator(const common_iterator& __x) still use new.

#include

template
using CI = std::common_iterator<
  std::reverse_iterator, 
  std::unreachable_sentinel_t>;

static_assert([] {
  CI it1 = CI{};
  return true;
}());

https://godbolt.org/z/aT431jrhd

[Bug tree-optimization/103977] [12 Regression] ice in try_vectorize_loop_1 since r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af

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

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

--- Comment #8 from avieira at gcc dot gnu.org ---
The patch Jeff mentioned is this:
[vect] PR103971, PR103977: Fix epilogue mode selection for autodetect only

gcc/ChangeLog:

* tree-vect-loop.c (vect-analyze-loop): Handle scenario where target
does not add autovectorize_vector_modes.

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=016bd7523131b645bca5b5530c81ab5149922743

Should be OK to close this now?

[Bug tree-optimization/103971] [12 regression] build fails after r12-6420, ICE at libgfortran/generated/matmul_i1.c:2450

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

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from avieira at gcc dot gnu.org ---
Have been told powerpc is working again after:
[vect] PR103971, PR103977: Fix epilogue mode selection for autodetect only

gcc/ChangeLog:

* tree-vect-loop.c (vect-analyze-loop): Handle scenario where target
does not add autovectorize_vector_modes.

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=016bd7523131b645bca5b5530c81ab5149922743



Closing this PR.

[Bug tree-optimization/42436] VRP should mark non-trapping integer divisions

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Andrew Macleod  ---
What needs to be done here? anything?  

Looking at VRP1, there is only a single divide left at that point:

countm1.6_54 = _12 / _13;

and VRP1 is setting the global range of _13 to:

_13: unsigned int [2, 2147483647]

So at least from that point on, it is trivial to determine the divide is
non-trapping even using the global ranges.

[Bug tree-optimization/103977] [12 Regression] ice in try_vectorize_loop_1 since r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af

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

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

--- Comment #7 from avieira at gcc dot gnu.org ---
Thanks for confirming that Jeff :)

[Bug c++/103991] [12 Regression] Bogus -Wreturn-type with constexpr if and local var with destructor

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

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

--- Comment #3 from Jakub Jelinek  ---
Maybe better:
struct S { ~S(); };
int
foo ()
{
  S s;
  if constexpr (true)
return 0;
  else
return 1;
}

#if __cpp_if_consteval >= 202106L
constexpr int
bar ()
{
  S s;
  if consteval
{
  return 0;
}
  else
{
  return 1;
}
}

int
baz ()
{
  return bar ();
}
#endif

[Bug tree-optimization/103977] [12 Regression] ice in try_vectorize_loop_1 since r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af

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

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

--- Comment #6 from Jeffrey A. Law  ---
And just to follow-up.  With the patch that was committed to the trunk, the 30+
targets that were previously failing are now working.

A few are still building, but I expect them to succeed.  mips* is failing, but
I suspect it's the recent allocator changes, not the vectorizer changes causing
problems.

[Bug c++/103991] [12 Regression] Bogus -Wreturn-type with constexpr if and local var with destructor

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

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

--- Comment #2 from Jakub Jelinek  ---
Slightly bigger testcase that shows that also consteval if is affected:
struct S { ~S(); };
int
foo ()
{
  S s;
  if constexpr (true)
return 0;
  else
return 1;
}

#if __cpp_if_consteval >= 202106L
int
bar ()
{
  S s;
  if consteval
{
  return 0;
}
  else
{
  return 1;
}
}
#endif

[Bug tree-optimization/103720] bogus warning from -Wuninitialized + -ftrivial-auto-var-init + O2

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from qinzhao at gcc dot gnu.org ---
fixed in GCC12

[Bug tree-optimization/103720] bogus warning from -Wuninitialized + -ftrivial-auto-var-init + O2

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

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

--- Comment #3 from qinzhao at gcc dot gnu.org ---
this is fixed with the following commit in gcc12.
https://gcc.gnu.org/pipermail/gcc-cvs/2022-January/359118.html

[Bug target/98737] Atomic operation on x86 no optimized to use flags

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

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

--- Comment #11 from Jakub Jelinek  ---
Created attachment 52170
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52170=edit
gcc12-pr98737-canon.patch

Untested patch to fix up if users misuse the fetch_op or op_fetch atomic when
they should be using the other one.

[Bug sanitizer/103978] AddressSanitizer CHECK failed with threads and thread canceling with glibc 2.28+

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #10 from H.J. Lu  ---
I got this with GCC 12:

[hjl@gnu-tgl-3 tmp]$ /usr/gcc-12.0.0-x32/bin/gcc -fsanitize=address -pthread
x.c -Wl,-R,/usr/gcc-12.0.0-x32/lib64
[hjl@gnu-tgl-3 tmp]$ ldd a.out 
linux-vdso.so.1 (0x7fff71bf2000)
libasan.so.8 => /usr/gcc-12.0.0-x32/lib64/libasan.so.8
(0x7fcc73b56000)
libc.so.6 => /lib64/libc.so.6 (0x7fcc73936000)
libstdc++.so.6 => /usr/gcc-12.0.0-x32/lib/../lib64/libstdc++.so.6
(0x7fcc7371c000)
libm.so.6 => /lib64/libm.so.6 (0x7fcc7364)
libgcc_s.so.1 => /usr/gcc-12.0.0-x32/lib/../lib64/libgcc_s.so.1
(0x7fcc7361e000)
/lib64/ld-linux-x86-64.so.2 (0x7fcc749fd000)
[hjl@gnu-tgl-3 tmp]$ ./a.out 
=
==1360021==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x7f4a9b4fed50 at pc 0x7f4a9ce81a01 bp 0x7f4a9b4fed10 sp 0x7f4a9b4fe4c0
WRITE of size 24 at 0x7f4a9b4fed50 thread T-1
#0 0x7f4a9ce81a00  (/usr/gcc-12.0.0-x32/lib64/libasan.so.8+0x63a00)
#1 0x7f4a9cef8367  (/usr/gcc-12.0.0-x32/lib64/libasan.so.8+0xda367)
#2 0x7f4a9cee8004  (/usr/gcc-12.0.0-x32/lib64/libasan.so.8+0xca004)
#3 0x7f4a9cc88d20 in __nptl_deallocate_tsd (/lib64/libc.so.6+0x8ad20)
#4 0x7f4a9cc8ba51 in start_thread (/lib64/libc.so.6+0x8da51)
#5 0x7f4a9cd106df in __GI___clone3 (/lib64/libc.so.6+0x1126df)

Address 0x7f4a9b4fed50 is a wild pointer inside of access range of size
0x0018.
SUMMARY: AddressSanitizer: stack-buffer-underflow
(/usr/gcc-12.0.0-x32/lib64/libasan.so.8+0x63a00) 
Shadow bytes around the buggy address:
  0x0fe9d3697d50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe9d3697d60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe9d3697d70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe9d3697d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe9d3697d90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0fe9d3697da0: 00 00 00 00 00 00 00 00 00 00[f1]f1 f1 f1 00 00
  0x0fe9d3697db0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe9d3697dc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe9d3697dd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe9d3697de0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe9d3697df0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==1360021==ABORTING
[hjl@gnu-tgl-3 tmp]$

[Bug tree-optimization/103551] [12 Regression] wrong code with -O1 -fno-tree-dominator-opts -ftree-vectorize -ftree-vrp since r12-5014-g6b8b959675a3e14c

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Macleod  ---
In the end, simply set the EDGE_EXECUTABLE flag on all edges before running
ranger VRP and using the simplify engine.  
Fixed.

[Bug tree-optimization/83541] Missed optimization with int overflow

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Macleod  ---
fixed.

[Bug tree-optimization/83541] Missed optimization with int overflow

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:75845d584f490c294d40908168e5721adc38145d

commit r12-6529-g75845d584f490c294d40908168e5721adc38145d
Author: Andrew MacLeod 
Date:   Tue Jan 11 14:58:35 2022 -0500

Add testcase for PR 83541.

Ranger now performs this optimzation.

PR tree-optimization/83541
gcc/testsuite
* g++.dg/pr83541.C: New.

[Bug tree-optimization/103551] [12 Regression] wrong code with -O1 -fno-tree-dominator-opts -ftree-vectorize -ftree-vrp since r12-5014-g6b8b959675a3e14c

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:77184b7446196eae1a70452939ccd3e99e0d2e3b

commit r12-6528-g77184b7446196eae1a70452939ccd3e99e0d2e3b
Author: Andrew MacLeod 
Date:   Tue Jan 11 09:59:21 2022 -0500

Always set EDGE_EXECUTABLE in VRP2.

PR tree-optimization/103551
* tree-vrp.c (execute_ranger_vrp): Always set EDGE_EXECUTABLE.

[Bug target/97444] [nvptx] stack atomics

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

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

--- Comment #1 from Tom de Vries  ---
Created attachment 52169
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52169=edit
Tentative patch, __atomic_exchange only

Code generated for the generic case:
...
{ // Atomic exchange - generic - start  
  .reg .pred %local_p;  
  isspacep.local %local_p, %r26;
  @%local_p bra $L51;   
  .reg .pred %shared_p; 
  isspacep.shared %shared_p, %r26;  
  @%local_p bra $L52;   
  // Atomic exchange - generic - global 
  atom.exch.b32 %r27, [%r26], 2;
  bra $L53; 
$L51:
  // Atomic exchange - generic - local  
  {
.reg .b32 %tmp; 
ld.b32 %tmp, [%r26];
st.b32 [%r26], 2;   
mov.b32 %r27, %tmp; 
  }
  bra $L53; 
$L52:
  // Atomic exchange - generic - shared 
  atom.exch.b32 %r27, [%r26], 2;
$L53:
} // Atomic exchange - generic - end
...

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

Bug 103990 Summary: 541.leela_r slower by 4.5-6% with PGO+LTO -Ofast 
-march=native in the first week of January 2022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103990

   What|Removed |Added

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

[Bug tree-optimization/103990] 541.leela_r slower by 4.5-6% with PGO+LTO -Ofast -march=native in the first week of January 2022

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/103990] 541.leela_r slower by 4.5-6% with PGO+LTO -Ofast -march=native in the first week of January 2022

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

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

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

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

commit r12-6527-g2f62294dec1f3af59dd7505c058b0af38c2d1524
Author: Richard Biener 
Date:   Wed Jan 12 15:25:07 2022 +0100

tree-optimization/103990 - fix CFG cleanup regression from PRE change

This adjusts the CFG cleanup flow back to what it was before the
last change which fixes the observed regression of 541.leela_r with
LTO and FDO.

2022-01-12  Richard Biener  

PR tree-optimization/103990
* tree-pass.h (tail_merge_optimize): Drop unused argument.
* tree-ssa-tail-merge.c (tail_merge_optimize): Likewise.
* tree-ssa-pre.c (pass_pre::execute): Retain TODO_cleanup_cfg
and adjust call to tail_merge_optimize.

[Bug analyzer/103225] gcc/analyzer/sm-taint.cc:400:25: warning: private field 'm_dir' is not used [-Wunused-private-field]

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Thanks.  I believe I've fixed this in
r12-6526-g2c16dfe6268eeeb4b7924ff423e274fa00894a4d; marking as resolved.  Feel
free to reopen if I messed up.

[Bug target/82028] Windows x86_64 should not pass float aggregates in xmm

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||10walls at gmail dot com
   Last reconfirmed||2022-01-12

--- Comment #3 from Richard Biener  ---
Thus confirmed.

[Bug analyzer/103940] RFE: check -Wanalyzer-tainted-size on external fns with attribute ((access)) with a size-index

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

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

David Malcolm  changed:

   What|Removed |Added

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

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

[Bug analyzer/103940] RFE: check -Wanalyzer-tainted-size on external fns with attribute ((access)) with a size-index

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

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

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

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

commit r12-6526-g2c16dfe6268eeeb4b7924ff423e274fa00894a4d
Author: David Malcolm 
Date:   Tue Jan 11 15:57:39 2022 -0500

analyzer: complain about tainted sizes with "access" attribute [PR103940]

GCC 10 gained the "access" function and type attribute, which
optionally can take a size-index param:
  https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html

-fanalyzer in trunk (for GCC 12) has gained a -Wanalyzer-tainted-size to
complain about attacker-controlled size values, but this was only being
used deep inside the region-model code when handling the hardcoded known
behavior of certain functions (memset, IIRC).

This patch extends -Wanalyzer-tainted-size to also complain about
unsanitized attacker-controlled values being passed to function
parameters marked as a size via the "access" attribute.

Note that -fanalyzer-checker=taint is currently required in
addition to -fanalyzer to use this warning, due to scaling issues
(see bug 103533).

gcc/analyzer/ChangeLog:
PR analyzer/103940
* engine.cc (impl_sm_context::impl_sm_context): Add
"unknown_side_effects" param and use it to initialize
new m_unknown_side_effects field.
(impl_sm_context::unknown_side_effects_p): New.
(impl_sm_context::m_unknown_side_effects): New.
(exploded_node::on_stmt): Pass unknown_side_effects to sm_ctxt
ctor.
* sm-taint.cc: Include "stringpool.h" and "attribs.h".
(tainted_size::tainted_size): Drop "dir" param.
(tainted_size::get_kind): Drop "FINAL".
(tainted_size::emit): Likewise.
(tainted_size::m_dir): Drop unused field.
(class tainted_access_attrib_size): New subclass.
(taint_state_machine::on_stmt): Call check_for_tainted_size_arg on
external functions with unknown side effects.
(taint_state_machine::check_for_tainted_size_arg): New.
(region_model::check_region_for_taint): Drop "dir" param from
tainted_size ctor.
* sm.h (sm_context::unknown_side_effects_p): New.

gcc/testsuite/ChangeLog:
PR analyzer/103940
* gcc.dg/analyzer/taint-size-access-attr-1.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/103533] Enable "taint" state machine with -fanalyzer without requiring -fanalyzer-checker=taint

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

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

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

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

commit r12-6526-g2c16dfe6268eeeb4b7924ff423e274fa00894a4d
Author: David Malcolm 
Date:   Tue Jan 11 15:57:39 2022 -0500

analyzer: complain about tainted sizes with "access" attribute [PR103940]

GCC 10 gained the "access" function and type attribute, which
optionally can take a size-index param:
  https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html

-fanalyzer in trunk (for GCC 12) has gained a -Wanalyzer-tainted-size to
complain about attacker-controlled size values, but this was only being
used deep inside the region-model code when handling the hardcoded known
behavior of certain functions (memset, IIRC).

This patch extends -Wanalyzer-tainted-size to also complain about
unsanitized attacker-controlled values being passed to function
parameters marked as a size via the "access" attribute.

Note that -fanalyzer-checker=taint is currently required in
addition to -fanalyzer to use this warning, due to scaling issues
(see bug 103533).

gcc/analyzer/ChangeLog:
PR analyzer/103940
* engine.cc (impl_sm_context::impl_sm_context): Add
"unknown_side_effects" param and use it to initialize
new m_unknown_side_effects field.
(impl_sm_context::unknown_side_effects_p): New.
(impl_sm_context::m_unknown_side_effects): New.
(exploded_node::on_stmt): Pass unknown_side_effects to sm_ctxt
ctor.
* sm-taint.cc: Include "stringpool.h" and "attribs.h".
(tainted_size::tainted_size): Drop "dir" param.
(tainted_size::get_kind): Drop "FINAL".
(tainted_size::emit): Likewise.
(tainted_size::m_dir): Drop unused field.
(class tainted_access_attrib_size): New subclass.
(taint_state_machine::on_stmt): Call check_for_tainted_size_arg on
external functions with unknown side effects.
(taint_state_machine::check_for_tainted_size_arg): New.
(region_model::check_region_for_taint): Drop "dir" param from
tainted_size ctor.
* sm.h (sm_context::unknown_side_effects_p): New.

gcc/testsuite/ChangeLog:
PR analyzer/103940
* gcc.dg/analyzer/taint-size-access-attr-1.c: New test.

Signed-off-by: David Malcolm 

[Bug tree-optimization/103990] 541.leela_r slower by 4.5-6% with PGO+LTO -Ofast -march=native in the first week of January 2022

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

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

--- Comment #3 from Martin Jambor  ---
(In reply to Richard Biener from comment #2)
> 
> should fix that

I can confirm that it does.

[Bug target/82028] Windows x86_64 should not pass float aggregates in xmm

[lh_mouse at 126 dot com via Gcc-bugs]

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

LIU Hao  changed:

   What|Removed |Added

 CC||lh_mouse at 126 dot com

--- Comment #2 from LIU Hao  ---
As per


> Structs and unions of size 8, 16, 32, or 64 bits, and __m64 types, are 
> passed as if they were integers of the same size. Structs or unions of 
> other sizes are passed as a pointer to memory allocated by the caller.

GCC behavior seems incorrect.