[Bug ipa/106072] [13 Regression] Bogus -Wnonnull warning breaks rust bootstrap

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-14
 Target|sparc*-sun-solaris2.11  |sparc*-sun-solaris2.11
   |aarch64-linux-gnu,  |aarch64-linux-gnu,
   |powerpc-darwin9 |powerpc-darwin9,
   ||aarch64-darwin
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #11 from Iain Sandoe  ---
workaround did not work for me on either powerpc darwin or aarch64 (prototype).
x86_64 and i686 bootstrapped OK (without any workaround).

[Bug tree-optimization/107617] SCC-VN with len_store and big endian

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

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

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

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

commit r13-4694-gd3fee43fb3873b00de913e0501fbf28b56d2ce64
Author: Richard Biener 
Date:   Mon Nov 28 12:38:46 2022 +0100

tree-optimization/107617 - big-endian .LEN_STORE VN

The following fixes a mistake in interpreting .LEN_STORE definitions
during value-numbering when in big-endian mode.  We cannot offset
the encoding of the RHS but instead encode to an offsetted position
which is then treated correctly by the endian aware copying code.

PR tree-optimization/107617
* tree-ssa-sccvn.cc (vn_walk_cb_data::push_partial_def):
Handle negative pd.rhs_off.
(vn_reference_lookup_3): Properly provide pd.rhs_off
for .LEN_STORE on big-endian targets.

[Bug tree-optimization/107617] SCC-VN with len_store and big endian

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug bootstrap/108092] libstdc++ and all other gcc libraries installed incorrectly installed $PREFIX/lib32 for crossback compilation

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |bootstrap

--- Comment #1 from Andrew Pinski  ---
Why do you not use a sysroot?

[Bug libstdc++/108092] New: libstdc++ and all other gcc libraries installed incorrectly installed $PREFIX/lib32 for crossback compilation

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 108092
   Summary: libstdc++ and all other gcc libraries installed
incorrectly installed $PREFIX/lib32 for crossback
compilation
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

I do crossback compilation. The problem is that 32-bit libraries libstdc++ and
other libraries will install in $PREFIX/$TARGET/lib32 for x86_64-Linux-gnu
target. However, GCC does not try to find libraries in $PREFIX/$TARGET/lib32
with -m32. They should be installed in $PREFIX/$TARGET/lib instead of
$PREFIX/$TARGET/lib32

[Bug target/100866] PPC: Inefficient code for vec_revb(vector unsigned short) < P9

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

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

HaoChen Gui  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |guihaoc at gcc dot 
gnu.org
 CC||guihaoc at gcc dot gnu.org

--- Comment #17 from HaoChen Gui  ---
Both issues are fixed.

[Bug tree-optimization/104959] nested lambda capture pack by ref will load from nullptr

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Fixed in GCC 10.4.0 by the patch for PR 97938.

[Bug jit/108078] Canot compare vector types

[bouanto at zoho dot com via Gcc-bugs]

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

Antoni  changed:

   What|Removed |Added

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

--- Comment #2 from Antoni  ---
Fixed on master.

[Bug jit/108078] Canot compare vector types

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Antoni Boucher :

https://gcc.gnu.org/g:512098a3316f07d4b8bf0e035ab128ed2a50cb5e

commit r13-4693-g512098a3316f07d4b8bf0e035ab128ed2a50cb5e
Author: Antoni Boucher 
Date:   Fri Jun 24 21:05:29 2022 -0400

libgccjit: Allow comparing vector types

gcc/jit/ChangeLog:
PR jit/108078
* jit-recording.h: Add vector_type::is_same_type_as method

gcc/testsuite/ChangeLog:
PR jit/108078
* jit.dg/test-vector-types.cc: Add tests for vector type comparison

Co-authored-by: Guillaume Gomez 
Signed-off-by: Guillaume Gomez 

[Bug tree-optimization/106559] [10/11/12/13 Regression] Spurious warning -Wformat-truncation (regression from 9)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||cjamcl at gmail dot com

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

[Bug tree-optimization/85741] [meta-bug] bogus/missing -Wformat-overflow

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

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

Bug 108091 Summary: '-Wformat-overflow' determines incorrect size when printing 
strings from an array of structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108091

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug tree-optimization/108091] '-Wformat-overflow' determines incorrect size when printing strings from an array of structs

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Dup of bug 106559 (the underlying problem is the same).

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

[Bug tree-optimization/108091] '-Wformat-overflow' determines incorrect size when printing strings from an array of structs

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
IV-OPTS produces:
   [local count: 858993457]:
  # ivtmp.10_13 = PHI 
  _1 = (char[64] *) ivtmp.10_13;
  __builtin_strcpy (, _1);
  ivtmp.10_14 = ivtmp.10_13 + 68;
  if (ivtmp.10_14 != _17)
goto ; [80.00%]
  else
goto ; [20.00%]

   [local count: 687194763]:
  goto ; [100.00%]

Which confuses the warning pass.

[Bug tree-optimization/108091] New: '-Wformat-overflow' determines incorrect size when printing strings from an array of structs

[cjamcl at gmail dot com via Gcc-bugs]

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

Bug ID: 108091
   Summary: '-Wformat-overflow' determines incorrect size when
printing strings from an array of structs
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cjamcl at gmail dot com
  Target Milestone: ---

Given an array of structs for which a member is a `char[]`, `-Wformat-overflow`
will be far too conservative in its determination of how big the printed value
can be.


Repro:

https://gcc.godbolt.org/z/K69baxW55

```c
// gcc -Os -Wformat-overflow -c test.c

struct my_struct
{
char name[64];
int id;
};

struct my_struct list[]=
{
{ "A", 0},
{ "B", 0},
{ "C", 0},
{ "",  0},
};

int main() {
char str[100];

for (int i = 0; i < 4; i++) {
__builtin_sprintf(str, "%s", list[i].name);
}

return 0;
}
```

Output:

```
: In function 'int main()':
:19:33: warning: '%s' directive writing up to 271 bytes into a region
of size 100 [-Wformat-overflow=]
   19 | __builtin_sprintf(str, "%s", list[i].name);
  | ^~
:19:26: note: '__builtin_sprintf' output between 1 and 272 bytes into a
destination of size 100
   19 | __builtin_sprintf(str, "%s", list[i].name);
  | ~^
Compiler returned: 0
```


-

My assumption is that it cannot be determined that some value doesn't get a
non-null terminated string written to it at runtime, so the check is very
conservative and gives a length equal to the full size of the array.

In the above example, I'd expect gcc to know that the values are never
re-assigned, so it should use the length of whatever the biggest string in the
array is. I attempted to help the check by adding `const` qualifiers but that
didn't help.

[Bug c++/108090] New: pack expansion of using declarations doesn't properly handle dependent conversion function names

[richard-gccbugzilla at metafoo dot co.uk via Gcc-bugs]

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

Bug ID: 108090
   Summary: pack expansion of using declarations doesn't properly
handle dependent conversion function names
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

Testcase, which I believe is valid, and other compilers accept:

template struct As { operator T(); };
template struct AsAll : As... {
  using As::operator T...;
};
AsAll x;

But GCC rejects:

:3:26: error: parameter packs not expanded with '...':
3 |   using As::operator T...;
  |  ^~~
:3:26: note: 'T'

[Bug ipa/103585] fatigue2 requires inlining of peridida to work well

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

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:10478270fe0c39c59eb0f35d19356a63bdf3a2ad

commit r13-4687-g10478270fe0c39c59eb0f35d19356a63bdf3a2ad
Author: Martin Jambor 
Date:   Wed Dec 14 00:33:06 2022 +0100

ipa-sra: Treat REFERENCE_TYPES as always dereferencable

C++ and especially Fortran pass data by references which are not
pointers potentially pointing anywhere and so can be assumed to be
safely dereferencable.  This patch teaches IPA-SRA to treat them as
such and avoid the dance we do to prove that we can move loads from
them to the caller.

When we do not know that a dereference will happen all the time, we
need a heuristics so that we do not force memory accesses that normally
happen only rarely.  The patch simply uses the (possibly guessed)
profile and checks whether the (expected) number of loads is at least
half of function invocations invocations - the half is now
configurable with a param as requested by Honza.

gcc/ChangeLog:

2022-12-13  Martin Jambor  

PR ipa/103585
* params.opt (ipa-sra-deref-prob-threshold): New parameter.
* doc/invoke.texi (ipa-sra-deref-prob-threshold): Document it.
* ipa-sra.cc (struct gensum_param_access): New field load_count.
(struct gensum_param_desc): New field safe_ref, adjusted comments.
(by_ref_count): Renamed to unsafe_by_ref_count, adjusted all uses.
(dump_gensum_access): Dump the new field.
(dump_gensum_param_descriptor): Likewise.
(create_parameter_descriptors): Set safe_ref field, move setting
by_ref forward.  Only increment unsafe_by_ref_count for unsafe
by_ref parameters.
(allocate_access): Initialize new field.
(mark_param_dereference): Adjust indentation.  Only add data to
bb_dereferences for unsafe by_ref parameters.
(scan_expr_access): For loads, accumulate BB counts.
(dereference_probable_p): New function.
(check_gensum_access): Fix leading comment, add parameter FUN.
Check cumulative counts of loads for safe by_ref accesses instead
of dereferences.
(process_scan_results): Do not propagate dereference distances for
safe by_ref parameters.  Pass fun to check_gensum_access.  Safe
by_ref params do not need the postdominance check.

gcc/testsuite/ChangeLog:

2022-11-11  Martin Jambor  

* g++.dg/ipa/ipa-sra-5.C: New test

[Bug ipa/103227] [12 Regression] 58% exchange2 regression with -Ofast -march=native on zen3 since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:4834e9360f7bf42fbeabaa20de5619e67c9fee4e

commit r13-4685-g4834e9360f7bf42fbeabaa20de5619e67c9fee4e
Author: Martin Jambor 
Date:   Wed Dec 14 00:33:05 2022 +0100

ipa: Better way of applying both IPA-CP and IPA-SRA (PR 103227)

This is basically a better fix for PR 103227.  The one currently in
use, rushed in late at stage3, which means that IPA-CP transformation
simply does a replacement of default-definition of IPA-SRA-created
scalar parameters with a constant, meant that IPA-SRA actually often
led to creation of a bunch of unused parameters, which was rather
ironic and sub-optimal.

This patch rips that old way out and makes sure the clash is resolved
at clone-materialization time.  What happens is that:

1) IPA-SRA IPA analysis (decision) stage recognizes the clash and does
   not create a param adjustment entry for such a scalar component.

2) Clone materialization code checks the IPA-CP transformation
   summary and when it realizes that it is removing a parameter that
   is a base for a discovered IPA-CP aggregate constant, and:

   a) the value is passed by reference, it internally records that any
  load of the value is replaced directly with the known constant
  value.  IPA-SRA will not attempt to split values passed by
  reference when there is a write to it so we know such a load
  won't be on a a LHS.

   b) the value is passed by value, there can be stores to the
  corresponding bit of the aggregate and so all accesses are
  replaced with a new decl and an assignment of the constant to
  this decl is generated at the beginning of the function.

The new testcase contains an xfail as the patch does not fix PR 107640
but it is one that ICEs when one is not careful about remapping
indices of parameters, so I'd like to have it in testsuite/gcc.gd/ipa/
even now.

I don't think that PR 107640 should be attempted through
ipa-param-manipulation replacements because the information is not
really there any more and we'd either need to do the replacements
earlier or dig deep into the clone parent info.  Instead, we should
record somewhere that at the beginning of the function the bits of the
global decl have known values and use that in the value numbering.
That way we could one day encode also known constants in globals that
do not come through parameters.

gcc/ChangeLog:

2022-11-11  Martin Jambor  

PR ipa/103227
* ipa-param-manipulation.h (class ipa_param_adjustments): Removed
member function get_updated_index_or_split.
(class ipa_param_body_adjustments): New overload of
register_replacement, new member function append_init_stmts, new
member m_split_agg_csts_inits.
* ipa-param-manipulation.cc: Include ipa-prop.h.
(ipa_param_adjustments::get_updated_index_or_split): Removed.
(ipa_param_body_adjustments::register_replacement): New overload,
use
it from the older one.
(ipa_param_body_adjustments::common_initialization): Added the
capability to create replacements for conflicting IPA-CP discovered
constants.
(ipa_param_body_adjustments::ipa_param_body_adjustments): Construct
the new member.
(ipa_param_body_adjustments::append_init_stmts): New function.
* ipa-sra.cc: Include ipa-prop.h.
(push_param_adjustments_for_index): Require IPA-CP transformation
summary as a parameter, do not create replacements which are known
to
have constant values.
(process_isra_node_results): Find and pass to the above function
the
IPA-CP transformation summary.
* ipa-prop.cc (adjust_agg_replacement_values): Remove the
functionality replacing IPA-SRA created scalar parameters with
constants.  Simplify, do not require parameter descriptors, do not
return anything.
(ipcp_transform_function): Simplify now that
adjust_agg_replacement_values does not change cfg.  Move definition
and initialization of descriptors lower.
* tree-inline.cc (tree_function_versioning): Call append_init_stmts
of
param_body_adjs, if there are any.

gcc/testsuite/ChangeLog:

2022-11-11  Martin Jambor  

PR ipa/103227
PR ipa/107640
* gcc.dg/ipa/pr107640-2.c: New test.

[Bug ipa/107640] IPA-CP drops known values passed by reference when the reference is to a global variable

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:4834e9360f7bf42fbeabaa20de5619e67c9fee4e

commit r13-4685-g4834e9360f7bf42fbeabaa20de5619e67c9fee4e
Author: Martin Jambor 
Date:   Wed Dec 14 00:33:05 2022 +0100

ipa: Better way of applying both IPA-CP and IPA-SRA (PR 103227)

This is basically a better fix for PR 103227.  The one currently in
use, rushed in late at stage3, which means that IPA-CP transformation
simply does a replacement of default-definition of IPA-SRA-created
scalar parameters with a constant, meant that IPA-SRA actually often
led to creation of a bunch of unused parameters, which was rather
ironic and sub-optimal.

This patch rips that old way out and makes sure the clash is resolved
at clone-materialization time.  What happens is that:

1) IPA-SRA IPA analysis (decision) stage recognizes the clash and does
   not create a param adjustment entry for such a scalar component.

2) Clone materialization code checks the IPA-CP transformation
   summary and when it realizes that it is removing a parameter that
   is a base for a discovered IPA-CP aggregate constant, and:

   a) the value is passed by reference, it internally records that any
  load of the value is replaced directly with the known constant
  value.  IPA-SRA will not attempt to split values passed by
  reference when there is a write to it so we know such a load
  won't be on a a LHS.

   b) the value is passed by value, there can be stores to the
  corresponding bit of the aggregate and so all accesses are
  replaced with a new decl and an assignment of the constant to
  this decl is generated at the beginning of the function.

The new testcase contains an xfail as the patch does not fix PR 107640
but it is one that ICEs when one is not careful about remapping
indices of parameters, so I'd like to have it in testsuite/gcc.gd/ipa/
even now.

I don't think that PR 107640 should be attempted through
ipa-param-manipulation replacements because the information is not
really there any more and we'd either need to do the replacements
earlier or dig deep into the clone parent info.  Instead, we should
record somewhere that at the beginning of the function the bits of the
global decl have known values and use that in the value numbering.
That way we could one day encode also known constants in globals that
do not come through parameters.

gcc/ChangeLog:

2022-11-11  Martin Jambor  

PR ipa/103227
* ipa-param-manipulation.h (class ipa_param_adjustments): Removed
member function get_updated_index_or_split.
(class ipa_param_body_adjustments): New overload of
register_replacement, new member function append_init_stmts, new
member m_split_agg_csts_inits.
* ipa-param-manipulation.cc: Include ipa-prop.h.
(ipa_param_adjustments::get_updated_index_or_split): Removed.
(ipa_param_body_adjustments::register_replacement): New overload,
use
it from the older one.
(ipa_param_body_adjustments::common_initialization): Added the
capability to create replacements for conflicting IPA-CP discovered
constants.
(ipa_param_body_adjustments::ipa_param_body_adjustments): Construct
the new member.
(ipa_param_body_adjustments::append_init_stmts): New function.
* ipa-sra.cc: Include ipa-prop.h.
(push_param_adjustments_for_index): Require IPA-CP transformation
summary as a parameter, do not create replacements which are known
to
have constant values.
(process_isra_node_results): Find and pass to the above function
the
IPA-CP transformation summary.
* ipa-prop.cc (adjust_agg_replacement_values): Remove the
functionality replacing IPA-SRA created scalar parameters with
constants.  Simplify, do not require parameter descriptors, do not
return anything.
(ipcp_transform_function): Simplify now that
adjust_agg_replacement_values does not change cfg.  Move definition
and initialization of descriptors lower.
* tree-inline.cc (tree_function_versioning): Call append_init_stmts
of
param_body_adjs, if there are any.

gcc/testsuite/ChangeLog:

2022-11-11  Martin Jambor  

PR ipa/103227
PR ipa/107640
* gcc.dg/ipa/pr107640-2.c: New test.

[Bug analyzer/108028] Misleading -fanalyzer messages at -O2 and above

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

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

--- Comment #2 from David Malcolm  ---
(D)  Also, the 
(3) dereference of NULL '0'
is poorly worded; ideally we'd say:
(3) dereference of NULL 'q'

[Bug analyzer/108028] Misleading -fanalyzer messages at -O2 and above

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

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

David Malcolm  changed:

   What|Removed |Added

Summary|--Wanalyzer-null-dereferenc |Misleading -fanalyzer
   |e false positive with *q =  |messages at -O2 and above
   |1   |

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug.

There are several things going on here.

(A): the analyzer is considering the function "f" as called standalone, as well
as the case where it's called from "main", rather than merely considering it
when it's called from "main".  There are a few other bug reports about that;
it's not clear to me what we should do for this case; is it expected that such
functions are only ever called from main?

The situation is clearer if we simply delete "main" from the reproducer.  With
that, we see:

  'f': events 1-3
|
|7 | if (p && (0 == q))
|  |^
|  ||
|  |(1) following 'true' branch...
|8 | {
|9 | __analyzer_eval(p && (0 == q));
|  | ~~~
|  | |
|  | (2) ...to here
|..
|   14 | *q = 1;
|  | ~~
|  ||
|  |(3) dereference of NULL '0'
|


(B) arguably the CFG event (1) to (2) is poorly worded; at (1) we have
"following 'true' branch...", which suggests it always follows the 'true'
branch, whereas it's merely considering what happens *if* we take the 'true'
branch.

If it read: e.g.:

  'f': events 1-3
|
|7 | if (p && (0 == q))
|  |^
|  ||
|  |(1) considering following 'true' branch (implying that 'q'
is NULL)...
|8 | {
|9 | __analyzer_eval(p && (0 == q));
|  | ~~~
|  | |
|  | (2) ...to here
|..
|   14 | *q = 1;
|  | ~~
|  ||
|  |(3) dereference of NULL '0'
|

the analyzer would be more obviously correct and useful.

Or even "considering when 'q' is NULL; following 'true' branch..."

I've been experimenting with making the wording here clearer
(i): should make a distinction between when the analyzer chooses one of several
paths to consider, versus when the choice of execution path is already
determined by previous choices
(ii): would be nice to capture that q's nullness is the most interesting
property at the "if" statement with respect to the warning, and express that to
the user.


(C) The analyzer runs relatively late compared to most static analyzers, so the
optimization levels affect things.  In particular, consider the gimple IR seen
by -fanalyzer for the assignment:
 *q = 1;
in the block guarded by (0 == q).

At -O1 we have:
 *q_10(D) = 1;
but at -O2 it converts it to:
 MEM[(int *)0B] = 1;

Arguably it's a bug here that we only warn at -O2 and above; analyzing "f"
standalone, we ought to be complaining about the null dereference without
needing -O2.
(specifically, at -O2 -fanalyzer sees a deref of NULL, whereas at -O1 it merely
sees a deref of INIT_VAL(q), whilst knowing the constraint that INIT_VAL(q) is
NULL.
The __analyzer_eval results are also due to gimple IR differences caused by the
optimizer.

Also, perhaps we should run earlier; I probably ought to file a bug about that,
it's a big can of worms.

[Bug fortran/79426] [10/11/12/13 Regression] fortran - internal compiler error: in fold_convert_loc, at fold-const.c:2251

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||anlauf at gcc dot gnu.org

--- Comment #15 from anlauf at gcc dot gnu.org ---
The testcase in comment#0 seems to work on mainline, 12-branch and 11-branch.
It still ICEs on 10-branch at GNU Fortran (GCC) 10.4.1 20221125.

[Bug target/108044] [13 Regression] ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints) at -O

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug target/108044] [13 Regression] ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints) at -O

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:37c2d99f3f569350ebc0de43c10374b90086b832

commit r13-4683-g37c2d99f3f569350ebc0de43c10374b90086b832
Author: Jakub Jelinek 
Date:   Tue Dec 13 22:16:34 2022 +0100

i386: Fix up *concat*_{5,6,7} patterns [PR108044]

The following patch fixes 2 issues with the *concat3_5 and
*concat3_{6,7} patterns.
One is that if the destination is memory rather than register, then
we can't use movabsq and so can't support all the possible immediates.
I see 3 possibilities to fix that.  One would be to use
x86_64_hilo_int_operand predicate instead of const_scalar_int_operand
and thus not match it at all during combine in such cases, but that
unnecessarily pessimizes also the case when it is loaded into register
where we can use movabsq.
Another one is what is implemented in the patch, use Wd constraint
for the integer on 64-bit if destination is memory and n otherwise.
Yet another option would be to add match_scratch to the pattern and use
it with =X constraints except for the =o case for 64-bit non-Wd where it
would give a single DImode register (rather than 2).

Another thing is that if one half of the constant is
ix86_endbr_immediate_operand, then for -fcf-protection=branch we
force those constants into memory and that might not work properly
with -fpic.  So we should refuse to match with such constants.
OT, seems for movabsq we don't check that and happily allow the endbr
pattern in the immediate.

2022-12-13  Jakub Jelinek  

PR target/108044
* config/i386/i386.md (*concat3_5,
*concat3_6,
*concat3_7): Split alternative with =ro output
constraint
into =r,o,o and use Wd input constraint for the last alternative
which
is enabled for TARGET_64BIT.  Reject ix86_endbr_immediate_operand
in the input constant.

* gcc.target/i386/pr108044-1.c: New test.
* gcc.target/i386/pr108044-2.c: New test.
* gcc.target/i386/pr108044-3.c: New test.
* gcc.target/i386/pr108044-4.c: New test.

[Bug fortran/107423] ICE in parse_spec, at fortran/parse.cc:4017

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
 Status|NEW |RESOLVED
   Target Milestone|--- |13.0
 Resolution|--- |FIXED

--- Comment #3 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-13.  Closing.

Thanks for the report!

[Bug tree-optimization/108088] False positive for -Wfree-nonheap-object when using std::variant

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

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

--- Comment #2 from Jonathan Wakely  ---
*** Bug 108089 has been marked as a duplicate of this bug. ***

[Bug c++/108089] False positive for -Wfree-nonheap-object when using std::variant

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/108088] False positive for -Wfree-nonheap-object when using std::variant

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

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

--- Comment #1 from Andrew Pinski  ---
-O2 -std=c++17 -Wall -Werror=free-nonheap-object

[Bug c++/108089] False positive for -Wfree-nonheap-object when using std::variant

[falemagn at gmail dot com via Gcc-bugs]

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

Fabio Alemagna  changed:

   What|Removed |Added

  Known to work||11.3.0
  Known to fail||12.1.0

--- Comment #1 from Fabio Alemagna  ---
To be noted that the issue doesn't happen on gcc v11.3.

[Bug c++/108089] New: False positive for -Wfree-nonheap-object when using std::variant

[falemagn at gmail dot com via Gcc-bugs]

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

Bug ID: 108089
   Summary: False positive for -Wfree-nonheap-object when using
std::variant
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: falemagn at gmail dot com
  Target Milestone: ---

The following is the most reduced example I could come up with.

#include 
#include 
#include 

using variant = std::variant<
std::string,
std::vector
>;

extern std::size_t _index;

void func() {
ext_index = variant(std::string()).index();
}

"ext_index" being a reference is all it takes to trigger the issue. If it'd be
an object, the issue would not triggered. The issue would be triggered also if
ext_index were a pointer.

As far as I could tell, ff "std::string" is substituted with a type whose
destructor doesn't involve any deallocation, then the issue is not triggered.

The issue is also not triggered if std::string is substituted with another
std::vector specialization.

You can see it all on godbolt: https://godbolt.org/z/aaxY1jW1q

This is the error (unecessary lines removed):

In member function 'void std::__new_allocator<_Tp>::deallocate(_Tp*,
size_type) [with _Tp = char]',
inlined from 'static void
std::allocator_traits >::deallocate(allocator_type&,
pointer, size_type) [with _Tp = char]' at /opt/compiler-explorer/gcc-12.1.0/

[...]

inlined from 'std::variant<_Types>::~variant() [with _Types =
{std::__cxx11::basic_string, std::allocator
>, std::vector >}]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/variant:1407:28,
inlined from 'void func()' at :14:17:
   
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/new_allocator.h:158:33:
error: 'void operator delete(void*, std::size_t)' called on unallocated object
'' [-Werror=free-nonheap-object]
  158 | _GLIBCXX_OPERATOR_DELETE(_GLIBCXX_SIZED_DEALLOC(__p,
__n));
  | ^
: In function 'void func()':
:14:38: note: declared here
   14 | ext_index = variant(std::string()).index();
  |  ^

[Bug c++/108088] New: False positive for -Wfree-nonheap-object when using std::variant

[falemagn at gmail dot com via Gcc-bugs]

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

Bug ID: 108088
   Summary: False positive for -Wfree-nonheap-object when using
std::variant
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: falemagn at gmail dot com
  Target Milestone: ---

Created attachment 54083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54083=edit
Preprocessed file

The following is the most reduced example I could come up with.

#include 
#include 
#include 

using variant = std::variant<
std::string,
std::vector
>;

extern std::size_t _index;

void func() {
ext_index = variant(std::string()).index();
}

"ext_index" being a reference is all it takes to trigger the issue. If it'd be
an object, the issue would not triggered. The issue would be triggered also if
ext_index were a pointer.

As far as I could tell, ff "std::string" is substituted with a type whose
destructor doesn't involve any deallocation, then the issue is not triggered.

The issue is also not triggered if std::string is substituted with another
std::vector specialization.

You can see it all on godbolt: https://godbolt.org/z/aaxY1jW1q

This is the error (unecessary lines removed):

In member function 'void std::__new_allocator<_Tp>::deallocate(_Tp*,
size_type) [with _Tp = char]',
inlined from 'static void
std::allocator_traits >::deallocate(allocator_type&,
pointer, size_type) [with _Tp = char]' at /opt/compiler-explorer/gcc-12.1.0/

[...]

inlined from 'std::variant<_Types>::~variant() [with _Types =
{std::__cxx11::basic_string, std::allocator
>, std::vector >}]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/variant:1407:28,
inlined from 'void func()' at :14:17:
   
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/new_allocator.h:158:33:
error: 'void operator delete(void*, std::size_t)' called on unallocated object
'' [-Werror=free-nonheap-object]
  158 | _GLIBCXX_OPERATOR_DELETE(_GLIBCXX_SIZED_DEALLOC(__p,
__n));
  | ^
: In function 'void func()':
:14:38: note: declared here
   14 | ext_index = variant(std::string()).index();
  |  ^

[Bug rust/108087] -Wodr warnings in rust/rust-lang.cc (lang_type)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build

--- Comment #2 from Andrew Pinski  ---
This does look like a real issue in the rust front-end.
lang_type is defined differently in those two files.

[Bug rust/108087] -Wodr warnings in rust/rust-lang.cc (lang_type)

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #1 from Sam James  ---
Sorry, output got mangled slightly by ansifiltering:
```
/var/tmp/portage/sys-devel/gcc-13.0./work/gcc-13.0./gcc/rust/rust-lang.cc:67:17:
warning: type ‘struct lang_type’ violates the C++ One Definition Rule [-Wodr]
   67 | struct GTY (()) lang_type
  | ^
/var/tmp/portage/sys-devel/gcc-13.0./work/gcc-13.0./gcc/rust/backend/rust-tree.h:234:
note: a different type is defined in another translation unit
  234 | struct GTY (()) lang_type
  |
/var/tmp/portage/sys-devel/gcc-13.0./work/gcc-13.0./gcc/rust/backend/rust-tree.h:236:
note: the first difference of corresponding definitions is field ‘align’
  236 |   unsigned char align;
  |
/var/tmp/portage/sys-devel/gcc-13.0./work/gcc-13.0./gcc/rust/backend/rust-tree.h:234:
note: a type with different number of fields is defined in another translation
unit
  234 | struct GTY (()) lang_type
  |
```

[Bug rust/108087] New: -Wodr warnings in rust/rust-lang.cc (lang_type)

[sam at gentoo dot org via Gcc-bugs]

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

Bug ID: 108087
   Summary: -Wodr warnings in rust/rust-lang.cc (lang_type)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rust
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sam at gentoo dot org
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54082=edit
build.log.xz (slightly past warning)

Noticed when bootstrapping GCC 13 from trunk at r13-4681-g531ca06c007d4c.
```
/var/tmp/portage/sys-devel/gcc-13.0./work/gcc-13.0./gcc/rust/rust-lang.cc:67:17:
warning: type [-Wodr]
   67 | struct GTY (()) lang_type
  | ^
/var/tmp/portage/sys-devel/gcc-13.0./work/gcc-13.0./gcc/rust/backend/rust-tree.h:234:
note: a different type is defined in another translation unit
  234 | struct GTY (()) lang_type
  |
/var/tmp/portage/sys-devel/gcc-13.0./work/gcc-13.0./gcc/rust/backend/rust-tree.h:236:
note: the first difference of corresponding definitions is field ‘align’
  236 |   unsigned char align;
  |
/var/tmp/portage/sys-devel/gcc-13.0./work/gcc-13.0./gcc/rust/backend/rust-tree.h:234:
note: a type with different number of fields is defined in another translation
unit
  234 | struct GTY (()) lang_type
  |
```

I've attached the build.log compressed a bit past the point of the warning, as
it's still building.

Host compiler is 12.2.1_p20221210.

[Bug c++/108086] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

[jonas.keller--- via Gcc-bugs]

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

--- Comment #3 from Jonas Keller  ---
Created attachment 54081
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54081=edit
source

[Bug c++/108086] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

[jonas.keller--- via Gcc-bugs]

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

--- Comment #2 from Jonas Keller  ---
Created attachment 54080
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54080=edit
preprocessed source

[Bug c++/108086] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

[jonas.keller--- via Gcc-bugs]

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

--- Comment #1 from Jonas Keller  ---
Created attachment 54079
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54079=edit
The file generated by -freport-bug

[Bug c++/108086] New: internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

[jonas.keller--- via Gcc-bugs]

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

Bug ID: 108086
   Summary: internal compiler error: in set_accesses, at
rtl-ssa/internals.inl:449
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jonas.kel...@uni-bielefeld.de
  Target Milestone: ---

gcc Version: 12.2.0, as well as at least 5.1 until 7.4

command line that triggers the bug:
g++ -v -save-temps -freport-bug -mavx512f -O1 main.cpp

The bug also occurs with -O2 and -O3 but not with -O0.
It also does not seem to be dependend on a specific architecture, as long as
the architecture has avx512f, as the code depends on that.

The bug is present at least since gcc 5.1, as tested in compiler explorer.
I couldn't test it with newer versions than gcc 7.4, since the compilation
takes too long and is killed by compiler explorer.

The following output is generated by gcc:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-freport-bug' '-mavx512f' '-O1'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
 /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/cc1plus -E -quiet -v -D_GNU_SOURCE
main.cpp -mavx512f -mtune=generic -march=x86-64 -freport-bug -O1
-fpch-preprocess -o a-main.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../include/c++/12.2.0

/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../include/c++/12.2.0/x86_64-pc-linux-gnu

/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../include/c++/12.2.0/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-freport-bug' '-mavx512f' '-O1'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
 /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/cc1plus -fpreprocessed a-main.ii
-quiet -dumpdir a- -dumpbase main.cpp -dumpbase-ext .cpp -mavx512f
-mtune=generic -march=x86-64 -O1 -version -freport-bug -o a-main.s
GNU C++17 (GCC) version 12.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.25-GMP

warning: MPFR header version 4.1.0-p13 differs from library version 4.1.1-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (GCC) version 12.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.25-GMP

warning: MPFR header version 4.1.0-p13 differs from library version 4.1.1-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 402ce889a414e2a3abbbe3146fa0a6cb
during RTL pass: fwprop1
main.cpp: In function ‘int main()’:
main.cpp:230:1: internal compiler error: in set_accesses, at
rtl-ssa/internals.inl:449
  230 | }
  | ^
0x19eab38 internal_error(char const*, ...)
???:0
0x6546f4 fancy_abort(char const*, int, char const*)
???:0
0x19f0d14
rtl_ssa::function_info::start_block(rtl_ssa::function_info::build_info&,
rtl_ssa::bb_info*)
???:0
0x19f0db3
rtl_ssa::function_info::bb_walker::before_dom_children(basic_block_def*)
???:0
0x1808697 dom_walker::walk(basic_block_def*)
???:0
0x19f1b38 rtl_ssa::function_info::process_all_blocks()
???:0
0x194bda4 rtl_ssa::function_info::function_info(function*)
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/ccDnfPKX.out file, please attach this to
your 

[Bug fortran/107423] ICE in parse_spec, at fortran/parse.cc:4017

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

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

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

https://gcc.gnu.org/g:531ca06c007d4c4d156637083dcad7f25ac8713d

commit r13-4681-g531ca06c007d4c4d156637083dcad7f25ac8713d
Author: Steve Kargl 
Date:   Mon Dec 12 21:11:07 2022 +0100

Fortran: NULL pointer dereference while parsing a function [PR107423]

gcc/fortran/ChangeLog:

PR fortran/107423
* parse.cc (parse_spec): Avoid NULL pointer dereference when
parsing
a function and an error occured.

gcc/testsuite/ChangeLog:

PR fortran/107423
* gfortran.dg/pr107423.f90: New test.

[Bug ipa/106072] [13 Regression] Bogus -Wnonnull warning breaks rust bootstrap

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

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

--- Comment #10 from Andrew Pinski  ---
The code definitely has a check for nullptr on pattern:
```
  // parse pattern (which is required)
  std::unique_ptr pattern = parse_pattern ();
  if (pattern == nullptr)
{
  // not necessarily an error
  return AST::ClosureParam::create_error ();
}

  // parse optional type of param
  std::unique_ptr type = nullptr;
  if (lexer.peek_token ()->get_id () == COLON)
{
  lexer.skip_token ();

  // parse type, which is now required
  type = parse_type ();
  if (type == nullptr)
{
  Error error (lexer.peek_token ()->get_locus (),
   "failed to parse type in closure parameter");
  add_error (std::move (error));

  // skip somewhere?
  return AST::ClosureParam::create_error ();
}
}

  return AST::ClosureParam (std::move (pattern), pattern->get_locus (),
std::move (type), std::move (outer_attrs));
```
Easy workaround is to add right before AST::CLosureParam:
rust_assert (pattern);

That should enforce the compiler to figure out that the load from pattern
unique_ptr is non-null.

[Bug ipa/106072] [13 Regression] Bogus -Wnonnull warning breaks rust bootstrap

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |ipa
 CC||marxin at gcc dot gnu.org

--- Comment #9 from Andrew Pinski  ---
#1  0x01cb4b1c in (anonymous namespace)::pass_post_ipa_warn::execute
(this=0x40ec8a0, fun=0xcd8ed910) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/tree-ssa-ccp.cc:4683
4683  if (warning_at (loc, OPT_Wnonnull,
(gdb) l
4678? EXPR_LOCATION (arg)
4679: gimple_location (stmt));
4680  auto_diagnostic_group d;
4681  if (argno == 0)
4682{
4683  if (warning_at (loc, OPT_Wnonnull,
4684  "%qs pointer is null", "this")
4685  && fndecl)
4686inform (DECL_SOURCE_LOCATION (fndecl),
4687"in a call to non-static member function
%qD",

(gdb) p debug_gimple_stmt(stmt)
# .MEM_32 = VDEF <.MEM_75>
D.1130746 = OBJ_TYPE_REF(_6;(const struct Pattern)0B->6B) (0B);
$6 = void

[Bug c++/106072] [13 Regression] Bogus -Wnonnull warning breaks rust bootstrap

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

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

--- Comment #8 from Andrew Pinski  ---
The aarch64-linux-gnu preprocessed source is attached to PR 108084 too.
The same preprocessed source does not show the issue on x86_64-linux-gnu either
.

[Bug c++/108084] AArch64 Linux bootstrap failure in rust

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
Dup of bug 106072.

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

[Bug c++/106072] [13 Regression] Bogus -Wnonnull warning breaks rust bootstrap

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

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

[Bug c++/106072] [13 Regression] Bogus -Wnonnull warning breaks rust bootstrap

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
Summary|Bogus -Wnonnull warning |[13 Regression] Bogus
   |breaks rust bootstrap   |-Wnonnull warning breaks
   ||rust bootstrap
 Target|sparc*-sun-solaris2.11  |sparc*-sun-solaris2.11
   ||aarch64-linux-gnu

--- Comment #6 from Andrew Pinski  ---
Also breaks aarch64-linux-gnu.

[Bug c++/108084] AArch64 Linux bootstrap failure in rust

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

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

--- Comment #7 from Andrew Pinski  ---
I built cc1plus on x86_64 at r13-4678-g8f4634fb82d and still not able to
reproduce it. This is a bit interesting.

[Bug c++/106072] Bogus -Wnonnull warning breaks rust bootstrap

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

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

Rainer Orth  changed:

   What|Removed |Added

Version|12.0|13.0
   Target Milestone|--- |13.0

--- Comment #5 from Rainer Orth  ---
Happens on trunk when bootstrapping with rust included.

[Bug c++/106072] Bogus -Wnonnull warning breaks rust bootstrap

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

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

--- Comment #4 from Rainer Orth  ---
With rust merged into trunk, the warning resurfaced and broke SPARC bootstrap.

[Bug c++/108084] AArch64 Linux bootstrap failure in rust

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

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

--- Comment #6 from Andrew Pinski  ---

The command line which is able to reproduce on aarch64:
../prev-gcc/cc1plus -fpreprocessed t.ii -quiet -dumpdir rust/ -dumpbase
rust-ast-full-test.cc -dumpbase-ext .cc  -g -g -gtoggle -O2 -O2 -Wextra -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wsuggest-attribute=format
-Woverloaded-virtual=2 -Wpedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -Wno-unused-parameter -version -fno-PIE
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-common
-fno-checking -o rust/rust-ast-full-test.s

But the following command line which does not produce the warning (still on
aarch64):
../prev-gcc/cc1plus t.ii -fpreprocessed -quiet -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-Wno-unused-parameter -fno-common -o t.s


Note I can't reproduce it on x86_64 with cc1plus built from
r13-4401-gf57ff189572575 .

[Bug c++/108084] AArch64 Linux bootstrap failure in rust

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 54078
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54078=edit
Preprocessed source

[Bug c++/108084] AArch64 Linux bootstrap failure in rust

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #3)
> Can you please attach preprocessed source?


I will in a few minutes.

[Bug c++/108084] AArch64 Linux bootstrap failure in rust

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Can you please attach preprocessed source?
Trying x86_64-linux bootstrap with rust now if I can trigger it there too...

[Bug c++/108084] AArch64 Linux bootstrap failure in rust

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

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

--- Comment #2 from Andrew Pinski  ---
I can reproduce the failure.
It is happening in stage 2

Command line:
/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/./prev-gcc/xg++
-B/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/./prev-gcc/
-B/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/bin/ -nostdinc++
-B/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/prev-aarch64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/prev-aarch64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/prev-aarch64-unknown-linux-gnu/libstdc++-v3/include/aarch64-unknown-linux-gnu

-I/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/prev-aarch64-unknown-linux-gnu/libstdc++-v3/include
 -I/home/ubuntu/src/upstream-gcc-aarch64/gcc/libstdc++-v3/libsupc++
-L/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/prev-aarch64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/prev-aarch64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c  -DIN_GCC_FRONTEND -g -O2 -fno-checking -gtoggle -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-Wno-unused-parameter -fno-common  -DHAVE_CONFIG_H -I. -Irust
-I/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc
-I/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust
-I/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/../include
-I/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/../libcpp/include
-I/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/../libcody 
-I/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/../libdecnumber
-I/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/../libdecnumber/bid
-I../libdecnumber
-I/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/../libbacktrace   -o
rust/rust-ast-full-test.o -MT rust/rust-ast-full-test.o -MMD -MP -MF
rust/.deps/rust-ast-full-test.TPo -g -O2 -fno-checking -gtoggle -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/lex -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/parse -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/ast -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/analysis -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/backend -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/expand -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/hir/tree -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/hir -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/resolve -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/util -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/typecheck -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/checks/lints -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/checks/errors -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/checks/errors/privacy -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/util -I
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/metadata
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/rust/ast/rust-ast-full-test.cc

Let me try to see if I can try to reduce what is going on.

[Bug sanitizer/108083] Code with memory leak does not get triggered when I run the executable

[ssofroni at cytanet dot com.cy via Gcc-bugs]

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

--- Comment #3 from stefanos  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to stefanos from comment #0)
> > With my Makefile, I generate an executable with the following steps:
> > 
> > ccache g++ -Wall -Wextra -Werror -Wpedantic -std=c++20 -g -Og
> > -D_GLIBCXX_DEBUG  -I src -c src/tmp.cpp -o obj/tmp.o
> 
> You're not compiling with sanitizers, only linking:
> 
> > ccache g++ obj/tmp.o -o bin/tmp -fno-strict-aliasing -fwrapv -lfmt -lm
> > -fsanitize=address,undefined
> 
> Your makefile is incorrect.

Even if I do so, it does not trigger the memory leak...unless I misunderstood
you.


stefanos@debian:~/code/cpp/tmp $ make
ccache g++ -Wall -Wextra -Werror -Wpedantic -std=c++20 -g -Og -D_GLIBCXX_DEBUG
-fsanitize=address,undefined  -I src -c src/tmp.cpp -o obj/tmp.o
ccache g++ obj/tmp.o -o bin/tmp -fno-strict-aliasing -fwrapv -lfmt -lm
-fsanitize=address,undefined 
make  -j4 --jobserver-auth=3,4 got executed in debug mode...
stefanos@debian:~/code/cpp/tmp $ bin/tmp 
histefanos@debian:~/code/cpp/tmp $

[Bug sanitizer/108085] New: gcc trunk's ASAN at -O3 missed a stack-use-after-scope

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 108085
   Summary: gcc trunk's ASAN at -O3 missed a stack-use-after-scope
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

For the following code, ASAN at -O3 failed to report the stack-use-after-scope,
other opt levels detected it successfully.

GCC-8 works fine. 
Clang at all optimization levels reported it.

Compiler explorer: https://godbolt.org/z/jbsThYWa6

% cat a.c
int a;
void b() {
  int c[1];
  c;
}
int main() {
  int d[1]={1};
  int *e = d;
  a = 0;
  for (; a <= 5; ++a) {
int f[1]={};
e = f;
a || (b(), 1);
  }
  return *e;
}
%
% gcc-tk -O2 -fsanitize=address -g a.c && ./a.out
=
==780198==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7f2307600030 at pc 0x004011c5 bp 0x7ffdd19ecd80 sp 0x7ffdd19ecd78
READ of size 4 at 0x7f2307600030 thread T0
#0 0x4011c4 in main /a.c:15
#1 0x7f2309f41082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x40126d in _start (/a.out+0x40126d)

Address 0x7f2307600030 is located in stack of thread T0 at offset 48 in frame
#0 0x4010bf in main /a.c:6

  This frame has 3 object(s):
[32, 36) 'd' (line 7)
[48, 52) 'f' (line 11) <== Memory access at offset 48 is inside this
variable
[64, 68) 'c' (line 3)
...
%
% gcc-tk -O3 -fsanitize=address -g a.c && ./a.out
%

[Bug tree-optimization/108064] [13 Regression] apache-arrow-cpp-9.0.0 is vectored incorrectly: arithmetic shift instead of logical

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/108064] [13 Regression] apache-arrow-cpp-9.0.0 is vectored incorrectly: arithmetic shift instead of logical

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:33be3ee36a7e2c0be383ec01b5fbc9aef39568fd

commit r13-4679-g33be3ee36a7e2c0be383ec01b5fbc9aef39568fd
Author: Jakub Jelinek 
Date:   Tue Dec 13 16:55:21 2022 +0100

vect-patterns: Fix up vect_recog_rotate_pattern [PR108064]

Since vect_recog_rotate_pattern has been extended to work also
on signed types in r13-1100 we miscompile the testcase below.
vect_recog_rotate_pattern actually emits correct scalar code into
the pattern def sequence (in particular cast to utype, doing the
2 shifts in utype so that the right shift is logical and not arithmetic,
or and then cast back to the signed type), but it didn't supply vectype
for most of those pattern statements, which means that the generic handling
fills it up later with the vectype provided by vect_recog_rotate_pattern.
The problem is that it is vectype of the result of the whole pattern,
i.e. vector of signed values in this case, while the conversion to utype,
2 shifts and or (everything with utype lhs in scalar code) should have
uvectype as STMT_VINFO_VECTYPE.

2022-12-13  Jakub Jelinek  

PR tree-optimization/108064
* tree-vect-patterns.cc (vect_recog_rotate_pattern): Pass uvectype
as 4th argument to append_pattern_def_seq for statements with lhs
with utype type.

* gcc.c-torture/execute/pr108064.c: New test.

[Bug c++/108084] AArch64 Linux bootstrap failure in rust

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|rust|c++

--- Comment #1 from Andrew Pinski  ---
This seems like a C++ front-end bug or a miscompiling of the C++ front-end.

[Bug c++/108083] Code with memory leak does not get triggered when I run the executable

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to stefanos from comment #0)
> With my Makefile, I generate an executable with the following steps:
> 
> ccache g++ -Wall -Wextra -Werror -Wpedantic -std=c++20 -g -Og
> -D_GLIBCXX_DEBUG  -I src -c src/tmp.cpp -o obj/tmp.o

You're not compiling with sanitizers, only linking:

> ccache g++ obj/tmp.o -o bin/tmp -fno-strict-aliasing -fwrapv -lfmt -lm
> -fsanitize=address,undefined

Your makefile is incorrect.

[Bug c++/85668] ICE with substitution failure

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 CC||ppalka at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #3 from Patrick Palka  ---
dup

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

[Bug c++/87844] ICE in tsubst_copy using non-constant expression as a non-type template argument

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||miguel.ojeda.sandonis@gmail
   ||.com

--- Comment #3 from Patrick Palka  ---
*** Bug 85668 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/107617] SCC-VN with len_store and big endian

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

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

--- Comment #7 from rdapp at linux dot ibm.com ---
The patch fixes the problem for me.  I did a full bootstrap with enabled
len_load support.  No new regressions with -march=arch14.  Thanks again!

[Bug rust/108084] New: AArch64 Linux bootstrap failure in rust

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

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

Bug ID: 108084
   Summary: AArch64 Linux bootstrap failure in rust
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: rust
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
CC: dkm at gcc dot gnu.org
  Target Milestone: ---
  Host: aarch64-none-linux-gnu
Target: aarch64-none-linux-gnu

Congratulations on getting the rust frontend committed!
When trying a bootstrap on aarch64-none-linux with
--enable-languages=c,c++,fortran,rust I get a -Werror=nonnull failure

In file included from $SRC/gcc/rust/parse/rust-parse.h:730,
 from $SRC/gcc/rust/expand/rust-macro-builtins.cc:25:
$SRC/gcc/rust/parse/rust-parse-impl.h: In member function
'Rust::AST::ClosureParam
Rust::Parser::parse_closure_param() [with
ManagedTokenSource = Rust::Lexer]':
$SRC/gcc/rust/parse/rust-parse-impl.h:8916:70: error: 'this' pointer is null
[-Werror=nonnull]
 8916 | std::move (type), std::move (outer_attrs));
  |  ^
In file included from $SRC/gcc/rust/parse/rust-parse.h:730,
 from $SRC/gcc/rust/expand/rust-macro-expand.h:23,
 from $SRC/gcc/rust/expand/rust-macro-expand.cc:19:
$SRC/gcc/rust/parse/rust-parse-impl.h: In member function
'Rust::AST::ClosureParam
Rust::Parser::parse_closure_param() [with
ManagedTokenSource = Rust::MacroInvocLexer]':
$SRC/gcc/rust/parse/rust-parse-impl.h:8916:70: error: 'this' pointer is null
[-Werror=nonnull]
 8916 | std::move (type), std::move (outer_attrs));
  |  ^
In file included from $SRC/gcc/rust/parse/rust-parse.h:730,
 from $SRC/gcc/rust/rust-session-manager.cc:23:
$SRC/gcc/rust/parse/rust-parse-impl.h: In member function
'Rust::AST::ClosureParam
Rust::Parser::parse_closure_param() [with
ManagedTokenSource = Rust::Lexer]':
$SRC/gcc/rust/parse/rust-parse-impl.h:8916:70: error: 'this' pointer is null
[-Werror=nonnull]
 8916 | std::move (type), std::move (outer_attrs));

[Bug c++/97837] ICE on requires with *this in destructor

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
 CC||ppalka at gcc dot gnu.org

--- Comment #4 from Patrick Palka  ---
This is basically an ICE-on-invalid version of PR99961 which has been fixed in
GCC 11.1+

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

[Bug c++/99961] requires clause rejects mentioning of function parameters too early

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||gccbugbjorn at fahller dot se

--- Comment #3 from Patrick Palka  ---
*** Bug 97837 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/105801] Missed CCP with -ftrivial-auto-var-init=zero

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Richard Biener  ---
Fixed for GCC 13.

[Bug tree-optimization/105801] Missed CCP with -ftrivial-auto-var-init=zero

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

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

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

https://gcc.gnu.org/g:8f4634fb82d5670183d0ee42de9dae3b55ab5087

commit r13-4678-g8f4634fb82d5670183d0ee42de9dae3b55ab5087
Author: Richard Biener 
Date:   Tue Dec 13 14:24:02 2022 +0100

tree-optimization/105801 - CCP and .DEFERRED_INIT

This makes sure we treat .DEFERRED_INIT as producing UNDEFINED so
we can continue optimizing uninitialized uses the same as without
-ftrivial-auto-var-init=zero.  For the testcase this means we
catch the return 1 optimization opportunity at CCP rather than
only at FRE which already does the right thing here.

PR tree-optimization/105801
* tree-ssa-ccp.cc (likely_value): .DEFERRED_INIT produces
UNDEFINED.
* doc/invoke.texi (ftrivial-auto-var-init): Explicitely
mention we treat variables without an initializer as
undefined also for optimization purposes.

* gcc.dg/tree-ssa/ssa-ccp-43.c: New testcase.

[Bug c++/108083] Code with memory leak does not get triggered when I run the executable

[ssofroni at cytanet dot com.cy via Gcc-bugs]

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

--- Comment #1 from stefanos  ---
I forgot to mention that if I try *directly* the following command

g++ -Wall -Wextra -Werror -Wpedantic -std=c++20 -g -g0
-fsanitize=address,undefined -D_GLIBCXX_DEBUG -fno-strict-aliasing -fwrapv -lm
-o tmp src/tmp.cpp

in place of Makefile, it triggers the memory leak.

[Bug rtl-optimization/90706] [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR

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

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #14 from Vladimir Makarov  ---
What I see is the input to RA was significantly changed sing gcc-8 (see
insns marked by !).  A lot of subregs is generated now and there is no
promotion of (argument) hard regs (insns 44-47) because of
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-10/msg01356.html.


1: NOTE_INSN_DELETED 1: NOTE_INSN_DELETED
4: NOTE_INSN_BASIC_BLOCK 2   4: NOTE_INSN_BASIC_BLOCK 2
2: r44:SF=r22:SF44: r56:QI=r22:QI
  REG_DEAD r22:SF  REG_DEAD r22:QI
3: NOTE_INSN_FUNCTION_BEG   45: r57:QI=r23:QI
6: r45:QI=0x1  REG_DEAD r23:QI
  REG_EQUAL 0x1 46: r58:QI=r24:QI
7: r18:SF=0.0  REG_DEAD r24:QI
!   8: r22:SF=r44:SF47: r59:QI=r25:QI
  REG_DEAD r44:SF  REG_DEAD r25:QI
9: r24:QI=call [`__gtsf2'] argc:0   48: r52:QI=r56:QI
  REG_DEAD r25:QI  REG_DEAD r56:QI
  REG_DEAD r23:QI   49: r53:QI=r57:QI
  REG_DEAD r22:QI  REG_DEAD r57:QI
  REG_DEAD r18:SF   50: r54:QI=r58:QI
  REG_CALL_DECL `__gtsf2'  REG_DEAD r58:QI
  REG_EH_REGION 0x8000  51: r55:QI=r59:QI
   10: NOTE_INSN_DELETED   REG_DEAD r59:QI
   11: cc0=cmp(r24:QI,0) 3: NOTE_INSN_FUNCTION_BEG
  REG_DEAD r24:QI6: r46:QI=0x1
   12: pc={(cc0>0)?L14:pc} REG_EQUAL 0x1
  REG_BR_PROB 633507684  7: r18:SF=0.0
   22: NOTE_INSN_BASIC_BLOCK 3!  52: clobber r60:SI
   13: r45:QI=0   !  53: r60:SI#0=r52:QI
  REG_EQUAL 0  REG_DEAD r52:QI
   14: L14:   !  54: r60:SI#1=r53:QI
   23: NOTE_INSN_BASIC_BLOCK 4 REG_DEAD r53:QI
   19: r24:QI=r45:QI  !  55: r60:SI#2=r54:QI
  REG_DEAD r45:QI  REG_DEAD r54:QI
   20: use r24:QI !  56: r60:SI#3=r55:QI
   REG_DEAD r55:QI
  !  57: r22:SF=r60:SI#0
   REG_DEAD r60:SI
 9: r24:QI=call [`__gtsf2']
argc:0
   REG_DEAD r25:QI
   REG_DEAD r23:QI
   REG_DEAD r22:QI
   REG_DEAD r18:SF
   REG_CALL_DECL `__gtsf2'
   REG_EH_REGION
0x8000
34: r50:QI=r24:QI
   REG_DEAD r24:QI
10: NOTE_INSN_DELETED
11: pc={(r50:QI>0)?L13:pc}
   REG_DEAD r50:QI
   REG_BR_PROB 633507684
21: NOTE_INSN_BASIC_BLOCK 3
12: r46:QI=0
   REG_EQUAL 0
13: L13:
22: NOTE_INSN_BASIC_BLOCK 4
18: r24:QI=r46:QI
   REG_DEAD r46:QI
19: use r24:QI

Currently, GCC generates the following AVR code:

check:
push r28
push r29
rcall .
rcall .
push __tmp_reg__
in r28,__SP_L__
in r29,__SP_H__
/* prologue: function */
/* frame size = 5 */
/* stack size = 7 */
.L__stack_usage = 7
ldi r18,lo8(1)
std Y+5,r18
ldi r18,0
ldi r19,0
ldi r20,0
ldi r21,0
!   std Y+1,r22
!   std Y+2,r23
!   std Y+3,r24
!   std Y+4,r25
!   ldd r22,Y+1

[Bug c++/108083] New: Code with memory leak does not get triggered when I run the executable

[ssofroni at cytanet dot com.cy via Gcc-bugs]

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

Bug ID: 108083
   Summary: Code with memory leak does not get triggered when I
run the executable
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ssofroni at cytanet dot com.cy
  Target Milestone: ---

I have a very weird behavior with gcc version 12.2.0 (Debian 12.2.0-9).

My code is the following:

#include 

int main()
{
[[maybe_unused]] int x{64};
std::cout << new char[]{"hi"};
return 0;
}

With my Makefile, I generate an executable with the following steps:

ccache g++ -Wall -Wextra -Werror -Wpedantic -std=c++20 -g -Og -D_GLIBCXX_DEBUG 
-I src -c src/tmp.cpp -o obj/tmp.o
ccache g++ obj/tmp.o -o bin/tmp -fno-strict-aliasing -fwrapv -lfmt -lm
-fsanitize=address,undefined

If I execute `bin/tmp`, it prints 'hi' and does not trigger the sanitizer.

If I replace `g++` to `clang++`, the generated executable triggers the
sanitizer and catches the memory leak.

Here's the output:

hi
=
==12782==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 3 byte(s) in 1 object(s) allocated from:
#0 0x55fafedff07d in operator new[](unsigned long)
(/home/stefanos/code/cpp/tmp/bin/tmp+0xdf07d) (BuildId:
0903120ed7ac810b75b124e3d84396bbe7870f32)
#1 0x55fafee0156a in main /home/stefanos/code/cpp/tmp/src/tmp.cpp:6:18

SUMMARY: AddressSanitizer: 3 byte(s) leaked in 1 allocation(s).


To make GCC catch the leak, I either have to add a newline at the end of {"hi"}
or add `std::flush;`:

stefanos@debian:~/code/cpp/tmp $ cat src/tmp.cpp 
#include 

int main()
{
[[maybe_unused]] int x{64};
std::cout << new char[]{"hi"} << '\n';
}

stefanos@debian:~/code/cpp/tmp $ make
ccache g++ -Wall -Wextra -Werror -Wpedantic -std=c++20 -g -Og -D_GLIBCXX_DEBUG 
-I src -c src/tmp.cpp -o obj/tmp.o
ccache g++ obj/tmp.o -o bin/tmp -fno-strict-aliasing -fwrapv -lfmt -lm
-fsanitize=address,undefined 
make  -j4 --jobserver-auth=3,4 got executed in debug mode...
stefanos@debian:~/code/cpp/tmp $ bin/tmp 
hi

=
==12975==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 3 byte(s) in 1 object(s) allocated from:
#0 0x7f0437de7628 in operator new[](unsigned long)
../../../../src/libsanitizer/asan/asan_new_delete.cpp:98
#1 0x556a5b56e1bc in main src/tmp.cpp:6

SUMMARY: AddressSanitizer: 3 byte(s) leaked in 1 allocation(s).

Am I doing something wrong?

[Bug tree-optimization/106514] [12/13 Regression] ranger slowness in path query

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

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

--- Comment #11 from Richard Biener  ---
(In reply to Richard Biener from comment #10)
> Re-confirmed.  =15 vs =30 goes from
> 
>  backwards jump threading   :   0.58 ( 13%)
> 
> to
> 
>  backwards jump threading   :   7.00 ( 65%)
> 
> so it still shows exponential behavior for CFGs like
> 
>  if (a)
>...
>  if (b)
>...
>  if (c)
>...
> 
> because we explore all paths through the CFG that fit in some size limit.
> I'm not sure if there's any low hanging fruit besides this (like if we
> properly avoid re-doing local computes when visiting blocks as part of a
> path multiple times).

We do have --param max-jump-thread-paths putting a hard limit on the number
of branches in a paths we explore, the default might just be a bit high
for this testcase.

[Bug tree-optimization/106514] [12/13 Regression] ranger slowness in path query

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

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

--- Comment #10 from Richard Biener  ---
Re-confirmed.  =15 vs =30 goes from

 backwards jump threading   :   0.58 ( 13%)

to

 backwards jump threading   :   7.00 ( 65%)

so it still shows exponential behavior for CFGs like

 if (a)
   ...
 if (b)
   ...
 if (c)
   ...

because we explore all paths through the CFG that fit in some size limit.
I'm not sure if there's any low hanging fruit besides this (like if we
properly avoid re-doing local computes when visiting blocks as part of a
path multiple times).

[Bug tree-optimization/108082] False Warray-bounds warning

[risto.alasaarela at nokia dot com via Gcc-bugs]

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

--- Comment #2 from Risto Alasaarela  ---
Could you please point the duplicate report?

[Bug tree-optimization/108082] False Warray-bounds warning

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |tree-optimization
 Blocks||56456
   Keywords||diagnostic
   Last reconfirmed||2022-12-13
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Without a full testcase it's hard to tell but I would guess there's partial
inlining inlining the if (num < 2) num; check so the bound isn't present
when analyzing the body.  There's a duplicate bugreport for exactly this case
btw.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug c/108079] [10/11/12/13 Regression] -Wunused-variable gives misleading duplicate warning for unused static local variable

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|-Wunused-variable gives |[10/11/12/13 Regression]
   |misleading duplicate|-Wunused-variable gives
   |warning for unused static   |misleading duplicate
   |local variable  |warning for unused static
   ||local variable
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-12-13
  Known to work||5.5.0
   Target Milestone|--- |10.5
   Priority|P3  |P2
  Known to fail||6.1.0

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug c/108082] New: False Warray-bounds warning

[risto.alasaarela at nokia dot com via Gcc-bugs]

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

Bug ID: 108082
   Summary: False Warray-bounds warning
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: risto.alasaarela at nokia dot com
  Target Milestone: ---

Code:
static inline int
count_same_evgroup(event_hdr_t *ev_hdr_tbl[], const unsigned int num)
{
if (unlikely(num < 2)) {
return num;
} else {
const em_event_group_t egrp = ev_hdr_tbl[0]->egrp;
unsigned int i = 1; /* 2nd hdr */

if (EM_EVENT_GROUP_SAFE_MODE) {
const int32_t egrp_gen = ev_hdr_tbl[0]->egrp_gen;

for (; i < num &&
 egrp == ev_hdr_tbl[i]->egrp &&
 egrp_gen == ev_hdr_tbl[i]->egrp_gen; i++)
;
} else {
for (; i < num &&
 egrp == ev_hdr_tbl[i]->egrp; i++)
;
}
return i;
}
}

Warning:
In file included from ../../src/em_include.h:115,
 from ../../src/event_machine_dispatcher.c:31:
In function 'count_same_evgroup',
inlined from 'dispatch_multi_receive' at ../../src/em_dispatcher.h:362:24,
inlined from 'dispatch_local_queues' at ../../src/em_dispatcher.h:284:4,
inlined from 'check_local_queues.part.0' at
../../src/em_dispatcher.h:316:3:
../../src/em_dispatcher.h:336:40: error: array subscript 1 is outside array
bounds of 'event_hdr_t *[1]' [-Werror=array-bounds]
  336 |  egrp == ev_hdr_tbl[i]->egrp &&

Description:
When setting the "num" parameter of the function to 1, compiler throws an
unnecessary warning, even if else branch is dedicated to handle the bigger
table indexes than 0.

[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.

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

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

--- Comment #7 from Andrew Pinski  ---
Except sprintf is 100% when used correctly. And snprintf requires just as much
audit as sprintf does really. Many people have written about this before where
using snprint just gives a false sense of security even.

[Bug tree-optimization/108076] [10/11/12 Regression] GCC with -O3 produces code which fails to link

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||13.0
Summary|[10/11/12/13 Regression]|[10/11/12 Regression] GCC
   |GCC with -O3 produces code  |with -O3 produces code
   |which fails to link |which fails to link

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

[Bug tree-optimization/108076] [10/11/12/13 Regression] GCC with -O3 produces code which fails to link

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

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

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

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

commit r13-4630-gb4fddbe9592e9feb37ce567d90af822b75995531
Author: Richard Biener 
Date:   Mon Dec 12 17:52:46 2022 +0100

tree-optimization/108076 - if-conversion and forced labels

When doing if-conversion we simply throw away labels without checking
whether they are possibly targets of non-local gotos or have their
address taken.  The following rectifies this and refuses to if-convert
such loops.

PR tree-optimization/108076
* tree-if-conv.cc (if_convertible_loop_p_1): Reject blocks
with non-local or forced labels that we later remove
labels from.

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

[Bug target/107568] Bootstrap failure on macOS 12.6 (monterey)

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

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

--- Comment #6 from Iain Sandoe  ---
since this effects upstream *-*-darwin21+ the bug is now tracked here (I've
closed the arm64 duvet branch dup)

I am considering amending the darwin host module to add
-Wno-error=deprecated-declarations to the STAGE2+ flags, rather than
fix-including.

Two reasons:
 * fixincludes make life tricky when compiling for different Darwin versions
with --sysroot (since they leak into the target runtime, esp. libstdc++
headers).  It's better to avoid them if possible

 * fixinclude-ing would make the GCC behaviour different from clang's on
end-user's code. It is clear that Apple's intention is dissuade users from the
unsafer APIs (which is reasonable, I guess, but the mechanism is a bit
heavy-handed).

anyway just thoughts at present, no draft patch yet.

[Bug tree-optimization/107828] tree-inlining would generate SSA with incorrect def stmt

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

Feng Xue  changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|WAITING

--- Comment #4 from Feng Xue  ---
(In reply to Martin Jambor from comment #2)
> I don't see any correctness issue here.  It is true that when IPA-SRA
> needs to create a temporary SSA_NAME for an assignment with
> VIEW_CONVERT_EXPR (that is the only statement that extra_stmts can
> contain at the moment), the SSA_NAME then get's re-mapped to another
> while woe could have just re-use the existing one, it is already
> created within the new function.
> 
> We could use the knowledge that extra_stmts is really only this one
> statement or nothing and avoid the remapping but that would be at the
> expense of universality and extensibility of the interface between
> tree-inline.cc and ipa-param-manipulations.cc.
> 
> Please let me know if I am missing something (and preferably with a
> test-case that demonstrates the problem).

Sorry for late response.

It is hard to compose a simple test case, since this could only be exposed with
our own private code. To reproduce it is not that straightforward, but we could
forcefully do that with a minor change to
"ipa_param_body_adjustments::modify_assignment" in ipa-param-manipulation.cc.

diff --git a/gcc/ipa-param-manipulation.cc b/gcc/ipa-param-manipulation.cc
index cee0e23f946..202c0fda32b 100644
--- a/gcc/ipa-param-manipulation.cc
+++ b/gcc/ipa-param-manipulation.cc
@@ -1787,7 +1787,7 @@ ipa_param_body_adjustments::modify_assignment (gimple
*stmt,
   any = modify_expression (lhs_p, false);
   any |= modify_expression (rhs_p, false);
   if (any
-  && !useless_type_conversion_p (TREE_TYPE (*lhs_p), TREE_TYPE (*rhs_p)))
+  && true /* !useless_type_conversion_p (TREE_TYPE (*lhs_p), TREE_TYPE
(*rhs_p)) */)
 {
   if (TREE_CODE (*rhs_p) == CONSTRUCTOR)
{
@@ -1805,7 +1805,14 @@ ipa_param_body_adjustments::modify_assignment (gimple
*stmt,
  *rhs_p);
  tree tmp = force_gimple_operand (new_rhs, extra_stmts, true,
   NULL_TREE);
- gimple_assign_set_rhs1 (stmt, tmp);
+
+ tree tmp1 = make_ssa_name (tmp);
+ gimple *copy = gimple_build_assign (tmp1, tmp);
+
+ auto gsi = gsi_last (*extra_stmts);
+ gsi_insert_after_without_update (, copy, GSI_NEW_STMT);
+
+ gimple_assign_set_rhs1 (stmt, tmp1);
}
   return true;
 }

The purpose of above code piece is to add trivial ssa copy statement to make
the below "extra_stmts" not empty:

remap_gimple_stmt()

{
  ...
  if (id->param_body_adjs)
{
  ...
  if (!gimple_seq_empty_p (extra_stmts))
{
  memset (, 0, sizeof (wi));
  wi.info = id;
  for (gimple_stmt_iterator egsi = gsi_start (extra_stmts);
   !gsi_end_p (egsi);
   gsi_next ())
walk_gimple_op (gsi_stmt (egsi), remap_gimple_op_r, );
 ^

...
}
}
   ...
}

Now, we use the case gcc.dg/ipa/ipa-sra-1.c, and option is "-O3 -flto
-fipa-sra". Trace into "remap_gimple_op_r" as above, check remapping on copy:

<&0x76c282d0> ISRA.0_1 = ISRA.0;

A new SSA name "ISRA.0_2" is created, after setting definition statement for it
via:


  if (TREE_CODE (*tp) == SSA_NAME)
{
  *tp = remap_ssa_name (*tp, id);
  *walk_subtrees = 0;
  if (is_lhs)
 SSA_NAME_DEF_STMT (*tp) = wi_p->stmt;
 ^
  return NULL;
}

Here, both "ISRA.0_1" and "ISRA.O_2" belong to same function, and point to same
def stmt.

[Bug sanitizer/108072] [13 Regression] gcc/libbacktrace/elf.c:5144: multiple definition of `backtrace_uncompress_zstd' with --with-build-config=bootstrap-asan since r13-4547-g9df1ba9a35b86e

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:0a43f7b1a73c8e3b9cefffe430274d0a3d6d3291

commit r13-4629-g0a43f7b1a73c8e3b9cefffe430274d0a3d6d3291
Author: Jakub Jelinek 
Date:   Tue Dec 13 10:30:36 2022 +0100

libsanitizer: Fix up libbacktrace build after r13-4547 [PR108072]

The r13-4547 commit added new non-static function to libbacktrace:
backtrace_uncompress_zstd but for the libsanitizer use we need to
rename it, so that it is in __asan_* namespace and doesn't clash
with other copies of libbacktrace.

2022-12-13  Jakub Jelinek  

libsanitizer/
PR sanitizer/108072
* libbacktrace/backtrace-rename.h (backtrace_uncompress_zstd):
Define.

[Bug c++/108077] [13 Regression] Can't brace initialize container of llvm::opt::OptSpecifier

[romain.geissler at amadeus dot com via Gcc-bugs]

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

Romain Geissler  changed:

   What|Removed |Added

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

--- Comment #2 from Romain Geissler  ---
Indeed this is working now after Jason reverted his commit as mentioned in Bug
108071.

I close this ticket.

[Bug target/108081] -O0 leads to R_MIPS_TLS_GD error

[malat at debian dot org via Gcc-bugs]

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

--- Comment #3 from Mathieu Malaterre  ---
> 11956#c6
> [...]
> -mxgot might help,

Pay attention that my bug report is about `R_MIPS_TLS_GD` and not
`R_MIPS_CALL16` which indeed can be fixed by `-mxgot`

[Bug target/108081] -O0 leads to R_MIPS_TLS_GD error

[malat at debian dot org via Gcc-bugs]

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

Mathieu Malaterre  changed:

   What|Removed |Added

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

--- Comment #2 from Mathieu Malaterre  ---
> There is nothing GCC can do here. Especially at -O0.

How do you explain that symptoms disappear at -O1 ?

[Bug target/108081] -O0 leads to R_MIPS_TLS_GD error

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
https://sourceware.org/bugzilla/show_bug.cgi?id=11956

There is nothing GCC can do here. Especially at -O0.

[Bug c++/108081] New: -O0 leads to R_MIPS_TLS_GD error

[malat at debian dot org via Gcc-bugs]

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

Bug ID: 108081
   Summary: -O0 leads to R_MIPS_TLS_GD error
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: malat at debian dot org
  Target Milestone: ---

Looks like -O0 leads to some kind of `R_MIPS_TLS_GD` error on mipsel.

See for example:

*
https://buildd.debian.org/status/fetch.php?pkg=openvdb=mipsel=10.0.0-13=1670656059=0


/usr/bin/c++ -fPIC -g0 -O0 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security --param
ggc-min-expand=10 -mxgot -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro
-Wl,-z,now -Wl,--no-keep-memory -Wl,--reduce-memory-overhead -shared
-Wl,-soname,libopenvdb.so.10.0 -o libopenvdb.so.10.0.0
CMakeFiles/openvdb_shared.dir/Grid.cc.o
CMakeFiles/openvdb_shared.dir/io/Archive.cc.o
CMakeFiles/openvdb_shared.dir/io/Compression.cc.o
CMakeFiles/openvdb_shared.dir/io/DelayedLoadMetadata.cc.o
CMakeFiles/openvdb_shared.dir/io/File.cc.o
CMakeFiles/openvdb_shared.dir/io/GridDescriptor.cc.o
CMakeFiles/openvdb_shared.dir/io/Queue.cc.o
CMakeFiles/openvdb_shared.dir/io/Stream.cc.o
CMakeFiles/openvdb_shared.dir/io/TempFile.cc.o
CMakeFiles/openvdb_shared.dir/math/Half.cc.o
CMakeFiles/openvdb_shared.dir/math/Maps.cc.o
CMakeFiles/openvdb_shared.dir/math/Proximity.cc.o
CMakeFiles/openvdb_shared.dir/math/QuantizedUnitVec.cc.o
CMakeFiles/openvdb_shared.dir/math/Transform.cc.o
CMakeFiles/openvdb_shared.dir/Metadata.cc.o
CMakeFiles/openvdb_shared.dir/MetaMap.cc.o
CMakeFiles/openvdb_shared.dir/openvdb.cc.o
CMakeFiles/openvdb_shared.dir/Platform.cc.o
CMakeFiles/openvdb_shared.dir/points/AttributeArray.cc.o
CMakeFiles/openvdb_shared.dir/points/AttributeArrayString.cc.o
CMakeFiles/openvdb_shared.dir/points/AttributeGroup.cc.o
CMakeFiles/openvdb_shared.dir/points/AttributeSet.cc.o
CMakeFiles/openvdb_shared.dir/points/StreamCompression.cc.o
CMakeFiles/openvdb_shared.dir/points/points.cc.o
CMakeFiles/openvdb_shared.dir/util/Formats.cc.o
CMakeFiles/openvdb_shared.dir/util/Util.cc.o 
/usr/lib/mipsel-linux-gnu/libImath-3_1.so.29.4.0
/usr/lib/mipsel-linux-gnu/libtbb.so /usr/lib/mipsel-linux-gnu/liblog4cplus.so
/usr/lib/mipsel-linux-gnu/libblosc.so /usr/lib/mipsel-linux-gnu/libz.so
-latomic /usr/lib/mipsel-linux-gnu/libboost_iostreams.so.1.74.0 -lm 
CMakeFiles/openvdb_shared.dir/openvdb.cc.o: in function
`std::once_flag::_Prepare_execution::_Prepare_execution, 3u>, 4u>, 5u> > >::treeType()::{lambda()#1}>(std::once_flag&,
openvdb::v10_0::tree::Tree, 3u>, 4u>, 5u> >
>::treeType()::{lambda()#1}&&)::{lambda()#1}>(openvdb::v10_0::tree::Tree, 3u>, 4u>, 5u> >
>::treeType()::{lambda()#1}&)::{lambda()#1}::operator()() const':
openvdb.cc:(.text._ZZNSt9once_flag18_Prepare_executionC4IZSt9call_onceIZN7openvdb5v10_04tree4TreeINS5_8RootNodeINS5_12InternalNodeINS8_INS4_5tools18PointIndexLeafNodeINS4_10PointIndexIjLj0EEELj3EEELj4EEELj5EE8treeTypeEvEUlvE_JEEvRS_OT_DpOT0_EUlvE_EERSK_ENKUlvE_clEv[_ZZNSt9once_flag18_Prepare_executionC4IZSt9call_onceIZN7openvdb5v10_04tree4TreeINS5_8RootNodeINS5_12InternalNodeINS8_INS4_5tools18PointIndexLeafNodeINS4_10PointIndexIjLj0EEELj3EEELj4EEELj5EE8treeTypeEvEUlvE_JEEvRS_OT_DpOT0_EUlvE_EERSK_ENKUlvE_clEv]+0x30):
relocation truncated to fit: R_MIPS_TLS_GD against
`std::__once_callable@@GLIBCXX_3.4.11'
CMakeFiles/openvdb_shared.dir/openvdb.cc.o: in function
`std::once_flag::_Prepare_execution::_Prepare_execution, 3u>, 4u>, 5u> > >::treeType()::{lambda()#1}>(std::once_flag&,
openvdb::v10_0::tree::Tree, 3u>, 4u>, 5u> >
>::treeType()::{lambda()#1}&&)::{lambda()#1}>(openvdb::v10_0::tree::Tree, 3u>, 4u>, 5u> > >::treeType()::{lambda()#1}&)':
openvdb.cc:(.text._ZNSt9once_flag18_Prepare_executionC2IZSt9call_onceIZN7openvdb5v10_04tree4TreeINS5_8RootNodeINS5_12InternalNodeINS8_INS4_5tools18PointIndexLeafNodeINS4_10PointIndexIjLj0EEELj3EEELj4EEELj5EE8treeTypeEvEUlvE_JEEvRS_OT_DpOT0_EUlvE_EERSK_[_ZNSt9once_flag18_Prepare_executionC5IZSt9call_onceIZN7openvdb5v10_04tree4TreeINS5_8RootNodeINS5_12InternalNodeINS8_INS4_5tools18PointIndexLeafNodeINS4_10PointIndexIjLj0EEELj3EEELj4EEELj5EE8treeTypeEvEUlvE_JEEvRS_OT_DpOT0_EUlvE_EERSK_]+0x70):
relocation truncated to fit: R_MIPS_TLS_GD against
`std::__once_callable@@GLIBCXX_3.4.11'
openvdb.cc:(.text._ZNSt9once_flag18_Prepare_executionC2IZSt9call_onceIZN7openvdb5v10_04tree4TreeINS5_8RootNodeINS5_12InternalNodeINS8_INS4_5tools18PointIndexLeafNodeINS4_10PointIndexIjLj0EEELj3EEELj4EEELj5EE8treeTypeEvEUlvE_JEEvRS_OT_DpOT0_EUlvE_EERSK_[_ZNSt9once_flag18_Prepare_executionC5IZSt9call_onceIZN7openvdb5v10_04tree4TreeINS5_8RootNodeINS5_12InternalNodeINS8_INS4_5tools18PointIndexLeafNodeINS4_10PointIndexIjLj0EEELj3EEELj4EEELj5EE8treeTypeEvEUlvE_JEEvRS_OT_DpOT0_EUlvE_EERSK_]+0xbc):
relocation truncated to fit: R_MIPS_TLS_GD against
`std::__once_call@@GLIBCXX_3.4.11'