[Bug sanitizer/98669] SIGSEGV on pc=0 in crypt() with -fsanitize=address

[asn at samba dot org via Gcc-bugs]

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

Andreas Schneider  changed:

   What|Removed |Added

 CC||asn at samba dot org

--- Comment #14 from Andreas Schneider  ---
I've run into this with a python script:

==9542==AddressSanitizer: failed to intercept 'crypt'
==9542==AddressSanitizer: failed to intercept 'crypt_r'

[..]

AddressSanitizer:DEADLYSIGNAL
=
==29768==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x bp 0x7ffcec4bf3c0 sp 0x7ffcec4beb58 T0)
==29768==Hint: pc points to the zero page.
==29768==The signal is caused by a READ memory access.
==29768==Hint: address points to the zero page.
#0 0x0  ()
#1 0x7f052cca4129 in crypt_crypt_impl
/usr/src/debug/python310-core-3.10.6-3.1.x86_64/Modules/_cryptmodule.c:44

In case someone runs into this as well. You can fix it by preloading
libcrypt.so.1!

[Bug analyzer/106845] New: [13 Regression] ICE in exceeds_p, at analyzer/store.cc:464

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 106845
   Summary: [13 Regression] ICE in exceeds_p, at
analyzer/store.cc:464
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: tlange at gcc dot gnu.org
  Target Milestone: ---

gcc 13.0.0 20220904 snapshot (g:20d30e737ad79dc36817e59f1676aa8bc0c6b325) ICEs
when compiling the following testcase w/ -fanalyzer:

int buf_size;

int
main (void)
{
  char buf[buf_size];

  __builtin_memset (&buf[1], 0, buf_size);

  return 0;
}

% gcc-13.0.0 -fanalyzer -c vuqxegnn.c
during IPA pass: analyzer
vuqxegnn.c: In function 'main':
vuqxegnn.c:8:3: internal compiler error: in exceeds_p, at analyzer/store.cc:464
8 |   __builtin_memset (&buf[1], 0, buf_size);
  |   ^~~
0x7cd727 ana::byte_range::exceeds_p(ana::byte_range const&, ana::byte_range*)
const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/analyzer/store.cc:464
0x12d8d97 ana::region_model::check_region_bounds(ana::region const*,
ana::access_direction, ana::region_model_context*) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/analyzer/region-model.cc:1658
0x12d9121 ana::region_model::check_region_access(ana::region const*,
ana::access_direction, ana::region_model_context*) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/analyzer/region-model.cc:3234
0x12d9121 ana::region_model::check_region_for_write(ana::region const*,
ana::region_model_context*) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/analyzer/region-model.cc:3255
0x12f03e8 ana::region_model::impl_call_memset(ana::call_details const&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/analyzer/region-model-impl-calls.cc:548
0x12debc0 ana::region_model::on_call_pre(gcall const*,
ana::region_model_context*, bool*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/analyzer/region-model.cc:1953
0x12e9a12 ana::region_model::on_stmt_pre(gimple const*, bool*, bool*,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/analyzer/region-model.cc:1257
0x12b5878 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*,
ana::path_context*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/analyzer/engine.cc:1430
0x12b871f ana::exploded_graph::process_node(ana::exploded_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/analyzer/engine.cc:3868
0x12b974a ana::exploded_graph::process_worklist()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/analyzer/engine.cc:3271
0x12bbe3c ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/analyzer/engine.cc:5912
0x12bce8e ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/analyzer/engine.cc:5986
0x12abdf8 execute
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/analyzer/analyzer-pass.cc:87

[Bug c/106836] [13 Regression] ICE in c_omp_split_clauses, at c-family/c-omp.cc:2636 since r13-2388-ga651e6d59188da89

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug preprocessor/106840] [13 Regression] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
Summary|glibc master build failure  |[13 Regression] glibc
   |on ppc64le-linux-gnu since  |master build failure on
   |r13-2212-geb4879ab905308|ppc64le-linux-gnu since
   ||r13-2212-geb4879ab905308

--- Comment #4 from Richard Biener  ---
Btw, why does this C++ feature affect assembler source?  The invocation
specifies -std=gnu11 so I would have expected the preprocessor to be set up in
"C mode"?

[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests

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

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

--- Comment #17 from Christophe Lyon  ---
I think Torbjorn is right, at the fix seems as simple as handling "-T" the same
as "-Xlinker" in gcc_adjust_linker_flags_list.

However, looking at the GCC documentation, under "Linker Options", I noticed:
-e entry
-u symbol
-z keyword
where although it is unlikely that 'entry', 'symbol' or 'keyword' actually
return true to [file isfile $opt], there's still a possibility that someone
uses e.g. -e file.o :-(

[Bug lto/91299] [10/11/12/13 Regression] LTO inlines a weak definition in presence of a non-weak definition from an ELF file

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

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

Alexander Monakov  changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|LTO inlines a weak  |[10/11/12/13 Regression]
   |definition in presence of a |LTO inlines a weak
   |non-weak definition from an |definition in presence of a
   |ELF file|non-weak definition from an
   ||ELF file

--- Comment #14 from Alexander Monakov  ---
gcc-4.9 used to get this right, so let's play the regression card? This should
not be in WAITING.

[Bug preprocessor/106840] [13 Regression] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308

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

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

--- Comment #5 from Jakub Jelinek  ---
It is treated as an extension even for C and older C++.
But given the discussions Joseph started, the above patch changes it such that
it only will be recognized as an extension outside of string/character literals
if it starts with \N{ rather than just \N and only in the non-standard modes
(-std=gnu*) except for -std=c++2{3,b}.
So \NARG will be handled as before without any diagnostics...

[Bug c/106836] [13 Regression] ICE in c_omp_split_clauses, at c-family/c-omp.cc:2636 since r13-2388-ga651e6d59188da89

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

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

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

https://gcc.gnu.org/g:1bf8b7adc2de6f2ddaffa3af131b6855ae3e3793

commit r13-2489-g1bf8b7adc2de6f2ddaffa3af131b6855ae3e3793
Author: Jakub Jelinek 
Date:   Tue Sep 6 09:21:10 2022 +0200

openmp: Fix ICE when splitting invalid depend(source)/depend(sink:vec)

As we now create OMP_CLAUSE_DOACROSS rather than OMP_CLAUSE_DEPEND when
depend is used with source/sink modifiers, c_omp_split_clauses can see
OMP_CLAUSE_DOACROSS clause too before we diagnose it as erroneous.

The following patch treats it like OMP_CLAUSE_DEPEND during
the splitting but adds an assertion.

2022-09-06  Jakub Jelinek  

PR c/106836
* c-omp.cc (c_omp_split_clauses): Handle OMP_CLAUSE_DOACROSS.

* c-c++-common/gomp/pr106836.c: New test.

[Bug fortran/106846] New: [OpenMP][5.1] Permit 'declare target' with clauses inside INTERFACE

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

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

Bug ID: 106846
   Summary: [OpenMP][5.1] Permit 'declare target' with clauses
inside INTERFACE
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: openmp, rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

This is target_task_reduction.1.f90 from the OpenMP examples document; it is
5.2 (due to 'enter') but it applies already to 5.1:

   interface
  subroutine device_compute(res)
  !$omp declare target enter(device_compute)
integer :: res
  end subroutine device_compute
  ! ...
   end interface

is rejected with:
  Error: Only the !$OMP DECLARE TARGET form without clauses is allowed in
 interface block at (1)

That's based on OpenMP 5.0's
• Any declare target directive with clauses must appear in a specification part
of a
  subroutine subprogram, function subprogram, program or module.
• Any declare target directive without clauses must appear in a specification
part of a
  subroutine subprogram, function subprogram or interface body to which it
applies.

However, that is gone with OpenMP 5.1 and later.

[Bug c/106836] [13 Regression] ICE in c_omp_split_clauses, at c-family/c-omp.cc:2636 since r13-2388-ga651e6d59188da89

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Should be fixed now.

[Bug preprocessor/106840] [13 Regression] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #6 from Martin Liška  ---
Apparently, Joseph noticed that before at the mailing list where the patch was
discussed.

[Bug c++/106841] [12/13 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1509 since r12-2733-g31855ba6b16cd138

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
The issue seems to be that we get

t.ii:40:17: note:   vect_recog_widen_mult_pattern: detected: _56 = _55 * 8;
t.ii:40:17: note:   widen_mult pattern recognized: patt_36 = (long unsigned
int) patt_38;
t.ii:40:17: note:   extra pattern stmt: patt_38 = _76 w* 8;
...
t.ii:40:17: note:  -->vectorizing statement: _55 = (long unsigned int) _76;
t.ii:40:17: note:  -->vectorizing statement: patt_63 = _76 w* 8;
t.ii:40:17: note:  transform statement.
...
t.ii:40:17: note:  -->vectorizing statement: A$z_42 = MEM[(const struct R3
&)_57].z;
t.ii:40:17: note:  multiple-types.
t.ii:40:17: note:  transform statement.
t.ii:40:17: note:  vect_is_simple_use: operand (long unsigned int) _76, type of
def: internal
t.ii:40:17: note:  vect_is_simple_use: vectype vector(2) long unsigned int
t.ii:40:17: note:  transform load. ncopies = 2
t.ii:40:17: note:  vect_get_vec_defs_for_operand: _55

and a SLP tree that seems to run into a bug with hybrid discovery:

t.ii:40:17: note:   node 0x654a7d8 (max_nunits=4, refcnt=2) vector(4) int
t.ii:40:17: note:   op template: _76 = (int) _75;
t.ii:40:17: note:   stmt 0 _76 = (int) _75;
t.ii:40:17: note:   stmt 1 _84 = (int) _83;
t.ii:40:17: note:   children 0x654a860

t.ii:40:17: note:   Processing hybrid candidate : _55 = (long unsigned int)
_76;
t.ii:40:17: note:   Marked SLP consumed stmt pure: _55 = (long unsigned int)
_76;

that is because the use of _55 is

 _56 = _55 * 8;

but that is part of a pattern that is PURE_SLP and we fail to see the
direct use in the gather since gather discovery skips this scaling stmt.

We can probably detect this after the fact but the best fix would be to
somehow mark _55 as hybrid, I'll see if I can manage to do that.

[Bug target/106339] [13 Regression] ICE in exact_div, at poly-int.h:2232

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

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

Tejas Belagod  changed:

   What|Removed |Added

 CC||belagod at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-09-06
 Status|UNCONFIRMED |NEW

--- Comment #1 from Tejas Belagod  ---
Also breaks my glibc build - ICEs with this test case reduced from
glibc/dlfcn/dlinfo.c:

/* aarch64-none-linux-gnu-gcc -march=armv8-a+sve -O2 ice.c  */
typedef long unsigned int size_t;
struct link_map
  {
size_t l_tls_modid;
  };
# 24 "dlinfo.c" 2
struct dlinfo_args
{
  void *handle;
  int request;
  void *arg;
};
void
dlinfo_doit (void *argsblock)
{
  struct dlinfo_args *const args = argsblock;
  struct link_map *l = args->handle;
  *(size_t *) args->arg = 0;
  *(size_t *) args->arg = l->l_tls_modid;
}


>From my prelimnary investigation, it looks like tree-vect-slp is trying to
build the constant vector using duplicate and interleave with 2 V1DI vectors as
with the other example posted above. I haven't dug deep enough if V1DI vectors
are the right thing to do here.

[Bug tree-optimization/106842] [12 Regression] misleading warning : iteration X invokes undefined behavior

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Keywords||missed-optimization,
   ||wrong-code

--- Comment #4 from Richard Biener  ---
Huh.

static void
infer_loop_bounds_from_signedness (class loop *loop, gimple *stmt)
{
...
  low = lower_bound_in_type (type, type);
  high = upper_bound_in_type (type, type);
  value_range r;
  get_range_query (cfun)->range_of_expr (r, def);
  if (r.kind () == VR_RANGE)
{
  low = wide_int_to_tree (type, r.lower_bound ());
  high = wide_int_to_tree (type, r.upper_bound ());
}

  record_nonwrapping_iv (loop, base, step, stmt, low, high, false, true);

and record_nonwrapping_iv verifies that the IV stays in [low, high].  So
this essentially means we are verifying range info here.  We have

# RANGE [0, 9]
k_36 = PHI 
# RANGE [1, 9]
k_20 = k_36 + 1;

note the whole code is in a if (0) guarded block and we are executing
ranger_vrp, in the substitute and fold phase (IIRC the old [E]VRP avoided
to substitute/fold in dead code regions?).

somebody needs to double-check if the range on the stmts is wrong, but
depending on how VRP propagation treats unexecutable edges it might be
GIGO anyhow.

The "missed optimization" is that substitute-and-fold considers dead
regions.  "wrong code" is because either the range is bogus or the
niter we derive from it is.

needs a second eye

[Bug tree-optimization/106842] [12/13 Regression] misleading warning : iteration X invokes undefined behavior

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[12 Regression] misleading  |[12/13 Regression]
   |warning : iteration X   |misleading warning :
   |invokes undefined behavior  |iteration X invokes
   ||undefined behavior

--- Comment #5 from Richard Biener  ---
And for sure the cited rev. doesn't fix anything, in fact it should not have
caused less threading.

[Bug tree-optimization/106844] ICE in init_use_preds, at gimple-predicate-analysis.cc:1944 since r13-2436-ge9ea2688271bd0b4

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Let me have a look.

[Bug c++/106841] [12/13 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1509 since r12-2733-g31855ba6b16cd138

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

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

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

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

commit r13-2492-ge33e61d417eb5e981bb7d709f8681a2f55ed518a
Author: Richard Biener 
Date:   Tue Sep 6 10:08:44 2022 +0200

tree-optimization/106841 - gather and hybrid SLP

Hybrid SLP detection currently fails to consider a not direct
offset operand of a scatter/gather operation.  The following fixes
this.

PR tree-optimization/106841
* tree-vect-slp.cc (vect_detect_hybrid_slp): Also process
scatter/gather offset.

* g++.dg/vect/pr106841.cc: New testcase.

[Bug analyzer/106845] [13 Regression] ICE in exceeds_p, at analyzer/store.cc:464 since r13-2029-g7e3b45befdbbf1a1

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-09-06
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|[13 Regression] ICE in  |[13 Regression] ICE in
   |exceeds_p, at   |exceeds_p, at
   |analyzer/store.cc:464   |analyzer/store.cc:464 since
   ||r13-2029-g7e3b45befdbbf1a1

--- Comment #1 from Martin Liška  ---
Started with r13-2029-g7e3b45befdbbf1a1.

[Bug c++/106841] [12 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1509 since r12-2733-g31855ba6b16cd138

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[12/13 Regression] ICE in   |[12 Regression] ICE in
   |vect_get_vec_defs_for_opera |vect_get_vec_defs_for_opera
   |nd, at  |nd, at
   |tree-vect-stmts.cc:1509 |tree-vect-stmts.cc:1509
   |since   |since
   |r12-2733-g31855ba6b16cd138  |r12-2733-g31855ba6b16cd138
  Known to fail||12.2.0
   Priority|P3  |P2
  Known to work||13.0

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

[Bug c++/106837] False compilation error "inconsistent begin/end types in range-based 'for' statement"

[ofekshilon at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Ofek Shilon  ---
This can be tested empirically. Remove the entire build_x_binary_op check,
build gcc and run on this snippet. If it builds correctly than the begin/end
types are indeed comparable and the emitted error is false.

[Bug analyzer/106845] [13 Regression] ICE in exceeds_p, at analyzer/store.cc:464 since r13-2029-g7e3b45befdbbf1a1

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/106844] ICE in init_use_preds, at gimple-predicate-analysis.cc:1944 since r13-2436-ge9ea2688271bd0b4

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

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

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

https://gcc.gnu.org/g:1a4e1425f8498580994e32ceb3c50bd52616a82d

commit r13-2493-g1a4e1425f8498580994e32ceb3c50bd52616a82d
Author: Richard Biener 
Date:   Tue Sep 6 10:42:50 2022 +0200

tree-optimization/106844 - fix ICE in init_use_preds

The following fixes an oversight in the last change to
compute_control_dep_chain where we have to return whether we found
a chain.

PR tree-optimization/106844
* gimple-predicate-analysis.cc (compute_control_dep_chain):
Return whether we found a chain.

* gcc.dg/pr106844.c: New testcase.

[Bug tree-optimization/106844] ICE in init_use_preds, at gimple-predicate-analysis.cc:1944 since r13-2436-ge9ea2688271bd0b4

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/106827] operator++ doesn't work for enum -O2 -mcpu=cortex-m0plus

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

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

--- Comment #8 from Richard Earnshaw  ---
That's C++ for you, it permits you to overload operators in completely
meaningless ways.

[Bug c++/106838] Built-in traits have wrong preconditions

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> All traits of kind C currently reject T[] and T[1], but should accept them.

Gah, they do in gcc-12, but not trunk, sorry.

But they do reject incomplete unions, which should be accepted.

And traits of kind A incorrectly allow Incomplete[1].

And traits of kind B incorrectly allow Incomplete[].


Here's a testcase:

struct I;

// A.
// "T shall be a complete type, (possibly cv-qualified) void,"
// "or an array of unknown bound."

void kindA()
{
  // No incomplete object types.
  (void) __is_constructible(I); // { dg-error "incomplete type" "FAILS" }
  (void) __is_constructible(I[1]); // { dg-error "incomplete type" "FAILS" }
  // Except arrays of unknown bound.
  (void) __is_constructible(I[]);
}

// B.
// "remove_all_extents_t shall be a complete type or cv void."

void kindB()
{
  // No incomplete types, including arrays.
  (void) __is_trivial(I); // { dg-error "incomplete type" }
  (void) __is_trivial(I[1]); // { dg-error "incomplete type" }
  (void) __is_trivial(I[]); // { dg-error "incomplete type" "FAILS" }
}

union U;

// C.
// "If T is a non-union class type, T shall be a complete type."

void kindC()
{
  // No incomplete non-union class types.
  (void) __is_empty(I); // { dg-error "incomplete type" }
  // But arrays of incomplete type are OK.
  (void) __is_empty(I[1]); // { dg-bogus "incomplete type" "FAILS" }
  (void) __is_empty(I[]);
  // And incomplete unions are OK.
  (void) __is_empty(U); // { dg-bogus "incomplete type" "FAILS" }
  (void) __is_empty(U[1]); // { dg-bogus "incomplete type" "FAILS" }
  (void) __is_empty(U[]);
}

The dg-error lines marked FAIL are incorrectly accepted. The dg-bogus lines are
incorrectly rejected.

[Bug c++/106838] Built-in traits have wrong preconditions

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #5)
>   (void) __is_trivial(I[]); // { dg-error "incomplete type" "FAILS" }

This gives an error in gcc-12, so is a regression.

But gcc-12 also gives additional bogus errors, so overall trunk is closer to
being right. But still not right.

[Bug c++/106847] New: deprecated class data member makes the class generate diagnostics even when the member is not used

[avi at scylladb dot com via Gcc-bugs]

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

Bug ID: 106847
   Summary: deprecated class data member makes the class generate
diagnostics even when the member is not used
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: avi at scylladb dot com
  Target Milestone: ---

A class with a deprecated member:

struct foo {
[[deprecated]] bool x;
};

Cannot be used without lots of noise from the compiler:

foo make_a_foo() {
foo f;
return f;
}

: In function 'foo make_a_foo()':
:10:12: warning: 'f' is used uninitialized [-Wuninitialized]
   10 | return f;
  |^
:9:9: note: 'f' declared here
9 | foo f;
  | ^
Compiler returned: 0


Although I didn't touch x, the compiler thinks I did. IMO synthesized
constructors (and assignment operators) should suppress the warning and only
explicit access by the user should trigger the warning.

[Bug c++/106847] deprecated class data member makes the class generate diagnostics even when the member is not used

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #1 from Avi Kivity  ---
Clang equivalent: https://github.com/llvm/llvm-project/issues/55774

[Bug c++/106838] Built-in traits have wrong preconditions

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

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

--- Comment #7 from Jonathan Wakely  ---
Oh, and actually __is_final is a fourth kind:

// D.
// "If T is a class type, T shall be a complete type."

So the same as C, but doesn't allow incomplete unions.

[Bug c++/106838] Built-in traits have wrong preconditions

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Last reconfirmed||2022-09-06

--- Comment #8 from Jonathan Wakely  ---
Created attachment 53543
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53543&action=edit
c++: Fix type completeness checks for type traits [PR106838]

Untested patch

[Bug libstdc++/103382] condition_variable::wait() is not cancellable because it is marked noexcept

[vanyacpp at gmail dot com via Gcc-bugs]

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

Ivan Sorokin  changed:

   What|Removed |Added

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

--- Comment #7 from Ivan Sorokin  ---
As the bug is fixed I'm closing the issue.

[Bug libstdc++/103382] condition_variable::wait() is not cancellable because it is marked noexcept

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Resolution|FIXED   |---
 Status|RESOLVED|ASSIGNED

--- Comment #8 from Jonathan Wakely  ---
As I said in comment 6, we might want to disable cancellation in the release
branches.

[Bug tree-optimization/106754] compute_control_dep_chain over-estimates domain

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

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

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

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

commit r13-2500-g0a4a2667dc115ca73b552fcabf8570620dfbe55f
Author: Richard Biener 
Date:   Tue Sep 6 13:46:00 2022 +0200

tree-optimization/106754 - fix compute_control_dep_chain defect

The following handles the situation of a loop exit along the
control path to the PHI def or from there to the use in a different
way, aoviding premature abort of the walks as noticed in the two
cases where the exit is outermost (gcc.dg/uninit-pred-11.c) or
wrapped in a condition that is on the path (gcc.dg/uninit-pred-12.c).
Instead of handling such exits during recursion we now pick them
up in the parent when walking post-dominators.  That requires an
additional post-dominator walk at the outermost level which is
facilitated by splitting out the walk to a helper function and
the existing wrapper added earlier.

The patch also removes the bogus early exit from
uninit_analysis::init_use_preds, fixing a simplified version
of the PR106155 testcase.

PR tree-optimization/106754
* gimple-predicate-analysis.cc (compute_control_dep_chain_pdom):
New function, split out from compute_control_dep_chain.  Handle
loop-exit like conditions here by pushing to the control vector.
(compute_control_dep_chain): Adjust and streamline dumping.
In the wrapper perform a post-dominator walk as well.
(uninit_analysis::init_use_preds): Remove premature early exit.

* gcc.dg/uninit-pred-12.c: New testcase.
* gcc.dg/uninit-pr106155-1.c: Likewise.

[Bug tree-optimization/106754] compute_control_dep_chain over-estimates domain

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
  Known to work||13.0

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

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 106754 Summary: compute_control_dep_chain over-estimates domain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106754

   What|Removed |Added

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

[Bug tree-optimization/106155] [12/13 Regression] spurious "may be used uninitialized" warning

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

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

--- Comment #7 from Richard Biener  ---
This should now be fixed up to the confusion due to IVOPTs.  As said the
narrowing is problematic here :/

[Bug tree-optimization/106155] [12/13 Regression] spurious "may be used uninitialized" warning

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

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

--- Comment #8 from Richard Biener  ---
The following variant warns with all GCC releases I tested (and -fno-ivopts
fixes it), not exposing a mitigating jump threading opportunity:

int *e;
int f1 (void);
void f2 (int);
long f3 (void *, long, int *);
void f4 (void *);
int *fh;

void tst (void)
{
  int status;
  unsigned char badData[5][5] = { { 7 }, { 16 }, { 23 } };
  int badDataSize[5] = { 1, 1, 1 };
  int i;

  for (i = 0; i < 5; i++)
{
  int emax;
  if (i == 2)
emax = f1 ();
  status = f3 (&badData[i][0], badDataSize[i], fh);
  if (status)
{
  f1 ();
  f1 ();
  f1 ();
}
  f4 (fh);
  *e = 0;
  f1 ();
  if (i >= 2)
f2 (emax);
}
}

[Bug tree-optimization/106155] [12/13 Regression] spurious "may be used uninitialized" warning

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

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

--- Comment #9 from Richard Biener  ---
This is another example where when doing PHI chaining, we fail to consider the
use predicate of the PHI operand in the final PHI which has now no further
guard before the use.

[Bug c++/106829] [12/13 Regression] OpenMP offload internal compiler error: in gimplify_expr, at gimplify.cc:16222 since r12-5835

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 53544
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53544&action=edit
gcc13-pr106829.patch

Untested fix.

[Bug target/99555] [OpenMP/nvptx] Execution-time hang for simple nested OpenMP 'target'/'parallel'/'task' constructs

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

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

--- Comment #17 from Tom de Vries  ---
(In reply to Thomas Schwinge from comment #14)
> > That's with a Nvidia Tesla K20c GPU, Driver Version: 346.46.
> > As that version is "a bit old", I shall first update this, before we spend
> > any further time on analyzing this.
> 
> Cross-checking on another system with Nvidia Tesla K20c GPU but more recent
> Driver Version I'm not seeing such an issue.
> 
> On the "old" system, gradually upgrading Driver Version: 346.46 to 352.99,
> 361.93.02, 375.88 (always the latest (?) version of the respective series),
> these all did not resolve the problem.
> 
> Only starting with 384.59 (that is, early version of the 384.X series), that
> then did resolve the issue.  That's still using the GCC/nvptx '-mptx=3.1'
> multilib.
> 
> (We couldn't with earlier series, but given this is 384.X, we may now also
> cross-check with the default multilib, and that also was fine.)
> 
> Now, I don't know if at all we would like to spend any more effort on this
> issue, given that it only appears with rather old pre-384.X versions -- but
> on the other hand, the GCC/nvptx '-mptx=3.1' multilib is meant to keep these
> supported?  (... which is why I'm running such testing; and certainly the
> timeouts are annoying there.)
> 
> It might be another issue with pre-384.X versions of the Nvidia PTX JIT, or
> is there the slight possibility that GCC is generating/libgomp contains some
> "weird" code that post-384.X version happen to "fix up" -- probably the
> former rather than the latter?  (Or, the chance of GPU hardware/firmware or
> some other system weirdness -- unlikely, otherwise behaves totally fine?)
> 
> I don't know where to find complete Nvidia Driver/JIT release notes, where
> the 375.X -> 384.X notes might provide an idea of what got fixed, and we
> might then add another 'WORKAROUND_PTXJIT_BUG' for that -- maybe simple,
> maybe not.
> 
> Any thoughts, Tom?

I care about old cards, not about old drivers.  The oldest card we support is
an sm_30, and last driver series that supports that one is 470.x (and AFAIU, is
therefore supported by nvidia for that arch).

There's the legacy series, 390.x, which is the last to support fermi, but we
don't support any fermi cards or earlier.  I did do some testing with this one
for later cards, but reported issues are acknowledged but not fixed by nvidia,
so ... this is already out of scope for me.

So yeah, IWBN to come up with workarounds for various older drivers, but I'm
not investing time in that.  Is there a problem for you to move to 470.x or
later (515.x) ?  Is there a card for which that causes problems ?

[Bug analyzer/106845] [13 Regression] ICE in exceeds_p, at analyzer/store.cc:464 since r13-2029-g7e3b45befdbbf1a1

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

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

--- Comment #2 from David Malcolm  ---
Failing assertion here:

#1  0x014df116 in ana::byte_range::exceeds_p (this=0x7fffbf80,
other=..., out_overhanging_byte_range=0x7fffbfc0)
at ../../src/gcc/analyzer/store.cc:464
464   gcc_assert (size > 0);


(gdb) list
459 {
460   /* THIS definitely exceeds OTHER.  */
461   byte_offset_t start = MAX (get_start_byte_offset (),
462  other.get_next_byte_offset ());
463   byte_offset_t size = get_next_byte_offset () - start;
464   gcc_assert (size > 0);
465   out_overhanging_byte_range->m_start_byte_offset = start;
466   out_overhanging_byte_range->m_size_in_bytes = size;
467   return true;
468 }

where "this" and "other" are both empty, having 0 size:

(gdb) call this->dump()
bytes 1-0
(gdb) call other.dump()
bytes 0--1

due to the cst_capacity_tree in the region_model::check_region_bounds caller is
zero.

[Bug c++/106848] New: ICE when compiling module interface file with -g: error: type variant differs by TYPE_MAX_VALUE

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

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

Bug ID: 106848
   Summary: ICE when compiling module interface file with -g:
error: type variant differs by TYPE_MAX_VALUE
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 103524
  Target Milestone: ---

$ cat std.cc
export module std;

import ;


Compiling the bits/stdc++.h works OK:

$ gcc -c -std=c++23 -fmodules-ts -x c++-system-header bits/stdc++.h


And compiling the module file works without -g:

$ ~/gcc/13/bin/gcc -c -std=c++23 -fmodules-ts std.cc


But with -g there's an ICE:

$ ~/gcc/13/bin/gcc -c -std=c++23 -fmodules-ts std.cc -g
std.cc:3:24: error: type variant differs by TYPE_MAX_VALUE
3 | import ;
  |^
 
unit-size 
align:32 warn_if_not_align:0 symtab:931886976 alias-set -1
canonical-type 0x7feb3950e690 precision:32 min 
max 
pointer_to_this  reference_to_this
>
asm_written unsigned type_5 type_6 SI size 
unit-size 
align:32 warn_if_not_align:0 symtab:877031008 alias-set -1 canonical-type
0x7feb36b08bd0 precision:32 min  max 
values >
value 
readonly constant nonlocal VOID
/home/jwakely/gcc/13/include/c++/13.0.0/bits/regex_scanner.h:48:7
align:1 warn_if_not_align:0 context  initial  chain >
chain > value 
chain > value 
chain > value 
chain > value 
chain  value  chain >>
context 
chain >
 
unit-size 
align:32 warn_if_not_align:0 symtab:931886976 alias-set -1
canonical-type 0x7feb3950e690 precision:32 min 
max 
pointer_to_this  reference_to_this
>
readonly unsigned type_5 type_6 SI size 
unit-size 
align:32 warn_if_not_align:0 symtab:877078960 alias-set -1 canonical-type
0x7feb35f18540 precision:32 context 
reference_to_this >
std.cc:3:24: internal compiler error: ‘verify_type’ failed
0x149aade verify_type(tree_node const*)
/home/jwakely/src/gcc/gcc/gcc/tree.cc:14023
0xd936f3 gen_type_die_with_usage
/home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26117
0xd93a0b gen_type_die_with_usage
/home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26251
0xda82b3 gen_type_die
/home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26348
0xda82b3 gen_formal_types_die
/home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:23083
0xd8cf96 gen_subprogram_die
/home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:23927
0xd90919 gen_decl_die
/home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26964
0xd92bb5 gen_member_die
/home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:25801
0xd92bb5 gen_struct_or_union_type_die
/home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:25897
0xd92bb5 gen_tagged_type_die
/home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26098
0xd939d0 gen_tagged_type_die
/home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26052
0xd939d0 gen_type_die_with_usage
/home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26293
0xd9052b gen_type_die
/home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26348
0xd9052b gen_decl_die
/home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26987
0xd916db dwarf2out_decl
/home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:27542
0xd919d8 dwarf2out_type_decl
/home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:27260
0xd919d8 dwarf2out_type_decl
/home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:27255
0x10b94e4 rest_of_type_compilation(tree_node*, int)
/home/jwakely/src/gcc/gcc/gcc/passes.cc:339
0xaa7fc5 trees_in::read_class_def(tree_node*, tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/module.cc:12173
0xaa9b59 module_state::read_cluster(unsigned int)
/home/jwakely/src/gcc/gcc/gcc/cp/module.cc:14957
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug c++/106849] New: internal compiler error: tree check: expected none of template_decl, have template_decl in do_nonmember_using_decl, at cp/name-lookup.cc:4841

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

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

Bug ID: 106849
   Summary: internal compiler error: tree check: expected none of
template_decl, have template_decl in
do_nonmember_using_decl, at cp/name-lookup.cc:4841
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 103524
  Target Milestone: ---

I don't know if this is valid, but it shouldn't ICE:

export module lib;

namespace outer {
  template void any_of(T) { }
}

export using outer::any_of;


$ ~/gcc/13/bin/gcc -c -std=c++23 -fmodules-ts lib.cc 
lib.cc:7:21: internal compiler error: tree check: expected none of
template_decl, have template_decl in do_nonmember_using_decl, at
cp/name-lookup.cc:4841
7 | export using outer::any_of;
  | ^~
0x887d60 tree_not_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/jwakely/src/gcc/gcc/gcc/tree.cc:8864
0x6eea80 tree_not_check(tree_node*, char const*, int, char const*, tree_code)
/home/jwakely/src/gcc/gcc/gcc/tree.h:3529
0x6eea80 do_nonmember_using_decl
/home/jwakely/src/gcc/gcc/gcc/cp/name-lookup.cc:4841
0xac2676 finish_nonmember_using_decl(tree_node*, tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/name-lookup.cc:6284
0xacaf04 finish_using_decl
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:21629
0xb113ce cp_parser_using_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:21757
0xb1eba6 cp_parser_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:15099
0xb1e794 cp_parser_module_export
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:14844
0xb1e794 cp_parser_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:15040
0xb1f432 cp_parser_toplevel_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:15120
0xb1f432 cp_parser_translation_unit
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:5068
0xb1f432 c_parse_file()
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:48594
0xc57221 c_common_parse_file()
/home/jwakely/src/gcc/gcc/gcc/c-family/c-opts.cc:1255
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug c/106850] New: restrict type qualifier ignored on function return type

[colomar.6.4.3 at gmail dot com via Gcc-bugs]

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

Bug ID: 106850
   Summary: restrict type qualifier ignored on function return
type
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colomar.6.4.3 at gmail dot com
  Target Milestone: ---

Related: 

The description of the restrict qualifier would lead one to think that it can
be used as a standard way of describing a function that returns a unique
pointer, as the [[gnu::malloc]] attribute does in GNU C.

GCC currently ignores the qualifier, so it can't use it for the optimizations
that [[gnu::malloc]] allows, but if GCC didn't ignore the qualifier, it could
be used for that.

```c
#include 
#include 
#include 
#include 

[[gnu::malloc(free)]]
void *restrict
my_malloc(size_t size)
{
void *p;

p = malloc(size);  
if (!p)
err(EXIT_FAILURE, "malloc(2)");

return p;
}
```
```sh
$ cc -Wall -Wextra my_malloc.c -S
my_malloc.c:8:1: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
8 | my_malloc(size_t size)
  | ^
```

Could you please not ignore the qualifier, and treat it as synonym of
[[gnu::malloc]]?

[Bug c/106850] restrict type qualifier ignored on function return type

[colomar.6.4.3 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Alejandro Colomar  ---
The benefits are:

- It's standard.
- It's less bytes to type.

[Bug c/106850] restrict type qualifier ignored on function return type

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

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

--- Comment #2 from Andrew Pinski  ---
> It's standard.

Not really as the warning is correct qualifiers are really ignored on return
types as required by the standard.

[Bug c++/106851] New: [modules] Name conflict for exported using-declaration

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

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

Bug ID: 106851
   Summary: [modules] Name conflict for exported using-declaration
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 103524
  Target Milestone: ---

$ cat lib.h
namespace outer {
  template void any_of(T) { }

  namespace inner {
struct A { };
inline constexpr A any_of;
  }
}

$ gcc -c -std=c++23 -fmodules-ts -x c++-header lib.h


$ cat lib.cc
export module lib;

import "lib.h";

export using outer::any_of;
export using outer::inner::any_of;


$ gcc -c -std=c++23 -fmodules-ts lib.cc 
lib.cc:6:28: error: ‘constexpr const outer::inner::A outer::inner::any_of’
conflicts with a previous declaration
6 | export using outer::inner::any_of;
  |^~
In module ./lib.h, imported at lib.cc:3:
lib.h:2:29: note: previous declaration ‘void outer::any_of(T)’
2 |   template void any_of(T) { }
  | ^~
lib.cc:1:8: warning: not writing module ‘lib’ due to errors
1 | export module lib;
  |^~


The names are in different scopes, shouldn't they be exported that way too?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug libstdc++/106852] New: Implement C++23 P2465R3 Standard Library Modules std and std.compat

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

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

Bug ID: 106852
   Summary: Implement C++23 P2465R3 Standard Library Modules std
and std.compat
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Depends on: 102341
Blocks: 106749
  Target Milestone: ---

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2465r3.pdf


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102341
[Bug 102341] [modules] "error: conflicting exporting declaration" for anything
previously declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749
[Bug 106749] Implement C++23 library features

[Bug c/106850] restrict type qualifier ignored on function return type

[colomar.6.4.3 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Alejandro Colomar  ---
Ahhh, yeah, something like rvalues don't have qualifiers.  I seem to remember
now.

Maybe the standard should fix this for restrict, because things like clang's
_Nonnull would benefit from being kept in such cases.

Of course, that might complicate the compiler...

[Bug c++/106851] [modules] Name conflict for exported using-declaration

[johelegp at gmail dot com via Gcc-bugs]

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

Johel Ernesto Guerrero Peña  changed:

   What|Removed |Added

 CC||johelegp at gmail dot com

--- Comment #1 from Johel Ernesto Guerrero Peña  ---
Could https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106363 be related?

[Bug c/106853] New: compound literal storage duration

[marcelgcc at firemail dot eu via Gcc-bugs]

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

Bug ID: 106853
   Summary: compound literal storage duration
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marcelgcc at firemail dot eu
  Target Milestone: ---

According to the C Standard a compound literal has automatic storage duration.
Please, consider the following code. Note it's C code NOT C++:

% cat test.c
#include 

struct ab {
  int a, b;
} *p1, *p2;

int set_p1(struct ab *ab) {
  p1 = ab;
  return 0;
}
int set_p2(struct ab *ab) {
  p2 = ab;
  return 0;
}

int main() {

  if (0 != set_p1(&(struct ab){42, 42})) {
return 1;
  }
  set_p2(&(struct ab){46, 46});

  printf("%d, %d\n", p1->a, p1->b);
  printf("%d, %d\n", p2->a, p2->b);
  return 0;
}
/*EOF*/


# Expected Output:
% clang-15 -O1 test.c && ./a.out
42, 42
46, 46

#GCC#

% gcc-11 -O1 test.c && ./a.out 
0, 0
46, 46

% gcc-11 test.c && ./a.out
42, 42
46, 46

% gcc-12 test.c && ./a.out 
46, 46
46, 46

% gcc-12 -O1 test.c && ./a.out
-760366272, 32718
46, 46

% gcc-11 --version
gcc (Debian 11.3.0-5) 11.3.0

% gcc-12 --version 
gcc (GCC) 12.2.0

[Bug c/106853] compound literal storage duration

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---

> if (0 != set_p1(&(struct ab){42, 42}))

Yes it is auto storage and the scope is only inside the condition statement as
specified by the standard.

[Bug c/106853] compound literal storage duration

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
In C89 that would be valid scope-wise (but C89 doesn't have compound literals
on the other side), but in C99 and later compound statements like if introduce
a new block scope.  So, accessing *p1 is valid during evaluation of the if
condition or during evaluation of the substatements, but not after the compound
statement ends.  As the testcase does that, it invokes UB and anything can
happen.

[Bug c/106853] compound literal storage duration

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

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

--- Comment #3 from Andrew Pinski  ---
The important part of the standards:
6.5.2.5 Compound literals

5 The value of the compound literal is that of an unnamed object initialized by
the initializer list. If the compound literal occurs outside the body of a
function, the object has static storage duration; otherwise, it has automatic
storage duration associated with the enclosing block.

-
6.8.4 Selection statements

3 A selection statement is a block whose scope is a strict subset of the scope
of its enclosing block. Each associated substatement is also a block whose
scope is a strict subset of the scope of the selection statement.

[Bug c/106853] compound literal storage duration

[marcelgcc at firemail dot eu via Gcc-bugs]

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

--- Comment #4 from marcelgcc at firemail dot eu ---
Thanks for the explanation.

[Bug c/106854] New: [[gnu::malloc(deallocator)]] for non-pointer functions (e.g., fd)

[colomar.6.4.3 at gmail dot com via Gcc-bugs]

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

Bug ID: 106854
   Summary: [[gnu::malloc(deallocator)]] for non-pointer functions
(e.g., fd)
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colomar.6.4.3 at gmail dot com
  Target Milestone: ---

Some stuff is allocated and deallocated through non-pointer types.  Most of the
time it's file descriptors, i.e., int.

Since [[gnu::malloc(f)]] is independent of [[gnu::malloc]], it could be used
for such cases:

int close(int fd);

[[gnu::malloc(close)]]
int open(const char *pathname, int flags, ...);

Notice that [[gnu::malloc]] can't be used above.

[[gnu::malloc(f)]] has no reason to be restricted to functions returning
pointers, has it?

Could you allow using it for file descriptors?  Otherwise, a more generic
[[open(close)]] attribute might be reasonable.


Currently, it results in a warning:

$ cat fd.c && echo && cc -Wall -Wextra -S fd.c 
#include 
#include 

[[gnu::malloc(close)]]
int g(void)
{
return open("foo", O_RDONLY);
}

fd.c:6:1: warning: ‘malloc’ attribute ignored on functions returning ‘int’;
valid only for pointer return types [-Wattributes]
6 | {
  | ^

[Bug analyzer/106854] [[gnu::malloc(deallocator)]] for non-pointer functions (e.g., fd)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
  Component|c   |analyzer

--- Comment #1 from Andrew Pinski  ---
Analyzer is a better place to handle this. Maybe not with this attribute but
with a different one.

[Bug analyzer/106845] [13 Regression] ICE in exceeds_p, at analyzer/store.cc:464 since r13-2029-g7e3b45befdbbf1a1

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

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

--- Comment #3 from Tim Lange  ---
Thanks for the report!

(In reply to David Malcolm from comment #2)
> (gdb) call this->dump()
> bytes 1-0

This should be the read_bytes in region_model::check_region_bounds, with the
start being the offset and the last byte being the offset + num_bytes - 1. So
the number of accessed bytes seems to return 0.
I do use get_byte_size_sval () to retrieve the num_bytes. For the sized_region,
the m_byte_size_sval is returned, which is set to buf_size aka 0 inside
impl_call_memset. So the bug is that the caller proceeds to check for overflows
even if no bytes are accessed.

Solutions would be:
1. Bail out in the region_model::check_region_bounds if (tree_int_cst_equal
(num_bytes_tree, integer_zero_node)). Maybe also add an assertion to the
constructor of byte_range that m_size_in_bytes > 0.
2. Returning false if either THIS or OTHER has a size == 0 in
byte_range::exceeds_p and byte_range::falls_short_p.

It seems to me that the implementations of byte_range/bit_range
get_last_byte_offset () already assume that m_size_in_bytes should be greater
than zero. So I think the first one should the preferred fix.

[Bug analyzer/106845] [13 Regression] ICE in exceeds_p, at analyzer/store.cc:464 since r13-2029-g7e3b45befdbbf1a1

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

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

--- Comment #4 from David Malcolm  ---
(In reply to Tim Lange from comment #3)
> It seems to me that the implementations of byte_range/bit_range
> get_last_byte_offset () already assume that m_size_in_bytes should be
> greater than zero. So I think the first one should the preferred fix.

Sounds right to me; do you want to assign yourself this one?

[Bug analyzer/106845] [13 Regression] ICE in exceeds_p, at analyzer/store.cc:464 since r13-2029-g7e3b45befdbbf1a1

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

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

Tim Lange  changed:

   What|Removed |Added

   Assignee|dmalcolm at gcc dot gnu.org|tlange at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

[Bug analyzer/106854] [[gnu::malloc(deallocator)]] for non-pointer functions (e.g., fd)

[colomar.6.4.3 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Alejandro Colomar  ---
Also interesting might be that one function might have more than one closer.

For example, open(2) might be closed by close(2), but it is also closed by
fdopen(3), in the sense that the file descriptor can't be (safely) used again
after that, and also that it can't be passed to close(2) after that --even if
in reality the file descriptor is still valid, for obvious reasons--.

[Bug target/106834] GCC creates R_X86_64_GOTOFF64 for 4-bytes immediate

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

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

H.J. Lu  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=29551

--- Comment #11 from H.J. Lu  ---
I opened:

https://sourceware.org/bugzilla/show_bug.cgi?id=29551

[Bug c/106835] [i386] Taking an address of _GLOBAL_OFFSET_TABLE_ produces a wrong value

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

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

H.J. Lu  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=29551

--- Comment #7 from H.J. Lu  ---
(In reply to Rui Ueyama from comment #6)
> If it silently produces a value that doesn't make sense, shouldn't we ban
> the use of the variable or at least show a warning?

I opened:

https://sourceware.org/bugzilla/show_bug.cgi?id=29551

[Bug c/106830] [13 Regression] ICE: in tree_to_uhwi, at tree.cc:6392 (from check_for_xor_used_as_pow) since r13-2386-gbedfca647a9e9c1a

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Thanks for filing this; sorry about the breakage.

I'm working on a fix.

[Bug bootstrap/106855] New: [13 Regression] Removal of stabs/xcoff debugging broke bootstrap on AIX

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

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

Bug ID: 106855
   Summary: [13 Regression] Removal of stabs/xcoff debugging broke
bootstrap on AIX
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

New.

[Bug bootstrap/106855] [13 Regression] Removal of stabs/xcoff debugging broke bootstrap on AIX

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

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-09-06
 Status|UNCONFIRMED |NEW

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug bootstrap/106855] [13 Regression] Removal of stabs/xcoff debugging broke bootstrap on AIX

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

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

--- Comment #2 from David Edelsohn  ---
dwarf2out.cc uses XCOFF_DEBUGGING_INFO to emit DWARF information with XCOFF
syntax.

[Bug fortran/106856] New: [12/13 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.cc:1977

[gscfq--- via Gcc-bugs]

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

Bug ID: 106856
   Summary: [12/13 Regression] ICE in gfc_conv_expr_present, at
fortran/trans-expr.cc:1977
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20211010 and 20211017, with option -fcheck=all :


$ cat z1.f90
program p
   class(*), allocatable :: x, y
   y = 'abc'
   call s1(x, y)
contains
   subroutine s1(x, y)
  class(*) :: x, y
   end
   subroutine s2(x, y)
  class(*), allocatable :: x, y
  optional :: x
   end
end


$ gfortran-13-20220904 -c z1.f90 -fcheck=all
z1.f90:4:16:

4 |call s1(x, y)
  |1
internal compiler error: in gfc_conv_expr_present, at
fortran/trans-expr.cc:1977
0x894a80 gfc_conv_expr_present(gfc_symbol*, bool)
../../gcc/fortran/trans-expr.cc:1977
0x8a2b86 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.cc:7192
0x8e1130 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../gcc/fortran/trans-stmt.cc:422
0x867f18 trans_code
../../gcc/fortran/trans.cc:2018
0x8910ae gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7654
0x81353e translate_all_program_units
../../gcc/fortran/parse.cc:6670
0x81353e gfc_parse_file()
../../gcc/fortran/parse.cc:6976
0x860b1f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug fortran/106857] New: [10/11/12/13 Regression] ICE in gfc_simplify_pack, at fortran/simplify.cc:6438

[gscfq--- via Gcc-bugs]

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

Bug ID: 106857
   Summary: [10/11/12/13 Regression] ICE in gfc_simplify_pack, at
fortran/simplify.cc:6438
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20211003 and 20211010 :


$ cat z1.f90
program p
   type t
  integer :: n
   end type
   type(t), parameter :: a(2,2) = t(1)
   type(t), parameter :: b(4) = reshape(a, [2])
   type(t), parameter :: c(2) = pack(b, [.false.,.true.,.false.,.true.])
end


$ gfortran-12-20211003 -c z1.f90
z1.f90:6:29:

6 |type(t), parameter :: b(4) = reshape(a, [2])
  | 1
Error: Different shape for array assignment at (1) on dimension 1 (4 and 2)


$ gfortran-13-20220904 -c z1.f90
f951: internal compiler error: Segmentation fault
0xd8a29f crash_signal
../../gcc/toplev.cc:314
0x84695d gfc_simplify_pack(gfc_expr*, gfc_expr*, gfc_expr*)
../../gcc/fortran/simplify.cc:6438
0x7c2f2a do_simplify
../../gcc/fortran/intrinsic.cc:4677
0x7cde0a gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.cc:5056
0x8230c8 resolve_unknown_f
../../gcc/fortran/resolve.cc:2990
0x8230c8 resolve_function
../../gcc/fortran/resolve.cc:3347
0x8230c8 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7194
0x7b2de4 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.cc:3163
0x7b5d70 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.cc:3211
0x79ff6b variable_decl
../../gcc/fortran/decl.cc:3028
0x79ff6b gfc_match_data_decl()
../../gcc/fortran/decl.cc:6331
0x80b513 match_word
../../gcc/fortran/parse.cc:67
0x80b513 decode_statement
../../gcc/fortran/parse.cc:378
0x80cf5a next_free
../../gcc/fortran/parse.cc:1398
0x80cf5a next_statement
../../gcc/fortran/parse.cc:1630
0x80e4fb parse_spec
../../gcc/fortran/parse.cc:4169
0x8116bc parse_progunit
../../gcc/fortran/parse.cc:6211
0x812d81 gfc_parse_file()
../../gcc/fortran/parse.cc:6756
0x860b1f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug c++/106858] New: [12/13 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'baselink' in cp_ubsan_maybe_instrument_member_access, at cp/cp-ubsan.cc:172

[gscfq--- via Gcc-bugs]

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

Bug ID: 106858
   Summary: [12/13 Regression] ICE: tree check: expected tree that
contains 'decl common' structure, have 'baselink' in
cp_ubsan_maybe_instrument_member_access, at
cp/cp-ubsan.cc:172
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20211205 and 20211212 :
(gcc configured with --enable-checking=yes)


$ cat z1.cc
class A {
  void f() {
#pragma omp target map(this->f)
;
  }
};


$ g++-13-20220904 -c z1.cc -fopenmp
$
$ g++-13-20220904 -c z1.cc -fopenmp -fsanitize=undefined
z1.cc: In member function 'void A::f()':
z1.cc:5:3: internal compiler error: tree check: expected tree that contains
'decl common' structure, have 'baselink' in
cp_ubsan_maybe_instrument_member_access, at cp/cp-ubsan.cc:172
5 |   }
  |   ^
0x6fa541 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/tree.cc:9001
0x8a0efc contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3634
0x8a0efc cp_ubsan_maybe_instrument_member_access
../../gcc/cp/cp-ubsan.cc:172
0x8a0efc cp_ubsan_check_member_access_r
../../gcc/cp/cp-ubsan.cc:231
0x152cac3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11247
0x152d35d walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11370
0x8a140d cp_ubsan_instrument_member_accesses(tree_node**)
../../gcc/cp/cp-ubsan.cc:268
0x891bd7 cp_genericize_tree
../../gcc/cp/cp-gimplify.cc:1792
0x891d96 cp_genericize(tree_node*)
../../gcc/cp/cp-gimplify.cc:1931
0x8eb95f finish_function(bool)
../../gcc/cp/decl.cc:18058
0xa20fb3 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.cc:31480
0xa21358 cp_parser_late_parsing_for_member
../../gcc/cp/parser.cc:32444
0x9f25ca cp_parser_class_specifier
../../gcc/cp/parser.cc:26399
0x9f3a7c cp_parser_type_specifier
../../gcc/cp/parser.cc:19488
0x9f4796 cp_parser_decl_specifier_seq
../../gcc/cp/parser.cc:16038
0x9f5411 cp_parser_simple_declaration
../../gcc/cp/parser.cc:15286
0xa29c2f cp_parser_declaration
../../gcc/cp/parser.cc:15099
0xa2a758 cp_parser_translation_unit
../../gcc/cp/parser.cc:5068
0xa2a758 c_parse_file()
../../gcc/cp/parser.cc:48595
0xbbe741 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1255

[Bug c/106859] New: [10/11/12/13 Regression] ICE in val_store, at var-tracking.cc:2532

[gscfq--- via Gcc-bugs]

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

Bug ID: 106859
   Summary: [10/11/12/13 Regression] ICE in val_store, at
var-tracking.cc:2532
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r7 at -O1+ and with file gcc.dg/torture/pr90553.c :


$ gcc-13-20220904 -c pr90553.c -O2 -da -funroll-loops -fcompare-debug
during RTL pass: vartrack
dump file: pr90553.gk.c.328r.vartrack
pr90553.c: In function 'f2':
pr90553.c:58:1: internal compiler error: Segmentation fault
   58 | }
  | ^
0xec93cf crash_signal
../../gcc/toplev.cc:314
0x127cc04 INSN_UID(rtx_def*)
../../gcc/rtl.h:1453
0x127cc04 val_store
../../gcc/var-tracking.cc:2532
0x127d826 compute_bb_dataflow
../../gcc/var-tracking.cc:6961
0x127e658 vt_find_locations
../../gcc/var-tracking.cc:7200
0x127fef3 variable_tracking_main_1
../../gcc/var-tracking.cc:10519
0x127fef3 variable_tracking_main()
../../gcc/var-tracking.cc:10565
0x127fef3 execute
../../gcc/var-tracking.cc:10602

[Bug c/106860] New: [12/13 Regression] ICE in single_pred_edge, at basic-block.h:347

[gscfq--- via Gcc-bugs]

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

Bug ID: 106860
   Summary: [12/13 Regression] ICE in single_pred_edge, at
basic-block.h:347
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r12 between 20211219 and 20220109, at -O3 or -Ofast,
and with file gcc.dg/graphite/isl-ast-gen-user-1.c :
(gcc/g++ configured with --enable-checking=yes)


$ cat isl-ast-gen-user-1.c
static const int N = 12;
int nSlip;

int main ()
{
  int i, j, k, fdot = 0;
  int a[N][N];

  for ( i = 1; i < nSlip; i++)
{
  for ( j = i+1; j < nSlip; j++)
{
  for ( k = 0; k < i; k++)
fdot += a[i][k] * a[k][j];
  a[i][j] = a[i][j] - fdot;
}
   }

  return 0;
}


$ g++-13-20220904 -c isl-ast-gen-user-1.c -Ofast -ftrapv -fnon-call-exceptions
-fno-tree-fre
during GIMPLE pass: lsplit
isl-ast-gen-user-1.c: In function 'int main()':
isl-ast-gen-user-1.c:4:5: internal compiler error: in single_pred_edge, at
basic-block.h:347
4 | int main ()
  | ^~~~
0x1390add single_pred_edge
../../gcc/basic-block.h:347
0x1390add split_loop
../../gcc/tree-ssa-loop-split.cc:647
0x1390add tree_ssa_split_loops
../../gcc/tree-ssa-loop-split.cc:1678

[Bug c/106861] New: [12/13 Regression] ICE in add_cfi_args_size, at dwarf2cfi.cc:501

[gscfq--- via Gcc-bugs]

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

Bug ID: 106861
   Summary: [12/13 Regression] ICE in add_cfi_args_size, at
dwarf2cfi.cc:501
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r12 between 20210822 and 20210905, at -O0,
reduced from llvm-project-llvmorg-14.0.6/clang/test/CodeGen/ms_abi.c :


$ cat z1.c
struct foo {
  int x;
  float y;
  char z;
};
void __attribute__((ms_abi)) f1(void);
void __attribute__((sysv_abi)) f2(void);
void f3(void) {
  f1();
  f2();
}
void __attribute__((sysv_abi)) f6(__builtin_ms_va_list ap) {
  int b = __builtin_va_arg(ap, int);
  double _Complex c = __builtin_va_arg(ap, double _Complex);
  struct foo d = __builtin_va_arg(ap, struct foo);
  __builtin_ms_va_list ap2;
  __builtin_ms_va_copy(ap2, ap);
}


$ gcc-13-20220904 -c z1.c -mabi=ms -ftrapv -fnon-call-exceptions
-fprofile-generate
during RTL pass: dwarf2
z1.c: In function 'f6':
z1.c:18:1: internal compiler error: in add_cfi_args_size, at dwarf2cfi.cc:501
   18 | }
  | ^
0x9f7350 add_cfi_args_size
../../gcc/dwarf2cfi.cc:501
0x9fa82f connect_traces
../../gcc/dwarf2cfi.cc:3082
0x9fa82f execute_dwarf2_frame
../../gcc/dwarf2cfi.cc:3305
0x9fa82f execute
../../gcc/dwarf2cfi.cc:3794

[Bug c++/106862] New: ice in compute_control_dep_chain, at gimple-predicate-analysis.cc:1105

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 106862
   Summary: ice in compute_control_dep_chain, at
gimple-predicate-analysis.cc:1105
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 53545
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53545&action=edit
gzipped C++ source code

For the attached C++ code, recent g++ does this:

$ /home/dcb/gcc/results/bin/g++ -c -g -O1 -Wall -fpermissive bug842.cc
during GIMPLE pass: uninit
In file included from VSLRead.C:113:
y.tab.c: In function ‘int VSLLib_parse()’:
y.tab.c:1497:1: internal compiler error: in compute_control_dep_chain, at
gimple-predicate-analysis.cc:1105
0x1df8e69 compute_control_dep_chain(basic_block_def*, basic_block_def const*,
vec*, uns
igned int*, vec&, unsigned int*, unsigned int,
unsigned int)
../../trunk.git/gcc/gimple-predicate-analysis.cc:1105
0x1df8ae7 compute_control_dep_chain(basic_block_def*, basic_block_def const*,
vec*, uns
igned int*, vec&, unsigned int*, unsigned int,
unsigned int)
../../trunk.git/gcc/gimple-predicate-analysis.cc:1086
0x1df8ae7 compute_control_dep_chain(basic_block_def*, basic_block_def const*,
vec*, uns
igned int*, vec&, unsigned int*, unsigned int,
unsigned int)
../../trunk.git/gcc/gimple-predicate-analysis.cc:1086
0x1df7895 compute_control_dep_chain(basic_block_def*, basic_block_def const*,
vec*, uns
igned int*, unsigned int)
../../trunk.git/gcc/gimple-predicate-analysis.cc:1120

The bug first seems to occur sometime between git hash 5e070cf4bd085e10,
from yesterday, and d6582c662ca0da05, from today.

[Bug target/106834] GCC creates R_X86_64_GOTOFF64 for 4-bytes immediate

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

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

--- Comment #12 from H.J. Lu  ---
We can't use

movq_GLOBAL_OFFSET_TABLE_@GOTPCREL(%rip), %rax

to get the address of _GLOBAL_OFFSET_TABLE_ since there is no entry for
_GLOBAL_OFFSET_TABLE_ in GOT.  We can't use

movl $_GLOBAL_OFFSET_TABLE_, %eax

either since it generates R_X86_64_GOTPC32 relocation.  The reliable way to get
the address of _GLOBAL_OFFSET_TABLE_ is to use

leaq_GLOBAL_OFFSET_TABLE_(%rip), %rsi

[Bug tree-optimization/106862] ice in compute_control_dep_chain, at gimple-predicate-analysis.cc:1105

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
I have a cvise reduction running. 

The code is in C++, which cvise isn't very efficient at reducing, so I expect 
it will be some hours before I have any finished reduction.

[Bug analyzer/106854] [[gnu::malloc(deallocator)]] for non-pointer functions (e.g., fd)

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

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

David Malcolm  changed:

   What|Removed |Added

 CC||mir at gcc dot gnu.org

--- Comment #3 from David Malcolm  ---
Immad Mir has spent this summer working on adding support for tracking file
descriptors to -fanalyzer for GCC 13 (as part of GSoC 2022), and he's made a
lot of progress; see:
  *
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=97baacba963c06e3d0e33cde04e7e687671e60e7
which adds five new warnings, relating to misuses of file descriptors:
-Wanalyzer-fd-access-mode-mismatch
-Wanalyzer-fd-double-close
-Wanalyzer-fd-leak
-Wanalyzer-fd-use-after-close
-Wanalyzer-fd-use-without-check 
and specialcases the analyzer's handling of open, close, read, and write.

  *
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=f8e6e2c046e1015697356ee7079fb39e0cb6add5
which adds three new function attributes for int parameters that refer to file
descriptors

  *
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6a11f2d974a912aaaedb0ce32cdfde10193003cd
which specialcases the analyzer's handling of creat, dup, dup2 and dup3.

See also:
  https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=106003&hide_resolved=0
which I hope covers the rest of what you're asking for.

Are we missing anything?

[Bug analyzer/106854] [[gnu::malloc(deallocator)]] for non-pointer functions (e.g., fd)

[colomar.6.4.3 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Alejandro Colomar  ---
Hi David,

I was missing that this is to be introduced in GCC 13, which of course I still
don't have; but thanks!  It'll be a great improvement.

Still, this doesn't seem to cover all cases.  See for example the case of

   int timer_create(clockid_t clockid, struct sigevent *restrict sevp,
timer_t *restrict timerid);
   int timer_delete(timer_t timerid);

One needs to pair those two functions.

The case with these functions has another problem: the initialized object
(which is an arithmetic type; check clockid_t(3type) --or clockid_t(3) in older
systems--) is returned via a parameter, instead of the return value.

It would be good if a more generic attribute could be used to mark such cases. 
We would need to be careful to accept both pointers and integers, to not
unnecessarily make it unusable in some future use cases, so it could be used
for malloc(3), for open(2), for timer_create(3), and for any other functions
that one may create.

I think the following syntax would make sense:

   [[gnu::init(3, timer_delete, 1)]]
   int timer_create(clockid_t clockid, struct sigevent *restrict sevp,
timer_t *restrict timerid);

Where the first argument, 3, refers to the position of the parameter that is
initialized to a unique value; the second refers to the function that
deinitializes it; and the third (optional), refers to the position in the
deinitializer function where the parameter is expected.  For a function like
malloc(3) or open(2), where the initialized value is returned via the return
value, the first argument should be 0.

Does this make sense?

This would superseed the [[gnu::malloc(...)]] attribute, which would be less
confusing (having two different attributes with the same name is confusing,
IMHO).

[Bug analyzer/106854] [[gnu::malloc(deallocator)]] for non-pointer functions (e.g., fd)

[colomar.6.4.3 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Alejandro Colomar  ---
We could also keep the old [[gnu::malloc(...)]] attribute, of course, if a new
attribute would be an issue.  We would just have to add an extra argument (the
third?, or one before the function name?) to mark the position of the
initialized object.

Either [[gnu::malloc(3, timerfd_close)]] with an optional third argument of 1,
or [[gnu::malloc(timerfd_close, 1, 3)]] and force to specify the position in
the closer if the position in the initializer needs to be specified.

The second form would probably be easier to implement, and the first one might
be easier to use (having to specify less things).

[Bug fortran/106857] [10/11/12/13 Regression] ICE in gfc_simplify_pack, at fortran/simplify.cc:6438

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||anlauf at gcc dot gnu.org
   Last reconfirmed||2022-09-06
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Obvious fix for NULL pointer dereference:

diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index bc178d54891..d5c4fe8443d 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -6431,7 +6432,7 @@ gfc_simplify_pack (gfc_expr *array, gfc_expr *mask,
gfc_expr *vector)
   /* Copy only those elements of ARRAY to RESULT whose
 MASK equals .TRUE..  */
   mask_ctor = gfc_constructor_first (mask->value.constructor);
-  while (mask_ctor)
+  while (mask_ctor && array_ctor)
{
  if (mask_ctor->expr->value.logical)
{

[Bug c++/106863] New: internal compiler error: in write_template_arg_literal, at cp/mangle.cc:3678

[jehova at existiert dot net via Gcc-bugs]

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

Bug ID: 106863
   Summary: internal compiler error: in
write_template_arg_literal, at cp/mangle.cc:3678
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jehova at existiert dot net
  Target Milestone: ---

$ g++ --version
g++ (GCC) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ g++ -c bug.cxx -freport-bug
bug.cxx: In instantiation of ‘decltype ((g(t), (void)0)) f(T) [with T = int]’:
bug.cxx:4:6: internal compiler error: in write_template_arg_literal, at
cp/mangle.cc:3678
4 | auto f(T t) -> decltype(g(t), void{})
  |  ^
0x19eab38 internal_error(char const*, ...)
???:0
0x6546f4 fancy_abort(char const*, int, char const*)
???:0
0x728a60 mangle_decl(tree_node*)
???:0
0x984016 symbol_table::finalize_compilation_unit()
???: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/ccL1sCjr.out file, please attach this to
your bugreport.


$ cat bug.cxx 
void g(int);

template 
auto f(T t) -> decltype(g(t), void{})
{
   return g(t);
}

int main()
{
   f(0);
}


$ cat ccL1sCjr.out 
// 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) 
// 
// bug.cxx: In instantiation of ‘decltype ((g(t), (void)0)) f(T) [with T =
int]’:
// bug.cxx:4:6: internal compiler error: in write_template_arg_literal, at
cp/mangle.cc:3678
// 4 | auto f(T t) -> decltype(g(t), void{})
//   |  ^
// 0x19eab38 internal_error(char const*, ...)
//  ???:0
// 0x6546f4 fancy_abort(char const*, int, char const*)
//  ???:0
// 0x728a60 mangle_decl(tree_node*)
//  ???:0
// 0x984016 symbol_table::finalize_compilation_unit()
//  ???:0
// Please submit a full bug report, with preprocessed source.
// Please include the complete backtrace with any bug report.
// See  for instructions.

// /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/cc1plus -quiet -D_GNU_SOURCE bug.cxx
-quiet -dumpbase bug.cxx -dumpbase-ext .cxx -mtune=generic -march=x86-64
-freport-bug -o - -frandom-seed=0 -fdump-noaddr

# 0 "bug.cxx"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "bug.cxx"
void g(int);

template 
auto f(T t) -> decltype(g(t), void{})
{
   return g(t);
}

int main()
{
   f(0);
}

[Bug c++/106864] New: Unexpected capture of "constexpr int" variable inside lambda

[a.elovikov at gmail dot com via Gcc-bugs]

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

Bug ID: 106864
   Summary: Unexpected capture of "constexpr int" variable inside
lambda
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a.elovikov at gmail dot com
  Target Milestone: ---

void bad() {
  constexpr int x = 1;
  auto Outer = [&]() {
auto L = [=]() {
  for (int i = 0; i < x; ++i) {
  }
};
static_assert(sizeof(L) == 1); // fails
  };
}

void good() {
  constexpr int x = 1;
  auto L = [=]() {
for (int i = 0; i < x; ++i) {
}
  };
  static_assert(sizeof(L) == 1);  // passes
}

Not sure if that's a bug from the standard conformance point of view, but I'd
expect the L not to capture constexpr variable in both cases.

Sizeof is one in both cases with clang and (MSVC v19.latest + "/std:c++latest
/c") on godbolt.

[Bug tree-optimization/106865] New: addcarry pattern

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 106865
   Summary: addcarry pattern
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

clang provides builtins like __builtin_addcll to deal with addcarry in a
generic way. However, i believe we can provide pattern matching in GCC so
existing programs may get benefit from the code, instead of adding new
builtins.

https://godbolt.org/z/3j18bPq8b

Take riscv as example:

https://godbolt.org/z/KWxfPWGz4

https://godbolt.org/z/b4r63oGqj

This proves GCC and clang can generate identical code EVEN without using adc
builtins.

I suggest to add pattern matching for code like this in GCC:

template
inline constexpr T add_carry_no_carry_in(T a,T b,T& carryout) noexcept
{
T res{a+b};
carryout=res
inline constexpr T add_carry(T a,T b,T carryin,T& carryout) noexcept
{
if(carryin>1)
{
__builtin_unreachable();
}
a=add_carry_no_carry_in(carryin,a,carryout);
a=add_carry_no_carry_in(a,b,carryin);
carryout+=carryin;
return a;
}

This should correctly identify carries for GCC without adding new builtins
while it keeps the same interface as clang's builtins.

[Bug tree-optimization/106865] addcarry pattern

[unlvsur at live dot com via Gcc-bugs]

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

cqwrteur  changed:

   What|Removed |Added

 CC||unlvsur at live dot com

--- Comment #1 from cqwrteur  ---
https://godbolt.org/z/rsETjYvh4

template
inline constexpr bool add_carry2(bool carryin,T a,T b,T& res) noexcept
{
res=carryin+a;
T carry_temp{res1u)
{
__builtin_unreachable();
}
return carry_temp;
}

Also pattern like this for msvc compatibility.

[Bug middle-end/106833] Handle OPAQUE_TYPE in gimple_canonical_types_compatible_p

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

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

--- Comment #9 from Segher Boessenkool  ---
Although, preferably we should not allow assigning one opaque type to another
opaque type just because they will eventually use the same mode, not without
warning anyway?  Or is that unavoidable?  Compare assigning a V4SI to a V4SF.

I don't know if your patch does this, btw, and it isn't so easy to test, we
currently have only one type for each of our opaque modes.  Maybe test by
adding an extra builtin type :-)

[Bug tree-optimization/106862] ice in compute_control_dep_chain, at gimple-predicate-analysis.cc:1105

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
Reduced C++ code seems to be:

extern fprintf(char);
struct string {
  string(char);
};
struct {
  call();
  replace(string);
} vsllib;
struct ListNode {
  ListNode();
};
struct TestNode {
  TestNode(int);
};
typedef struct {
  *node;
} YYSTYPE;
int vsldebug, VSLLib_parse_vsln, VSLLib_parse_vslvsp_4294967293_0_0;
VSLLib_parse() {
  YYSTYPE *vslvsp;
vslnewstate:
  switch (VSLLib_parse_vsln) {
  case 13:
vslvsp = 0;
  case 6:
string("");
  case 35:
delete vslvsp;
VSLLib_parse_vslvsp_4294967293_0_0 &&vslvsp[0].node ? new ListNode : 0;
  case 72:
delete vslvsp;
  case 75:
vslvsp ? vsllib.call() : 0;
  case 9:
vsllib.call();
  case 1:
vsllib.call();
  case 3:
vsllib.call();
  case 5:
vsllib.call();
  case 7:
vsllib.call();
  case 0:
vsllib.call();
  case 2:
VSLLib_parse_vslvsp_4294967293_0_0 &&vslvsp[0].node ? new TestNode(new int)
: 0;
string func_name = vsllib.replace(func_name) && vsllib.replace(0);
delete vslvsp;
  }
  ++vslvsp;
  if (vsldebug)
fprintf("");
  goto vslnewstate;
}

[Bug c/106835] [i386] Taking an address of _GLOBAL_OFFSET_TABLE_ produces a wrong value

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

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

--- Comment #8 from H.J. Lu  ---
GCC generates _GLOBAL_OFFSET_TABLE_ to indicate GOTPC32 relocation.  It can't
be
treated as a normal symbol.

[Bug middle-end/104151] [10/11/12/13 Regression] x86: excessive code generated for 128-bit byteswap

[pobrn at protonmail dot com via Gcc-bugs]

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

Barnabás Pőcze  changed:

   What|Removed |Added

 CC||pobrn at protonmail dot com

--- Comment #15 from Barnabás Pőcze  ---
Sorry, I haven't found a better issue. But I think the example below exhibits
the same or a very similar issue.

I would expect the following code

void f(unsigned char *p, std::uint32_t x, std::uint32_t y)
{
p[0] = x >> 24;
p[1] = x >> 16;
p[2] = x >>  8;
p[3] = x >>  0;

p[4] = y >> 24;
p[5] = y >> 16;
p[6] = y >>  8;
p[7] = y >>  0;
}

to be compiled to something along the lines of

f(unsigned char*, unsigned int, unsigned int):
bswap   esi
bswap   edx
mov DWORD PTR [rdi], esi
mov DWORD PTR [rdi+4], edx
ret

however, I get scores of bitwise operations instead if `-fno-tree-vectorize` is
not specified.

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

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com via Gcc-bugs]

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

Michael Hudson-Doyle  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #13 from Michael Hudson-Doyle  
---
I fixed this in glibc so marking INVALID here. The general issue of preventing
fp operations being moved over rounding mode changes is all fairly depressing
but I'm not sure a general fix is realistic.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |MOVED

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

[foom at fuhm dot net via Gcc-bugs]

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

James Y Knight  changed:

   What|Removed |Added

 CC||foom at fuhm dot net

--- Comment #12 from James Y Knight  ---
https://github.com/llvm/llvm-project/issues/57589 was just filed, requesting to
fix this behavior in Clang, as well.

Since Clang is effectively only doing it in the first place to match GCC's
behavior, my feeling is that it'd be better not to make such a change in Clang
only.

However, I'd just like to give my support to changing this in GCC (either to
stop automatically linking against crtfastmath.o altogether, or to at least
stop doing so with -shared). And, if there is a change here, would certainly
then propose to match the new behavior in Clang.

[Bug analyzer/106854] [[gnu::malloc(deallocator)]] for non-pointer functions (e.g., fd)

[colomar.6.4.3 at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Alejandro Colomar  ---
timerfd_create() might not be important if the timer is not correctly deleted. 
pthread_mutex_init() is another one that is quite more important, as leaking
such a thing in a multithreaded program will be a pain to debug for sure.  This
attribute could help detect that.

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

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

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

--- Comment #13 from Andrew Pinski  ---
Patient: Doctor it hurts when I do this.
Doctor: then don't do that and if you read the instructions I gave you I told
you I would hurt this way.

Note I think it was a mistake that gcc had -ffast-math option at all now.

But that ship has sailed over 18 years ago. And people abuse optimizations that
are documented this way and will still continue to abuse others similarly
really.
Plus always will abuse c/c++ semantics too.

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #14 from Sam James  ---
(In reply to Andrew Pinski from comment #13)
> Patient: Doctor it hurts when I do this.
> Doctor: then don't do that and if you read the instructions I gave you I
> told you I would hurt this way.
> 

This response could be applied to any bug asking for a change in behaviour of a
command line option. But I accept it's been a long time.

[Bug tree-optimization/103144] vectorizer failed to recognize shift>>=1 in loop as shift>>i

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

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

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

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

commit r13-2503-gc13223b790bbc5e4a3f5605e057eac59b61b2c85
Author: liuhongt 
Date:   Thu Aug 4 09:04:22 2022 +0800

Extend vectorizer to handle nonlinear induction for neg, mul/lshift/rshift
with a constant.

For neg, the patch create a vec_init as [ a, -a, a, -a, ...  ] and no
vec_step is needed to update vectorized iv since vf is always multiple
of 2(negative * negative is positive).

For shift, the patch create a vec_init as [ a, a >> c, a >> 2*c, ..]
as vec_step as [ c * nunits, c * nunits, c * nunits, ... ], vectorized iv
is
updated as vec_def = vec_init >>/<< vec_step.

For mul, the patch create a vec_init as [ a, a * c, a * pow(c, 2), ..]
as vec_step as [ pow(c,nunits), pow(c,nunits),...] iv is updated as vec_def
=
vec_init * vec_step.

The patch handles nonlinear iv for
1. Integer type only, floating point is not handled.
2. No slp_node.
3. iv_loop should be same as vector loop, not nested loop.
4. No UD is created, for mul, use unsigned mult to avoid UD, for
   shift, shift count should be less than type precision.

gcc/ChangeLog:

PR tree-optimization/103144
* tree-vect-loop.cc (vect_is_nonlinear_iv_evolution): New function.
(vect_analyze_scalar_cycles_1): Detect nonlinear iv by upper
function.
(vect_create_nonlinear_iv_init): New function.
(vect_peel_nonlinear_iv_init): Ditto.
(vect_create_nonlinear_iv_step): Ditto
(vect_create_nonlinear_iv_vec_step): Ditto
(vect_update_nonlinear_iv): Ditto
(vectorizable_nonlinear_induction): Ditto.
(vectorizable_induction): Call
vectorizable_nonlinear_induction when induction_type is not
vect_step_op_add.
* tree-vect-loop-manip.cc (vect_update_ivs_after_vectorizer):
Update nonlinear iv for epilogue loop.
* tree-vectorizer.h (enum vect_induction_op_type): New enum.
(STMT_VINFO_LOOP_PHI_EVOLUTION_TYPE): New Macro.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr103144-mul-1.c: New test.
* gcc.target/i386/pr103144-mul-2.c: New test.
* gcc.target/i386/pr103144-neg-1.c: New test.
* gcc.target/i386/pr103144-neg-2.c: New test.
* gcc.target/i386/pr103144-shift-1.c: New test.
* gcc.target/i386/pr103144-shift-2.c: New test.

[Bug tree-optimization/103144] vectorizer failed to recognize shift>>=1 in loop as shift>>i

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Hongtao.liu  ---
Fixed in GCC13.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[crazylht at gmail dot com via Gcc-bugs]

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

Bug 103144 Summary: vectorizer failed to recognize shift>>=1 in loop as shift>>i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103144

   What|Removed |Added

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

[Bug tree-optimization/103144] vectorizer failed to recognize shift>>=1 in loop as shift>>i

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #7 from Hongtao.liu  ---
.

[Bug c/106830] [13 Regression] ICE: in tree_to_uhwi, at tree.cc:6392 (from check_for_xor_used_as_pow) since r13-2386-gbedfca647a9e9c1a

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING
   Keywords||patch

--- Comment #5 from David Malcolm  ---
Patch posted for review here:
  https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601179.html

[Bug testsuite/106345] Some ppc64le tests fail with -mcpu=power9 -mtune=power9

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

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

commit r13-2504-g7a43e52a48b6403a99d3e8ab3105869b4b3c081e
Author: Kewen Lin 
Date:   Tue Sep 6 20:37:57 2022 -0500

rs6000/test: Fix empty TU in some cases of effective targets [PR106345]

As the failure of test case gcc.target/powerpc/pr92398.p9-.c in
PR106345 shows, some test sources for some powerpc effective
targets use empty translation unit wrongly.  The test sources
could go with options like "-ansi -pedantic-errors", then those
effective target checkings will fail unexpectedly with the
error messages like:

  error: ISO C forbids an empty translation unit [-Wpedantic]

This patch is to fix empty TUs with one dummy function definition
accordingly.

PR testsuite/106345

gcc/testsuite/ChangeLog:

* lib/target-supports.exp (check_effective_target_powerpc_sqrt):
Add
a function definition to avoid pedwarn about empty translation
unit.
(check_effective_target_has_arch_pwr5): Likewise.
(check_effective_target_has_arch_pwr6): Likewise.
(check_effective_target_has_arch_pwr7): Likewise.
(check_effective_target_has_arch_pwr8): Likewise.
(check_effective_target_has_arch_pwr9): Likewise.
(check_effective_target_has_arch_pwr10): Likewise.
(check_effective_target_has_arch_ppc64): Likewise.
(check_effective_target_ppc_float128): Likewise.
(check_effective_target_ppc_float128_insns): Likewise.
(check_effective_target_powerpc_vsx): Likewise.