[Bug c++/19249] abstract classes should not access virtually inherited class constructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||

--- Comment #10 from Andrew Pinski  ---
GCC 7+ with -std=c++14 (and above) accept the code.

[Bug tree-optimization/103603] [11 Regression] stack overflow on ranger for huge program, but OK for legacy

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
  Known to work||10.3.0, 12.0
  Known to fail||11.1.0, 11.2.0

[Bug fortran/103607] [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.5

[Bug fortran/103609] [11/12 Regression] ICE in gfc_sym_get_dummy_args, at fortran/symbol.c:5243

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.3

[Bug fortran/103606] [9/10/11/12 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13297

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.5

[Bug testsuite/103522] New test case gcc.dg/ubsan/pr103456.c fails in r12-5649

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Fixed since  r12-5770-g97ffef3553267f52ca83.

[Bug target/100736] ICE: unrecognizable insn

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

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

HaoChen Gui  changed:

   What|Removed |Added

 CC||guihaoc at gcc dot gnu.org

--- Comment #2 from HaoChen Gui  ---
The root cause of the issue is condition rtx can't be recognized when
finite-math-only is set.
I drafted a patch to modify expand of "bcd__". It
expands as before when finite-math-only is not set. While it expands with a
reverse comparison(le -> ungt, ge -> unlt) when finite-math-only is set.
"rs6000_reverse_compare" is a helper method. The code is extracted from
"rs6000_emit_sCOND".
Any comments? Thanks a lot.

diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 93d237156d5..e91a1af6805 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -4415,7 +4415,7 @@ (define_insn "bcd_"
 ;; UNORDERED test on an integer type (like V1TImode) is not defined.  The type
 ;; probably should be one that can go in the VMX (Altivec) registers, so we
 ;; can't use DDmode or DFmode.
-(define_insn "*bcd_test_"
+(define_insn "bcd_test_"
   [(set (reg:CCFP CR6_REGNO)
(compare:CCFP
 (unspec:V2DF [(match_operand:VBCD 1 "register_operand" "v")
@@ -4542,6 +4542,18 @@ (define_expand "bcd__"
   "TARGET_P8_VECTOR"
 {
   operands[4] = CONST0_RTX (V2DFmode);
+  emit_insn (gen_bcd_test_ (operands[0], operands[1],
+  operands[2], operands[3],
+  operands[4]));
+  rtx cr6 = gen_rtx_REG (CCFPmode, CR6_REGNO);
+  rtx condition_rtx = gen_rtx_ (SImode, cr6, const0_rtx);
+  if (flag_finite_math_only)
+{
+  condition_rtx = rs6000_reverse_compare (condition_rtx);
+  PUT_MODE (condition_rtx, SImode);
+}
+  emit_insn (gen_rtx_SET (operands[0], condition_rtx));
+  DONE;
 })

 (define_insn "*bcdinvalid_"
diff --git a/gcc/config/rs6000/rs6000-protos.h
b/gcc/config/rs6000/rs6000-protos.h
index 14f6b313105..9b93e26bec2 100644
--- a/gcc/config/rs6000/rs6000-protos.h
+++ b/gcc/config/rs6000/rs6000-protos.h
@@ -114,6 +114,7 @@ extern enum rtx_code rs6000_reverse_condition
(machine_mode,
 extern rtx rs6000_emit_eqne (machine_mode, rtx, rtx, rtx);
 extern rtx rs6000_emit_fp_cror (rtx_code, machine_mode, rtx);
 extern void rs6000_emit_sCOND (machine_mode, rtx[]);
+extern rtx rs6000_reverse_compare (rtx);
 extern void rs6000_emit_cbranch (machine_mode, rtx[]);
 extern char * output_cbranch (rtx, const char *, int, rtx_insn *);
 extern const char * output_probe_stack_range (rtx, rtx, rtx);
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index ad860728169..39a36add08f 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -15690,19 +15690,14 @@ rs6000_emit_fp_cror (rtx_code code, machine_mode
mode, rtx x)
   return cc;
 }

-void
-rs6000_emit_sCOND (machine_mode mode, rtx operands[])
+rtx
+rs6000_reverse_compare (rtx condition_rtx)
 {
-  rtx condition_rtx = rs6000_generate_compare (operands[1], mode);
   rtx_code cond_code = GET_CODE (condition_rtx);
-
-  if (FLOAT_MODE_P (mode) && HONOR_NANS (mode)
-  && !(FLOAT128_VECTOR_P (mode) && !TARGET_FLOAT128_HW))
-;
-  else if (cond_code == NE
-  || cond_code == GE || cond_code == LE
-  || cond_code == GEU || cond_code == LEU
-  || cond_code == ORDERED || cond_code == UNGE || cond_code == UNLE)
+  if (cond_code == NE
+  || cond_code == GE || cond_code == LE
+  || cond_code == GEU || cond_code == LEU
+  || cond_code == ORDERED || cond_code == UNGE || cond_code == UNLE)
 {
   rtx not_result = gen_reg_rtx (CCEQmode);
   rtx not_op, rev_cond_rtx;
@@ -15716,6 +15711,19 @@ rs6000_emit_sCOND (machine_mode mode, rtx operands[])
   emit_insn (gen_rtx_SET (not_result, not_op));
   condition_rtx = gen_rtx_EQ (VOIDmode, not_result, const0_rtx);
 }
+  return condition_rtx;
+}
+
+void
+rs6000_emit_sCOND (machine_mode mode, rtx operands[])
+{
+  rtx condition_rtx = rs6000_generate_compare (operands[1], mode);
+
+  if (FLOAT_MODE_P (mode) && HONOR_NANS (mode)
+  && !(FLOAT128_VECTOR_P (mode) && !TARGET_FLOAT128_HW))
+  ;
+  else
+condition_rtx = rs6000_reverse_compare (condition_rtx);

   machine_mode op_mode = GET_MODE (XEXP (operands[1], 0));
   if (op_mode == VOIDmode)

[Bug target/103571] ABI: V2HF, V4HF and V8HFmode argument passing issues

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Hongtao.liu  ---
(In reply to Uroš Bizjak from comment #9)
> (In reply to Hongtao.liu from comment #8)
> > (In reply to Uroš Bizjak from comment #6)
> > > (In reply to Hongtao.liu from comment #5)
> > > 
> > > > There're several places in i386-expand.c which assume TARGET_AVX512FP16 
> > > > for
> > > > case V8HF/V16HF/V32HF, if we want to put V8HF/V16HF/V32HF in
> > > > VALID_SSE2/AVX256/AVX512F_REG_MODE, we need to "fix" them first.
> > > 
> > > These are of the type:
> > > 
> > >   use_vector_set = TARGET_AVX512FP16 && one_var == 0;
> > >   gen_vec_set_0 = gen_vec_setv8hf_0;
> > > 
> > > So they look immune to the above change.
> > 
> > This is ok.
> > 
> > I mean in ix86_expand_vector_init_duplicate
> > 
> > case E_V8HFmode:
> > case E_V16HFmode:
> > case E_V32HFmode:
> >   return ix86_vector_duplicate_value (mode, target, val);
> > 
> > AVX2 is needed for V8HF/V16HFmode vpbroadcastw, AVX512BW is needed for
> > V32HFmode, those modes should be handled same as V8HI/V16HI/V32HImode.
> > 
> > Also in ix86_expand_vector_extract, below should be under TARGET_AVX512BW,
> > other wise, vector_extract go through stack.
> > 
> > case E_V32HFmode:
> >   tmp = gen_reg_rtx (V16HFmode);
> >   if (elt < 16)
> > emit_insn (gen_vec_extract_lo_v32hf (tmp, vec));
> >   else
> > emit_insn (gen_vec_extract_hi_v32hf (tmp, vec));
> >   ix86_expand_vector_extract (false, target, tmp, elt & 15);
> >   return;
> > 
> > 
> > others seems to be ok.
> 
> Please note that the change mainly affects moves between SSE and GP
> registers. Expansion is done way before register allocation, and if we allow
> these modes earlier, I'm not sure I understand how it affects expand.
> 
> I propose we proceed with my patch and fix eventual fallout as a follow-up.

Sure.

[Bug target/87438] ICE building gfortran for MicroBlaze target

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||siddhesh at gcc dot gnu.org

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

[Bug target/103613] microblaze: ICE in reload pass when building PIE

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 87438

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

[Bug target/103571] ABI: V2HF, V4HF and V8HFmode argument passing issues

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Hongtao.liu from comment #8)
> (In reply to Uroš Bizjak from comment #6)
> > (In reply to Hongtao.liu from comment #5)
> > 
> > > There're several places in i386-expand.c which assume TARGET_AVX512FP16 
> > > for
> > > case V8HF/V16HF/V32HF, if we want to put V8HF/V16HF/V32HF in
> > > VALID_SSE2/AVX256/AVX512F_REG_MODE, we need to "fix" them first.
> > 
> > These are of the type:
> > 
> >   use_vector_set = TARGET_AVX512FP16 && one_var == 0;
> >   gen_vec_set_0 = gen_vec_setv8hf_0;
> > 
> > So they look immune to the above change.
> 
> This is ok.
> 
> I mean in ix86_expand_vector_init_duplicate
> 
> case E_V8HFmode:
> case E_V16HFmode:
> case E_V32HFmode:
>   return ix86_vector_duplicate_value (mode, target, val);
> 
> AVX2 is needed for V8HF/V16HFmode vpbroadcastw, AVX512BW is needed for
> V32HFmode, those modes should be handled same as V8HI/V16HI/V32HImode.
> 
> Also in ix86_expand_vector_extract, below should be under TARGET_AVX512BW,
> other wise, vector_extract go through stack.
> 
> case E_V32HFmode:
>   tmp = gen_reg_rtx (V16HFmode);
>   if (elt < 16)
>   emit_insn (gen_vec_extract_lo_v32hf (tmp, vec));
>   else
>   emit_insn (gen_vec_extract_hi_v32hf (tmp, vec));
>   ix86_expand_vector_extract (false, target, tmp, elt & 15);
>   return;
> 
> 
> others seems to be ok.

Please note that the change mainly affects moves between SSE and GP registers.
Expansion is done way before register allocation, and if we allow these modes
earlier, I'm not sure I understand how it affects expand.

I propose we proceed with my patch and fix eventual fallout as a follow-up.

[Bug middle-end/100738] Gimple failed to simplify ((v4si) ~a) < 0 ? c : d to ((v4si)a) >= 0 ? c : d

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #6 from Hongtao.liu  ---
Fixed in GCC12 in the backend.

[Bug middle-end/100738] Gimple failed to simplify ((v4si) ~a) < 0 ? c : d to ((v4si)a) >= 0 ? c : d

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

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

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

https://gcc.gnu.org/g:691f05c2197a7b79cb2d7fdbabe3182e22da320a

commit r12-5832-g691f05c2197a7b79cb2d7fdbabe3182e22da320a
Author: Haochen Jiang 
Date:   Thu Dec 2 15:30:17 2021 +0800

Add combine splitter to transform vpcmpeqd/vpxor/vblendvps to vblendvps for
~op0

gcc/ChangeLog:

PR target/100738
* config/i386/sse.md
(*_blendv_not_ltint):
Add new define_insn_and_split.

gcc/testsuite/ChangeLog:

PR target/100738
* g++.target/i386/pr100738-1.C: New test.

[Bug target/103571] ABI: V2HF, V4HF and V8HFmode argument passing issues

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Hongtao.liu  ---
(In reply to Uroš Bizjak from comment #6)
> (In reply to Hongtao.liu from comment #5)
> 
> > There're several places in i386-expand.c which assume TARGET_AVX512FP16 for
> > case V8HF/V16HF/V32HF, if we want to put V8HF/V16HF/V32HF in
> > VALID_SSE2/AVX256/AVX512F_REG_MODE, we need to "fix" them first.
> 
> These are of the type:
> 
>   use_vector_set = TARGET_AVX512FP16 && one_var == 0;
>   gen_vec_set_0 = gen_vec_setv8hf_0;
> 
> So they look immune to the above change.

This is ok.

I mean in ix86_expand_vector_init_duplicate

case E_V8HFmode:
case E_V16HFmode:
case E_V32HFmode:
  return ix86_vector_duplicate_value (mode, target, val);

AVX2 is needed for V8HF/V16HFmode vpbroadcastw, AVX512BW is needed for
V32HFmode, those modes should be handled same as V8HI/V16HI/V32HImode.

Also in ix86_expand_vector_extract, below should be under TARGET_AVX512BW,
other wise, vector_extract go through stack.

case E_V32HFmode:
  tmp = gen_reg_rtx (V16HFmode);
  if (elt < 16)
emit_insn (gen_vec_extract_lo_v32hf (tmp, vec));
  else
emit_insn (gen_vec_extract_hi_v32hf (tmp, vec));
  ix86_expand_vector_extract (false, target, tmp, elt & 15);
  return;


others seems to be ok.

[Bug c/103614] New: Modulo equality optimization

[getchar_gnu at hotmail dot com via Gcc-bugs]

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

Bug ID: 103614
   Summary: Modulo equality optimization
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: getchar_gnu at hotmail dot com
  Target Milestone: ---

Code: https://gcc.godbolt.org/z/99s5fc695
Related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853

(signed)x%145==0, (unsigned)x%145==0, (unsigned)x%145==1 are all optimized into
form x*c1+c2

[Bug target/103613] New: microblaze: ICE in reload pass when building PIE

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

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

Bug ID: 103613
   Summary: microblaze: ICE in reload pass when building PIE
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: siddhesh at gcc dot gnu.org
  Target Milestone: ---

This was found when running build-many-glibcs.py for microblazeel-linux-gnu
with this patch[1] (without the hunks that disable this for microblaze) to
build glibc programs as PIE.  I'll post clearer steps to reproduce once the
glibc patch is pushed.

microblazeel-glibc-linux-gnu-gcc tstdiomisc.c -c -std=gnu11 -fgnu89-inline  -g
-O2 -Wall -Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math
-fno-stack-protector -fno-common -Wstrict-prototypes -Wold-style-definition
-fmath-errno   -fpie -I../include
-Ibuild-many-3/build/glibcs/microblazeel-linux-gnu/glibc/stdio-common 
-Ibuild-many-3/build/glibcs/microblazeel-linux-gnu/glibc 
-I../sysdeps/unix/sysv/linux/microblaze/le 
-I../sysdeps/unix/sysv/linux/microblaze  -I../sysdeps/microblaze/nptl 
-I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux 
-I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu 
-I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix 
-I../sysdeps/posix  -I../sysdeps/microblaze/le  -I../sysdeps/microblaze 
-I../sysdeps/wordsize-32  -I../sysdeps/ieee754/soft-fp 
-I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754 
-I../sysdeps/generic  -I.. -I../libio -I.  -D_LIBC_REENTRANT -include
build-many-3/build/glibcs/microblazeel-linux-gnu/glibc/libc-modules.h
-DMODULE_NAME=testsuite -include ../include/libc-symbols.h  -DPIC
-DTOP_NAMESPACE=glibc -D_IO_MTSAFE_IO -o bu
ild-many-3/build/glibcs/microblazeel-linux-gnu/glibc/stdio-common/tstdiomisc.o
-MD -MP -MF
build-many-3/build/glibcs/microblazeel-linux-gnu/glibc/stdio-common/tstdiomisc.o.dt
-MT
build-many-3/build/glibcs/microblazeel-linux-gnu/glibc/stdio-common/tstdiomisc.o
during RTL pass: reload
tstdiomisc.c: In function ‘main’:
tstdiomisc.c:289:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1168
  289 | }
  | ^
0x55e2c5 gen_reg_rtx(machine_mode)
build-many-3/src/gcc/gcc/emit-rtl.c:1168
0x7a0696 force_reg(machine_mode, rtx_def*)
build-many-3/src/gcc/gcc/explow.c:687
0xfcf7f0 gen_movdf(rtx_def*, rtx_def*)
build-many-3/src/gcc/gcc/config/microblaze/microblaze.md:1226
0x7c0f77 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
build-many-3/src/gcc/gcc/recog.h:407
0x7c0f77 emit_move_insn_1(rtx_def*, rtx_def*)
build-many-3/src/gcc/gcc/expr.c:3766
0x7c7c1c gen_move_insn(rtx_def*, rtx_def*)
build-many-3/src/gcc/gcc/expr.c:3956
0xa3eeaa gen_reload
build-many-3/src/gcc/gcc/reload1.c:8617
0xa46e21 emit_input_reload_insns
build-many-3/src/gcc/gcc/reload1.c:7530
0xa46e21 do_input_reload
build-many-3/src/gcc/gcc/reload1.c:7817
0xa46e21 emit_reload_insns
build-many-3/src/gcc/gcc/reload1.c:8005
0xa46e21 reload_as_needed
build-many-3/src/gcc/gcc/reload1.c:4546
0xa4a953 reload(rtx_insn*, int)
build-many-3/src/gcc/gcc/reload1.c:1047
0x8fe433 do_reload
build-many-3/src/gcc/gcc/ira.c:5847
0x8fe433 execute
build-many-3/src/gcc/gcc/ira.c:6021
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[1]
https://patchwork.sourceware.org/project/glibc/patch/20211207082638.1960585-1-siddh...@sourceware.org/

[Bug c++/91247] Variadic template expansion - Mistmatch argument pack length

[mariogalindoq at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from Mario Galindo  ---
It has been fixed fixed in GCC 10.2.0 and GCC 11+
Thanks.

[Bug libstdc++/103612] get_time parsing error for two digits year

[pyaggi at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Pablo  ---
(In reply to Andrew Pinski from comment #1)
> Dup of bug 101152 ?

No, I don't think so. Here the problem is %y acts like %Y, it uses 4 digits of
the input, and It doesn't produce an error even in the case where there is not
enough digits to complete the parse.

[Bug target/103302] wrong code with -fharden-compares

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

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

--- Comment #10 from Alexandre Oliva  ---
Created attachment 51947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51947&action=edit
candidate patch under testing

Could the fix be as simple as this?

The resulting code is awful, with such stuff as loading and storing back each
word of multi-word pseudos that end up assigned to memory, but at least we
don't clobber the asm outputs with these clobbers, which is what makes them
look dead.

Anyhow, comments at the top of emit_move_multi_word state:

   Note that you will get better code if you define such
   patterns, even if they must turn into multiple assembler instructions.

[Bug c++/92662] change in gcc 8 vs 9: call of overloaded ‘basic_string()’ is ambiguous

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
   Target Milestone|--- |9.0
 Status|NEW |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86521

--- Comment #9 from Andrew Pinski  ---
Invalid as explained and GCC 9's behavior is correct.

[Bug c++/71369] Error message is confusing when missing template keyword with operator().

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-12-08
Summary|Compile failure about   |Error message is confusing
   |template function call  |when missing template
   |operator|keyword with operator().
 Status|UNCONFIRMED |NEW

--- Comment #3 from Andrew Pinski  ---
Confirmed for the error message being confusing. I thought we had a dup but I
can't find it.

[Bug c++/71369] Compile failure about template function call operator

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #2 from Andrew Pinski  ---
clang's error message is better:
:9:10: error: missing 'template' keyword prior to dependent template
name 'operator()'
functor.operator()();
^ ~~~

We might have a dup of this one already even.

[Bug c++/90652] Recursive concept leads to segfault

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

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

--- Comment #1 from Andrew Pinski  ---
With a "fixed" source to the new syntax of concepts I get:
: In substitution of 'template  requires (ToJson) &&
!(Serializable) std::ostream& operator<<(std::ostream&, const T&) [with T =
char]':
:5:86:   required from here
:5:31:   required by the constraints of 'template concept
Serializable'
:5:46:   in requirements with 'T x', 'std::ostream& os' [with T = char]
:5:46: error: satisfaction of atomic constraint 'requires(T x,
std::ostream& os) {{os << x};} [with T = T]' depends on itself
5 | template concept  Serializable = requires (T x,
std::ostream& os) { { os << x }; };
  | 
^




#include 

void to_json (std::ostream& os, char c) { os << '"' << c << '"'; }
template concept  Serializable = requires (T x, std::ostream& os) {
{ os << x }; };
template concept  ToJson = requires (T x, std::ostream& os) { {
to_json (os, x) }; };

template
  requires (ToJson && !Serializable)
std::ostream& operator << (std::ostream& os, T const& x)
{
  to_json (os, x);
  return os;
}

int main ()
{
  static_assert (Serializable);
  static_assert (ToJson);

  std::cout << 'c';
}

[Bug libstdc++/103612] get_time parsing error for two digits year

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 101152 ?

[Bug libstdc++/103612] New: get_time parsing error for two digits year

[pyaggi at gmail dot com via Gcc-bugs]

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

Bug ID: 103612
   Summary: get_time parsing error for two digits year
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pyaggi at gmail dot com
  Target Milestone: ---

std::get_time is behaving in the same way when the format includes '%y' or
'%Y', in both cases it tries to read a four digit year.

Example Code:
-
#include 
#include 

void testDate(const char *format,const char *date)
{
std::istringstream ds(date);
std::tm tm = {};
ds >> std::get_time(&tm,format);
std::cout< Year: "< Year: 1011 Month: 11 Day: 0
101112 parsed using %Y%m%d -> Year: 1011 Month: 11 Day: 0
20101112 parsed using %y%m%d -> Year: 2010 Month: 10 Day: 12
20101112 parsed using %Y%m%d -> Year: 2010 Month: 10 Day: 12

Tested with:

g++ (SUSE Linux) 11.2.1 20210816 
clang++ version 12.0.1

[Bug tree-optimization/103603] [11 Regression] stack overflow on ranger for huge program, but OK for legacy

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #5 from Andrew Macleod  ---
Yes, there is an updated patch that bootstraps posted here for approval:

https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586351.html

Give it a go.

[Bug target/103611] GCC generates suboptimal code for SSE2/SSE4.1 64-bit integer element extraction on 32-bit x86 targets

[john_platts at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from John Platts  ---
(In reply to Andrew Pinski from comment #3)
> Hmm, GCC 4.8.1-5.5.0 produces:
> long long SSE2ExtractInt64<0>(long long __vector):
> .LFB499:
> .cfi_startproc
> pshufd  xmm1, xmm0, 1
> movdeax, xmm0
> movdedx, xmm1
> ret
> long long SSE2ExtractInt64<1>(long long __vector):
> .LFB500:
> .cfi_startproc
> pshufd  xmm1, xmm0, 3
> pshufd  xmm0, xmm0, 2
> movdedx, xmm1
> movdeax, xmm0
> ret
> 
> For the code in comment #0.
> And always used memory for code in comment #2.

I have noticed that the issue with suboptimal code being generated for the code
in comment #0 and comment #1 isn't happening with GCC 5.5 or earlier, but the
issue with suboptimal code being generated for code in comment #0 and comment
#1 is happening with GCC 6.1 or later.

[Bug target/103611] GCC generates suboptimal code for SSE2/SSE4.1 64-bit integer element extraction on 32-bit x86 targets

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

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

--- Comment #3 from Andrew Pinski  ---
Hmm, GCC 4.8.1-5.5.0 produces:
long long SSE2ExtractInt64<0>(long long __vector):
.LFB499:
.cfi_startproc
pshufd  xmm1, xmm0, 1
movdeax, xmm0
movdedx, xmm1
ret
long long SSE2ExtractInt64<1>(long long __vector):
.LFB500:
.cfi_startproc
pshufd  xmm1, xmm0, 3
pshufd  xmm0, xmm0, 2
movdedx, xmm1
movdeax, xmm0
ret

For the code in comment #0.
And always used memory for code in comment #2.

[Bug middle-end/103149] cc1: error: inconsistent operand constraints in an 'asm' with -fharden-conditional-branches and SVE turned on

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

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #4 from Alexandre Oliva  ---
Fixed

[Bug middle-end/103149] cc1: error: inconsistent operand constraints in an 'asm' with -fharden-conditional-branches and SVE turned on

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:0485ce9128f272fe7ccb48672f69d7be6bb26a9c

commit r12-5831-g0485ce9128f272fe7ccb48672f69d7be6bb26a9c
Author: Alexandre Oliva 
Date:   Sat Dec 4 00:17:18 2021 -0300

[PR103149] detach values through mem only if general regs won't do

When hardening compares or conditional branches, we perform redundant
tests, and to prevent them from being optimized out, we use asm
statements that preserve a value used in a compare, but in a way that
the compiler can no longer assume it's the same value, so it can't
optimize the redundant test away.

We used to use +g, but that requires general regs or mem.  You might
think that, if a reg constraint can't be satisfied, the register
allocator will fall back to memory, but that's not so: we decide on
matching MEMs very early on, by using the same addressable operand on
both input and output, and only if the constraint does not allow
registers.  If it does, we use gimple registers and then pseudos as
inputs and outputs, and then inputs can be substituted by equivalent
expressions, and then, if no register contraint fits (e.g. because
that mode won't fit in general regs, or won't fit in regs at all), the
register allocator will give up before even trying to allocate some
temporary memory to unify input and output.

This patch arranges for us to create and use the temporary stack slot
if we can tell the mode requires memory, or won't otherwise fit in
general regs, and thus to use +m for that asm.


for  gcc/ChangeLog

PR middle-end/103149
* gimple-harden-conditionals.cc (detach_value): Use memory if
general regs won't do.

for  gcc/testsuite/ChangeLog

PR middle-end/103149
* gcc.target/aarch64/pr103149.c: New.

[Bug target/103611] GCC generates suboptimal code for SSE2/SSE4.1 64-bit integer element extraction on 32-bit x86 targets

[john_platts at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from John Platts  ---
Here is some code for extracting 64-bit integers from a SSE2 vector using GCC
vector extensions:
#include 
#include 

using Int64M128Vect [[__gnu__::__vector_size__(16)]] = std::int64_t;

template
std::int64_t SSE2ExtractInt64(__m128i vect) noexcept {
static_assert(ElemIdx == (ElemIdx & 1), "ElemIdx must be between 0 and 1");
return Int64M128Vect(vect)[ElemIdx];
}

template std::int64_t SSE2ExtractInt64<0>(__m128i vect) noexcept;
template std::int64_t SSE2ExtractInt64<1>(__m128i vect) noexcept;

Here is the output of the above C++ code when compiled with the -O2 -std=c++17
-march=nocona -mtune=skylake -m32 options:
_Z16SSE2ExtractInt64ILi0EExDv2_x:
subl$28, %esp
movq%xmm0, 8(%esp)
movl8(%esp), %eax
movl12(%esp), %edx
addl$28, %esp
ret
_Z16SSE2ExtractInt64ILi1EExDv2_x:
subl$28, %esp
movhps  %xmm0, 8(%esp)
movl8(%esp), %eax
movl12(%esp), %edx
addl$28, %esp
ret

Here is the output of the above C++ code when compiled with the -O2 -std=c++17
-march=nocona -mtune=skylake -m64 options:
_Z16SSE2ExtractInt64ILi0EElDv2_x:
movq%xmm0, %rax
ret
_Z16SSE2ExtractInt64ILi1EElDv2_x:
movhlps %xmm0, %xmm1
movq%xmm1, %rax
ret

Here is the output of the above C++ code when compiled with the -O2 -std=c++17
-march=core2 -msse4.1 -mtune=skylake -m32 options:
_Z16SSE2ExtractInt64ILi0EExDv2_x:
movd%xmm0, %eax
pextrd  $1, %xmm0, %edx
ret
_Z16SSE2ExtractInt64ILi1EExDv2_x:
subl$28, %esp
movhps  %xmm0, 8(%esp)
movl8(%esp), %eax
movl12(%esp), %edx
addl$28, %esp
ret

Here is the output of the above C++ code when compiled with the -O2 -std=c++17
-march=core2 -msse4.1 -mtune=skylake -m64 options:
_Z16SSE2ExtractInt64ILi0EElDv2_x:
movq%xmm0, %rax
ret
_Z16SSE2ExtractInt64ILi1EElDv2_x:
pextrq  $1, %xmm0, %rax
ret

[Bug target/103611] GCC generates suboptimal code for SSE2/SSE4.1 64-bit integer element extraction on 32-bit x86 targets

[john_platts at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from John Platts  ---
Here is some C++ code for extracting 64-bit integers from a __m128i vector
using SSE4.1:
#include 
#include 

template
std::int64_t SSE41ExtractInt64(__m128i vect) noexcept {
static_assert(ElemIdx == (ElemIdx & 1), "ElemIdx must be between 0 and 1");

std::uint32_t loVal;
std::uint32_t hiVal;
if constexpr(ElemIdx == 0) {
loVal = std::uint32_t(_mm_extract_epi32(vect, 0));
hiVal = std::uint32_t(_mm_extract_epi32(vect, 1));
} else {
loVal = std::uint32_t(_mm_extract_epi32(vect, 2));
hiVal = std::uint32_t(_mm_extract_epi32(vect, 3));
}

return std::int64_t(loVal) | std::int64_t(std::uint64_t(hiVal) << 32);
}

template std::int64_t SSE41ExtractInt64<0>(__m128i vect) noexcept;
template std::int64_t SSE41ExtractInt64<1>(__m128i vect) noexcept;

Here is the assembly code that is generated when the above C++ code is compiled
with the -O2 -std=c++17 -march=core2 -msse4.1 -mtune=skylake -m32 options:
_Z17SSE41ExtractInt64ILi0EExDv2_x:
subl$28, %esp
pmovzxdq%xmm0, %xmm1
movq%xmm1, 8(%esp)
pextrd  $1, %xmm0, %eax
movl%eax, %edx
movl8(%esp), %eax
orl 12(%esp), %edx
orb $0, %ah
addl$28, %esp
ret
_Z17SSE41ExtractInt64ILi1EExDv2_x:
pushl   %ebx
pextrd  $2, %xmm0, %ecx
psrldq  $12, %xmm0
xorl%ebx, %ebx
movd%xmm0, %edx
movl%ecx, %eax
orl %ebx, %edx
orb $0, %ah
popl%ebx
ret

Here is more optimal code for the above functions:
_Z17SSE41ExtractInt64ILi0EExDv2_x:
movd%xmm0, %eax
pextrd  $1, %xmm0, %edx
ret
_Z17SSE41ExtractInt64ILi1EExDv2_x:
pextrd  $2, %xmm0, %eax
pextrd  $3, %xmm0, %edx
ret

Here is the code that is generated when the above C++ code is compiled with
clang 13.0.0 with the -O2 -std=c++17 -march=core2 -msse4.1 -mtune=skylake -m32
options:
_Z17SSE41ExtractInt64ILi0EExDv2_x:  # @_Z17SSE41ExtractInt64ILi0EExDv2_x
movd%xmm0, %eax
pextrd  $1, %xmm0, %edx
retl
_Z17SSE41ExtractInt64ILi1EExDv2_x:  # @_Z17SSE41ExtractInt64ILi1EExDv2_x
extractps   $2, %xmm0, %eax
extractps   $3, %xmm0, %edx
retl

[Bug target/103611] New: GCC generates suboptimal code for SSE2/SSE4.1 64-bit integer element extraction on 32-bit x86 targets

[john_platts at hotmail dot com via Gcc-bugs]

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

Bug ID: 103611
   Summary: GCC generates suboptimal code for SSE2/SSE4.1 64-bit
integer element extraction on 32-bit x86 targets
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john_platts at hotmail dot com
  Target Milestone: ---

Here is some code for extracting 64-bit integers from a SSE2 vector:
#include 
#include 

template
std::int64_t SSE2ExtractInt64(__m128i vect) noexcept {
static_assert(ElemIdx == (ElemIdx & 1), "ElemIdx must be between 0 and 1");

__m128i vect2;
if constexpr(ElemIdx == 0) {
vect2 = _mm_shuffle_epi32(vect, 1);
} else {
vect2 = _mm_shuffle_epi32(vect, 3);
vect = _mm_shuffle_epi32(vect, 2);
}

auto loVal = std::uint32_t(_mm_cvtsi128_si32(vect));
auto hiVal = std::uint32_t(_mm_cvtsi128_si32(vect2));

return std::int64_t(loVal) | std::int64_t(std::uint64_t(hiVal) << 32);
}

template std::int64_t SSE2ExtractInt64<0>(__m128i vect) noexcept;
template std::int64_t SSE2ExtractInt64<1>(__m128i vect) noexcept;

Here is the assembly code that is generated when the above C++ code is compiled
with the -O2 -std=c++17 -march=nocona -mtune=skylake -m32 options:
_Z16SSE2ExtractInt64ILi0EExDv2_x:
pushl   %ebx
pshufd  $1, %xmm0, %xmm1
xorl%ebx, %ebx
movd%xmm1, %edx
movd%xmm0, %eax
orl %ebx, %edx
orb $0, %ah
popl%ebx
ret
_Z16SSE2ExtractInt64ILi1EExDv2_x:
pushl   %esi
pshufd  $3, %xmm0, %xmm1
xorl%esi, %esi
pushl   %ebx
pshufd  $2, %xmm0, %xmm0
movl%esi, %edx
movd%xmm1, %ecx
movd%xmm0, %eax
popl%ebx
orb $0, %ah
orl %ecx, %edx
popl%esi
ret

Here is a more optimal implementation of the above functions:
_Z16SSE2ExtractInt64ILi0EExDv2_x:
pshufd  $1, %xmm0, %xmm1
movd%xmm1, %edx
movd%xmm0, %eax
ret
_Z16SSE2ExtractInt64ILi1EExDv2_x:
pshufd  $3, %xmm0, %xmm1
pshufd  $2, %xmm0, %xmm0
movd%xmm1, %edx
movd%xmm0, %eax
ret

Here is the code that is generated when the above C++ code is compiled with
clang 13.0.0 with the -O2 -std=c++17 -march=nocona -mtune=skylake -m32 options:
_Z16SSE2ExtractInt64ILi0EExDv2_x:   # @_Z16SSE2ExtractInt64ILi0EExDv2_x
movd%xmm0, %eax
pshufd  $85, %xmm0, %xmm0   # xmm0 = xmm0[1,1,1,1]
movd%xmm0, %edx
retl
_Z16SSE2ExtractInt64ILi1EExDv2_x:   # @_Z16SSE2ExtractInt64ILi1EExDv2_x
pshufd  $238, %xmm0, %xmm1  # xmm1 = xmm0[2,3,2,3]
movd%xmm1, %eax
pshufd  $255, %xmm0, %xmm0  # xmm0 = xmm0[3,3,3,3]
movd%xmm0, %edx
retl

[Bug c++/103600] Cannot use typeid result in constant expressions

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

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

--- Comment #7 from Jonathan Wakely  ---
Created attachment 51946
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51946&action=edit
libstdc++: Implement P1328 "Making std::type_info::operator== constexpr"

Jakub, that patch works for me. Here's the libstdc++ patch to make operator==
constexpr, which passes with your patch applied.

[Bug tree-optimization/103603] [11 Regression] stack overflow on ranger for huge program, but OK for legacy

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

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

--- Comment #4 from Kito Cheng  ---
Hi Andrew:

Thanks for your quick response! the patch is work to me for the testcase,
but...I got seg fault when I built x86 GCC.

Here is a reduced case from gcov, and this testcase also take longer
compilation time than expect (>15s to compile and ICE, but ~0.01s w/o patch):
```
struct gcov_ctr_info {
  int values;
};
struct gcov_fn_info {
  struct gcov_ctr_info ctrs[1];
};
struct gcov_info {
  struct gcov_fn_info **functions;
};
void __gcov_dump_one() {
  {
struct gcov_info gi_ptr;
int gi_ptr_1;
struct gcov_info gi_ptr_0;
int run_max ;
for (; ; )
  for (unsigned f_ix ; gi_ptr_1; f_ix) {
struct gcov_ctr_info *cinfo = gi_ptr.functions[0];
int cinfo_0;
for (unsigned i ; cinfo_0; i) {
  run_max < &cinfo;
  run_max = cinfo->values;
}
  }
for (; &gi_ptr; )
  ;
  }
}

```
Backtrace:
during GIMPLE pass: evrp
gcov.c:28:1: internal compiler error: Segmentation fault
   28 | }
  | ^
0xba283f crash_signal
../../../riscv-gnu-toolchain/riscv-gcc/gcc/toplev.c:327
0x1488666 vec::quick_push(tree_node* const&)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/vec.h:1023
0x1488666 vec::quick_push(tree_node* const&)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/vec.h:1875
0x1488666 vec::safe_push(tree_node* const&)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/vec.h:1888
0x1488666 gimple_ranger::prefill_stmt_dependencies(tree_node*)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/gimple-range.cc:1177
0x14892de gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/gimple-range.cc:1089
0x1482b45 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/gimple-range.cc:982
0xe46670 range_query::value_of_expr(tree_node*, gimple*)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/value-query.cc:86
0x14960e0 hybrid_folder::value_of_expr(tree_node*, gimple*)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/gimple-ssa-evrp.c:235
0xd1575b substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/tree-ssa-propagate.c:1072
0x145cb34 dom_walker::walk(basic_block_def*)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/domwalk.c:309
0xd14d85 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/tree-ssa-propagate.c:1283
0x1495c34 execute_early_vrp
../../../riscv-gnu-toolchain/riscv-gcc/gcc/gimple-ssa-evrp.c:349
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies

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

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

--- Comment #15 from Tamar Christina  ---
> That is, we're trading two memory accesses in the call branch
> (if we allocate R) against one memory access in both branches
> (if we spill R).  As the call branch gets more likely,
> the cost of doing two memory accesses there gets higher
> relative to the cost of doing one memory access in both branches.
> And that seems like the right behaviour in principle.
> 
> From that point of view, it doesn't look like the memory and register
> costs of R are too wrong here.  The things being costed are the store
> and load around the call (which do exist if we allocate a call-clobbered
> register) and the loads at each use site (which do exist if we spill R).

Indeed, I don't think the heuristics are wrong, but because one frequency
CALL_FREQ grows much quicker than BB_FREQ and at the smaller values they are a
bit sensitive to any changes.  The edge probabilities can barely change while
the BB_FREQ can change dramatically.

> 
> Like Feng Xue says in comment 1, I think the main missed optimisation
> opportunity here is that foo + 1024 is invariant, so if we allocate
> a call-clobbered register, we could save R once outside the loop
> and reload it after each call.  That would give:
> 
> - a store of R outside the loop (low execution count)
> - a load of R inside the loop (after the call) with freq 0.51 * loop iters
> 

Yes, that is the ideal solution, but also requires more changes to RA.
Instead I've chosen a middle ground here (same as yours but done in
ira_tune_allocno_costs instead), which is to store and load only inside
the loop, but to do so only in the BB which contains the call.

This is a major improvement over the current situation because when you
have several nested loops where the value is invariant across a number of them
you run into problems when each of these BB have naturally very high register
pressure.

As you say:

> - a store of R outside the loop (low execution count)
> - a load of R inside the loop (after the call) with freq 0.51 * loop iters
> - a load of R inside the loop with freq 0.49 * loop iters

and if the loop has various BB (like a long if/then/elseif/else) chain the load
has to happen in in every BB in the loop.  That's why we get the large amount
of spills we currently do.

By forcing it to spill only in the BB with the call inside the loop the other
BBs are freed from all the loads.

> If we force R to be allocated a call-clobbered register instead
> of being spilled (and changing nothing else, via a hack to
> ira-color.c:improve_allocation) then we generate:
> 
> - a store of R inside the loop (before the call) with freq 0.51 * loop iters
> - a load of R inside the loop (after the call) with freq 0.51 * loop iters

I essentially did the same thing, but I think in a more conservative way. When
you just have a single call inside the entire loop I force it to assign the
call-clobbered if it needs it.  This removed the loads with freq 0.49.  But
left the ones with 0.51.

I use call counts as the measure here because with 1 call and multiple BB
inside the live range you know that at most 1 BB will have a call and so the
rest won't have any.

Since essentially if you have high register pressure, just only make the part
that increases it more pay for the spills.  As you say it's not perfect, but
it's a conservative improvement over the current situation.

> which is cheaper than both the current approaches.  We don't do that
> optimisation yet though, so the current costing seems to reflect what we
> currently generate.

In many (if not most) Arches stores are significantly cheaper than the loads
though. So the store before the call doesn't end up making that much of a
difference, but yes it adds up if you have many of them.

So indeed removing it is optimal, but that seems like a very hard one to do.  I
would assume that the live range for the loop starts at the body of the loop. 
So I would imagine it's very hard to tell reload to spill outside of the
current allocas it's currently allocating for?

> 
> I don't know how well the above translates to the original example
> though.  Are the some of the spilled values in exchange loop-invariant
> as well?

Yes I believe so, It's a bit hard for me to tell since the functions are huge
and have many nested loops... But in rtl the BBs quite large as well after the
constprop and recursive inlining stuff.

But the behaviour is consistent with the minimal problem here.

[Bug libstdc++/101152] std::get_time %Y accepts years with less than 4 digits

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

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

--- Comment #3 from Jonathan Wakely  ---
It's not essential, but I think that would be helpful

[Bug fortran/103610] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.c:193

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2021-December/057142.html

[Bug fortran/103607] [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927

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

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

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

https://gcc.gnu.org/g:9eec77c0df9e5c67454a2e8f83246104458ba4f0

commit r12-5829-g9eec77c0df9e5c67454a2e8f83246104458ba4f0
Author: Harald Anlauf 
Date:   Tue Dec 7 21:34:31 2021 +0100

Fortran: perform array subscript checks only for valid INTEGER bounds

gcc/fortran/ChangeLog:

PR fortran/103607
* frontend-passes.c (do_subscript): Ensure that array bounds are
of type INTEGER before performing checks on array subscripts.

gcc/testsuite/ChangeLog:

PR fortran/103607
* gfortran.dg/pr103607.f90: New test.

[Bug c++/79452] Provide builtin to detect compile-time execution

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

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

--- Comment #12 from Jonathan Wakely  ---
Well this request is satisfied by std::is_constant_evaluated() in C++20, which
is what __builtin_is_constant_evaluated() exists for. PR 100974 adds a newer
C++23 language feature that makes std::is_constant_evaluated() unnecessary.
This is still resolved one easy or another though.

[Bug fortran/103610] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.c:193

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Tentative patch:

diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index e5e22099405..a23fabbdcdb 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -2330,6 +2330,9 @@ spec_dimen_size (gfc_array_spec *as, int dimen, mpz_t
*result)

   mpz_add_ui (*result, *result, 1);

+  if (mpz_cmp_si (*result, 0) < 0)
+mpz_set_si (*result, 0);
+
   return true;
 }

[Bug target/103370] [12 Regression] Assembler error building glibc for ColdFire soft-float

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

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

--- Comment #4 from Joseph S. Myers  ---
It seems this glibc build failure disappeared between commit
b880d1514c1e3dd75a6ea311a5cc956742bd713c and commit
8e836af61b7027c0819da62c12a8d18b7c46f3fc.  (Not verified that the GCC change
was what's relevant - my bot updated other components as well - but it looks
plausible.)

[Bug fortran/103610] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.c:193

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-12-07
 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Really funny.

The bug however does not need maskl/maskr:

program p
  integer, parameter :: a(-1) = 1
  integer, parameter :: c(1) = shape(a)
  print *, c
end

This prints:

  -1

instead of 0.

[Bug testsuite/103586] New test case gcc.target/powerpc/pr101324.c fails on BE

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #4 from Peter Bergner  ---
Fixed.

[Bug fortran/103607] [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 CC||anlauf at gcc dot gnu.org
   Last reconfirmed||2021-12-07
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2021-December/057139.html

[Bug testsuite/103556] [12 regression] rop test cases start failing after r12-5780

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #3 from Peter Bergner  ---
Fixed.

[Bug testsuite/103556] [12 regression] rop test cases start failing after r12-5780

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Peter Bergner :

https://gcc.gnu.org/g:4394fd67264f5de650c2c3509c001c5f7203449d

commit r12-5827-g4394fd67264f5de650c2c3509c001c5f7203449d
Author: Peter Bergner 
Date:   Tue Dec 7 14:42:38 2021 -0600

testsuite: Fix check_effective_target_rop_ok [PR103556, PR103586]

The new rop_ok effective target test doesn't correctly compute its
expression
result because a new line starts a new statement.  Solution is to remove
the new line.

2021-12-07  Peter Bergner  

gcc/testsuite/
PR testsuite/103556
PR testsuite/103586
* lib/target-supports.exp (check_effective_target_rop_ok): Remove
'\n'.

[Bug testsuite/103586] New test case gcc.target/powerpc/pr101324.c fails on BE

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Peter Bergner :

https://gcc.gnu.org/g:4394fd67264f5de650c2c3509c001c5f7203449d

commit r12-5827-g4394fd67264f5de650c2c3509c001c5f7203449d
Author: Peter Bergner 
Date:   Tue Dec 7 14:42:38 2021 -0600

testsuite: Fix check_effective_target_rop_ok [PR103556, PR103586]

The new rop_ok effective target test doesn't correctly compute its
expression
result because a new line starts a new statement.  Solution is to remove
the new line.

2021-12-07  Peter Bergner  

gcc/testsuite/
PR testsuite/103556
PR testsuite/103586
* lib/target-supports.exp (check_effective_target_rop_ok): Remove
'\n'.

[Bug middle-end/103364] s390x: TLS reference in /usr/lib64/libLLVM.so mismatches non-TLS reference in /usr/lib64/libLLVM.so

[sarah.kriesch at opensuse dot org via Gcc-bugs]

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

--- Comment #24 from Sarah Julia Kriesch  ---
There can be a dependency to this kernel bug:
https://bugzilla.suse.com/show_bug.cgi?id=1188896
We want to integrate the patch from your colleague and look, what will be
changed.

[Bug libgomp/103444] Fortran async IO is broken on FreeBSD

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

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

--- Comment #4 from kargl at gcc dot gnu.org ---
This is as far as I have gotten on this bug.  I don't know if
this is a race condition in libgfortran's async_close(), a 
problem with gcc internal threading modeling (i.e., __gthrw_),
and problem with FreeBSD libthr.  Pointers on how to go to
the next step appreciated.  I assume something in __threadid
below is amiss.

% gfcx -o z -fopenmp -g async_io_9.f90 && ./z

% gdb ./z

(gdb) b async.c:479
Breakpoint 1 at 0x200a77ff0: file ../../../gccx/libgfortran/io/async.c, line
479.
(gdb) run
Thread 1 hit Breakpoint 1, _gfortrani_async_close (au=0x201a49000)
at ../../../gccx/libgfortran/io/async.c:479
479   if (au == NULL)
(gdb) p *au
$1 = {io_lock = 0x2006da908, lock = 0x2006da888, empty = true, id = {
waiting = -1, low = 1, high = 1, done = {pending = 0, 
  signal = 0x201a230a0}}, work = {pending = 0, signal = 0x201a23060}, 
  emptysignal = {pending = 0, signal = 0x201a23080}, pdt = 0x201a4e000, 
  thread = 0x201a12700, head = 0x0, tail = 0x0, error = {message = 0x0, 
cmp = 0x0, has_error = false, last_good_id = 0, family = 0, 
fatal_error = false}}
(gdb) n
483   enqueue_close (au);
(gdb) n
484   T_ERROR (__gthread_join, au->thread, NULL);
(gdb) 

Thread 2 received signal SIGBUS, Bus error.
[Switching to LWP 180470 of process 18692]
0x000200f1ad6a in _Unwind_ForcedUnwind (exc=0x201a12938, 
stop=0x20068a030 , stop_argument=0x0)
at ../../../gccx/libgcc/unwind.inc:215
215   exc->private_1 = (_Unwind_Ptr) stop;


(gdb) run 
Thread 1 hit Breakpoint 1, _gfortrani_async_close (au=0x201a49000)
at ../../../gccx/libgfortran/io/async.c:479
479   if (au == NULL)
(gdb) n
483   enqueue_close (au);
(gdb) n
484   T_ERROR (__gthread_join, au->thread, NULL);
(gdb) s
__gthread_join (__value_ptr=0x0, __threadid=0x201a12700)
at ../libgcc/gthr-default.h:669
669   return __gthrw_(pthread_join) (__threadid, __value_ptr);
(gdb) p __value_ptr
$2 = (void **) 0x0
(gdb) p __threadid
$3 = (__gthread_t) 0x201a12700
(gdb) p *__threadid
$4 = {tid = 180471, lock = {m_owner = 0, m_flags = 0, m_ceilings = {0, 0}, 
m_rb_lnk = 0, m_spare = {0, 0}}, cycle = 0, locklevel = 0, 
  critical_count = 0, sigblock = 0, fsigblock = 0, tle = {
tqe_next = 0x201a12000, tqe_prev = 0x200699900 <_thread_list>}, gcle = {
tqe_next = 0x0, tqe_prev = 0x0}, hle = {le_next = 0x0, 
le_prev = 0x20069a128}, wle = {tqe_next = 0x0, tqe_prev = 0x201a19080}, 
  refcount = 1, start_routine = 0x200a764d0 , arg = 0x201a1df00, 
  attr = {sched_policy = 2, sched_inherit = 4, prio = 0, suspend = 0, 
flags = 2, stackaddr_attr = 0x7fffbfdfe000, stacksize_attr = 2097152, 
guardsize_attr = 4096, cpuset = 0x0, cpusetsize = 0}, cancel_enable = 1, 
  cancel_pending = 0, cancel_point = 1, no_cancel = 0, cancel_async = 0, 
  cancelling = 0, sigmask = {__bits = {0, 0, 0, 0}}, unblock_sigcancel = 0, 
  in_sigsuspend = 0, deferred_siginfo = {si_signo = 0, si_errno = 0, 
si_code = 0, si_pid = 0, si_uid = 0, si_status = 0, si_addr = 0x0, 
si_value = {sival_int = 0, sival_ptr = 0x0, sigval_int = 0, 
  sigval_ptr = 0x0}, _reason = {_fault = {_trapno = 0}, _timer = {
_timerid = 0, _overrun = 0}, _mesgq = {_mqd = 0}, _poll = {_band = 0}, 
  _capsicum = {_syscall = 0}, __spare__ = {__spare1__ = 0, __spare2__ = {
  0, 0, 0, 0, 0, 0, 0, deferred_sigmask = {__bits = {0, 0, 0, 0}}, 
  deferred_sigact = {__sigaction_u = {__sa_handler = 0x0, 
  __sa_sigaction = 0x0}, sa_flags = 0, sa_mask = {__bits = {0, 0, 0, 0}}}, 
  deferred_run = 0, force_exit = 0, state = PS_RUNNING, error = 0, 
  joiner = 0x0, flags = 0, tlflags = 2, mq = {{tqh_first = 0x0, 
  tqh_last = 0x201a128a8}, {tqh_first = 0x0, tqh_last = 0x201a128b8}, {
  tqh_first = 0x0, tqh_last = 0x201a128c8}, {tqh_first = 0x0, 
  tqh_last = 0x201a128d8}, {tqh_first = 0x0, tqh_last = 0x201a128e8}, {
  tqh_first = 0x0, tqh_last = 0x201a128f8}}, ret = 0x0, specific = 0x0, 
  specific_data_count = 0, rdlock_count = 0, rtld_bits = 0, tcb = 0x2006bc1c0, 
  cleanup = 0x0, ex = {exception_class = 0, exception_cleanup = 0x0, 
private_1 = 0, private_2 = 0}, unwind_stackend = 0x7fffbfffe000, 
  unwind_disabled = 0, magic = 3499860245, report_events = 0, event_mask = 0, 
  event_buf = {event = TD_EVENT_NONE, th_p = 0, data = 0}, wchan = 0x0, 
  mutex_obj = 0x2006da888, will_sleep = 0, nwaiter_defer = 0, 
  robust_inited = 0, robust_list = 0, priv_robust_list = 0, inact_mtx = 0, 
  defer_waiters = {0x20069a428, 0x0 }, 
  wake_addr = 0x200637000, sleepqueue = 0x201a19080, name = 0x0, 
  dlerror_msg = '\000' , dlerror_seen = 0}
(gdb) s

Thread 2 received signal SIGBUS, Bus error.
[Switching to LWP 180472 of process 18709]
0x000200f1ad6a in _Unwind_ForcedUnwind (exc=0x201a12938, 
stop=0x20068a030 , stop_argument=0x0)
at ../../../gccx/libgcc/unwind.inc:215
215   exc->private_1 = (_Unwind_Ptr) stop;

[Bug analyzer/101962] Analyzer NULL false positive with pointer manipulation

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Any update on the backport?

[Bug c++/90341] pcsx2-git: "At global scope: cc1plus: internal compiler error: Segmentation fault"

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-reduction
 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug c++/71527] wrong type mismatch while template argument deduction/substitution

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||10.1.0, 9.1.0
  Known to fail||8.5.0
   Keywords||needs-bisection,
   ||rejects-valid

--- Comment #3 from Andrew Pinski  ---
Looks fixed in GCC 9.

[Bug fortran/103610] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.c:193

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

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

$ cat z3.f90
program p
   integer, parameter :: a(-1) = 1
   integer, parameter :: b(1) = maskr(shape(a))
end


$ cat z4.f90
program p
   integer, parameter :: a(-1) = maskr(shape(a))
end


$ gfortran-12-20211205 -c z3.f90
gmp: overflow in mpz type
f951: internal compiler error: Aborted
0xf0b99f crash_signal
../../gcc/toplev.c:322
0x870a74 gfc_simplify_maskr(gfc_expr*, gfc_expr*)
../../gcc/fortran/simplify.c:4885
0x7ef826 do_simplify
../../gcc/fortran/intrinsic.c:4648
0x7fa888 gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4920
0x7e0359 gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.c:2219
0x7e0eaa scalarize_intrinsic_call
../../gcc/fortran/expr.c:2486
0x7e03ad gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.c:2227
0x7faa3e gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:5070
0x84e86c resolve_unknown_f
../../gcc/fortran/resolve.c:2972
0x84e86c resolve_function
../../gcc/fortran/resolve.c:3329
0x84e86c gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:7166
0x7df8a4 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:3155
0x7e2810 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:3203
0x7ccac4 variable_decl
../../gcc/fortran/decl.c:3004
0x7ccac4 gfc_match_data_decl()
../../gcc/fortran/decl.c:6297
0x836f03 match_word
../../gcc/fortran/parse.c:67
0x836f03 decode_statement
../../gcc/fortran/parse.c:378
0x83894a next_free
../../gcc/fortran/parse.c:1397
0x83894a next_statement
../../gcc/fortran/parse.c:1629
0x839edb parse_spec
../../gcc/fortran/parse.c:4168

[Bug fortran/103610] New: ICE in gfc_convert_mpz_to_signed, at fortran/simplify.c:193

[gscfq--- via Gcc-bugs]

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

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

Affects versions down to at least r5 :


$ cat z1.f90
program p
   integer, parameter :: a(-1) = 1
   integer, parameter :: b(1) = maskl(shape(a))
end


$ cat z2.f90
program p
   integer, parameter :: a(-1) = maskl(shape(a))
end


$ gfortran-12-20211205 -c z1.f90
f951: internal compiler error: in gfc_convert_mpz_to_signed, at
fortran/simplify.c:193
0x8288e1 gfc_convert_mpz_to_signed(__mpz_struct*, int)
../../gcc/fortran/simplify.c:193
0x830010 gfc_simplify_maskl(gfc_expr*, gfc_expr*)
../../gcc/fortran/simplify.c:4923
0x7aefd6 do_simplify
../../gcc/fortran/intrinsic.c:4648
0x7b9f98 gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4920
0x79fb09 gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.c:2219
0x7a065a scalarize_intrinsic_call
../../gcc/fortran/expr.c:2486
0x79fb5d gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.c:2227
0x7ba14e gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:5070
0x80dcac resolve_unknown_f
../../gcc/fortran/resolve.c:2972
0x80dcac resolve_function
../../gcc/fortran/resolve.c:3329
0x80dcac gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:7166
0x79f054 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:3155
0x7a1fc0 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:3203
0x78c3d4 variable_decl
../../gcc/fortran/decl.c:3004
0x78c3d4 gfc_match_data_decl()
../../gcc/fortran/decl.c:6297
0x7f6343 match_word
../../gcc/fortran/parse.c:67
0x7f6343 decode_statement
../../gcc/fortran/parse.c:378
0x7f7d8a next_free
../../gcc/fortran/parse.c:1397
0x7f7d8a next_statement
../../gcc/fortran/parse.c:1629
0x7f931b parse_spec
../../gcc/fortran/parse.c:4168

[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies

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

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

--- Comment #14 from rsandifo at gcc dot gnu.org  
---
Thanks for the nice cut-down example.

In the original comment and the covering note to patch 1,
the highlighted spilled value is the final (terminating)
value of foo + 1024.  Let's start with the SPILLED=0.51
case and consider that register ("R") in isolation without
changing anything else.

If we spill R to memory (as for the current SPILLED=0.51 code),
we generate:

- a store of R outside the loop (low execution count)
- a load of R inside the loop (after the call) with freq 0.51 * loop iters
- a load of R inside the loop with freq 0.49 * loop iters

If we force R to be allocated a call-clobbered register instead
of being spilled (and changing nothing else, via a hack to
ira-color.c:improve_allocation) then we generate:

- a store of R inside the loop (before the call) with freq 0.51 * loop iters
- a load of R inside the loop (after the call) with freq 0.51 * loop iters

So the in-loop cost of the second (allocated) version is higher
than the in-loop cost of the first (spilled) version.  As the value
of SPILLED increases, the difference between the two also increases:
spilling R gets progressively “cheaper” than the allocating a
call-clobbered register to R.

That is, we're trading two memory accesses in the call branch
(if we allocate R) against one memory access in both branches
(if we spill R).  As the call branch gets more likely,
the cost of doing two memory accesses there gets higher
relative to the cost of doing one memory access in both branches.
And that seems like the right behaviour in principle.

>From that point of view, it doesn't look like the memory and register
costs of R are too wrong here.  The things being costed are the store
and load around the call (which do exist if we allocate a call-clobbered
register) and the loads at each use site (which do exist if we spill R).

Like Feng Xue says in comment 1, I think the main missed optimisation
opportunity here is that foo + 1024 is invariant, so if we allocate
a call-clobbered register, we could save R once outside the loop
and reload it after each call.  That would give:

- a store of R outside the loop (low execution count)
- a load of R inside the loop (after the call) with freq 0.51 * loop iters

which is cheaper than both the current approaches.  We don't do that
optimisation yet though, so the current costing seems to reflect what we
currently generate.

I don't know how well the above translates to the original example
though.  Are the some of the spilled values in exchange loop-invariant
as well?

[Bug fortran/103609] [11/12 Regression] ICE in gfc_sym_get_dummy_args, at fortran/symbol.c:5243

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

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

Seems to be related :


$ cat z2.f90
program p
   implicit none
   integer :: i
   do i = 1, 2
  call s
   end do
contains
   subroutine s
  call sub(x)
   end
end


$ gfortran-12-20211205 -c z2.f90
z2.f90:9:16:

9 |   call sub(x)
  |1
Error: Symbol 'x' at (1) has no IMPLICIT type
f951: internal compiler error: Segmentation fault
0xf0b99f crash_signal
../../gcc/toplev.c:322
0x87f8f0 gfc_sym_get_dummy_args(gfc_symbol*)
../../gcc/fortran/symbol.c:5243
0x94ec51 doloop_contained_procedure_code
../../gcc/fortran/frontend-passes.c:2483
0x954519 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5333
0x956a32 doloop_code
../../gcc/fortran/frontend-passes.c:2627
0x954519 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5333
0x954697 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5669
0x95570b doloop_warn
../../gcc/fortran/frontend-passes.c:3059
0x955c5a gfc_run_passes(gfc_namespace*)
../../gcc/fortran/frontend-passes.c:156
0x856467 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17572
0x83e764 resolve_all_program_units
../../gcc/fortran/parse.c:6586
0x83e764 gfc_parse_file()
../../gcc/fortran/parse.c:6842
0x88c73f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug fortran/103609] New: [11/12 Regression] ICE in gfc_sym_get_dummy_args, at fortran/symbol.c:5243

[gscfq--- via Gcc-bugs]

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

Bug ID: 103609
   Summary: [11/12 Regression] ICE in gfc_sym_get_dummy_args, at
fortran/symbol.c:5243
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20200726 and 20200809 :
(gcc configured with --enable-checking=yes)


$ cat z1.f90
program p
   implicit none
   integer :: i
   do i = 1, 2
  call s
   end do
contains
   subroutine s
  integer :: n
  call n
   end
end


$ gfortran-12-20211205 -c z1.f90
z1.f90:9:18:

9 |   integer :: n
  |  1
   10 |   call n
  |2
Error: 'n' at (1) has a type, which is not consistent with the CALL at (2)
f951: internal compiler error: Segmentation fault
0xf0b99f crash_signal
../../gcc/toplev.c:322
0x87f8f0 gfc_sym_get_dummy_args(gfc_symbol*)
../../gcc/fortran/symbol.c:5243
0x94ec51 doloop_contained_procedure_code
../../gcc/fortran/frontend-passes.c:2483
0x954519 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5333
0x956a32 doloop_code
../../gcc/fortran/frontend-passes.c:2627
0x954519 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5333
0x954697 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5669
0x95570b doloop_warn
../../gcc/fortran/frontend-passes.c:3059
0x955c5a gfc_run_passes(gfc_namespace*)
../../gcc/fortran/frontend-passes.c:156
0x856467 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17572
0x83e764 resolve_all_program_units
../../gcc/fortran/parse.c:6586
0x83e764 gfc_parse_file()
../../gcc/fortran/parse.c:6842
0x88c73f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug fortran/103608] New: ICE in do_intent, at fortran/frontend-passes.c:3035

[gscfq--- via Gcc-bugs]

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

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

Affects versions down to at least r5 :
(gcc configured with --enable-checking=yes)


$ cat z1.f90
program p
   integer :: i, x
   x(*) = 0
   do i = 1, 2
  call s(x(i))
   end do
end


$ cat z2.f90
program p
   integer :: i, x
   x(*) = 0
   do i = 1, 2
  print *, x(i)
   end do
end


$ cat z3.f90
program p
   integer :: i, x
   x(*) = 0
   print *, (x(i), i=1,2)
end


$ gfortran-12-20211205 -c z1.f90
z1.f90:2:18:

2 |integer :: i, x
  |  1
Error: Alternate return specifier in function 'x' at (1) is not allowed
z1.f90:5:13:

5 |   call s(x(i))
  | 1
Error: Missing alternate return specifier in subroutine call at (1)
f951: internal compiler error: Segmentation fault
0xf0b99f crash_signal
../../gcc/toplev.c:322
0x9564d5 do_intent
../../gcc/fortran/frontend-passes.c:3035
0x9564d5 do_function
../../gcc/fortran/frontend-passes.c:2699
0x952495 gfc_expr_walker(gfc_expr**, int (*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5223
0x9554f3 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5392
0x954697 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5669
0x95570b doloop_warn
../../gcc/fortran/frontend-passes.c:3059
0x955c5a gfc_run_passes(gfc_namespace*)
../../gcc/fortran/frontend-passes.c:156
0x856467 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17572
0x83e764 resolve_all_program_units
../../gcc/fortran/parse.c:6586
0x83e764 gfc_parse_file()
../../gcc/fortran/parse.c:6842
0x88c73f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug fortran/103607] New: [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927

[gscfq--- via Gcc-bugs]

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

Bug ID: 103607
   Summary: [9/10/11/12 Regression] ICE in do_subscript, at
fortran/frontend-passes.c:2927
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r8, before 20180525 :
(gcc configured with --enable-checking=yes)


$ cat z1.f90
program p
   integer :: i, x(abs(2.))
   do i = 1, 2
  x(i) = 0
   end do
end


$ gfortran-12-20211205 -c z1.f90
z1.f90:2:19:

2 |integer :: i, x(abs(2.))
  |   1
Error: Expression at (1) must be of INTEGER type, found REAL
z1.f90:2:27:

2 |integer :: i, x(abs(2.))
  |   1
Error: The module or main program array 'x' at (1) must have constant shape
f951: internal compiler error: Segmentation fault
0xf0b99f crash_signal
../../gcc/toplev.c:322
0x956154 do_subscript
../../gcc/fortran/frontend-passes.c:2927
0x956154 do_function
../../gcc/fortran/frontend-passes.c:2706
0x952495 gfc_expr_walker(gfc_expr**, int (*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5223
0x954601 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5661
0x954697 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5669
0x95570b doloop_warn
../../gcc/fortran/frontend-passes.c:3059
0x955c5a gfc_run_passes(gfc_namespace*)
../../gcc/fortran/frontend-passes.c:156
0x856467 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17572
0x83e764 resolve_all_program_units
../../gcc/fortran/parse.c:6586
0x83e764 gfc_parse_file()
../../gcc/fortran/parse.c:6842
0x88c73f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug fortran/103606] [9/10/11/12 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13297

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

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

Adding this attribute yields a still invalid but non-ICE-ing code :


$ cat z2.f90
program p
   type t
   end type
contains
   elemental function f() result(z)
  class(t), allocatable :: z
   end
end


$ gfortran-12-20211205 -c z2.f90
z2.f90:5:35:

5 |elemental function f() result(z)
  |   1
Error: Function result variable 'z' at (1) of elemental function 'f' shall not
have an ALLOCATABLE or POINTER attribute

[Bug fortran/103606] New: [9/10/11/12 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13297

[gscfq--- via Gcc-bugs]

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

Bug ID: 103606
   Summary: [9/10/11/12 Regression] ICE in resolve_fl_procedure,
at fortran/resolve.c:13297
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With a missing attribute allocatable or pointer, started with r7 :
(gcc configured with --enable-checking=yes)


$ cat z1.f90
program p
   type t
   end type
contains
   elemental function f() result(z)
  class(t) :: z
   end
end


$ gfortran-12-20211205 -c z1.f90
z1.f90:5:35:

5 |elemental function f() result(z)
  |   1
Error: CLASS variable 'z' at (1) must be dummy, allocatable or pointer
f951: internal compiler error: Segmentation fault
0xf0b99f crash_signal
../../gcc/toplev.c:322
0x859de6 resolve_fl_procedure
../../gcc/fortran/resolve.c:13297
0x859de6 resolve_symbol
../../gcc/fortran/resolve.c:16110
0x876b52 do_traverse_symtree
../../gcc/fortran/symbol.c:4174
0x85af84 resolve_types
../../gcc/fortran/resolve.c:17449
0x85642c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17564
0x83e764 resolve_all_program_units
../../gcc/fortran/parse.c:6586
0x83e764 gfc_parse_file()
../../gcc/fortran/parse.c:6842
0x88c73f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug c++/66641] An instance of an attribute-specifier-seq implies a simple-declaration while C++11 permits attribute-declaration and using-directive

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||101582
   Target Milestone|--- |12.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Andrew Pinski  ---
the using case was fixed with r12-2871-g3890c28ac5b .

The empty case was PR 101582.

So all fixed.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101582
[Bug 101582] C++ FE doesn't accept attribute-declaration

[Bug c++/101582] C++ FE doesn't accept attribute-declaration

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Keywords||rejects-valid

[Bug c++/66641] An instance of an attribute-specifier-seq implies a simple-declaration while C++11 permits attribute-declaration and using-directive

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.2.0
   Keywords||rejects-valid

--- Comment #2 from Andrew Pinski  ---
This is fixed on the trunk. Let me find the commit which fixed it.

[Bug c++/100974] [C++23] Implement if consteval

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gonzalo.gadeschi at gmail dot 
com

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

[Bug c++/79452] Provide builtin to detect compile-time execution

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
This is done for C++23 but GCC implements __builtin_is_constant_evaluated also
for old C++ standards.

Anyways this is a dup of bug 100974.

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

[Bug c++/69836] compilation error with constexpr in template types with redeclared methods

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> I wonder if this is just invalid code but no diagnostic required as state
> changes inside the scope of TemplateObject.

That is it needs to be reinterpret it after the parsing and needs to same
inside the scope itself. Like types of the same name should stay the same if
used inside the class.

Like:

typedef int t;
class y
{
  typedef t u;
  typedef float t;
};
Which GCC only handles currently:
:5:17: error: declaration of 'typedef float y::t' changes meaning of
't' [-fpermissive]
5 |   typedef float t;
  | ^
:1:13: note: 't' declared here as 'typedef int t'
1 | typedef int t;
  | ^

[Bug c++/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

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

[Bug c++/69836] compilation error with constexpr in template types with redeclared methods

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

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

--- Comment #2 from Andrew Pinski  ---
I wonder if this is just invalid code but no diagnostic required as state
changes inside the scope of TemplateObject.

[Bug libstdc++/101152] std::get_time %Y accepts years with less than 4 digits

[development at jordi dot vilar.cat via Gcc-bugs]

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

--- Comment #2 from Jordi Vilar  ---
(In reply to Jonathan Wakely from comment #1)
> I think the bug is that it treats 03 as 1903 instead of 0003. It is not
> supposed to print "N/A" though.
> 
> %Y doesn't require exactly 4 digits, it allows 1-4 and interprets the value
> read as the year (rather than interpreting it as a year between 1969 and
> 2068 like %y). So if it reads "20" that isn't an error, it means the year 20
> A.D.

Yes, you are right, "including the century" doesn't imply four digits for dates
before the 1000 A.D. Should I update the title accordingly?

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

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

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

--- Comment #5 from Jakub Jelinek  ---
Completely untested patch to set the flag when a label is only known reachable
through fallthrough from previous instructions, never jumped to, as the only
goto to it is on a non-executable branch of GIMPLE_COND with constant
condition.
--- gcc/tree.h.jj   2021-11-29 14:24:14.121633747 +0100
+++ gcc/tree.h  2021-12-07 19:26:06.645324657 +0100
@@ -787,6 +787,12 @@ extern void omp_clause_range_check_faile
 #define SWITCH_BREAK_LABEL_P(NODE) \
   (LABEL_DECL_CHECK (NODE)->base.protected_flag)

+/* Set on label that is known not to be jumped to, it can be only
+   reached by falling through from previous statements.
+   This is used to implement -Wimplicit-fallthrough.  */
+#define UNUSED_LABEL_P(NODE) \
+  (LABEL_DECL_CHECK (NODE)->base.default_def_flag)
+
 /* Nonzero means this expression is volatile in the C sense:
its address should be of type `volatile WHATEVER *'.
In other words, the declared item is volatile qualified.
--- gcc/gimplify.c.jj   2021-12-02 19:41:52.620552908 +0100
+++ gcc/gimplify.c  2021-12-07 19:49:43.964134745 +0100
@@ -4387,9 +4387,19 @@ gimplify_cond_expr (tree *expr_p, gimple
   if (TREE_OPERAND (expr, 1) == NULL_TREE
  && !have_else_clause_p
  && TREE_OPERAND (expr, 2) != NULL_TREE)
-   label_cont = label_true;
+   {
+ /* For if (0) {} else { code; } tell -Wimplicit-fallthrough
+handling that label_cont == label_true can be only reached
+through fallthrough from { code; }.  */
+ if (integer_zerop (COND_EXPR_COND (expr)))
+   UNUSED_LABEL_P (label_true) = 1;
+ label_cont = label_true;
+   }
   else
{
+ bool then_side_effects
+   = (TREE_OPERAND (expr, 1)
+  && TREE_SIDE_EFFECTS (TREE_OPERAND (expr, 1)));
  gimplify_seq_add_stmt (&seq, gimple_build_label (label_true));
  have_then_clause_p = gimplify_stmt (&TREE_OPERAND (expr, 1), &seq);
  /* For if (...) { code; } else {} or
@@ -4403,6 +4413,16 @@ gimplify_cond_expr (tree *expr_p, gimple
  gimple *g;
  label_cont = create_artificial_label (UNKNOWN_LOCATION);

+ /* For if (0) { non-side-effect-code } else { code }
+tell -Wimplicit-fallthrough handling that label_cont can
+be only reached through fallthrough from { code }.  */
+ if (integer_zerop (COND_EXPR_COND (expr)))
+   {
+ UNUSED_LABEL_P (label_true) = 1;
+ if (!then_side_effects)
+   UNUSED_LABEL_P (label_cont) = 1;
+   }
+
  g = gimple_build_goto (label_cont);

  /* GIMPLE_COND's are very low level; they have embedded
@@ -4419,6 +4439,13 @@ gimplify_cond_expr (tree *expr_p, gimple
 }
   if (!have_else_clause_p)
 {
+  /* For if (1) { code } or if (1) { code } else { non-side-effect-code }
+tell -Wimplicit-fallthrough handling that label_false can be only
+reached through fallthrough from { code }.  */
+  if (integer_nonzerop (COND_EXPR_COND (expr))
+ && (TREE_OPERAND (expr, 2) == NULL_TREE
+ || !TREE_SIDE_EFFECTS (TREE_OPERAND (expr, 2
+   UNUSED_LABEL_P (label_false) = 1;
   gimplify_seq_add_stmt (&seq, gimple_build_label (label_false));
   have_else_clause_p = gimplify_stmt (&TREE_OPERAND (expr, 2), &seq);
 }

[Bug testsuite/103556] [12 regression] rop test cases start failing after r12-5780

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

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

Peter Bergner  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Decembe
   ||r/586345.html
 Status|NEW |ASSIGNED

[Bug c++/83469] union is not accepted as a valid class-key in template name resolution

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Decembe
   ||r/586344.html

--- Comment #7 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586344.html

[Bug c++/93809] bogus error class tag used in naming union on typedef typename ::U U2

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Decembe
   ||r/586344.html
   Keywords||patch

--- Comment #6 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586344.html

[Bug fortran/103588] ICE: Simplification error in gfc_ref_dimen_size, at fortran/array.c:2407

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

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

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

https://gcc.gnu.org/g:652c28736209f10bac1aa7ecb31f9056b518dacf

commit r12-5826-g652c28736209f10bac1aa7ecb31f9056b518dacf
Author: Harald Anlauf 
Date:   Tue Dec 7 18:46:52 2021 +0100

Fortran: catch failed simplification of bad stride expression

gcc/fortran/ChangeLog:

PR fortran/103588
* array.c (gfc_ref_dimen_size): Do not generate internal error on
failed simplification of stride expression; just return failure.

gcc/testsuite/ChangeLog:

PR fortran/103588
* gfortran.dg/pr103588.f90: New test.

[Bug fortran/103591] ICE in gfc_compare_string, at fortran/arith.c:1119

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

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

Thanks for the report!

[Bug fortran/103591] ICE in gfc_compare_string, at fortran/arith.c:1119

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

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

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

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

commit r12-5825-gf47662204de27f7685699eeef89aa173ccf32d85
Author: Harald Anlauf 
Date:   Mon Dec 6 23:15:11 2021 +0100

Fortran: add check for type of upper bound in case range

gcc/fortran/ChangeLog:

PR fortran/103591
* match.c (match_case_selector): Check type of upper bound in case
range.

gcc/testsuite/ChangeLog:

PR fortran/103591
* gfortran.dg/select_9.f90: New test.

[Bug libstdc++/101152] std::get_time %Y accepts years with less than 4 digits

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-12-07

--- Comment #1 from Jonathan Wakely  ---
I think the bug is that it treats 03 as 1903 instead of 0003. It is not
supposed to print "N/A" though.

%Y doesn't require exactly 4 digits, it allows 1-4 and interprets the value
read as the year (rather than interpreting it as a year between 1969 and 2068
like %y). So if it reads "20" that isn't an error, it means the year 20 A.D.

[Bug libstdc++/71557] time_get is case sensitive

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-12-07

[Bug testsuite/103586] New test case gcc.target/powerpc/pr101324.c fails on BE

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

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Target Milestone|--- |12.0
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org

--- Comment #2 from Peter Bergner  ---
(In reply to Martin Liška from comment #1)
> @Peter: Can you please take a look?

Mine.  This is a bug in the new rop_ok target-supports.exp change (worked on
LE).  This test shouldn't be run on BE/ELFv1.  I have a fix which I'll submit
today.

[Bug c++/103598] [12 regression] __PRETTY_FUNCTION_ lost namespaces in types since r12-5783-gf78eaffd1538efb4

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
semi-related: bug 30812 (also about the stableness of __PRETTY_FUNCTION__
output, albeit for a different aspect of it)

[Bug c++/103600] Cannot use typeid result in constant expressions

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 51945
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51945&action=edit
gcc12-pr103600.patch

Untested patch that should make typeid(x) == typeid(y) and &typeid(x) ==
&typeid(y) work, but don't want to duplicate , so for a testcase I'd
need to wait (at least for the former case) until the libstdc++ change lands.

[Bug target/103605] [PowerPC] fmin/fmax should be inlined always with xsmindp/xsmaxdp

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

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

--- Comment #1 from pc at gcc dot gnu.org ---
$ cat fmin.c
#include 
double fm (double d0, double d1) {
  return fmin (d0, d1);
}

[Bug target/103605] New: [PowerPC] fmin/fmax should be inlined always with xsmindp/xsmaxdp

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

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

Bug ID: 103605
   Summary: [PowerPC] fmin/fmax should be inlined always with
xsmindp/xsmaxdp
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pc at gcc dot gnu.org
  Target Milestone: ---

--
$ gcc --version
gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-2)
[...]
$ gcc -c -O2 fmin.c && objdump -dr fmin.o
   0:   00 00 4c 3c addis   r2,r12,0
0: R_PPC64_REL16_HA .TOC.
   4:   00 00 42 38 addir2,r2,0
4: R_PPC64_REL16_LO .TOC.+0x4
   8:   a6 02 08 7c mflrr0
   c:   10 00 01 f8 std r0,16(r1)
  10:   e1 ff 21 f8 stdur1,-32(r1)
  14:   01 00 00 48 bl  14 
14: R_PPC64_REL24   fmin
  18:   00 00 00 60 nop
  1c:   20 00 21 38 addir1,r1,32
  20:   10 00 01 e8 ld  r0,16(r1)
  24:   a6 03 08 7c mtlrr0
  28:   20 00 80 4e blr
$ gcc -c -O2 fmin.c -ffast-math && objdump -dr fmin.o
   0:   40 14 21 f0 xsmincdp vs1,vs1,vs2
   4:   20 00 80 4e blr
--

And it appears that a better instruction choice in the above case is xsmindp,
and it can be used with and without "-ffast-math", as it matches the semantics
required of fmin.  Similarly, xsmaxdp with fmax.

[Bug testsuite/103545] [12 regression] gcc.target/powerpc/undef-bool-2.c fails after r12-5580

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

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

pc at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pc at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||pc at gcc dot gnu.org

--- Comment #2 from pc at gcc dot gnu.org ---
Fixed on trunk (commit above).

[Bug tree-optimization/103603] [11 Regression] stack overflow on ranger for huge program, but OK for legacy

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Andrew Macleod  ---
Created attachment 51944
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51944&action=edit
Ported patch

See if this works. I'll run it through testing, but this should be a port of
the patches from PR 103231 and the followup PR 103464  
There are some minor differences, but nothing too major.

[Bug c++/103553] Show what decltype deduced in static_assert

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

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

--- Comment #2 from Marek Polacek  ---
Yes, I added that in GCC 11.

To make this work, I think we'll have to print parser->scope when there's one. 
In this case it's

full-name "struct is_same"

so that could be extracted and used in finish_static_assert.

[Bug c++/84516] bitfield temporaries > 32-bits have wrong type

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

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

Bug 95009 Summary: [9/10 Regression] decltype of increment or decrement 
bitfield expressions are wrong and causes assembler errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95009

   What|Removed |Added

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

[Bug c++/70733] Wrong code with nested structs and bit field.

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

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

Bug 95009 Summary: [9/10 Regression] decltype of increment or decrement 
bitfield expressions are wrong and causes assembler errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95009

   What|Removed |Added

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

[Bug c++/95009] [9/10 Regression] decltype of increment or decrement bitfield expressions are wrong and causes assembler errors.

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10/11 Regression]|[9/10 Regression] decltype
   |decltype of increment or|of increment or decrement
   |decrement bitfield  |bitfield expressions are
   |expressions are wrong and   |wrong and causes assembler
   |causes assembler errors.|errors.
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #8 from Marek Polacek  ---
Fixed for GCC 11+.

[Bug c++/95009] [9/10/11 Regression] decltype of increment or decrement bitfield expressions are wrong and causes assembler errors.

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Marek Polacek
:

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

commit r11-9363-ge3fab19a79e3dc3cdf3e54ca20107e1dc15a3927
Author: Marek Polacek 
Date:   Sat Dec 4 12:07:41 2021 -0500

c++: Fix for decltype and bit-fields [PR95009]

Here, decltype deduces the wrong type for certain expressions involving
bit-fields.  Unlike in C, in C++ bit-field width is explicitly not part
of the type, so I think decltype should never deduce to 'int:N'.  The
problem isn't that we're not calling unlowered_expr_type--we are--it's
that is_bitfield_expr_with_lowered_type only handles certain codes, but
not others.  For example, += works fine but ++ does not.

This also fixes decltype-bitfield2.C where we were crashing (!), but
unfortunately it does not fix 84516 or 70733 where the problem is likely
a missing call to unlowered_expr_type.  It occurs to me now that typeof
likely has had the same issue, but this patch should fix that too.

PR c++/95009

gcc/cp/ChangeLog:

* typeck.c (is_bitfield_expr_with_lowered_type) :
Handle UNARY_PLUS_EXPR, NEGATE_EXPR, NON_LVALUE_EXPR, BIT_NOT_EXPR,
P*CREMENT_EXPR too.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/decltype-bitfield1.C: New test.
* g++.dg/cpp0x/decltype-bitfield2.C: New test.

(cherry picked from commit 3a2257e6b3fa288d6c50831987949b9ff7dfb865)

[Bug c++/103593] [11/12 Regression] Naming the constructor of a template class without using the injected-class-name causes parse error with C++20

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

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

--- Comment #4 from Marek Polacek  ---
Yup, just the diagnostic is really bad because I still haven't fixed bug 97202
:(

[Bug c++/103593] [11/12 Regression] Naming the constructor of a template class without using the injected-class-name causes parse error with C++20

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #3 from Patrick Palka  ---
So I suppose CWG2237 means we're correct to reject this testcase in C++20 mode.
 See also http://eel.is/c++draft/diff.cpp17.class#2

[Bug tree-optimization/103603] [11 Regression] stack overflow on ranger for huge program, but OK for legacy

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

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

--- Comment #2 from Kito Cheng  ---
Oh, apologize for misleading, it should fixed via pr103231 rather than
pr103254.

it work after g:5deacf6058d1bc7261a75c9fd1f116c4442e9e60, no new file, but it's
not trivial backport-able.

[Bug c++/103593] [11/12 Regression] Naming the constructor of a template class without using the injected-class-name causes parse error with C++20

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

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-12-07
   Keywords|needs-bisection |

--- Comment #2 from Patrick Palka  ---
Started with r11-532.

[Bug c++/95009] [9/10/11 Regression] decltype of increment or decrement bitfield expressions are wrong and causes assembler errors.

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10/11 Regression]
   |decltype of increment or|decltype of increment or
   |decrement bitfield  |decrement bitfield
   |expressions are wrong and   |expressions are wrong and
   |causes assembler errors.|causes assembler errors.

--- Comment #6 from Marek Polacek  ---
Fixed on trunk so far, will backport to gcc 11.

[Bug target/99531] [9/10/11/12 Regression] Performance regression since gcc 9 (argument passing / register allocation)

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

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

--- Comment #4 from Vladimir Makarov  ---
  Thank you for reporting this.  It is true my patch caused this.

  I've reproduced the bug on master too.  I will be working on this PR.  I
think a fix will be ready on the next week the best as the fix will touch cost
calculations and will require a lot of testing on different targets.

[Bug c++/103600] Cannot use typeid result in constant expressions

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

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

--- Comment #5 from Jonathan Wakely  ---
The new definition of operator== will be something like:

#if __GXX_TYPEINFO_EQUALITY_INLINE || __cplusplus > 202002L
  _GLIBCXX23_CONSTEXPR inline bool
  type_info::operator==(const type_info& __arg) const _GLIBCXX_NOEXCEPT
  {
if (__name == __arg.__name)
  return true;

if (!std::__is_constant_evaluated())
  return false;

#if !__GXX_TYPEINFO_EQUALITY_INLINE
// ABI requires comparisons to be non-inline.
return __equal(__arg);
#elif !__GXX_MERGED_TYPEINFO_NAMES
// Need to do string comparison.
return __name[0] != '*' && __builtin_strcmp (__name, __arg.name()) == 0;
#else
return false;
#endif
  }
# endif


i.e. no strcmp for the constant evaluation case. During constant evaluation I
think we only need to handle types that are completely defined in the current
TU, so we can ignore aliasing of _ZTi symbols, and we can ignore the problem of
non-unique std::type_info objects. Within the TU they will be unique.

[Bug d/103604] [12 Regression] trunk 20210506 fails to build in libphobos on mips64el-linux-gnu

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-12-07
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Martin Liška  ---
Can you please paste output of config.log file?