[Bug c++/105104] [coroutines] ICE during GIMPLE pass: coro-early-expand-ifns

[jehelset at gmail dot com via Gcc-bugs]

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

--- Comment #1 from John Eivind Helset  ---
Indices of `bb` and `case_bb` in `convert_single_case_switch` are: 
(gdb) p bb->index
$18 = 154
(gdb) p case_bb->index
$19 = 157

If that helps.

[Bug c++/105104] New: [coroutines] ICE during GIMPLE pass: coro-early-expand-ifns

[jehelset at gmail dot com via Gcc-bugs]

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

Bug ID: 105104
   Summary: [coroutines] ICE during GIMPLE pass:
coro-early-expand-ifns
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jehelset at gmail dot com
  Target Milestone: ---

Created attachment 52716
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52716=edit
Output from "-fdump-tree-coro-early-expand-ifns=stdout"

Compiler segfaults on `if (EDGE_COUNT (pred->succs) <= EDGE_COUNT
(succ->preds))`, as `succ` is null. 

Backtrace:
#0  0x0107a2ae in find_edge (pred=0x7fffc626f068, succ=0x0) at
../../gcc/cfganal.cc:523
#1  0x01864cc7 in convert_single_case_switch (swtch=0x7fffc625d2d0,
gsi=...) at ../../gcc/tree-cfgcleanup.cc:118
#2  0x01864d9e in cleanup_control_expr_graph (bb=0x7fffc626f068,
gsi=...) at ../../gcc/tree-cfgcleanup.cc:145
#3  0x018652be in cleanup_control_flow_bb (bb=0x7fffc626f068) at
../../gcc/tree-cfgcleanup.cc:274
#4  0x0186712f in cleanup_control_flow_pre () at
../../gcc/tree-cfgcleanup.cc:908
#5  0x018678f2 in cleanup_tree_cfg_noloop (ssa_update_flags=0) at
../../gcc/tree-cfgcleanup.cc:1073
#6  0x01867bbb in cleanup_tree_cfg (ssa_update_flags=0) at
../../gcc/tree-cfgcleanup.cc:1183
#7  0x016893c6 in execute_function_todo (fn=0x7fffcf0580b8, data=0x60)
at ../../gcc/passes.cc:2051
#8  0x016881d9 in do_per_function (callback=0x1689361
, data=0x60) at
../../gcc/passes.cc:1688
#9  0x0168972e in execute_todo (flags=96) at ../../gcc/passes.cc:2139
#10 0x0168a838 in execute_one_pass (pass=0x408fb20) at
../../gcc/passes.cc:2675
#11 0x0168aa9b in execute_pass_list_1 (pass=0x408fb20) at
../../gcc/passes.cc:2738
#12 0x0168ab25 in execute_pass_list (fn=0x7fffcf0580b8, pass=0x408f6a0)
at ../../gcc/passes.cc:2749
#13 0x010f6cbf in cgraph_node::analyze (this=0x7fffcf07d880) at
../../gcc/cgraphunit.cc:685
#14 0x010f8daa in analyze_functions (first_time=true) at
../../gcc/cgraphunit.cc:1240
#15 0x010fc094 in symbol_table::finalize_compilation_unit
(this=0x770c6000) at ../../gcc/cgraphunit.cc:2500
#16 0x017eb979 in compile_file () at ../../gcc/toplev.cc:479
#17 0x017eea61 in do_compile (no_backend=false) at
../../gcc/toplev.cc:2168
#18 0x017eee49 in toplev::main (this=0x7fffdf62, argc=33,
argv=0x7fffe098) at ../../gcc/toplev.cc:2320
#19 0x02fd18b1 in main (argc=33, argv=0x7fffe098) at
../../gcc/main.cc:39

Dump from tree-coro-early-expand-ifns put in attachment, because of
template-spew.

Compiled with e3d2b0d040e9baf6c0548b865ed5244dec464cc1.

[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #8 from Ian Lance Taylor  ---
This program should print

0
1

but when I run it on gcc112.fsffrance.org, compiling with -O2, it prints

1
824633846216


package main

func main() {
for _, test := range []struct {
x, y, want []int
}{
{[]int{}, []int{}, nil},
{[]int{0}, []int{0}, []int{0}},
} {
p := test.x
F(p)
}
}

func F(v interface{}) {
 recover()
 println(cap(v.([]int)))
}

This can be compiled (though not run) using a cross-compiler without building
libgo.

The code coming into 280r.dse1 seems to be indexing from the end of the array. 
I see

code_label 96 126 55 4 118 (nil) [0 uses])
(note 55 96 56 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 56 55 57 4 (set (reg:DI 144)
(mult:DI (reg:DI 121 [ ivtmp_47 ])
(const_int -72 [0xffb8]))) "foo.go":4:2 154 {muldi3}
 (nil))
(insn 57 56 59 4 (set (reg/f:DI 145)
(plus:DI (reg/f:DI 173)
(reg:DI 144))) "foo.go":4:2 66 {*adddi3}
 (expr_list:REG_DEAD (reg/f:DI 173)
(expr_list:REG_DEAD (reg:DI 144)
(nil

where earlier I see

(insn 17 16 19 2 (set (mem/f/c:DI (plus:DI (reg/f:DI 110 sfp)
(const_int 32 [0x20])) [8 GOTMP.5[0].x.__values+0 S8 A128])
(reg/f:DI 117 [ _11 ])) "foo.go":4:23 670 {*movdi_internal64}
 (expr_list:REG_DEAD (reg/f:DI 117 [ _11 ])
(nil)))

and

(insn 120 4 121 2 (set (reg/f:DI 173)
(plus:DI (reg/f:DI 110 sfp)
(const_int 32 [0x20]))) 66 {*adddi3}
 (nil))

So register 173 is  although insn 120 doesn't indicate that.  Then the
280r.dse1 pass drops out all the assignments to GOTMP.5, presumably because it
doesn't understand that register 173 points to it.

[Bug c++/105077] The std::bad_array_new_length is not thrown for some new array scenarios.

[chumarshal at foxmail dot com via Gcc-bugs]

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

--- Comment #5 from marshal  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to marshal from comment #3)
> > But why "new int[negative];" throws std::bad_array_new_length as following
> > case?
> 
> Because that case requires size_t(-1) * sizeof(int) and the compiler detects
> that it's out of range. It fails to detect that size_t(-1) is already
> incorrect.
> 
> > I think "new int[negative]" and "new char[negative]" should both throw
> > std::bad_array_new_length when "int negative = -1;". 
> 
> Yes, it's a bug.

Please modify "Status：RESOLVED DUPLICATE of bug 8579", because it's a new bug
and it's not same with bug 8579.

[Bug debug/105041] '-fcompare-debug' failure w/ -mcpu=power6 -O2 -fharden-compares -frename-registers

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

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

--- Comment #3 from Peter Bergner  ---
The first real change I see does occur in the rnreg dump file.

[Bug debug/105041] '-fcompare-debug' failure w/ -mcpu=power6 -O2 -fharden-compares -frename-registers

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

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

Peter Bergner  changed:

   What|Removed |Added

   Last reconfirmed||2022-03-29
 CC||bergner at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Peter Bergner  ---
Confirmed.  This only seems to fail for me on BE and using -m32.  It passes
when compiled with -mcpu={7,8,9} and fails using -mcpu={4,5,6,10}.

[Bug testsuite/105085] Excess errors from new test case gcc.dg/analyzer/untracked-1.c in r12-7809-g5f6197d7c197f9

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by the above commit; please reopen if it doesn't.

[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c

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

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

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

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

commit r12-7905-gc788a0eae0a7144e6f148162512fa2e93a45a035
Author: David Malcolm 
Date:   Tue Mar 29 17:50:48 2022 -0400

analyzer: skip constant pool in -fdump-analyzer-untracked [PR
testsuite/105085]

In r12-7809-g5f6197d7c197f9 I added -fdump-analyzer-untracked as support
for DejaGnu testing of an optimization of -fanalyzer,
PR analyzer/104954.

PR testsuite/105085 notes testsuite failures of the form:
  FAIL: gcc.dg/analyzer/untracked-1.c (test for excess errors)
  Excess errors:
  cc1: warning: track '*.LC1': yes
where these warnings are emitted on some targets where the test
causes labelled constants to be created in the constant pool.

We probably ought not to be tracking the values of such decls in the
store, given that they're meant to be constant, and I attempted various
fixes to make the "should we track this decl" logic smarter, but given
that we're in stage 4, the simplest fix seems to be for
-fdump-analyzer-untracked to skip such decls in its output, to minimize
test output differences between targets.

gcc/analyzer/ChangeLog:
PR testsuite/105085
* region-model-manager.cc (dump_untracked_region): Skip decls in
the constant pool.

gcc/testsuite/ChangeLog:
PR testsuite/105085
* gcc.dg/analyzer/untracked-1.c: Add further test coverage.

Signed-off-by: David Malcolm 

[Bug testsuite/105085] Excess errors from new test case gcc.dg/analyzer/untracked-1.c in r12-7809-g5f6197d7c197f9

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

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

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

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

commit r12-7905-gc788a0eae0a7144e6f148162512fa2e93a45a035
Author: David Malcolm 
Date:   Tue Mar 29 17:50:48 2022 -0400

analyzer: skip constant pool in -fdump-analyzer-untracked [PR
testsuite/105085]

In r12-7809-g5f6197d7c197f9 I added -fdump-analyzer-untracked as support
for DejaGnu testing of an optimization of -fanalyzer,
PR analyzer/104954.

PR testsuite/105085 notes testsuite failures of the form:
  FAIL: gcc.dg/analyzer/untracked-1.c (test for excess errors)
  Excess errors:
  cc1: warning: track '*.LC1': yes
where these warnings are emitted on some targets where the test
causes labelled constants to be created in the constant pool.

We probably ought not to be tracking the values of such decls in the
store, given that they're meant to be constant, and I attempted various
fixes to make the "should we track this decl" logic smarter, but given
that we're in stage 4, the simplest fix seems to be for
-fdump-analyzer-untracked to skip such decls in its output, to minimize
test output differences between targets.

gcc/analyzer/ChangeLog:
PR testsuite/105085
* region-model-manager.cc (dump_untracked_region): Skip decls in
the constant pool.

gcc/testsuite/ChangeLog:
PR testsuite/105085
* gcc.dg/analyzer/untracked-1.c: Add further test coverage.

Signed-off-by: David Malcolm 

[Bug fortran/104210] [11/12 Regression] ICE in gfc_zero_size_array, at fortran/arith.cc:1685 since r11-1814-gcc9a9229285a26ac

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-March/057722.html

[Bug fortran/104210] [11/12 Regression] ICE in gfc_zero_size_array, at fortran/arith.cc:1685 since r11-1814-gcc9a9229285a26ac

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Testing this patch:

diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index 06e032e22db..204fc433dff 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -1489,6 +1489,9 @@ eval_intrinsic (gfc_intrinsic_op op,
   int unary;
   arith rc;

+  if (!op1)
+return NULL;
+
   gfc_clear_ts ();

   switch (op)
@@ -1706,7 +1709,7 @@ eval_type_intrinsic0 (gfc_intrinsic_op iop, gfc_expr *op)
 static int
 gfc_zero_size_array (gfc_expr *e)
 {
-  if (e->expr_type != EXPR_ARRAY)
+  if (e == NULL || e->expr_type != EXPR_ARRAY)
 return 0;

   return e->value.constructor == NULL;

[Bug fortran/104571] ICE in resolve_elemental_actual, at fortran/resolve.cc:2383

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Fixed.

[Bug analyzer/105103] New: RFE: detect bogus use of varargs in analyzer

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

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

Bug ID: 105103
   Summary: RFE: detect bogus use of varargs in analyzer
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

The analyzer doesn't yet have any handling for the types, macros, functions
from :

https://en.cppreference.com/w/c/variadic
https://www.man7.org/linux/man-pages/man3/stdarg.3.html

It would be nice to e.g. detect the various undefined behaviors listed in the
above e.g. 

"If ap is passed to a function that uses va_arg(ap,type), then the value of ap
is undefined after the return of that function."

etc.

We could also implement __builtin_va_start, __builtin_va_end, etc
and have region_model unpack variadic args in interprocedural calls,
effectively inlining the analysis.

[Bug fortran/104571] ICE in resolve_elemental_actual, at fortran/resolve.cc:2383

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

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

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

https://gcc.gnu.org/g:69db6e7f4e1d07bf8f33e93a29139cc16c1e0a2f

commit r12-7904-g69db6e7f4e1d07bf8f33e93a29139cc16c1e0a2f
Author: Harald Anlauf 
Date:   Tue Mar 29 22:12:15 2022 +0200

Fortran: avoid NULL pointer dereference checking elemental procedure args

gcc/fortran/ChangeLog:

PR fortran/104571
* resolve.cc (resolve_elemental_actual): Avoid NULL pointer
dereference.

gcc/testsuite/ChangeLog:

PR fortran/104571
* gfortran.dg/pr104571.f90: New test.

Co-authored-by: Steven G. Kargl 

[Bug fortran/104571] ICE in resolve_elemental_actual, at fortran/resolve.cc:2383

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> NULL pointer dereference.
> 
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc

I'll handle this.

[Bug analyzer/105102] New: RFE: analyzer handling for asprintf and vasprintf

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

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

Bug ID: 105102
   Summary: RFE: analyzer handling for asprintf and vasprintf
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

(spotted while fixing PR analyzer/105087)

We don't yet have any special-casing of asprintf and vasprintf, and there
doesn't seem to be a way to express their behavior with attributes.

Would be nice to bifurcate state, and:
- on success, track that *ARG is to be freed with free (and thus we can detect
memory leaks, wrong deallocator, etc),
- on failure, *ARG is undefined; exactly what we should do here is unclear
(what exactly does glibc do?  https://linux.die.net/man/3/vasprintf says that
the "FreeBSD implementation sets strp to NULL on error.", presumably it means
*strp; ee PR 44435).

Maybe we need a new kind of poisoned_svalue "undefined" for the error case,
since there's no guarantee made about what the state of *ARG is?

[Bug libquadmath/105101] New: incorrect rounding for sqrtq

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

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

Bug ID: 105101
   Summary: incorrect rounding for sqrtq
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libquadmath
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

IEEE mandates correct rounding of square roots, and sqrtq rounds
incorrectly for some values:

#include 
#include 
#define MPFR_WANT_FLOAT128
#include 
#include 

#define NDIG 113

int main()
{
  mpfr_t a, b, tst;
  gmp_randstate_t state;
  __float128 af, bf;
  gmp_randinit_mt (state);
  mpfr_set_default_prec (NDIG);
  mpfr_init (a);  mpfr_init (b);  mpfr_init (tst);
  for (int i=0; i<100; i++) {
mpfr_urandom (a, state, MPFR_RNDN);
mpfr_mul_ui (a, a, 3, MPFR_RNDN);
mpfr_add_ui (a, a, 1, MPFR_RNDN);
af = mpfr_get_float128 (a, MPFR_RNDN);

mpfr_sqrt (b, a, MPFR_RNDN);
bf = sqrtq (af);
mpfr_set_float128 (tst, bf, MPFR_RNDN);
if (!mpfr_equal_p (tst, b)) {
  printf ("sqrt(");
  mpfr_out_str (stdout, 16, 0, a, MPFR_RNDN);
  printf (") = ");
  mpfr_out_str (stdout, 16, 0, b, MPFR_RNDN);
  printf (" ! = ");
  mpfr_out_str (stdout, 16, 0, tst, MPFR_RNDN);
  printf ("\n");
}
  }
  return 0;
}

gives me

sqrt(2.4e5658b5f6d2a1ec21e3829dd7f8) = 1.84bfedcba255aeaf7e99184e6f3b ! =
1.84bfedcba255aeaf7e99184e6f3a
sqrt(1.a8942b9fcf73a7cc6d2546104e8f) = 1.49af594bb6630a9358d929e60a7b ! =
1.49af594bb6630a9358d929e60a7c
sqrt(2.71ad677c998ff96c3a5af38b7ee0) = 1.9037796dd2ced85e3fde2112fe63 ! =
1.9037796dd2ced85e3fde2112fe62
sqrt(3.b8f47bfc809dc00ed76e72cc70a4) = 1.edeb6523391e23008db6386115d3 ! =
1.edeb6523391e23008db6386115d4
sqrt(1.48524d337f27113e25d7eee643b7) = 1.21ea0f970722185990c1a32be807 ! =
1.21ea0f970722185990c1a32be806
sqrt(1.c9e6c13fef31a052f5dba4c0d05e) = 1.5660ca59a7ad02740d08ec0ad237 ! =
1.5660ca59a7ad02740d08ec0ad236
sqrt(2.6c28926057d24449c618b8addbb4) = 1.8e729ca4cf7f6ab6f8cf2579a87b ! =
1.8e729ca4cf7f6ab6f8cf2579a87c
sqrt(1.51c65cf9647952785b859500bf70) = 1.260ef5983614564e3fa636e0d493 ! =
1.260ef5983614564e3fa636e0d492
sqrt(2.cf6052559128965a96f542a8c462) = 1.ad239894bbd64edaa5de12f61265 ! =
1.ad239894bbd64edaa5de12f61264
sqrt(2.bfe5732cc879053f71c5240d026e) = 1.a87f27daa19d145bb1d2756750e5 ! =
1.a87f27daa19d145bb1d2756750e4
sqrt(3.66185a13cbb8d455463507813f6c) = 1.d7f53f5b2ad068de705fe4660697 ! =
1.d7f53f5b2ad068de705fe4660698
sqrt(2.5af21489bafdf81c0047850a69e0) = 1.88e114747ee2213bc2af2c6f572f ! =
1.88e114747ee2213bc2af2c6f572e
sqrt(2.71c155bcdb555657ff0fe301660a) = 1.903dd936eb27661ee030b952dc2f ! =
1.903dd936eb27661ee030b952dc2e
sqrt(1.74ed7ee5a244f1c8a45361664fb0) = 1.34fb3bfc3d55ca48fbffb9be113f ! =
1.34fb3bfc3d55ca48fbffb9be1140
sqrt(2.414fd19bd0495ab521274e316538) = 1.806fe03d3244345277e674340bdb ! =
1.806fe03d3244345277e674340bda
sqrt(2.4853c8d694a5aa889070fdab21c6) = 1.82c40b824e75149ee39e9b1c8fed ! =
1.82c40b824e75149ee39e9b1c8fec
sqrt(1.e6ae9218331623b1a8b2ceea4b22) = 1.60f95131df63442f9ba389039d55 ! =
1.60f95131df63442f9ba389039d54
sqrt(1.4dff0457856b9f2097275f9decbe) = 1.2468b38405610910a60929f0c895 ! =
1.2468b38405610910a60929f0c896
sqrt(3.e720f9998891f40b8a3d2207eb6c) = 1.f9be75953c96a035da06ccdc1e67 ! =
1.f9be75953c96a035da06ccdc1e66
sqrt(1.98d4defa4bf711b662d1a2bca893) = 1.43836938d7cb1c9cadaa6d69f11f ! =
1.43836938d7cb1c9cadaa6d69f11e
sqrt(3.f2e46bf92ba492c9980ddfa4317e) = 1.fcb6674f25a5dc44b4b702a34d13 ! =
1.fcb6674f25a5dc44b4b702a34d14
sqrt(1.24e5a1865c0cbb6483d9ccd2ced0) = 1.11d3e6bd82323006686745d16fa1 ! =
1.11d3e6bd82323006686745d16fa0
sqrt(3.937ee06d6e7d373cf1d95f09e500) = 1.e41d51bcc6c6a8867a5819bb1a1b ! =
1.e41d51bcc6c6a8867a5819bb1a1c
sqrt(2.83faa7963fffa7fbc9e246e0914e) = 1.96072460dd2c31680ca207682e4f ! =
1.96072460dd2c31680ca207682e50
sqrt(1.fdf4c95075ffdccec60afb6a74fb) = 1.6950bb2977940a3c7b6524ac62a5 ! =
1.6950bb2977940a3c7b6524ac62a4

[Bug testsuite/105085] Excess errors from new test case gcc.dg/analyzer/untracked-1.c in r12-7809-g5f6197d7c197f9

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2022-03-29

--- Comment #1 from David Malcolm  ---
Thanks for reporting this.

Sorry about the noise; am working on a fix.

[Bug c++/100474] ICE: in diagnose_trait_expr, at cp/constraint.cc:3706

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-03-29

[Bug c++/103769] [11 Regression] checking ICE in hashtab_chk_error with alias template and pack expansion after r11-7931

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #12 from Alexander Lelyakin  ---
Great!

Just to recall: At the URL 

https://lelyakin.de/hashtab/

You can always find results of everyday testing 
how can last version of GCC compile standard c++ headers.

And sorry, it cannot compile all of them does not matter in which order.

[Bug fortran/50549] should detect different type parameters in structure constructors (r178939)

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed for gcc-12.  Closing.

Sorry that it took so long.

[Bug c++/68495] Error when expanding nontype variadic argument in trailing return type

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=104255

--- Comment #2 from Patrick Palka  ---
Like PR104255, the problem appears to be the use of the function parameter 'f'
within the signature of the function.  GCC should arguably accept such uses,
even in evaluated contexts, as long as the function parameter has an empty
type.

One workaround in this case is to replace the trailing return type
int_seq with int_seq.

[Bug fortran/50549] should detect different type parameters in structure constructors (r178939)

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

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

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

https://gcc.gnu.org/g:0712f356374c2cf26015cccfa3141537e42cbb12

commit r12-7900-g0712f356374c2cf26015cccfa3141537e42cbb12
Author: Harald Anlauf 
Date:   Sun Mar 27 21:35:15 2022 +0200

Fortran: character length of pointer assignments in structure constructors

gcc/fortran/ChangeLog:

PR fortran/50549
* resolve.cc (resolve_structure_cons): Reject pointer assignments
of character with different lengths in structure constructor.

gcc/testsuite/ChangeLog:

PR fortran/50549
* gfortran.dg/char_pointer_assign_7.f90: New test.

[Bug c/105100] New: Strange warning when modifying structures "writing 1 byte into a region of size 0" when compile with -O3

[ercli at ucdavis dot edu via Gcc-bugs]

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

Bug ID: 105100
   Summary: Strange warning when modifying structures "writing 1
byte into a region of size 0" when compile with -O3
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ercli at ucdavis dot edu
  Target Milestone: ---

Created attachment 52715
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52715=edit
Preprocessor output that triggers the bug

I am compiling a function that reads a byte array and converts it to
structures. I find strange compiler warnings when using -O3 optimization.

See attachment from line 10 for a minimize test case. My source code is named
b.c, which does not contain any includes.

The exact version of GCC:
gcc (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9)
Also see compiler output below

The system type:
Fedora 35 Workstation, kernel 5.16.16-200.fc35.x86_64

The options given when GCC was configured/built:
See compiler output below

The complete command line that triggers the bug:
gcc -v -save-temps -O3 -Wall -Werror -c -o b.o b.c

The compiler output (error messages, warnings, etc.):
Using built-in specs.
COLLECT_GCC=gcc
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-11.2.1-20220127/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20220127 (Red Hat 11.2.1-9) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-Wall' '-Werror' '-c' '-o' 'b.o'
'-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/11/cc1 -E -quiet -v b.c -mtune=generic
-march=x86-64 -Wall -Werror -O3 -fpch-preprocess -o b.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/11/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/11/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/11/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-Wall' '-Werror' '-c' '-o' 'b.o'
'-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/11/cc1 -fpreprocessed b.i -quiet
-dumpbase b.c -dumpbase-ext .c -mtune=generic -march=x86-64 -O3 -Wall -Werror
-version -o b.s
GNU C17 (GCC) version 11.2.1 20220127 (Red Hat 11.2.1-9) (x86_64-redhat-linux)
compiled by GNU C version 11.2.1 20220127 (Red Hat 11.2.1-9), GMP
version 6.2.0, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version
isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 11.2.1 20220127 (Red Hat 11.2.1-9) (x86_64-redhat-linux)
compiled by GNU C version 11.2.1 20220127 (Red Hat 11.2.1-9), GMP
version 6.2.0, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version
isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8878ef997f8884938fae95d09b5e3a52
b.c: In function 'func':
b.c:28:31: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
   28 | pb[i] = src[0];
  | ~~^~~~
b.c:9:18: note: at offset 2 into destination object 'a' of size 2
9 | uint16_t a;
  |  ^
b.c:28:31: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
   28 | pb[i] = src[0];
  | ~~^~~~
b.c:9:18: note: at offset 3 into destination object 'a' of size 2
9 | uint16_t a;
  |  ^
cc1: all warnings being treated as errors

[Bug middle-end/103597] [12 Regression] False -Wimplicit-fallthrough= involving macro since r12-5638-ga3e75c1491cd2d50

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Fixed.

[Bug middle-end/103597] [12 Regression] False -Wimplicit-fallthrough= involving macro since r12-5638-ga3e75c1491cd2d50

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

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

--- Comment #8 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r12-7899-gd886a5248e66ab911391af18bf955beb87ee8461
Author: Marek Polacek 
Date:   Mon Mar 28 18:19:20 2022 -0400

gimple: Wrong -Wimplicit-fallthrough with if(1) [PR103597]

This patch fixes a wrong -Wimplicit-fallthrough warning for

case 0:
  if (1)  // wrong may fallthrough
return 0;
case 1:

which in .gimple looks like

: // case 0
if (1 != 0) goto ; else goto ;
:
D.1987 = 0;
// predicted unlikely by early return (on trees) predictor.
return D.1987;
:  // dead
: // case 1

and the warning thinks that : falls through to :.  It
does not know that  is effectively a dead label, only reachable
through fallthrough from previous instructions, never jumped to.  To
that effect, Jakub introduced UNUSED_LABEL_P, which is set on such dead
labels.

collect_fallthrough_labels has code to deal with cases like

case 2:
  if (e != 10)
i++; // this may fallthru, warn
  else
return 44;
case 3:

which collects labels that may fall through.  Here it sees the "goto
;"
at the end of the then branch and so when the warning reaches

...
: // from if-then
: // case 3

it knows it should warn about the possible fallthrough.  But an
UNUSED_LABEL_P
is not a label that can fallthrough like that, so it should ignore those.

However, we still want to warn about this:

case 0:
  if (1)
n++; // falls through
case 1:

so collect_fallthrough_labels needs to return the "n = n + 1;" statement,
rather
than the dead label.

Co-authored-by: Jakub Jelinek 

PR middle-end/103597

gcc/ChangeLog:

* gimplify.cc (collect_fallthrough_labels): Don't push
UNUSED_LABEL_Ps
into labels.  Maybe set prev to the statement preceding
UNUSED_LABEL_P.
(gimplify_cond_expr): Set UNUSED_LABEL_P.
* tree.h (UNUSED_LABEL_P): New.

gcc/testsuite/ChangeLog:

* c-c++-common/Wimplicit-fallthrough-39.c: New test.

[Bug c/100789] [9/10/11/12 Regression] ICE with __transaction_relaxed and left shit signed overflow

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

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

--- Comment #5 from Marek Polacek  ---
The problem is that we're creating a C_MAYBE_CONST_EXPR inside of a
TRANSATION_EXPR, but c_fully_fold doesn't walk into TRANSATION_EXPRs, so the
C_MAYBE_CONST_EXPR leaks into the gimplifier.

__transaction_relaxed
{
  <<< Unknown tree: c_maybe_const_expr

8526495038820057088 >>>
}

I don't know if it's OK to fold the insides of a TRANSATION_EXPR.  Another
option would to avoid creating C_MAYBE_CONST_EXPRs inside a transaction expr,
like in_late_binary_op?

[Bug c++/91911] Strange interaction between CTAD and decltype

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||accounts at prantare dot xyz

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

[Bug c++/101914] internal compiler error: in tsubst, at cp/pt.c:15553

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
This appears to be a dup of PR91911, which has recently been fixed for GCC 12.

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

[Bug c++/71637] -Wmisleading-indentation only triggered when using integrated cpp

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||ppalka at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80076
   Target Milestone|--- |11.0
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |RESOLVED

--- Comment #5 from Patrick Palka  ---
This appears to be fixed for GCC 11+ by the fix for PR80076.

[Bug c++/71637] -Wmisleading-indentation only triggered when using integrated cpp

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:89976d082488b3a7dc7520b980f854ce83043d38

commit r12-7898-g89976d082488b3a7dc7520b980f854ce83043d38
Author: Patrick Palka 
Date:   Tue Mar 29 13:44:05 2022 -0400

c-family: Add -Wmisleading-indentation testcase [PR71637]

We no longer emit a bogus warning for the below testcase after
r11-3266-g4839de55e2c986.

PR c++/71637

gcc/testsuite/ChangeLog:

* c-c++-common/Wmisleading-indentation-6.c: New test.

[Bug c++/105099] New: In lookup for namespace name qualifiers only namespaces should be considered

[vanyacpp at gmail dot com via Gcc-bugs]

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

Bug ID: 105099
   Summary: In lookup for namespace name qualifiers only
namespaces should be considered
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

Consider this code:

namespace a
{
namespace c
{}

struct a
{};

namespace b = a::c;   // (1)
using namespace a::c; // (2)
}

Currently GCC prints an error:

file.cpp:9:22: error: 'c' is not a namespace-name
9 | namespace b = a::c;
  |  ^
file.cpp:10:24: error: 'c' is not a namespace-name
   10 | using namespace a::c;
  |^

If I interpret the standard correctly the code should compile without errors
because during the lookup of the qualifier the struct "a" should be ignored and
the namespace "a" should be found.

[basic.lookup.udir]p1: In a using-directive or namespace-alias-definition,
during the lookup for a namespace-name or for a name in a nested-name-specifier
only namespace names are considered.

https://eel.is/c++draft/basic.lookup.udir
https://godbolt.org/z/vaWjx4cKj

[Bug c++/105067] [12 Regression] ICE: in operator[], at vec.h:889 since r12-7631-g9413bb55185b9e88

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

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

--- Comment #6 from Patrick Palka  ---
(In reply to 康桓瑋 from comment #5)
> It still seems to be ICE.
> https://godbolt.org/z/YjazY4ajv

I only see ordinary errors, no ICEs:

:3:9: error: concept 'C' has multiple template parameter lists
3 | concept C = requires { typename T::type; };
  | ^
:5:11: error: 'C' has not been declared
5 | template  class S {};
  |   ^
:7:7: error: type/value mismatch at argument 1 in template parameter
list for 'template< > class S'
7 | S s;
  |   ^
:7:7: note:   expected a constant of type '', got 'void'

[Bug debug/105089] CTF for a defined extern variable is ambiguous

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

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

--- Comment #5 from Indu Bhagat  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Indu Bhagat from comment #2)
> > Regarding this above-mentioned case of two variables (one inside the
> > function), CTF emits debug information for file-scope and global-scope
> > variables only. So in this example, the declaration of a inside the function
> > should not be considered from CTF perspective.
> 
> But a is in the global scope 
> Just not injected into the global scope for that translation unit.

[I changed the name of variable inside the function to b, as I need some
clarification here.]

static const char a[] = "testme";
void foo () { puts (a); }
int main()
{
  extern const char b[];
  puts (b);
  foo ();
}

In this example, 
-- a is file scope.
-- b is function scope (but external linkage). Correct ?

CTF does not need to identify C type of variable b. But does need to identify C
type of variable a.

[Bug middle-end/105071] [9 Regression] Incorrect code with -Os and complex

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

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

--- Comment #3 from Martin Jambor  ---
(In reply to Martin Liška from comment #2)
> Fixed on master with r10-3311-gff6686d2e5f797d6, if I add -fno-ipa-sra for
> the revision, it's still correct.

But it also works if you add -fno-inline ! ;-) 

Anyway, this is a duplicate of PR 97456 which I guess I should have also
backported to GCC 9 but did not.

I'll bootstrap and test the patch on the branch tomorrow.

[Bug other/92396] -ftime-trace support

[barry.revzin at gmail dot com via Gcc-bugs]

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

Barry Revzin  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #11 from Barry Revzin  ---
+1 to supporting this. gcc's existing -ftime-report is useful for being able to
make statements like "gcc 11 is substantially more efficient at constraint
satisfaction than gcc 10 was" (nice job, folks!) but it isn't very useful for
being able to answer questions like "this translation unit takes 90 seconds to
compile, how can I improve that?" Clang's -ftime-trace, on the other hand,
gives me granular data per function -- which can help me determine what the hot
spots are, etc.

[Bug target/102024] [12 Regression] zero width bitfields and ABIs

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

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

--- Comment #21 from CVS Commits  ---
The master branch has been updated by Richard Earnshaw :

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

commit r12-7896-gb243ad1afb7f06ef4ab7649600d900b09b9c6b52
Author: Richard Earnshaw 
Date:   Tue Mar 29 16:07:09 2022 +0100

aarch64: correctly handle zero-sized bit-fields in AAPCS64 [PR102024]

On aarch64 the AAPCS64 states that an HFA is determined by the 'shape' of
the object after layout has been completed, so anything that adds no
members and does not cause the layout to be modified should be ignored
for the purposes of determining which registers are used for parameter
passing.

A zero-sized bit-field falls into this category.  This was not handled
correctly for C structs and in G++-11 only handled correctly because
such fields were eliminated early by the front end.

gcc/ChangeLog:

PR target/102024
* config/aarch64/aarch64.cc (aapcs_vfp_sub_candidate): Handle
zero-sized bit-fields.  Detect cases where a warning may be needed.
(aarch64_vfp_is_call_or_return_candidate): Emit a note if a
zero-sized bit-field has caused parameter passing to change.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/aapcs64/test_28.c: New test.

[Bug target/102024] [12 Regression] zero width bitfields and ABIs

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

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

--- Comment #20 from CVS Commits  ---
The master branch has been updated by Richard Earnshaw :

https://gcc.gnu.org/g:3032df28f2a1cc6514571558b76d9b80373b19c6

commit r12-7895-g3032df28f2a1cc6514571558b76d9b80373b19c6
Author: Richard Earnshaw 
Date:   Tue Mar 29 10:24:49 2022 +0100

arm: correctly handle zero-sized bit-fields in AAPCS [PR102024]

On arm the AAPCS states that an HFA is determined by the 'shape' of
the object after layout has been completed, so anything that adds no
members and does not cause the layout to be modified should be ignored
for the purposes of determining which registers are used for parameter
passing.

A zero-sized bit-field falls into this category.  This was not handled
correctly for C structs and in G++-11 only handled correctly because
such fields were eliminated early by the front end.

gcc/ChangeLog:

PR target/102024
* config/arm/arm.cc (aapcs_vfp_sub_candidate): Handle zero-sized
bit-fields.  Detect cases where a warning may be needed.
(aapcs_vfp_is_call_or_return_candidate): Emit a note if
a zero-sized bit-field has caused parameter passing to change.

gcc/testsuite/ChangeLog:

PR target/102024
* gcc.target/arm/aapcs/vfp26.c: New test.

[Bug c++/105067] [12 Regression] ICE: in operator[], at vec.h:889 since r12-7631-g9413bb55185b9e88

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #5 from 康桓瑋  ---
It still seems to be ICE.
https://godbolt.org/z/YjazY4ajv

[Bug debug/105089] CTF for a defined extern variable is ambiguous

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Indu Bhagat from comment #2)
> Regarding this above-mentioned case of two variables (one inside the
> function), CTF emits debug information for file-scope and global-scope
> variables only. So in this example, the declaration of a inside the function
> should not be considered from CTF perspective.

But a is in the global scope 
Just not injected into the global scope for that translation unit.

[Bug target/96882] Wrong assembly code generated with arm-none-eabi-gcc -flto -mfloat-abi=hard options

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Richard Earnshaw :

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

commit r12-7894-g1dca4ca1bf2f1b05537a1052e373d8b0ff11e53c
Author: Richard Earnshaw 
Date:   Tue Mar 29 16:59:37 2022 +0100

arm: temporarily disable 'local' pcs selection (PR96882)

The arm port has an optimization used during selection of the
function's ABI to permit deviation from the strict ABI when the
function does not escape the current translation unit.

Unfortunately, the ABI selection it makes can be unsafe if it changes
how a result is returned because not enough information is available
via the RETURN_IN_MEMORY hook to determine where the function gets
used.  This can result in some parts of the compiler thinking a value
is returned in memory while others think it is returned in registers.

To mitigate this, this patch temporarily disables the optimization and
falls back to using the default ABI for the translation.

gcc/ChangeLog:

PR target/96882
* config/arm/arm.cc (arm_get_pcs_model): Disable selection of
ARM_PCS_AAPCS_LOCAL.

[Bug debug/105089] CTF for a defined extern variable is ambiguous

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

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

--- Comment #3 from Indu Bhagat  ---
Re: the more "specific" one?, I think if the compiler picks the type from the
defining declaration of the variable, that will be useful (and correct I think)
CTF debug information.

So, for the following-

case 1
--
$ cat a.c
extern const char a[];
const char a[] = "testme";

The compiler should emit CTF type for variable a as const char[7]

If, however, there is a single non-defining decl as follows-

case 2
--
$ cat b.c
extern int a;

The compiler should emit CTF type for variable as as int.

[Bug debug/105089] CTF for a defined extern variable is ambiguous

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

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

--- Comment #2 from Indu Bhagat  ---
Regarding this above-mentioned case of two variables (one inside the function),
CTF emits debug information for file-scope and global-scope variables only. So
in this example, the declaration of a inside the function should not be
considered from CTF perspective.

[Bug c++/104419] [[no_unique_address]] interaction with is_standard_layout

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

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

--- Comment #2 from Jakub Jelinek  ---
>From what I can see, the reason why tuple2 is not std-layout is
https://eel.is/c++draft/class.prop#3.6
checked in:
/* ...has all non-static data members and bit-fields in the class
   and its base classes first declared in the same class.  */
for (basefield = TYPE_FIELDS (basetype); basefield;
 basefield = DECL_CHAIN (basefield))
  if (TREE_CODE (basefield) == FIELD_DECL
  && !(DECL_FIELD_IS_BASE (basefield)
   && is_empty_field (basefield)))
{
  if (field)
CLASSTYPE_NON_STD_LAYOUT (t) = 1;
  else
field = basefield;
  break;
}
basefield is t with int type, field is t with empty type and we haven't ignored
the latter because while is_empty_field is true on it, it isn't
DECL_FIELD_IS_BASE.

[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)

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

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

--- Comment #17 from Patrick Palka  ---
This won't be implemented in time for GCC 12, sadly.

FWIW a class-scope explicit specialization should in most cases be equivalent
to an appropriately constrained partial specialization.  So as a workaround,
instead of e.g.:

struct A {
  template
  struct B;

  template<>
  struct B { }; // unsupported class-scope explicit specialization
};

in C++20 one can do:

struct A {
  template
  struct B;

  template T>
  struct B { };
};

or in C++17:

struct A {
  template
  struct B;

  template
  struct B>> { };
};

[Bug c++/105092] ICE with local with NULL DECL_CONTEXT on templatized OpenMP iterator

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

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 52714
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52714=edit
gcc12-pr105092.patch

Untested fix.

[Bug c++/105098] ICE: endless recursion during auto deduction

[a3at.mail at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Azat  ---
>Seems to be fixed on trunk by r12-3906-g51018dd1395c72.

Indeed, thanks!

Will it be backported to gcc-11?

[Bug c++/102479] segfault when deducing class template arguments for tuple with libc++-14

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||a3at.mail at gmail dot com

--- Comment #7 from Marek Polacek  ---
*** Bug 105098 has been marked as a duplicate of this bug. ***

[Bug c++/105098] ICE: endless recursion during auto deduction

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
dup.

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

[Bug c++/105098] ICE: endless recursion during auto deduction

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

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

--- Comment #3 from Marek Polacek  ---
Seems to be fixed on trunk by r12-3906-g51018dd1395c72.

[Bug c++/105092] ICE with local with NULL DECL_CONTEXT on templatized OpenMP iterator

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Status|WAITING |ASSIGNED
  Component|analyzer|c++
   Assignee|dmalcolm at gcc dot gnu.org|jakub at gcc dot gnu.org

[Bug c++/104419] [[no_unique_address]] interaction with is_standard_layout

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2022-03-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug c++/104386] no_unique_address causes invalid member alignment of pod struct

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-03-29

[Bug c++/105098] ICE: endless recursion during auto deduction

[a3at.mail at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Azat  ---
Created attachment 52713
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52713=edit
original file generated with -save-temps

And here is the original pre-processed temporary file.

[Bug c++/105098] ICE: endless recursion during auto deduction

[a3at.mail at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Azat  ---
Created attachment 52712
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52712=edit
reduced

Here is reduced file, that had been created with the following test for
creduce:

#!/usr/bin/env bash

# NOTE: due to [1], you need to set CWD to the directory where you have
libcxx-tuple.ii
# 
#   [1]: https://github.com/csmith-project/creduce/issues/195

# NOTE: that we need only first line to avoid some syntax errors and
similar things
g++ -std=gnu++20 -c -o /dev/null -nostdinc++ libcxx-tuple.ii |& head -1 |
fgrep 'internal compiler error: Segmentation fault signal terminated program
cc1plus'

[Bug c++/105098] New: ICE: endless recursion during auto deduction

[a3at.mail at gmail dot com via Gcc-bugs]

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

Bug ID: 105098
   Summary: ICE: endless recursion during auto deduction
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a3at.mail at gmail dot com
  Target Milestone: ---

Created attachment 52711
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52711=edit
original cpp code

While switching to libcxx from llvm-14 (actually llvm-13 fails too), using
tuple w/o explicitly passing types leads to ICE with gcc-11.2 (gcc-12 works
fine).

Note, that you can reproduce this with simple usage of tuple from libcxx 13+,
i.e.:

# /usr/include/c++/v1 - path to libcxx
g++ -std=gnu++20 -c -o /dev/null -isystem /usr/include/c++/v1 -nostdinc++
libcxx-tuple.cpp

[Bug c++/101030] [9/10/11/12 Regression] ICE with -Wconversion and a?:b extension in template argument

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug testsuite/105095] gcc.dg/vect/complex/fast-math-complex-* tests are not executed

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

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

Tamar Christina  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org

--- Comment #3 from Tamar Christina  ---
Thanks,

Hadn't noticed those weren't picked up. It looks like the fast-math- has a
filter on the first character to distinguish them from fast-math-bb.

I'll fix it on friday.

[Bug tree-optimization/102466] -O3 -fsanitize=undefined causes warnings (writing 2 bytes into a region of size 0)

[mathieu.malaterre at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Mathieu Malaterre  ---
I can reproduce it using -Wall -fsanitize=undefined  -O2

* https://github.com/malaterre/PublicRep/tree/master/gcc/libjxl

[Bug tree-optimization/102466] -O3 -fsanitize=undefined causes warnings (writing 2 bytes into a region of size 0)

[mathieu.malaterre at gmail dot com via Gcc-bugs]

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

Mathieu Malaterre  changed:

   What|Removed |Added

 CC||mathieu.malaterre at gmail dot 
com

--- Comment #3 from Mathieu Malaterre  ---
This is also triggered in libjxl codebase:

* https://github.com/libjxl/libjxl/blob/main/tools/fuzzer_corpus.cc

/usr/include/c++/11/bits/stl_algobase.h:431:30: warning: 'void*
__builtin_memmove(void*, const void*, long unsigned int)' writing 1 or more
bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
  431 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
  | ~^~~

[Bug target/104857] [nvptx] Add macro specifying ptx isa version

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

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #3 from Tom de Vries  ---
Committed.

[Bug target/104857] [nvptx] Add macro specifying ptx isa version

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Tom de Vries :

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

commit r12-7893-ga2eacdbd4c4a698b3b6f27ef5e1f8dd3d836b2e5
Author: Tom de Vries 
Date:   Tue Mar 29 16:04:09 2022 +0200

[nvptx] Add __PTX_ISA_VERSION_{MAJOR,MINOR}__

Add preprocessor macros __PTX_ISA_VERSION_MAJOR__ and
__PTX_ISA_VERSION_MINOR__.

For the default 6.0, we have:
...
 $ echo | cc1 -E -dD - 2>&1 | grep PTX_ISA_VERSION
 #define __PTX_ISA_VERSION_MAJOR__ 6
 #define __PTX_ISA_VERSION_MINOR__ 0
...
and for 3.1, we have:
...
 $ echo | cc1 -mptx=3.1 -E -dD - 2>&1 | grep PTX_ISA_VERSION
 #define __PTX_ISA_VERSION_MAJOR__ 3
 #define __PTX_ISA_VERSION_MINOR__ 1
...

These can be used to express things like:
...
 #if __PTX_ISA_VERSION_MAJOR__ >= 4 && __PTX_ISA_VERSION_MAJOR__ >= 1
   /* Code using %dynamic_smem_size.  */
 #else
   /* Fallback code.  */
 #endif
...

Tested on nvptx.

gcc/ChangeLog:

2022-03-29  Tom de Vries  

PR target/104857
* config/nvptx/nvptx-c.cc (nvptx_cpu_cpp_builtins): Emit
__PTX_ISA_VERSION_MAJOR__ and __PTX_ISA_VERSION_MINOR__.
* config/nvptx/nvptx.cc (ptx_version_to_number): New function.
* config/nvptx/nvptx-protos.h (ptx_version_to_number): Declare.

gcc/testsuite/ChangeLog:

2022-03-29  Tom de Vries  

PR target/104857
* gcc.target/nvptx/ptx31.c: New test.
* gcc.target/nvptx/ptx60.c: New test.
* gcc.target/nvptx/ptx63.c: New test.
* gcc.target/nvptx/ptx70.c: New test.

[Bug sanitizer/105093] ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 52710
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52710=edit
gcc12-pr105093.patch

Untested fix.

[Bug analyzer/105092] ICE with local with NULL DECL_CONTEXT on templatized OpenMP iterator

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

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

David Malcolm  changed:

   What|Removed |Added

 CC||jakub at redhat dot com,
   ||jason at redhat dot com
Summary|ICE in  |ICE with local with NULL
   |get_region_for_local, at|DECL_CONTEXT on templatized
   |analyzer/region.cc:874  |OpenMP iterator
 Status|NEW |WAITING

--- Comment #2 from David Malcolm  ---
The root cause of PR analyzer/104979 involved looking up a local variable in
the wrong stack frame, so in r12-7790-g4cebae0924248beb I added assertions to
the analyzer to ensure that when accessing a local variable in a frame, the
frame is for the correct function.

This new assertion is failing on the templatizing OpenMP reproducer in
ana::frame_region::get_region_for_local:

869 case SSA_NAME:
870   {
871 if (tree var = SSA_NAME_VAR (expr))
872   {
873 if (DECL_P (var))
874   gcc_assert (DECL_CONTEXT (var) == m_fun->decl);
875   }

on this gimple stmt:
  i_11 = 0;

The SSA name's underlying var_decl "i" has NULL for its DECL_CONTEXT, despite
appearing to be a local variable.

"i" is created here:

(gdb) bt
#0  copy_node (node=) at ../../src/gcc/tree.cc:1358
#1  0x00bf64a3 in copy_decl (decl=) at
../../src/gcc/cp/lex.cc:1027
#2  0x00d87d5c in tsubst_decl (t=,
args=, complain=3) at ../../src/gcc/cp/pt.cc:14912
#3  0x00d9462f in tsubst_omp_clause_decl (decl=, args=, complain=3, 
in_decl=,
iterator_cache=0x7fffcc10) at ../../src/gcc/cp/pt.cc:17540
#4  0x00d9509d in tsubst_omp_clauses (clauses=, ort=C_ORT_OMP, args=, complain=3, 
in_decl=) at
../../src/gcc/cp/pt.cc:17643
#5  0x00d9eec5 in tsubst_expr (t=,
args=, complain=3, 
in_decl=,
integral_constant_expression_p=false) at ../../src/gcc/cp/pt.cc:18974
#6  0x00d9d132 in tsubst_expr (t=,
args=, complain=3, 
in_decl=,
integral_constant_expression_p=false) at ../../src/gcc/cp/pt.cc:18761
#7  0x00d99d5c in tsubst_expr (t=,
args=, complain=3, 
in_decl=,
integral_constant_expression_p=false) at ../../src/gcc/cp/pt.cc:18404
#8  0x00d9d132 in tsubst_expr (t=,
args=, complain=3, 
in_decl=,
integral_constant_expression_p=false) at ../../src/gcc/cp/pt.cc:18761
#9  0x00dc340d in instantiate_body (pattern=, args=, 
d=, nested_p=false) at
../../src/gcc/cp/pt.cc:26338
#10 0x00dc4fcf in instantiate_decl (d=, defer_ok=false, expl_inst_class_mem_p=false)
at ../../src/gcc/cp/pt.cc:26630
#11 0x00dc53bb in instantiate_pending_templates (retries=0) at
../../src/gcc/cp/pt.cc:26709
#12 0x00ba2148 in c_parse_final_cleanups () at
../../src/gcc/cp/decl2.cc:5092
#13 0x00f31e7a in c_common_parse_file () at
../../src/gcc/c-family/c-opts.cc:1262
#14 0x014ef80a in compile_file () at ../../src/gcc/toplev.cc:452
#15 0x00a20e98 in do_compile (no_backend=false) at
../../src/gcc/toplev.cc:2168
#16 toplev::main (this=this@entry=0x7fffdcae, argc=,
argc@entry=25, argv=, argv@entry=0x7fffddb8)
at ../../src/gcc/toplev.cc:2320
#17 0x00a22dd5 in main (argc=25, argv=0x7fffddb8) at
../../src/gcc/main.cc:39

as a copy of the "i" created here:

(gdb) bt
#0  make_node (code=VAR_DECL) at ../../src/gcc/tree.cc:1211
#1  0x017e2d6e in build_decl (loc=292864, code=VAR_DECL,
name=, type=)
at ../../src/gcc/tree.cc:5289
#2  0x00d0c3ce in cp_parser_omp_iterators (parser=0x7fffea6747b8) at
../../src/gcc/cp/parser.cc:39118
#3  0x00d0c746 in cp_parser_omp_clause_affinity (parser=0x7fffea6747b8,
list=) at ../../src/gcc/cp/parser.cc:39181
#4  0x00d0f6b5 in cp_parser_omp_all_clauses (parser=0x7fffea6747b8,
mask=..., where=0x259c622 "#pragma omp task", 
pragma_tok=0x7fffea5b41c8, finish_p=true, nested=0) at
../../src/gcc/cp/parser.cc:40274
#5  0x00d1c848 in cp_parser_omp_task (parser=0x7fffea6747b8,
pragma_tok=0x7fffea5b41c8, if_p=0x0) at ../../src/gcc/cp/parser.cc:43585
#6  0x00d307ba in cp_parser_omp_construct (parser=0x7fffea6747b8,
pragma_tok=0x7fffea5b41c8, if_p=0x0) at ../../src/gcc/cp/parser.cc:47225
#7  0x00d31980 in cp_parser_pragma (parser=0x7fffea6747b8,
context=pragma_compound, if_p=0x0) at ../../src/gcc/cp/parser.cc:47866
#8  0x00cd0ee5 in cp_parser_statement (parser=0x7fffea6747b8,
in_statement_expr=, in_compound=true, if_p=0x0, chain=0x0, 
loc_after_labels=0x0) at ../../src/gcc/cp/parser.cc:12393
#9  0x00cd1f60 in cp_parser_statement_seq_opt (parser=0x7fffea6747b8,
in_statement_expr=) at ../../src/gcc/cp/parser.cc:12846
#10 0x00cd1e50 in cp_parser_compound_statement 

[Bug c/105097] hashtab_chk_error when using g3 option to compile some C program

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2022-03-29
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Marek Polacek  ---
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

[Bug tree-optimization/105086] [12 Regression] Dead Code Elimination Regression at -Os (trunk vs. 11.2.0) 25

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #6 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #5)
> Even wrapping multiple times as long as it wraps finite number of times
> should be  possible to handle, no?
> for (unsigned int i = ~0U; i != 2; i -= 7)
>   ...;
> wraps 5 times and has 3681400539 iterations.

I think if we wrap more than once, we're probably looking at varying anyway :-)

but yes, in theory we could be as precise as we want to be.

[Bug tree-optimization/105086] [12 Regression] Dead Code Elimination Regression at -Os (trunk vs. 11.2.0) 25

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

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

--- Comment #5 from Jakub Jelinek  ---
Even wrapping multiple times as long as it wraps finite number of times should
be  possible to handle, no?
for (unsigned int i = ~0U; i != 2; i -= 7)
  ...;
wraps 5 times and has 3681400539 iterations.

[Bug tree-optimization/105086] [12 Regression] Dead Code Elimination Regression at -Os (trunk vs. 11.2.0) 25

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #4 from Andrew Macleod  ---
(In reply to Richard Biener from comment #3)
> (In reply to Andrew Macleod from comment #2)

> 
> > I have an alternate question.  it looks like when we utilize scev to pick up
> > ranges we just give up if scev_probably_wraps_p() is true.
> > 
> > Analyzing # of iterations of loop 1
> >   exit condition 1 < [4294967273, + , 1]
> >   bounds on difference of bases: 4294967272 ... 4294967272
> >   result:
> > # of iterations 23, bounded by 23
> > 
> > Statement (exit)if (a_1 > 1)
> > is executed at most 23 (bounded by 23) + 1 times in loop 1.
> > 
> > but we neglect to create range for the PHI. We should be able to properly
> > create a  range for this from the SCEV info rather than giving up?  It would
> > be [0,0][4294967273, 4294967295]. 
> 
> Well, we give up if the IV wraps because then the logic we have to compute
> the IV range doesn't work.  I'm talking about bounds_of_var_in_loop
> which basically computes the range as [base, base + step * niter] with
> adjustments to create proper ranges for negative step.
> 
Yeah, that is exactly where I was looking, and it looked like it was just to
keep things simple.

> > And even with the old value_range we could use anti-range and produce
> > ~[1, 4294967272]?
> 
> It should use the range as computed by the "iteration", just not use
> SCEV to refine it.
> 
> > Is there a practical reason we don't look any closer at wrap cases to see if
> > they are "simple wraps" or not?  I think that would also solve this issue.
> 
> The only reason is that nobody implemented it.  The important thing is to
> compute that it will wrap exactly once of course.

I suspected as much. I think we can enhance this next stage 1.

[Bug tree-optimization/69873] Vectorizer fails to emit runtime profitability check if no peeling/versioning is done

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

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

--- Comment #3 from Richard Biener  ---
It's difficult to find a testcase that we'd vectorize with a runtime
profitability check but whithout any versioning or peeling because we should
always be able to statically decide profitability there - more vector
iterations
shouldn't be able to offset any outside cost on the vector path because there
is none (well, an "excessive" number of emitted splats maybe - but that starts
to be quite a bit tricky).

[Bug c/105097] New: hashtab_chk_error when using g3 option to compile some C program

[jiangtaijin at acoinfo dot com via Gcc-bugs]

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

Bug ID: 105097
   Summary: hashtab_chk_error when using g3 option to compile some
C program
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiangtaijin at acoinfo dot com
  Target Milestone: ---

I gets hashtab_chk_error error when using "-g3" option to compile some C
program. But when I use "-g" option to compile, it is OK.

Follow is the command and output: 

H://RealEvo-Compiler/installer/compiler/loongarch64-sylixos-toolchain/bin/loongarch64-sylixos-elf-gcc
 -fPIC  -Wall -Werror -fmessage-length=0 -fsigned-char -O2 -g3 -gdwarf-2 
-DSYLIXOS -DSYLIXOS_LIB -DIN_LIBGCOV=1 -DGCOV_LOCKED=0 -DBITS_PER_UNIT=32
-DLONG_LONG_TYPE_SIZE=64 -DCROSS_DIRECTORY_STRUCTURE -DUSE_TM_CLONE_REGISTRY=0
-D__LIBGCC_VTABLE_USES_DESCRIPTORS__=0 -DL_gcov -DL_gcov_merge_add
-DL_gcov_merge_topn -DL_gcov_merge_ior -DL_gcov_merge_time_profile
-DL_gcov_interval_profiler -DL_gcov_interval_profiler_atomic
-DL_gcov_pow2_profiler -DL_gcov_pow2_profiler_atomic
-DL_gcov_topn_values_profiler -DL_gcov_topn_values_profiler_atomic
-DL_gcov_average_profiler -DL_gcov_average_profiler_atomic
-DL_gcov_ior_profiler -DL_gcov_ior_profiler_atomic
-DL_gcov_indirect_call_profiler_v4 -DL_gcov_time_profiler -DL_gcov_dump
-DL_gcov_flush -DL_gcov_execl -DL_gcov_execlp -DL_gcov_execle -DL_gcov_execv
-DL_gcov_execvp -DL_gcov_execve -DL_gcov_reset
-I"H:/RealEvo-Compiler/src/libsylixos/SylixOS"
-I"H:/RealEvo-Compiler/src/libsylixos/SylixOS/include"
-I"H:/RealEvo-Compiler/src/libsylixos/SylixOS/include/network" -o
loongarch64/libgcov/pic/libgcov-interface.o -c src/libgcov/libgcov-interface.c
-v -save-temps
Using built-in specs.
COLLECT_GCC=H:\RealEvo-Compiler\installer\compiler\loongarch64-sylixos-toolchain\bin\loongarch64-sylixos-elf-gcc.exe
Target: loongarch64-sylixos-elf
Configured with:
/home/user/toolchains/loongarch/gcc-loongarch64-sylixos-elf-10-2020-q4-major/src/gcc/configure
--build=x86_64-linux-gnu --host=i686-w64-mingw32
--target=loongarch64-sylixos-elf
--prefix=/home/user/toolchains/loongarch/gcc-loongarch64-sylixos-elf-10-2020-q4-major/install-mingw
--libexecdir=/home/user/toolchains/loongarch/gcc-loongarch64-sylixos-elf-10-2020-q4-major/install-mingw/lib
--infodir=/home/user/toolchains/loongarch/gcc-loongarch64-sylixos-elf-10-2020-q4-major/install-mingw/share/doc/gcc-loongarch64-sylixos-elf/info
--mandir=/home/user/toolchains/loongarch/gcc-loongarch64-sylixos-elf-10-2020-q4-major/install-mingw/share/doc/gcc-loongarch64-sylixos-elf/man
--htmldir=/home/user/toolchains/loongarch/gcc-loongarch64-sylixos-elf-10-2020-q4-major/install-mingw/share/doc/gcc-loongarch64-sylixos-elf/html
--pdfdir=/home/user/toolchains/loongarch/gcc-loongarch64-sylixos-elf-10-2020-q4-major/install-mingw/share/doc/gcc-loongarch64-sylixos-elf/pdf
--enable-languages=c,c++ --enable-mingw-wildcard --disable-decimal-float
--disable-libffi --enable-libgomp --disable-libmudflap --disable-libquadmath
--disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared
--enable-threads=posix --disable-tls --with-gnu-as --with-gnu-ld
--with-headers=yes --with-newlib
--with-python-dir=share/gcc-loongarch64-sylixos-elf
--with-sysroot=/home/user/toolchains/loongarch/gcc-loongarch64-sylixos-elf-10-2020-q4-major/install-mingw/loongarch64-sylixos-elf
--with-libiconv-prefix=/home/user/toolchains/loongarch/gcc-loongarch64-sylixos-elf-10-2020-q4-major/build-mingw/host-libs/usr
--with-gmp=/home/user/toolchains/loongarch/gcc-loongarch64-sylixos-elf-10-2020-q4-major/build-mingw/host-libs/usr
--with-mpfr=/home/user/toolchains/loongarch/gcc-loongarch64-sylixos-elf-10-2020-q4-major/build-mingw/host-libs/usr
--with-mpc=/home/user/toolchains/loongarch/gcc-loongarch64-sylixos-elf-10-2020-q4-major/build-mingw/host-libs/usr
--with-isl=/home/user/toolchains/loongarch/gcc-loongarch64-sylixos-elf-10-2020-q4-major/build-mingw/host-libs/usr
--with-libelf=/home/user/toolchains/loongarch/gcc-loongarch64-sylixos-elf-10-2020-q4-major/build-mingw/host-libs/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='GNU Loongarch SylixOS Toolchain 12-2022-q1-update'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220317 (experimental) (GNU Loongarch SylixOS Toolchain
12-2022-q1-update)
COLLECT_GCC_OPTIONS='-fPIC' '-Wall' '-Werror' '-fmessage-length=0'
'-fsigned-char' '-O2' '-g3' '-gdwarf-2' '-D' 'SYLIXOS' '-D' 'SYLIXOS_LIB' '-D'
'IN_LIBGCOV=1' '-D' 'GCOV_LOCKED=0' '-D' 'BITS_PER_UNIT=32' '-D'
'LONG_LONG_TYPE_SIZE=64' '-D' 'CROSS_DIRECTORY_STRUCTURE' '-D'
'USE_TM_CLONE_REGISTRY=0' '-D' '__LIBGCC_VTABLE_USES_DESCRIPTORS__=0' '-D'
'L_gcov' '-D' 'L_gcov_merge_add' '-D' 'L_gcov_merge_topn' '-D'
'L_gcov_merge_ior' '-D' 'L_gcov_merge_time_profile' '-D'
'L_gcov_interval_profiler' '-D' 

[Bug tree-optimization/65206] vectorized version of loop is removed, dependence analysis fails for *[i] vs a[j]

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

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

--- Comment #14 from Richard Biener  ---
*** Bug 69732 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/69732] Vectorization runtime alias check due to failed dependence analysis

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Richard Biener  ---
duplicate and fixed.

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

[Bug middle-end/105032] Compiling inline ASM x86 causing GCC stuck in an endless loop with 100% CPU usage

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

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

--- Comment #9 from Vladimir Makarov  ---
Cycling is the worst what can happen to compiler (even crash is better).
This is the highest priority PR right now for me.  I can not say why the cycle
does not finish.  It should as it works only for reload pseudos.  I'll
investigate it more.

In any case I hope to fix it on this week.  Sorry for inconvenience.

[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly

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

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

--- Comment #7 from Jiu Fu Guo  ---
tried to remove 'fmt' from the narrowed code, but it is still in code :)

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

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

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

--- Comment #11 from Mark Wielaard  ---
I believe the intention of the DWARF5 spec as that dir entry zero would be
equal to the comp_dir attribute of the CU and file entry zero would be equal to
the name attribute of the CU.

Also, although the spec does not explicitly seem to say so, consumers take an
absolute source path to mean that the file isn't relative to the compilation
dir.

So if the current working directory is my home dir and I compile a source file
/tmp/test.c then I would expect the Compile Unit DIE to have the following two
attributes:

   name (line_strp) "/tmp/test.c"
   comp_dir (line_strp) "/home/mark"

And the dir/line table to match with:

Directory table:
  [path(line_strp)]
 0 /home/mark (23)

File name table:
  [path(line_strp), directory_index(udata)]
 0 /tmp/test.c (52),  0

gcc tries to make that happen using the following .file 0 entry:

.file 0 "/home/mark" "/tmp/test.c"

So if that is no longer the case, then I think binutils gas is getting this
wrong now.

[Bug target/104714] [nvptx] Means to specify any sm_xx

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

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #3 from Tom de Vries  ---
Added march-map.

[Bug target/104714] [nvptx] Means to specify any sm_xx

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Tom de Vries :

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

commit r12-7891-gde0ef04419e90eacf0d1ddb265552a1b08c18d4b
Author: Tom de Vries 
Date:   Tue Mar 29 10:32:13 2022 +0200

[nvptx] Add march-map

Say we have an sm_50 board, and we want to run a benchmark using the
highest
possible march setting.

Currently there's march=sm_30, march=sm_35, march=sm_53, but no
march=sm_50.

So, we'd need to pick march=sm_35.

Likewise, for a test script that handles multiple boards, we'd need a
mapping
from native board sm_xx to march, which might have to be updated with newer
gcc releases.

Add an option march-map, such that we can just specify march-map=sm_50, and
let the compiler map this to the appropriate march.

The option is implemented as a list of aliases, such that we have a
somewhat
lengthy (17 lines in total):
...
$ gcc --help=target
  ...
  -march-map=sm_30Same as -misa=sm_30.
  -march-map=sm_32Same as -misa=sm_30.
  ...
  -march-map=sm_87Same as -misa=sm_80.
  -march-map=sm_90Same as -misa=sm_80.
...

This implementation was chosen in the hope that it'll be easier if
we end up with some misa multilib.

It would be nice to have the mapping list generated from an updated
nvptx-sm.def, but for now it's spelled out in nvptx.opt.

Tested on nvptx.

gcc/ChangeLog:

2022-03-29  Tom de Vries  

PR target/104714
* config/nvptx/nvptx.opt (march-map=*): Add aliases.

gcc/testsuite/ChangeLog:

2022-03-29  Tom de Vries  

PR target/104714
* gcc.target/nvptx/march-map.c: New test.

[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly

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

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

--- Comment #6 from Jiu Fu Guo  ---
---bits_test.go
package big

import (
"fmt"
"testing"
)

type Bits []int

func TestMulBits(t *testing.T) {
for _, test := range []struct {
x, y, want Bits
}{

{Bits{}, Bits{}, nil},
{Bits{0}, Bits{0}, Bits{0}},
} {
p := test.x
fmt.Printf("%v", p)
}
}

---

Hi Richard!

The dumps are attached.  Thanks.
One interesting thing: after r12-656, it seems no changes on dse.cc relates to
this issue.

[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly

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

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

--- Comment #5 from Jiu Fu Guo  ---
Created attachment 52709
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52709=edit
280r.dse1

[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly

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

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

--- Comment #4 from Jiu Fu Guo  ---
Created attachment 52708
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52708=edit
279r.cse2

[Bug driver/105096] --target-help not an alias for --help=target

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-03-29
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
You are right, I can take a look.

[Bug testsuite/105095] gcc.dg/vect/complex/fast-math-complex-* tests are not executed

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Eric Botcazou  ---
> works for me, so what doesn't work?

See the subject.

[Bug tree-optimization/105094] [10/11/12 Regression] UBSAN in clear_bit_region(unsigned char*, unsigned int, unsigned int) (gimple-ssa-store-merging.cc:1834)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |10.4
Summary|UBSAN in|[10/11/12 Regression] UBSAN
   |clear_bit_region(unsigned   |in
   |char*, unsigned int,|clear_bit_region(unsigned
   |unsigned int)   |char*, unsigned int,
   |(gimple-ssa-store-merging.c |unsigned int)
   |c:1834) |(gimple-ssa-store-merging.c
   ||c:1834)
   Priority|P3  |P2

--- Comment #2 from Jakub Jelinek  ---
Started with my r10-179-g3afd514bca6ea572e614b5289c4429ace693311b change.

[Bug tree-optimization/105094] UBSAN in clear_bit_region(unsigned char*, unsigned int, unsigned int) (gimple-ssa-store-merging.cc:1834)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2022-03-29
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Jakub Jelinek  ---
Created attachment 52707
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52707=edit
gcc12-pr105094.patch

Untested fix.

[Bug target/104271] [12 Regression] 538.imagick_r run-time at -Ofast -march=native regressed by 26% on Intel Cascade Lake server CPU

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||hubicka at gcc dot gnu.org,
   ||jamborm at gcc dot gnu.org

--- Comment #8 from Richard Biener  ---
(In reply to cuilili from comment #7)
> Created attachment 52706 [details]
> Add a heuristic for eliminate redundant load and store in inline pass.
> 
> Hi Richard,
> 
> Could you help take a look? This is my first time adding code in mid-end,
> hope you can give me some advice, thank you!
> 
> I add a INLINE_HINT_eliminate_load_and_store hint in to inline pass. when
> callee's memory access is caller's local memory parameter and access size is
> greater than the target threshold, we will enable the hint. with the hint,
> inlining_insns_auto will enlarge the bound. The target hook is only enabled
> for x86 now.
> 
> With the patch applied
> Icelake server: 538.imagic_r get 15.18% improvement for multicopy and 40.78%
> improvement for single copy with no measurable changes for other benchmarks.
> 
> Casecadelake: 538.imagic_r get 12.4% improvement for multicopy with and code
> size increased by 0.4%. With no measurable changes for other benchmarks.
> 
> Znver3 server: 538.imagic_r get 9.6% improvement for multicopy with and code
> size increased by 0.5%. With no measurable changes for other benchmarks.

It's an interesting idea, note Honza knows better about IPA modref and
inlining than me.  What I doubt is that you can directly use IPA modref
info to determine whether inlining will likely elide a store/load pair
since IIRC the modref info is for the whole function.

IPA SRA might perform the kind of analysis that is contained to the
call context and that might be available here already (and eventually
even IPA SRA considers passing the stored/loaded values by value?)

But yes, having a stream of up to N (independent?) stores before each call
plus a stream of up to M (independent hoistable to function start?) loads
at each function start would make such analysis possible.

[Bug sanitizer/105093] ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba

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

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

--- Comment #1 from Richard Biener  ---
--- t.ii.025t.waccess1  2022-03-29 12:27:14.769503716 +0200
+++ t.ii.026t.ubsan 2022-03-29 12:27:14.769503716 +0200
...
 volatile struct X test21 ()
 {
   volatile struct X & x.0_1;
   volatile struct X & x.1_2;
+  unsigned long _5;
+  unsigned long _6;
+  sizetype _7;
+  sizetype _8;

:
+  _5 = (unsigned long) &;
+  _6 = (unsigned long) &;
+  _7 = _5 - _6;
+  _8 = _7 + 8;
+  .UBSAN_OBJECT_SIZE (&, _8, 8, 0);
   x.0_1 ={v} ;
   X::X (x.0_1);
   return ;

the ubsan pass fails to mark  as TREE_ADDRESSABLE.

[Bug testsuite/105095] gcc.dg/vect/complex/fast-math-complex-* tests are not executed

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2022-03-29

--- Comment #1 from Richard Biener  ---
Hm, if the files in complex/ follow the naming scheme of vect.exp I expected
that it would work?  In particular

> make check-gcc RUNTESTFLAGS="complex.exp=pr103169.c"

works for me, so what doesn't work?

[Bug middle-end/100059] [OpenMP] wrong code with 'declare target link' and a scalar variable

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

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

--- Comment #5 from Tobias Burnus  ---
Another example for this is https://github.com/clang-ykt/omptests 's
t-same-name-definitions which has the same issue + is fixed by the pull request
for nvptx-tools.

[Bug driver/105096] New: --target-help not an alias for --help=target

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

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

Bug ID: 105096
   Summary: --target-help not an alias for --help=target
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

In common.opt, we read:
...
-target-help
Common Driver
Alias for --help=target.
...

But that doesn't seem to be correct, I get different results.

For instance, for nvptx target, we have an malias that atm is undocumented, and
we have:
...
$ cc1 --target-help 2>&1 | grep malias
$
...
and:
...
$ cc1 --help=target 2>&1 | grep malias
  -malias   [disabled]
$...

[Bug tree-optimization/105090] BFI instructions are not generated on arm-none-eabi-g++

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

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

Richard Earnshaw  changed:

   What|Removed |Added

   Last reconfirmed||2022-03-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Richard Earnshaw  ---
The PR you cite is for aarch64, so while very similar is for a separate target.

[Bug tree-optimization/105090] BFI instructions are not generated on arm-none-eabi-g++

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

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

--- Comment #1 from Richard Earnshaw  ---
This was fallout from some changes made internally in the compiler in around
the gcc-10 timeframe, but it really just exposed a more general problem with
the failure to detect opportunities to use bitfield expressions.

TLDR;

We need to recognize that the pattern:

(set (reg:SI 119)
(ior:SI (and:SI (reg:SI 123)
(const_int -481 [0xfe1f]))
(and:SI (ashift:SI (reg:SI 124)
(const_int 5 [0x5]))
(const_int 480 [0x1e0]

Is in fact a direct match for a bitfield insert instruction and handle it
accordingly.

[Bug target/101908] [12 regression] cray regression with -O2 -ftree-slp-vectorize compared to -O2

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #47 from rguenther at suse dot de  ---
On Tue, 29 Mar 2022, crazylht at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908
> 
> --- Comment #46 from Hongtao.liu  ---
> Another issue is splitting vector load to halves or elements, the latter
> requires scratch registers which may not be available, the former doesn't
> require extra register but may still trigger STLF stalls. For cray case,
> splitting to halves is equal to splitting to elements.
> 
> For x86, there're sse/256_unaligned_load_optima would split 128/256-bit vector
> load to halves.

I suggest to try the easy case first, only split when splitting would
split to elements and when that doesn't require scratch registers.
For large N (number of elements) the separate loads + inserts will
eventually offset the penalty of a failing forwarding anyway, so it
is less obviously a win (or less obviously not a loss).

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||mark at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
It is not more compact, because the "/tmp/cwd/test.c" string is already present
in .debug_line_str anyway (for DW_AT_name which uses DW_FORM_line_strp).
CCing some other DWARF committee members for their opinions.

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #9 from Eric Botcazou  ---
> The reason for the duplication (DW_AT_comp_dir of CU vs. dir 0
> entry in .debug_line and DW_AT_name of CU vs. file 0 entry in .debug_line)
> is so that .debug_info can be stripped and .debug_line* kept.

You can still do that, i.e. .debug_line* contains the same information, it's
just encoded differently and more compact.

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

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

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

--- Comment #8 from Jakub Jelinek  ---
See the
"Note that if a .debug_line_str section is present, both the compilation unit
debugging information entry and the line number header can share a single copy
of
the current directory name string."
and
"Note that if a .debug_line_str section is present, both the compilation unit
debugging information entry and the line number header can share a single copy
of
the current file name string."
comments.  The reason for the duplication (DW_AT_comp_dir of CU vs. dir 0 entry
in .debug_line and DW_AT_name of CU vs. file 0 entry in .debug_line) is so that
.debug_info can be stripped and .debug_line* kept.

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

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

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

--- Comment #7 from Jakub Jelinek  ---
That looks incorrect to me, the intent was that it is actually the same string,
that is also why there is DW_FORM_line_strp so that it can actually use the
same string rather than its copy.

[Bug analyzer/105092] ICE in get_region_for_local, at analyzer/region.cc:874

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-03-29
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r12-7790-g4cebae0924248beb.

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

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

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

--- Comment #6 from Eric Botcazou  ---
This comes from binutils:
  https://sourceware.org/pipermail/binutils/2021-November/118442.html
and I don't think that there is any violation, the file_name is simply
represented by a pair (DW_LNCT_path, DW_LNCT_directory_index).

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
In my case I have binutils 2.35.
Anyway, if newer binutils breaks this, it is binutils fault.
DW_AT_name of the CU in this case has to include the full path, because the
only option it has to supply a path when DW_AT_name is relative is through
DW_AT_comp_dir.  But DW_AT_comp_dir should be the current working directory
which can be and often is completely different from the /tmp/cwd path and some
paths (e.g. of includes) can be relative to the current path.

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

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

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

--- Comment #4 from Jakub Jelinek  ---
Can't reproduce with current 11 branch either.
Perhaps r12-1777-ga21dc9d1529b8a8071e36b22b6e8492fc2ce7d5a which has been
backported to 11 in r11-8650-gf19b20de1b24d6b53479c6815316a5201b22775d as well?