Re: [PATCH] Introduce -nolibstdc++ option

[Alexandre Oliva via Gcc-patches]

On Jun 23, 2022, Alexandre Oliva  wrote:

> Here's the patch.  Regstrapped on x86_64-linux-gnu, also tested with a
> cross to aarch64-rtems6.  Ok to install?

> Introduce -nostdlib++ option

Uhh, I went ahead and installed this.  The earlier patch was approved if
nobody objected, and so, having overcome the objection to the option
spelling, it ended up in my "approved" patchset.

In case there are objections to it, please let me know, and I'll revert
it promptly, but I guess it makes little sense to revert it on the odd
change that someone does.  Thanks for your understanding.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[Bug tree-optimization/106070] Wrong code with -O1

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-06-24
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||needs-bisection

--- Comment #2 from Andrew Pinski  ---
Reduced testcase:
#include 
unsigned int var_2 = 1;
int var_4 = -1;
int var_10 = 4;
unsigned long arr_252;
[[gnu::noipa]]
void test() {
  for (int a = 0; a < var_10; a += 2)
arr_252 = var_2 != (int)var_4 ? (unsigned long)var_4 : (unsigned
long)var_2;
}

void test();

int main() {
test();
fprintf(stderr, "%lx\n", arr_252);
if (arr_252 != 0x)
__builtin_abort();
}

 CUT ---
There is a missing sign extend from 32bit to 64bit.

Confirmed.

[Bug tree-optimization/106070] Wrong code with -O1

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

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

--- Comment #1 from Andrew Pinski  ---
Single file testcase:
#include 
unsigned int var_2 = 1;
int var_4 = -1;
signed char var_10 = (signed char)(-127 - 1);
unsigned long long int arr_252;
[[gnu::noipa]]
void test() {
  for (unsigned a = 0; a < (unsigned char)var_10; a += 2)
arr_252 = var_2 != var_4 ? var_4 : (long)var_2;
}

void test();

int main() {
test();
printf("%llx\n", arr_252);
if (arr_252 != 0x)
__builtin_abort();
}

(The [[gnu::noipa]] makes things easier for single file testcases so no
inlining or other IPA passes on the function).

[Bug tree-optimization/106070] New: Wrong code with -O1

[vsevolod.livinskiy at gmail dot com via Gcc-bugs]

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

Bug ID: 106070
   Summary: Wrong code with -O1
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskiy at gmail dot com
  Target Milestone: ---

GCC produces incorrect code with -O1.
I was not able to merge the test into a single file.

Reproducer:
// func.cpp
extern unsigned var_2;
extern int var_4;
extern signed char var_10;
extern unsigned long long arr_252;
void test() {
  for (unsigned a = 0; a < (unsigned char)var_10; a += 2)
arr_252 = var_2 != var_4 ? var_4 : (long)var_2;
}

//driver.cpp
#include 

unsigned int var_2 = 1;
int var_4 = -1;
signed char var_10 = (signed char)(-127 - 1);
unsigned long long int arr_252;

void test();

int main() {
test();
printf("%llx\n", arr_252);
if (arr_252 != 0x)
__builtin_abort();
}

Error:
>$ g++ -O0 func.cpp driver.cpp && ./a.out 

>$  g++ -O1 func.cpp driver.cpp && ./a.out 

Aborted (core dumped)

gcc version 13.0.0 20220623 (31ce821a790caec8a2849dd67a9847e78a33d14c)

[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

--- Comment #2 from luoxhu at gcc dot gnu.org ---
Could you also paste the ASM difference please? (I don't have environment at
handle so far..)

Re: [PATCH] libstdc++-v3: check for openat

[Alexandre Oliva via Gcc-patches]

On Jun 23, 2022, Alexandre Oliva  wrote:

>   * aclocal.m4, configure, config.h.in: Rebuilt.

Dropped aclocal.m4 for the checkin, thanks to the ChangeLog checker.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] aarch64: testsuite: symbol-range compile only

[Alexandre Oliva via Gcc-patches]

On Jun 23, 2022, Alexandre Oliva  wrote:

> for  gcc/testsuite/ChangeLog

>   * doc/sourcebuild.exp (Environment attributes): Document it.

Fixed two problems in the above, thanks for the ChangeLog checker.  It's
.texi, and it belongs in gcc/ChangeLog.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] libstdc++: testsuite: test symlnks ifdef _GLIBCXX_HAVE_SYMLINK

[Alexandre Oliva via Gcc-patches]

On Jun 23, 2022, Alexandre Oliva  wrote:

>   * 
> testsuite/experimental/filesystem/iterators/recursive_directory_itreator.cc

s/itreator/iterator/ for the checkin, thanks to the ChangeLog checker :-)

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[Bug c++/106024] [11/12/13 Regression] ICE on missing template keyword in template method call in pack expansion

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Testcase with only one lambda:

template  void sink(Ts &&...);
template  void f()
{
  sink ([]  (auto...) { return 1; }
.operator()(args...)...);
}

int main()
{
  f<1,2,3>();
}

[Bug fortran/106065] Crash when reading extended derived type array in namelist

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

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #1 from Jerry DeLisle  ---
Well, its not really a 'crash', but certainly not correct.

Comment out the READ statements and look at the result:

$ ./a.out 
_BAL_NE
 DATE_TIME_NE(1)%NYEAR=0  ,
 DATE_TIME_NE(1)%NMONTH=0  ,
 DATE_TIME_NE(1)%NDAY=0  ,
 DATE_TIME_NE(1)%XTIME=  0.,
 DATE_TIME_NE(2)%NYEAR=0  ,
 DATE_TIME_NE(2)%NMONTH=0  ,
 DATE_TIME_NE(2)%NDAY=0  ,
 DATE_TIME_NE(2)%XTIME=  0.,
 /
_BAL_E
 DATE_TIME_E%TDATE%NYEAR=0  ,
 DATE_TIME_E%TDATE%NMONTH=0  ,
 DATE_TIME_E%TDATE%NDAY=0  ,
 DATE_TIME_E%YTIME=  0.,
 /

The extended type is not even being seen as an array

[PATCH v6, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

[HAO CHEN GUI via Gcc-patches]

Hi,
  This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
Tests show that outputs of xs[min/max]dp are consistent with the standard
of C99 fmin/max.

  This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
of smin/max. So the builtins always generate xs[min/max]dp on all
platforms.

  Bootstrapped and tested on ppc64 Linux BE and LE with no regressions.
Is this okay for trunk? Any recommendations? Thanks a lot.

ChangeLog
2022-06-24 Haochen Gui 

gcc/
PR target/103605
* config/rs6000/rs6000.md (FMINMAX): New.
(minmax_op): New.
(f3): New pattern by UNSPEC_FMAX and UNSPEC_FMIN.
* config/rs6000/rs6000-builtins.def (__builtin_vsx_xsmaxdp): Set
pattern to fmaxdf3.
(__builtin_vsx_xsmindp): Set pattern to fmindf3.

gcc/testsuite/
PR target/103605
* gcc.dg/powerpc/pr103605.c: New.


patch.diff
diff --git a/gcc/config/rs6000/rs6000-builtins.def 
b/gcc/config/rs6000/rs6000-builtins.def
index f4a9f24bcc5..8b735493b40 100644
--- a/gcc/config/rs6000/rs6000-builtins.def
+++ b/gcc/config/rs6000/rs6000-builtins.def
@@ -1613,10 +1613,10 @@
 XSCVSPDP vsx_xscvspdp {}

   const double __builtin_vsx_xsmaxdp (double, double);
-XSMAXDP smaxdf3 {}
+XSMAXDP fmaxdf3 {}

   const double __builtin_vsx_xsmindp (double, double);
-XSMINDP smindf3 {}
+XSMINDP fmindf3 {}

   const double __builtin_vsx_xsrdpi (double);
 XSRDPI vsx_xsrdpi {}
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index bf85baa5370..ae0dd98f0f9 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -158,6 +158,8 @@ (define_c_enum "unspec"
UNSPEC_HASHCHK
UNSPEC_XXSPLTIDP_CONST
UNSPEC_XXSPLTIW_CONST
+   UNSPEC_FMAX
+   UNSPEC_FMIN
   ])

 ;;
@@ -5341,6 +5343,22 @@ (define_insn_and_split "*s3_fpr"
   DONE;
 })

+
+(define_int_iterator FMINMAX [UNSPEC_FMAX UNSPEC_FMIN])
+
+(define_int_attr  minmax_op [(UNSPEC_FMAX "max")
+(UNSPEC_FMIN "min")])
+
+(define_insn "f3"
+  [(set (match_operand:SFDF 0 "vsx_register_operand" "=wa")
+   (unspec:SFDF [(match_operand:SFDF 1 "vsx_register_operand" "wa")
+ (match_operand:SFDF 2 "vsx_register_operand" "wa")]
+FMINMAX))]
+  "TARGET_VSX && !flag_finite_math_only"
+  "xsdp %x0,%x1,%x2"
+  [(set_attr "type" "fp")]
+)
+
 (define_expand "movcc"
[(set (match_operand:GPR 0 "gpc_reg_operand")
 (if_then_else:GPR (match_operand 1 "comparison_operator")
diff --git a/gcc/testsuite/gcc.target/powerpc/pr103605.c 
b/gcc/testsuite/gcc.target/powerpc/pr103605.c
new file mode 100644
index 000..1c938d40e61
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr103605.c
@@ -0,0 +1,37 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-options "-O2 -mvsx" } */
+/* { dg-final { scan-assembler-times {\mxsmaxdp\M} 3 } } */
+/* { dg-final { scan-assembler-times {\mxsmindp\M} 3 } } */
+
+#include 
+
+double test1 (double d0, double d1)
+{
+  return fmin (d0, d1);
+}
+
+float test2 (float d0, float d1)
+{
+  return fmin (d0, d1);
+}
+
+double test3 (double d0, double d1)
+{
+  return fmax (d0, d1);
+}
+
+float test4 (float d0, float d1)
+{
+  return fmax (d0, d1);
+}
+
+double test5 (double d0, double d1)
+{
+  return __builtin_vsx_xsmindp (d0, d1);
+}
+
+double test6 (double d0, double d1)
+{
+  return __builtin_vsx_xsmaxdp (d0, d1);
+}

Re: [PATCH v3] rs6000: Adjust mov optabs for opaque modes [PR103353]

[Kewen.Lin via Gcc-patches]

Hi Segher,

Thanks for the comments.

on 2022/6/24 03:06, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, May 18, 2022 at 10:07:48PM +0800, Kewen.Lin wrote:
>> As PR103353 shows, we may want to continue to expand a MMA built-in
>> function like a normal function, even if we have already emitted
>> error messages about some missing required conditions.  As shown in
>> that PR, without one explicit mov optab on OOmode provided, it would
>> call emit_move_insn recursively.
> 
> First off: lxvp is a VSX insn, not an MMA insn.  So please don't call it
> that -- this confusion is what presumably caused the problem here, so it
> would be good to root it out :-)
> 

I guess the "it" in "don't call it call" is for "MMA built-in function"?
It comes from the current code:

;   mma  Needs special handling for MMA
;   quad MMA instruction using a register quad as an input operand
;   pair MMA instruction using a register pair as an input operand

  v256 __builtin_vsx_lxvp (unsigned long, const v256 *);
LXVP nothing {mma}

  void __builtin_vsx_stxvp (v256, unsigned long, const v256 *);
STXVP nothing {mma,pair}

...

>> +  /* Opaque modes are only expected to be available when MMA is supported,
> 
> Why do people expect that?  It is completely wrong.  The name "opaque"
> itself already says this is not just for MMA, but perhaps more
> importantly, it is a basic VSX insn, doesn't touch any MMA resources,
> and is useful in other contexts as well.
> 

... The above statements are also based on current code, for now, the
related things like built-in functions, mov optab, hard_regno_ok etc.
for these two modes are guarded by TARGET_MMA.

I think I get your points here, you want to separate these opaque
modes from MMA since the underlying lxvp/stxvp are not MMA specific,
so those related things (bifs, mov optabs etc.) are not necessarily
guarded under MMA.

> So this needs some bigger surgery.

Yes, Peter may have more comments on this.

BR,
Kewen

[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X' since r12-954-g84fd1b5dff70cd74

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to work||11.3.1, 12.1.1, 13.0

--- Comment #8 from Jason Merrill  ---
Fixed for 11.4/12.2/13.

[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X' since r12-954-g84fd1b5dff70cd74

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

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

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

https://gcc.gnu.org/g:553aecc570ce4ef5c751dc39b83bfbde6380f953

commit r11-10091-g553aecc570ce4ef5c751dc39b83bfbde6380f953
Author: Jason Merrill 
Date:   Thu Jun 23 16:04:02 2022 -0400

c++: anon union designated init [PR105925]

This testcase was failing because CONSTRUCTOR_IS_DESIGNATED_INIT wasn't
getting set on the introduced CONSTRUCTOR for the anonymous union, and
build_aggr_conv uses that flag to decide whether to pay attention to the
indexes of the CONSTRUCTOR.  So set the flag when we see a designator
rather
than relying on copying it from another CONSTRUCTOR.

PR c++/105925

gcc/cp/ChangeLog:

* decl.c (reshape_init_array_1): Set
CONSTRUCTOR_IS_DESIGNATED_INIT here.
(reshape_init_class): And here.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/desig26.C: New test.

Re: [PATCH] testsuite: Add new target check for no_alignment_constraints

[Andrew Pinski via Gcc-patches]

On Thu, Jun 23, 2022 at 2:24 PM Dimitar Dimitrov  wrote:
>
> A few testcases were marked for avr target, which has no alignment
> requirements.  But those tests in fact should filter for any
> target having __BIGGEST_ALIGNMENT__=1.
>
> A new effective target check is introduced: no_alignment_constraints.
> It checks whether __BIGGEST_ALIGNMENT__ is declared as 1.
>
> Alternative names I considered for the new macro are:
>   - !natural_alignment_16
>   - biggest_alignment_1
>
> This change fixes the testsuite cases for PRU target.  I don't have
> environment to test mm32c and cris targets, which also declare
> __BIGGEST_ALIGNMENT__=1.
>
> It was regression-tested on x86_64-pc-linux-gnu.
>
> The following two existing macros were considered, but they check for
> subtly different target behaviour:
>  1. non_strict_align
> If true, non-aligned access is permitted. But it also allows
> variables to be naturally aligned, which is not true for
> no_alignment_constraints.
>
>  2. default_packed
> Whether structures are packed by default is not necessarily
> the same as lacking constraints for any variable alignment.
> For example, BIGGEST_FIELD_ALIGNMENT or ADJUST_FIELD_ALIGN
> could be defined for a target.
>
> Ok for trunk?

How is no_alignment_constraints different from default_packed? I
suspect they have the same effect really.

Thanks,
Andrew

>
> Signed-off-by: Dimitar Dimitrov 
> ---
>  gcc/testsuite/c-c++-common/Wcast-align.c |  4 ++--
>  gcc/testsuite/gcc.dg/c11-align-4.c   |  2 +-
>  gcc/testsuite/gcc.dg/strlenopt-10.c  |  6 +++---
>  gcc/testsuite/gcc.dg/strlenopt-11.c  | 14 +++---
>  gcc/testsuite/gcc.dg/strlenopt-13.c  | 16 
>  gcc/testsuite/lib/target-supports.exp| 13 +
>  6 files changed, 34 insertions(+), 21 deletions(-)
>
> diff --git a/gcc/testsuite/c-c++-common/Wcast-align.c 
> b/gcc/testsuite/c-c++-common/Wcast-align.c
> index c296c7fd249..1087b10fd99 100644
> --- a/gcc/testsuite/c-c++-common/Wcast-align.c
> +++ b/gcc/testsuite/c-c++-common/Wcast-align.c
> @@ -16,8 +16,8 @@ struct t { double x; } *q;
>  void
>  foo (void)
>  {
> -  y = (c *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of 
> target type" } */
> -  z = (d *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of 
> target type" } */
> +  y = (c *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of 
> target type" "" { target { ! no_alignment_constraints } } } */
> +  z = (d *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of 
> target type" "" { target { ! no_alignment_constraints } } } */
>(long long *) p;  /* { dg-bogus "alignment" } */
>(double *) q; /* { dg-bogus "alignment" } */
>  }
> diff --git a/gcc/testsuite/gcc.dg/c11-align-4.c 
> b/gcc/testsuite/gcc.dg/c11-align-4.c
> index 57f93ff05fc..eb9071b9149 100644
> --- a/gcc/testsuite/gcc.dg/c11-align-4.c
> +++ b/gcc/testsuite/gcc.dg/c11-align-4.c
> @@ -2,7 +2,7 @@
> are at least some alignment constraints).  */
>  /* { dg-do compile } */
>  /* { dg-options "-std=c11 -pedantic-errors" } */
> -/* { dg-skip-if "no alignment constraints" { "avr-*-*" } } */
> +/* { dg-skip-if "no alignment constraints" { no_alignment_constraints } } */
>
>  #include 
>
> diff --git a/gcc/testsuite/gcc.dg/strlenopt-10.c 
> b/gcc/testsuite/gcc.dg/strlenopt-10.c
> index ce959c34a80..6e2c2597b27 100644
> --- a/gcc/testsuite/gcc.dg/strlenopt-10.c
> +++ b/gcc/testsuite/gcc.dg/strlenopt-10.c
> @@ -70,10 +70,10 @@ main ()
>  }
>
>  /* { dg-final { scan-tree-dump-times "strlen \\(" 2 "strlen1" } } */
> -/* avr has BIGGEST_ALIGNMENT 8, allowing fold_builtin_memory_op
> +/* Some targets have BIGGEST_ALIGNMENT 8-bits, allowing 
> fold_builtin_memory_op
> to expand the memcpy call at the end of fn2.  */
> -/* { dg-final { scan-tree-dump-times "memcpy \\(" 8 "strlen1" { target { ! 
> avr-*-* } } } } */
> -/* { dg-final { scan-tree-dump-times "memcpy \\(" 7 "strlen1" { target { 
> avr-*-* } } } } */
> +/* { dg-final { scan-tree-dump-times "memcpy \\(" 8 "strlen1" { target { ! 
> no_alignment_constraints } } } } */
> +/* { dg-final { scan-tree-dump-times "memcpy \\(" 7 "strlen1" { target { 
> no_alignment_constraints} } } } */
>  /* { dg-final { scan-tree-dump-times "strcpy \\(" 0 "strlen1" } } */
>  /* { dg-final { scan-tree-dump-times "strcat \\(" 0 "strlen1" } } */
>  /* { dg-final { scan-tree-dump-times "strchr \\(" 0 "strlen1" } } */
> diff --git a/gcc/testsuite/gcc.dg/strlenopt-11.c 
> b/gcc/testsuite/gcc.dg/strlenopt-11.c
> index abd9faebed6..952de0730f1 100644
> --- a/gcc/testsuite/gcc.dg/strlenopt-11.c
> +++ b/gcc/testsuite/gcc.dg/strlenopt-11.c
> @@ -59,17 +59,17 @@ main ()
>  }
>
>  /* { dg-final { scan-tree-dump-times "strlen \\(" 3 "strlen1" } } */
> -/* avr has BIGGEST_ALIGNMENT 8, allowing fold_builtin_memory_op
> +/* Some targets have BIGGEST_ALIGNMENT 8-bits, allowing 
> fold_builtin_memory_op
> to expand the memcpy call at the end of fn1.  */
> -/* { 

[PATCH] or1k: gcc: Add naked attribute

[jesus via Gcc-patches]

Hello.

I have added support for naked functions on the OpenRISC 1200 target
it practically inhibits the generation of a function epilogue and
prologue and will warn about variables that might use the stack (to
prevent unintended code being generated).

As well added a table for attributes where the attribute can only
be applied functions, like in the other backends.

gcc/ChangeLog:

* config/or1k/or1k.cc (or1k_handle_naked_attribute):
(has_func_attr): Likewise.
(callee_saved_regno_p): Likewise.
(or1k_save_reg): Likewise.
(or1k_restore_reg): Likewise.
(or1k_expand_prologue): Likewise.
(or1k_expand_epilogue): Likewise.
(or1k_frame_pointer_required): Likewise.
(TARGET_ATTRIBUTE_TABLE): Define.

---
 gcc/config/or1k/or1k.cc | 58 ++---
 1 file changed, 55 insertions(+), 3 deletions(-)

diff --git a/gcc/config/or1k/or1k.cc b/gcc/config/or1k/or1k.cc
index da2f59062ba..c41ac5ab099 100644
--- a/gcc/config/or1k/or1k.cc
+++ b/gcc/config/or1k/or1k.cc
@@ -79,6 +79,41 @@ struct GTY(()) machine_function
   rtx_insn *set_mcount_arg_insn;
 };

+static tree
+or1k_handle_naked_attribute(tree *node, tree name ATTRIBUTE_UNUSED,
+tree args ATTRIBUTE_UNUSED,
+int flags ATTRIBUTE_UNUSED, bool *no_add_attrs)
+{
+  gcc_assert(DECL_P(*node));
+
+  if (TREE_CODE(*node) != FUNCTION_DECL)
+  {
+warning(OPT_Wattributes, "%qE attribute only applies to functions",
+name);
+*no_add_attrs = true;
+  }
+  return NULL_TREE;
+}
+
+static const struct attribute_spec or1k_attribute_table[] = {
+  { "naked", 0, 0, true, false, false, false,
+or1k_handle_naked_attribute, NULL },
+
+  /* End element.  */
+  { NULL, 0, 0, false, false, false, false, NULL, NULL }
+};
+
+/* Returns true if the provided function has the specified attribute.  */
+
+static inline bool
+has_func_attr(const_tree decl, const char *func_attr)
+{
+  if (decl == NULL_TREE)
+decl = current_function_decl;
+
+  return lookup_attribute(func_attr, DECL_ATTRIBUTES(decl)) != NULL_TREE;
+}
+
 /* Zero initialization is OK for all current fields.  */

 static struct machine_function *
@@ -103,6 +138,10 @@ or1k_option_override (void)
 static bool
 callee_saved_regno_p (int regno)
 {
+  /* Naked functions do not save anything, so let's say NO! */
+  if (has_func_attr(NULL_TREE, "naked"))
+return false;
+
   /* Check call-saved registers.  */
   if (!call_used_or_fixed_reg_p (regno) && df_regs_ever_live_p (regno))
 return true;
@@ -185,6 +224,9 @@ or1k_compute_frame_layout (void)
 static void
 or1k_save_reg (int regno, HOST_WIDE_INT offset)
 {
+  if (has_func_attr(NULL_TREE, "naked"))
+warning(0, "stack usage on naked function %s", current_function_name());
+
   rtx reg = gen_rtx_REG (Pmode, regno);
   rtx mem = gen_frame_mem (SImode, plus_constant (Pmode, stack_pointer_rtx,
  offset));
@@ -198,6 +240,9 @@ or1k_save_reg (int regno, HOST_WIDE_INT offset)
 static rtx
 or1k_restore_reg (int regno, HOST_WIDE_INT offset, rtx cfa_restores)
 {
+  if (has_func_attr(NULL_TREE, "naked"))
+warning(0, "stack usage on naked function %s", current_function_name());
+
   rtx reg = gen_rtx_REG (Pmode, regno);
   rtx mem = gen_frame_mem (SImode, plus_constant (Pmode, stack_pointer_rtx,
  offset));
@@ -217,8 +262,8 @@ or1k_expand_prologue (void)
   if (flag_stack_usage_info)
 current_function_static_stack_size = -sp_offset;

-  /* Early exit for frameless functions.  */
-  if (sp_offset == 0)
+  /* Early exit for frameless functions */
+  if (sp_offset == 0 || has_func_attr(NULL_TREE, "naked"))
 goto fini;

   /* Adjust the stack pointer.  For large stack offsets we will
@@ -325,7 +370,7 @@ or1k_expand_epilogue (void)
   rtx insn, cfa_restores = NULL;

   sp_offset = cfun->machine->total_size;
-  if (sp_offset == 0)
+  if (sp_offset == 0 || has_func_attr(NULL_TREE, "naked"))
 return;

   reg_offset = cfun->machine->local_vars_size + cfun->machine->args_size;
@@ -509,6 +554,10 @@ or1k_return_addr (int, rtx frame)
 static bool
 or1k_frame_pointer_required ()
 {
+  /* Frame pointer is not required for naked functions */
+  if (has_func_attr(NULL_TREE, "naked"))
+return false;
+
   /* ??? While IRA checks accesses_prior_frames, reload does not.
  We do want the frame pointer for this case.  */
   return (crtl->accesses_prior_frames);
@@ -2212,6 +2261,9 @@ or1k_output_mi_thunk (FILE *file, tree thunk_fndecl,
 #undef  TARGET_HAVE_SPECULATION_SAFE_VALUE
 #define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed

+#undef  TARGET_ATTRIBUTE_TABLE
+#define TARGET_ATTRIBUTE_TABLE or1k_attribute_table
+
 /* Calling Conventions.  */
 #undef  TARGET_FUNCTION_VALUE
 #define TARGET_FUNCTION_VALUE or1k_function_value
-- 
2.30.2

Re: [PATCH] analyzer PR 106003

[David Malcolm via Gcc]

On Fri, 2022-06-24 at 00:00 +0530, Mir Immad wrote:

Thanks for the updated patch.

This is close to being ready.

One big issue is the target hook idea for isolating the target's
definition of the O_* flags as per Joseph's suggestion here:
  https://gcc.gnu.org/pipermail/gcc/2022-June/238961.html
Given Joseph's comment here:
  https://gcc.gnu.org/pipermail/gcc/2022-June/238954.html
I'm inclined to think that the target hook stuff could be done as a
followup.

Indentation has gone a bit wrong (presumably due to issue with the
mailer); the main thing to watch out for is to use tabs for 8 space
indentations within the file.  Enabling "visual whitespace" (or
whatever it's called) in your editor can help with this.

Every patch that adds any options (e.g. to gcc/analyzer/analyzer.opt)
needs to document those options, in gcc/doc/invoke.texi.  Grep for one
of the existing analyzer options in invoke.texi to see what you need to
add for the new options.

You'll need a ChangeLog entry before this can be pushed.  For better or
worse, the project requires ChangeLog entries.  You can
use the script ./contrib/mklog.py to help generate this.  Some more
information is here:
  https://www.gnu.org/prep/standards/html_node/Change-Logs.html
In GCC our ChangeLog entries are part of the git commit message, and we
have a serverside script to update the ChangeLog files in the source
tree (to avoid constantly having merge conflicts).

The Subject line for the commit should have an "analyzer: " prefix
and reference the bugzilla problem report (PR 106003)

Before you can push the patch, you'll have to test it with a full
bootstrap and regression test run.  Let me know if you need help with
that.

Various other comments inline below...

[...snip...]

> diff --git gcc/analyzer/analyzer.opt gcc/analyzer/analyzer.opt
> index 23dfc797cea..e2a629bb42c 100644
> --- gcc/analyzer/analyzer.opt
> +++ gcc/analyzer/analyzer.opt

[...snip...]
> +Wanalyzer-fd-use-without-check
> +Common Var(warn_analyzer_fd_use_without_check) Init(1) Warning
> +warn about code paths in which a possibly invalid file descriptor is
> passed to a must-be-a-valid file descriptor function argument.

These should be capitalized as English sentences, and the "must-be-a-
valid" wording doesn't feel quite right to me.

Reword this to something like:

"Warn about code paths in which a file descriptor is used without being
checked for validity."

or somesuch (all on one line).

[...snip...]

> diff --git gcc/analyzer/sm-fd.cc gcc/analyzer/sm-fd.cc
> new file mode 100644
> index 000..048014d7a26
> --- /dev/null
> +++ gcc/analyzer/sm-fd.cc
> @@ -0,0 +1,770 @@
> +/* A state machine for detecting misuses of POSIX file descriptor APIs.
> +   Copyright (C) 2019-2022 Free Software Foundation, Inc.
> +   Contributed by Immad Mir .
> +
> +This file is part of GCC.
> +
> +GCC 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.
> +
> +GCC 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 GCC; see the file COPYING3.  If not see
> +.  */
> +
> +#include "config.h"
> +#include "system.h"
> +#include "coretypes.h"
> +#include "tree.h"
> +#include "function.h"
> +#include "basic-block.h"
> +#include "gimple.h"
> +#include "options.h"
> +#include "diagnostic-path.h"
> +#include "diagnostic-metadata.h"
> +#include "function.h"
> +#include "json.h"
> +#include "analyzer/analyzer.h"
> +#include "diagnostic-event-id.h"
> +#include "analyzer/analyzer-logging.h"
> +#include "analyzer/sm.h"
> +#include "analyzer/pending-diagnostic.h"
> +#include "analyzer/function-set.h"
> +#include "analyzer/analyzer-selftests.h"
> +#include "tristate.h"
> +#include "selftest.h"
> +#include "analyzer/call-string.h"
> +#include "analyzer/program-point.h"
> +#include "analyzer/store.h"
> +#include "analyzer/region-model.h"
> +
> +#include 

We'll want to drop the #include  once we have a target hook.

[...snip...]
> +
> +  state_machine::state_t
> +  get_default_state (const svalue *sval) const final override
> +  {
> +if (tree cst = sval->maybe_get_constant ())
> +  {
> +int val = TREE_INT_CST_LOW (cst);
> +if (val < 0)
> +  {
> +return m_invalid;
> +  }
> +  }
> +return m_start;
> +  }

Please add coverage to the testsuite for the case of accessing negative
and non-negative constant integer values: what happens when we hit the
above cases?

In particular, IIRC 0, 1, and 2 are stdin, stdout, and stderr
respectively, and are already open at the start of "main" (though not
necessarily at the 

[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

--- Comment #1 from Marek Polacek  ---
The difference between r12-4495 and r12-4496:

$ diff -up b/q.C.252r.expand a/q.C.252r.expand
--- b/q.C.252r.expand   2022-06-23 23:16:44.753507476 +
+++ a/q.C.252r.expand   2022-06-23 23:16:16.232784087 +
@@ -831,10 +831,14 @@ try_optimize_cfg iteration 2
 (subreg:V16QI (reg/v:V4SI 168 [ R02$m_simd ]) 0)) "q.C":31:47 -1
  (nil))
 (insn 188 187 189 5 (set (reg:V4SI 339)
-(unspec:V4SI [
-(subreg:V4SI (reg:V16QI 338) 0)
-(subreg:V4SI (reg:V16QI 337) 0)
-] UNSPEC_VMRGL_DIRECT)) "q.C":31:47 -1
+(vec_select:V4SI (vec_concat:V8SI (subreg:V4SI (reg:V16QI 338) 0)
+(subreg:V4SI (reg:V16QI 337) 0))
+(parallel [
+(const_int 2 [0x2])
+(const_int 6 [0x6])
+(const_int 3 [0x3])
+(const_int 7 [0x7])
+]))) "q.C":31:47 -1
  (nil))
 (insn 189 188 190 5 (set (reg:V16QI 336)
 (subreg:V16QI (reg:V4SI 339) 0)) "q.C":31:47 -1
@@ -846,10 +850,14 @@ try_optimize_cfg iteration 2
 (subreg:V16QI (reg/v:V4SI 143 [ val ]) 0)) "q.C":32:47 -1
  (nil))
 (insn 192 191 193 5 (set (reg:V4SI 344)
-(unspec:V4SI [
-(subreg:V4SI (reg:V16QI 343) 0)
-(subreg:V4SI (reg:V16QI 342) 0)
-] UNSPEC_VMRGL_DIRECT)) "q.C":32:47 -1
+(vec_select:V4SI (vec_concat:V8SI (subreg:V4SI (reg:V16QI 343) 0)
+(subreg:V4SI (reg:V16QI 342) 0))
+(parallel [
+(const_int 2 [0x2])
+(const_int 6 [0x6])
+(const_int 3 [0x3])
+(const_int 7 [0x7])
+]))) "q.C":32:47 -1
  (nil))
 (insn 193 192 194 5 (set (reg:V16QI 341)
 (subreg:V16QI (reg:V4SI 344) 0)) "q.C":32:47 -1
@@ -861,10 +869,14 @@ try_optimize_cfg iteration 2
 (subreg:V4SI (reg:V16QI 341) 0)) "q.C":35:8 -1
  (nil))
 (insn 196 195 197 5 (set (reg:V4SI 349)
-(unspec:V4SI [
-(subreg:V4SI (reg:V16QI 341) 0)
-(subreg:V4SI (reg:V16QI 336) 0)
-] UNSPEC_VMRGL_DIRECT)) "q.C":35:8 -1
+(vec_select:V4SI (vec_concat:V8SI (subreg:V4SI (reg:V16QI 341) 0)
+(subreg:V4SI (reg:V16QI 336) 0))
+(parallel [
+(const_int 2 [0x2])
+(const_int 6 [0x6])
+(const_int 3 [0x3])
+(const_int 7 [0x7])
+]))) "q.C":35:8 -1
  (nil))
 (insn 197 196 198 5 (set (reg:V16QI 348)
 (subreg:V16QI (reg:V4SI 349) 0)) "q.C":35:8 -1
@@ -934,7 +946,7 @@ try_optimize_cfg iteration 2
 (reg/f:DI 120)) "q.C":103:7 -1
  (nil))
 (call_insn 9 8 10 2 (parallel [
-(call (mem:SI (symbol_ref:DI ("_Z3fooPhPj") [flags 0x3] 
) [0 foo S4 A8])
+(call (mem:SI (symbol_ref:DI ("_Z3fooPhPj") [flags 0x3] 
) [0 foo S4 A8])
 (const_int 0 [0]))
 (use (const_int 0 [0]))
 (clobber (reg:DI 96 lr))
@@ -968,7 +980,7 @@ try_optimize_cfg iteration 2
  -> 17)
 (note 14 13 15 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
 (call_insn 15 14 16 4 (parallel [
-(call (mem:SI (symbol_ref:DI ("abort") [flags 0x41] 
) [0 __builtin_abort S4 A8])
+(call (mem:SI (symbol_ref:DI ("abort") [flags 0x41] 
) [0 __builtin_abort S4 A8])
 (const_int 0 [0]))
 (use (const_int 0 [0]))
 (clobber (reg:DI 96 lr))

[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |12.2
   Keywords||wrong-code
 Target||powerpc64le-unknown-linux-g
   ||nu
   Host||powerpc64le-unknown-linux-g
   ||nu
Summary|wrong code with -O  |[12/13 Regression] wrong
   |-fno-tree-forwprop  |code with -O
   |-maltivec on ppc64le|-fno-tree-forwprop
   ||-maltivec on ppc64le
 CC||luoxhu at gcc dot gnu.org
  Build||powerpc64le-unknown-linux-g
   ||nu

[Bug target/106069] New: wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

Bug ID: 106069
   Summary: wrong code with -O -fno-tree-forwprop -maltivec on
ppc64le
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

The following test crashes at runtime since r12-4496-g0910c516a3d72a.

$ ./cc1plus.r12-4495 -quiet -O -fno-tree-forwprop -maltivec q.C; g++ q.s;
./a.out
$ ./cc1plus.r12-4496 -quiet -O -fno-tree-forwprop -maltivec q.C; g++ q.s;
./a.out 
Aborted

Target: powerpc64le-unknown-linux-gnu
Configured with: /home/polacek/src/gcc/configure --enable-languages=c,c++
--enable-checking=yes -with-system-zlib --disable-bootstrap --disable-libvtv
--disable-libitm --disable-libsanitizer
gcc version 13.0.0 20220622 (experimental) (GCC)


extern "C" void *memcpy(void *, const void *, unsigned long);
typedef __attribute__((altivec(vector__))) unsigned native_simd_type;

union {
  native_simd_type V;
  int R[4];
} store_le_vec;

struct S {
  S() = default;
  S(unsigned B0) {
native_simd_type val{B0};
m_simd = val;
  }
  void store_le(unsigned char out[]) {
store_le_vec.V = m_simd;
unsigned int x0 = store_le_vec.R[0];
memcpy(out, , 1);
  }
  S rotl(unsigned int r) {
native_simd_type rot{r};
return __builtin_vec_rl(m_simd, rot);
  }
  void operator+=(S other) {
m_simd = __builtin_vec_add(m_simd, other.m_simd);
  }
  void operator^=(S other) {
m_simd = __builtin_vec_xor(m_simd, other.m_simd);
  }
  static void transpose(S , S B1, S B2, S B3) {
native_simd_type T0 = __builtin_vec_mergeh(B0.m_simd, B2.m_simd);
native_simd_type T1 = __builtin_vec_mergeh(B1.m_simd, B3.m_simd);
native_simd_type T2 = __builtin_vec_mergel(B0.m_simd, B2.m_simd);
native_simd_type T3 = __builtin_vec_mergel(B1.m_simd, B3.m_simd);
B0 = __builtin_vec_mergeh(T0, T1);
B3 = __builtin_vec_mergel(T2, T3);
  }
  S(native_simd_type x) : m_simd(x) {}
  native_simd_type m_simd;
};

void
foo (unsigned char output[], unsigned state[])
{
  S R00 = state[0];
  S R01 = state[0];
  S R02 = state[2];
  S R03 = state[0];
  S R05 = state[5];
  S R06 = state[6];
  S R07 = state[7];
  S R08 = state[8];
  S R09 = state[9];
  S R10 = state[10];
  S R11 = state[11];
  S R12 = state[12];
  S R13 = state[13];
  S R14 = state[4];
  S R15 = state[15];
  for (int r = 0; r != 10; ++r) {
R09 += R13;
R11 += R15;
R05 ^= R09;
R06 ^= R10;
R07 ^= R11;
R07 = R07.rotl(7);
R00 += R05;
R01 += R06;
R02 += R07;
R15 ^= R00;
R12 ^= R01;
R13 ^= R02;
R00 += R05;
R01 += R06;
R02 += R07;
R15 ^= R00;
R12 = R12.rotl(8);
R13 = R13.rotl(8);
R10 += R15;
R11 += R12;
R08 += R13;
R09 += R14;
R05 ^= R10;
R06 ^= R11;
R07 ^= R08;
R05 = R05.rotl(7);
R06 = R06.rotl(7);
R07 = R07.rotl(7);
  }
  R00 += state[0];
  S::transpose(R00, R01, R02, R03);
  R00.store_le(output);
}

unsigned char res[1];
unsigned main_state[]{1634760805, 60878,  2036477234, 6,
  0,  825562964,  1471091955, 1346092787,
  506976774,  4197066702, 518848283,  118491664,
  0,  0,  0,  0};
int
main ()
{
  foo (res, main_state);
  if (res[0] != 152)
__builtin_abort();
}

[Bug libstdc++/106067] Error on implicit conversion to std::function: 'static constexpr bool std::_Function_handler<...>...' used before its definition

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

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

--- Comment #1 from Jonathan Wakely  ---
Probably due to r12-3174 (backported as r11-9289)

gcc-10-20220623 is now available

[GCC Administrator via Gcc]

Snapshot gcc-10-20220623 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20220623/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-10 revision 94dd514748a75862dc123d5da0673dffbf48239e

You'll find:

 gcc-10-20220623.tar.xz   Complete GCC

  SHA256=a4417bc36aa036db13b551c21339f29177d3dd63e04eecaa13cd20a1d658f9e5
  SHA1=75a07f041dada80593c8a571f782861b6a44ede9

Diffs from 10-20220616 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug fortran/105813] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8490

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

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

--- Comment #3 from Steve Kargl  ---
On Thu, Jun 23, 2022 at 09:18:40PM +, anlauf at gcc dot gnu.org wrote:
> 
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> Simpler fix:
> 
> diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
> index 0c2cb50c6a7..91d87a1b2c1 100644
> --- a/gcc/fortran/check.cc
> +++ b/gcc/fortran/check.cc
> @@ -6353,6 +6353,8 @@ gfc_check_unpack (gfc_expr *vector, gfc_expr *mask,
> gfc_expr *field)
>if (!same_type_check (vector, 0, field, 2))
>  return false;
> 
> +  gfc_simplify_expr (mask, 0);
> +
>if (mask->expr_type == EXPR_ARRAY
>&& gfc_array_size (vector, _size))
>  {
> 

If it survives regression testing, then I think it
can be committed.

[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X' since r12-954-g84fd1b5dff70cd74

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

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

commit r12-8511-gdb29b66193407d2fd6a04a07ecbd961c8d3f7d62
Author: Jason Merrill 
Date:   Thu Jun 23 16:04:02 2022 -0400

c++: anon union designated init [PR105925]

This testcase was failing because CONSTRUCTOR_IS_DESIGNATED_INIT wasn't
getting set on the introduced CONSTRUCTOR for the anonymous union, and
build_aggr_conv uses that flag to decide whether to pay attention to the
indexes of the CONSTRUCTOR.  So set the flag when we see a designator
rather
than relying on copying it from another CONSTRUCTOR.

PR c++/105925

gcc/cp/ChangeLog:

* decl.cc (reshape_init_array_1): Set
CONSTRUCTOR_IS_DESIGNATED_INIT here.
(reshape_init_class): And here.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/desig26.C: New test.

[PATCH] testsuite: Add new target check for no_alignment_constraints

[Dimitar Dimitrov]

A few testcases were marked for avr target, which has no alignment
requirements.  But those tests in fact should filter for any
target having __BIGGEST_ALIGNMENT__=1.

A new effective target check is introduced: no_alignment_constraints.
It checks whether __BIGGEST_ALIGNMENT__ is declared as 1.

Alternative names I considered for the new macro are:
  - !natural_alignment_16
  - biggest_alignment_1

This change fixes the testsuite cases for PRU target.  I don't have
environment to test mm32c and cris targets, which also declare
__BIGGEST_ALIGNMENT__=1.

It was regression-tested on x86_64-pc-linux-gnu.

The following two existing macros were considered, but they check for
subtly different target behaviour:
 1. non_strict_align
If true, non-aligned access is permitted. But it also allows
variables to be naturally aligned, which is not true for
no_alignment_constraints.

 2. default_packed
Whether structures are packed by default is not necessarily
the same as lacking constraints for any variable alignment.
For example, BIGGEST_FIELD_ALIGNMENT or ADJUST_FIELD_ALIGN
could be defined for a target.

Ok for trunk?

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/c-c++-common/Wcast-align.c |  4 ++--
 gcc/testsuite/gcc.dg/c11-align-4.c   |  2 +-
 gcc/testsuite/gcc.dg/strlenopt-10.c  |  6 +++---
 gcc/testsuite/gcc.dg/strlenopt-11.c  | 14 +++---
 gcc/testsuite/gcc.dg/strlenopt-13.c  | 16 
 gcc/testsuite/lib/target-supports.exp| 13 +
 6 files changed, 34 insertions(+), 21 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/Wcast-align.c 
b/gcc/testsuite/c-c++-common/Wcast-align.c
index c296c7fd249..1087b10fd99 100644
--- a/gcc/testsuite/c-c++-common/Wcast-align.c
+++ b/gcc/testsuite/c-c++-common/Wcast-align.c
@@ -16,8 +16,8 @@ struct t { double x; } *q;
 void
 foo (void)
 {
-  y = (c *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of target 
type" } */
-  z = (d *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of target 
type" } */
+  y = (c *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of target 
type" "" { target { ! no_alignment_constraints } } } */
+  z = (d *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of target 
type" "" { target { ! no_alignment_constraints } } } */
   (long long *) p;  /* { dg-bogus "alignment" } */
   (double *) q; /* { dg-bogus "alignment" } */
 }
diff --git a/gcc/testsuite/gcc.dg/c11-align-4.c 
b/gcc/testsuite/gcc.dg/c11-align-4.c
index 57f93ff05fc..eb9071b9149 100644
--- a/gcc/testsuite/gcc.dg/c11-align-4.c
+++ b/gcc/testsuite/gcc.dg/c11-align-4.c
@@ -2,7 +2,7 @@
are at least some alignment constraints).  */
 /* { dg-do compile } */
 /* { dg-options "-std=c11 -pedantic-errors" } */
-/* { dg-skip-if "no alignment constraints" { "avr-*-*" } } */
+/* { dg-skip-if "no alignment constraints" { no_alignment_constraints } } */
 
 #include 
 
diff --git a/gcc/testsuite/gcc.dg/strlenopt-10.c 
b/gcc/testsuite/gcc.dg/strlenopt-10.c
index ce959c34a80..6e2c2597b27 100644
--- a/gcc/testsuite/gcc.dg/strlenopt-10.c
+++ b/gcc/testsuite/gcc.dg/strlenopt-10.c
@@ -70,10 +70,10 @@ main ()
 }
 
 /* { dg-final { scan-tree-dump-times "strlen \\(" 2 "strlen1" } } */
-/* avr has BIGGEST_ALIGNMENT 8, allowing fold_builtin_memory_op
+/* Some targets have BIGGEST_ALIGNMENT 8-bits, allowing fold_builtin_memory_op
to expand the memcpy call at the end of fn2.  */
-/* { dg-final { scan-tree-dump-times "memcpy \\(" 8 "strlen1" { target { ! 
avr-*-* } } } } */
-/* { dg-final { scan-tree-dump-times "memcpy \\(" 7 "strlen1" { target { 
avr-*-* } } } } */
+/* { dg-final { scan-tree-dump-times "memcpy \\(" 8 "strlen1" { target { ! 
no_alignment_constraints } } } } */
+/* { dg-final { scan-tree-dump-times "memcpy \\(" 7 "strlen1" { target { 
no_alignment_constraints} } } } */
 /* { dg-final { scan-tree-dump-times "strcpy \\(" 0 "strlen1" } } */
 /* { dg-final { scan-tree-dump-times "strcat \\(" 0 "strlen1" } } */
 /* { dg-final { scan-tree-dump-times "strchr \\(" 0 "strlen1" } } */
diff --git a/gcc/testsuite/gcc.dg/strlenopt-11.c 
b/gcc/testsuite/gcc.dg/strlenopt-11.c
index abd9faebed6..952de0730f1 100644
--- a/gcc/testsuite/gcc.dg/strlenopt-11.c
+++ b/gcc/testsuite/gcc.dg/strlenopt-11.c
@@ -59,17 +59,17 @@ main ()
 }
 
 /* { dg-final { scan-tree-dump-times "strlen \\(" 3 "strlen1" } } */
-/* avr has BIGGEST_ALIGNMENT 8, allowing fold_builtin_memory_op
+/* Some targets have BIGGEST_ALIGNMENT 8-bits, allowing fold_builtin_memory_op
to expand the memcpy call at the end of fn1.  */
-/* { dg-final { scan-tree-dump-times "memcpy \\(" 7 "strlen1" { target { ! 
avr-*-* } } } } */
-/* { dg-final { scan-tree-dump-times "memcpy \\(" 6 "strlen1" { target { 
avr-*-* } } } } */
+/* { dg-final { scan-tree-dump-times "memcpy \\(" 7 "strlen1" { target { ! 
no_alignment_constraints } } } } */
+/* { dg-final { scan-tree-dump-times "memcpy \\(" 6 "strlen1" { target { 
no_alignment_constraints 

[PATCH] testsuite: Handle default_packed for gcc.dg/builtin-object-size-20.c

[Dimitar Dimitrov]

The gcc.dg/builtin-object-size-20.c test case assumes that the target
inserts padding between structure members.  Obviously it fails for
targets which pack structures by default.

Split the cases into two tests, so that the ones requiring structure
padding can be skipped for default_packed targets.

Ok for trunk?

gcc/testsuite/ChangeLog:

* gcc.dg/builtin-object-size-20.c: Remove cases which
work on default_packed targets.
* gcc.dg/builtin-object-size-22.c: New test with the cases
removed above.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/gcc.dg/builtin-object-size-20.c | 64 +--
 gcc/testsuite/gcc.dg/builtin-object-size-22.c | 79 +++
 2 files changed, 81 insertions(+), 62 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/builtin-object-size-22.c

diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-20.c 
b/gcc/testsuite/gcc.dg/builtin-object-size-20.c
index bed973c2c77..f40e3dcc1a9 100644
--- a/gcc/testsuite/gcc.dg/builtin-object-size-20.c
+++ b/gcc/testsuite/gcc.dg/builtin-object-size-20.c
@@ -1,7 +1,8 @@
 /* PR middle-end/92815 - spurious -Wstringop-overflow writing into
a flexible array of an extern struct
{ dg-do compile }
-   { dg-options "-O -Wall -fdump-tree-optimized" } */
+   { dg-options "-O -Wall -fdump-tree-optimized" }
+   { dg-skip-if "test assumes that structs have padding" { default_packed } } 
*/
 
 #define ASSERT(expr) ((expr) ? (void)0 : fail (__LINE__))
 #define bos0(expr) __builtin_object_size (expr, 1)
@@ -18,44 +19,6 @@ typedef __SIZE_TYPE__  size_t;
 extern void fail (int);
 
 
-/* Verify sizes of a struct with a flexible array member and no padding.  */
-
-struct ACX { char n, a[]; };
-
-struct ACX ac0 = { };
-struct ACX ac1 = { 1, { 1 } };
-struct ACX ac2 = { 2, { 1, 2 } };
-struct ACX ac3 = { 3, { 1, 2, 3 } };
-
-extern struct ACX eacx;
-
-void facx (void)
-{
-  ASSERT (bos0 () == sizeof ac0);
-  ASSERT (bos0 () == 2);
-  ASSERT (bos0 () == 3);
-  ASSERT (bos0 () == 4);
-  ASSERT (bos0 () == (size_t)-1);
-
-  ASSERT (bos1 () == sizeof ac0);
-  ASSERT (bos1 () == 2);
-  ASSERT (bos1 () == 3);
-  ASSERT (bos1 () == 4);
-  ASSERT (bos1 () == (size_t)-1);
-
-  ASSERT (bos2 () == sizeof ac0);
-  ASSERT (bos2 () == 2);
-  ASSERT (bos2 () == 3);
-  ASSERT (bos2 () == 4);
-  ASSERT (bos2 () == sizeof eacx);
-
-  ASSERT (bos3 () == sizeof ac0);
-  ASSERT (bos3 () == 2);
-  ASSERT (bos3 () == 3);
-  ASSERT (bos3 () == 4);
-  ASSERT (bos3 () == sizeof eacx);
-}
-
 
 
 /* Verify sizes of a struct with a flexible array member and 1 byte
@@ -289,27 +252,4 @@ void fai64cx (void)
   ASSERT (bos3 () == sizeof eai64cx);
 }
 
-
-/* Also verify sizes of a struct with a zero length array member.  */
-
-struct A0C0 { char n, a[0]; };
-
-struct A0C0 a0c0 = { };
-extern struct A0C0 ea0c0;
-
-void fa0c0 (void)
-{
-  ASSERT (bos0 () == sizeof a0c0);
-  ASSERT (bos0 () == sizeof ea0c0);
-
-  ASSERT (bos1 () == sizeof a0c0);
-  ASSERT (bos1 () == sizeof ea0c0);
-
-  ASSERT (bos2 () == sizeof a0c0);
-  ASSERT (bos2 () == sizeof ea0c0);
-
-  ASSERT (bos3 () == sizeof a0c0);
-  ASSERT (bos3 () == sizeof ea0c0);
-}
-
 /* { dg-final { scan-tree-dump-not "fail" "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-22.c 
b/gcc/testsuite/gcc.dg/builtin-object-size-22.c
new file mode 100644
index 000..1e55229c949
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/builtin-object-size-22.c
@@ -0,0 +1,79 @@
+/* PR middle-end/92815 - a variant of gcc.dg/builtin-object-size-20.c
+   prepared for all targets, irregardless if they pack or not
+   the structs by default.
+   { dg-do compile }
+   { dg-options "-O -Wall -fdump-tree-optimized" } */
+
+#define ASSERT(expr) ((expr) ? (void)0 : fail (__LINE__))
+#define bos0(expr) __builtin_object_size (expr, 1)
+#define bos1(expr) __builtin_object_size (expr, 1)
+#define bos2(expr) __builtin_object_size (expr, 2)
+#define bos3(expr) __builtin_object_size (expr, 3)
+
+typedef __SIZE_TYPE__  size_t;
+
+
+extern void fail (int);
+
+
+/* Verify sizes of a struct with a flexible array member and no padding.  */
+
+struct ACX { char n, a[]; };
+
+struct ACX ac0 = { };
+struct ACX ac1 = { 1, { 1 } };
+struct ACX ac2 = { 2, { 1, 2 } };
+struct ACX ac3 = { 3, { 1, 2, 3 } };
+
+extern struct ACX eacx;
+
+void facx (void)
+{
+  ASSERT (bos0 () == sizeof ac0);
+  ASSERT (bos0 () == 2);
+  ASSERT (bos0 () == 3);
+  ASSERT (bos0 () == 4);
+  ASSERT (bos0 () == (size_t)-1);
+
+  ASSERT (bos1 () == sizeof ac0);
+  ASSERT (bos1 () == 2);
+  ASSERT (bos1 () == 3);
+  ASSERT (bos1 () == 4);
+  ASSERT (bos1 () == (size_t)-1);
+
+  ASSERT (bos2 () == sizeof ac0);
+  ASSERT (bos2 () == 2);
+  ASSERT (bos2 () == 3);
+  ASSERT (bos2 () == 4);
+  ASSERT (bos2 () == sizeof eacx);
+
+  ASSERT (bos3 () == sizeof ac0);
+  ASSERT (bos3 () == 2);
+  ASSERT (bos3 () == 3);
+  ASSERT (bos3 () == 4);
+  ASSERT (bos3 () == sizeof eacx);
+}
+
+/* Also verify sizes of a struct with a zero length array member.  */
+

[PATCH] testsuite: Rename test-defined macros

[Dimitar Dimitrov]

Epiphany, PRU, ARC and NDS32 may predefine __big_endian__ and
__little_endian__ macros.  This leads to spurious warnings like:
  gcc.dg/sso/memcpy-1.c:7: warning: "__little_endian__" redefined

Fix by renaming the macros in the test.

Ok for trunk?

gcc/testsuite/ChangeLog:

* gcc.dg/sso/memcpy-1.c (__big_endian__, __little_endian__):
Rename macros to avoid conflicts with predefined ones.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/gcc.dg/sso/memcpy-1.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/sso/memcpy-1.c 
b/gcc/testsuite/gcc.dg/sso/memcpy-1.c
index b4e1c8786d9..0dea955cbaf 100644
--- a/gcc/testsuite/gcc.dg/sso/memcpy-1.c
+++ b/gcc/testsuite/gcc.dg/sso/memcpy-1.c
@@ -3,20 +3,20 @@
 typedef unsigned char uint8_t;
 typedef unsigned int uint32_t;
 
-#define __big_endian__ scalar_storage_order("big-endian")
-#define __little_endian__ scalar_storage_order("little-endian")
+#define __big_endian_attr__ scalar_storage_order("big-endian")
+#define __little_endian_attr__ scalar_storage_order("little-endian")
 
 typedef union
 {
   uint32_t val;
   uint8_t v[4];
-} __attribute__((__big_endian__)) upal_u32be_t;
+} __attribute__((__big_endian_attr__)) upal_u32be_t;
 
 typedef union
 {
   uint32_t val;
   uint8_t v[4];
-} __attribute__((__little_endian__)) upal_u32le_t;
+} __attribute__((__little_endian_attr__)) upal_u32le_t;
 
 static inline uint32_t native_to_big_endian(uint32_t t)
 {
-- 
2.36.1

[PATCH] testsuite: Remove reliance on argc in lto/pr101868_0.c

[Dimitar Dimitrov]

Some embedded targets do not pass any argv arguments.  When argc is
zero, this causes spurious failures for lto/pr101868_0.c.  Fix by
following the strategy in r0-114701-g2c49569ecea56d.  Use a volatile
variable instead of argc to inject a runtime value into the test.

I validated the following:
  - No changes in testresults for x86_64-pc-linux-gnu.
  - The spurious failures are fixed for PRU target.
  - lto/pr101868_0.c still fails on x86_64-pc-linux-gnu, if
the PR/101868 fix (r12-2254-gfedcf3c476aff7) is reverted.

Ok for trunk?

PR tree-optimization/101868

gcc/testsuite/ChangeLog:

* gcc.dg/lto/pr101868_0.c (zero): New volatile variable.
(main): Use it instead of argc.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/gcc.dg/lto/pr101868_0.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/lto/pr101868_0.c 
b/gcc/testsuite/gcc.dg/lto/pr101868_0.c
index c84d19b0267..03124308267 100644
--- a/gcc/testsuite/gcc.dg/lto/pr101868_0.c
+++ b/gcc/testsuite/gcc.dg/lto/pr101868_0.c
@@ -22,12 +22,13 @@ repro(VALUE dummy, VALUE hash)
 
 static VALUE (*that)(VALUE dummy, VALUE hash) = repro;
 
+volatile int zero = 0;
+
 int
 main(int argc, char **argv)
 {
-argc--;
-that(0, argc);
+that(0, zero);
 
-rb_check_type(argc, argc);
+rb_check_type(zero, zero);
 
 }
-- 
2.36.1

[PATCH] testsuite: Skip btf-bitfields-1.c if int is less than 32-bits

[Dimitar Dimitrov]

This test spuriously fails on AVR with:
   error: width of 'bitfield_c' exceeds its type

8-bit and 16-bit microcontrollers do not seem to be the target audience
for BTF file format.  So the least intrusive fix is to simply skip the
test for them.

Ok for trunk?

gcc/testsuite/ChangeLog:

* gcc.dg/debug/btf/btf-bitfields-1.c: Skip if int is less than
32-bits.

CC: Jose E. Marchesi 
Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c
index 4cb7ee84f83..793b4c8db82 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c
@@ -10,6 +10,7 @@
 
 /* { dg-do compile )  */
 /* { dg-options "-O0 -gbtf -dA" } */
+/* { dg-require-effective-target int32plus } */
 
 /* { dg-final { scan-assembler-times "\[\t \]0x8404\[\t 
\]+\[^\n\]*btt_info" 1 } } */
 
-- 
2.36.1

[PATCH] testsuite: Adjust btf-bitfields-1.c for default_packed

[Dimitar Dimitrov]

If target packs structures by default, the bitfield offset which the
tests validates must be adjusted to not include padding.

Ok for trunk?

gcc/testsuite/ChangeLog:

* gcc.dg/debug/btf/btf-bitfields-1.c: Adjust the checked offsets
for targets which pack structures by default.

CC: Jose E. Marchesi 
Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c
index c6bf52130dc..4cb7ee84f83 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c
@@ -5,7 +5,8 @@
  (bit_size << 24) | bit_offset
  - (0xa  << 24) | 0x20
  - (0x7  << 24) | 0x2a
- - (0x13 << 24) | 0x40 - note that this is aligned to 0x40.  */
+ - (0x13 << 24) | 0x40 - note that this is aligned to 0x40.
+ - (0x13 << 24) | 0x31 - in case structures are packed.  */
 
 /* { dg-do compile )  */
 /* { dg-options "-O0 -gbtf -dA" } */
@@ -14,7 +15,8 @@
 
 /* { dg-final { scan-assembler-times "\[\t \]0xa20\[\t 
\]+\[^\n\]*btm_offset" 1 } } */
 /* { dg-final { scan-assembler-times "\[\t \]0x72a\[\t 
\]+\[^\n\]*btm_offset" 1 } } */
-/* { dg-final { scan-assembler-times "\[\t \]0x1340\[\t 
\]+\[^\n\]*btm_offset" 1 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x1340\[\t 
\]+\[^\n\]*btm_offset" 1 { target { ! default_packed } } } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x1331\[\t 
\]+\[^\n\]*btm_offset" 1 { target { default_packed } } } } */
 
 struct bitt {
   int a;
-- 
2.36.1

[Bug fortran/105813] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8490

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Simpler fix:

diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 0c2cb50c6a7..91d87a1b2c1 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -6353,6 +6353,8 @@ gfc_check_unpack (gfc_expr *vector, gfc_expr *mask,
gfc_expr *field)
   if (!same_type_check (vector, 0, field, 2))
 return false;

+  gfc_simplify_expr (mask, 0);
+
   if (mask->expr_type == EXPR_ARRAY
   && gfc_array_size (vector, _size))
 {

Re: [PATCH] fortran, libgfortran: Avoid using libquadmath for glibc 2.26+

[Jakub Jelinek via Gcc-patches]

On Thu, Jun 23, 2022 at 10:49:55PM +0200, Harald Anlauf wrote:
> > We need both a compiler change (so that for glibc 2.26+ it uses *f128 APIs
> > instead of *q) and library change.
> 
> this is quite an important change in the gfortran ABI, as it will
> require recompilation of (library) code using quad precision.
> Not that I am particularly affected, but this should be highlighted
> for users.

We currently use
%rename lib liborig
*lib: %{static-libgfortran:--as-needed} -lquadmath 
%{static-libgfortran:--no-as-needed} -lm %(libgcc) %(liborig)
in libgfortran.spec (on targets where we do configure in libquadmath).
So, I believe the patch as is is an ABI change for *.o files if they use
real(kind=16) math functions (one needs to recompile them), but not
for linked shared libraries or executables, because the above aranges
for them to be linked with -lquadmath or for -static-libgfortran with
--as-needed -lquadmath --no-as-needed.  The former adds libquadmath.so.0
automatically to anything gfortran links, the latter to anything that
actually needs it (i.e. has undefined math/complex *q symbols).

Note, libgfortran.so.5 itself is ABI compatible, just no longer has
DT_NEEDED libquadmath.so.0 and uses the *f128 APIs + str{to,from}f128
instead of *q APIs + strtoflt128 and quadmath_snprintf.

Now, what we could do if we'd want to also preserve *.o file compatibility,
would be for gcc configured on glibc 2.26+ change libgfortran.spec to
*lib: --as-needed -lquadmath --no-as-needed -lm %(libgcc) %(liborig)
so that we even without -static-libgfortran link in libquadmath.so.0
only if it is needed.  So, if there will be any gcc <= 12 compiled
*.o files or *.o files compiled by gcc 13 if it was configured against
glibc 2.25 or older, we'd link -lquadmath in, but if there are just
*.o files referencing *f128 symbols, we wouldn't.

> Am I right in assuming that this also effectively fixes PR46539?
> (Add -static-libquadmath).

That was one of the intents of the patch.
But sure, it doesn't introduce -static-libquadmath, nor arranges for
-static-libgfortran to link libquadmath statically, just in some cases
(gcc configured on glibc 2.26 or later) and when everything that calls
real(kind=16) math functions has been recompiled arranges for libquadmath
not to be used at all.

> > --- gcc/fortran/trans-intrinsic.cc.jj   2022-05-16 11:14:57.587427707 
> > +0200
> > +++ gcc/fortran/trans-intrinsic.cc  2022-06-23 11:42:03.355899271 +0200
> > @@ -155,7 +155,7 @@ builtin_decl_for_precision (enum built_i
> > else if (precision == TYPE_PRECISION (double_type_node))
> >   i = m->double_built_in;
> > else if (precision == TYPE_PRECISION (long_double_type_node)
> > -  && (!gfc_real16_is_float128
> > +  && ((!gfc_real16_is_float128 & !gfc_real16_is__Float128)
> 
> Shouldn't this be && instead of & ?

You're right, will fix.

Jakub

[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X' since r12-954-g84fd1b5dff70cd74

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

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

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

https://gcc.gnu.org/g:6c72f1bfc3469422460d86314a081353632d4bcb

commit r13-1227-g6c72f1bfc3469422460d86314a081353632d4bcb
Author: Jason Merrill 
Date:   Thu Jun 23 14:41:19 2022 -0400

c++: designated init cleanup [PR105925]

build_aggr_conv expects to run after reshape_init, which will usually have
filled out all the CONSTRUCTOR indexes; there's no reason to limit using
those to the case where the user gave an explicit designator.

PR c++/105925

gcc/cp/ChangeLog:

* call.cc (build_aggr_conv): Don't depend on
CONSTRUCTOR_IS_DESIGNATED_INIT.

[pushed] c++: designated init cleanup [PR105925]

[Jason Merrill via Gcc-patches]

build_aggr_conv expects to run after reshape_init, which will usually have
filled out all the CONSTRUCTOR indexes; there's no reason to limit using
those to the case where the user gave an explicit designator.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/105925

gcc/cp/ChangeLog:

* call.cc (build_aggr_conv): Don't depend on
CONSTRUCTOR_IS_DESIGNATED_INIT.
---
 gcc/cp/call.cc | 60 +-
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 4710c3777c5..f1dd8377628 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -969,7 +969,8 @@ build_aggr_conv (tree type, tree ctor, int flags, 
tsubst_flags_t complain)
   tree empty_ctor = NULL_TREE;
   hash_set pset;
 
-  /* We already called reshape_init in implicit_conversion.  */
+  /* We already called reshape_init in implicit_conversion, but it might not
+ have done anything in the case of parenthesized aggr init.  */
 
   /* The conversions within the init-list aren't affected by the enclosing
  context; they're always simple copy-initialization.  */
@@ -979,49 +980,48 @@ build_aggr_conv (tree type, tree ctor, int flags, 
tsubst_flags_t complain)
  to corresponding TREE_TYPE (ce->index) and mark those FIELD_DECLs as
  visited.  In the following loop then ignore already visited
  FIELD_DECLs.  */
-  if (CONSTRUCTOR_IS_DESIGNATED_INIT (ctor))
+  tree idx, val;
+  FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (ctor), i, idx, val)
 {
-  tree idx, val;
-  FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (ctor), i, idx, val)
+  if (!idx)
+   break;
+
+  gcc_checking_assert (TREE_CODE (idx) == FIELD_DECL);
+
+  tree ftype = TREE_TYPE (idx);
+  bool ok;
+
+  if (TREE_CODE (ftype) == ARRAY_TYPE)
+   ok = can_convert_array (ftype, val, flags, complain);
+  else
+   ok = can_convert_arg (ftype, TREE_TYPE (val), val, flags,
+ complain);
+
+  if (!ok)
+   return NULL;
+
+  /* For unions, there should be just one initializer.  */
+  if (TREE_CODE (type) == UNION_TYPE)
{
- if (idx && TREE_CODE (idx) == FIELD_DECL)
-   {
- tree ftype = TREE_TYPE (idx);
- bool ok;
-
- if (TREE_CODE (ftype) == ARRAY_TYPE)
-   ok = can_convert_array (ftype, val, flags, complain);
- else
-   ok = can_convert_arg (ftype, TREE_TYPE (val), val, flags,
- complain);
-
- if (!ok)
-   return NULL;
- /* For unions, there should be just one initializer.  */
- if (TREE_CODE (type) == UNION_TYPE)
-   {
- field = NULL_TREE;
- i = 1;
- break;
-   }
- pset.add (idx);
-   }
- else
-   return NULL;
+ field = NULL_TREE;
+ i = 1;
+ break;
}
+  pset.add (idx);
 }
 
   for (; field; field = next_aggregate_field (DECL_CHAIN (field)))
 {
   tree ftype = TREE_TYPE (field);
-  tree val;
   bool ok;
 
   if (!pset.is_empty () && field_in_pset (pset, field))
continue;
   if (i < CONSTRUCTOR_NELTS (ctor))
{
- val = CONSTRUCTOR_ELT (ctor, i)->value;
+ constructor_elt *ce = CONSTRUCTOR_ELT (ctor, i);
+ gcc_checking_assert (!ce->index);
+ val = ce->value;
  ++i;
}
   else if (DECL_INITIAL (field))

base-commit: d610ae121e8ecd738de4dc01e6ac11ecf7c2327e
-- 
2.27.0

[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X' since r12-954-g84fd1b5dff70cd74

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

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

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

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

commit r13-1226-gd610ae121e8ecd738de4dc01e6ac11ecf7c2327e
Author: Jason Merrill 
Date:   Thu Jun 23 16:04:02 2022 -0400

c++: anon union designated init [PR105925]

This testcase was failing because CONSTRUCTOR_IS_DESIGNATED_INIT wasn't
getting set on the introduced CONSTRUCTOR for the anonymous union, and
build_aggr_conv uses that flag to decide whether to pay attention to the
indexes of the CONSTRUCTOR.  So set the flag when we see a designator
rather
than relying on copying it from another CONSTRUCTOR.

This avoids some redundant errors on desig4.C because we stop setting
CONSTRUCTOR_IS_DESIGNATED_INIT on _Complex CONSTRUCTORs where it's
nonsense.

PR c++/105925

gcc/cp/ChangeLog:

* decl.cc (reshape_init_array_1): Set
CONSTRUCTOR_IS_DESIGNATED_INIT here.
(reshape_init_class): And here.
(reshape_init): Not here.

gcc/testsuite/ChangeLog:

* g++.dg/ext/desig4.C: Remove extra errors.
* g++.dg/cpp2a/desig26.C: New test.

[pushed] c++: anon union designated init [PR105925]

[Jason Merrill via Gcc-patches]

This testcase was failing because CONSTRUCTOR_IS_DESIGNATED_INIT wasn't
getting set on the introduced CONSTRUCTOR for the anonymous union, and
build_aggr_conv uses that flag to decide whether to pay attention to the
indexes of the CONSTRUCTOR.  So set the flag when we see a designator rather
than relying on copying it from another CONSTRUCTOR.

This avoids some redundant errors on desig4.C because we stop setting
CONSTRUCTOR_IS_DESIGNATED_INIT on _Complex CONSTRUCTORs where it's
nonsense.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/105925

gcc/cp/ChangeLog:

* decl.cc (reshape_init_array_1): Set
CONSTRUCTOR_IS_DESIGNATED_INIT here.
(reshape_init_class): And here.
(reshape_init): Not here.

gcc/testsuite/ChangeLog:

* g++.dg/ext/desig4.C: Remove extra errors.
* g++.dg/cpp2a/desig26.C: New test.
---
 gcc/cp/decl.cc   |  6 +-
 gcc/testsuite/g++.dg/cpp2a/desig26.C | 22 ++
 gcc/testsuite/g++.dg/ext/desig4.C|  4 
 3 files changed, 27 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/desig26.C

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 29fc36534c2..aa6cf3c6c2e 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -6505,6 +6505,8 @@ reshape_init_array_1 (tree elt_type, tree max_index, 
reshape_iter *d,
   tree elt_init;
   constructor_elt *old_cur = d->cur;
 
+  if (d->cur->index)
+   CONSTRUCTOR_IS_DESIGNATED_INIT (new_init) = true;
   check_array_designated_initializer (d->cur, index);
   elt_init = reshape_init_r (elt_type, d,
 /*first_initializer_p=*/NULL_TREE,
@@ -6674,6 +6676,7 @@ reshape_init_class (tree type, reshape_iter *d, bool 
first_initializer_p,
}
  else if (TREE_CODE (d->cur->index) == IDENTIFIER_NODE)
{
+ CONSTRUCTOR_IS_DESIGNATED_INIT (new_init) = true;
  field = get_class_binding (type, d->cur->index);
  direct_desig = true;
}
@@ -7158,7 +7161,8 @@ reshape_init (tree type, tree init, tsubst_flags_t 
complain)
 CONSTRUCTOR_IS_DIRECT_INIT (new_init) = true;
   if (CONSTRUCTOR_IS_DESIGNATED_INIT (init)
   && BRACE_ENCLOSED_INITIALIZER_P (new_init))
-CONSTRUCTOR_IS_DESIGNATED_INIT (new_init) = true;
+gcc_checking_assert (CONSTRUCTOR_IS_DESIGNATED_INIT (new_init)
+|| seen_error ());
 
   return new_init;
 }
diff --git a/gcc/testsuite/g++.dg/cpp2a/desig26.C 
b/gcc/testsuite/g++.dg/cpp2a/desig26.C
new file mode 100644
index 000..443fa3d089d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/desig26.C
@@ -0,0 +1,22 @@
+// PR c++/105925
+// { dg-do compile { target c++20 } }
+
+struct V
+{
+int i;
+double d;
+};
+
+struct X
+{
+union
+{
+int x;
+V y;
+};
+};
+
+X foo()
+{
+return {.y = {0, 0.0}};
+}
diff --git a/gcc/testsuite/g++.dg/ext/desig4.C 
b/gcc/testsuite/g++.dg/ext/desig4.C
index 902bd1ff0b6..9b92a6de249 100644
--- a/gcc/testsuite/g++.dg/ext/desig4.C
+++ b/gcc/testsuite/g++.dg/ext/desig4.C
@@ -6,13 +6,9 @@ int a = { .foo = 6 };   // { dg-error "designator" 
}
 int b = { [0] = 1 };// { dg-error "12:designator .0." }
 _Complex float c = { .foo = 0,  1 }; // { dg-error "designator" }
 // { dg-error "either all initializer 
clauses should be designated or none of them should be" "" { target c++2a } .-1 
}
-// { dg-error "cannot convert" "" { target 
*-*-* } .-2 }
 _Complex float d = { [0] = 0,  1 };  // { dg-error "23:designator .0." }
 // { dg-error "either all initializer 
clauses should be designated or none of them should be" "" { target c++2a } .-1 
}
-// { dg-error "cannot convert" "" { target 
*-*-* } .-2 }
 _Complex float e = { 0, .foo = 1 };  // { dg-error "designator" }
 // { dg-error "either all initializer 
clauses should be designated or none of them should be" "" { target c++2a } .-1 
}
-// { dg-error "cannot convert" "" { target 
*-*-* } .-2 }
 _Complex float f = { 0, [0] = 1 };   // { dg-error "26:designator .0." }
 // { dg-error "either all initializer 
clauses should be designated or none of them should be" "" { target c++2a } .-1 
}
-// { dg-error "cannot convert" "" { target 
*-*-* } .-2 }

base-commit: b00b95198e6720eb23a2618870d67800f6180fdd
-- 
2.27.0

Re: [PATCH] fortran, libgfortran: Avoid using libquadmath for glibc 2.26+

[Harald Anlauf via Gcc-patches]

Hi Jakub,

Am 23.06.22 um 14:04 schrieb Jakub Jelinek via Gcc-patches:

Hi!

As mentioned by Joseph in PR105101, glibc 2.26 or later has on x86
(both -m32/-m64), powerpc64le, ia64 and mips support for
*f128 math/complex APIs plus strtof128 and strfromf128, and these APIs allow
us to avoid libquadmath for Fortran purposes on these architectures,
replace *q math/complex APIs, strtof128 instead of strtoflt128 and,
while strfromf128 unfortunately isn't a perfect replacement to
quadmath_snprintf, it can be made to work.

The advantage of this is that when configured against such glibcs
(2.26 is now almost 5 years old), we can avoid linking against an extra shared
library and the math support in glibc is maintained better than libquadmath.

We need both a compiler change (so that for glibc 2.26+ it uses *f128 APIs
instead of *q) and library change.


this is quite an important change in the gfortran ABI, as it will
require recompilation of (library) code using quad precision.
Not that I am particularly affected, but this should be highlighted
for users.

Am I right in assuming that this also effectively fixes PR46539?
(Add -static-libquadmath).


So far lightly tested on x86_64-linux with glibc 2.35 (removed libgfortran
dirs, rebuilt stage3 f951 and make all-target-libgfortran + make
check-gfortran), ok for trunk if it passes full testing?


I did not look into all details, but noticed the following:


--- gcc/fortran/trans-intrinsic.cc.jj   2022-05-16 11:14:57.587427707 +0200
+++ gcc/fortran/trans-intrinsic.cc  2022-06-23 11:42:03.355899271 +0200
@@ -155,7 +155,7 @@ builtin_decl_for_precision (enum built_i
else if (precision == TYPE_PRECISION (double_type_node))
  i = m->double_built_in;
else if (precision == TYPE_PRECISION (long_double_type_node)
-  && (!gfc_real16_is_float128
+  && ((!gfc_real16_is_float128 & !gfc_real16_is__Float128)


Shouldn't this be && instead of & ?


   || long_double_type_node != gfc_float128_type_node))
  i = m->long_double_built_in;
else if (precision == TYPE_PRECISION (gfc_float128_type_node))
@@ -175,7 +175,7 @@ gfc_builtin_decl_for_float_kind (enum bu
  {
int i = gfc_validate_kind (BT_REAL, kind, false);

-  if (gfc_real_kinds[i].c_float128)
+  if (gfc_real_kinds[i].c_float128 || gfc_real_kinds[i].c__Float128)
  {
/* For _Float128, the story is a bit different, because we return
 a decl to a library function rather than a built-in.  */
@@ -688,7 +688,7 @@ gfc_build_intrinsic_lib_fndecls (void)
gfc_intrinsic_map_t *m;
tree quad_decls[END_BUILTINS + 1];

-  if (gfc_real16_is_float128)
+  if (gfc_real16_is_float128 || gfc_real16_is__Float128)
{
  /* If we have soft-float types, we create the decls for their
 C99-like library functions.  For now, we only handle _Float128
@@ -739,7 +739,10 @@ gfc_build_intrinsic_lib_fndecls (void)
 builtin_decl_for_float_type(). The others are all constructed by
 gfc_get_intrinsic_lib_fndecl().  */
  #define OTHER_BUILTIN(ID, NAME, TYPE, CONST) \
-  quad_decls[BUILT_IN_ ## ID] = define_quad_builtin (NAME "q", func_ ## TYPE, 
CONST);
+quad_decls[BUILT_IN_ ## ID]
\
+  = define_quad_builtin (gfc_real16_is__Float128   \
+? NAME "f128" : NAME "q", func_ ## TYPE,   \
+CONST);

  #include "mathbuiltins.def"

@@ -751,8 +754,9 @@ gfc_build_intrinsic_lib_fndecls (void)
  /* There is one built-in we defined manually, because it gets called
 with builtin_decl_for_precision() or builtin_decl_for_float_type()
 even though it is not an OTHER_BUILTIN: it is SQRT.  */
-quad_decls[BUILT_IN_SQRT] = define_quad_builtin ("sqrtq", func_1, true);
-
+quad_decls[BUILT_IN_SQRT]
+  = define_quad_builtin (gfc_real16_is__Float128
+? "sqrtf128" : "sqrtq", func_1, true);
}

/* Add GCC builtin functions.  */
@@ -775,7 +779,7 @@ gfc_build_intrinsic_lib_fndecls (void)
m->complex10_decl
  = builtin_decl_explicit (m->complex_long_double_built_in);

-  if (!gfc_real16_is_float128)
+  if (!gfc_real16_is_float128 && !gfc_real16_is__Float128)
{
  if (m->long_double_built_in != END_BUILTINS)
m->real16_decl = builtin_decl_explicit (m->long_double_built_in);
@@ -876,6 +880,9 @@ gfc_get_intrinsic_lib_fndecl (gfc_intrin
else if (gfc_real_kinds[n].c_float128)
snprintf (name, sizeof (name), "%s%s%s",
  ts->type == BT_COMPLEX ? "c" : "", m->name, "q");
+  else if (gfc_real_kinds[n].c__Float128)
+   snprintf (name, sizeof (name), "%s%s%s",
+ ts->type == BT_COMPLEX ? "c" : "", m->name, "f128");
else
gcc_unreachable ();
  }
--- gcc/fortran/trans-expr.cc.jj2022-04-23 10:10:51.146097072 +0200
+++ gcc/fortran/trans-expr.cc   2022-06-23 11:49:31.191964727 

[Bug c++/105931] [12/13 regression] ICE in cxx_eval_constant_expression

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

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

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

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

commit r13-1225-gb00b95198e6720eb23a2618870d67800f6180fdd
Author: Patrick Palka 
Date:   Thu Jun 23 16:36:43 2022 -0400

c++: constexpr folding in unevaluated context [PR105931]

Changing the type of N from int to unsigned in decltype82.C (from
r13-986-g0ecb6b906f215e) reveals another spot where we perform constexpr
evaluation in an unevaluated context for sake of warnings, this time
from the call to shorten_compare in cp_build_binary_op, which calls
fold_for_warn.

We could (and probably should) suppress the shorten_compare warnings
when in an unevaluated context, but there's probably other callers of
fold_for_warn that are similarly affected.  So this patch takes the
approach of directly suppressing fold_for_warn when in an unevaluated
context.

PR c++/105931

gcc/cp/ChangeLog:

* expr.cc (fold_for_warn): Don't fold when in an unevaluated
context.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/decltype82a.C: New test.

[Bug target/86722] ifcvt produces x&0 that is never cleaned up

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |12.0
 Resolution|--- |FIXED
 CC||roger at nextmovesoftware dot 
com

--- Comment #6 from Roger Sayle  ---
This is now fixed on mainline (and GCC 12).

[Bug c++/105982] [13 Regression] internal compiler error: in lookup_template_class, at cp/pt.cc:10361

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Fixed.

[Bug c++/105982] [13 Regression] internal compiler error: in lookup_template_class, at cp/pt.cc:10361

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

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

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

https://gcc.gnu.org/g:01aff2ba18a654324957af446a3065db489c0f14

commit r13-1224-g01aff2ba18a654324957af446a3065db489c0f14
Author: Patrick Palka 
Date:   Thu Jun 23 16:18:55 2022 -0400

c++: context completion in lookup_template_class [PR105982]

The below testcase demonstrates that completion of the substituted
context during lookup_template_class can end up registering the desired
specialization for us in more cases than r13-1045-gcb7fd1ea85feea
anticipated.  In particular this can happen for a non-dependent
specialization of a nested class as well.

For this testcase, during overload resolution with A's guides, we
substitute the deduced argument T=int into the TYPENAME_TYPE B::C,
during which we call lookup_template_class for A::B with T=int,
which completes A for the first time, which recursively registers
the desired specialization of B already.  The parent call to
lookup_template_class then tries to register the same specialization,
triggering an ICE.

This patch fixes this by making lookup_template_class determine more
directly whether we need to recheck the specializations table after
completion of the context -- when and only when the call to complete_type
had an effect.

PR c++/105982

gcc/cp/ChangeLog:

* pt.cc (lookup_template_class): After calling complete_type for
the substituted context, check the table again iff the type was
previously incomplete and complete_type made it complete.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction111.C: New test.

[Bug target/106068] Infinite loop generated with -mcpu=cortex-m7 and -O2

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Dave Flogeras from comment #2)
> For that code, agreed, and that was indeed both our and upstreams
> workaround.  We were just wondering if it was a legitimate compiler bug
> given that it generated an infinite loop in asm.  Or does it just fall under
> "undefined"

It is undefined if you access an out of bounds in an array. In this case the
compiler assumes there would be no such access and optimizes the range of n
because of the access and then removes the bounds check as the access already
happened.
So yes it is falls under undefined.

[Bug target/106068] Infinite loop generated with -mcpu=cortex-m7 and -O2

[dflogeras2 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Dave Flogeras  ---
(In reply to Andrew Pinski from comment #1)
> You access an out of bounds for the array dhcp_rx_options_given in the while
> statement:
> 
>   while((dhcp_rx_options_given[8 + n] != 0) && (n < 2)) {
> 
> 
> Swap around the two expressions so you check to make sure n is less than 2
> before doing the array access. that is:
> 
>   while((n < 2) && (dhcp_rx_options_given[8 + n] != 0)) {


For that code, agreed, and that was indeed both our and upstreams workaround. 
We were just wondering if it was a legitimate compiler bug given that it
generated an infinite loop in asm.  Or does it just fall under "undefined"

Go patch committed: In Sort_bindings handle same value passed twice

[Ian Lance Taylor via Gcc-patches]

This patch by zhangjian to the Go frontend changes Sort_bindings to
return false if comparing a value to itself.  Apparently some versions
of std::sort may pass elements at the same iterator location.  This
fixes https://go.dev/issue/53483.  Bootstrapped and ran Go testsuite
on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
5ee8e1d1b0c0d9f6310d27a37a6162e0be80e413
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 629bc666dc0..f882812d219 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-6c3752315dc9b82d0f3f3ac646a1e7376818f84a
+6b314f7947b4b31a86c09d166fe6664cd9968824
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/gcc/go/gofrontend/export.cc b/gcc/go/gofrontend/export.cc
index a30b11af31e..7373deee310 100644
--- a/gcc/go/gofrontend/export.cc
+++ b/gcc/go/gofrontend/export.cc
@@ -530,6 +530,9 @@ struct Sort_bindings
   bool
   operator()(const Named_object* n1, const Named_object* n2) const
   {
+if (n1 == n2)
+  return false;
+
 if (n1->package() != n2->package())
   {
if (n1->package() == NULL)

[Bug target/106068] Infinite loop generated with -mcpu=cortex-m7 and -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
You access an out of bounds for the array dhcp_rx_options_given in the while
statement:

  while((dhcp_rx_options_given[8 + n] != 0) && (n < 2)) {


Swap around the two expressions so you check to make sure n is less than 2
before doing the array access. that is:

  while((n < 2) && (dhcp_rx_options_given[8 + n] != 0)) {

[Bug c/106068] New: Infinite loop generated with -mcpu=cortex-m7 and -O2

[dflogeras2 at gmail dot com via Gcc-bugs]

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

Bug ID: 106068
   Summary: Infinite loop generated with -mcpu=cortex-m7 and -O2
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dflogeras2 at gmail dot com
  Target Milestone: ---

Created attachment 53197
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53197=edit
Preprocessed src to reproduce bug

We hit this suspected bug compiling an older firmware after recently upgrading
to a more recent version of GCC.  It can be triggered by 11.3.0, while the old
5.4.x version did not produce the infinite loop.

The code snippet is from a quite old version of LWIP (stripped down to the
minimal).  It appears to not be exiting the loop on the second condition (n<2).

The exact command I used to generate the .i is as follows:

  arm-none-eabi-gcc -mcpu=cortex-m7 src/core/dhcp.c -c -save-temps -g -O2


GCC that it definitely fails on is as follows:

arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-none-eabi/11.3.0/lto-wrapper
Target: arm-none-eabi
Configured with:
/var/tmp/notmpfs/portage/cross-arm-none-eabi/gcc-11.3.0/work/gcc-11.3.0/configure
--host=x86_64-pc-linux-gnu --target=arm-none-eabi --build=x86_64-pc-linux-gnu
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arm-none-eabi/gcc-bin/11.3.0
--includedir=/usr/lib/gcc/arm-none-eabi/11.3.0/include
--datadir=/usr/share/gcc-data/arm-none-eabi/11.3.0
--mandir=/usr/share/gcc-data/arm-none-eabi/11.3.0/man
--infodir=/usr/share/gcc-data/arm-none-eabi/11.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/arm-none-eabi/11.3.0/include/g++-v11
--with-python-dir=/share/gcc-data/arm-none-eabi/11.3.0/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.3.0 p4'
--disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch
--enable-poison-system-directories --disable-libstdcxx-time
--with-sysroot=/usr/arm-none-eabi --disable-bootstrap --with-newlib
--enable-multilib --disable-fixed-point --disable-libgomp --disable-libssp
--disable-libada --disable-cet --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--without-zstd --enable-lto --without-isl --disable-libsanitizer
--disable-default-pie --enable-default-ssp --with-multilib-list=rmprofile
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 11.3.0 (Gentoo 11.3.0 p4)

[Bug analyzer/106066] crash dump when "-fdump-analyzer" enabled

[chipitsine at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Илья Шипицин  ---
another crash using "-fanalyzer-verbose-state-changes"

stacktrace


during IPA pass: analyzer
src/ssl_crtlist.c:523:17: internal compiler error: Segmentation fault
  523 | entry = crtlist_entry_new();
  | ^
0xf3ec3f crash_signal
/home/ilia/gcc/gcc-master/gcc/toplev.cc:322
0x950028 c_tree_printer
/home/ilia/gcc/gcc-master/gcc/c/c-objc-common.cc:305
0x1eea9ef pp_format(pretty_printer*, text_info*)
/home/ilia/gcc/gcc-master/gcc/pretty-print.cc:1475
0x1e65b58 make_label_text(bool, char const*, ...)
/home/ilia/gcc/gcc-master/gcc/analyzer/analyzer.cc:439
0x1e6afc0 ana::state_change_event::get_desc(bool) const
/home/ilia/gcc/gcc-master/gcc/analyzer/checker-path.cc:409
0x1e68232 ana::checker_event::prepare_for_emission(ana::checker_path*,
ana::pending_diagnostic*, diagnostic_event_id_t)
/home/ilia/gcc/gcc-master/gcc/analyzer/checker-path.cc:237
0x1e8622f ana::checker_path::prepare_for_emission(ana::pending_diagnostic*)
/home/ilia/gcc/gcc-master/gcc/analyzer/checker-path.h:652
0x1e8622f ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&)
/home/ilia/gcc/gcc-master/gcc/analyzer/diagnostic-manager.cc:1396
0x1e8a0d3 ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
/home/ilia/gcc/gcc-master/gcc/analyzer/diagnostic-manager.cc:1296
0x1e8677c ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
/home/ilia/gcc/gcc-master/gcc/analyzer/diagnostic-manager.cc:1348
0x12e148a ana::impl_run_checkers(ana::logger*)
/home/ilia/gcc/gcc-master/gcc/analyzer/engine.cc:5846
0x12e230e ana::run_checkers()
/home/ilia/gcc/gcc-master/gcc/analyzer/engine.cc:5906
0x12d1c48 execute
/home/ilia/gcc/gcc-master/gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Go patch committed: unalias types for hash/equality functions

[Ian Lance Taylor via Gcc-patches]

This patch to the Go frontend makes sure to unalias types when
creating hash/equality functions.  This fixes
https://go.dev/issue/52846.  There is a test case at
https://go.dev/cl/413694.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
3e134d9c6716f6acaf3e17458c603c3786003fb2
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 737bc483274..629bc666dc0 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-77821de1a149c2e6ef9c154ae384c16292173039
+6c3752315dc9b82d0f3f3ac646a1e7376818f84a
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/gcc/go/gofrontend/gogo.cc b/gcc/go/gofrontend/gogo.cc
index d35c6baf582..e13df0da22b 100644
--- a/gcc/go/gofrontend/gogo.cc
+++ b/gcc/go/gofrontend/gogo.cc
@@ -2811,7 +2811,7 @@ Specific_type_functions::type(Type* t)
 
 case Type::TYPE_MAP:
   {
-   Type* key_type = t->map_type()->key_type();
+   Type* key_type = t->map_type()->key_type()->unalias();
if (key_type->needs_specific_type_functions(this->gogo_))
  key_type->hash_function(this->gogo_, NULL);
   }
diff --git a/gcc/go/gofrontend/types.cc b/gcc/go/gofrontend/types.cc
index eb3afd94682..39aea769eb2 100644
--- a/gcc/go/gofrontend/types.cc
+++ b/gcc/go/gofrontend/types.cc
@@ -1764,6 +1764,9 @@ Type::needs_specific_type_functions(Gogo* gogo)
 Named_object*
 Type::hash_function(Gogo* gogo, Function_type* hash_fntype)
 {
+  if (this->named_type() != NULL)
+go_assert(!this->named_type()->is_alias());
+
   if (!this->is_comparable())
 return NULL;
 
@@ -2067,6 +2070,9 @@ Type::write_identity_hash(Gogo* gogo, int64_t size)
 Named_object*
 Type::equal_function(Gogo* gogo, Named_type* name, Function_type* equal_fntype)
 {
+  if (this->named_type() != NULL)
+go_assert(!this->named_type()->is_alias());
+
   // If the unaliased type is not a named type, then the type does not
   // have a name after all.
   if (name != NULL)
@@ -6700,7 +6706,8 @@ Struct_type::write_hash_function(Gogo* gogo, 
Function_type* hash_fntype)
   subkey = Expression::make_cast(key_arg_type, subkey, bloc);
 
   // Get the hash function to use for the type of this field.
-  Named_object* hash_fn = pf->type()->hash_function(gogo, hash_fntype);
+  Named_object* hash_fn =
+   pf->type()->unalias()->hash_function(gogo, hash_fntype);
 
   // Call the hash function for the field, passing retval as the seed.
   ref = Expression::make_temporary_reference(retval, bloc);
@@ -7553,8 +7560,8 @@ Array_type::write_hash_function(Gogo* gogo, 
Function_type* hash_fntype)
   gogo->start_block(bloc);
 
   // Get the hash function for the element type.
-  Named_object* hash_fn = this->element_type_->hash_function(gogo,
-hash_fntype);
+  Named_object* hash_fn =
+this->element_type_->unalias()->hash_function(gogo, hash_fntype);
 
   // Get a pointer to this element in the loop.
   Expression* subkey = Expression::make_temporary_reference(key, bloc);
@@ -8441,8 +8448,8 @@ Map_type::do_type_descriptor(Gogo* gogo, Named_type* name)
   ++p;
   go_assert(p->is_field_name("hasher"));
   Function_type* hasher_fntype = p->type()->function_type();
-  Named_object* hasher_fn = this->key_type_->hash_function(gogo,
-  hasher_fntype);
+  Named_object* hasher_fn =
+this->key_type_->unalias()->hash_function(gogo, hasher_fntype);
   if (hasher_fn == NULL)
 vals->push_back(Expression::make_cast(hasher_fntype,
  Expression::make_nil(bloc),

[Bug libstdc++/106067] New: Error on implicit conversion to std::function: 'static constexpr bool std::_Function_handler<...>...' used before its definition

[e.tadeu at gmail dot com via Gcc-bugs]

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

Bug ID: 106067
   Summary: Error on implicit conversion to std::function: 'static
constexpr bool std::_Function_handler<...>...' used
before its definition
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e.tadeu at gmail dot com
  Target Milestone: ---

The following code started failing on GCC 11.3 (also fails on GCC 12):

#include 

double fn();

template )>
void caller()
{
auto f = T(fn);
// auto f = T(std::function(fn));  // workaround (this works)
}


The snippet is also here: https://godbolt.org/z/zh7nr7vKc

The full error is:

In file included from
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/move.h:57,
 from
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/stl_function.h:60,
 from
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/functional:49,
 from :1:
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/type_traits: In
instantiation of 'struct std::is_trivially_copyable':
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:69:12:
  required from 'struct std::__is_location_invariant'
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:125:38:
  required from 'const bool std::_Function_base::_Base_manager::__stored_locally'
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:130:8:
  required from 'class std::_Function_base::_Base_manager'
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:260:11:
  required from 'class std::_Function_handler'
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:436:65:
  required from 'std::function<_Res(_ArgTypes ...)>::function(_Functor&&) [with
_Functor = double (*)(); _Constraints = void; _Res = double; _ArgTypes = {}]'
:8:15:   required from here
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/type_traits:713:52: error:
non-constant condition for static assertion
  713 |  
static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
  |
~~~^~~~
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/type_traits:713:52: error:
'constexpr std::true_type
std::__is_complete_or_unbounded(std::__type_identity<_Tp>) [with _Tp = double
(*)(); long unsigned int  = 8; std::true_type =
std::integral_constant]' used before its definition
In file included from
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/functional:59,
 from :1:
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h: In
instantiation of 'std::function<_Res(_ArgTypes ...)>::function(_Functor&&)
[with _Functor = double (*)(); _Constraints = void; _Res = double; _ArgTypes =
{}]':
:8:15:   required from here
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:436:72:
error: 'static constexpr bool std::_Function_handler<_Res(_ArgTypes ...),
_Functor>::_S_nothrow_init() [with _Fn = double (*)(); _Res = double; _Functor
= double (*)(); _ArgTypes = {}]' used before its definition
  436 | noexcept(_Handler<_Functor>::template
_S_nothrow_init<_Functor>())
  | 
~~^~
ASM generation compiler returned: 1
In file included from
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/move.h:57,
 from
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/stl_function.h:60,
 from
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/functional:49,
 from :1:
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/type_traits: In
instantiation of 'struct std::is_trivially_copyable':
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:69:12:
  required from 'struct std::__is_location_invariant'
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:125:38:
  required from 'const bool std::_Function_base::_Base_manager::__stored_locally'
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:130:8:
  required from 'class std::_Function_base::_Base_manager'
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:260:11:
  required from 'class std::_Function_handler'
   

Re: [PATCH] c++: constexpr folding in unevaluated context [PR105931]

[Jason Merrill via Gcc-patches]

On 6/23/22 11:06, Patrick Palka wrote:

Changing the type of N from int to unsigned in decltype82.C from
r12-8472-g47ea22015c90df reveals another spot where we perform
constexpr evaluation in an unevaluated context for sake of diagnostics,
this time from the call to shorten_compare in cp_build_binary_op,
which calls fold_for_warn.

We could (and probably should?) suppress the shorten_compare diagnostics
when in an unevaluated context, but there's probably other spots
that have the same bug.  So this patch takes the approach of suppressing
fold_for_warn more generally when in an unevaluated context.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/12?


OK.


PR c++/105931

gcc/cp/ChangeLog:

* expr.cc (fold_for_warn): Don't fold when in an unevaluated
context.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/decltype82a.C: New test.
---
  gcc/cp/expr.cc   |  5 +
  gcc/testsuite/g++.dg/cpp0x/decltype82a.C | 11 +++
  2 files changed, 16 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/decltype82a.C

diff --git a/gcc/cp/expr.cc b/gcc/cp/expr.cc
index 31fe0980337..b71245f937d 100644
--- a/gcc/cp/expr.cc
+++ b/gcc/cp/expr.cc
@@ -397,6 +397,11 @@ fold_for_warn (tree x)
  {
/* C++ implementation.  */
  
+  if (cp_unevaluated_operand)

+/* In an unevaluated context, we don't care about the reduced value
+   of an expression, so neither should any warnings.  */
+return x;
+
/* Prevent warning-dependent constexpr evaluation from changing
   DECL_UID (which breaks -fcompare-debug) and from instantiating
   templates.  */
diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype82a.C 
b/gcc/testsuite/g++.dg/cpp0x/decltype82a.C
new file mode 100644
index 000..cbbcdfd8e58
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/decltype82a.C
@@ -0,0 +1,11 @@
+// PR c++/105931
+// { dg-do compile { target c++11 } }
+// A version of decltype82.C where N is unsigned.
+
+template
+void f() {
+  using ty1 = decltype((5 % N) == 0);
+  using ty2 = decltype((5 / N) == 0);
+}
+
+template void f<0>();

Re: [PATCH] c++: context completion in lookup_template_class [PR105982]

[Jason Merrill via Gcc-patches]

On 6/23/22 10:48, Patrick Palka wrote:

The below testcase demonstrates that completion of the substituted
context during lookup_template_class can end up registering the desired
specialization for us in more cases than r13-1045-gcb7fd1ea85feea
anticipated.  In particular, it can happen for a non-dependent
specialization of a nested class as well.

During overload resolution with A's guides, we substitute the deduced
argument T=int into the TYPENAME_TYPE B::C (*).  This substitution calls
lookup_template_class for A::B with T=int, which completes A
for the first time, which recursively registers the desired specialization
of B for us.  The parent call to lookup_template_class then tries
registering the same specialization, which leads to a crash.

This patch fixes this by making lookup_template_class check the
specializations table after completion of the context iff necessary,
i.e. when the call to complete_type actually has an effect.

(*): Note that the TYPE_CONTEXT of this TYPENAME_TYPE is just the
RECORD_TYPE B instead of TYPENAME_TYPE A::B.  Is this expected?
I'd think maybe_dependent_member_ref would rewrite the reference to B
in terms of another TYPENAME_TYPE.  This is why the testcase needs to
use 'typename B::C' instead of just 'B' -- maybe_dependent_member_ref
rewrites the use of B in the latter case but not the former.


Hmm, perhaps maybe_dependent_member_ref needs to consider rewriting ctx 
as well.



Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?


OK.


PR c++/105982

gcc/cp/ChangeLog:

* pt.cc (lookup_template_class): After completion of the
substituted context, check the table again iff the type was
previously incomplete and complete_type made it complete.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction111.C: New test.
---
  gcc/cp/pt.cc  | 21 +++
  .../g++.dg/cpp1z/class-deduction111.C | 10 +
  2 files changed, 22 insertions(+), 9 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1z/class-deduction111.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 28edc6ae988..eeae867a816 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -10089,16 +10089,19 @@ lookup_template_class (tree d1, tree arglist, tree 
in_decl, tree context,
{
  context = tsubst_aggr_type (context, arglist,
  complain, in_decl, true);
- context = complete_type (context);
- if (is_dependent_type && arg_depth > 1)
+ /* Try completing the enclosing context if it's not already so.  
*/
+ if (context != error_mark_node
+ && !COMPLETE_TYPE_P (context))
{
+ context = complete_type (context);
+ if (COMPLETE_TYPE_P (context))
+   {
+ /* Completion could have caused us to register the desired
+specialization for us, so check the table again.  */
+ entry = type_specializations->find_with_hash (, hash);
+ if (entry)
+   return entry->spec;
+   }
}
}
}
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction111.C 
b/gcc/testsuite/g++.dg/cpp1z/class-deduction111.C
new file mode 100644
index 000..2406529ea5a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction111.C
@@ -0,0 +1,10 @@
+// PR c++/105982
+// { dg-do compile { target c++17 } }
+
+template
+struct A {
+  struct B { struct C { }; };
+  A(T, typename B::C);
+};
+
+A a(0, {});

Re: [PATCH v3] rs6000: Adjust mov optabs for opaque modes [PR103353]

[Segher Boessenkool]

Hi!

On Wed, May 18, 2022 at 10:07:48PM +0800, Kewen.Lin wrote:
> As PR103353 shows, we may want to continue to expand a MMA built-in
> function like a normal function, even if we have already emitted
> error messages about some missing required conditions.  As shown in
> that PR, without one explicit mov optab on OOmode provided, it would
> call emit_move_insn recursively.

First off: lxvp is a VSX insn, not an MMA insn.  So please don't call it
that -- this confusion is what presumably caused the problem here, so it
would be good to root it out :-)

> +  /* Opaque modes are only expected to be available when MMA is supported,

Why do people expect that?  It is completely wrong.  The name "opaque"
itself already says this is not just for MMA, but perhaps more
importantly, it is a basic VSX insn, doesn't touch any MMA resources,
and is useful in other contexts as well.

So this needs some bigger surgery.


Segher

Re: [PATCH 01/12] diagnostics: add ability to associate diagnostics with rules from coding standards

[David Malcolm via Gcc-patches]

On Wed, 2022-06-22 at 18:34 -0400, David Malcolm wrote:
> gcc/ChangeLog:
> * common.opt (fdiagnostics-show-rules): New option.
> * diagnostic-format-json.cc
> (diagnostic_output_format_init_json):
> Fix up context->show_rules.
> * diagnostic-format-sarif.cc
> (diagnostic_output_format_init_sarif): Likewise.
> * diagnostic-metadata.h (diagnostic_metadata::rule): New
> class.
> (diagnostic_metadata::precanned_rule): New class.
> (diagnostic_metadata::add_rule): New.
> (diagnostic_metadata::get_num_rules): New.
> (diagnostic_metadata::get_rule): New.
> (diagnostic_metadata::m_rules): New field.
> * diagnostic.cc (diagnostic_initialize): Initialize
> show_rules.
> (print_any_rules): New.
> (diagnostic_report_diagnostic): Call it.
> * diagnostic.h (diagnostic_context::show_rules): New field.
> * doc/invoke.texi (-fno-diagnostics-show-rules): New option.
> * opts.cc (common_handle_option): Handle
> OPT_fdiagnostics_show_rules.
> * toplev.cc (general_init): Set up global_dc->show_rules.
> 
> gcc/testsuite/ChangeLog:
> * gcc.dg/plugin/diagnostic-test-metadata.c: Expect " [STR34-
> C]" to
> be emitted at the "gets" call.
> * gcc.dg/plugin/diagnostic_plugin_test_metadata.c
> (pass_test_metadata::execute): Associate the "gets"
> diagnostic
> with a rule named "STR34-C".
> 
> Signed-off-by: David Malcolm 

This one seems potentially useful to plugin authors without the rest of
the patch kit, so I've pushed it to trunk as: r13-1221-g0b14f590e3e9d9
(after a successful bootstrap & regression test on x86_64-pc-linux-gnu)

Dave

[Bug analyzer/106066] New: crash dump when "-fdump-analyzer" enabled

[chipitsine at gmail dot com via Gcc-bugs]

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

Bug ID: 106066
   Summary: crash dump when "-fdump-analyzer" enabled
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: chipitsine at gmail dot com
  Target Milestone: ---

reproduce steps (using latest gcc13 from git):


git clone https://github.com/haproxy/haproxy
cd haproxy

export CC=/path/to/latest/gcc13
export ADDITIONAL_CFLAGS="-fanalyzer -fdump-analyzer"


QUICTLS=yes scripts/build-ssl.sh
make -j3 CC=$CC V=1 ERR=1 TARGET=linux-glibc USE_OPENSSL=1 USE_QUIC=1
USE_ZLIB=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_LUA=1 USE_SYSTEMD=1
ADDLIB="-Wl,-rpath,${HOME}/opt/lib" SSL_LIB=${HOME}/opt/lib
SSL_INC=${HOME}/opt/include DEBUG_CFLAGS="-g ${ADDITIONAL_CFLAGS}"




stacktrace:

during IPA pass: analyzer
src/ev_epoll.c: In function ‘_do_poll’:
src/ev_epoll.c:239:55: internal compiler error: Segmentation fault
  239 | ((e & EPOLLERR)   ? FD_EV_ERR_RW  : 0);
  | ~~^~~~
0xf3ec3f crash_signal
/home/ilia/gcc/gcc-master/gcc/toplev.cc:322
0x101a64c tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/ilia/gcc/gcc-master/gcc/tree.h:3638
0x101a64c dump_mem_ref
/home/ilia/gcc/gcc-master/gcc/tree-pretty-print.cc:1700
0x100ff3f dump_generic_node(pretty_printer*, tree_node*, int, dump_flag, bool)
/home/ilia/gcc/gcc-master/gcc/tree-pretty-print.cc:2061
0x1011554 dump_generic_node(pretty_printer*, tree_node*, int, dump_flag, bool)
/home/ilia/gcc/gcc-master/gcc/tree-pretty-print.cc:2425
0x1014d46 dump_generic_node(pretty_printer*, tree_node*, int, dump_flag, bool)
/home/ilia/gcc/gcc-master/gcc/tree-pretty-print.cc:2910
0x12faef9 ana::dump_tree(pretty_printer*, tree_node*)
/home/ilia/gcc/gcc-master/gcc/analyzer/region-model.cc:87
0x12faef9 ana::dump_quoted_tree(pretty_printer*, tree_node*)
/home/ilia/gcc/gcc-master/gcc/analyzer/region-model.cc:97
0x12ed6f9 ana::sm_state_map::print(ana::region_model const*, bool, bool,
pretty_printer*) const
/home/ilia/gcc/gcc-master/gcc/analyzer/program-state.cc:242
0x12ef45e ana::program_state::dump_to_pp(ana::extrinsic_state const&, bool,
bool, pretty_printer*) const
/home/ilia/gcc/gcc-master/gcc/analyzer/program-state.cc:901
0x12f0283 ana::program_state::detect_leaks(ana::program_state const&,
ana::program_state const&, ana::svalue const*, ana::extrinsic_state const&,
ana::region_model_context*)
/home/ilia/gcc/gcc-master/gcc/analyzer/program-state.cc:1366
0x12f0986 ana::program_state::prune_for_point(ana::exploded_graph&,
ana::program_point const&, ana::exploded_node*, ana::uncertainty_t*) const
/home/ilia/gcc/gcc-master/gcc/analyzer/program-state.cc:1214
0x12de456 ana::exploded_graph::process_node(ana::exploded_node*)
/home/ilia/gcc/gcc-master/gcc/analyzer/engine.cc:3822
0x12df0fa ana::exploded_graph::process_worklist()
/home/ilia/gcc/gcc-master/gcc/analyzer/engine.cc:3240
0x12e1467 ana::impl_run_checkers(ana::logger*)
/home/ilia/gcc/gcc-master/gcc/analyzer/engine.cc:5832
0x12e2295 ana::run_checkers()
/home/ilia/gcc/gcc-master/gcc/analyzer/engine.cc:5906
0x12d1c48 execute
/home/ilia/gcc/gcc-master/gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/99963] [11 Regression] [concepts] template vs concept auto reports ambiguous overload

[tabloid.adroit at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Yuanfang Chen  ---
(In reply to Yuanfang Chen from comment #4)
> (In reply to Patrick Palka from comment #1)
> > Started with r11-1571.  Reduced testcase that replaces the abbreviated
> > function templates with their corresponding non-abbreviated forms:
> > 
> > template  concept C1 = true;
> > template  concept C2 = C1 && true;
> > 
> > template  int f(T, U);
> > template  int f(U, T);
> > 
> > int x = f(0, 0); // error: ambiguous call
> > 
> > 
> > If I understand the wording of P2113 correctly:
> > 
> >   If deduction against the other template succeeds for both transformed
> > templates, constraints can be considered as follows:
> >   - ... if the corresponding template-parameters of the
> > template-parameter-lists are not equivalent ([temp.over.link]) or if the
> > function parameters that positionally correspond between the two templates
> > are not of the same type, neither template is more specialized than the 
> > other
> > 
> > then I think we're correct to reject the call as ambiguous because although
> > the second overload is more constrained than the first, their function
> > parameter lists aren't equivalent.
> 
> IMHO, `template  int f(U, T);` should win over `template  C1 U> int f(T, U);`.
> 
> Based on interpreting the intent mentioned in
> https://github.com/cplusplus/nbballot/issues/119 and the second example in
> https://eel.is/c++draft/temp.fct#temp.func.order-example-6, the
> `corresponding` (of the `corresponding template-parameters of ...`)
> relationship is based on the mapping used during partial-ordering deduction.
> So the deduction between `f(T, ..)` against `f(U, ..)` builds the 
> mapping, the deduction between `f(.., U)` against `f(.., T)` builds the  T> mapping. The correspondence is [T, U] against [U, T]. So `C1 T` is less
> constrained than `C2 U`, thus the second `f` wins.

Sorry. I spoke too soon. Template parameters reordering is not allowed for the
test case. The call is indeed ambiguous.

[PATCH] analyzer PR 106003

[Mir Immad via Gcc]

diff --git gcc/Makefile.in gcc/Makefile.in
index b6dcc45a58a..04631f737ea 100644
--- gcc/Makefile.in
+++ gcc/Makefile.in
@@ -1269,6 +1269,7 @@ ANALYZER_OBJS = \
  analyzer/region-model-reachability.o \
  analyzer/sm.o \
  analyzer/sm-file.o \
+ analyzer/sm-fd.o \
  analyzer/sm-malloc.o \
  analyzer/sm-pattern-test.o \
  analyzer/sm-sensitive.o \
diff --git gcc/analyzer/analyzer.opt gcc/analyzer/analyzer.opt
index 23dfc797cea..e2a629bb42c 100644
--- gcc/analyzer/analyzer.opt
+++ gcc/analyzer/analyzer.opt
@@ -66,6 +66,26 @@ Wanalyzer-exposure-through-output-file
 Common Var(warn_analyzer_exposure_through_output_file) Init(1) Warning
 Warn about code paths in which sensitive data is written to a file.

+Wanalyzer-fd-access-mode-mismatch
+Common Var(warn_analyzer_fd_mode_mismatch) Init(1) Warning
+Warn about code paths in which read on write-only file descriptor is
attempted, or vice versa.
+
+Wanalyzer-fd-double-close
+Common Var(warn_analyzer_fd_double_close) Init(1) Warning
+Warn about code paths in which a file descriptor can be closed more than
once.
+
+Wanalyzer-fd-leak
+Common Var(warn_analyzer_fd_leak) Init(1) Warning
+Warn about code paths in which a file descriptor is not closed.
+
+Wanalyzer-fd-use-after-close
+Common Var(warn_analyzer_fd_use_after_close) Init(1) Warning
+Warn about code paths in which a read or write is performed on a closed
file descriptor.
+
+Wanalyzer-fd-use-without-check
+Common Var(warn_analyzer_fd_use_without_check) Init(1) Warning
+warn about code paths in which a possibly invalid file descriptor is
passed to a must-be-a-valid file descriptor function argument.
+
 Wanalyzer-file-leak
 Common Var(warn_analyzer_file_leak) Init(1) Warning
 Warn about code paths in which a stdio FILE is not closed.
diff --git gcc/analyzer/sm-fd.cc gcc/analyzer/sm-fd.cc
new file mode 100644
index 000..048014d7a26
--- /dev/null
+++ gcc/analyzer/sm-fd.cc
@@ -0,0 +1,770 @@
+/* A state machine for detecting misuses of POSIX file descriptor APIs.
+   Copyright (C) 2019-2022 Free Software Foundation, Inc.
+   Contributed by Immad Mir .
+
+This file is part of GCC.
+
+GCC 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.
+
+GCC 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 GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tree.h"
+#include "function.h"
+#include "basic-block.h"
+#include "gimple.h"
+#include "options.h"
+#include "diagnostic-path.h"
+#include "diagnostic-metadata.h"
+#include "function.h"
+#include "json.h"
+#include "analyzer/analyzer.h"
+#include "diagnostic-event-id.h"
+#include "analyzer/analyzer-logging.h"
+#include "analyzer/sm.h"
+#include "analyzer/pending-diagnostic.h"
+#include "analyzer/function-set.h"
+#include "analyzer/analyzer-selftests.h"
+#include "tristate.h"
+#include "selftest.h"
+#include "analyzer/call-string.h"
+#include "analyzer/program-point.h"
+#include "analyzer/store.h"
+#include "analyzer/region-model.h"
+
+#include 
+#if ENABLE_ANALYZER
+
+namespace ana
+{
+
+namespace
+{
+
+/* An enum for distinguishing between three different access modes. */
+
+enum access_mode
+{
+  READ_WRITE,
+  READ_ONLY,
+  WRITE_ONLY
+};
+
+class fd_state_machine : public state_machine
+{
+public:
+  fd_state_machine (logger *logger);
+
+  bool
+  inherited_state_p () const final override
+  {
+return false;
+  }
+
+  state_machine::state_t
+  get_default_state (const svalue *sval) const final override
+  {
+if (tree cst = sval->maybe_get_constant ())
+  {
+int val = TREE_INT_CST_LOW (cst);
+if (val < 0)
+  {
+return m_invalid;
+  }
+  }
+return m_start;
+  }
+
+  bool on_stmt (sm_context *sm_ctxt, const supernode *node,
+const gimple *stmt) const final override;
+
+  void on_condition (sm_context *sm_ctxt, const supernode *node,
+ const gimple *stmt, const svalue *lhs, const
tree_code op,
+ const svalue *rhs) const final override;
+
+  bool can_purge_p (state_t s) const final override;
+  pending_diagnostic *on_leak (tree var) const final override;
+
+  bool is_unchecked (state_t s) const;
+  bool is_valid (state_t s) const;
+  const char *get_string_for_access_mode (enum access_mode) const;
+  enum access_mode get_access_mode_from_flag (int flag) const;
+  enum access_mode get_access_mode_from_state (state_t s) const;
+  bool check_for_closed_fd (state_t s) const;
+
+  /* States representing a file descriptor that hasn't yet been
+  

Re: [PATCH] static analysis support for posix file desccriptor APIs

[Mir Immad via Gcc]

 Hi Dave,
Thanks for the suggestions,

I changed most of the things that you suggested, however reporting for
warnings like close of known invalid fd was problematic:

consider the following code:

if (fd >= 0)
{ write (fd,...); }
close(fd);

As I was checking the exploded graph for this; the "close(fd)" stmt when
visited by the FALSE edge of if stmt (fd < 0) finds fd to be in m_invalid
state; hence warns about "close on known invalid fd" which I believe is not
true as fd at that point is not *known* to be invalid. I spent quite some
time on this and decided not to add this diagnosis for now.

Also, when close transitions m_invalid to m_close; this leads to double
close even when the second close is outside the ( < 0 ) condition which
again does not seem right.
if (fd < 0)
close(fd):
close(fd); // double close here.

> Maybe consolidate on_read and on_write by adding a subroutine that
> checks for m_closed, and for checking access mode (maybe a
> "check_for_open_fd" that takes an access mode enum value amongst other
> params.  If you pass around caller_fndecl, I think much of this code
> can be shared that way between on_read and on_write (which will help
> simplify things if we want to support further functions)

I hope I got this right.


> > +}
> > +}
> > +  else
> > +{
>  >+  /* FIXME: add leak reporting */

> Do you have a testcase that exhibits this behavior?

I was thinking of the following case:
void test()
{
 open(..);
}
Here the resources are leaked because there is no way to free them.

In "read" and "write" funcs, I'm warning for unchecked_use_of_fd and
access_mode_mismatch only when we know fd is not in closed state.
Otherwise, such code leads to lot of irrelevant warnings, example:

void test1(const char *path, void *buf) {
  int fd = open(path, O_RDONLY);
  if (fd >= 0)
  {
  close(fd);
  read(fd, buf, 1); // read on closed fd + read on possibly invalid fd
  write(fd, buf, 1); // write on closed fd + write on possibly invlid fd
  }
}


Adding docs for new options still remains pending. I added some new tests;
and all tests are passing. The stuff about O_* macros is left as-is.

 I'm sending a patch in another email.

Thanks a lot.

On Wed, Jun 22, 2022 at 12:04 AM David Malcolm  wrote:

> Hi Immad, thanks for this patch.
>
> Overall, looks like you're making good progress.
>
> Various notes and nitpicks inline below, throughout...
>
> On Tue, 2022-06-21 at 22:00 +0530, Mir Immad wrote:
>
> [...snip...]
>
> >
> > diff --git a/gcc/analyzer/analyzer.opt b/gcc/analyzer/analyzer.opt
> > index 23dfc797cea..d99acfbb069 100644
> > --- a/gcc/analyzer/analyzer.opt
> > +++ b/gcc/analyzer/analyzer.opt
> > @@ -54,6 +54,10 @@ The minimum number of supernodes within a function
> > for
> > the analyzer to consider
> >  Common Joined UInteger Var(param_analyzer_max_enodes_for_full_dump)
> > Init(200) Param
> >  The maximum depth of exploded nodes that should appear in a dot dump
> > before switching to a less verbose format.
>
> I'm not yet sure if this is a good idea, but I wonder if all of these
> warnings ought to have a "-Wanalyzer-fd-" prefix?  "file-descriptor" is
> rather long, and the analyzer's warnings are already tending to be on
> the long side, and having a consistent prefix might make it easier for
> users to grok them.
>
> (though this feels like a "what color do we paint the bikeshed?" issue;
> see e.g. https://bikeshed.org/ )
>
> >
> > +Wanalyzer-double-close
> > +Common Var(warn_analyzer_double_close) Init(1) Warning
> > +Warn about code paths in which a file descriptor can be closed more
> > than
> > once.
>
> ...so this could be Wanalyzer-fd-double-close
>
> > +
> >  Wanalyzer-double-fclose
> >  Common Var(warn_analyzer_double_fclose) Init(1) Warning
> >  Warn about code paths in which a stdio FILE can be closed more than
> > once.
> > @@ -66,6 +70,10 @@ Wanalyzer-exposure-through-output-file
> >  Common Var(warn_analyzer_exposure_through_output_file) Init(1) Warning
> >  Warn about code paths in which sensitive data is written to a file.
> >
> > +Wanalyzer-file-descriptor-leak
> > +Common Var(warn_analyzer_file_descriptor_leak) Init(1) Warning
> > +Warn about code paths in which a file descriptor is not closed.
>
> ...and Wanalyzer-fd-leak
>
> > +
> >  Wanalyzer-file-leak
> >  Common Var(warn_analyzer_file_leak) Init(1) Warning
> >  Warn about code paths in which a stdio FILE is not closed.
> > @@ -82,6 +90,14 @@ Wanalyzer-mismatching-deallocation
> >  Common Var(warn_analyzer_mismatching_deallocation) Init(1) Warning
> >  Warn about code paths in which the wrong deallocation function is
> > called.
> >
> > +Wanalyzer-mismatching-operation-on-file-descriptor
> > +Common Var(warn_analyzer_mismatching_operation_on_file_descriptor)
> > Init(1)
> > Warning
> > +Warn about the code paths in which read on write-only file descriptor
> > or
> > write on read-only file descriptor is called.
>
> Maybe:
>   Wanalyzer-fd-access-mode-mismatch
> ?
>
> Lose the "the" in "the code 

Re: [PATCH] libstdc++-v3: check for openat

[Jonathan Wakely via Gcc-patches]

On Thu, 23 Jun 2022 at 15:05, Alexandre Oliva  wrote:
>
> On Jun 23, 2022, Jonathan Wakely  wrote:
>
> > On Thu, 23 Jun 2022 at 12:08, Alexandre Oliva  wrote:
> >>
> >> On Jun 22, 2022, Jonathan Wakely  wrote:
> >>
> >> > There are other interactions between AT_CDCWD and ::openat not covered
> >> > by this patch. I this this also needs to check HAVE_OPENAT:
> >>
> >> Here's an updated version, tested with this additional change.
>
> > Did this improve your test results for directory iterators?
>
> 'fraid the bad results I posted earlier today had this patch in.  I
> can't tell whether it improved anything because I didn't save earlier
> results to compare.
>
> > In the unlikely even that the target has ::unlinkat but not ::openat
>
> c++config.h on the target says:
>
> /* #undef _GLIBCXX_HAVE_UNLINKAT */
>
> Thanks for the concern,


Here's what I'm thinking of so that the derived _Dir class doesn't
need to know whether the base _Dir_base::openat function will actually
use ::openat or not.

It defines a new _At_path type which contains a {fd, path} pair (to be
used together by openat and unlinkat) and a separate path to be used
on its own. This allows identifying a file within a directory
unambiguously, without being concerned with whether HAVE_OPENAT and
HAVE_UNLINKAT are defined.

With this change I don't think your patch to make dir_and_pathname()
check HAVE_OPENAT is needed.

This passes tests on x86_64-linux.
diff --git a/libstdc++-v3/src/c++17/fs_dir.cc b/libstdc++-v3/src/c++17/fs_dir.cc
index c67fe76bc14..fb752239e1f 100644
--- a/libstdc++-v3/src/c++17/fs_dir.cc
+++ b/libstdc++-v3/src/c++17/fs_dir.cc
@@ -46,7 +46,7 @@ struct fs::_Dir : _Dir_base
 {
   _Dir(const fs::path& p, bool skip_permission_denied, bool nofollow,
[[maybe_unused]] bool filename_only, error_code& ec)
-  : _Dir_base(fdcwd(), p.c_str(), skip_permission_denied, nofollow, ec)
+  : _Dir_base(p.c_str(), skip_permission_denied, nofollow, ec)
   {
 #if _GLIBCXX_HAVE_DIRFD
 if (filename_only)
@@ -120,15 +120,15 @@ struct fs::_Dir : _Dir_base
   // Return a file descriptor for the directory and current entry's path.
   // If dirfd is available, use it and return only the filename.
   // Otherwise, return AT_FDCWD and return the full path.
-  pair
+  _At_path
   dir_and_pathname() const noexcept
   {
 const fs::path& p = entry.path();
 #if _GLIBCXX_HAVE_DIRFD
 if (!p.empty())
-  return {::dirfd(this->dirp), std::prev(p.end())->c_str()};
+  return {::dirfd(this->dirp), std::prev(p.end())->c_str(), p.c_str()};
 #endif
-return {this->fdcwd(), p.c_str()};
+return p.c_str();
   }
 
   // Create a new _Dir for the directory this->entry.path().
@@ -136,8 +136,7 @@ struct fs::_Dir : _Dir_base
   open_subdir(bool skip_permission_denied, bool nofollow,
  error_code& ec) const noexcept
   {
-auto [dirfd, pathname] = dir_and_pathname();
-_Dir_base d(dirfd, pathname, skip_permission_denied, nofollow, ec);
+_Dir_base d(dir_and_pathname(), skip_permission_denied, nofollow, ec);
 // If this->path is empty, the new _Dir should have an empty path too.
 const fs::path& p = this->path.empty() ? this->path : this->entry.path();
 return _Dir(std::move(d), p);
@@ -147,7 +146,7 @@ struct fs::_Dir : _Dir_base
   do_unlink(bool is_directory, error_code& ec) const noexcept
   {
 #if _GLIBCXX_HAVE_UNLINKAT
-auto [dirfd, pathname] = dir_and_pathname();
+auto [dirfd, pathname, _] = dir_and_pathname();
 if (::unlinkat(dirfd, pathname, is_directory ? AT_REMOVEDIR : 0) == -1)
   {
ec.assign(errno, std::generic_category());
diff --git a/libstdc++-v3/src/filesystem/dir-common.h 
b/libstdc++-v3/src/filesystem/dir-common.h
index 365fd527f4d..5f7f4909ad3 100644
--- a/libstdc++-v3/src/filesystem/dir-common.h
+++ b/libstdc++-v3/src/filesystem/dir-common.h
@@ -91,12 +91,37 @@ is_permission_denied_error(int e)
 
 struct _Dir_base
 {
+  struct _At_path
+  {
+_At_path(const char* p) noexcept
+: dir_fd(fdcwd()), path_from_dir(p), pathname(p)
+{ }
+
+_At_path(int fd, const char* p1, const char* p2)
+: dir_fd(fd), path_from_dir(p1), pathname(p2)
+{ }
+
+int dir_fd; // A directory descriptor (either the parent dir, or AT_FDCWD).
+const posix::char_type* path_from_dir; // Path relative to dir_fd.
+const posix::char_type* pathname; // Full path relative to CWD.
+
+static constexpr int
+fdcwd() noexcept
+{
+#ifdef AT_FDCWD
+  return AT_FDCWD;
+#else
+  return -1; // Use invalid fd if AT_FDCWD isn't supported.
+#endif
+}
+  };
+
   // If no error occurs then dirp is non-null,
   // otherwise null (even if a permission denied error is ignored).
-  _Dir_base(int fd, const posix::char_type* pathname,
+  _Dir_base(const _At_path& atp,
bool skip_permission_denied, bool nofollow,
error_code& ec) noexcept
-  : dirp(_Dir_base::openat(fd, pathname, nofollow))
+  : dirp(_Dir_base::openat(atp, nofollow))
   {
 if (dirp)
 

[Bug testsuite/106059] [13 regression] cc.dg/vect/pr79347.c fails after r13-1171-g9f55aee9dca759

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Mine.

Ping^2: [PATCH v2] diagnostics: Honor #pragma GCC diagnostic in the preprocessor [PR53431]

[Lewis Hyatt via Gcc-patches]

Hello-

https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431#c49

Would a C++ maintainer have some time to take a look at this patch
please? I feel like the PR is still worth resolving. If this doesn't
seem like a good way, I am happy to try another -- would really
appreciate any feedback. Thanks!

-Lewis

On Tue, May 24, 2022 at 5:28 PM Lewis Hyatt  wrote:
>
> Hello-
>
> Now that we're back in stage 1, I thought it might be a better time to
> ask for feedback on this pair of patches that tries to resolve PR53431
> please?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587357.html
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587358.html
>
> Part 1/2 is a trivial cleanup in the C++ parser that simplifies
> adding the support for early pragma handling.
>
> Part 2/2 adds the concept of early pragma handling and makes the C++
> and preprocessor frontends use it.
>
> The patches required some minor rebasing, so I have attached updated
> versions here.
>
> bootstrap + regtest all languages still looks good:
>
> FAIL 103 103
> PASS 541178 541213
> UNSUPPORTED 15177 15177
> UNTESTED 136 136
> XFAIL 4140 4140
> XPASS 17 17
>
> Thanks! If this approach doesn't seem like the right one, I am happy
> to try another way.
>
> -Lewis
>
>
> On Fri, Dec 24, 2021 at 04:23:08PM -0500, Lewis Hyatt wrote:
> > Hello-
> >
> > I would like please to follow up on this patch submitted for PR53431 here:
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586191.html
> >
> > However, it was suggested on the PR that part of it could be split into a
> > separate simpler patch. I have now done that, and also made a few tweaks to
> > the first version at the same time, so may I please request that you review
> > this version 2 instead? This email contains the first smaller cleanup patch,
> > and the next email contains the main part of it. Thanks very much.
> >
> > bootstrap and regtest were performed on x86-64 Linux, all tests look the 
> > same
> > before + after, plus the new passing testcases.
> >
> > FAIL 112 112
> > PASS 528007 528042
> > UNSUPPORTED 14888 14888
> > UNTESTED 132 132
> > XFAIL 3238 3238
> > XPASS 17 17
> >
> > -Lewis
>
> > From: Lewis Hyatt 
> > Date: Thu, 23 Dec 2021 17:03:04 -0500
> > Subject: [PATCH] c++: Minor cleanup in parser.c
> >
> > The code to determine whether a given token starts a module directive is
> > currently repeated in 4 places in parser.c. I am about to submit a patch
> > that needs to add it in a 5th place, so since the code is not completely
> > trivial (needing to check for 3 different token types), it seems worthwhile
> > to factor this logic into its own function.
> >
> > gcc/cp/ChangeLog:
> >
> >   * parser.c (cp_token_is_module_directive): New function
> >   refactoring common code.
> >   (cp_parser_skip_to_closing_parenthesis_1): Use the new function.
> >   (cp_parser_skip_to_end_of_statement): Likewise.
> >   (cp_parser_skip_to_end_of_block_or_statement): Likewise.
> >   (cp_parser_declaration): Likewise.
> >
> > diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> > index 33fb40a5b59..9b7446655be 100644
> > --- a/gcc/cp/parser.c
> > +++ b/gcc/cp/parser.c
> > @@ -629,6 +629,16 @@ cp_lexer_alloc (void)
> >return lexer;
> >  }
> >
> > +/* Return TRUE if token is the start of a module declaration that will be
> > +   terminated by a CPP_PRAGMA_EOL token.  */
> > +static inline bool
> > +cp_token_is_module_directive (cp_token *token)
> > +{
> > +  return token->keyword == RID__EXPORT
> > +|| token->keyword == RID__MODULE
> > +|| token->keyword == RID__IMPORT;
> > +}
> > +
> >  /* Create a new main C++ lexer, the lexer that gets tokens from the
> > preprocessor.  */
> >
> > @@ -3805,9 +3815,7 @@ cp_parser_skip_to_closing_parenthesis_1 (cp_parser 
> > *parser,
> > break;
> >
> >   case CPP_KEYWORD:
> > -   if (token->keyword != RID__EXPORT
> > -   && token->keyword != RID__MODULE
> > -   && token->keyword != RID__IMPORT)
> > +   if (!cp_token_is_module_directive (token))
> >   break;
> > /* FALLTHROUGH  */
> >
> > @@ -3908,9 +3916,7 @@ cp_parser_skip_to_end_of_statement (cp_parser* parser)
> > break;
> >
> >   case CPP_KEYWORD:
> > -   if (token->keyword != RID__EXPORT
> > -   && token->keyword != RID__MODULE
> > -   && token->keyword != RID__IMPORT)
> > +   if (!cp_token_is_module_directive (token))
> >   break;
> > /* FALLTHROUGH  */
> >
> > @@ -3997,9 +4003,7 @@ cp_parser_skip_to_end_of_block_or_statement 
> > (cp_parser* parser)
> > break;
> >
> >   case CPP_KEYWORD:
> > -   if (token->keyword != RID__EXPORT
> > -   && token->keyword != RID__MODULE
> > -   && token->keyword != RID__IMPORT)
> > +   if (!cp_token_is_module_directive (token))
> >   break;
> > /* FALLTHROUGH  */
> >
> > @@ -14860,9 +14864,7 @@ 

Re: [PATCH] RISC-V: Split unordered FP comparisons into individual RTL insns

[Kito Cheng via Gcc-patches]

Hi Maciej:

Thanks for detail analysis and performance number report, I am concern
about this patch might let compiler schedule the fsflags/frflags with
other floating point instructions, and the major issue is we didn't
model fflags right in GCC as you mentioned in the first email.

So I think we should model this right before we split that, I guess
that would be a bunch of work:
1. Add fflags to the hard register list.
2. Add (clobber (reg fflags)) or (set (reg fflags) (fpop
(operands...))) to those floating point operations which might change
fflags
3. Rewrite riscv_frflags and riscv_fsflags pattern by right RTL
pattern: (set (reg) (reg fflags)) and (set (reg fflags) (reg)).
4. Then split *f_quiet4_default and
*f_quiet4_snan pattern.

However I am not sure about the code gen impact of 2, especially the
impact to the combine pass, not sure if you are interested to give a
try?

And, I did some hack for part of this approach (1+3+4) got following
result for "__builtin_isless (x, y) + __builtin_isless (x, z)":

fltlt:
   frflags a4  # 8 [c=4 l=4]  riscv_frflags
   flt.d   a5,fa0,fa1  # 14[c=4 l=4]  *cstoredfdi4
   flt.d   a0,fa0,fa2  # 17[c=4 l=4]  *cstoredfdi4
   fsflags a4  # 18[c=4 l=4]  riscv_fsflags
   add a0,a0,a5# 30[c=4 l=4]  adddi3/0
   ret # 40[c=0 l=4]  simple_return

Verbose version:
fltlt:
#(insn 8 5 9 (set (reg:SI 14 a4 [88])
#(reg:SI 66 fflags)) "x.c":5:10 258 {riscv_frflags}
# (expr_list:REG_DEAD (reg:SI 66 fflags)
#(nil)))
   frflags a4  # 8 [c=4 l=4]  riscv_frflags
#(insn 14 11 15 (parallel [
#(set (reg:DI 15 a5 [90])
#(lt:DI (reg/v:DF 42 fa0 [orig:81 x ] [81])
#(reg:DF 43 fa1 [101])))
#(clobber:SI (reg:SI 66 fflags))
#]) "x.c":5:10 197 {*cstoredfdi4}
# (expr_list:REG_DEAD (reg:DF 43 fa1 [101])
#(expr_list:REG_UNUSED (reg:SI 66 fflags)
#(nil
   flt.d   a5,fa0,fa1  # 14[c=4 l=4]  *cstoredfdi4
#(insn 17 15 18 (parallel [
#(set (reg:DI 10 a0 [94])
#(lt:DI (reg/v:DF 42 fa0 [orig:81 x ] [81])
#(reg:DF 44 fa2 [102])))
#(clobber:SI (reg:SI 66 fflags))
#]) "x.c":5:36 197 {*cstoredfdi4}
# (expr_list:REG_DEAD (reg:DF 44 fa2 [102])
#(expr_list:REG_DEAD (reg/v:DF 42 fa0 [orig:81 x ] [81])
#(expr_list:REG_UNUSED (reg:SI 66 fflags)
#(nil)
   flt.d   a0,fa0,fa2  # 17[c=4 l=4]  *cstoredfdi4
#(insn 18 17 19 (set (reg:SI 66 fflags)
#(reg:SI 14 a4 [88])) "x.c":5:36 259 {riscv_fsflags}
# (expr_list:REG_DEAD (reg:SI 14 a4 [88])
#(nil)))
   fsflags a4  # 18[c=4 l=4]  riscv_fsflags
#(insn 30 25 31 (set (reg/i:DI 10 a0)
#(plus:DI (reg:DI 10 a0 [94])
#(reg:DI 15 a5 [90]))) "x.c":6:1 4 {adddi3}
# (expr_list:REG_DEAD (reg:DI 15 a5 [90])
#(nil)))
   add a0,a0,a5# 30[c=4 l=4]  adddi3/0
#(jump_insn 40 39 41 (simple_return) "x.c":6:1 244 {simple_return}
# (nil)
# -> simple_return)
   ret # 40[c=0 l=4]  simple_return


But this hack add an extra use of fflags to prevent FFLAGS getting
CSEed, patch attached.
From 1116422bb5a69d8361f5c5bc334a122fecbaa306 Mon Sep 17 00:00:00 2001
From: Kito Cheng 
Date: Fri, 24 Jun 2022 00:41:55 +0800
Subject: [PATCH] model fflags

---
 gcc/config/riscv/riscv.h  | 12 +--
 gcc/config/riscv/riscv.md | 42 ---
 gcc/function.cc   |  1 +
 3 files changed, 29 insertions(+), 26 deletions(-)

diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index 6f7f4d3fbdc..c4e6efe9885 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/riscv/riscv.h
@@ -291,7 +291,7 @@ ASM_MISA_SPEC
 	- ARG_POINTER_REGNUM
 	- FRAME_POINTER_REGNUM */
 
-#define FIRST_PSEUDO_REGISTER 66
+#define FIRST_PSEUDO_REGISTER 67
 
 /* x0, sp, gp, and tp are fixed.  */
 
@@ -303,7 +303,7 @@ ASM_MISA_SPEC
   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,			\
   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,			\
   /* Others.  */			\
-  1, 1	\
+  1, 1, 1\
 }
 
 /* a0-a7, t0-t6, fa0-fa7, and ft0-ft11 are volatile across calls.
@@ -317,7 +317,7 @@ ASM_MISA_SPEC
   1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1,			\
   1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1,			\
   /* Others.  */			\
-  1, 1	\
+  1, 1, 1,\
 }
 
 /* Select a register mode required for caller save of hard regno REGNO.
@@ -472,7 +472,7 @@ enum reg_class
   { 0x, 0x, 0x },	/* GR_REGS */		\
   { 0x, 0x, 0x },	/* FP_REGS */		\
   { 0x, 0x, 0x0003 },	/* FRAME_REGS */	\
-  { 0x, 0x, 0x0003 }	/* ALL_REGS */		\
+  { 0x, 0x, 0x0007 }	/* ALL_REGS */		\
 }
 
 /* A C expression whose value is a register class 

Re: [PATCH 03/12] Add more emit_diagnostic overloads

[Joseph Myers]

On Wed, 22 Jun 2022, David Malcolm via Gcc-patches wrote:

>  extern bool emit_diagnostic (diagnostic_t, rich_location *, int,
>const char *, ...) ATTRIBUTE_GCC_DIAG(4,5);
> +extern bool emit_diagnostic (diagnostic_t, rich_location *,
> +  const diagnostic_metadata *, int,
> +  const char *, ...) ATTRIBUTE_GCC_DIAG(5,6);

Note that functions that take translatable diagnostic strings (*msgid 
parameters) can't have overloads with the diagnostic string argument in 
different positions because that breaks xgettext (see commit 
40fecdd62f7d293a214dd71b81de5e0f1099bba7).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] libstdc++: testsuite: avoid predictable mkstemp

[Jonathan Wakely via Gcc-patches]

On Thu, 23 Jun 2022 at 12:39, Alexandre Oliva  wrote:
>
> On Jun 22, 2022, Jonathan Wakely  wrote:
>
> > On Wed, 22 Jun 2022 at 07:05, Alexandre Oliva via Libstdc++
> >  wrote:
>
> >> It was prompted by a target system with a non-random implementation of
> >> mkstemp, that returns a predictable sequence of filenames and selects
> >> the first one that isn't already taken.
>
> > OK
>
> And here's the patch that enabled me to stop worrying about the above.
> Regstrapped on x86_64-linux-gnu, also tested with a cross to
> aarch64-rtems6.  Ok to install?
>
>
> __gnu_test::nonexistent_path: Always include counter in filename returned
>
> From: Joel Brobecker 
>
> We have noticed that, on RTEMS, a small number of testscases are
> failing because two calls to this method return the same filename.
> This happens for instance in 27_io/filesystem/operations/copy_file.cc
> where it does:
>
>   auto from = __gnu_test::nonexistent_path();
>   auto to = __gnu_test::nonexistent_path();
>
> We tracked this issue down to the fact that the implementation of
> mkstemp on that system appears to use a very predictable algorithm
> for chosing the name of the temporary file, where the same filename
> appears to be tried in the same order, regardless of past calls.
> So, as long as the file gets deleted after a call to mkstemp (something
> we do here in our nonexistent_path method), the next call to mkstemps
> ends up returning the same filename, causing the collision we se above.
>
> This commit enhances the __gnu_test::nonexistent_path method to
> introduce in the filename being returned a counter which gets
> incremented at every call of this method.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/util/testsuite_fs.h (__gnu_test::nonexistent_path):
> Always include a counter in the filename returned.
> ---
>  libstdc++-v3/testsuite/util/testsuite_fs.h |   31 
> 
>  1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/libstdc++-v3/testsuite/util/testsuite_fs.h 
> b/libstdc++-v3/testsuite/util/testsuite_fs.h
> index 037d9ffc0f429..206ea67779003 100644
> --- a/libstdc++-v3/testsuite/util/testsuite_fs.h
> +++ b/libstdc++-v3/testsuite/util/testsuite_fs.h
> @@ -38,9 +38,9 @@ namespace test_fs = std::experimental::filesystem;
>
>  #if defined(_GNU_SOURCE) || _XOPEN_SOURCE >= 500 || _POSIX_C_SOURCE >= 
> 200112L
>  #include  // mkstemp
> -#else
> -#include// std::random_device
> +#include  // strcpy
>  #endif
> +#include// std::random_device
>
>  #if defined(__MINGW32__) || defined(__MINGW64__) \
>|| !defined (_GLIBCXX_HAVE_SYMLINK)
> @@ -125,8 +125,32 @@ namespace __gnu_test
>file.erase(0, pos+1);
>
>  test_fs::path p;
> +// A counter, starting from a random value, to be included as part
> +// of the filename being returned, and incremented each time
> +// this method is used.  It allows us to ensure that two calls
> +// to this method can never return the same filename, something
> +// testcases do when they need multiple non-existent filenames
> +// for their purposes.
> +static unsigned counter = std::random_device{}();
> +
>  #if defined(_GNU_SOURCE) || _XOPEN_SOURCE >= 500 || _POSIX_C_SOURCE >= 
> 200112L
> -char tmp[] = "filesystem-test.XX";
> +// Use mkstemp to determine the name of a file which does not exist yet.
> +//
> +// Note that we have seen on some systems (such as RTEMS, for instance)
> +// that mkstemp behaves very predictably, causing it to always try
> +// the same sequence of file names.  In other words, if we call mkstemp
> +// with a pattern, delete the file it created (which is what we do, 
> here),
> +// and call mkstemp with the same pattern again, it returns the same
> +// filename once more.  While most implementations introduce a degree
> +// of randomness, it is not mandated by the standard, and this is why
> +// we include a counter in the template passed to mkstemp.
> +std::string mkstemp_template ("filesystem-test.");
> +mkstemp_template.append(std::to_string (counter++));
> +mkstemp_template.append(".XX");
> +
> +char tmp[mkstemp_template.length() + 1];
> +std::strcpy (tmp, mkstemp_template.c_str());

std::string::copy can be used to copy a string into a buffer, but
there's no reason to use another buffer anyway.

The attached makes this a bit more efficient, and makes more of the
code common to the mkstemp and non-mkstmp branches. I'll wait to hear
back from you before pushing it (since it has Joel's name on the
patch).
commit 87d861e3126f6304e8bc9d8e743022a21424
Author: Joel Brobecker 
Date:   Thu Jun 23 13:12:12 2022

libstdc++: testsuite: avoid predicable mkstemp

We have noticed that, on RTEMS, a small number of testscases are
failing because two calls to this method return the same filename.
This happens for instance in 27_io/filesystem/operations/copy_file.cc
where it does:

  auto 

Re: [PATCH] Inline memchr with a small constant string

[H.J. Lu via Gcc-patches]

On Wed, Jun 22, 2022 at 11:03 PM Richard Biener
 wrote:
>
> On Wed, Jun 22, 2022 at 7:13 PM H.J. Lu  wrote:
> >
> > On Wed, Jun 22, 2022 at 4:39 AM Richard Biener
> >  wrote:
> > >
> > > On Tue, Jun 21, 2022 at 11:03 PM H.J. Lu via Gcc-patches
> > >  wrote:
> > > >
> > > > When memchr is applied on a constant string of no more than the bytes of
> > > > a word, inline memchr by checking each byte in the constant string.
> > > >
> > > > int f (int a)
> > > > {
> > > >return  __builtin_memchr ("eE", a, 2) != 0;
> > > > }
> > > >
> > > > is simplified to
> > > >
> > > > int f (int a)
> > > > {
> > > >   return (char) a == 'e' || (char) a == 'E';
> > > > }
> > > >
> > > > gcc/
> > > >
> > > > PR tree-optimization/103798
> > > > * match.pd (__builtin_memchr (const_str, a, N)): Inline memchr
> > > > with constant strings of no more than the bytes of a word.
> > >
> > > Please do this in strlenopt or so, with match.pd you will end up moving
> > > the memchr loads across possible aliasing stores to the point of the
> > > comparison.
> >
> > strlenopt is run after many other passes.  The code won't be well optimized.
>
> What followup optimizations do you expect?  That is, other builtins are only

reassociation and dce turn

  _5 = a_2(D) == 101;
  _6 = a_2(D) == 69;
  _1 = _5 | _6;
  _4 = (int) _1;

into

  _7 = a_2(D) & -33;
  _8 = _7 == 69;
  _1 = _8;
  _4 = (int) _1;

> expanded inline at RTL expansion time?

Some high level optimizations will be missed and
TARGET_GIMPLE_FOLD_BUILTIN improves builtins
codegen.

> > Since we are only optimizing
> >
> > __builtin_memchr ("eE", a, 2) != 0;
> >
> > I don't see any aliasing store issues here.
>
> Ah, I failed to see the STRING_CST restriction.  Note that when optimizing for
> size this doesn't look very good.

True.

> I would expect a target might produce some vector code for
> memchr ("aAbBcCdDeE...", c, 9) != 0 by splatting 'c', doing
> a v16qimode compare, masking off excess elements beyond length
> and then comparing against zero or for == 0 against all-ones.
>
> The repetitive pattern result also suggests an implementation elsewhere,
> if you think strlenopt is too late there would be forwprop as well.

forwprop seems a good place.

Thanks.

> Richard.
>
>
>
> > > Richard.
> > >
> > > > gcc/testsuite/
> > > >
> > > > PR tree-optimization/103798
> > > > * c-c++-common/pr103798-1.c: New test.
> > > > * c-c++-common/pr103798-2.c: Likewise.
> > > > * c-c++-common/pr103798-3.c: Likewise.
> > > > * c-c++-common/pr103798-4.c: Likewise.
> > > > * c-c++-common/pr103798-5.c: Likewise.
> > > > * c-c++-common/pr103798-6.c: Likewise.
> > > > * c-c++-common/pr103798-7.c: Likewise.
> > > > * c-c++-common/pr103798-8.c: Likewise.
> > > > ---
> > > >  gcc/match.pd| 136 
> > > >  gcc/testsuite/c-c++-common/pr103798-1.c |  28 +
> > > >  gcc/testsuite/c-c++-common/pr103798-2.c |  30 ++
> > > >  gcc/testsuite/c-c++-common/pr103798-3.c |  28 +
> > > >  gcc/testsuite/c-c++-common/pr103798-4.c |  28 +
> > > >  gcc/testsuite/c-c++-common/pr103798-5.c |  26 +
> > > >  gcc/testsuite/c-c++-common/pr103798-6.c |  27 +
> > > >  gcc/testsuite/c-c++-common/pr103798-7.c |  27 +
> > > >  gcc/testsuite/c-c++-common/pr103798-8.c |  27 +
> > > >  9 files changed, 357 insertions(+)
> > > >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-1.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-2.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-3.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-4.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-5.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-6.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-7.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-8.c
> > > >
> > > > diff --git a/gcc/match.pd b/gcc/match.pd
> > > > index a63b649841b..aa4766749af 100644
> > > > --- a/gcc/match.pd
> > > > +++ b/gcc/match.pd
> > > > @@ -7976,3 +7976,139 @@ and,
> > > >  (match (bitwise_induction_p @0 @2 @3)
> > > >   (bit_not
> > > >(nop_convert1? (bit_xor@0 (convert2? (lshift integer_onep@1 @2)) 
> > > > @3
> > > > +
> > > > +#if GIMPLE
> > > > +/* __builtin_memchr (const_str, a, N) != 0 ->
> > > > +   a == const_str[0] .. || a == const_str[N-1]
> > > > +   __builtin_memchr (const_str, a, N) == 0 ->
> > > > +   a != const_str[0] .. && a != const_str[N-1]
> > > > +   where N is less than the string size.  */
> > > > +(for cmp (eq ne)
> > > > + icmp (ne eq)
> > > > + bit_op (bit_and bit_ior)
> > > > + (simplify (cmp:c @0 (BUILT_IN_MEMCHR ADDR_EXPR@1 @2 INTEGER_CST@3))
> > > > +  (if (UNITS_PER_WORD <= 8
> > > > +   && CHAR_TYPE_SIZE == 8
> > > > +   && BITS_PER_UNIT == 8
> > > > +   && CHAR_BIT == 8
> > > > +   && integer_zerop (@0)
> > > > +  

[committed] libstdc++: Properly remove temporary directories in filesystem tests

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux, pushed to trunk.

-- >8 --

Although these tests use filesystem::remove_all to clean up, that fails
because it uses recursive_directory_iterator which is intentionally
bodged by the custom readdir defined in the test.

Just use POSIX rmdir to clean up. We don't need to use _rmdir or _wrmdir
for Windows, because we'll never reach test02() on targets where the
custom readdir doesn't interpose the one from libc.

libstdc++-v3/ChangeLog:

* testsuite/27_io/filesystem/iterators/error_reporting.cc: Use
rmdir to remove directories.
* testsuite/experimental/filesystem/iterators/error_reporting.cc:
Likewise.
---
 .../27_io/filesystem/iterators/error_reporting.cc| 9 +++--
 .../experimental/filesystem/iterators/error_reporting.cc | 9 +++--
 2 files changed, 14 insertions(+), 4 deletions(-)

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 1c8ea4c9249..a26b29f0974 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/iterators/error_reporting.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/iterators/error_reporting.cc
@@ -107,7 +107,7 @@ void
 test02()
 {
   namespace fs = std::filesystem;
-  auto dir = __gnu_test::nonexistent_path();
+  const auto dir = __gnu_test::nonexistent_path();
   fs::create_directories(dir/"subdir");
 
   std::error_code ec;
@@ -137,7 +137,12 @@ test02()
   }
 #endif
 
-  fs::remove_all(dir, ec);
+  // Cannot use fs::remove_all here because that uses
+  // recursive_directory_iterator which would use the fake readdir above.
+#ifndef _GLIBCXX_FILESYSTEM_IS_WINDOWS
+  ::rmdir((dir/"subdir").c_str());
+  ::rmdir(dir.c_str());
+#endif
 }
 
 int
diff --git 
a/libstdc++-v3/testsuite/experimental/filesystem/iterators/error_reporting.cc 
b/libstdc++-v3/testsuite/experimental/filesystem/iterators/error_reporting.cc
index 806c511ebef..f005b7d5293 100644
--- 
a/libstdc++-v3/testsuite/experimental/filesystem/iterators/error_reporting.cc
+++ 
b/libstdc++-v3/testsuite/experimental/filesystem/iterators/error_reporting.cc
@@ -99,7 +99,7 @@ void
 test02()
 {
   namespace fs = std::experimental::filesystem;
-  auto dir = __gnu_test::nonexistent_path();
+  const auto dir = __gnu_test::nonexistent_path();
   fs::create_directories(dir/"subdir");
 
   std::error_code ec;
@@ -129,7 +129,12 @@ test02()
   }
 #endif
 
-  fs::remove_all(dir, ec);
+  // Cannot use fs::remove_all here because that depends on
+  // recursive_directory_iterator which would use the fake readdir above.
+#ifndef _GLIBCXX_FILESYSTEM_IS_WINDOWS
+  ::rmdir((dir/"subdir").c_str());
+  ::rmdir(dir.c_str());
+#endif
 }
 
 int
-- 
2.36.1

[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
This seems to have changed in the GCC 9 series. GCC 8.5 generates:
f():
mov w0, 1
ret
g():
mov w0, 1
ret
b:
a:

Tagging as a claimed wrong-code bug.

[Bug c++/105593] avx512 math function raises uninitialized variable warning

[rogerio.souza at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Rogério de Souza Moraes  ---
I got another example with similar warning:

#

#include 
//#pragma GCC diagnostic push
//#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
#include 
//#pragma GCC diagnostic pop
#include 

namespace sysOs
{
  std::regex rgxVer("ABC");
}

int main()
{
  return 0;
}

###

The code above is available at https://godbolt.org/z/chsjPKE33. 

Compiled with:

gcc -c -fPIC -Werror -std=c++2a  -Wno-unused -O -Wall

it returns the warning:

/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/std_function.h:405:42:
error: '*(std::function*)((char*)&__tmp +
offsetof(std::__detail::_StateT,
std::__detail::_State::.std::__detail::_State_base::)).std::function::_M_invoker'
may be used uninitialized [-Werror=maybe-uninitialized]
  405 |   : _Function_base(), _M_invoker(__x._M_invoker)
  |  ^~


Would it be related with the same issue reported here? This example does not
raise the warning on GCC 11.3.

Regards,
--
Rogerio

Re: remove intl/ directory?

[Iain Sandoe via Gcc]

> On 23 Jun 2022, at 16:40, Iain Sandoe via Gcc  wrote:
> 
> 
> 
>> On 23 Jun 2022, at 07:51, Iain Sandoe via Gcc  wrote:
>> 
>>> On 23 Jun 2022, at 05:24, Bruno Haible  wrote:
>>> 
>>> Iain Sandoe wrote:
>> 
 … although now I see some configure warnings about not being able to 
 access build-aux (which I do not recall seeing with the previous hack - 
 but that could be just bad memory ;) )
>>> 
>>> You can get warnings if you _move_ the gettext-runtime directory so that it
>>> becomes a sibling directory of 'gcc'. You should *not* get warnings if you
>>> create a symlink, sibling of the 'gcc' directory, to the
>>> gettext-20220620/gettext-runtime/ directory.
>> 
>> I did symlink, and agree it should work - I’ll need to try and repeat when 
>> next I have some time.
>>> 
 FWIW this following snippet would be just as broken on macOS as other 
 noted platforms - it would need auto-foo-provided shared lib extension - 
 or the equivalent to be used.
 …  is there any reason that all platforms with non-’so’ suffixes would not 
 work with that change?
>>> 
>>> On macOS (with .dylib instead of .so) it would probably work.
>>> 
>>> However, AIX and HP-UX will not work, because (as I understand it) if you 
>>> want
>>> to have a binary, say cc1, which depends on libintl, then
>>> - the cc1 that accesses /usr/local/lib/libintl.$suffix
>>> and
>>> - the cc1 that accesses 
>>> /home/user/build/gcc-snap/gettext-runtime/intl/.libs/libintl.$suffix
>>> must necessarily be different. You cannot just install the second one in
>>> public locations, because it will have the wrong shared library filename
>>> hardcoded into it. This is why on these systems, libtool has to rebuild
>>> executables during "make install".
>> 
>> Ah, actually a similar situation might apply to the macOS case, you would 
>> either need
>> to build it “@rpath” and install the library in the exe’s dir or build and 
>> install it into
>> ‘prefix’ (that puts the full pathname into the dylib, in a similar way to 
>> AIX / HP-UX).
>> This is also requires a bit of juggling on macOS (I have patches in flight 
>> to make all
>> the runtimes for GCC built with ‘@rpath’ and using embedded rpaths in exe) 
>> hopefully
>> for GCC-13
>> … so let’s quietly forget the shared case for now...
>> 
>>> Anyway, you said that for GCC, the important case is to build libintl as a
>>> static (non-shared) library.
>> 
>> Yes, in a 1:1 replacement for ‘intl’ that’s the case, we can figure out 
>> shared stuff as a follow-on.
>> 
 I think that we now need to deal with the GCC-side of the configury …
 
 1) add logic [like GMP et. al.] to specify an external source of the 
 library (when there is no-in-tree source present)
>>> 
>>> Are you aware that gettext.m4 already introduces the configure options
>>> --with-libintl-prefix[=DIR]  search for libintl in DIR/include and DIR/lib
>>> --without-libintl-prefix don't search for libintl in includedir and 
>>> libdir
>> 
>> Hmm - the following cases:
>> a) there’s no gettext-runtime in the source tree and the user needs to 
>> configure —with-libintl-prefix= 
>> b) there is a  gettext-runtime in the source tree and the user decides to 
>> configure —with-libintl-prefix= (which will be ignored if we take the way 
>> the other in-tree builds are handled as ’status quo’
>> c) there is a  gettext-runtime in the source tree  and no 
>> —with-libintl-prefix= is given (we expect to pick up the in-tree build 
>> silently and automatically).
>> 
>> … in case (a) we’d need to arrange for the gettext macro to be called in 
>> configure, but I don’t think it will play nicely with gettext-sister .. so 
>> there’s some work needed here.
>> in case (b) I’m not sure what will happen - will the configure for libintl 
>> just point the variables to the install suggested?
> 
> .. update on (b).
> OK, so there are two issues I can see [let’s put the flags pollution issues 
> to one side for now, since people sometimes forget that the configuration 
> namespace is flat and overload save_CFLAGS et. al]
> 
> 1. —with-libintl-prefix= is not going to work on macOS, when the prefix 
> contains only a convenience lib (which is what I prefer for GCC).
>  This is because the configure has no way to know that libintl.a depends on 
> -framework CoreFoundation, AFAICS there’s nowhere it could even look - the 
> info is not in the libtool lib (and that does not seem to get installed 
> anyway for the snapshot) 
>  I'd suppose that a shared library would work (since there are no hidden 
> deps) .. 
> 
> AFAICT, ‘intl/‘ works OK with this (iff I manually add -framework 
> CoreFoundation to the LDFLAGS) and LIBINTL gets set to the right line for 
> using the installed variant.

this ^ is actually inconsistent with the other deps .. as noted  below.
> 
> 2/ .. the current gettext-runtime snapshot does not work, I think because it 
> assumes if we’re not using the in-tree case, then the lib must be coming from 
> libc 

[PATCH, libgomp] Fix chunk_size<1 for dynamic schedule

[Chung-Lin Tang]

Hi Jakub,
with the way that chunk_size < 1 is handled for gomp_iter_dynamic_next:

(1) chunk_size <= -1: wraps into large unsigned value, seems to work though.
(2) chunk_size == 0:  infinite loop

The (2) behavior is obviously not desired. This patch fixes this by changing
the chunk_size initialization in gomp_loop_init to "max(1,chunk_size)"

The OMP_SCHEDULE parsing in libgomp/env.c has also been adjusted to reject
negative values.

Tested without regressions, and a new testcase for the infinite loop behavior 
added.
Okay for trunk?

Thanks,
Chung-Lin

libgomp/ChangeLog:
* env.c (parse_schedule): Make negative values invalid for chunk_size.
* loop.c (gomp_loop_init): For non-STATIC schedule and chunk_size <= 0,
set initialized chunk_size to 1.

* testsuite/libgomp.c/loop-28.c: New test.diff --git a/libgomp/env.c b/libgomp/env.c
index 1c4ee894515..dff07617e15 100644
--- a/libgomp/env.c
+++ b/libgomp/env.c
@@ -182,6 +182,8 @@ parse_schedule (void)
 goto invalid;
 
   errno = 0;
+  if (*env == '-')
+goto invalid;
   value = strtoul (env, , 10);
   if (errno || end == env)
 goto invalid;
diff --git a/libgomp/loop.c b/libgomp/loop.c
index be85162bb1e..018b4e9a8bd 100644
--- a/libgomp/loop.c
+++ b/libgomp/loop.c
@@ -41,7 +41,7 @@ gomp_loop_init (struct gomp_work_share *ws, long start, long 
end, long incr,
enum gomp_schedule_type sched, long chunk_size)
 {
   ws->sched = sched;
-  ws->chunk_size = chunk_size;
+  ws->chunk_size = (sched == GFS_STATIC || chunk_size > 1) ? chunk_size : 1;
   /* Canonicalize loops that have zero iterations to ->next == ->end.  */
   ws->end = ((incr > 0 && start > end) || (incr < 0 && start < end))
? start : end;
diff --git a/libgomp/testsuite/libgomp.c/loop-28.c 
b/libgomp/testsuite/libgomp.c/loop-28.c
new file mode 100644
index 000..e3f852046f4
--- /dev/null
+++ b/libgomp/testsuite/libgomp.c/loop-28.c
@@ -0,0 +1,17 @@
+/* { dg-do run } */
+/* { dg-timeout 10 } */
+
+void __attribute__((noinline))
+foo (int a[], int n, int chunk_size)
+{
+  #pragma omp parallel for schedule (dynamic,chunk_size)
+  for (int i = 0; i < n; i++)
+a[i] = i;
+}
+
+int main (void)
+{
+  int a[100];
+  foo (a, 100, 0);
+  return 0;
+}

[Bug c++/105885] [12/13 Regression] the address of 'template argument' will never be NULL warning

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed for 12.2/13.

[Bug target/106060] Inefficient constant broadcast on x86_64

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

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

--- Comment #2 from H.J. Lu  ---
Created attachment 53196
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53196=edit
A patch

This generates:

 :
   0:   b8 7b 00 00 00  mov$0x7b,%eax
   5:   c5 f9 6e c0 vmovd  %eax,%xmm0
   9:   c4 e2 7d 78 c0  vpbroadcastb %xmm0,%ymm0
   e:   c3  ret
   f:   90  nop

0010 :
  10:   b8 01 00 00 00  mov$0x1,%eax
  15:   c5 f9 6e c0 vmovd  %eax,%xmm0
  19:   c4 e2 7d 78 c0  vpbroadcastb %xmm0,%ymm0
  1e:   c3  ret
  1f:   90  nop

0020 :
  20:   b8 fe ff ff ff  mov$0xfffe,%eax
  25:   c5 f9 6e c0 vmovd  %eax,%xmm0
  29:   c4 e2 7d 78 c0  vpbroadcastb %xmm0,%ymm0
  2e:   c3  ret

[Bug c++/105885] [12/13 Regression] the address of 'template argument' will never be NULL warning

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

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

commit r12-8510-gb96b64bec37c3dddf1f0f93c27ceb4fd5685c70a
Author: Jason Merrill 
Date:   Wed Jun 22 23:50:23 2022 -0400

c++: -Waddress and value-dependent expr [PR105885]

We already suppress various warnings for code that would be tautological if
written directly, but not when it's the result of template substitution. 
It
seems we need to do this for -Waddress as well.

PR c++/105885

gcc/cp/ChangeLog:

* pt.cc (tsubst_copy_and_build): Also suppress -Waddress for
comparison of dependent operands.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-if37.C: New test.

[Bug c/103360] [meta-bug] bogus/missing -Waddress

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

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

Bug 94554 Summary: spurious -Waddress warning within "if constexpr" 
function-null compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94554

   What|Removed |Added

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

[Bug c++/94554] spurious -Waddress warning within "if constexpr" function-null compares

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for GCC 13.

[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X' since r12-954-g84fd1b5dff70cd74

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/106047] ICE in structure_alloc_comps, at fortran/trans-array.cc:9574

[gscfq--- via Gcc-bugs]

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

--- Comment #2 from G. Steinmetz  ---

Hmm, exploring some more test cases;
z2 gives same ICE, z3 prints 128, z4 gives an error, z5 is ok/works :

$ cat z2.f90
program p
   type t
  character(:), allocatable :: c
   end type
   type(t) :: x ! without = t()
   integer, parameter :: n = storage_size(x)
end

$ cat z3.f90
program p
   type t
  character(:), allocatable :: c
   end type
   type(t), parameter :: x = t()   ! that is t(null())
   integer :: n = storage_size(x)
   print *, n
end

$ cat z4.f90
program p
   type t
  character(:), allocatable :: c
   end type
   type(t), parameter :: x = t('abc')   ! instead of t(null())
   integer :: n = storage_size(x)
   print *, n
end

$ cat z5.f90
program p
   type t
  character(:), allocatable :: c
   end type
   type(t) :: x 
   integer :: n
   n = storage_size(x)
   print *, n
end

---

Some examples without "type" :

$ cat zz1.f90
program p
   character(:), allocatable :: c
   integer :: n = storage_size(c)
   print *, n
end

$ cat zz2.f90
program p
   character(:), allocatable :: c
   integer, parameter :: n = storage_size(c)
   print *, n
end

$ cat zz3.f90
program p
   character(:), allocatable :: c
   print *, storage_size(c)
end


$ gfortran-13-20220619 -c zz1.f90
zz1.f90:3:31:

3 |integer :: n = storage_size(c)
  |   1
Error: Parameter 'c' at (1) has not been declared or is a variable, which does
not reduce to a constant expression
$
$ gfortran-13-20220619 -c zz2.f90
zz2.f90:3:42:

3 |integer, parameter :: n = storage_size(c)
  |  1
Error: Parameter 'c' at (1) has not been declared or is a variable, which does
not reduce to a constant expression
$
$ gfortran-13-20220619 zz3.f90 ; a.out
   0
$

Via Compiler Explorer :
Latest ifort/ifx indeed compiles z1/2/3/5, rejects z4 with an error (ok).
Latest ifort/ifx rejects zz1/zz2 with an error, accepts zz3 and prints 0.

Re: remove intl/ directory?

[Iain Sandoe via Gcc]

> On 23 Jun 2022, at 07:51, Iain Sandoe via Gcc  wrote:
> 
>> On 23 Jun 2022, at 05:24, Bruno Haible  wrote:
>> 
>> Iain Sandoe wrote:
> 
>>> … although now I see some configure warnings about not being able to access 
>>> build-aux (which I do not recall seeing with the previous hack - but that 
>>> could be just bad memory ;) )
>> 
>> You can get warnings if you _move_ the gettext-runtime directory so that it
>> becomes a sibling directory of 'gcc'. You should *not* get warnings if you
>> create a symlink, sibling of the 'gcc' directory, to the
>> gettext-20220620/gettext-runtime/ directory.
> 
> I did symlink, and agree it should work - I’ll need to try and repeat when 
> next I have some time.
>> 
>>> FWIW this following snippet would be just as broken on macOS as other noted 
>>> platforms - it would need auto-foo-provided shared lib extension - or the 
>>> equivalent to be used.
>>> …  is there any reason that all platforms with non-’so’ suffixes would not 
>>> work with that change?
>> 
>> On macOS (with .dylib instead of .so) it would probably work.
>> 
>> However, AIX and HP-UX will not work, because (as I understand it) if you 
>> want
>> to have a binary, say cc1, which depends on libintl, then
>> - the cc1 that accesses /usr/local/lib/libintl.$suffix
>> and
>> - the cc1 that accesses 
>> /home/user/build/gcc-snap/gettext-runtime/intl/.libs/libintl.$suffix
>> must necessarily be different. You cannot just install the second one in
>> public locations, because it will have the wrong shared library filename
>> hardcoded into it. This is why on these systems, libtool has to rebuild
>> executables during "make install".
> 
> Ah, actually a similar situation might apply to the macOS case, you would 
> either need
> to build it “@rpath” and install the library in the exe’s dir or build and 
> install it into
> ‘prefix’ (that puts the full pathname into the dylib, in a similar way to AIX 
> / HP-UX).
> This is also requires a bit of juggling on macOS (I have patches in flight to 
> make all
> the runtimes for GCC built with ‘@rpath’ and using embedded rpaths in exe) 
> hopefully
> for GCC-13
> … so let’s quietly forget the shared case for now...
> 
>> Anyway, you said that for GCC, the important case is to build libintl as a
>> static (non-shared) library.
> 
> Yes, in a 1:1 replacement for ‘intl’ that’s the case, we can figure out 
> shared stuff as a follow-on.
> 
>>> I think that we now need to deal with the GCC-side of the configury …
>>> 
>>> 1) add logic [like GMP et. al.] to specify an external source of the 
>>> library (when there is no-in-tree source present)
>> 
>> Are you aware that gettext.m4 already introduces the configure options
>> --with-libintl-prefix[=DIR]  search for libintl in DIR/include and DIR/lib
>> --without-libintl-prefix don't search for libintl in includedir and 
>> libdir
> 
> Hmm - the following cases:
> a) there’s no gettext-runtime in the source tree and the user needs to 
> configure —with-libintl-prefix= 
> b) there is a  gettext-runtime in the source tree and the user decides to 
> configure —with-libintl-prefix= (which will be ignored if we take the way the 
> other in-tree builds are handled as ’status quo’
> c) there is a  gettext-runtime in the source tree  and no 
> —with-libintl-prefix= is given (we expect to pick up the in-tree build 
> silently and automatically).
> 
> … in case (a) we’d need to arrange for the gettext macro to be called in 
> configure, but I don’t think it will play nicely with gettext-sister .. so 
> there’s some work needed here.
> in case (b) I’m not sure what will happen - will the configure for libintl 
> just point the variables to the install suggested?

.. update on (b).
OK, so there are two issues I can see [let’s put the flags pollution issues to 
one side for now, since people sometimes forget that the configuration 
namespace is flat and overload save_CFLAGS et. al]

1. —with-libintl-prefix= is not going to work on macOS, when the prefix 
contains only a convenience lib (which is what I prefer for GCC).
  This is because the configure has no way to know that libintl.a depends on 
-framework CoreFoundation, AFAICS there’s nowhere it could even look - the info 
is not in the libtool lib (and that does not seem to get installed anyway for 
the snapshot) 
  I'd suppose that a shared library would work (since there are no hidden deps) 
.. 

AFAICT, ‘intl/‘ works OK with this (iff I manually add -framework 
CoreFoundation to the LDFLAGS) and LIBINTL gets set to the right line for using 
the installed variant.

2/ .. the current gettext-runtime snapshot does not work, I think because it 
assumes if we’re not using the in-tree case, then the lib must be coming from 
libc - which is not the case for most non-glibc clients (so it seems to ignore 
the —with… and populate the uninstalled-gettext.sh with the in-tree data anyway)



(we still need to deal with case (a) but case (b) could be fixable, perhaps at 
a cost of having 

[Bug fortran/105807] ICE / error when defining a class containing polymorphic components

[gscfq--- via Gcc-bugs]

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

--- Comment #3 from G. Steinmetz  ---

One tick simpler, without vect3d :

$ cat z3.f90
program p
type t
end type
type t2
class(t), allocatable :: v
end type
type, extends(t2) :: elem2d
end type
type(t) :: b
class(t2), allocatable :: e
e = elem2d(b)
end program


No ICE when b is replaced by constructor t() :

$ cat z5.f90
program p
type t
end type
type t2
class(t), allocatable :: v
end type
type, extends(t2) :: elem2d
end type
class(t2), allocatable :: e
e = elem2d(t())
end program

[Bug analyzer/105890] RFE: -fanalyzer should complain about mkstemp with not enough "X"s in format string

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

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

--- Comment #2 from David Malcolm  ---
  https://pubs.opengroup.org/onlinepubs/009604499/functions/mkstemp.html says:
"The string in template should look like a filename with six trailing 'X's"


https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkstemp.html says:
"The application shall ensure that the string provided in template is a
pathname ending with at least six trailing 'X' characters."

Re: remove intl/ directory?

[Eric Gallager via Gcc]

On Thu, Jun 23, 2022 at 12:25 AM Bruno Haible  wrote:
>
> Iain Sandoe wrote:
> > Yes (
> > # We can use an in-tree build of libintl.
> > if test -f  ifelse([$1],,[../gettext-runtime],[$1])/uninstalled-config.sh; 
> > then
> >   
> > relative_builddir='ifelse([$1],,[${top_builddir}/..],[$1]/..)/gettext-runtime'
> >   .  ifelse([$1],,[../gettext-runtime],[$1])/uninstalled-config.sh
> > elif test -f  ifelse([$1],,[../intl],[$1])/config.intl; then
> >   .  ifelse([$1],,[../intl],[$1])/config.intl
> > fi
> > )
> > and it works ...
>
> Good!
>
> > … although now I see some configure warnings about not being able to access 
> > build-aux (which I do not recall seeing with the previous hack - but that 
> > could be just bad memory ;) )
>
> You can get warnings if you _move_ the gettext-runtime directory so that it
> becomes a sibling directory of 'gcc'. You should *not* get warnings if you
> create a symlink, sibling of the 'gcc' directory, to the
> gettext-20220620/gettext-runtime/ directory.
>
> > FWIW this following snippet would be just as broken on macOS as other noted 
> > platforms - it would need auto-foo-provided shared lib extension - or the 
> > equivalent to be used.
> > …  is there any reason that all platforms with non-’so’ suffixes would not 
> > work with that change?
>
> On macOS (with .dylib instead of .so) it would probably work.
>
> However, AIX and HP-UX will not work, because (as I understand it) if you want
> to have a binary, say cc1, which depends on libintl, then
>   - the cc1 that accesses /usr/local/lib/libintl.$suffix
> and
>   - the cc1 that accesses 
> /home/user/build/gcc-snap/gettext-runtime/intl/.libs/libintl.$suffix
> must necessarily be different. You cannot just install the second one in
> public locations, because it will have the wrong shared library filename
> hardcoded into it. This is why on these systems, libtool has to rebuild
> executables during "make install".
>
> Anyway, you said that for GCC, the important case is to build libintl as a
> static (non-shared) library.
>
> > > There is also a GCC specific quirk, that I upstreamed into GNU gettext:
> > > https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=fdc2bd236a6a62b477c1fca4205df10b0e64266b
> >
> > IMHO we need to fix this ^ in GCC config - since gettext-runtime accepts 
> > “—with-pic” we should amend the GCC configury to pass —with-pic [to GMP et. 
> > al. as well, currently to build in-tree with host-shared, needs a manual 
> > —with-pic on the configure too]
>
> Indeed, the option '--with-pic' (from libtool) has the same effect as
> '--enable-host-shared'. If you can arrange to pass '--with-pic' instead
> of '--enable-host-shared', I can revert the addition of the option
> '--enable-host-shared' in gettext-runtime/intl from two days ago.
>
> > I think that we now need to deal with the GCC-side of the configury …
> >
> > 1) add logic [like GMP et. al.] to specify an external source of the 
> > library (when there is no-in-tree source present)
>
> Are you aware that gettext.m4 already introduces the configure options
>   --with-libintl-prefix[=DIR]  search for libintl in DIR/include and DIR/lib
>   --without-libintl-prefix don't search for libintl in includedir and 
> libdir
> ?
>

N.B. that there's already at least one issue open about those flags
that I can think of OTTOMH; it's part of the reason I wanted to go
about updating GCC configury in the first place:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251

> Bruno
>
>
>

[Bug c++/94554] spurious -Waddress warning within "if constexpr" function-null compares

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

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

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

https://gcc.gnu.org/g:124a9e08b7a83795bd4d09001955f0eef68ecd00

commit r13-1219-g124a9e08b7a83795bd4d09001955f0eef68ecd00
Author: Jason Merrill 
Date:   Thu Jun 23 00:24:22 2022 -0400

c++: -Waddress and if constexpr [PR94554]

Like we avoid various warnings for seemingly tautological expressions when
substituting a template, we should avoid warning for the implicit
conversion
to bool in an if statement.  I considered also doing this for the
conditions
in loop expressions, but that seems unnecessary, as a loop condition is
unlikely to be a constant.

The change to finish_if_stmt_cond isn't necessary since dependent_operand_p
looks through IMPLICIT_CONV_EXPR, but makes it more constent with
e.g. build_x_binary_op that determines the type of an expression and then
builds it using the original operands.

PR c++/94554

gcc/cp/ChangeLog:

* pt.cc (dependent_operand_p): Split out from...
(tsubst_copy_and_build): ...here.
(tsubst_expr) [IF_STMT]: Use it.
* semantics.cc (finish_if_stmt_cond): Keep the pre-conversion
condition in the template tree.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-if38.C: New test.

[pushed] c++: -Waddress and if constexpr [PR94554]

[Jason Merrill via Gcc-patches]

Like we avoid various warnings for seemingly tautological expressions when
substituting a template, we should avoid warning for the implicit conversion
to bool in an if statement.  I considered also doing this for the conditions
in loop expressions, but that seems unnecessary, as a loop condition is
unlikely to be a constant.

The change to finish_if_stmt_cond isn't necessary since dependent_operand_p
looks through IMPLICIT_CONV_EXPR, but makes it more constent with
e.g. build_x_binary_op that determines the type of an expression and then
builds it using the original operands.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/94554

gcc/cp/ChangeLog:

* pt.cc (dependent_operand_p): Split out from...
(tsubst_copy_and_build): ...here.
(tsubst_expr) [IF_STMT]: Use it.
* semantics.cc (finish_if_stmt_cond): Keep the pre-conversion
condition in the template tree.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-if38.C: New test.
---
 gcc/cp/pt.cc| 43 +++--
 gcc/cp/semantics.cc | 10 +++--
 gcc/testsuite/g++.dg/cpp1z/constexpr-if38.C | 16 
 3 files changed, 55 insertions(+), 14 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-if38.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 4535c14c26a..12a2b57d9e3 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -18547,6 +18547,29 @@ lookup_init_capture_pack (tree decl)
   return r;
 }
 
+/* T is an operand of a template tree being substituted.  Return whether
+   T is dependent such that we should suppress some warnings that would
+   make sense if the substituted expression were written directly, like
+ template  bool f() { return I == 2; }
+   We don't want to warn when instantiating f that comparing two constants
+   always has the same value.
+
+   This is a more limited concept of dependence than instantiation-dependent;
+   here we don't care whether substitution could fail.  */
+
+static bool
+dependent_operand_p (tree t)
+{
+  while (TREE_CODE (t) == IMPLICIT_CONV_EXPR)
+t = TREE_OPERAND (t, 0);
+  ++processing_template_decl;
+  bool r = (potential_constant_expression (t)
+   ? value_dependent_expression_p (t)
+   : type_dependent_expression_p (t));
+  --processing_template_decl;
+  return r;
+}
+
 /* Like tsubst_copy for expressions, etc. but also does semantic
processing.  */
 
@@ -18872,8 +18895,13 @@ tsubst_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl,
   IF_STMT_CONSTEVAL_P (stmt) = IF_STMT_CONSTEVAL_P (t);
   if (IF_STMT_CONSTEXPR_P (t))
args = add_extra_args (IF_STMT_EXTRA_ARGS (t), args, complain, in_decl);
-  tmp = RECUR (IF_COND (t));
-  tmp = finish_if_stmt_cond (tmp, stmt);
+  {
+   tree cond = IF_COND (t);
+   bool was_dep = dependent_operand_p (cond);
+   cond = RECUR (cond);
+   warning_sentinel s1(warn_address, was_dep);
+   tmp = finish_if_stmt_cond (cond, stmt);
+  }
   if (IF_STMT_CONSTEXPR_P (t)
  && instantiation_dependent_expression_p (tmp))
{
@@ -20422,15 +20450,8 @@ tsubst_copy_and_build (tree t,
   warnings that depend on the range of the types involved.  */
tree op0 = TREE_OPERAND (t, 0);
tree op1 = TREE_OPERAND (t, 1);
-   auto dep_p = [](tree t) {
- ++processing_template_decl;
- bool r = (potential_constant_expression (t)
-   ? value_dependent_expression_p (t)
-   : type_dependent_expression_p (t));
- --processing_template_decl;
- return r;
-   };
-   const bool was_dep = dep_p (op0) || dep_p (op1);
+   const bool was_dep = (dependent_operand_p (op0)
+ || dependent_operand_p (op1));
op0 = RECUR (op0);
op1 = RECUR (op1);
 
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 24cca99e909..2344b5eea00 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -1029,9 +1029,9 @@ maybe_warn_for_constant_evaluated (tree cond, bool 
constexpr_if)
IF_STMT.  */
 
 tree
-finish_if_stmt_cond (tree cond, tree if_stmt)
+finish_if_stmt_cond (tree orig_cond, tree if_stmt)
 {
-  cond = maybe_convert_cond (cond);
+  tree cond = maybe_convert_cond (orig_cond);
   if (IF_STMT_CONSTEXPR_P (if_stmt)
   && !type_dependent_expression_p (cond)
   && require_constant_expression (cond)
@@ -1045,7 +1045,11 @@ finish_if_stmt_cond (tree cond, tree if_stmt)
   cond = cxx_constant_value (cond, NULL_TREE);
 }
   else
-maybe_warn_for_constant_evaluated (cond, /*constexpr_if=*/false);
+{
+  maybe_warn_for_constant_evaluated (cond, /*constexpr_if=*/false);
+  if (processing_template_decl)
+   cond = orig_cond;
+}
   finish_cond (_COND (if_stmt), cond);
   add_stmt (if_stmt);
   THEN_CLAUSE (if_stmt) = push_stmt_list ();
diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-if38.C 

[Bug c++/105885] [12/13 Regression] the address of 'template argument' will never be NULL warning

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

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

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

https://gcc.gnu.org/g:6e4d5300c1f62c3f0cd1bf859b0ee6bb4e31e434

commit r13-1218-g6e4d5300c1f62c3f0cd1bf859b0ee6bb4e31e434
Author: Jason Merrill 
Date:   Wed Jun 22 23:50:23 2022 -0400

c++: -Waddress and value-dependent expr [PR105885]

We already suppress various warnings for code that would be tautological if
written directly, but not when it's the result of template substitution. 
It
seems we need to do this for -Waddress as well.

PR c++/105885

gcc/cp/ChangeLog:

* pt.cc (tsubst_copy_and_build): Also suppress -Waddress for
comparison of dependent operands.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-if37.C: New test.

[pushed] c++: -Waddress and value-dependent expr [PR105885]

[Jason Merrill via Gcc-patches]

We already suppress various warnings for code that would be tautological if
written directly, but not when it's the result of template substitution.  It
seems we need to do this for -Waddress as well.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/105885

gcc/cp/ChangeLog:

* pt.cc (tsubst_copy_and_build): Also suppress -Waddress for
comparison of dependent operands.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-if37.C: New test.
---
 gcc/cp/pt.cc|  1 +
 gcc/testsuite/g++.dg/cpp1z/constexpr-if37.C | 21 +
 2 files changed, 22 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-if37.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 80d2bec2348..4535c14c26a 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -20438,6 +20438,7 @@ tsubst_copy_and_build (tree t,
warning_sentinel s2(warn_div_by_zero, was_dep);
warning_sentinel s3(warn_logical_op, was_dep);
warning_sentinel s4(warn_tautological_compare, was_dep);
+   warning_sentinel s5(warn_address, was_dep);
 
tree r = build_x_binary_op
  (input_location, TREE_CODE (t),
diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-if37.C 
b/gcc/testsuite/g++.dg/cpp1z/constexpr-if37.C
new file mode 100644
index 000..e11e02cfa0e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/constexpr-if37.C
@@ -0,0 +1,21 @@
+// PR c++/105885
+// { dg-do compile { target c++17 } }
+// { dg-additional-options -Wall }
+
+int i;
+
+template
+void test() {
+  if constexpr(ARG == nullptr) {
+++i;
+  } else {
+--i;
+  }
+}
+
+const char CONSTSTR[] = {'\n', '\t', ' ', '\0'};
+
+int main() {
+  test();
+  test();
+}

base-commit: 8a15cd3396aa08dc2633982481fe392af0aa9e78
-- 
2.27.0

[PATCH] c++: constexpr folding in unevaluated context [PR105931]

[Patrick Palka via Gcc-patches]

Changing the type of N from int to unsigned in decltype82.C from
r12-8472-g47ea22015c90df reveals another spot where we perform
constexpr evaluation in an unevaluated context for sake of diagnostics,
this time from the call to shorten_compare in cp_build_binary_op,
which calls fold_for_warn.

We could (and probably should?) suppress the shorten_compare diagnostics
when in an unevaluated context, but there's probably other spots
that have the same bug.  So this patch takes the approach of suppressing
fold_for_warn more generally when in an unevaluated context.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/12?

PR c++/105931

gcc/cp/ChangeLog:

* expr.cc (fold_for_warn): Don't fold when in an unevaluated
context.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/decltype82a.C: New test.
---
 gcc/cp/expr.cc   |  5 +
 gcc/testsuite/g++.dg/cpp0x/decltype82a.C | 11 +++
 2 files changed, 16 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/decltype82a.C

diff --git a/gcc/cp/expr.cc b/gcc/cp/expr.cc
index 31fe0980337..b71245f937d 100644
--- a/gcc/cp/expr.cc
+++ b/gcc/cp/expr.cc
@@ -397,6 +397,11 @@ fold_for_warn (tree x)
 {
   /* C++ implementation.  */
 
+  if (cp_unevaluated_operand)
+/* In an unevaluated context, we don't care about the reduced value
+   of an expression, so neither should any warnings.  */
+return x;
+
   /* Prevent warning-dependent constexpr evaluation from changing
  DECL_UID (which breaks -fcompare-debug) and from instantiating
  templates.  */
diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype82a.C 
b/gcc/testsuite/g++.dg/cpp0x/decltype82a.C
new file mode 100644
index 000..cbbcdfd8e58
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/decltype82a.C
@@ -0,0 +1,11 @@
+// PR c++/105931
+// { dg-do compile { target c++11 } }
+// A version of decltype82.C where N is unsigned.
+
+template
+void f() {
+  using ty1 = decltype((5 % N) == 0);
+  using ty2 = decltype((5 / N) == 0);
+}
+
+template void f<0>();
-- 
2.37.0.rc1

[PATCH] c++: context completion in lookup_template_class [PR105982]

[Patrick Palka via Gcc-patches]

The below testcase demonstrates that completion of the substituted
context during lookup_template_class can end up registering the desired
specialization for us in more cases than r13-1045-gcb7fd1ea85feea
anticipated.  In particular, it can happen for a non-dependent
specialization of a nested class as well.

During overload resolution with A's guides, we substitute the deduced
argument T=int into the TYPENAME_TYPE B::C (*).  This substitution calls
lookup_template_class for A::B with T=int, which completes A
for the first time, which recursively registers the desired specialization
of B for us.  The parent call to lookup_template_class then tries
registering the same specialization, which leads to a crash.

This patch fixes this by making lookup_template_class check the
specializations table after completion of the context iff necessary,
i.e. when the call to complete_type actually has an effect.

(*): Note that the TYPE_CONTEXT of this TYPENAME_TYPE is just the
RECORD_TYPE B instead of TYPENAME_TYPE A::B.  Is this expected?
I'd think maybe_dependent_member_ref would rewrite the reference to B
in terms of another TYPENAME_TYPE.  This is why the testcase needs to
use 'typename B::C' instead of just 'B' -- maybe_dependent_member_ref
rewrites the use of B in the latter case but not the former.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

PR c++/105982

gcc/cp/ChangeLog:

* pt.cc (lookup_template_class): After completion of the
substituted context, check the table again iff the type was
previously incomplete and complete_type made it complete.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction111.C: New test.
---
 gcc/cp/pt.cc  | 21 +++
 .../g++.dg/cpp1z/class-deduction111.C | 10 +
 2 files changed, 22 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/class-deduction111.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 28edc6ae988..eeae867a816 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -10089,16 +10089,19 @@ lookup_template_class (tree d1, tree arglist, tree 
in_decl, tree context,
{
  context = tsubst_aggr_type (context, arglist,
  complain, in_decl, true);
- context = complete_type (context);
- if (is_dependent_type && arg_depth > 1)
+ /* Try completing the enclosing context if it's not already so.  
*/
+ if (context != error_mark_node
+ && !COMPLETE_TYPE_P (context))
{
- /* If this is a dependent nested specialization such as
-A::B [with T=int, U=U], then completion of A
-could have caused to register the desired specialization
-of B already, so check the table again (33959).  */
- entry = type_specializations->find_with_hash (, hash);
- if (entry)
-   return entry->spec;
+ context = complete_type (context);
+ if (COMPLETE_TYPE_P (context))
+   {
+ /* Completion could have caused us to register the desired
+specialization for us, so check the table again.  */
+ entry = type_specializations->find_with_hash (, hash);
+ if (entry)
+   return entry->spec;
+   }
}
}
}
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction111.C 
b/gcc/testsuite/g++.dg/cpp1z/class-deduction111.C
new file mode 100644
index 000..2406529ea5a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction111.C
@@ -0,0 +1,10 @@
+// PR c++/105982
+// { dg-do compile { target c++17 } }
+
+template
+struct A {
+  struct B { struct C { }; };
+  A(T, typename B::C);
+};
+
+A a(0, {});
-- 
2.37.0.rc1

[Bug tree-optimization/106063] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #1 from Andrew Macleod  ---
That option enables legacy EVRP, and will be going away soon.  however, looking
at the IL, the difference out of EVRP is that legacy doesnt touch the code. The
IL is:

  vector(1) __int128 _1;
  vector(1)  _2;
  V _4;

   :
  _1 = v_3(D) & { 15 };
  _2 = v_3(D) == _1;
  _4 = VEC_COND_EXPR <_2, { -1 }, { 0 }>;
  return _4;


Ranger ends up triggering a simplification :

Folding statement: _2 = v_3(D) == _1;
gimple_simplified to _6 = v_3(D) & { -16 };
_2 = _6 == { 0 };
Folded into: _2 = _6 == { 0 };

producing:

_1 = v_3(D) & { 15 };
_6 = v_3(D) & { -16 };
_2 = _6 == { 0 };
_4 = VEC_COND_EXPR <_2, { -1 }, { 0 }>;
return _4;

Which ends up not causing the ICE seen in this PR.

However, if we completely disable EVRP, we also get the trap.

   -O2 -fno-tree-forwprop --disable-tree-evrp

So it would seem the problem probably lies with vector expansion?

Re: [PATCH] libstdc++-v3: check for openat

[Alexandre Oliva via Gcc-patches]

On Jun 23, 2022, Jonathan Wakely  wrote:

> On Thu, 23 Jun 2022 at 12:08, Alexandre Oliva  wrote:
>> 
>> On Jun 22, 2022, Jonathan Wakely  wrote:
>> 
>> > There are other interactions between AT_CDCWD and ::openat not covered
>> > by this patch. I this this also needs to check HAVE_OPENAT:
>> 
>> Here's an updated version, tested with this additional change.

> Did this improve your test results for directory iterators?

'fraid the bad results I posted earlier today had this patch in.  I
can't tell whether it improved anything because I didn't save earlier
results to compare.

> In the unlikely even that the target has ::unlinkat but not ::openat

c++config.h on the target says:

/* #undef _GLIBCXX_HAVE_UNLINKAT */

Thanks for the concern,

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Add fnspec attributes to cxa_* functions

[Jan Hubicka via Gcc-patches]

Hi,
this patch adds fnspecs for cxa_* functions in except.cc.  Main goal is to make
modref to see proper side-effects of functions which may throw. So in general
we get
 - cxa_allocate_exception
which gets the same annotations as malloc (since it is kind of same thing)
 - cxa_free_exception
which gets the same annotations as free
 - cxa_throw which is marked as const except for first parameter which is 
believed
that it makes it escape (which is necessary) and modify (which is not 
necessary
but it would matter inly if we would like to do constant propagation across
EH edges.

Honza
 
gcc/cp/ChangeLog:

2022-06-23  Jan Hubicka  

* except.cc (declare_library_fn_1): Add fnspec parameter.
(declare_library_fn): Add fnspec parameter.
(do_allocate_exception): Declare fnspecs.
(do_free_exception): Declare fnspecs.
(build_throw): Declare fnspecs.

gcc/testsuite/ChangeLog:

2022-06-23  Jan Hubicka  

* g++.dg/opt/eh6.C: New test.
* g++.dg/tree-ssa/kill.C: New test.

diff --git a/gcc/cp/except.cc b/gcc/cp/except.cc
index da0a65c613d..bb9a5aee6da 100644
--- a/gcc/cp/except.cc
+++ b/gcc/cp/except.cc
@@ -133,13 +133,14 @@ build_exc_ptr (void)
 }
 
 /* Declare an exception ABI entry point called NAME.
-   ECF are the library flags, RTYPE the return type and ARGS[NARGS]
+   ECF are the library flags, FNSPEC is the attr "fn spec" string (or NULL),
+   RTYPE the return type and ARGS[NARGS]
the parameter types.  We return the DECL -- which might be one
found via the symbol table pushing, if the user already declared
it.  If we pushed a new decl, the user will see it.  */
 
 static tree
-declare_library_fn_1 (const char *name, int ecf,
+declare_library_fn_1 (const char *name, int ecf, const char *fnspec,
  tree rtype, int nargs, tree args[])
 {
   tree ident = get_identifier (name);
@@ -150,6 +151,14 @@ declare_library_fn_1 (const char *name, int ecf,
   for (unsigned ix = nargs; ix--;)
 arg_list = tree_cons (NULL_TREE, args[ix], arg_list);
   tree fntype = build_function_type (rtype, arg_list);
+  if (fnspec)
+{
+  tree attr_args = build_tree_list (NULL_TREE,
+   build_string (strlen (fnspec), fnspec));
+  tree attrs = tree_cons (get_identifier ("fn spec"),
+ attr_args, TYPE_ATTRIBUTES (fntype));
+  fntype = build_type_attribute_variant (fntype, attrs);
+}
   tree res = push_library_fn (ident, fntype, except, ecf);
 
   return res;
@@ -157,7 +166,8 @@ declare_library_fn_1 (const char *name, int ecf,
 
 /* Find or declare a function NAME, returning RTYPE, taking a single
parameter PTYPE, with an empty exception specification. ECF are the
-   library fn flags.  If TM_ECF is non-zero, also find or create a
+   library fn flags.  FNSPEC is the attr "fn spec" string (or NULL).
+   If TM_ECF is non-zero, also find or create a
transaction variant and record it as a replacement, when flag_tm is
in effect.
 
@@ -167,9 +177,10 @@ declare_library_fn_1 (const char *name, int ecf,
 
 static tree
 declare_library_fn (const char *name, tree rtype, tree ptype,
-   int ecf, int tm_ecf)
+   int ecf, int tm_ecf, const char *fnspec = NULL)
 {
-  tree res = declare_library_fn_1 (name, ecf, rtype, ptype ? 1 : 0, );
+  tree res = declare_library_fn_1 (name, ecf, fnspec,
+  rtype, ptype ? 1 : 0, );
   if (res == error_mark_node)
 return res;
 
@@ -177,7 +188,7 @@ declare_library_fn (const char *name, tree rtype, tree 
ptype,
 {
   char *tm_name = concat ("_ITM_", name + 2, NULL_TREE);
 
-  tree tm_fn = declare_library_fn_1 (tm_name, ecf | tm_ecf, rtype,
+  tree tm_fn = declare_library_fn_1 (tm_name, ecf | tm_ecf, fnspec, rtype,
 ptype ? 1 : 0, );
   free (tm_name);
   if (tm_fn != error_mark_node)
@@ -547,7 +558,8 @@ do_allocate_exception (tree type)
 allocate_exception_fn
   = declare_library_fn ("__cxa_allocate_exception",
ptr_type_node, size_type_node,
-   ECF_NOTHROW | ECF_MALLOC | ECF_COLD, ECF_TM_PURE);
+   ECF_NOTHROW | ECF_MALLOC | ECF_COLD, ECF_TM_PURE,
+   "mc");
 
   return cp_build_function_call_nary (allocate_exception_fn,
  tf_warning_or_error,
@@ -565,7 +577,8 @@ do_free_exception (tree ptr)
 free_exception_fn
   = declare_library_fn ("__cxa_free_exception",
void_type_node, ptr_type_node,
-   ECF_NOTHROW | ECF_LEAF, ECF_TM_PURE);
+   ECF_NOTHROW | ECF_LEAF, ECF_TM_PURE,
+   ".co ");
 
   return cp_build_function_call_nary (free_exception_fn,
  tf_warning_or_error, ptr, NULL_TREE);
@@ -653,11 +666,13 @@ build_throw 

[Bug testsuite/106059] [13 regression] cc.dg/vect/pr79347.c fails after r13-1171-g9f55aee9dca759

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

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

--- Comment #1 from Segher Boessenkool  ---
Well, this patch should not have changed behaviour at all!

Re: Fix stmt_kills_ref_p wrt external throws

[Richard Biener via Gcc-patches]

On Thu, 23 Jun 2022, Jan Hubicka wrote:

> Hi,
> this patch adds missing check to stmt_kills_ref_p for case that function
> is terminated by EH before call return value kills the ref. In the PR
> I tried to construct testcase but I don't know how to do that until I 
> annotate EH code with fnspec attributes which I will do in separate patch
> and add a testcase.
> 
> Bootstrapped/regtested x86_64-linux, OK?
> 
>   PR ipa/106057
>   * tree-ssa-alias.cc (stmt_kills_ref_p): Check for external throw.
> diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc
> index b1e7a2d5afc..e427ee6744a 100644
> --- a/gcc/tree-ssa-alias.cc
> +++ b/gcc/tree-ssa-alias.cc
> @@ -87,10 +87,11 @@ along with GCC; see the file COPYING3.  If not see
>  
>   This function tries to disambiguate two reference trees.
>  
> -   bool ptr_deref_may_alias_global_p (tree)
> +   bool ptr_deref_may_alias_global_p (tree, bool)
>  
>   This function queries if dereferencing a pointer variable may
> - alias global memory.
> + alias global memory.  If bool argument is true, global memory
> + is considered to also include function local memory that escaped.
>  
> More low-level disambiguators are available and documented in
> this file.  Low-level disambiguators dealing with points-to
> @@ -,11 +3334,18 @@ stmt_kills_ref_p (gimple *stmt, ao_ref *ref)
>&& TREE_CODE (gimple_get_lhs (stmt)) != SSA_NAME
>/* The assignment is not necessarily carried out if it can throw
>and we can catch it in the current function where we could inspect
> -  the previous value.
> +  the previous value.  Similarly if the function can throw externally
> +  and the ref does not diea on the function return.

die.

>???  We only need to care about the RHS throwing.  For aggregate
>assignments or similar calls and non-call exceptions the LHS
> -  might throw as well.  */
> -  && !stmt_can_throw_internal (cfun, stmt))
> +  might throw as well.
> +  ???  We also should care about possible longjmp, but since we
> +  do not understand that longjmp is not using global memory we will
> +  not consider a kill here since the function call will be considered
> +  as possibly using REF.  */
> +  && !stmt_can_throw_internal (cfun, stmt)
> +  && (!stmt_can_throw_external (cfun, stmt)
> +   || !ref_may_alias_global_p (ref, false)))
>  {
>tree lhs = gimple_get_lhs (stmt);
>/* If LHS is literally a base of the access we are done.  */
> @@ -3434,8 +3442,12 @@ stmt_kills_ref_p (gimple *stmt, ao_ref *ref)
> && node->binds_to_current_def_p ()
> && (summary = get_modref_function_summary (node)) != NULL
> && summary->kills.length ()
> +   /* Check that we can not trap while evaulating function
> +  parameters.  This check is overly conservative.  */
> && (!cfun->can_throw_non_call_exceptions
> -   || !stmt_can_throw_internal (cfun, stmt)))
> +   || (!stmt_can_throw_internal (cfun, stmt)
> +   && (!stmt_can_throw_external (cfun, stmt)
> +   || !ref_may_alias_global_p (ref, stmt)

you wanted , false here instead of , stmt?

OK otherwise.

Thanks,
Richard.

>   {
> for (auto kill : summary->kills)
>   {
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstra

Fix stmt_kills_ref_p wrt external throws

[Jan Hubicka via Gcc-patches]

Hi,
this patch adds missing check to stmt_kills_ref_p for case that function
is terminated by EH before call return value kills the ref. In the PR
I tried to construct testcase but I don't know how to do that until I 
annotate EH code with fnspec attributes which I will do in separate patch
and add a testcase.

Bootstrapped/regtested x86_64-linux, OK?

PR ipa/106057
* tree-ssa-alias.cc (stmt_kills_ref_p): Check for external throw.
diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc
index b1e7a2d5afc..e427ee6744a 100644
--- a/gcc/tree-ssa-alias.cc
+++ b/gcc/tree-ssa-alias.cc
@@ -87,10 +87,11 @@ along with GCC; see the file COPYING3.  If not see
 
  This function tries to disambiguate two reference trees.
 
-   bool ptr_deref_may_alias_global_p (tree)
+   bool ptr_deref_may_alias_global_p (tree, bool)
 
  This function queries if dereferencing a pointer variable may
- alias global memory.
+ alias global memory.  If bool argument is true, global memory
+ is considered to also include function local memory that escaped.
 
More low-level disambiguators are available and documented in
this file.  Low-level disambiguators dealing with points-to
@@ -,11 +3334,18 @@ stmt_kills_ref_p (gimple *stmt, ao_ref *ref)
   && TREE_CODE (gimple_get_lhs (stmt)) != SSA_NAME
   /* The assignment is not necessarily carried out if it can throw
 and we can catch it in the current function where we could inspect
-the previous value.
+the previous value.  Similarly if the function can throw externally
+and the ref does not diea on the function return.
 ???  We only need to care about the RHS throwing.  For aggregate
 assignments or similar calls and non-call exceptions the LHS
-might throw as well.  */
-  && !stmt_can_throw_internal (cfun, stmt))
+might throw as well.
+???  We also should care about possible longjmp, but since we
+do not understand that longjmp is not using global memory we will
+not consider a kill here since the function call will be considered
+as possibly using REF.  */
+  && !stmt_can_throw_internal (cfun, stmt)
+  && (!stmt_can_throw_external (cfun, stmt)
+ || !ref_may_alias_global_p (ref, false)))
 {
   tree lhs = gimple_get_lhs (stmt);
   /* If LHS is literally a base of the access we are done.  */
@@ -3434,8 +3442,12 @@ stmt_kills_ref_p (gimple *stmt, ao_ref *ref)
  && node->binds_to_current_def_p ()
  && (summary = get_modref_function_summary (node)) != NULL
  && summary->kills.length ()
+ /* Check that we can not trap while evaulating function
+parameters.  This check is overly conservative.  */
  && (!cfun->can_throw_non_call_exceptions
- || !stmt_can_throw_internal (cfun, stmt)))
+ || (!stmt_can_throw_internal (cfun, stmt)
+ && (!stmt_can_throw_external (cfun, stmt)
+ || !ref_may_alias_global_p (ref, stmt)
{
  for (auto kill : summary->kills)
{

Re: [PATCH] RISC-V: Split unordered FP comparisons into individual RTL insns

[Maciej W. Rozycki]

On Thu, 9 Jun 2022, Maciej W. Rozycki wrote:

>  I'm yet running some benchmarking to see if the use of UNSPEC_VOLATILEs 
> makes any noticeable performance difference, but I suspect it does not as 
> the compiler could not do much about the original multiple-instruction 
> single RTL insns anyway.

 This has now finally completed.  I used SPECfp 2006 built at `-O3' and 
statically linked, which needs ~33 hours per run with the HiFive Unmatched 
board at its standard 1196MHz clock rate.  Here are the results merged by 
hand from original reports:

   Base Base Base Base   Est Base  Est Base  Est Base   
Benchmarks Ref.   Run Time Run Time Run Time   Ratio Ratio Ratio  
   (base)  (length) (split)   (base)   (length)   (split)  
- --  ---  ---  ---       
410.bwaves 135901035310396103701.31  1.31  1.31   
416.gamess 19580 9080 9410 92842.16  2.08  2.11   
433.milc9180 5465 5475 56101.68  1.68  1.64   
434.zeusmp  9100 5773 5767 57611.58  1.58  1.58   
435.gromacs 7140 3605 3561 35451.98  2.00  2.01   
436.cactusADM  11950 7779 7658 76801.54  1.56  1.56   
437.leslie3d94001028010697102740.914 0.879 0.915  
444.namd8020 3141 3120 31292.55  2.57  2.56   
447.dealII 11440 3459 3490 34953.31  3.28  3.27   
450.soplex  8340 4698 4899 47811.78  1.70  1.74   
453.povray  5320 1953 1922 19162.72  2.77  2.78   
454.calculix8250 4844 4857 48211.70  1.70  1.71   
459.GemsFDTD   10610 8703 8957 90281.22  1.18  1.18   
465.tonto   9840 4585 4539 46202.15  2.17  2.13   
470.lbm137401017210945107891.35  1.26  1.27   
481.wrf11170 8516 8646 85841.31  1.29  1.30   
482.sphinx319490 9240 9267 92802.11  2.10  2.10   
==

The execution time reference (second column) is for a Sun Ultra Enterprise 
2 system from 1997, based on a 296MHz UltraSPARC II CPU, times are given 
in seconds (lower is better) and the ratios calculated are in relation to 
the reference (higher is better).

In the table above "base" results are with upstream master as at commit 
7b98910406b5 ("c++: ICE with template NEW_EXPR [PR105803]".  Then "length" 
results are with commit 72b185189f91 ("RISC-V: Reset the length to the 
default of 4 for FP comparisons") applied on top, as it does make changes 
to code produced even at `-O3' (where size matters less than speed), e.g.:

46b2c:  8d01b787fld fa5,-1840(gp) # 7760a8 
<__SDATA_BEGIN__+0xd0>
-   46b30:  66f4b027fsd fa5,1632(s1)
-   46b34:  a029j   46b3e 
-   46b36:  8c01b787fld fa5,-1856(gp) # 776098 
<__SDATA_BEGIN__+0xc0>
-   46b3a:  66f4b027fsd fa5,1632(s1)
-   46b3e:  00ab67b7lui a5,0xab6
-   46b42:  0a07b707fld fa4,160(a5) # ab60a0 
-   46b46:  8d81b787fld fa5,-1832(gp) # 7760b0 
<__SDATA_BEGIN__+0xd8>
-   46b4a:  a2f727d3feq.d   a5,fa4,fa5
-   46b4e:  18079fe3bneza5,474ec 
-   46b52:  00afd7b7lui a5,0xafd
-   46b56:  4607a703lw  a4,1120(a5) # afd460 

-   46b5a:  4785li  a5,1
-   46b5c:  18f708e3beq a4,a5,474ec 
-   46b60:  00aaeab7lui s5,0xaae
-   46b64:  d70a8a93addis5,s5,-656 # aadd70 
-   46b68:  008aa783lw  a5,8(s5)
-   46b6c:  8301b707fld fa4,-2000(gp) # 776008 
<__SDATA_BEGIN__+0x30>
-   46b70:  37fdaddiw   a5,a5,-1
+   46b30:  00ab67b7lui a5,0xab6
+   46b34:  0a07b707fld fa4,160(a5) # ab60a0 
+   46b38:  66f4b027fsd fa5,1632(s1)
+   46b3c:  8d81b787fld fa5,-1832(gp) # 7760b0 
<__SDATA_BEGIN__+0xd8>
+   46b40:  a2f727d3feq.d   a5,fa4,fa5
+   46b44:  c39dbeqza5,46b6a 
+   46b46:  8901b787fld fa5,-1904(gp) # 776068 
<__SDATA_BEGIN__+0x90>
+   46b4a:  66f4b027fsd fa5,1632(s1)
+   46b4e:  a02dj   46b78 
+   46b50:  8c01b787fld fa5,-1856(gp) # 776098 
<__SDATA_BEGIN__+0xc0>
+   46b54:  66f4b027fsd fa5,1632(s1)
+   46b58:  

[Bug fortran/106065] New: Crash when reading extended derived type array in namelist

[philippe.wautelet at aero dot obs-mip.fr via Gcc-bugs]

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

Bug ID: 106065
   Summary: Crash when reading extended derived type array in
namelist
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: philippe.wautelet at aero dot obs-mip.fr
  Target Milestone: ---

Created attachment 53195
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53195=edit
Reproducer

I get a crash when using an array of extended derived types.
If I define an other type containing the same information but not extended, the
problem disappears.

See the attached source:
> gfortran type_extends_nml.f90 ;./a.out

_BAL_NE
 DATE_TIME_NE(1)%NYEAR=   2022,
 DATE_TIME_NE(1)%NMONTH=  0,
 DATE_TIME_NE(1)%NDAY=  0,
 DATE_TIME_NE(1)%XTIME=  0.,
 DATE_TIME_NE(2)%NYEAR=  0,
 DATE_TIME_NE(2)%NMONTH=  0,
 DATE_TIME_NE(2)%NDAY=  0,
 DATE_TIME_NE(2)%XTIME=  1.2337,
 /
At line 36 of file type_extends_nml.f90
Fortran runtime error: Cannot match namelist object name 2022

I tested with several versions of gfortran from version 5.5.0 to 12.1.0. All
failed.

[Bug c++/106062] [13 Regression] ICE in build_builtin_unreachable since r13-1204-gd68d366425369649

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug c++/106062] [13 Regression] ICE in build_builtin_unreachable since r13-1204-gd68d366425369649

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r13-1217-g8a15cd3396aa08dc2633982481fe392af0aa9e78
Author: Martin Liska 
Date:   Thu Jun 23 14:43:50 2022 +0200

c++: properly initialize UBSAN built-ins

PR c++/106062

gcc/ChangeLog:

* ubsan.cc (sanitize_unreachable_fn): Change order of calls
in order to initialize UBSAN built-ins.

gcc/testsuite/ChangeLog:

* gfortran.dg/ubsan/pr106062.f90: New test.

[PATCH][PUSHED] c++: properly initialize UBSAN built-ins

[Martin Liška]

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Pushed based on Jakub's approval.

Thanks,
Martin

PR c++/106062

gcc/ChangeLog:

* ubsan.cc (sanitize_unreachable_fn): Change order of calls
in order to initialize UBSAN built-ins.

gcc/testsuite/ChangeLog:

* gfortran.dg/ubsan/pr106062.f90: New test.
---
 gcc/testsuite/gfortran.dg/ubsan/pr106062.f90 | 11 +++
 gcc/ubsan.cc |  3 ++-
 2 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/ubsan/pr106062.f90

diff --git a/gcc/testsuite/gfortran.dg/ubsan/pr106062.f90 
b/gcc/testsuite/gfortran.dg/ubsan/pr106062.f90
new file mode 100644
index 000..879a67eb749
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/ubsan/pr106062.f90
@@ -0,0 +1,11 @@
+! PR c++/106062
+! { dg-do compile }
+! { dg-options "-O2 -fsanitize=undefined" }
+
+call test (reshape ((/ 'a', 'b', 'c', 'd' /), (/ 2, 2 /)))
+contains
+  subroutine test (a)
+character (*), dimension (:, :) :: a
+if (len (a) .ne. 1) STOP 
+  end  
+end
diff --git a/gcc/ubsan.cc b/gcc/ubsan.cc
index f15026872a1..b6c4301dfaf 100644
--- a/gcc/ubsan.cc
+++ b/gcc/ubsan.cc
@@ -654,9 +654,10 @@ sanitize_unreachable_fn (tree *data, location_t loc)
 }
   else if (san)
 {
-  fn = builtin_decl_explicit (BUILT_IN_UBSAN_HANDLE_BUILTIN_UNREACHABLE);
+  /* Call ubsan_create_data first as it initializes SANITIZER built-ins.  
*/
   *data = ubsan_create_data ("__ubsan_unreachable_data", 1, ,
 NULL_TREE, NULL_TREE);
+  fn = builtin_decl_explicit (BUILT_IN_UBSAN_HANDLE_BUILTIN_UNREACHABLE);
   *data = build_fold_addr_expr_loc (loc, *data);
 }
   else
-- 
2.36.1

[Bug c++/106062] [13 Regression] ICE in build_builtin_unreachable since r13-1204-gd68d366425369649

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

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

Martin Liška  changed:

   What|Removed |Added

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

Re: [PATCH] libstdc++: testsuite: fs rename to self may fail

[Alexandre Oliva via Gcc-patches]

On Jun 23, 2022, Jonathan Wakely  wrote:

>> Regstrapped on x86_64-linux-gnu, also tested with a cross to
>> aarch64-rtems6.  Ok to install?

> OK, thanks.

Sorry, I failed to refresh this one too.
Here's what I'm going to install:

libstdc++: xfail rename tests on rtems

From: Alexandre Oliva 

::rename on RTEMS does not meet several POSIX requirements, despite
compliance with C and C++ standards.  ::std::filesystem::rename, in
turn, has requirements borrowed from POSIX, so it would have to be a
lot more than a simple wrapper around ::rename on RTEMS, and even then
fall short.

Until RTEMS reimplements ::rename for POSIX compliance, expect
filesystem rename tests to fail on it.


for  libstdc++-v3/ChangeLog

* testsuite/27_io/filesystem/operations/rename.cc: xfail on
rtems.
* testsuite/experimental/filesystem/operations/rename.cc:
Likewise.
---
 .../27_io/filesystem/operations/rename.cc  |1 +
 .../experimental/filesystem/operations/rename.cc   |1 +
 2 files changed, 2 insertions(+)

diff --git a/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc
index b74e1133a7618..983374f42e448 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++17 } }
 // { dg-require-filesystem-ts "" }
+// { dg-xfail-run-if "rename is not POSIX-compliant" { *-*-rtems* } }
 
 #include 
 #include 
diff --git 
a/libstdc++-v3/testsuite/experimental/filesystem/operations/rename.cc 
b/libstdc++-v3/testsuite/experimental/filesystem/operations/rename.cc
index 37e743b770fdf..762b943888f9e 100644
--- a/libstdc++-v3/testsuite/experimental/filesystem/operations/rename.cc
+++ b/libstdc++-v3/testsuite/experimental/filesystem/operations/rename.cc
@@ -18,6 +18,7 @@
 // { dg-options "-DUSE_FILESYSTEM_TS -lstdc++fs" }
 // { dg-do run { target c++11 } }
 // { dg-require-filesystem-ts "" }
+// { dg-xfail-run-if "rename is not POSIX-compliant" { *-*-rtems* } }
 
 #include 
 #include 


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] libstdc++: testsuite: use -lbsd for net_ts on RTEMS

[Alexandre Oliva via Gcc-patches]

On Jun 23, 2022, Jonathan Wakely  wrote:

> On Thu, 23 Jun 2022 at 12:26, Alexandre Oliva via Libstdc++
>  wrote:

>> I was using something like this internally.  Regstrapped on
>> x86_64-linux-gnu, also tested with a cross to aarch64-rtems6.  Ok to
>> install?

> OK, thanks.

Sorry, I goofed when testing this, and another internal xfail machinery
hid the bug: I had to use dg-xfail-run-if instead.

I caught that later, but it looks like I failed to refresh the xfail
patchfiles I posted :-(

I'm going ahead and check it in assuming this is what you meant to
approve, but only after catching some sleep, because it's been a long
day and I don't want any more goofs ;-)


libstdc++: xfail io_context/pipe users on rtems

From: Alexandre Oliva 

A handful of tests fail on rtems because pipe() always returns -1, and
the io_context ctor throws a system error when pipe() fails.


for  libstdc++-v3/ChangeLog

* testsuite/experimental/net/timer/waitable/cons.cc: xfail on
RTEMS.
* testsuite/experimental/net/timer/waitable/dest.cc: Likewise.
* testsuite/experimental/net/timer/waitable/ops.cc: Likewise.
* testsuite/experimental/net/internet/resolver/ops/lookup.cc:
Likewise.
* testsuite/experimental/net/internet/resolver/ops/reverse.cc:
Likewise.

TN: V617-003
---
 .../net/internet/resolver/ops/lookup.cc|1 +
 .../net/internet/resolver/ops/reverse.cc   |1 +
 .../experimental/net/timer/waitable/cons.cc|1 +
 .../experimental/net/timer/waitable/dest.cc|1 +
 .../experimental/net/timer/waitable/ops.cc |1 +
 5 files changed, 5 insertions(+)

diff --git 
a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc 
b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
index eb411dea8369c..0ac9cb3513d7e 100644
--- a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
@@ -18,6 +18,7 @@
 // { dg-do run { target c++14 } }
 // { dg-require-effective-target net_ts_ip }
 // { dg-add-options net_ts }
+// { dg-xfail-run-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #include 
 #include 
diff --git 
a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc 
b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc
index 361df2676efc8..dfdf855c68cd7 100644
--- a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc
@@ -18,6 +18,7 @@
 // { dg-do run { target c++14 } }
 // { dg-require-effective-target net_ts_ip }
 // { dg-add-options net_ts }
+// { dg-xfail-run-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc 
b/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc
index 40ae5b965a2b0..f013278675d33 100644
--- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc
+++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++14 } }
 // { dg-add-options libatomic }
+// { dg-xfail-run-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc 
b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
index f571f4a8d861a..dc557d01a9136 100644
--- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
+++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++14 } }
 // { dg-add-options libatomic }
+// { dg-xfail-run-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc 
b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
index 97ab629b893a9..f7549def38925 100644
--- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
+++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++14 } }
 // { dg-add-options libatomic }
+// { dg-xfail-run-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #include 
 #include 


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about