[Bug fortran/104332] [9/10/11/12 Regression] ICE in resolve_symbol, at fortran/resolve.cc:15815

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.5

[Bug fortran/104331] [10/11 Regression] ICE in gfc_simplify_eoshift, at fortran/simplify.cc:2590

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/104329] [12 Regression] ICE in resolve_omp_atomic, at fortran/openmp.cc:7827 (etc.)

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Priority|P3  |P4

[Bug target/104327] [12 Regression] Inlining error on s390x since r12-1039

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||s390x

--- Comment #2 from Richard Biener  ---
Guess this will hit all targets that have the bogus code special-casing NULL
DECL_FUNCTION_SPECIFIC_TARGET in their target hook instead of using the global
options node for that case.

[Bug ipa/104325] [9/10/11/12 Regression] undefined reference to `virtual thunk to ...' since r9-4254-g12485662c00914ed

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #2 from Richard Biener  ---
I think we have similar duplicates (but always for mingw or so)

Re: [PATCH] gcc-12: Mention -mharden-sls= and -mindirect-branch-cs-prefix

[Richard Biener via Gcc-patches]

On Tue, 1 Feb 2022, H.J. Lu wrote:


LGTM.

> ---
>  htdocs/gcc-12/changes.html | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> index 2719b9d5..479bd6c5 100644
> --- a/htdocs/gcc-12/changes.html
> +++ b/htdocs/gcc-12/changes.html
> @@ -387,6 +387,12 @@ a work-in-progress.
>x86 systems with SSE2 enabled. Without {-mavx512fp16},
>all operations will be emulated in software and float
>instructions.
> +  Mitigation against straight line speculation (SLS) for function
> +  return and indirect jump is supported via
> +  -mharden-sls=[none|all|return|indirect-jmp].
> +  
> +  Add CS prefix to call and jmp to indirect thunk with branch target
> +  in r8-r15 registers via -mindirect-branch-cs-prefix.
>
>  
>  

[Bug fortran/104340] Derived type interface Array spec clobbered

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-02-02
 Ever confirmed|0   |1
 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Likely, a duplicate of one of the the 20 or 30 bug reports about
parameterized derived types.

Workaround 1.  Make COPY_TYPE a contained procedures to get an 
explicit interface.  Remove the external statement and the
interface block.

program test_derived_types

   implicit none

   integer, parameter :: n = 10
   integer :: i
   type :: tp(nx)
  integer, len :: nx
  real, dimension(nx) :: x
   end type tp
   type(tp(n)) :: a
   type(tp(n)) :: b

   do i = 1, n
  a%x(i) = i
   end do

   call copy_type(n, a, b)

   contains
  subroutine copy_type(n, a, b)
 integer, intent(in) :: n
 type(tp(n)), intent(in)  :: a
 type(tp(n)), intent(out) :: b
 b = a
  end subroutine copy_type
end program test_derived_types

[Bug middle-end/95115] RISC-V 64: inf/inf division optimized out, invalid operation not raised

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Xi Ruoyao :

https://gcc.gnu.org/g:8799006ab889b8bd8a6d6fbea5ddb64a17b2e541

commit r11-9531-g8799006ab889b8bd8a6d6fbea5ddb64a17b2e541
Author: Xi Ruoyao 
Date:   Mon Jan 31 01:15:20 2022 +0800

fold-const: do not fold NaN result from non-NaN operands [PR95115]

These operations should raise an invalid operation exception at runtime.
So they should not be folded during compilation unless -fno-trapping-math
is used.

gcc/
PR middle-end/95115
* fold-const.c (const_binop): Do not fold NaN result from
  non-NaN operands.

gcc/testsuite
* gcc.dg/pr95115.c: New test.

(cherry picked from commit 34afa19d29c5bf0b0f504e4d0aca4e9a8bc82c5c)

[Bug debug/104337] [9/10/11/12 Regression] ICE when compiling with optimize attribute and always_inline at -m32 -g3 -O0

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed. We inline c but something goes wrong otherwise.

[Bug debug/104337] [9/10/11/12 Regression] ICE when compiling with optimize attribute at -m32 -g3 -O0

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |9.0
  Known to fail||11.2.0, 9.1.0
  Known to work||6.1.0, 7.1.0, 8.1.0, 8.5.0
Summary|ICE when compiling with |[9/10/11/12 Regression] ICE
   |optimize attribute at -m32  |when compiling with
   |-g3 -O0 |optimize attribute at -m32
   ||-g3 -O0

[Bug tree-optimization/101822] Codegen bug for popcount

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
The code that was added to fix PR 71016 is causing this. Looks like there needs
to be a better way of doing this.

[Bug preprocessor/78287] #line directive with value more than 2147483640 prints out the value twice

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |11.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=99325

[Bug c++/77792] Generic lamdba scope issue when working with list::remove_if

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |7.0

--- Comment #6 from Andrew Pinski  ---
Fixed. g++.dg/cpp1y/pr77585.C does seem to cover this enough really.

[Bug fortran/69695] slice of an array retains pointer attribute

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug fortran/69695] slice of an array retains pointer attribute

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed. the two testcases added seems to represent the original testcase.

[Bug c++/99811] ICE: tree check: accessed elt 2 of 'tree_vec' with 1 elts in tsubst_pack_expansion, at cp/pt.c:13002

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |11.0
 Resolution|--- |FIXED

--- Comment #6 from Andrew Pinski  ---
Fixed.
Even though the original testcase was invalid, there was valid testcases which
was added with g++.dg/cpp2a/concepts-lambda16.C .

[Bug c++/104326] Deduction failure for parameter pack in template template non-type parameter

[colavitam at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Michael Colavita  ---
This is a slightly different case, but if you change

-   template  typename... Outer,
+   template  typename... Outer,

it is accepted by both MSVC and clang (whereas gcc now rejects both test1 and
test2). ICC still ICEs.

[Bug fortran/104340] New: Derived type interface Array spec clobbered

[river.02.soles at icloud dot com via Gcc-bugs]

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

Bug ID: 104340
   Summary: Derived type interface Array spec clobbered
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: river.02.soles at icloud dot com
  Target Milestone: ---

Created attachment 52326
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52326=edit
A minimum working example for compiler failure on derived type interfaces.

Trying to use gfortran to compile a Fortran program that uses derived types.
gfortran crashes and requests a bug report. The program code
`derived_type_err.f03` that triggers the error is attached.

Another issue can be observed, when the line `EXTERNAL :: COPY_TYPE` is
commented and the `INTERFACE` block that precedes it is uncommented (this is
valid code), gfortran complains about NX not having an implicit type (an
incorrect error message). Executing the following command gives:

  $ gfortran -o test derived_type_issue.f03

  f951: internal compiler error: gfc_compare_array_spec(): Array spec clobbered


Attempting to explicitly define the `INTERFACE` by commenting out the
`EXTERNAL` line yields a different (incorrect) error raised by the compiler:

  $ gfortran -o test derived_type_issue.f03

  derived_type_error.f03:35:28:

 35 |   REAL, DIMENSION(NX) :: X
|1
  Error: Symbol 'nx' at (1) has no IMPLICIT type; did you mean 'n'?


Both of these errors indicate that the semantics of the source code are not
correctly being parsed.

[Bug c++/104326] Deduction failure for parameter pack in template template non-type parameter

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

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

--- Comment #3 from Andrew Pinski  ---
Hmm, only clang is able to accept the code.
MSVC rejects it with:
(13): error C3520: 'Types': parameter pack must be expanded in this
context


While ICC ICEs after an error message:
(10): error: parameter pack "Types" was referenced but not expanded
  template  typename... Outer,
^

(11): error: parameter pack "Types" was referenced but not expanded
  Types... Inner
  ^

(19): internal error: null pointer
  Test, O2<2>>> test1;
^

[Bug c++/85846] [Concepts] Concept as value in initializer: bogus declared-as-implicit-template error

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||hewillk at gmail dot com

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

[Bug c++/99923] Rejects valid if statement with default argument concept

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Palka  ---
Fixed on 11.3/12 by r11-9388/r12-5053, so let's call this a dup of PR85846

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

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||lto, wrong-code
   Severity|normal  |blocker

--- Comment #2 from Andrew Pinski  ---
>So most probably LTO bootstrap is the trigger :(.

Maybe you could throw some "#pragma GCC optimize" in some files to figure out
which file has the function that is being miscompiled. Maybe then narrow it
down using the optimize attribute?

[Bug tree-optimization/99997] Missed optimisation with -Os

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Part of the fix is PR 104339 but the code which was added to fix PR 71016 is
what is really causing the issue. We need to figure out how to improve the code
that handles the fix for PR 71016.

[Bug tree-optimization/104339] Missing phiopt due to cast

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
I have a fix which I will be submitting once GCC 13 opens up.
Basically for factor_out_conditional_conversion instead of checking
dominatation, check to see if the cast is only used in the PHI.

This allows us to take:
  y_5 = -y_2(D);
  yy_6 = (int) y_5;
  if (y_2(D) != 0)
goto ; [INV]
  else
goto ; [INV]

   :

   :
  # tt_1 = PHI <0(2), yy_6(3)>

And and factor out the cast in phiopt1 and then allows us to change the whole
if to a straight line of -y_2(D).

>From phiopt1 with details:
PHI tt_1 changed to factor conversion out from COND_EXPR.
New stmt with CAST that defines tt_1.
Removing basic block 3
;; basic block 3, loop depth 0
;;  pred:   2
;;  succ:   4


COND_EXPR in block 2 and PHI in block 4 converted to straightline code.
Merging blocks 2 and 4
fix_loop_structure: fixing up loops for function

[Bug tree-optimization/104339] New: Missing phiopt due to cast

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

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

Bug ID: 104339
   Summary: Missing phiopt due to cast
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
int f(unsigned short y)
{
unsigned short t =y;
   int tt = y;
   y = -y;
   int yy = y;
   if (t) tt = y;
   return tt;
}

--- CUT ---
We should be able to optimize this to:
  y_3 = -y_2(D);
  tt_1 = (int) y_3;

But currently don't do a few things.

[PATCH 5/5] cris: Reload using special-regs before general-regs

[Hans-Peter Nilsson via Gcc-patches]

On code where reload has an effect (i.e. quite rarely, just enough to be
noticeable), this change gets code quality back to the situation prior
to "Remove CRIS v32 ACR artefacts".  We had from IRA a pseudoregister
marked to be reloaded from a union of all allocatable registers (here:
SPEC_GENNONACR_REGS) but where the register-class corresponding to the
constraint for the register-type alternative (here: GENERAL_REGS) was
*not* a subset of that class: SPEC_GENNONACR_REGS (and GENNONACR_REGS)
had a one-register "hole" for the ACR register, a register present in
GENERAL_REGS.

Code in reload.cc:find_reloads adds 4 to the cost of a register-type
alternative that is neither a subset of the preferred register class nor
vice versa and thus reload thinks it can't use.  It would be preferable
to look for a non-empty intersection of the two, and use that
intersection for that alternative, something that can't be expressed
because a register class can't be formed from a random register set.

The effect was here that the GENERAL_REGS to/from memory alternatives
("r") had their cost raised such that the SPECIAL_REGS alternatives
("x") looked better.  This happened to improve code quality just a
little bit compared to GENERAL_REGS being chosen.

Anyway, with the improved CRIS register-class topology, the
subset-checking code no longer has the GENERAL_REGS-demoting effect.
To get the same quality, we have to adjust the port such that
SPECIAL_REGS are specifically preferred when possible and advisible,
i.e. when there's at least two of those registers as for the CPU variant
with multiplication (which happens to be the variant maintained for
performance).

For the move-pattern, the obvious method may seem to simply "curse" the
constraints of some alternatives (by prepending one of the "?!^$"
characters) but that method can't be used, because we want the effect to
be conditional on the CPU variant.  It'd also be a shame to split the
"*movsi_internal" into two CPU-variants (with
different cursing).  Iterators would help, but it still seems unwieldy.
Instead, add copies of the GENERAL_REGS variants (to the SPECIAL_REGS
alternatives) on the "other" side, and make use of the "enabled"
attribute to activate just the desired order of alternatives.

gcc:

* config/cris/cris.cc (cris_preferred_reload_class): Reject
"eliminated" registers and small-enough constants unless
reloaded into a class that is a subset of GENERAL_REGS.
* config/cris/cris.md (attribute "cpu_variant"): New.
(attribute "enabled"): Conditionalize on a matching attribute
cpu_variant, if specified.
("*movsi_internal"): For moves to and from
memory, add cpu-variant-enabled variants for "r" alternatives on
the far side of the "x" alternatives, preferring the "x" ones
only for variants where MOF is present (in addition to SRP).
---
 gcc/config/cris/cris.cc | 13 -
 gcc/config/cris/cris.md | 25 -
 2 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/gcc/config/cris/cris.cc b/gcc/config/cris/cris.cc
index 4f977221f459..f0017d630229 100644
--- a/gcc/config/cris/cris.cc
+++ b/gcc/config/cris/cris.cc
@@ -1661,7 +1661,7 @@ cris_reload_address_legitimized (rtx x,
a bug.  */
 
 static reg_class_t
-cris_preferred_reload_class (rtx x ATTRIBUTE_UNUSED, reg_class_t rclass)
+cris_preferred_reload_class (rtx x, reg_class_t rclass)
 {
   if (rclass != MOF_REGS
   && rclass != MOF_SRP_REGS
@@ -1670,6 +1670,17 @@ cris_preferred_reload_class (rtx x ATTRIBUTE_UNUSED, 
reg_class_t rclass)
   && rclass != SPECIAL_REGS)
 return GENERAL_REGS;
 
+  /* We can't make use of something that's not a general register when
+ reloading an "eliminated" register (i.e. something that has turned into
+ e.g. sp + const_int).  */
+  if (GET_CODE (x) == PLUS && !reg_class_subset_p (rclass, GENERAL_REGS))
+return NO_REGS;
+
+  /* Avoid putting constants into a special register, where the instruction is
+ shorter if loaded into a general register.  */
+  if (satisfies_constraint_P (x) && !reg_class_subset_p (rclass, GENERAL_REGS))
+return NO_REGS;
+
   return rclass;
 }
 
diff --git a/gcc/config/cris/cris.md b/gcc/config/cris/cris.md
index 9d9eb8b7dbbf..dd7094163784 100644
--- a/gcc/config/cris/cris.md
+++ b/gcc/config/cris/cris.md
@@ -153,9 +153,20 @@ (define_delay (eq_attr "slottable" "has_return_slot")
(not (match_test "dead_or_set_regno_p (insn, CRIS_SRP_REGNUM)")))
(nil) (nil)])
 
+;; Enable choosing particular instructions.  The discriminator choice
+;; "v0" stands for "pre-v10", for brevity.
+(define_attr "cpu_variant" "default,v0,v10" (const_string "default"))
+
 (define_attr "enabled" "no,yes"
   (if_then_else
-   (eq_attr "cc_enabled" "normal")
+   (and
+(eq_attr "cc_enabled" "normal")
+(ior
+ (eq_attr "cpu_variant" "default")
+ (and (eq_attr "cpu_variant" "v10")
+ (match_test "TARGET_HAS_MUL_INSNS"))

[PATCH 4/5] cris: Don't discriminate against ALL_REGS in TARGET_REGISTER_MOVE_COST

[Hans-Peter Nilsson via Gcc-patches]

When the tightest class including both SPECIAL_REGS and GENERAL_REGS
is ALL_REGS, artificially special-casing for *either* to or from, hits
artificially hard.  This gets the port back to the code quality before
the previous patch ("cris: Remove CRIS v32 ACR artefacts") - except
for_vfprintf_r and _vfiprintf_r in newlib (still .8 and .4% larger).

gcc:
* config/cris/cris.cc (cris_register_move_cost): Remove special pre-ira
extra cost for ALL_REGS.
---
 gcc/config/cris/cris.cc | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/gcc/config/cris/cris.cc b/gcc/config/cris/cris.cc
index 264439c7654a..4f977221f459 100644
--- a/gcc/config/cris/cris.cc
+++ b/gcc/config/cris/cris.cc
@@ -1683,20 +1683,10 @@ cris_register_move_cost (machine_mode mode 
ATTRIBUTE_UNUSED,
  their move cost within that class is higher.  How about 7?  That's 3
  for a move to a GENERAL_REGS register, 3 for the move from the
  GENERAL_REGS register, and 1 for the increased register pressure.
- Also, it's higher than the memory move cost, as it should.
- We also do this for ALL_REGS, since we don't want that class to be
- preferred (even to memory) at all where GENERAL_REGS doesn't fit.
- Whenever it's about to be used, it's for SPECIAL_REGS.  If we don't
- present a higher cost for ALL_REGS than memory, a SPECIAL_REGS may be
- used when a GENERAL_REGS should be used, even if there are call-saved
- GENERAL_REGS left to allocate.  This is because the fall-back when
- the most preferred register class isn't available, isn't the next
- (or next good) wider register class, but the *most widest* register
- class.  FIXME: pre-IRA comment, perhaps obsolete now.  */
-
-  if ((reg_classes_intersect_p (from, SPECIAL_REGS)
-   && reg_classes_intersect_p (to, SPECIAL_REGS))
-  || from == ALL_REGS || to == ALL_REGS)
+ Also, it's higher than the memory move cost, as it should be.  */
+
+  if (reg_classes_intersect_p (from, SPECIAL_REGS)
+  && reg_classes_intersect_p (to, SPECIAL_REGS))
 return 7;
 
   /* Make moves to/from SPECIAL_REGS slightly more expensive, as we
-- 
2.30.2

[Bug tree-optimization/101831] [11 Regression] Spurious maybe-uninitialized warning on std::array::size

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

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

Martin Sebor  changed:

   What|Removed |Added

Summary|[11/12 Regression] Spurious |[11 Regression] Spurious
   |maybe-uninitialized warning |maybe-uninitialized warning
   |on std::array::size |on std::array::size

--- Comment #6 from Martin Sebor  ---
Fixed in r12-6992.  Let me backport it after a bit.

[PATCH 3/5] cris: Remove CRIS v32 ACR artefacts

[Hans-Peter Nilsson via Gcc-patches]

This is the change to which I alluded to this in r11-220 /
d0780379c1b6 as "causes extra register moves in libgcc".  It has
unfortunate side-effects due to the change in register-class topology.
There's a slight improvement in coremark numbers (< 0.07%) though also
increase in code size total (< 0.7%) but looking at the individual
changes in functions, it's all-over (-7..+7%).  Looking specifically
at functions that improved in speed, it's also both plus and minus in
code sizes.  It's unworkable to separate improvements from regressions
for this case.  I'll follow up with patches to restore the previous
code quality, in both size and speed.

gcc:
* config/cris/constraints.md (define_register_constraint "b"): Now
GENERAL_REGS.
* config/cris/cris.md (CRIS_ACR_REGNUM): Remove.
* config/cris/cris.h: (reg_class, REG_CLASS_NAMES)
(REG_CLASS_CONTENTS): Remove ACR_REGS, SPEC_ACR_REGS, GENNONACR_REGS,
and SPEC_GENNONACR_REGS.
* config/cris/cris.cc (cris_preferred_reload_class): Don't mention
ACR_REGS and return GENERAL_REGS instead of GENNONACR_REGS.
---
 gcc/config/cris/constraints.md |  7 ++-
 gcc/config/cris/cris.cc|  5 ++---
 gcc/config/cris/cris.h | 27 +--
 gcc/config/cris/cris.md|  1 -
 4 files changed, 13 insertions(+), 27 deletions(-)

diff --git a/gcc/config/cris/constraints.md b/gcc/config/cris/constraints.md
index 01ec12c4cf2a..83fab622717d 100644
--- a/gcc/config/cris/constraints.md
+++ b/gcc/config/cris/constraints.md
@@ -18,7 +18,12 @@
 ;; .
 
 ;; Register constraints.
-(define_register_constraint "b" "GENNONACR_REGS"
+
+;; Kept for compatibility.  It used to exclude the CRIS v32
+;; register "ACR", which was like GENERAL_REGS except it
+;; couldn't be used for autoincrement, and intended mainly
+;; for use in user asm statements.
+(define_register_constraint "b" "GENERAL_REGS"
   "@internal")
 
 (define_register_constraint "h" "MOF_REGS"
diff --git a/gcc/config/cris/cris.cc b/gcc/config/cris/cris.cc
index a7807b3cc25c..264439c7654a 100644
--- a/gcc/config/cris/cris.cc
+++ b/gcc/config/cris/cris.cc
@@ -1663,13 +1663,12 @@ cris_reload_address_legitimized (rtx x,
 static reg_class_t
 cris_preferred_reload_class (rtx x ATTRIBUTE_UNUSED, reg_class_t rclass)
 {
-  if (rclass != ACR_REGS
-  && rclass != MOF_REGS
+  if (rclass != MOF_REGS
   && rclass != MOF_SRP_REGS
   && rclass != SRP_REGS
   && rclass != CC0_REGS
   && rclass != SPECIAL_REGS)
-return GENNONACR_REGS;
+return GENERAL_REGS;
 
   return rclass;
 }
diff --git a/gcc/config/cris/cris.h b/gcc/config/cris/cris.h
index 9245d7886929..6edfe13d92cc 100644
--- a/gcc/config/cris/cris.h
+++ b/gcc/config/cris/cris.h
@@ -436,19 +436,15 @@ extern int cris_cpu_version;
 
 /* Node: Register Classes */
 
-/* We need a separate register class to handle register allocation for
-   ACR, since it can't be used for post-increment.
-
-   It's not obvious, but having subunions of all movable-between
+/* It's not obvious, but having subunions of all movable-between
register classes does really help register allocation (pre-IRA
comment).  */
 enum reg_class
   {
 NO_REGS,
-ACR_REGS, MOF_REGS, SRP_REGS, CC0_REGS,
+MOF_REGS, SRP_REGS, CC0_REGS,
 MOF_SRP_REGS, SPECIAL_REGS,
-SPEC_ACR_REGS, GENNONACR_REGS,
-SPEC_GENNONACR_REGS, GENERAL_REGS,
+GENERAL_REGS,
 ALL_REGS,
 LIM_REG_CLASSES
   };
@@ -457,9 +453,8 @@ enum reg_class
 
 #define REG_CLASS_NAMES\
   {"NO_REGS",  \
-   "ACR_REGS", "MOF_REGS", "SRP_REGS", "CC0_REGS", \
+   "MOF_REGS", "SRP_REGS", "CC0_REGS", \
"MOF_SRP_REGS", "SPECIAL_REGS", \
-   "SPEC_ACR_REGS", "GENNONACR_REGS", "SPEC_GENNONACR_REGS",   \
"GENERAL_REGS", "ALL_REGS"}
 
 #define CRIS_SPECIAL_REGS_CONTENTS \
@@ -472,37 +467,25 @@ enum reg_class
 #define REG_CLASS_CONTENTS \
   {\
{0},\
-   {1 << CRIS_ACR_REGNUM}, \
{1 << CRIS_MOF_REGNUM}, \
{1 << CRIS_SRP_REGNUM}, \
{1 << CRIS_CC0_REGNUM}, \
{(1 << CRIS_MOF_REGNUM) \
 | (1 << CRIS_SRP_REGNUM)}, \
{CRIS_SPECIAL_REGS_CONTENTS},   \
-   {CRIS_SPECIAL_REGS_CONTENTS \
-| (1 << CRIS_ACR_REGNUM)}, \
-   {(0x | CRIS_FAKED_REGS_CONTENTS)\
-& ~(1 << CRIS_ACR_REGNUM)},\
-   {(0x | CRIS_FAKED_REGS_CONTENTS \
-| CRIS_SPECIAL_REGS_CONTENTS)  \
-& ~(1 << CRIS_ACR_REGNUM)},\
{0x | 

[PATCH 2/5] cris: For expanded movsi, don't match operands we know will be reloaded

[Hans-Peter Nilsson via Gcc-patches]

In a session investigating unexpected fallout from a change, I
noticed reload needs one operand being a register to make an
informed decision.  It can happen that there's just a constant
and a memory operand, as in:

(insn 668 667 42 104 (parallel [
(set (mem:SI (plus:SI (reg/v/f:SI 347 [ fs ])
(const_int 168 [0xa8])) \
 [1 fs_126(D)->regs.cfa_how+0 S4 A8])
(const_int 2 [0x2]))
(clobber (reg:CC 19 dccr))
]) "<...>/gcc/libgcc/unwind-dw2.c":1121:21 22 {*movsi_internal}
 (expr_list:REG_UNUSED (reg:CC 19 dccr)
(nil)))

This was helpfully created by combine.  When this happens,
reload can't check for costs and preferred register classes,
(both operands will start with NO_REGS as the preferred class)
and will default to the constraints order in the insn in reload.
(Which also does its own temporary merge in find_reloads, but
that's a different story.)  Better don't match the simple cases.
Beware that subregs have to be matched.

I'm doing this just for word_mode (SI) for now, but may repeat
this for the other valid modes as well.  In particular, that
goes for DImode as I see the expanded movdi does *almost* this,
but uses register_operand instead of REG_S_P (from cris.h).
Using REG_S_P is the right choice here because register_operand
also matches (subreg (mem ...)  ...) *until* reload is done.
By itself it's just a sub-0.1% performance win (coremark).

Also removing a stale comment.

gcc:
* config/cris/cris.md ("*movsi_internal"):
Conditionalize on (sub-)register operands or operand 1 being 0.
---
 gcc/config/cris/cris.md | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gcc/config/cris/cris.md b/gcc/config/cris/cris.md
index bc8d7584f6d9..9d1c179d5211 100644
--- a/gcc/config/cris/cris.md
+++ b/gcc/config/cris/cris.md
@@ -583,9 +583,10 @@ (define_insn "*movsi_internal"
 (match_operand:SI 1 "general_operand"
   "r,Q>,M,M, I,r, M,n,g,r,x,  rQ>,x,gi"))
(clobber (reg:CC CRIS_CC0_REGNUM))]
-;; Note that we prefer not to use the S alternative (if for some reason
-;; it competes with others) above, but g matches S.
-  ""
+  ;; Avoid matching insns we know must be reloaded.  Without one
+  ;; operand being a (pseudo-)register, reload chooses
+  ;; reload-registers suboptimally.
+  "REG_S_P (operands[0]) || REG_S_P (operands[1]) || operands[1] == const0_rtx"
 {
   /* Better to have c-switch here; it is worth it to optimize the size of
  move insns.  The alternative would be to try to find more constraint
-- 
2.30.2

Re: [PATCH] declare std::array members attribute const [PR101831]

[Martin Sebor via Gcc-patches]

On 2/1/22 17:15, Jonathan Wakely wrote:

On Wed, 2 Feb 2022 at 00:13, Martin Sebor  wrote:


On 2/1/22 12:48, Jonathan Wakely wrote:

On Tue, 1 Feb 2022 at 18:54, Martin Sebor via Libstdc++
 wrote:


Passing an uninitialized object to a function that takes its argument
by const reference is diagnosed by -Wmaybe-uninitialized because most
such functions read the argument.  The exceptions are functions that
don't access the object but instead use its address to compute
a result.  This includes a number of std::array member functions such
as std::array::size() which returns the template argument N.  Such
functions may be candidates for attribute const which also avoids
the warning.  The attribute typically only benefits extern functions
that IPA cannot infer the property from, but in this case it helps
avoid the warning which runs very early on, even without optimization
or inlining.  The attached patch adds the attribute to a subset of
those member functions of std::array.  (It doesn't add it to const
member functions like cbegin() or front() that return a const_iterator
or const reference to the internal data.)

It might be possible to infer this property from inline functions
earlier on than during IPA and avoid having to annotate them explicitly.
That seems like an enhancement worth considering in the future.

Tested on x86_64-linux.

Martin


new file mode 100644
index 000..b7743adf3c9
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/array/iterators/begin_end.cc
@@ -0,0 +1,56 @@
+// { dg-do compile { target c++11 } }
+//
+// Copyright (C) 2011-2022 Free Software Foundation, Inc.

Those dates look wrong. I no longer bother putting a license text and
copyright notice on simple tests like this. It's meaningless to assert
copyright on something so trivial that doesn't do anything.



Should I take to mean that you're okay with the rest of the change
(i.e., with the notice removed)?


Yes, OK for trunk either with the notice entirely removed, or just fix
the dates (I don't think it is copied from an existing test dating
from 2011, right?)


I copied it from 23_containers/array/iterators/end_is_one_past.cc
without even looking at the dates.



Whichever you prefer.



Okay, pushed in r12-6992.

Martin

[PATCH 1/5] cris: Don't default to -mmul-bug-workaround

[Hans-Peter Nilsson via Gcc-patches]

This flips the default for the errata handling for an old version
(TL;DR: workaround: no multiply instruction last on a cache-line).
Newer versions of the CRIS cpu don't have that bug.  While the impact
of the workaround is very marginal (coremark: less than .05% larger,
less than .0005% slower) it's an irritating pseudorandom factor when
assessing the impact of other changes.

Also, fix a wart requiring changes to more than TARGET_DEFAULT to flip
the default.

People building old kernels or operating systems to run on
ETRAX 100 LX are advised to pass "-mmul-bug-workaround".

gcc:
* config/cris/cris.h (TARGET_DEFAULT): Don't include MASK_MUL_BUG.
(MUL_BUG_ASM_DEFAULT): New macro.
(MAYBE_AS_NO_MUL_BUG_ABORT): Define in terms of MUL_BUG_ASM_DEFAULT.
* doc/invoke.texi (CRIS Options, -mmul-bug-workaround): Adjust
accordingly.
---
 gcc/config/cris/cris.h | 19 ---
 gcc/doc/invoke.texi|  2 +-
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/gcc/config/cris/cris.h b/gcc/config/cris/cris.h
index b274e1166203..9245d7886929 100644
--- a/gcc/config/cris/cris.h
+++ b/gcc/config/cris/cris.h
@@ -153,7 +153,9 @@ extern int cris_cpu_version;
 
 #ifdef HAVE_AS_NO_MUL_BUG_ABORT_OPTION
 #define MAYBE_AS_NO_MUL_BUG_ABORT \
- "%{mno-mul-bug-workaround:-no-mul-bug-abort} "
+ "%{mno-mul-bug-workaround:-no-mul-bug-abort} " \
+ "%{mmul-bug-workaround:-mul-bug-abort} " \
+ "%{!mmul-bug-workaround:%{!mno-mul-bug-workaround:" MUL_BUG_ASM_DEFAULT "}} "
 #else
 #define MAYBE_AS_NO_MUL_BUG_ABORT
 #endif
@@ -255,15 +257,26 @@ extern int cris_cpu_version;
  (MASK_SIDE_EFFECT_PREFIXES + MASK_STACK_ALIGN \
   + MASK_CONST_ALIGN + MASK_DATA_ALIGN \
   + MASK_ALIGN_BY_32 \
-  + MASK_PROLOGUE_EPILOGUE + MASK_MUL_BUG)
+  + MASK_PROLOGUE_EPILOGUE)
 # else  /* 0 */
 #  define TARGET_DEFAULT \
  (MASK_SIDE_EFFECT_PREFIXES + MASK_STACK_ALIGN \
   + MASK_CONST_ALIGN + MASK_DATA_ALIGN \
-  + MASK_PROLOGUE_EPILOGUE + MASK_MUL_BUG)
+  + MASK_PROLOGUE_EPILOGUE)
 # endif
 #endif
 
+/* Don't depend on the assembler default setting for the errata machinery;
+   always pass the option to turn it on or off explicitly.  But, we have to
+   decide on which is the *GCC* default, and for that we should only need to
+   consider what's in TARGET_DEFAULT; no other changes should be necessary.  */
+
+#if (TARGET_DEFAULT & MASK_MUL_BUG)
+#define MUL_BUG_ASM_DEFAULT "-mul-bug-abort"
+#else
+#define MUL_BUG_ASM_DEFAULT "-no-mul-bug-abort"
+#endif
+
 /* Local, providing a default for cris_cpu_version.  */
 #define CRIS_DEFAULT_CPU_VERSION TARGET_CPU_DEFAULT
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index cfd415110cdf..7af5c51cc3c7 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -22268,7 +22268,7 @@ The options @option{-metrax4} and @option{-metrax100} 
are synonyms for
 @opindex mmul-bug-workaround
 @opindex mno-mul-bug-workaround
 Work around a bug in the @code{muls} and @code{mulu} instructions for CPU
-models where it applies.  This option is active by default.
+models where it applies.  This option is disabled by default.
 
 @item -mpdebug
 @opindex mpdebug
-- 
2.30.2

[Bug tree-optimization/101831] [11/12 Regression] Spurious maybe-uninitialized warning on std::array::size

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:756eabacfcd767e39eea63257a026f61a4c4e661

commit r12-6992-g756eabacfcd767e39eea63257a026f61a4c4e661
Author: Martin Sebor 
Date:   Tue Feb 1 17:19:11 2022 -0700

Declare std::array members with attribute const [PR101831].

Resolves:
PR libstdc++/101831 - Spurious maybe-uninitialized warning on
std::array::size

libstdc++-v3/ChangeLog:

PR libstdc++/101831
* include/std/array (begin): Declare const member function
attribute
const.
(end, rbegin, rend, size, max_size, empty, data): Same.
* testsuite/23_containers/array/capacity/empty.cc: Add test cases.
* testsuite/23_containers/array/capacity/max_size.cc: Same.
* testsuite/23_containers/array/capacity/size.cc: Same.
* testsuite/23_containers/array/iterators/begin_end.cc: New test.

[PATCH 0/5] A few CRIS port improvements

[Hans-Peter Nilsson via Gcc-patches]

I'm taking advantage of CRIS being a lesser important target and as
such not subject to the constraints of GCC being in stage 4.
I'm applying this set of CRIS-specific changes that don't have much
expected effect on generated code.

1: cris: Don't default to -mmul-bug-workaround
Avoid the workaround having a sort-of pseudorandom effect
on observability of code-quality changes.

2: cris: For expanded movsi, don't match operands we know will be
reloaded
A random improvement noticed while looking at the performance impact
of the other changes, helping reload to behave better.

3:  cris: Remove CRIS v32 ACR artefacts
The bigger cleanup; tightening up register classes.  A left-over from
r11-220 / d0780379c1b6.  Unfortunately on its own has a negative
effect on performance, when applied in this order.  Don't apply
without the other patches in this set unless you're actually
interested in seeing the fallout.

4:  cris: Don't discriminate against ALL_REGS in TARGET_REGISTER_MOVE_COST
A workaround for a problem from before IRA, one that didn't fit well
with the register class cleanup.

5: cris: Reload using special-regs before general-regs
Fixing a flaw exposed by the register class cleanup.

 gcc/config/cris/constraints.md |  7 +-
 gcc/config/cris/cris.cc| 36 +-
 gcc/config/cris/cris.h | 46 --
 gcc/config/cris/cris.md| 33 +---
 gcc/doc/invoke.texi|  2 +-
 5 files changed, 70 insertions(+), 54 deletions(-)

-- 
2.30.2

brgds, H-P

Re: [PATCH] declare std::array members attribute const [PR101831]

[Jonathan Wakely via Gcc-patches]

On Wed, 2 Feb 2022 at 00:13, Martin Sebor  wrote:
>
> On 2/1/22 12:48, Jonathan Wakely wrote:
> > On Tue, 1 Feb 2022 at 18:54, Martin Sebor via Libstdc++
> >  wrote:
> >>
> >> Passing an uninitialized object to a function that takes its argument
> >> by const reference is diagnosed by -Wmaybe-uninitialized because most
> >> such functions read the argument.  The exceptions are functions that
> >> don't access the object but instead use its address to compute
> >> a result.  This includes a number of std::array member functions such
> >> as std::array::size() which returns the template argument N.  Such
> >> functions may be candidates for attribute const which also avoids
> >> the warning.  The attribute typically only benefits extern functions
> >> that IPA cannot infer the property from, but in this case it helps
> >> avoid the warning which runs very early on, even without optimization
> >> or inlining.  The attached patch adds the attribute to a subset of
> >> those member functions of std::array.  (It doesn't add it to const
> >> member functions like cbegin() or front() that return a const_iterator
> >> or const reference to the internal data.)
> >>
> >> It might be possible to infer this property from inline functions
> >> earlier on than during IPA and avoid having to annotate them explicitly.
> >> That seems like an enhancement worth considering in the future.
> >>
> >> Tested on x86_64-linux.
> >>
> >> Martin
> >
> > new file mode 100644
> > index 000..b7743adf3c9
> > --- /dev/null
> > +++ b/libstdc++-v3/testsuite/23_containers/array/iterators/begin_end.cc
> > @@ -0,0 +1,56 @@
> > +// { dg-do compile { target c++11 } }
> > +//
> > +// Copyright (C) 2011-2022 Free Software Foundation, Inc.
> >
> > Those dates look wrong. I no longer bother putting a license text and
> > copyright notice on simple tests like this. It's meaningless to assert
> > copyright on something so trivial that doesn't do anything.
> >
>
> Should I take to mean that you're okay with the rest of the change
> (i.e., with the notice removed)?

Yes, OK for trunk either with the notice entirely removed, or just fix
the dates (I don't think it is copied from an existing test dating
from 2011, right?)

Whichever you prefer.

Re: [PATCH] declare std::array members attribute const [PR101831]

[Martin Sebor via Gcc-patches]

On 2/1/22 12:48, Jonathan Wakely wrote:

On Tue, 1 Feb 2022 at 18:54, Martin Sebor via Libstdc++
 wrote:


Passing an uninitialized object to a function that takes its argument
by const reference is diagnosed by -Wmaybe-uninitialized because most
such functions read the argument.  The exceptions are functions that
don't access the object but instead use its address to compute
a result.  This includes a number of std::array member functions such
as std::array::size() which returns the template argument N.  Such
functions may be candidates for attribute const which also avoids
the warning.  The attribute typically only benefits extern functions
that IPA cannot infer the property from, but in this case it helps
avoid the warning which runs very early on, even without optimization
or inlining.  The attached patch adds the attribute to a subset of
those member functions of std::array.  (It doesn't add it to const
member functions like cbegin() or front() that return a const_iterator
or const reference to the internal data.)

It might be possible to infer this property from inline functions
earlier on than during IPA and avoid having to annotate them explicitly.
That seems like an enhancement worth considering in the future.

Tested on x86_64-linux.

Martin


new file mode 100644
index 000..b7743adf3c9
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/array/iterators/begin_end.cc
@@ -0,0 +1,56 @@
+// { dg-do compile { target c++11 } }
+//
+// Copyright (C) 2011-2022 Free Software Foundation, Inc.

Those dates look wrong. I no longer bother putting a license text and
copyright notice on simple tests like this. It's meaningless to assert
copyright on something so trivial that doesn't do anything.



Should I take to mean that you're okay with the rest of the change
(i.e., with the notice removed)?

Martin

Re: [committed] libstdc++: Reset filesystem::recursive_directory_iterator on error

[Jonathan Wakely via Gcc-patches]

On Tue, 1 Feb 2022 at 22:00, Jonathan Wakely via Libstdc++
 wrote:
>
> The standard requires directory iterators to become equal to the end
> iterator value if they report an error. Some members functions of
> filesystem::recursive_directory_iterator fail to do that.
>
> libstdc++-v3/ChangeLog:
>
> * src/c++17/fs_dir.cc (recursive_directory_iterator::increment):
> Reset state to past-the-end iterator on error.
> (fs::recursive_directory_iterator::pop(error_code&)): Likewise.
> (fs::recursive_directory_iterator::pop()): Check _M_dirs before
> it might get reset.
> * src/filesystem/dir.cc (recursive_directory_iterator): Likewise,
> for the TS implementation.
> * testsuite/27_io/filesystem/iterators/error_reporting.cc: New test.
> * testsuite/experimental/filesystem/iterators/error_reporting.cc: New 
> test.
> ---
>  libstdc++-v3/src/c++17/fs_dir.cc  |  12 +-
>  libstdc++-v3/src/filesystem/dir.cc|  12 +-
>  .../filesystem/iterators/error_reporting.cc   | 135 +
>  .../filesystem/iterators/error_reporting.cc   | 136 ++
>  4 files changed, 291 insertions(+), 4 deletions(-)
>  create mode 100644 
> libstdc++-v3/testsuite/27_io/filesystem/iterators/error_reporting.cc
>  create mode 100644 
> libstdc++-v3/testsuite/experimental/filesystem/iterators/error_reporting.cc
>
[...]
> +
> +extern "C" struct dirent* readdir(DIR*)
> +{
> +  switch (choice)
> +  {
> +  case 1:
> +global_dirent.d_ino = 999;
> +global_dirent.d_type = DT_REG;

These new tests should not use the d_type member unless it's actually
present on the OS. Fixed by the attached patch.

Tested x86_64-linux and mingw-w64, pushed to trunk.
commit d98668eb06f532b2dbe0c721fa1b9ed6e643df27
Author: Jonathan Wakely 
Date:   Tue Feb 1 23:58:08 2022

libstdc++: Do not use dirent::d_type unconditionally

These new tests should not use the d_type member unless it's actually
present on the OS.

libstdc++-v3/ChangeLog:

* testsuite/27_io/filesystem/iterators/error_reporting.cc: Use
autoconf macro to check whether d_type is present.
* testsuite/experimental/filesystem/iterators/error_reporting.cc:
Likewise.

diff --git 
a/libstdc++-v3/testsuite/27_io/filesystem/iterators/error_reporting.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/iterators/error_reporting.cc
index 81ef1069367..1f297a731a3 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/iterators/error_reporting.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/iterators/error_reporting.cc
@@ -36,14 +36,18 @@ extern "C" struct dirent* readdir(DIR*)
   {
   case 1:
 global_dirent.d_ino = 999;
+#if defined _GLIBCXX_HAVE_STRUCT_DIRENT_D_TYPE && defined DT_REG
 global_dirent.d_type = DT_REG;
+#endif
 global_dirent.d_reclen = 0;
 std::char_traits::copy(global_dirent.d_name, "file", 5);
 choice = 0;
 return _dirent;
   case 2:
 global_dirent.d_ino = 111;
+#if defined _GLIBCXX_HAVE_STRUCT_DIRENT_D_TYPE && defined DT_DIR
 global_dirent.d_type = DT_DIR;
+#endif
 global_dirent.d_reclen = 60;
 std::char_traits::copy(global_dirent.d_name, "subdir", 7);
 choice = 1;
diff --git 
a/libstdc++-v3/testsuite/experimental/filesystem/iterators/error_reporting.cc 
b/libstdc++-v3/testsuite/experimental/filesystem/iterators/error_reporting.cc
index ade62732028..806c511ebef 100644
--- 
a/libstdc++-v3/testsuite/experimental/filesystem/iterators/error_reporting.cc
+++ 
b/libstdc++-v3/testsuite/experimental/filesystem/iterators/error_reporting.cc
@@ -37,14 +37,18 @@ extern "C" struct dirent* readdir(DIR*)
   {
   case 1:
 global_dirent.d_ino = 999;
+#if defined _GLIBCXX_HAVE_STRUCT_DIRENT_D_TYPE && defined DT_REG
 global_dirent.d_type = DT_REG;
+#endif
 global_dirent.d_reclen = 0;
 std::char_traits::copy(global_dirent.d_name, "file", 5);
 choice = 0;
 return _dirent;
   case 2:
 global_dirent.d_ino = 111;
+#if defined _GLIBCXX_HAVE_STRUCT_DIRENT_D_TYPE && defined DT_DIR
 global_dirent.d_type = DT_DIR;
+#endif
 global_dirent.d_reclen = 60;
 std::char_traits::copy(global_dirent.d_name, "subdir", 7);
 choice = 1;

[Bug middle-end/104260] [12 Regression] Misplaced waccess3 pass

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589629.html

[Bug target/104338] RISC-V: Subword atomics result in library calls

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Severity|normal  |enhancement
   Last reconfirmed||2022-02-01

[Bug target/104338] RISC-V: Subword atomics result in library calls

[patrick at rivosinc dot com via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89835
   Last reconfirmed||2022-02-01
 Status|UNCONFIRMED |NEW

Patrick O'Neill  changed:

   What|Removed |Added

 CC||patrick at rivosinc dot com
   Last reconfirmed|2022-02-01 00:00:00 |
 Ever confirmed|1   |0
 Status|NEW |UNCONFIRMED

--- Comment #1 from Andrew Pinski  ---
Bug 89835 comment #2 references this.

[Bug target/104338] RISC-V: Subword atomics result in library calls

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89835
   Last reconfirmed||2022-02-01
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Bug 89835 comment #2 references this.

[Bug target/104338] New: RISC-V: Subword atomics result in library calls

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

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

Bug ID: 104338
   Summary: RISC-V: Subword atomics result in library calls
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palmer at gcc dot gnu.org
  Target Milestone: ---

There's a handful of bugs sort of related to this one, but nothing specific. 
This has been a long-standing issue and I think folks are generally familiar
with it, but just to summarize: we don't have sub-word atomic instruction in
RISC-V, so we just call out to the libatomic routines.  This causes fallout in
a handful of places (see 86005 and 81358, for example) and there's been some
attempts to resolve it but nothing appears to have stuck.

I figured it'd be a good starter project for Patrick, as he's yet to do any GCC
stuff.  He's working through it and doesn't have anything to post yet, but
figured I'd just open the bug now so folks knew what was going on from our end.

[PATCH] adjust warn-access pass placement [PR104260]

[Martin Sebor via Gcc-patches]

The attached patch adjusts the placement of the warn-access pass
as the two of you suggested in the bug.  Please let me know if
this is good to commit or if you want me to make some other tweaks.

The patch passes tests in an x86_64-linux bootstrap.

MartinPR middle-end/104260 - Misplaced waccess3 pass

gcc/ChangeLog:

	PR 104260
	* passes.def (pass_warn_access): Adjust pass placement.

diff --git a/gcc/passes.def b/gcc/passes.def
index 3e75de46c23..f7718181038 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -60,10 +60,10 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_warn_printf);
   NEXT_PASS (pass_warn_nonnull_compare);
   NEXT_PASS (pass_early_warn_uninitialized);
+  NEXT_PASS (pass_warn_access, /*early=*/true);
   NEXT_PASS (pass_ubsan);
   NEXT_PASS (pass_nothrow);
   NEXT_PASS (pass_rebuild_cgraph_edges);
-  NEXT_PASS (pass_warn_access, /*early=*/true);
   POP_INSERT_PASSES ()
 
   NEXT_PASS (pass_local_optimization_passes);
@@ -428,9 +428,9 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_gimple_isel);
   NEXT_PASS (pass_harden_conditional_branches);
   NEXT_PASS (pass_harden_compares);
+  NEXT_PASS (pass_warn_access, /*early=*/false);
   NEXT_PASS (pass_cleanup_cfg_post_optimizing);
   NEXT_PASS (pass_warn_function_noreturn);
-  NEXT_PASS (pass_warn_access, /*early=*/false);
 
   NEXT_PASS (pass_expand);
 

Re: Prerequisites page lists http://multiprecision.org but it supports https too/instead

[Andrew Pinski via Gcc]

On Tue, Feb 1, 2022 at 12:20 PM Jonathan Leffler via Gcc
 wrote:
>
> The prerequisites page https://gcc.gnu.org/install/prerequisites.html lists
> (for MPC):
>
> It can be downloaded from http://www.multiprecision.org/mpc/.
>
>
> The website actually supports https now: https://www.multiprecision.org/mpc/

Thanks for the report,
I committed the fix
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589628.html
(r12-6983) and it will appear the next time the documentation is
regenerated (I don't know the schedule sorry).

Thanks,
Andrew

>
> --
> Jonathan Leffler   #include 
> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org
> "Blessed are we who can laugh at ourselves, for we shall never cease to be
> amused."

[PATCH] [COMMITTED] Change multiprecision.org to use https

[apinski--- via Gcc-patches]

From: Andrew Pinski 

As reported at
https://gcc.gnu.org/pipermail/gcc/2022-February/238216.html,
multiprecision.org now uses https so this updates the documentation
to use https instead of http.

Committed as obvious.

gcc/ChangeLog:

* doc/install.texi:
---
 gcc/doc/install.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index dae7c0acc36..f8898af027d 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -406,7 +406,7 @@ download_prerequisites installs.
 @item MPC Library version 1.0.1 (or later)
 
 Necessary to build GCC@.  It can be downloaded from
-@uref{http://www.multiprecision.org/mpc/}.  If an MPC source distribution
+@uref{https://www.multiprecision.org/mpc/}.  If an MPC source distribution
 is found in a subdirectory of your GCC sources named @file{mpc}, it
 will be built together with GCC.  Alternatively, if MPC is already
 installed but it is not in your default library search path, the
-- 
2.17.1

Re: [PATCH 5/8] rs6000: Fix LE code gen for vec_cnt[lt]z_lsbb [PR95082]

[Segher Boessenkool]

On Fri, Jan 28, 2022 at 11:50:23AM -0600, Bill Schmidt wrote:
> These built-ins were misimplemented as always having big-endian semantics.

>   PR target/95082
>   * config/rs6000/rs6000-builtin.cc (rs6000_expand_builtin): Handle
>   endianness for vclzlsbb and vctzlsbb.
>   * config/rs6000/rs6000-builtins.def (VCLZLSBB_V16QI): Change
>   default pattern and indicate a different pattern will be used for
>   big endian.
>   (VCLZLSBB_V4SI): Likewise.
>   (VCLZLSBB_V8HI): Likewise.
>   (VCTZLSBB_V16QI): Likewise.
>   (VCTZLSBB_V4SI): Likewise.
>   (VCTZLSBB_V8HI): Likewise.

Please don't break lines early?  Changelog lines are one tab followed
by 72 chars.

The patch is fine though.  Thanks!


Segher

[Bug debug/104337] New: ICE when compiling with optimize attribute at -m32 -g3 -O0

[tlwang at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 104337
   Summary: ICE when compiling with optimize attribute at -m32 -g3
-O0
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tlwang at uwaterloo dot ca
  Target Milestone: ---

This occurs in attributes_transformed_program0_preprocessed.c, shown below:

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.JKF7BF3fiK-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220201 (experimental) [master -g1bb526625] (GCC)
$
$ cat attributes_transformed_program0_preprocessed.c
struct a {
  unsigned b : 7;
};
__attribute__((optimize(3))) __attribute__((always_inline)) struct a c() {
  struct a d;
  return d;
}
void e() {
  for (;;)
c();
}
int main() {}
$
$ gcc-trunk -m32 -O0 -g3 attributes_transformed_program0_preprocessed.c
attributes_transformed_program0_preprocessed.c:4:70: warning: ‘always_inline’
function might not be inlinable [-Wattributes]
4 | __attribute__((optimize(3))) __attribute__((always_inline)) struct a
c() {
  |  ^
during RTL pass: final
attributes_transformed_program0_preprocessed.c: In function ‘e’:
attributes_transformed_program0_preprocessed.c:11:1: internal compiler error:
in decl_ultimate_origin, at dwarf2out.cc:4466
   11 | }
  | ^
0x71239e decl_ultimate_origin
/tmp/tmp.JKF7BF3fiK-gcc-builder/gcc/gcc/dwarf2out.cc:4466
0x71239e decl_ultimate_origin
/tmp/tmp.JKF7BF3fiK-gcc-builder/gcc/gcc/dwarf2out.cc:4454
0xbb0b17 process_scope_var
/tmp/tmp.JKF7BF3fiK-gcc-builder/gcc/gcc/dwarf2out.cc:26452
0xbb0c2f decls_for_scope
/tmp/tmp.JKF7BF3fiK-gcc-builder/gcc/gcc/dwarf2out.cc:26515
0xbd36c6 gen_inlined_subroutine_die
/tmp/tmp.JKF7BF3fiK-gcc-builder/gcc/gcc/dwarf2out.cc:24964
0xbd36c6 gen_block_die
/tmp/tmp.JKF7BF3fiK-gcc-builder/gcc/gcc/dwarf2out.cc:26419
0xbb0cea decls_for_scope
/tmp/tmp.JKF7BF3fiK-gcc-builder/gcc/gcc/dwarf2out.cc:26544
0xbb14a2 gen_subprogram_die
/tmp/tmp.JKF7BF3fiK-gcc-builder/gcc/gcc/dwarf2out.cc:24026
0xbcf88f gen_decl_die
/tmp/tmp.JKF7BF3fiK-gcc-builder/gcc/gcc/dwarf2out.cc:26952
0xbd11f6 dwarf2out_decl
/tmp/tmp.JKF7BF3fiK-gcc-builder/gcc/gcc/dwarf2out.cc:27530
0xbd1572 dwarf2out_function_decl
/tmp/tmp.JKF7BF3fiK-gcc-builder/gcc/gcc/dwarf2out.cc:27545
0xc34e70 rest_of_handle_final
/tmp/tmp.JKF7BF3fiK-gcc-builder/gcc/gcc/final.cc:4321
0xc34e70 execute
/tmp/tmp.JKF7BF3fiK-gcc-builder/gcc/gcc/final.cc:4363
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/102191] [C++20] Can't return prvalue with potentially-throwing destructor during constant evaluation

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Fixed for GCC 12.

[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws

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

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|10.4|12.0
 Status|REOPENED|RESOLVED

--- Comment #21 from Jason Merrill  ---
Fixed for GCC 12.

[Bug c++/51501] [DR 1433] decltype over-agressive SFINAE

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

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |8.0

--- Comment #16 from Jason Merrill  ---
Then this seems resolved, until/unless someone actually proposes to make it
well-formed.

[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce

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

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

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 #8 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-February/057499.html

[PATCH] PR fortran/104311 - [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce

[Harald Anlauf via Gcc-patches]

Dear Fortranners,

a check in gfc_calculate_transfer_sizes had a bug in the logic:
it did not trigger for MOLD having a storage size zero when
arugment SIZE was present.  The attached obvious patch fixes this.

Regtested on x86_64-pc-linux-gnu.  OK for mainline/11/10/9?

Thanks,
Harald

From b8f124adcf258eccd29ffcec5cc3f8915cc2ca47 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Tue, 1 Feb 2022 23:33:24 +0100
Subject: [PATCH] Fortran: reject simplifying TRANSFER for MOLD with storage
 size 0

gcc/fortran/ChangeLog:

	PR fortran/104311
	* check.cc (gfc_calculate_transfer_sizes): Checks for case when
	storage size of SOURCE is greater than zero while the storage size
	of MOLD is zero and MOLD is an array shall not depend on SIZE.

gcc/testsuite/ChangeLog:

	PR fortran/104311
	* gfortran.dg/transfer_simplify_15.f90: New test.
---
 gcc/fortran/check.cc   |  2 +-
 gcc/testsuite/gfortran.dg/transfer_simplify_15.f90 | 11 +++
 2 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/transfer_simplify_15.f90

diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index d6c6767ae9e..fc97bb1371e 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -6150,7 +6150,7 @@ gfc_calculate_transfer_sizes (gfc_expr *source, gfc_expr *mold, gfc_expr *size,
* representation is not shorter than that of SOURCE.
* If SIZE is present, the result is an array of rank one and size SIZE.
*/
-  if (result_elt_size == 0 && *source_size > 0 && !size
+  if (result_elt_size == 0 && *source_size > 0
   && (mold->expr_type == EXPR_ARRAY || mold->rank))
 {
   gfc_error ("% argument of % intrinsic at %L is an "
diff --git a/gcc/testsuite/gfortran.dg/transfer_simplify_15.f90 b/gcc/testsuite/gfortran.dg/transfer_simplify_15.f90
new file mode 100644
index 000..cdbec97ae71
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/transfer_simplify_15.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! PR fortran/104311 - ICE out of memory
+! Contributed by G.Steinmetz
+
+program p
+  type t
+  end type
+  type(t) :: x(2)
+  print *, transfer(1,x,2)   ! { dg-error "shall not have storage size 0" }
+  print *, transfer(1,x,huge(1)) ! { dg-error "shall not have storage size 0" }
+end
--
2.34.1

[Bug tree-optimization/55288] Improve handling/suppression of maybe-uninitialized warnings

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

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

--- Comment #5 from Eric Gallager  ---
(In reply to CVS Commits from comment #4)
> The master branch has been updated by Martin Sebor :
> 
> https://gcc.gnu.org/g:b04093adb28bd6ee8b0390e840219fd2bba134db
> 
> commit r11-8099-gb04093adb28bd6ee8b0390e840219fd2bba134db
> Author: Martin Sebor 
> Date:   Fri Apr 9 11:40:48 2021 -0600
> 
> PR middle-end/55288 - Improve handling/suppression of
> maybe-uninitialized warnings
> 
> gcc/testsuite/ChangeLog:
> PR middle-end/55288
> * g++.dg/warn/uninit-pr55288.C: New test.

so... is the intent to backport this?

[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce

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

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #6)
> (In reply to anlauf from comment #2)
> > We could limit the size of the resulting array constructor, using e.g.
> > flag_max_array_constructor.
> 
> Sample patch:

Well, thinking some more and rereading the standard text, I see I got it wrong.
A comment in gfc_calculate_transfer_sizes explains what it should be.
So the right thing is simply:

diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index d6c6767ae9e..fc97bb1371e 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -6150,7 +6150,7 @@ gfc_calculate_transfer_sizes (gfc_expr *source, gfc_expr
*mold, gfc_expr *size,
* representation is not shorter than that of SOURCE.
* If SIZE is present, the result is an array of rank one and size SIZE.
*/
-  if (result_elt_size == 0 && *source_size > 0 && !size
+  if (result_elt_size == 0 && *source_size > 0
   && (mold->expr_type == EXPR_ARRAY || mold->rank))
 {
   gfc_error ("% argument of % intrinsic at %L is an "

[Bug target/103910] openjdk17 causes ICE on -O3 -march=opteron -fcheck-new: during GIMPLE pass: aprefetch: in gimple_build_call, at gimple.c:267

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

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

--- Comment #12 from Eric Gallager  ---
(In reply to Sam James from comment #11)
> (In reply to Andrew Pinski from comment #10)
> > Someone would have hit this a long time ago, in GCC 4.3.0 or latter.
> 
> My point was that some software has recently started building with PCH by
> default and hence it's only appeared now and I was surprised at the number
> of people who were affected. I understand the bug isn't new, it's just been
> exposed by a change in the ecosystem.

Could you provide some more info on the software that has recently started
building with PCH by default? There has been some talk of wanting to rip PCH
out of GCC at some point, but if there's software out there actually depending
on it, that could be useful info for the argument that PCH ought to be kept.

Re: [PATCH v2 3/8] rs6000: Unify error messages for built-in constant restrictions

[Segher Boessenkool]

On Tue, Feb 01, 2022 at 08:53:52AM -0600, Bill Schmidt wrote:
> As discussed, I simplified this patch by just changing how the error
> message is produced:
> 
> We currently give different error messages for built-in functions that
> violate range restrictions on their arguments, depending on whether we
> record them as requiring an n-bit literal or a literal between two values.
> It's better to be consistent.  Change the error message for the n-bit
> literal to look like the other one.

> --- a/gcc/config/rs6000/rs6000-call.cc
> +++ b/gcc/config/rs6000/rs6000-call.cc
> @@ -5729,8 +5729,10 @@ rs6000_expand_builtin (tree exp, rtx target, rtx /* 
> subtarget */,
>   if (!(TREE_CODE (restr_arg) == INTEGER_CST
> && (TREE_INT_CST_LOW (restr_arg) & ~mask) == 0))
> {
> - error ("argument %d must be a %d-bit unsigned literal",
> -bifaddr->restr_opnd[i], bifaddr->restr_val1[i]);
> + unsigned p = ((unsigned) 1 << bifaddr->restr_val1[i]) - 1;

Don't write
  (unsigned) 1
but instead just
  1U
please.  Does it need to be 1ULL btw?  (You need this if restr_val1[i]
can be greater than or equal to 32).  (32 itself would work, but is UB
nevertheless).

Okay with that.  Thanks!


Segher

[committed] libstdc++: Add more tests for filesystem directory iterators

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.


The PR 97731 test was added to verify a fix to the Filesystem TS code,
but we should also have the same test to avoid similar regressions in
the C++17 std::filesystem code.

Also add tests for directory_options::follow_directory_symlink

libstdc++-v3/ChangeLog:

* testsuite/27_io/filesystem/iterators/97731.cc: New test.
* testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc:
Check follow_directory_symlink option.
* 
testsuite/experimental/filesystem/iterators/recursive_directory_iterator.cc:
Likewise.
---
 .../27_io/filesystem/iterators/97731.cc   | 48 +++
 .../iterators/recursive_directory_iterator.cc | 19 
 .../iterators/recursive_directory_iterator.cc | 21 +++-
 3 files changed, 87 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/testsuite/27_io/filesystem/iterators/97731.cc

diff --git a/libstdc++-v3/testsuite/27_io/filesystem/iterators/97731.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/iterators/97731.cc
new file mode 100644
index 000..9021e6edf41
--- /dev/null
+++ b/libstdc++-v3/testsuite/27_io/filesystem/iterators/97731.cc
@@ -0,0 +1,48 @@
+// Copyright (C) 2020-2022 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do run { target c++17 } }
+// { dg-require-filesystem-ts "" }
+
+#include 
+#include 
+#include 
+
+bool used_custom_readdir = false;
+
+extern "C" void* readdir(void*)
+{
+  used_custom_readdir = true;
+  errno = EIO;
+  return nullptr;
+}
+
+void
+test01()
+{
+  using std::filesystem::recursive_directory_iterator;
+  std::error_code ec;
+  recursive_directory_iterator it(".", ec);
+  if (used_custom_readdir)
+VERIFY( ec.value() == EIO );
+}
+
+int
+main()
+{
+  test01();
+}
diff --git 
a/libstdc++-v3/testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc
 
b/libstdc++-v3/testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc
index b0ccdfe3d73..e67e2cf38f7 100644
--- 
a/libstdc++-v3/testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc
+++ 
b/libstdc++-v3/testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc
@@ -184,6 +184,24 @@ test05()
   remove_all(p, ec);
 }
 
+void
+test06()
+{
+#if !(defined __MINGW32__ || defined __MINGW64__)
+  auto p = __gnu_test::nonexistent_path();
+  create_directories(p/"d1/d2");
+  create_directory_symlink("d1", p/"link");
+  fs::recursive_directory_iterator it(p), endit;
+  VERIFY( std::distance(it, endit) == 3 ); // d1 and d2 and link
+
+  it = fs::recursive_directory_iterator(p, 
fs::directory_options::follow_directory_symlink);
+  VERIFY( std::distance(it, endit) == 4 ); // d1 and d1/d2 and link and link/d2
+
+  std::error_code ec;
+  remove_all(p, ec);
+#endif
+}
+
 int
 main()
 {
@@ -192,4 +210,5 @@ main()
   test03();
   test04();
   test05();
+  test06();
 }
diff --git 
a/libstdc++-v3/testsuite/experimental/filesystem/iterators/recursive_directory_iterator.cc
 
b/libstdc++-v3/testsuite/experimental/filesystem/iterators/recursive_directory_iterator.cc
index 455dbf28c8c..a201415921c 100644
--- 
a/libstdc++-v3/testsuite/experimental/filesystem/iterators/recursive_directory_iterator.cc
+++ 
b/libstdc++-v3/testsuite/experimental/filesystem/iterators/recursive_directory_iterator.cc
@@ -174,7 +174,7 @@ test05()
 {
   auto p = __gnu_test::nonexistent_path();
   create_directory(p);
-  create_directory_symlink(p, p / "l");
+  create_directory(p / "x");
   fs::recursive_directory_iterator it(p), endit;
   VERIFY( begin(it) == it );
   static_assert( noexcept(begin(it)), "begin is noexcept" );
@@ -185,6 +185,24 @@ test05()
   remove_all(p, ec);
 }
 
+void
+test06()
+{
+#if !(defined __MINGW32__ || defined __MINGW64__)
+  auto p = __gnu_test::nonexistent_path();
+  create_directories(p/"d1/d2");
+  create_directory_symlink("d1", p/"link");
+  fs::recursive_directory_iterator it(p), endit;
+  VERIFY( std::distance(it, endit) == 3 ); // d1 and d2 and link
+
+  it = fs::recursive_directory_iterator(p, 
fs::directory_options::follow_directory_symlink);
+  VERIFY( std::distance(it, endit) == 4 ); // d1 and d1/d2 and link and link/d2
+
+  std::error_code ec;
+  remove_all(p, ec);
+#endif
+}
+
 int
 main()
 {
@@ -193,4 +211,5 @@ main()
   test03();
   

[committed] libstdc++: Reset filesystem::recursive_directory_iterator on error

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.


The standard requires directory iterators to become equal to the end
iterator value if they report an error. Some members functions of
filesystem::recursive_directory_iterator fail to do that.

libstdc++-v3/ChangeLog:

* src/c++17/fs_dir.cc (recursive_directory_iterator::increment):
Reset state to past-the-end iterator on error.
(fs::recursive_directory_iterator::pop(error_code&)): Likewise.
(fs::recursive_directory_iterator::pop()): Check _M_dirs before
it might get reset.
* src/filesystem/dir.cc (recursive_directory_iterator): Likewise,
for the TS implementation.
* testsuite/27_io/filesystem/iterators/error_reporting.cc: New test.
* testsuite/experimental/filesystem/iterators/error_reporting.cc: New 
test.
---
 libstdc++-v3/src/c++17/fs_dir.cc  |  12 +-
 libstdc++-v3/src/filesystem/dir.cc|  12 +-
 .../filesystem/iterators/error_reporting.cc   | 135 +
 .../filesystem/iterators/error_reporting.cc   | 136 ++
 4 files changed, 291 insertions(+), 4 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/27_io/filesystem/iterators/error_reporting.cc
 create mode 100644 
libstdc++-v3/testsuite/experimental/filesystem/iterators/error_reporting.cc

diff --git a/libstdc++-v3/src/c++17/fs_dir.cc b/libstdc++-v3/src/c++17/fs_dir.cc
index e050304c19a..149a8b0740c 100644
--- a/libstdc++-v3/src/c++17/fs_dir.cc
+++ b/libstdc++-v3/src/c++17/fs_dir.cc
@@ -311,6 +311,10 @@ fs::recursive_directory_iterator::increment(error_code& ec)
  return *this;
}
 }
+
+  if (ec)
+_M_dirs.reset();
+
   return *this;
 }
 
@@ -334,16 +338,20 @@ fs::recursive_directory_iterator::pop(error_code& ec)
ec.clear();
return;
   }
-  } while (!_M_dirs->top().advance(skip_permission_denied, ec));
+  } while (!_M_dirs->top().advance(skip_permission_denied, ec) && !ec);
+
+  if (ec)
+_M_dirs.reset();
 }
 
 void
 fs::recursive_directory_iterator::pop()
 {
+  const bool dereferenceable = _M_dirs != nullptr;
   error_code ec;
   pop(ec);
   if (ec)
-_GLIBCXX_THROW_OR_ABORT(filesystem_error(_M_dirs
+_GLIBCXX_THROW_OR_ABORT(filesystem_error(dereferenceable
  ? "recursive directory iterator cannot pop"
  : "non-dereferenceable recursive directory iterator cannot pop",
  ec));
diff --git a/libstdc++-v3/src/filesystem/dir.cc 
b/libstdc++-v3/src/filesystem/dir.cc
index d5b11f25297..ac9e70da516 100644
--- a/libstdc++-v3/src/filesystem/dir.cc
+++ b/libstdc++-v3/src/filesystem/dir.cc
@@ -298,6 +298,10 @@ fs::recursive_directory_iterator::increment(error_code& 
ec) noexcept
  return *this;
}
 }
+
+  if (ec)
+_M_dirs.reset();
+
   return *this;
 }
 
@@ -321,16 +325,20 @@ fs::recursive_directory_iterator::pop(error_code& ec)
ec.clear();
return;
   }
-  } while (!_M_dirs->top().advance(skip_permission_denied, ec));
+  } while (!_M_dirs->top().advance(skip_permission_denied, ec) && !ec);
+
+  if (ec)
+_M_dirs.reset();
 }
 
 void
 fs::recursive_directory_iterator::pop()
 {
+  const bool dereferenceable = _M_dirs != nullptr;
   error_code ec;
   pop(ec);
   if (ec)
-_GLIBCXX_THROW_OR_ABORT(filesystem_error(_M_dirs
+_GLIBCXX_THROW_OR_ABORT(filesystem_error(dereferenceable
  ? "recursive directory iterator cannot pop"
  : "non-dereferenceable recursive directory iterator cannot pop",
  ec));
diff --git 
a/libstdc++-v3/testsuite/27_io/filesystem/iterators/error_reporting.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/iterators/error_reporting.cc
new file mode 100644
index 000..81ef1069367
--- /dev/null
+++ b/libstdc++-v3/testsuite/27_io/filesystem/iterators/error_reporting.cc
@@ -0,0 +1,135 @@
+// Copyright (C) 2020-2022 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do run { target { c++17 } } }
+// { dg-require-filesystem-ts "" }
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int choice;
+
+struct dirent global_dirent;
+
+extern "C" struct dirent* readdir(DIR*)
+{
+  switch (choice)
+  {
+  case 1:
+global_dirent.d_ino = 999;
+global_dirent.d_type = DT_REG;
+global_dirent.d_reclen = 0;
+   

[Bug libstdc++/97731] terminate called in std::experimental::filesystem::recursive_directory_iterator

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r12-6982-g2dc2f417288d4f0839b4bc01388e676ee343f941
Author: Jonathan Wakely 
Date:   Tue Feb 1 14:02:56 2022 +

libstdc++: Add more tests for filesystem directory iterators

The PR 97731 test was added to verify a fix to the Filesystem TS code,
but we should also have the same test to avoid similar regressions in
the C++17 std::filesystem code.

Also add tests for directory_options::follow_directory_symlink

libstdc++-v3/ChangeLog:

* testsuite/27_io/filesystem/iterators/97731.cc: New test.
*
testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc:
Check follow_directory_symlink option.
*
testsuite/experimental/filesystem/iterators/recursive_directory_iterator.cc:
Likewise.

[committed] libstdc++: Fix doxygen comment for filesystem::perms operators

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.


libstdc++-v3/ChangeLog:

* include/bits/fs_fwd.h (filesystem::perms): Fix comment.
---
 libstdc++-v3/include/bits/fs_fwd.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/bits/fs_fwd.h 
b/libstdc++-v3/include/bits/fs_fwd.h
index 75aaf554a05..bc063761080 100644
--- a/libstdc++-v3/include/bits/fs_fwd.h
+++ b/libstdc++-v3/include/bits/fs_fwd.h
@@ -160,7 +160,7 @@ _GLIBCXX_END_NAMESPACE_CXX11
   };
 
   /// @{
-  /// @relates perm_options
+  /// @relates perms
   constexpr perms
   operator&(perms __x, perms __y) noexcept
   {
-- 
2.34.1

[committed] libstdc++: Improve config output for --enable-cstdio [PR104301]

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.


Currently we just print "checking for underlying I/O to use... stdio"
unconditionally, whether configured to use stdio_pure or stdio_posix. We
should make it clear that the user's configure option chose the right
thing.

libstdc++-v3/ChangeLog:

PR libstdc++/104301
* acinclude.m4 (GLIBCXX_ENABLE_CSTDIO): Print different messages
for stdio_pure and stdio_posix options.
* configure: Regenerate.
---
 libstdc++-v3/acinclude.m4 | 4 +++-
 libstdc++-v3/configure| 7 +--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 32638e6bfc5..066453e2148 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -2830,11 +2830,13 @@ AC_DEFUN([GLIBCXX_ENABLE_CSTDIO], [
   CSTDIO_H=config/io/c_io_stdio.h
   BASIC_FILE_H=config/io/basic_file_stdio.h
   BASIC_FILE_CC=config/io/basic_file_stdio.cc
-  AC_MSG_RESULT(stdio)
 
   if test "x$enable_cstdio" = "xstdio_pure" ; then
+   AC_MSG_RESULT([stdio (without POSIX read/write)])
AC_DEFINE(_GLIBCXX_USE_STDIO_PURE, 1,
  [Define to restrict std::__basic_file<> to stdio APIs.])
+  else
+   AC_MSG_RESULT([stdio (with POSIX read/write)])
   fi
   ;;
   esac

[Bug libstdc++/104301] --enable-cstdio=stdio_pure not passed down to libstdc++-v3

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:19b8946dbda5fda4389ef8e3ea162c3df2b1998d

commit r12-6979-g19b8946dbda5fda4389ef8e3ea162c3df2b1998d
Author: Jonathan Wakely 
Date:   Mon Jan 31 11:00:18 2022 +

libstdc++: Improve config output for --enable-cstdio [PR104301]

Currently we just print "checking for underlying I/O to use... stdio"
unconditionally, whether configured to use stdio_pure or stdio_posix. We
should make it clear that the user's configure option chose the right
thing.

libstdc++-v3/ChangeLog:

PR libstdc++/104301
* acinclude.m4 (GLIBCXX_ENABLE_CSTDIO): Print different messages
for stdio_pure and stdio_posix options.
* configure: Regenerate.

Re: [PATCH v2 1/8] rs6000: More factoring of overload processing

[Segher Boessenkool]

On Tue, Feb 01, 2022 at 08:49:34AM -0600, Bill Schmidt wrote:
> I've modified the previous patch to add more explanatory commentary about
> the number-of-arguments test that was previously confusing, and to convert
> the switch into an if-then-else chain.  The rest of the patch is unchanged.
> Bootstrapped and tested on powerpc64le-linux-gnu.  Is this okay for trunk?

> gcc/
>   * config/rs6000/rs6000-c.cc (resolve_vec_mul): Accept args and types
>   parameters instead of arglist and nargs.  Simplify accordingly.  Remove
>   unnecessary test for argument count mismatch.
>   (resolve_vec_cmpne): Likewise.
>   (resolve_vec_adde_sube): Likewise.
>   (resolve_vec_addec_subec): Likewise.
>   (altivec_resolve_overloaded_builtin): Move overload special handling
>   after the gathering of arguments into args[] and types[] and the test
>   for correct number of arguments.  Don't perform the test for correct
>   number of arguments for certain special cases.  Call the other special
>   cases with args and types instead of arglist and nargs.

> +  if (fcode != RS6000_OVLD_VEC_PROMOTE
> +  && fcode != RS6000_OVLD_VEC_SPLATS
> +  && fcode != RS6000_OVLD_VEC_EXTRACT
> +  && fcode != RS6000_OVLD_VEC_INSERT
> +  && fcode != RS6000_OVLD_VEC_STEP
> +  && (!VOID_TYPE_P (TREE_VALUE (fnargs)) || n < nargs))
>  return NULL;

Please don't do De Morgan manually, let the compiler deal with it?
Although even with that the logic is as clear as mud.  This matters if
someone (maybe even you) will have to debug this later, or modify this.
Maybe adding some suitably named variables can clarify things  here?

> +  if (fcode == RS6000_OVLD_VEC_MUL)
> +returned_expr = resolve_vec_mul (, args, types, loc);
> +  else if (fcode == RS6000_OVLD_VEC_CMPNE)
> +returned_expr = resolve_vec_cmpne (, args, types, loc);
> +  else if (fcode == RS6000_OVLD_VEC_ADDE || fcode == RS6000_OVLD_VEC_SUBE)
> +returned_expr = resolve_vec_adde_sube (, fcode, args, types, loc);
> +  else if (fcode == RS6000_OVLD_VEC_ADDEC || fcode == RS6000_OVLD_VEC_SUBEC)
> +returned_expr = resolve_vec_addec_subec (, fcode, args, types, loc);
> +  else if (fcode == RS6000_OVLD_VEC_SPLATS || fcode == 
> RS6000_OVLD_VEC_PROMOTE)
> +returned_expr = resolve_vec_splats (, fcode, arglist, nargs);
> +  else if (fcode == RS6000_OVLD_VEC_EXTRACT)
> +returned_expr = resolve_vec_extract (, arglist, nargs, loc);
> +  else if (fcode == RS6000_OVLD_VEC_INSERT)
> +returned_expr = resolve_vec_insert (, arglist, nargs, loc);
> +  else if (fcode == RS6000_OVLD_VEC_STEP)
> +returned_expr = resolve_vec_step (, arglist, nargs);
> +
> +  if (res == resolved)
> +return returned_expr;

This is so convoluted because the functions do two things, and have two
return values (res and returned_expr).


Segher

Re: gcd_1.c:188:13: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

[Marc Glisse]

On Tue, 1 Feb 2022, Toon Moene wrote:


I just ran a "ubsan" build on my x86_64-linux-gnu system.

See: https://gcc.gnu.org/pipermail/gcc-testresults/2022-February/754454.html

This is an interesting failure:

Executing on host: 
/home/toon/scratch/bld1142336/gcc/testsuite/gfortran29/../../gfortran 
-B/home/toon/scratch/bld1142336/gcc/testsuite/gfortran29/../../ 
-B/home/toon/scratch/bld1142336/x86_64-pc-linux-gnu/./libgfortran/ 
/home/toon/compilers/gcc/gcc/testsuite/gfortran.dg/graphite/pr39516.f 
-fdiagnostics-plain-output  -fdiagnostics-plain-output-O  -O2 
-ftree-loop-linear -S -o pr39516.s(timeout = 300)
spawn -ignore SIGHUP 
/home/toon/scratch/bld1142336/gcc/testsuite/gfortran29/../../gfortran 
-B/home/toon/scratch/bld1142336/gcc/testsuite/gfortran29/../../ 
-B/home/toon/scratch/bld1142336/x86_64-pc-linux-gnu/./libgfortran/ 
/home/toon/compilers/gcc/gcc/testsuite/gfortran.dg/graphite/pr39516.f 
-fdiagnostics-plain-output -fdiagnostics-plain-output -O -O2 
-ftree-loop-linear -S -o pr39516.s
gcd_1.c:188:13: runtime error: shift exponent 64 is too large for 64-bit type 
'long unsigned int'

FAIL: gfortran.dg/graphite/pr39516.f   -O  (test for excess errors)
Excess errors:
gcd_1.c:188:13: runtime error: shift exponent 64 is too large for 64-bit type 
'long unsigned int'


Note that the test case is pure Fortran source. The undefined error seems to 
come from a function inside the graphite library ...


Maybe try with a more recent version of GMP first? gcd_1.c has only 103 
lines in release 6.2.1.


A stack trace (UBSAN_OPTIONS=print_stacktrace=1) would make it easier to 
guess where this is coming from.


--
Marc Glisse

[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce

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

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> We could limit the size of the resulting array constructor, using e.g.
> flag_max_array_constructor.

Sample patch:

diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index 6483f9c31e7..15a2b36eed9 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -8152,6 +8152,15 @@ gfc_simplify_transfer (gfc_expr *source, gfc_expr *mold,
gfc_expr *size)
   if (source->expr_type == EXPR_ARRAY && !gfc_array_size (source, ))
 gfc_internal_error ("Failure getting length of a constant array.");

+  if (size && mpz_cmp_si (size->value.integer, flag_max_array_constructor) >
0)
+{
+  gfc_error ("The number of elements in the array constructor "
+"at %L requires an increase of the allowed %d "
+"upper limit.   See %<-fmax-array-constructor%> "
+"option", >where, flag_max_array_constructor);
+  return NULL;
+}
+
   /* Create an empty new expression with the appropriate characteristics.  */
   result = gfc_get_constant_expr (mold->ts.type, mold->ts.kind,
  >where);

[Bug tree-optimization/104336] bogus -Wrestrict for std::string assignment with

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
URL||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=2047428
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=98465
   Last reconfirmed||2022-02-01
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 Blocks||84774


Referenced Bugs:

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

[Bug tree-optimization/104336] New: bogus -Wrestrict for std::string assignment with

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

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

Bug ID: 104336
   Summary: bogus -Wrestrict for std::string assignment with
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following false positive was reported in
https://bugzilla.redhat.com/show_bug.cgi?id=2047428.  It boils down to the same
underlying problem as in pr98465.

$ cat t.C && g++ -O2 -S -Wall -D_GLIBCXX_ASSERTIONS t.C
#include 

std::string s;

void f (void)
{
  s = "/";
}

In file included from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/string:40,
 from ../t.C:1:
In static member function ‘static std::char_traits::char_type*
std::char_traits::copy(char_type*, const char_type*, std::size_t)’,
inlined from ‘static void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_S_copy(_CharT*, const _CharT*, size_type) [with _CharT = char;
_Traits = std::char_traits; _Alloc = std::allocator]’ at
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:423:21,
inlined from ‘static void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_S_copy(_CharT*, const _CharT*, size_type) [with _CharT = char;
_Traits = std::char_traits; _Alloc = std::allocator]’ at
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:418:7,
inlined from ‘std::__cxx11::basic_string<_CharT, _Traits, _Allocator>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_M_replace(size_type,
size_type, const _CharT*, size_type) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]’ at
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:532:22,
inlined from ‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::assign(const _CharT*)
[with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’ at
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:1647:19,
inlined from ‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const _CharT*)
[with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’ at
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:815:28,
inlined from ‘void f()’ at ../t.C:7:7:
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:431:56:
warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’
accessing 9223372036854775810 or more bytes at offsets -4611686018427387902 and
[-4611686018427387903, 4611686018427387904] may overlap up to
9223372036854775813 bytes at offset -3 [-Wrestrict]
  431 | return static_cast(__builtin_memcpy(__s1, __s2,
__n));
  |   
^

[Bug target/104335] [12 regression] build failure if go is included in languages after r12-6747

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

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

Bill Schmidt  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Keywords||build, ice-on-valid-code

[Bug fortran/104330] ICE in gfc_simplify_image_index, at fortran/simplify.cc:8294

[gscfq--- via Gcc-bugs]

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

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

Better test cases (valid) instead of accidentally invalid z2.f90 :


$ cat zz4.f90
program p
   class(*), allocatable :: x[:]
   allocate (real :: x[*])
   print *, image_index(x, [1])
end


$ cat zz5.f90
program p
   class(*), allocatable :: x[:,:]
   allocate (real :: x[8,*])
   print *, image_index(x, [5,3])
end


$ cat zz7.f90
program p
   type t
   end type
   class(*), allocatable :: x[:,:,:]
   allocate (t :: x[8,8,*])
   print *, image_index(x, [3,2,1])
end

[Bug target/104335] New: [12 regression] build failure if go is included in languages after r12-6747

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

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

Bug ID: 104335
   Summary: [12 regression] build failure if go is included in
languages after r12-6747
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:aa8cfe785953a0e87d2472311e1260cd98c605c0, r12-6747 

This is a non-bootstrap build on a power 10 system with the configuration: 
configure --enable-languages=all --with-cpu=power10 --disable-bootstrap 


libtool: compile:  /home/seurer/gcc/git/build/gcc-test/./gcc/gccgo
-B/home/seurer/gcc/git/build/gcc-test/./gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
-O2 -g -I . -c -fgo-pkgpath=golang.org/x/tools/internal/analysisinternal
/home/seurer/gcc/git/gcc-test/libgo/go/golang.org/x/tools/internal/analysisinternal/analysis.go
-o golang.org/x/tools/internal/analysisinternal.o
during RTL pass: ce2
/home/seurer/gcc/git/gcc-test/libgo/go/golang.org/x/tools/internal/analysisinternal/analysis.go:
In function 'golang.org/x/tools/internal/analysisinternal.FindBestMatch':
/home/seurer/gcc/git/gcc-test/libgo/go/golang.org/x/tools/internal/analysisinternal/analysis.go:402:1:
internal compiler error: in validate_condition_mode, at
config/rs6000/rs6000.cc:11358
  402 | func FindBestMatch(pattern string, idents []*ast.Ident) ast.Expr {
  | ^
0x11128e5f validate_condition_mode(rtx_code, machine_mode)
/home/seurer/gcc/git/gcc-test/gcc/config/rs6000/rs6000.cc:11354
0x1112909b rs6000_generate_compare
/home/seurer/gcc/git/gcc-test/gcc/config/rs6000/rs6000.cc:15153
0x11132f63 rs6000_emit_int_cmove(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
/home/seurer/gcc/git/gcc-test/gcc/config/rs6000/rs6000.cc:16320
0x11840903 gen_movsicc(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
/home/seurer/gcc/git/gcc-test/gcc/config/rs6000/rs6000.md:5365
0x10a678e7 rtx_insn* insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*, rtx_def*) const
/home/seurer/gcc/git/gcc-test/gcc/recog.h:407
0x10a678e7 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/home/seurer/gcc/git/gcc-test/gcc/optabs.cc:7962
0x10a68a93 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/home/seurer/gcc/git/gcc-test/gcc/optabs.cc:7993
0x10a68a93 emit_conditional_move_1
/home/seurer/gcc/git/gcc-test/gcc/optabs.cc:5030
0x10a68a93 emit_conditional_move_1
/home/seurer/gcc/git/gcc-test/gcc/optabs.cc:4991
0x10a68bdb emit_conditional_move(rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*, machine_mode)
/home/seurer/gcc/git/gcc-test/gcc/optabs.cc:4980
0x11b9408f noce_emit_cmove
/home/seurer/gcc/git/gcc-test/gcc/ifcvt.cc:1753
0x11b94d5b try_emit_cmove_seq
/home/seurer/gcc/git/gcc-test/gcc/ifcvt.cc:3179
0x11b9c0a7 noce_convert_multiple_sets
/home/seurer/gcc/git/gcc-test/gcc/ifcvt.cc:3394
0x11b9d8bf noce_process_if_block
/home/seurer/gcc/git/gcc-test/gcc/ifcvt.cc:3613
0x11ba08bf noce_find_if_block
/home/seurer/gcc/git/gcc-test/gcc/ifcvt.cc:4367
0x11ba08bf find_if_header
/home/seurer/gcc/git/gcc-test/gcc/ifcvt.cc:4572
0x11ba08bf if_convert
/home/seurer/gcc/git/gcc-test/gcc/ifcvt.cc:5713
0x11ba1a0b execute
/home/seurer/gcc/git/gcc-test/gcc/ifcvt.cc:5866


commit e9ebb86799fd77cdd5351078230c114a90e66066 (HEAD)
Author: Robin Dapp 
Date:   Wed Nov 27 13:53:40 2019 +0100

ifcvt/optabs: Allow using a CC comparison for emit_conditional_move.

gcd_1.c:188:13: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

[Toon Moene]

I just ran a "ubsan" build on my x86_64-linux-gnu system.

See: https://gcc.gnu.org/pipermail/gcc-testresults/2022-February/754454.html

This is an interesting failure:

Executing on host: 
/home/toon/scratch/bld1142336/gcc/testsuite/gfortran29/../../gfortran 
-B/home/toon/scratch/bld1142336/gcc/testsuite/gfortran29/../../ 
-B/home/toon/scratch/bld1142336/x86_64-pc-linux-gnu/./libgfortran/ 
/home/toon/compilers/gcc/gcc/testsuite/gfortran.dg/graphite/pr39516.f 
 -fdiagnostics-plain-output  -fdiagnostics-plain-output-O  -O2 
-ftree-loop-linear -S -o pr39516.s(timeout = 300)
spawn -ignore SIGHUP 
/home/toon/scratch/bld1142336/gcc/testsuite/gfortran29/../../gfortran 
-B/home/toon/scratch/bld1142336/gcc/testsuite/gfortran29/../../ 
-B/home/toon/scratch/bld1142336/x86_64-pc-linux-gnu/./libgfortran/ 
/home/toon/compilers/gcc/gcc/testsuite/gfortran.dg/graphite/pr39516.f 
-fdiagnostics-plain-output -fdiagnostics-plain-output -O -O2 
-ftree-loop-linear -S -o pr39516.s
gcd_1.c:188:13: runtime error: shift exponent 64 is too large for 64-bit 
type 'long unsigned int'

FAIL: gfortran.dg/graphite/pr39516.f   -O  (test for excess errors)
Excess errors:
gcd_1.c:188:13: runtime error: shift exponent 64 is too large for 64-bit 
type 'long unsigned int'


Note that the test case is pure Fortran source. The undefined error 
seems to come from a function inside the graphite library ...


Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

Re: [PATCH] IBM Z: fix `section type conflict` with -mindirect-branch-table

[Andreas Krebbel via Gcc-patches]

On 2/1/22 21:49, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux.  Ok for master?
> 
> 
> s390_code_end () puts indirect branch tables into separate sections and
> tries to switch back to wherever it was in the beginning by calling
> switch_to_section (current_function_section ()).
> 
> First of all, this is unnecessary - the other backends don't do it.
> 
> Furthermore, at this time there is no current function, but if the
> last processed function was cold, in_cold_section_p remains set.  This
> causes targetm.asm_out.function_section () to call
> targetm.section_type_flags (), which in absence of current function
> decl classifies the section as SECTION_WRITE.  This causes a section
> type conflict with the existing SECTION_CODE.
> 
> gcc/ChangeLog:
> 
>   * config/s390/s390.cc (s390_code_end): Do not switch back to
>   code section.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/s390/nobp-section-type-conflict.c: New test.

Ok. Thanks!

Andreas


> ---
>  gcc/config/s390/s390.cc   |  1 -
>  .../s390/nobp-section-type-conflict.c | 22 +++
>  2 files changed, 22 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.target/s390/nobp-section-type-conflict.c
> 
> diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
> index 43c5c72554a..2db12d4ba4b 100644
> --- a/gcc/config/s390/s390.cc
> +++ b/gcc/config/s390/s390.cc
> @@ -16809,7 +16809,6 @@ s390_code_end (void)
> assemble_name_raw (asm_out_file, label_start);
> fputs ("-.\n", asm_out_file);
>   }
> -   switch_to_section (current_function_section ());
>   }
>  }
>  }
> diff --git a/gcc/testsuite/gcc.target/s390/nobp-section-type-conflict.c 
> b/gcc/testsuite/gcc.target/s390/nobp-section-type-conflict.c
> new file mode 100644
> index 000..5d78bc99bb5
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/s390/nobp-section-type-conflict.c
> @@ -0,0 +1,22 @@
> +/* Checks that we don't get error: section type conflict with ‘put_page’.  */
> +
> +/* { dg-do compile } */
> +/* { dg-options "-mindirect-branch=thunk-extern 
> -mfunction-return=thunk-extern -mindirect-branch-table -O2" } */
> +
> +int a;
> +int b (void);
> +void c (int);
> +
> +static void
> +put_page (void)
> +{
> +  if (b ())
> +c (a);
> +}
> +
> +__attribute__ ((__section__ (".init.text"), __cold__)) void
> +d (void)
> +{
> +  put_page ();
> +  put_page ();
> +}

[Bug fortran/104332] [9/10/11/12 Regression] ICE in resolve_symbol, at fortran/resolve.cc:15815

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #4 from Steve Kargl  ---
On Tue, Feb 01, 2022 at 08:04:45PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104332
> 
> kargl at gcc dot gnu.org changed:
> 
>What|Removed |Added
> 
>  Ever confirmed|0   |1
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2022-02-01
> 
> --- Comment #3 from kargl at gcc dot gnu.org ---
> (In reply to G. Steinmetz from comment #0)
> > Affects versions down to r8 (ifort/ifx rejects it) :
> > 
> > 
> > $ cat z1.f90
> > block data
> >bind(c) a
> > end
> > 
> 
> This fixes the ICE by avoiding a NULL pointer dereference.
> 
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 835a4783718..0ea68c707a0 100644
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc 
> @@ -15812,8 +15815,9 @@ resolve_symbol (gfc_symbol *sym)
> 
>/* First, make sure the variable is declared at the
>  module-level scope (J3/04-007, Section 15.3).  */
> -  if (sym->ns->proc_name->attr.flavor != FL_MODULE &&
> -  sym->attr.in_common == 0)
> +  if (sym->ns->proc_name
> + && sym->ns->proc_name->attr.flavor != FL_MODULE
> + && sym->attr.in_common == 0)
> {
>   gfc_error ("Variable %qs at %L cannot be BIND(C) because it "
>  "is neither a COMMON block nor declared at the "

OK. So, the above stops the ICE, but allows the code to compile,
which is bad.  The code is invalid by C819.  From C1415, the 
BIND statement would apply to a common block.  Thus, the following
is valid code

block data
   common /a/x
   bind(c) :: /a/
end block data

[PATCH] IBM Z: fix `section type conflict` with -mindirect-branch-table

[Ilya Leoshkevich via Gcc-patches]

Bootstrapped and regtested on s390x-redhat-linux.  Ok for master?


s390_code_end () puts indirect branch tables into separate sections and
tries to switch back to wherever it was in the beginning by calling
switch_to_section (current_function_section ()).

First of all, this is unnecessary - the other backends don't do it.

Furthermore, at this time there is no current function, but if the
last processed function was cold, in_cold_section_p remains set.  This
causes targetm.asm_out.function_section () to call
targetm.section_type_flags (), which in absence of current function
decl classifies the section as SECTION_WRITE.  This causes a section
type conflict with the existing SECTION_CODE.

gcc/ChangeLog:

* config/s390/s390.cc (s390_code_end): Do not switch back to
code section.

gcc/testsuite/ChangeLog:

* gcc.target/s390/nobp-section-type-conflict.c: New test.
---
 gcc/config/s390/s390.cc   |  1 -
 .../s390/nobp-section-type-conflict.c | 22 +++
 2 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/s390/nobp-section-type-conflict.c

diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index 43c5c72554a..2db12d4ba4b 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -16809,7 +16809,6 @@ s390_code_end (void)
  assemble_name_raw (asm_out_file, label_start);
  fputs ("-.\n", asm_out_file);
}
- switch_to_section (current_function_section ());
}
 }
 }
diff --git a/gcc/testsuite/gcc.target/s390/nobp-section-type-conflict.c 
b/gcc/testsuite/gcc.target/s390/nobp-section-type-conflict.c
new file mode 100644
index 000..5d78bc99bb5
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/nobp-section-type-conflict.c
@@ -0,0 +1,22 @@
+/* Checks that we don't get error: section type conflict with ‘put_page’.  */
+
+/* { dg-do compile } */
+/* { dg-options "-mindirect-branch=thunk-extern -mfunction-return=thunk-extern 
-mindirect-branch-table -O2" } */
+
+int a;
+int b (void);
+void c (int);
+
+static void
+put_page (void)
+{
+  if (b ())
+c (a);
+}
+
+__attribute__ ((__section__ (".init.text"), __cold__)) void
+d (void)
+{
+  put_page ();
+  put_page ();
+}
-- 
2.34.1

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation

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

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

--- Comment #1 from Jakub Jelinek  ---
Also tried
../configure --enable-bootstrap --enable-languages=c,c++
--enable-checking=release --disable-multilib --with-tune=generic
build, but there it doesn't reproduce in either of stage1 or stage2 (stage3
still building).
So most probably LTO bootstrap is the trigger :(.

[Bug fortran/104331] [10/11 Regression] ICE in gfc_simplify_eoshift, at fortran/simplify.cc:2590

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
   Target Milestone|--- |10.4
Summary|[10/11/12 Regression] ICE   |[10/11 Regression] ICE in
   |in gfc_simplify_eoshift, at |gfc_simplify_eoshift, at
   |fortran/simplify.cc:2590|fortran/simplify.cc:2590

--- Comment #3 from anlauf at gcc dot gnu.org ---
Taking.

[pushed] PR fortran/104331 - [10/11/12 Regression] ICE in gfc_simplify_eoshift, at fortran/simplify.cc:2590

[Harald Anlauf via Gcc-patches]

Dear all,

another trivial and obvious one, discovered by Gerhard.

We can have a NULL pointer dereference simplifying EOSHIFT on an array
that was not properly declared.

Pushed to mainline as r12-6977 after regtesting on x86_64-pc-linux-gnu.
Will backport to affected branches [11/10] with some delay.

Thanks,
Harald

From 447047a8f95c6bf4b1873f390c833e91aa8af18c Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Tue, 1 Feb 2022 21:36:42 +0100
Subject: [PATCH] Fortran: error recovery when simplifying EOSHIFT

gcc/fortran/ChangeLog:

	PR fortran/104331
	* simplify.cc (gfc_simplify_eoshift): Avoid NULL pointer
	dereference when shape is not set.

gcc/testsuite/ChangeLog:

	PR fortran/104331
	* gfortran.dg/eoshift_9.f90: New test.
---
 gcc/fortran/simplify.cc | 3 +++
 gcc/testsuite/gfortran.dg/eoshift_9.f90 | 8 
 2 files changed, 11 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/eoshift_9.f90

diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index 8604162cfd5..6483f9c31e7 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -2572,6 +2572,9 @@ gfc_simplify_eoshift (gfc_expr *array, gfc_expr *shift, gfc_expr *boundary,
   if (arraysize == 0)
 goto final;

+  if (array->shape == NULL)
+goto final;
+
   arrayvec = XCNEWVEC (gfc_expr *, arraysize);
   array_ctor = gfc_constructor_first (array->value.constructor);
   for (i = 0; i < arraysize; i++)
diff --git a/gcc/testsuite/gfortran.dg/eoshift_9.f90 b/gcc/testsuite/gfortran.dg/eoshift_9.f90
new file mode 100644
index 000..f711b04a7da
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/eoshift_9.f90
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! PR fortran/104331 - ICE in gfc_simplify_eoshift
+! Contributed by G.Steinmetz
+
+program p
+  character(3), parameter :: a(:) = ['123'] ! { dg-error "deferred shape" }
+  character(3), parameter :: b(*) = eoshift(a, 1)
+end
--
2.34.1

[Bug fortran/104331] [10/11/12 Regression] ICE in gfc_simplify_eoshift, at fortran/simplify.cc:2590

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

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

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

https://gcc.gnu.org/g:447047a8f95c6bf4b1873f390c833e91aa8af18c

commit r12-6977-g447047a8f95c6bf4b1873f390c833e91aa8af18c
Author: Harald Anlauf 
Date:   Tue Feb 1 21:36:42 2022 +0100

Fortran: error recovery when simplifying EOSHIFT

gcc/fortran/ChangeLog:

PR fortran/104331
* simplify.cc (gfc_simplify_eoshift): Avoid NULL pointer
dereference when shape is not set.

gcc/testsuite/ChangeLog:

PR fortran/104331
* gfortran.dg/eoshift_9.f90: New test.

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|Ranger/dom miscompilation   |[12 Regression] Ranger/dom
   ||miscompilation
   Priority|P3  |P1
   Target Milestone|--- |12.0

[Bug tree-optimization/104334] New: Ranger/dom miscompilation

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

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

Bug ID: 104334
   Summary: Ranger/dom miscompilation
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

enum class A { A0, A1, A2, A3 };
int x;

__attribute__((noipa)) void
baz ()
{
  x = 1;
}

struct B {
  unsigned b : 2;

  A
  foo () const
  {
return static_cast (b);
  }

  __attribute__((noinline)) void
  bar ()
  {
if (foo () == A::A2 || foo () == A::A3)
  baz ();
  }
};

int
main ()
{
  B c;
  c.b = 2;
  c.bar ();
  if (x != 1)
__builtin_abort ();
  return 0;
}

is miscompiled on x86_64-linux with -O2 --param logical-op-non-short-circuit=0
and on powerpc64le-linux and s390x-linux with just -O2.
Strangely, I can't reproduce it with cross-compilers or -O0 built cc1plus or
even cc1plus bootstrapped my usual way:
../configure --enable-languages=default,ada,obj-c++,lto,go,d
--enable-checking=yes,rtl,extra --enable-libstdcxx-backtrace=yes
but can reproduce it in:
./configure --enable-bootstrap --enable-languages=c,c++
--enable-checking=release --disable-multilib --with-tune=generic
--with-build-config=bootstrap-lto --enable-link-serialization=1
(but there only in second and third stages, stage1-gcc still doesn't miscompile
it).
thread2 dump is still identical between non-miscompiled and miscompiled cases,
we have there:
   _5;
   _7;

   [local count: 1073741823]:
  _5 = MEM[(const struct B *)this_3(D)].b;
  _7 = _5 + 2;
  if (_7 <= 1)
(frankly weird to do the addition and comparison in unsigned:2 type, but it is
what reassoc comes up with.  Furthermore, for unsigned:2 type, test for value
in [2,3] range can be done with just
_5 >= 2 and doesn't need to do the addition).
The difference is in dom3 dump (-fdump-tree-all-alias-details):
@@ -66,11 +66,11 @@ LKUP STMT _5 = MEM[(const struct B *)thi
 extract_range_from_stmt visiting:
 _7 = _5 + 2;
 Intersecting
-   VARYING
+   [1, +INF]
 and
VARYING
 to
-   VARYING
+   [1, +INF]
 Optimizing statement _7 = _5 + 2;
 LKUP STMT _7 = _5 plus_expr 2
 2>>> STMT _7 = _5 plus_expr 2
@@ -79,7 +79,7 @@ Optimizing statement if (_7 <= 1)
 Visiting conditional with predicate: if (_7 <= 1)

 With known ranges
-   _7:  VARYING
+   _7:  [1, +INF]

 Predicate evaluates to: DON'T KNOW
 LKUP STMT _7 le_expr 1
@@ -94,9 +94,9 @@ Adding assert for _5 from _5 + 2 <= 1
 Intersecting
[0, 1]  EQUIVALENCES: { _7 } (1 elements)
 and
-   VARYING
+   [1, +INF]
 to
-   [0, 1]  EQUIVALENCES: { _7 } (1 elements)
+   [1, 1]  EQUIVALENCES: { _7 } (1 elements)
 Intersecting
[2, +INF]  EQUIVALENCES: { _5 } (1 elements)
 and
@@ -104,12 +104,12 @@ and
 to
[2, +INF]  EQUIVALENCES: { _5 } (1 elements)
 Intersecting
-   VARYING
+   [1, +INF]
 and
-   [0, 1]
+   [1, 1]
 to
-   [0, 1]
-pushing new range for _7:  [0, 1]  EQUIVALENCES: { _7 } (1
elements)
+   [1, 1]
+pushing new range for _7:  [1, 1]  EQUIVALENCES: { _7 } (1
elements)
 Intersecting
VARYING
 and
@@ -123,7 +123,7 @@ Optimizing statement baz ();
  STMT 0 = _7 gt_expr 1
  STMT 1 = _7 le_expr 1
 popping range for _5, restoring  VARYING
-popping range for _7, restoring  VARYING
+popping range for _7, restoring  [1, +INF]


 Optimizing block #4
@@ -144,6 +144,7 @@ void B::bar (struct B * const this)

[local count: 1073741823]:
   _5 = MEM[(const struct B *)this_3(D)].b;
+  # RANGE [1, 3]
   _7 = _5 + 2;
   if (_7 <= 1)
 goto ; [20.24%]

and the bogus # RANGE in the last hunk is what is the problem, both _5 and _7
have actually VARYING range (aka [0, 3]).

Prerequisites page lists http://multiprecision.org but it supports https too/instead

[Jonathan Leffler via Gcc]

The prerequisites page https://gcc.gnu.org/install/prerequisites.html lists
(for MPC):

It can be downloaded from http://www.multiprecision.org/mpc/.


The website actually supports https now: https://www.multiprecision.org/mpc/

-- 
Jonathan Leffler   #include 
Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."

[PATCH] reload: Adjust comment in find_reloads about subset, not intersection

[Hans-Peter Nilsson via Gcc-patches]

> From: Richard Sandiford 
> Hans-Peter Nilsson via Gcc-patches  writes:
> > The mystery isn't so much that there's code mismatching comments or
> > intent, but that this code has been there "forever".  There has been a
> > function reg_classes_intersect_p, in gcc since r0-54, even *before*
> > there was reload.c; r0-361, so why the "we don't have a way of forming
> > the intersection" in the actual patch and why wasn't this fixed
> > (perhaps not even noticed) when reload was state-of-the-art?
> 
> But doesn't the comment

(the second, patched comment; removed in the patch)

> mean that we have/had no way of getting
> a *class* that is the intersection of preferred_class[i] and
> this_alternative[i], to store as the new
> this_alternative[i]?

Yes, that's likely what's going on in the (second) comment
and code; needing a s/intersection/a class for the
intersection/, but the *first* comment is pretty clear that
the intent is exactly to "override" this_alternative[i]: "If
not (a subclass), but it intersects that class, use the
preferred class instead".  But of course, that doesn't
actually have to make sense as code!  And indeed it doesn't,
as you say.

> If the alternatives were register sets rather than classes,
> I think the intended effect would be:
> 
>   this_alternative[i] &= preferred_class[i];
> 
> (i.e. AND_HARD_REG_SET in old money).
> 
> It looks like the patch would instead make this_alternative[i] include
> registers that the alternative doesn't actually accept, which feels odd.

Perhaps I put too much trust in the sanity of old comments.

How about I actually commit this one instead?  Better get it
right before reload is removed.

8< --- >8
"reload: Adjust comment in find_reloads about subset, not intersection"
gcc:

* reload.cc (find_reloads): Align comment with code where
considering the intersection of register classes then tweaking the
regclass for the current alternative or rejecting it.
---
 gcc/reload.cc | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/gcc/reload.cc b/gcc/reload.cc
index 664082a533d9..3ed901e39447 100644
--- a/gcc/reload.cc
+++ b/gcc/reload.cc
@@ -3635,9 +3635,11 @@ find_reloads (rtx_insn *insn, int replace, int 
ind_levels, int live_known,
 a hard reg and this alternative accepts some
 register, see if the class that we want is a subset
 of the preferred class for this register.  If not,
-but it intersects that class, use the preferred class
-instead.  If it does not intersect the preferred
-class, show that usage of this alternative should be
+but it intersects that class, we'd like to use the
+intersection, but the best we can do is to use the
+preferred class, if it is instead a subset of the
+class we want in this alternative.  If we can't use
+it, show that usage of this alternative should be
 discouraged; it will be discouraged more still if the
 register is `preferred or nothing'.  We do this
 because it increases the chance of reusing our spill
@@ -3664,9 +3666,10 @@ find_reloads (rtx_insn *insn, int replace, int 
ind_levels, int live_known,
  if (! reg_class_subset_p (this_alternative[i],
preferred_class[i]))
{
- /* Since we don't have a way of forming the intersection,
-we just do something special if the preferred class
-is a subset of the class we have; that's the most
+ /* Since we don't have a way of forming a register
+class for the intersection, we just do
+something special if the preferred class is a
+subset of the class we have; that's the most
 common case anyway.  */
  if (reg_class_subset_p (preferred_class[i],
  this_alternative[i]))
-- 
2.30.2

[Bug fortran/104332] [9/10/11/12 Regression] ICE in resolve_symbol, at fortran/resolve.cc:15815

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/104332] [9/10/11/12 Regression] ICE in resolve_symbol, at fortran/resolve.cc:15815

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> Affects versions down to r8 (ifort/ifx rejects it) :
> 
> 
> $ cat z1.f90
> block data
>bind(c) a
> end
> 

This fixes the ICE by avoiding a NULL pointer dereference.

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 835a4783718..0ea68c707a0 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc 
@@ -15812,8 +15815,9 @@ resolve_symbol (gfc_symbol *sym)

   /* First, make sure the variable is declared at the
 module-level scope (J3/04-007, Section 15.3).  */
-  if (sym->ns->proc_name->attr.flavor != FL_MODULE &&
-  sym->attr.in_common == 0)
+  if (sym->ns->proc_name
+ && sym->ns->proc_name->attr.flavor != FL_MODULE
+ && sym->attr.in_common == 0)
{
  gfc_error ("Variable %qs at %L cannot be BIND(C) because it "
 "is neither a COMMON block nor declared at the "

[Bug preprocessor/104147] [9/10/11 Regression] C preprocessor may remove the standard required whitespace between the preprocessing tokens

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] C   |[9/10/11 Regression] C
   |preprocessor may remove the |preprocessor may remove the
   |standard required   |standard required
   |whitespace between the  |whitespace between the
   |preprocessing tokens|preprocessing tokens

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/104323] [12 Regression] PCH (and maybe GC) of rs6000 builtins broken

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug preprocessor/104147] [9/10/11/12 Regression] C preprocessor may remove the standard required whitespace between the preprocessing tokens

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

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

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

https://gcc.gnu.org/g:95ac5635409606386259d2ff21fb61738858ca4a

commit r12-6976-g95ac5635409606386259d2ff21fb61738858ca4a
Author: Jakub Jelinek 
Date:   Tue Feb 1 20:48:03 2022 +0100

libcpp: Fix up padding handling in funlike_invocation_p [PR104147]

As mentioned in the PR, in some cases we preprocess incorrectly when we
encounter an identifier which is defined as function-like macro, followed
by at least 2 CPP_PADDING tokens and then some other identifier.
On the following testcase, the problem is in the 3rd funlike_invocation_p,
the tokens are CPP_NAME Y, CPP_PADDING (the pfile->avoid_paste shared
token),
CPP_PADDING (one created with padding_token, val.source is non-NULL and
val.source->flags & PREV_WHITE is non-zero) and then another CPP_NAME.
funlike_invocation_p remembers there was a padding token, but remembers the
first one because of its condition, then the next token is the CPP_NAME,
which is not CPP_OPEN_PAREN, so the CPP_NAME token is backed up, but as we
can't easily backup more tokens, it pushes into a new context the padding
token (the pfile->avoid_paste one).  The net effect is that when Y is not
defined as fun-like macro, we read Y, avoid_paste, padding_token, Y,
while if Y is fun-like macro, we read Y, avoid_paste, avoid_paste, Y
(the second avoid_paste is because that is how we handle end of a context).
Now, for stringify_arg that is unfortunately a significant difference,
which handles CPP_PADDING tokens with:
  if (token->type == CPP_PADDING)
{
  if (source == NULL
  || (!(source->flags & PREV_WHITE)
  && token->val.source == NULL))
source = token->val.source;
  continue;
}
and later on
  /* Leading white space?  */
  if (dest - 1 != BUFF_FRONT (pfile->u_buff))
{
  if (source == NULL)
source = token;
  if (source->flags & PREV_WHITE)
*dest++ = ' ';
}
  source = NULL;
(and c-ppoutput.cc has similar code).
So, when Y is not fun-like macro, ' ' is added because padding_token's
val.source->flags & PREV_WHITE is non-zero, while when it is fun-like
macro, we don't add ' ' in between, because source is NULL and so
used from the next token (CPP_NAME Y), which doesn't have PREV_WHITE set.

Now, the funlike_invocation_p condition
   if (padding == NULL
   || (!(padding->flags & PREV_WHITE) && token->val.source ==
NULL))
padding = token;
looks very similar to that in stringify_arg/c-ppoutput.cc, so I assume
the intent was to prefer do the same thing and pick the right padding.
But there are significant differences.  Both stringify_arg and
c-ppoutput.cc
don't remember the CPP_PADDING token, but its val.source instead, while
in funlike_invocation_p we want to remember the padding token that has the
significant information for stringify_arg/c-ppoutput.cc.
So, IMHO we want to overwrite padding if:
1) padding == NULL (remember that there was any padding at all)
2) padding->val.source == NULL (this matches the source == NULL
   case in stringify_arg)
3) !(padding->val.source->flags & PREV_WHITE) && token->val.source == NULL
   (this matches the !(source->flags & PREV_WHITE) && token->val.source ==
NULL
   case in stringify_arg)

2022-02-01  Jakub Jelinek  

PR preprocessor/104147
* macro.cc (funlike_invocation_p): For padding prefer a token
with val.source non-NULL especially if it has PREV_WHITE set
on val.source->flags.  Add gcc_assert that CPP_PADDING tokens
don't have PREV_WHITE set in flags.

* c-c++-common/cpp/pr104147.c: New test.

Re: [PATCH] declare std::array members attribute const [PR101831]

[Jonathan Wakely via Gcc-patches]

On Tue, 1 Feb 2022 at 18:54, Martin Sebor via Libstdc++
 wrote:
>
> Passing an uninitialized object to a function that takes its argument
> by const reference is diagnosed by -Wmaybe-uninitialized because most
> such functions read the argument.  The exceptions are functions that
> don't access the object but instead use its address to compute
> a result.  This includes a number of std::array member functions such
> as std::array::size() which returns the template argument N.  Such
> functions may be candidates for attribute const which also avoids
> the warning.  The attribute typically only benefits extern functions
> that IPA cannot infer the property from, but in this case it helps
> avoid the warning which runs very early on, even without optimization
> or inlining.  The attached patch adds the attribute to a subset of
> those member functions of std::array.  (It doesn't add it to const
> member functions like cbegin() or front() that return a const_iterator
> or const reference to the internal data.)
>
> It might be possible to infer this property from inline functions
> earlier on than during IPA and avoid having to annotate them explicitly.
> That seems like an enhancement worth considering in the future.
>
> Tested on x86_64-linux.
>
> Martin

new file mode 100644
index 000..b7743adf3c9
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/array/iterators/begin_end.cc
@@ -0,0 +1,56 @@
+// { dg-do compile { target c++11 } }
+//
+// Copyright (C) 2011-2022 Free Software Foundation, Inc.

Those dates look wrong. I no longer bother putting a license text and
copyright notice on simple tests like this. It's meaningless to assert
copyright on something so trivial that doesn't do anything.

[Bug target/104323] [12 Regression] PCH (and maybe GC) of rs6000 builtins broken

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

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

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

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

commit r12-6974-gfa882c3e3bf642e0ef30772e4b54a2851497db96
Author: Jakub Jelinek 
Date:   Tue Feb 1 20:22:14 2022 +0100

rs6000: Fix up PCH on powerpc* [PR104323]

As mentioned in the PR and as can be seen on:
--- gcc/testsuite/gcc.dg/pch/pr104323-1.c.jj2022-02-01
13:06:00.163192414 +0100
+++ gcc/testsuite/gcc.dg/pch/pr104323-1.c   2022-02-01
13:13:41.226712735 +0100
@@ -0,0 +1,16 @@
+/* PR target/104323 */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec" } */
+
+#include "pr104323-1.h"
+
+__vector int a1 = { 100, 200, 300, 400 };
+__vector int a2 = { 500, 600, 700, 800 };
+__vector int r;
+
+int
+main ()
+{
+  r = vec_add (a1, a2);
+  return 0;
+}
--- gcc/testsuite/gcc.dg/pch/pr104323-1.hs.jj   2022-02-01
13:06:03.180149978 +0100
+++ gcc/testsuite/gcc.dg/pch/pr104323-1.hs  2022-02-01
13:12:30.175706620 +0100
@@ -0,0 +1,5 @@
+/* PR target/104323 */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec" } */
+
+#include 
testcase which I'm not including into testsuite because for some reason
the test fails on non-powerpc* targets (is done even on those and fails
because of missing altivec.h etc.), PCH is broken on powerpc*-*-* since the
new builtin generator has been introduced.
The generator contains or emits comments like:
  /*  Cannot mark this as a GC root because only pointer types can
 be marked as GTY((user)) and be GC roots.  All trees in here are
 kept alive by other globals, so not a big deal.  Alternatively,
 we could change the enum fields to ints and cast them in and out
 to avoid requiring a GTY((user)) designation, but that seems
 unnecessarily gross.  */
Having the fntypes stored in other GC roots can work fine for GC,
ggc_collect will then always mark them and so they won't disappear from
the tables, but it definitely doesn't work for PCH, which when the
arrays with fntype members aren't GTY marked means on PCH write we create
copies of those FUNCTION_TYPEs and store in *.gch that the GC roots should
be updated, but don't store that rs6000_builtin_info[?].fntype etc. should
be updated.  When PCH is read again, the blob is read at some other
address,
GC roots are updated, rs6000_builtin_info[?].fntype contains garbage
pointers (GC freed pointers with random data, or random unrelated types or
other trees).
The following patch fixes that.  It stops any user markings because that
is totally unnecessary, just skips fields we don't need to mark and adds
GTY(()) to the 2 array variables.  We can get rid of all those global
vars for the fn types, they can be now automatic vars.
With the patch we get
  {
_instance_info[0].fntype,
1 * (RS6000_INST_MAX),
sizeof (rs6000_instance_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
  },
  {
_builtin_info[0].fntype,
1 * (RS6000_BIF_MAX),
sizeof (rs6000_builtin_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
  },
as the new roots which is exactly what we want and significantly more
compact than countless
  {
_ftype_pudi_usi,
1,
sizeof (uv2di_ftype_pudi_usi),
_ggc_mx_tree_node,
_pch_nx_tree_node
  },
  {
_ftype_lg_puv2di,
1,
sizeof (uv2di_ftype_lg_puv2di),
_ggc_mx_tree_node,
_pch_nx_tree_node
  },
  {
_ftype_lg_pudi,
1,
sizeof (uv2di_ftype_lg_pudi),
_ggc_mx_tree_node,
_pch_nx_tree_node
  },
  {
_ftype_di_puv2di,
1,
sizeof (uv2di_ftype_di_puv2di),
_ggc_mx_tree_node,
_pch_nx_tree_node
  },
cases (822 of these instead of just those 4 shown).

2022-02-01  Jakub Jelinek  

PR target/104323
* config/rs6000/t-rs6000 (EXTRA_GTYPE_DEPS): Append
rs6000-builtins.h
rather than $(srcdir)/config/rs6000/rs6000-builtins.def.
* config/rs6000/rs6000-gen-builtins.cc (write_decls): Don't use
GTY((user)) for struct bifdata and struct ovlddata.  Instead add
GTY((skip(""))) to members with pointer and enum types that don't
need
to be tracked.  Add GTY(()) to rs6000_builtin_info and
rs6000_instance_info
declarations.  Don't emit gt_ggc_mx and gt_pch_nx declarations.
(write_extern_fntype, write_fntype): Remove.
(write_fntype_init): Emit the fntype vars as automatic vars instead
of file scope ones.
(write_header_file): Don't 

Re: [PATCH] libcpp: Avoid PREV_WHITE and other random content on CPP_PADDING tokens

[Jason Merrill via Gcc-patches]

On 2/1/22 10:31, Jakub Jelinek wrote:

On Tue, Feb 01, 2022 at 10:03:57AM +0100, Jakub Jelinek via Gcc-patches wrote:

I wonder if we shouldn't replace that
   toks[0] = pfile->directive_result;
line with
   toks[0] = pfile->avoid_paste;
or even replace those
   toks = XNEW (cpp_token);
   toks[0] = pfile->directive_result;
lines with
   toks = >avoid_paste;


Here is a patch that does that, bootstrapped/regtested on powerpc64le-linux,
ok for trunk?


OK along with the previous patch and the (checking) assert in 
funlike_invocation_p.



2022-02-01  Jakub Jelinek  

* directives.cc (destringize_and_run): Push >avoid_paste
instead of a copy of pfile->directive_result for the CPP_PADDING
case.

--- libcpp/directives.cc.jj 2022-01-18 11:59:00.257972414 +0100
+++ libcpp/directives.cc2022-02-01 13:39:27.240114485 +0100
@@ -1954,8 +1954,7 @@ destringize_and_run (cpp_reader *pfile,
else
  {
count = 1;
-  toks = XNEW (cpp_token);
-  toks[0] = pfile->directive_result;
+  toks = >avoid_paste;
  
/* If we handled the entire pragma internally, make sure we get the

 line number correct for the next token.  */


Jakub

[Bug target/104324] v850-elf-as regression: displacement is too large

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #2 from Andrew Pinski  ---
This is not a GCC bug, this is a binutils bug (if at all) as the code you wrote
is pure assembler and binutils is where the assembler comes from , please
report it to binutils project: https://sourceware.org/bugzilla/ .

[Bug c++/103186] [11 Regression] ICE with lambda as default argument in template

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

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||12.0
Summary|[11/12 Regression] ICE with |[11 Regression] ICE with
   |lambda as default argument  |lambda as default argument
   |in template |in template

--- Comment #14 from Jason Merrill  ---
Fixed for 12 so far.

[Bug c++/103186] [11/12 Regression] ICE with lambda as default argument in template

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

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r12-6973-g8a3789786205376e3ba19fdefadd8937e8ac534e
Author: Jason Merrill 
Date:   Wed Jan 26 16:42:57 2022 -0500

c++: lambda in template default argument [PR103186]

The problem with this testcase was that since my patch for PR97900 we
weren't preserving DECL_UID identity for parameters of instantiations of
templated functions, so using those parameters as the keys for the
defarg_inst map broke.  I think this was always fragile given the
possibility of redeclarations, so instead of reverting that change let's
switch to keying off the function.

Memory use compiling stdc++.h is not noticeably different.

PR c++/103186

gcc/cp/ChangeLog:

* pt.cc (defarg_inst): Use tree_vec_map_cache_hasher.
(defarg_insts_for): New.
(tsubst_default_argument): Adjust.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-defarg10.C: New test.

[Bug fortran/104332] [9/10/11/12 Regression] ICE in resolve_symbol, at fortran/resolve.cc:15815

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #1)
> Note that this addition gives an ICE down to at least r5 for some reasons :
> 
> $ cat z3.f90
> block data
>real, bind(c) :: a
> end block data

This is fixed by

diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 7a80dfd063b..8f9a2bb4d95 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -481,6 +481,9 @@ gfc_check_conflict (symbol_attribute *attr, const char
*name, locus *where)
a1 = publik;
   if (attr->intent != INTENT_UNKNOWN)
a1 = intent;
+  /* F2018:C1416. */
+  if (attr->is_bind_c != INTENT_UNKNOWN)
+   a1 = is_bind_c;

   if (a1 != NULL)
{

But, I think that there are conflicts in the Fortran standard.
Are these code snippets equivalent?

BLOCK DATA
   BIND(C) :: A
END BLOCK DATA

BLOCK DATA
   REAL :: A
   BIND(C) :: A
END BLOCK DATA

BLOCK DATA
   REAL, BIND(C) :: A
END BLOCK DATA

If yes, do C1415 and C1416 conflict?

C1415 (R1420) A block-data specification-part shall contain
  only derived-type definitions and ..., BIND, ..., and
  type declaration statements.

C1416 (R1420) A type declaration statement in a block-data
  specification-part shall not contain ALLOCATABLE, EXTERNAL,
  or BIND attribute specifiers.

In fact, does C1415 conflict with C819?

C819 A variable with the BIND attribute shall be declared in
 the specification part of a module.

[Bug c++/86430] ambiguous overload?

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Alias||CWG2235
 Resolution|--- |FIXED
   Target Milestone|--- |11.0

--- Comment #4 from Andrew Pinski  ---
Closing as g++.dg/template/partial-order2.C is similar testcase to the original
one here.

Re: [PATCH] rs6000: Fix up PCH on powerpc* [PR104323]

[Bill Schmidt via Gcc-patches]

Hi!

Jakub, thanks for fixing this.  I didn't realize the PCH implications here, 
clearly...

On 2/1/22 12:33 PM, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Feb 01, 2022 at 04:27:40PM +0100, Jakub Jelinek wrote:
>> +/* PR target/104323 */
>> +/* { dg-require-effective-target powerpc_altivec_ok } */
>> +/* { dg-options "-maltivec" } */
>> +
>> +#include 
>> testcase which I'm not including into testsuite because for some reason
>> the test fails on non-powerpc* targets (is done even on those and fails
>> because of missing altivec.h etc.),
> powerpc_altivec_ok returns false if the target isn't Power, you can use
> this in the testsuite fine?  Why does it still fail on other targets,
> the test should be SKIPPED there?
>
> Or wait, proc check_effective_target_powerpc_altivec_ok is broken, and
> does not implement its intention or documentation.  Will fix.
>
>> PCH is broken on powerpc*-*-* since the
>> new builtin generator has been introduced.
>> The generator contains or emits comments like:
>>   /*  Cannot mark this as a GC root because only pointer types can
>>  be marked as GTY((user)) and be GC roots.  All trees in here are
>>  kept alive by other globals, so not a big deal.  Alternatively,
>>  we could change the enum fields to ints and cast them in and out
>>  to avoid requiring a GTY((user)) designation, but that seems
>>  unnecessarily gross.  */
>> Having the fntypes stored in other GC roots can work fine for GC,
>> ggc_collect will then always mark them and so they won't disappear from
>> the tables, but it definitely doesn't work for PCH, which when the
>> arrays with fntype members aren't GTY marked means on PCH write we create
>> copies of those FUNCTION_TYPEs and store in *.gch that the GC roots should
>> be updated, but don't store that rs6000_builtin_info[?].fntype etc. should
>> be updated.  When PCH is read again, the blob is read at some other address,
>> GC roots are updated, rs6000_builtin_info[?].fntype contains garbage
>> pointers (GC freed pointers with random data, or random unrelated types or
>> other trees).
>> The following patch fixes that.  It stops any user markings because that
>> is totally unnecessary, just skips fields we don't need to mark and adds
>> GTY(()) to the 2 array variables.  We can get rid of all those global
>> vars for the fn types, they can be now automatic vars.
>> With the patch we get
>>   {
>> _instance_info[0].fntype,
>> 1 * (RS6000_INST_MAX),
>> sizeof (rs6000_instance_info[0]),
>> _ggc_mx_tree_node,
>> _pch_nx_tree_node
>>   },
>>   {
>> _builtin_info[0].fntype,
>> 1 * (RS6000_BIF_MAX),
>> sizeof (rs6000_builtin_info[0]),
>> _ggc_mx_tree_node,
>> _pch_nx_tree_node
>>   },
>> as the new roots which is exactly what we want and significantly more
>> compact than countless
>>   {
>> _ftype_pudi_usi,
>> 1,
>> sizeof (uv2di_ftype_pudi_usi),
>> _ggc_mx_tree_node,
>> _pch_nx_tree_node
>>   },
>>   {
>> _ftype_lg_puv2di,
>> 1,
>> sizeof (uv2di_ftype_lg_puv2di),
>> _ggc_mx_tree_node,
>> _pch_nx_tree_node
>>   },
>>   {
>> _ftype_lg_pudi,
>> 1,
>> sizeof (uv2di_ftype_lg_pudi),
>> _ggc_mx_tree_node,
>> _pch_nx_tree_node
>>   },
>>   {
>> _ftype_di_puv2di,
>> 1,
>> sizeof (uv2di_ftype_di_puv2di),
>> _ggc_mx_tree_node,
>> _pch_nx_tree_node
>>   },
>> cases (822 of these instead of just those 4 shown).
> Bill, can you review the builtin side of this?

Yes, I've just read through it and it looks just fine to me.
It's a big improvement over what I had there, even ignoring
the PCH issues.

Thanks again, Jakub!

Bill

>
>>  PR target/104323
>>  * config/rs6000/t-rs6000 (EXTRA_GTYPE_DEPS): Append rs6000-builtins.h
>>  rather than $(srcdir)/config/rs6000/rs6000-builtins.def.
>>  * config/rs6000/rs6000-gen-builtins.cc (write_decls): Don't use
>>  GTY((user)) for struct bifdata and struct ovlddata.  Instead add
>>  GTY((skip(""))) to members with pointer and enum types that don't need
>>  to be tracked.  Add GTY(()) to rs6000_builtin_info and 
>> rs6000_instance_info
>>  declarations.  Don't emit gt_ggc_mx and gt_pch_nx declarations.
> Nice :-)
>
>>  (write_extern_fntype, write_fntype): Remove.
>>  (write_fntype_init): Emit the fntype vars as automatic vars instead
>>  of file scope ones.
>>  (write_header_file): Don't iterate with write_extern_fntype.
>>  (write_init_file): Don't iterate with write_fntype.  Don't emit
>>  gt_ggc_mx and gt_pch_nx definitions.
>>if (tf_found)
>> -fprintf (init_file, "  if (float128_type_node)\n  ");
>> +fprintf (init_file,
>> + "  tree %s = NULL_TREE;\n  if (float128_type_node)\n",
>> + buf);
>>else if (dfp_found)
>> -fprintf (init_file, "  if (dfloat64_type_node)\n  ");
>> +fprintf (init_file,
>> + "  tree %s = NULL_TREE;\n  if (dfloat64_type_node)\n",
>> + buf);
> Things are 

[Bug tree-optimization/101831] [11/12 Regression] Spurious maybe-uninitialized warning on std::array::size

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Sebor  ---
libstdc++ patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589612.html

[PATCH] declare std::array members attribute const [PR101831]

[Martin Sebor via Gcc-patches]

Passing an uninitialized object to a function that takes its argument
by const reference is diagnosed by -Wmaybe-uninitialized because most
such functions read the argument.  The exceptions are functions that
don't access the object but instead use its address to compute
a result.  This includes a number of std::array member functions such
as std::array::size() which returns the template argument N.  Such
functions may be candidates for attribute const which also avoids
the warning.  The attribute typically only benefits extern functions
that IPA cannot infer the property from, but in this case it helps
avoid the warning which runs very early on, even without optimization
or inlining.  The attached patch adds the attribute to a subset of
those member functions of std::array.  (It doesn't add it to const
member functions like cbegin() or front() that return a const_iterator
or const reference to the internal data.)

It might be possible to infer this property from inline functions
earlier on than during IPA and avoid having to annotate them explicitly.
That seems like an enhancement worth considering in the future.

Tested on x86_64-linux.

MartinDeclare std::array members with attribute const [PR101831].

Resolves:
PR libstdc++/101831 - Spurious maybe-uninitialized warning on std::array::size

libstdc++-v3/ChangeLog:

	* include/std/array (begin): Declare const member function attribute
	const.
	(end, rbegin, rend, size, max_size, empty, data): Same.
	* testsuite/23_containers/array/capacity/empty.cc: Add test cases.
	* testsuite/23_containers/array/capacity/max_size.cc: Same.
	* testsuite/23_containers/array/capacity/size.cc: Same.
	* testsuite/23_containers/array/iterators/begin_end.cc: New test.

diff --git a/libstdc++-v3/include/std/array b/libstdc++-v3/include/std/array
index b4d8fc81a52..e45143fb329 100644
--- a/libstdc++-v3/include/std/array
+++ b/libstdc++-v3/include/std/array
@@ -127,7 +127,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { std::swap_ranges(begin(), end(), __other.begin()); }
 
   // Iterators.
-  [[__nodiscard__]]
+  [[__gnu__::__const__, __nodiscard__]]
   _GLIBCXX17_CONSTEXPR iterator
   begin() noexcept
   { return iterator(data()); }
@@ -137,7 +137,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   begin() const noexcept
   { return const_iterator(data()); }
 
-  [[__nodiscard__]]
+  [[__gnu__::__const__, __nodiscard__]]
   _GLIBCXX17_CONSTEXPR iterator
   end() noexcept
   { return iterator(data() + _Nm); }
@@ -147,7 +147,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   end() const noexcept
   { return const_iterator(data() + _Nm); }
 
-  [[__nodiscard__]]
+  [[__gnu__::__const__, __nodiscard__]]
   _GLIBCXX17_CONSTEXPR reverse_iterator
   rbegin() noexcept
   { return reverse_iterator(end()); }
@@ -157,7 +157,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   rbegin() const noexcept
   { return const_reverse_iterator(end()); }
 
-  [[__nodiscard__]]
+  [[__gnu__::__const__, __nodiscard__]]
   _GLIBCXX17_CONSTEXPR reverse_iterator
   rend() noexcept
   { return reverse_iterator(begin()); }
@@ -188,15 +188,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { return const_reverse_iterator(begin()); }
 
   // Capacity.
-  [[__nodiscard__]]
+  [[__gnu__::__const__, __nodiscard__]]
   constexpr size_type
   size() const noexcept { return _Nm; }
 
-  [[__nodiscard__]]
+  [[__gnu__::__const__, __nodiscard__]]
   constexpr size_type
   max_size() const noexcept { return _Nm; }
 
-  [[__nodiscard__]]
+  [[__gnu__::__const__, __nodiscard__]]
   constexpr bool
   empty() const noexcept { return size() == 0; }
 
@@ -278,7 +278,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  	   : _AT_Type::_S_ref(_M_elems, 0);
   }
 
-  [[__nodiscard__]]
+  [[__gnu__::__const__, __nodiscard__]]
   _GLIBCXX17_CONSTEXPR pointer
   data() noexcept
   { return _AT_Type::_S_ptr(_M_elems); }
diff --git a/libstdc++-v3/testsuite/23_containers/array/capacity/empty.cc b/libstdc++-v3/testsuite/23_containers/array/capacity/empty.cc
index 3f3f282ad9d..cecbae39e45 100644
--- a/libstdc++-v3/testsuite/23_containers/array/capacity/empty.cc
+++ b/libstdc++-v3/testsuite/23_containers/array/capacity/empty.cc
@@ -40,8 +40,26 @@ test01()
   }
 }
 
+#pragma GCC push_options
+#pragma GCC optimize "0"
+
+void
+test02()
+{
+  {
+const size_t len = 3;
+typedef std::array array_type;
+array_type a;
+
+VERIFY( a.empty() == false );// { dg-bogus "-Wmaybe-uninitialized"
+  }
+}
+
+#pragma GCC pop_options
+
 int main()
 {
   test01();
+  test02();
   return 0;
 }
diff --git a/libstdc++-v3/testsuite/23_containers/array/capacity/max_size.cc b/libstdc++-v3/testsuite/23_containers/array/capacity/max_size.cc
index 0e000258530..4629316161d 100644
--- a/libstdc++-v3/testsuite/23_containers/array/capacity/max_size.cc
+++ 

Re: [PATCH] Reset relations when crossing backedges.

[Aldy Hernandez via Gcc-patches]

Ping

On Mon, Jan 24, 2022, 20:20 Aldy Hernandez  wrote:

> On Mon, Jan 24, 2022 at 9:51 AM Richard Biener
>  wrote:
> >
> > On Fri, Jan 21, 2022 at 1:12 PM Aldy Hernandez  wrote:
> > >
> > > On Fri, Jan 21, 2022 at 11:56 AM Richard Biener
> > >  wrote:
> > > >
> > > > On Fri, Jan 21, 2022 at 11:30 AM Aldy Hernandez 
> wrote:
> > > > >
> > > > > On Fri, Jan 21, 2022 at 10:43 AM Richard Biener
> > > > >  wrote:
> > > > > >
> > > > > > On Fri, Jan 21, 2022 at 9:30 AM Aldy Hernandez via Gcc-patches
> > > > > >  wrote:
> > > > > > >
> > > > > > > As discussed in PR103721, the problem here is that we are
> crossing a
> > > > > > > backedge and causing us to use relations from a previous
> iteration of a
> > > > > > > loop.
> > > > > > >
> > > > > > > This handles the testcases in both PR103721 and PR104067 which
> are variants
> > > > > > > of the same thing.
> > > > > > >
> > > > > > > Tested on x86-64 Linux with the usual regstrap as well as
> verifying the
> > > > > > > thread count before and after the patch.  The number of
> threads is
> > > > > > > reduced by a miniscule amount.
> > > > > > >
> > > > > > > I assume we need release manager approval at this point?  OK
> for trunk?
> > > > > >
> > > > > > Not for regression fixes.
> > > > >
> > > > > OK, I've pushed it to fix the P1s.  We can continue refining the
> > > > > solution in a follow-up patch.
> > > > >
> > > > > >
> > > > > > Btw, I wonder whether you have to treat irreducible regions in
> the same
> > > > > > way more generally - which edges are marked as backedge there
> depends
> > > > > > on which edge into the region was visited first.  I also wonder
> how we
> > > > >
> > > > > Jeff, Andrew??
> > > > >
> > > > > > I also wonder how we guarantee that all users of the resolve
> mode have backedges marked
> > > > > > properly?  Also note that CFG manipulation routines in general
> do not
> > > > > > keep backedge markings up-to-date so incremental modification and
> > > > > > resolving queries might not mix.
> > > > > >
> > > > > > It's a bit unfortunate that we can't query the CFG on whether
> backedges
> > > > > > are marked.
> > > > >
> > > > > Ughh.  The call to mark_dfs_back_edges is currently in the backward
> > > > > threader.  Perhaps we could put it in the path_range_query
> > > > > constructor?  That way other users of path_range_query can benefit
> > > > > (loop_ch for instance, though it doesn't use it in a way that
> crosses
> > > > > backedges so perhaps it's unaffected).  Does that sound reasonable?
> > > >
> > > > Hmm, I'd rather keep the burden on the callers because many already
> > > > should have backedges marked.  What you could instead do is
> > > > add sth like
> > > >
> > > >   if (flag_checking)
> > > > {
> > > >auto_edge_flag saved_dfs_back;
> > > >for-each-edge-in-cfg () set saved_dfs_back flag if dfs_back is
> > > > set, clear dfs_back
> > > >mark_dfs_back_edges ();
> > > >for-each-edge-in-cfg () verify the flags are set on the same
> > > > edges and clear saved_dfs_back
> > > > }
> > > >
> > > > to the path_range_query constructor.  That way we at least notice
> when passes
> > > > do _not_ have the backedges marked properly.
> > >
> > > Sounds good.  Thanks.
> > >
> > > I've put the verifier by mark_dfs_back_edges(), since it really has
> > > nothing to do with the path solver.  Perhaps it's useful for someone
> > > else.
> > >
> > > The patch triggered with the loop-ch use, so I've added a
> > > corresponding mark_dfs_back_edges there.
> > >
> > > OK pending tests?
> >
> > Please rename dfs_back_edges_available_p to sth not suggesting
> > it's a simple predicate check, like maybe verify_marked_backedges.
> >
> > +
> > +  gcc_checking_assert (!m_resolve || dfs_back_edges_available_p ());
> >
> > I'd prefer the following which allows even release checking builds
> > to verify this with -fchecking.
> >
> >   if (!m_resolve)
> > if (flag_checking)
> >   verify_marked_backedges ();
> >
> > and then ideally verify_marked_backedges () should raise an
> > internal_error () for the edge not marked properly, best by
> > also specifying it.  Just like other CFG verifiers do.
> >
> > The loop ch and backwards threader changes are OK.  You
> > can post the verification independently again.
>
> How about this?
>
> Tested on x86-64 Linux.
>

[Bug c++/104325] [9/10/11/12 Regression] undefined reference to `virtual thunk to ...' since r9-4254-g12485662c00914ed

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||link-failure
   Target Milestone|--- |9.5