[Bug fortran/99145] gfortran LOOP

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Vittorio Zecca  ---
(In reply to Jerry DeLisle from comment #3)
> Initially it is creating the very large string in the frontend passes and
> then via resolution and translation phases, and finally into the middle-end
> and back end phases where it I am guessing the optimizers are realizing the
> simplifications.
> 
> It is a known that some of these special cases are not recognized in the
> front end and immediately reduced.  In this case it is creating a literal
> constant that big. Normally a program would be attempting to use the
> parameter in more than one place in which case it is literally substituted
> in.
> 
> Should we mark this as invalid?

Yes, please.

[Bug fortran/99147] Sanitizer detects heap-use-after-free in gfc_add_flavor

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Vittorio Zecca  ---
I ran the testsuite against the proposed fix and it was successful, no
sanitizer errors in symbol.c.

Only remaining error as in bug 99148.

[PATCH v3 2/2] MIPS: add builtime option for -mcompact-branches

[YunQiang Su]

For R6+ target, it allows to configure gcc to use compact branches only.

gcc/ChangeLog:
* config.gcc: add -with-compact-branches=policy build option.
* doc/install.texi: Likewise.
---
 gcc/ChangeLog|  5 +
 gcc/config.gcc   | 12 +++-
 gcc/doc/install.texi | 19 +++
 3 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index caa3fda48ce..c5fae50e782 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2021-02-20  YunQiang Su  
+
+   * config.gcc: add -with-compact-branches=policy build option.
+   * doc/install.texi: Likewise.
+
 2021-02-20  YunQiang Su  
 
* config/mips/mips.c (mips_option_override):
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 17fea83b2e4..047f5631067 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4743,7 +4743,7 @@ case "${target}" in
;;
 
mips*-*-*)
-   supported_defaults="abi arch arch_32 arch_64 float fpu nan 
fp_32 odd_spreg_32 tune tune_32 tune_64 divide llsc mips-plt synci lxc1-sxc1 
madd4"
+   supported_defaults="abi arch arch_32 arch_64 float fpu nan 
fp_32 odd_spreg_32 tune tune_32 tune_64 divide llsc mips-plt synci lxc1-sxc1 
madd4 compact-branches"
 
case ${with_float} in
"" | soft | hard)
@@ -4896,6 +4896,16 @@ case "${target}" in
exit 1
;;
esac
+
+   case ${with_compact_branches} in
+   never | always | optimal)
+   with_compact_branches=${with_compact_branches}
+   ;;
+   *)
+   echo "Unknown compact-branches policy used in 
--with-compact-branches" 1>&2
+   exit 1
+   ;;
+   esac
;;
 
nds32*-*-*)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 4c38244ae58..865630826c6 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -1464,6 +1464,25 @@ systems that support conditional traps).
 Division by zero checks use the break instruction.
 @end table
 
+@item --with-compact-branches=@var{policy}
+Specify how the compiler should generate code for checking for
+division by zero.  This option is only supported on the MIPS target.
+The possibilities for @var{type} are:
+@table @code
+@item optimal
+Cause a delay slot branch to be used if one is available in the
+current ISA and the delay slot is successfully filled. If the delay slot
+is not filled, a compact branch will be chosen if one is available.
+@item never
+Ensures that compact branch instructions will never be generated.
+@item always
+Ensures that a compact branch instruction will be generated if available.
+If a compact branch instruction is not available,
+a delay slot form of the branch will be used instead.
+This option is supported from MIPS Release 6 onwards.
+For pre-R6, this option is just same as never/optimal.
+@end table
+
 @c If you make --with-llsc the default for additional targets,
 @c update the --with-llsc description in the MIPS section below.
 
-- 
2.20.1

[PATCH v3 1/2] MIPS: Not trigger error for pre-R6 and -mcompact-branches=always

[YunQiang Su]

For MIPSr6, we may wish to use compact-branches only.
Currently, we have to use `always' option, while it is mark as conflict
with pre-R6.
  cc1: error: unsupported combination: ‘mips32r2’ -mcompact-branches=always
Just ignore -mcompact-branches=always for pre-R6.

This patch also defines
__mips_compact_branches_never
__mips_compact_branches_always
__mips_compact_branches_optimal
predefined macros

gcc/ChangeLog:
* config/mips/mips.c (mips_option_override):
* config/mips/mips.h (TARGET_RTP_PIC): not trigger error for
compact-branches=always for pre-R6.
(TARGET_CB_NEVER): Likewise.
(TARGET_CB_ALWAYS): Likewise.
(struct mips_cpu_info): define macros for compact branch policy.
* doc/invoke.texi: Document "always" with pre-R6.

gcc/testsuite/ChangeLog:
* gcc.target/mips/compact-branches-1.c: add isa_rev>=6.
* gcc.target/mips/mips.exp: don't add -mipsXXr6 option for
-mcompact-branches=always. It is usable for pre-R6 now.
* gcc.target/mips/compact-branches-8.c: New test.
* gcc.target/mips/compact-branches-9.c: New test.
---
 gcc/ChangeLog | 10 +
 gcc/config/mips/mips.c|  8 +--
 gcc/config/mips/mips.h| 22 ---
 gcc/doc/invoke.texi   |  1 +
 gcc/testsuite/ChangeLog   |  8 +++
 .../gcc.target/mips/compact-branches-1.c  |  2 +-
 .../gcc.target/mips/compact-branches-8.c  | 10 +
 .../gcc.target/mips/compact-branches-9.c  | 10 +
 gcc/testsuite/gcc.target/mips/mips.exp|  4 +---
 9 files changed, 56 insertions(+), 19 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/mips/compact-branches-8.c
 create mode 100644 gcc/testsuite/gcc.target/mips/compact-branches-9.c

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index eb1a44ae676..caa3fda48ce 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,13 @@
+2021-02-20  YunQiang Su  
+
+   * config/mips/mips.c (mips_option_override):
+   * config/mips/mips.h (TARGET_RTP_PIC): not trigger error for
+   compact-branches=always for pre-R6.
+   (TARGET_CB_NEVER): Likewise.
+   (TARGET_CB_ALWAYS): Likewise.
+   (struct mips_cpu_info): define macros for compact branch policy.
+   * doc/invoke.texi: Document "always" with pre-R6.
+
 2021-02-19  Martin Sebor  
 
PR c/97172
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 8bd2d29552e..9a75dd61031 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -20107,13 +20107,7 @@ mips_option_override (void)
   target_flags |= MASK_ODD_SPREG;
 }
 
-  if (!ISA_HAS_COMPACT_BRANCHES && mips_cb == MIPS_CB_ALWAYS)
-{
-  error ("unsupported combination: %qs%s %s",
- mips_arch_info->name, TARGET_MICROMIPS ? " -mmicromips" : "",
- "-mcompact-branches=always");
-}
-  else if (!ISA_HAS_DELAY_SLOTS && mips_cb == MIPS_CB_NEVER)
+  if (!ISA_HAS_DELAY_SLOTS && mips_cb == MIPS_CB_NEVER)
 {
   error ("unsupported combination: %qs%s %s",
  mips_arch_info->name, TARGET_MICROMIPS ? " -mmicromips" : "",
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index b4a60a55d80..b8399fe1b0d 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -103,11 +103,9 @@ struct mips_cpu_info {
 #define TARGET_RTP_PIC (TARGET_VXWORKS_RTP && flag_pic)
 
 /* Compact branches must not be used if the user either selects the
-   'never' policy or the 'optimal' policy on a core that lacks
+   'never' policy or the 'optimal' / 'always' policy on a core that lacks
compact branch instructions.  */
-#define TARGET_CB_NEVER (mips_cb == MIPS_CB_NEVER  \
-|| (mips_cb == MIPS_CB_OPTIMAL \
-&& !ISA_HAS_COMPACT_BRANCHES))
+#define TARGET_CB_NEVER (mips_cb == MIPS_CB_NEVER || !ISA_HAS_COMPACT_BRANCHES)
 
 /* Compact branches may be used if the user either selects the
'always' policy or the 'optimal' policy on a core that supports
@@ -117,10 +115,11 @@ struct mips_cpu_info {
 && ISA_HAS_COMPACT_BRANCHES))
 
 /* Compact branches must always be generated if the user selects
-   the 'always' policy or the 'optimal' policy om a core that
-   lacks delay slot branch instructions.  */
-#define TARGET_CB_ALWAYS (mips_cb == MIPS_CB_ALWAYS\
-|| (mips_cb == MIPS_CB_OPTIMAL \
+   the 'always' policy on a core support compact branches,
+   or the 'optimal' policy on a core that lacks delay slot branch 
instructions.  */
+#define TARGET_CB_ALWAYS ((mips_cb == MIPS_CB_ALWAYS \
+&& ISA_HAS_COMPACT_BRANCHES) \
+|| (mips_cb == MIPS_CB_OPTIMAL   \
 && !ISA_HAS_DELAY_SLOTS))
 
 /* Special handling for JRC that exists in microMIPSR3 as well as R6
@@ -655,6 +654,13 @@ 

[Bug c/99134] S390x: pfpo instructions are not used for dfp[128|64|32] to/from long double conversions

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Ilya Leoshkevich :

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

commit r11-7310-gb6e446cb58183557a5a5d87dc866aae9613544f8
Author: Ilya Leoshkevich 
Date:   Wed Feb 17 14:40:03 2021 +0100

IBM Z: Fix long double <-> DFP conversions

When switching the s390 backend to store long doubles in vector
registers, the patterns for long double <-> DFP conversions were
forgotten.  This did not cause observable problems so far, because
libdfp calls are emitted instead of pfpo.  However, when building
libdfp itself, this leads to infinite recursion.

gcc/ChangeLog:

PR target/99134
* config/s390/vector.md (trunctf2_vr): New
pattern.
(trunctf2): Likewise.
(trunctdtf2_vr): Likewise.
(trunctdtf2): Likewise.
(extendtf2_vr): Likewise.
(extendtf2): Likewise.
(extendtftd2_vr): Likewise.
(extendtftd2): Likewise.

gcc/testsuite/ChangeLog:

PR target/99134
* gcc.target/s390/vector/long-double-from-decimal128.c: New test.
* gcc.target/s390/vector/long-double-from-decimal32.c: New test.
* gcc.target/s390/vector/long-double-from-decimal64.c: New test.
* gcc.target/s390/vector/long-double-to-decimal128.c: New test.
* gcc.target/s390/vector/long-double-to-decimal32.c: New test.
* gcc.target/s390/vector/long-double-to-decimal64.c: New test.

[Bug debug/99178] New: Emit .debug_names

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

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

Bug ID: 99178
   Summary: Emit .debug_names
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

DWARF 5 includes a new index section, .debug_names.
GCC should emit this with -gdwarf-5

Re: [PATCH v7] Practical improvement to libgcc complex divide

[Joseph Myers]

On Fri, 19 Feb 2021, Patrick McGehearty via Gcc-patches wrote:

> > Here you're properly computing the mapping from mode to float.h macro
> > prefix (though I think "modename" is a confusing name for the variable
> > used for float.h macro prefixes; to me, "modename" suggests the names such
> > as SF or DF, which are actually "name" here, and something like
> > "float_h_prefix" would be better than "modename").
> 
> float_h_prefix puts me in mind of half-precision floating point rather than
> float.h.
> How would modeprefix do instead of modename?

I'm not sure modeprefix is better; you could say SF is the prefix of 
SFmode, for example.  Hence my suggestion of a name that makes clear it's 
the prefix *in float.h*.  typeprefix might be a possibility, as it's 
really a prefix associated with a corresponding type rather than directly 
with the mode.

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

[Bug testsuite/99173] new test case c-c++-common/attr-retain-5.c added in r11-7284 fails

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

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

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

Try this.

[Bug tree-optimization/98512] [11 Regression] “#pragma GCC diagnostic ignored” ineffective in conjunction with alias attribute

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

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

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|11.0|12.0

--- Comment #6 from Martin Sebor  ---
The fix has been deferred to GCC 12:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565551.html

[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert

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

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

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|11.0|12.0

--- Comment #32 from Martin Sebor  ---
The solution in
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563862.html has been
deferred to GCC 12:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565551.html

[Bug middle-end/87489] [8/9/10/11 Regression] Spurious -Wnonnull warning

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

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

--- Comment #16 from Martin Sebor  ---
The test case in
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565564.html shows that
running the -Wnonnull pass later, after FRE, allows the warning to detect the
bug in the following test case:

class b {
public:
   long c();
};
class B {
public:
   B() : f() {}
   b *f;
};
long d, e;
class g : B {
public:
   void h() {
 long a = f->c();   <<< -Wnonnull
 d = e = a;
   }
};
class j {
   j();
   g i;
};
j::j() { i.h(); }

My response
(https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565590.html) is copied
below:

> Thanks.  Yes, the warning would be useful here since the f pointer
> in the call to f->c() is null when i.h() is called from j's ctor.
> The FRE3 pass clearly exposes this :
> 
> void j::j (struct j * const this)
> {
>long int _9;
> 
> [local count: 1073741824]:
>MEM[(struct B *)this_3(D)] ={v} {CLOBBER};
>MEM[(struct B *)this_3(D)].f = 0B;
>_9 = b::c (0B);
>...
> 
> Because the warning runs early (after CCP2), the null pointer is
> not detected.  To see it the warning code would have to work quite
> hard to figure out that the two assignments below refer to the same
> location (it would essentially have to do what FRE does):
> 
>MEM[(struct B *)this_3(D)].f = 0B;
>_7 = MEM[(struct b * *)_1];
>_9 = b::c (_7);
> 
> It's probably too late to make this change for GCC 11 as Jeff has
> already decided that it should be deferred until GCC 12, and even
> then there's a concern that doing so might cause false positives.
> I think it's worth revisiting the idea in GCC 12 to see if
> the concern is founded.  Let me make a note of it in the bug.

[Bug c++/99176] [8/9/10/11 Regression] GCC rejects const_cast of null pointer in constant expressions

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
I'll take a look.

[Bug c++/99176] [8/9/10/11 Regression] GCC rejects const_cast of null pointer in constant expressions

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|GCC rejects const_cast of   |[8/9/10/11 Regression] GCC
   |null pointer in constant|rejects const_cast of null
   |expressions |pointer in constant
   ||expressions
   Last reconfirmed||2021-02-19
 Status|UNCONFIRMED |NEW
   Priority|P3  |P2
   Keywords||rejects-valid
   Target Milestone|--- |9.4
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Thanks for the report.  Started with r238909.

Re: [PATCH v7] Practical improvement to libgcc complex divide

[Patrick McGehearty via Gcc-patches]

Comments inline

On 2/19/2021 3:27 PM, Joseph Myers wrote:

On Tue, 2 Feb 2021, Patrick McGehearty via Gcc-patches wrote:


  if (mode == TYPE_MODE (double_type_node))
-   ; /* Empty suffix correct.  */
+   {
+ ; /* Empty suffix correct.  */
+ memcpy (modename, "DBL", 4);
+   }
  else if (mode == TYPE_MODE (float_type_node))
-   suffix[0] = 'f';
+   {
+ suffix[0] = 'f';
+ memcpy (modename, "FLT", 4);
+   }
  else if (mode == TYPE_MODE (long_double_type_node))
-   suffix[0] = 'l';
+   {
+ suffix[0] = 'l';
+ memcpy (modename, "LDBL", 4);
+   }
  else
{
  bool found_suffix = false;
@@ -1305,6 +1316,8 @@ c_cpp_builtins (cpp_reader *pfile)
sprintf (suffix, "f%d%s", floatn_nx_types[i].n,
 floatn_nx_types[i].extended ? "x" : "");
found_suffix = true;
+   sprintf (modename, "FLT%d%s", floatn_nx_types[i].n,
+floatn_nx_types[i].extended ? "X" : "");
break;
  }
  gcc_assert (found_suffix);

Here you're properly computing the mapping from mode to float.h macro
prefix (though I think "modename" is a confusing name for the variable
used for float.h macro prefixes; to me, "modename" suggests the names such
as SF or DF, which are actually "name" here, and something like
"float_h_prefix" would be better than "modename").


float_h_prefix puts me in mind of half-precision floating point rather 
than float.h.

How would modeprefix do instead of modename?




+ if ((mode == TYPE_MODE (float_type_node))
+ || (mode == TYPE_MODE (double_type_node))
+ || (mode == TYPE_MODE (long_double_type_node)))

But then here you still have the check for the mode matching one of those
three types, which defeats the point of computing the prefix in a way that
works for *all* floating-point modes supported in libgcc.  (The above
"gcc_assert (found_suffix)" asserts that the relevant mapping did get
found.)

To be able to use the __LIBGCC_* macros in libgcc in all cases, they
should be defined, using the modename (or float_h_prefix) found above,
whether or not the mode matches one of float, double and long double.


My apologies. You are completely correct. I intended to remove the "mode 
== TYPE_MODE" code

when making the other changes but overlooked it.




  #elif defined(L_multc3) || defined(L_divtc3)
  # define MTYPETFtype
  # define CTYPETCtype
  # define MODE tc
  # define CEXT __LIBGCC_TF_FUNC_EXT__
  # define NOTRUNC (!__LIBGCC_TF_EXCESS_PRECISION__)
+#if defined(__LIBGCC_TF_MIN__)
+# define RBIG  ((__LIBGCC_TF_MAX__)/2)
+# define RMIN  (__LIBGCC_TF_MIN__)
+# define RMIN2 (__LIBGCC_TF_EPSILON__)
+# define RMINSCAL (1/__LIBGCC_TF_EPSILON__)
+#else
+# define RBIG  ((__LIBGCC_XF_MAX__)/2)
+# define RMIN  (__LIBGCC_XF_MIN__)
+# define RMIN2 (__LIBGCC_XF_EPSILON__)
+# define RMINSCAL (1/__LIBGCC_XF_EPSILON__)
+#endif

Once you've removed the unnecessary conditional above, you don't need this
conditional on __LIBGCC_TF_MIN__ being defined either; the *TF* macros
will always be defined when TFmode is supported in libgcc, so you never
need to use *XF* macros instead when building TFmode code.
And as you note, the test for LIBGCC_TF_MIN being defined is not needed 
either.


I'll resubmit the patch after I rebuild and complete testings on the 
revised code.


- patrick

[Bug testsuite/99177] New: FAIL: g++.dg/modules/adl-1 -std=c++17 link

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

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

Bug ID: 99177
   Summary: FAIL: g++.dg/modules/adl-1 -std=c++17 link
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu/gcc/objdir/gcc/testsuite/g++/../../ adl-1_a.s adl-1_b.s adl-1_c.s
-fdiagnostics-plain-output -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++17
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -lm -o
./adl-1.exe
/usr/ccs/bin/ld: Unsatisfied symbols:
   _ZGIW5interEv (first referenced in /var/tmp//ccoDSegQ.o) (data)
   _ZGIW6workerEv (first referenced in /var/tmp//ccovdX7c.o) (data)
collect2: error: ld returned 1 exit status
compiler exited with status 1
output is:
/usr/ccs/bin/ld: Unsatisfied symbols:
   _ZGIW5interEv (first referenced in /var/tmp//ccoDSegQ.o) (data)
   _ZGIW6workerEv (first referenced in /var/tmp//ccovdX7c.o) (data)
collect2: error: ld returned 1 exit status

FAIL: g++.dg/modules/adl-1 -std=c++17 link
UNRESOLVED: g++.dg/modules/adl-1 -std=c++17 execute

[Bug c++/99176] New: GCC rejects const_cast of null pointer in constant expressions

[richard-gccbugzilla at metafoo dot co.uk via Gcc-bugs]

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

Bug ID: 99176
   Summary: GCC rejects const_cast of null pointer in constant
expressions
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

GCC rejects:

constexpr const int *p = nullptr;
constexpr int *q = const_cast(p);

saying:

:2:20: error: conversion of 'const int*' null pointer to 'int*' is not
a constant expression
2 | constexpr int *q = const_cast(p);
  |^~~

I don't think any such rule exists, and other compilers accept. This only
appears to affect const_casts of null pointers; non-null pointer const casts
seem to work OK. Perhaps GCC thinks that this is a reinterpret_cast / cast from
void* or something like that?

It looks like this regressed between GCC 6 and GCC 7.

[Bug testsuite/99175] New: FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for errors, line )

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

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

Bug ID: 99175
   Summary: FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17  (test
for errors, line )
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu/gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C
-fdiagnostics-plain-output -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++17
-pedantic-errors -Wno-long-long -fmodules-ts
-fmodule-mapper=|this-will-not-work -S -o bad-mapper-1.s
cc1plus: error trying to exec 'this-will-not-work': execvp: No such file or
directory
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C: error: failed
mapper handshake communication error:Broken pipe
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C:2:1: error:
unknown Compiled Module Interface: communication error:Broken pipe
In module imported at
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C:2:1:
unique1.bob: error: failed to read compiled module: Unknown CMI mapping
unique1.bob: note: imports must be built before being imported
unique1.bob: fatal error: returning to the gate for a mechanical issue
compilation terminated.
compiler exited with status 1
output is:
cc1plus: error trying to exec 'this-will-not-work': execvp: No such file or
directory
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C: error: failed
mapper handshake communication error:Broken pipe
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C:2:1: error:
unknown Compiled Module Interface: communication error:Broken pipe
In module imported at
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C:2:1:
unique1.bob: error: failed to read compiled module: Unknown CMI mapping
unique1.bob: note: imports must be built before being imported
unique1.bob: fatal error: returning to the gate for a mechanical issue
compilation terminated.

FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17  (test for errors, line )
FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for excess errors)
Excess errors:
cc1plus: error trying to exec 'this-will-not-work': execvp: No such file or
directory
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C: error: failed
mapper handshake communication error:Broken pipe
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C:2:1: error:
unknown Compiled Module Interface: communication error:Broken pipe

[Bug testsuite/99173] new test case c-c++-common/attr-retain-5.c added in r11-7284 fails

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

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

--- Comment #1 from seurer at gcc dot gnu.org ---
There are actually a bunch more.  Here's the full list:

FAIL: c-c++-common/attr-retain-5.c  -Wc++-compat  (test for excess errors)
FAIL: c-c++-common/attr-retain-5.c  -std=gnu++14 (test for excess errors)
FAIL: c-c++-common/attr-retain-5.c  -std=gnu++17 (test for excess errors)
FAIL: c-c++-common/attr-retain-5.c  -std=gnu++2a (test for excess errors)
FAIL: c-c++-common/attr-retain-5.c  -std=gnu++98 (test for excess errors)
FAIL: c-c++-common/attr-retain-6.c  -Wc++-compat  (test for excess errors)
FAIL: c-c++-common/attr-retain-6.c  -std=gnu++14 (test for excess errors)
FAIL: c-c++-common/attr-retain-6.c  -std=gnu++17 (test for excess errors)
FAIL: c-c++-common/attr-retain-6.c  -std=gnu++2a (test for excess errors)
FAIL: c-c++-common/attr-retain-6.c  -std=gnu++98 (test for excess errors)
FAIL: c-c++-common/attr-retain-7.c  -Wc++-compat  (test for excess errors)
FAIL: c-c++-common/attr-retain-7.c  -std=gnu++14 (test for excess errors)
FAIL: c-c++-common/attr-retain-7.c  -std=gnu++17 (test for excess errors)
FAIL: c-c++-common/attr-retain-7.c  -std=gnu++2a (test for excess errors)
FAIL: c-c++-common/attr-retain-7.c  -std=gnu++98 (test for excess errors)
FAIL: c-c++-common/attr-retain-8.c  -Wc++-compat  (test for excess errors)
FAIL: c-c++-common/attr-retain-8.c  -std=gnu++14 (test for excess errors)
FAIL: c-c++-common/attr-retain-8.c  -std=gnu++17 (test for excess errors)
FAIL: c-c++-common/attr-retain-8.c  -std=gnu++2a (test for excess errors)
FAIL: c-c++-common/attr-retain-8.c  -std=gnu++98 (test for excess errors)
FAIL: c-c++-common/attr-retain-9.c  -Wc++-compat  (test for excess errors)
FAIL: c-c++-common/attr-retain-9.c  -std=gnu++14 (test for excess errors)
FAIL: c-c++-common/attr-retain-9.c  -std=gnu++17 (test for excess errors)
FAIL: c-c++-common/attr-retain-9.c  -std=gnu++2a (test for excess errors)
FAIL: c-c++-common/attr-retain-9.c  -std=gnu++98 (test for excess errors)

gcc-9-20210219 is now available

[GCC Administrator via Gcc]

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

This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 
revision 65565c1da24c013274eb073c649d7f01acc4c7cd

You'll find:

 gcc-9-20210219.tar.xzComplete GCC

  SHA256=70ef145c0260f7ee90cfd40258d0e8adced0a3c799626b57f825b9553034d1db
  SHA1=e6d97fe22a31f73f8773fa86df6687d15a348593

Diffs from 9-20210212 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
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 c++/99153] [11 Regression] ICE: depset::hash::make_dependency

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

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

--- Comment #2 from Nathan Sidwell  ---
// B_a.ii
template
struct pair
{
  inline void Frob ();
};

// B_b.ii
import  "./B_a.ii"

template
inline  void pair<_T1>::Frob()
{ }


./cc1plus -quiet -std=c++20 -fmodule-header  -fpreprocessed B_a.ii && ./cc1plus
-quiet -std=c++20 -fmodule-header  -fpreprocessed B_b.ii
B_b.ii:1: internal compiler error: in make_dependency, at cp/module.cc:12523
1 | import  "./B_a.ii" [[__translated]];
  | 
0xcd61da depset::hash::make_dependency(tree_node*, depset::entity_kind)
../../../src/gcc/cp/module.cc:12523
0xcd7f54 depset::hash::add_class_entities(vec*)
../../../src/gcc/cp/module.cc:12942
0xce60bb module_state::write(elf_out*, cpp_reader*)
../../../src/gcc/cp/module.cc:17604

The module flags on the TEMPLATE_DECL do not match those of the
DECL_TEMPLATE_RESULT.

[Bug c++/99174] New: [modules] ICE with recursive inclusion of header-unit

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

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

Bug ID: 99174
   Summary: [modules] ICE with recursive inclusion of header-unit
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

self-inclusion considered dangerous

// 1_b.ii
import "./1_b.ii";



./cc1plus -quiet -std=c++20 -fmodule-header 1_b.ii  
1_b.ii:1:1: internal compiler error: in read_preprocessor, at
cp/module.cc:17891
1 | import "./1_b.ii";
  | ^~
0xce6da8 module_state::read_preprocessor(bool)
../../../src/gcc/cp/module.cc:17891
0xceb5db preprocess_module(module_state*, unsigned int, bool, bool, bool,
cpp_reader*)
../../../src/gcc/cp/module.cc:19446
0xc73707 module_token_filter::resume(int, int, tree_node*, unsigned int)
../../../src/gcc/cp/lex.c:520
0xc71c69 module_token_lang(int, int, tree_node*, unsigned int, unsigned long)
../../../src/gcc/cp/lex.c:557
0xd26638 cp_lexer_new_main
../../../src/gcc/cp/parser.c:658
0xd90362 c_parse_file()
../../../src/gcc/cp/parser.c:45168
0xf5194e c_common_parse_file()
../../../src/gcc/c-family/c-opts.c:1218

[Bug testsuite/99173] New: new test case c-c++-common/attr-retain-5.c added in r11-7284 fails

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

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

Bug ID: 99173
   Summary: new test case c-c++-common/attr-retain-5.c added in
r11-7284 fails
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:6347f4a0904fce17eedf5c071be6f3c118680290, r11-7284

make  -k check-gcc RUNTESTFLAGS="dg.exp=c-c++-common/attr-retain-5.c"
FAIL: c-c++-common/attr-retain-5.c  -Wc++-compat  (test for excess errors)
FAIL: c-c++-common/attr-retain-5.c  -std=gnu++98 (test for excess errors)
FAIL: c-c++-common/attr-retain-5.c  -std=gnu++14 (test for excess errors)
FAIL: c-c++-common/attr-retain-5.c  -std=gnu++17 (test for excess errors)
FAIL: c-c++-common/attr-retain-5.c  -std=gnu++2a (test for excess errors)
# of unexpected failures1
# of unexpected failures4




spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/attr-retain-5.c
-fdiagnostics-plain-output -Wc++-compat -Wall -O2 -ffat-lto-objects -fno-ident
-S -o attr-retain-5.s
/home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/attr-retain-5.c:23:1:
warning: 'retain' attribute ignored [-Wattributes]
FAIL: c-c++-common/attr-retain-5.c  -Wc++-compat  (test for excess errors)
Excess errors:
/home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/attr-retain-5.c:23:1:
warning: 'retain' attribute ignored [-Wattributes]

[Bug c/99156] __builtin_expect affects the interpretation of its first operand

[zhan3299 at purdue dot edu via Gcc-bugs]

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

--- Comment #2 from zhan3299 at purdue dot edu ---
(In reply to Martin Liška from comment #1)
> Yes, I can confirm the issue. Thanks for the report.

Many thanks for your prompt reply. Additionally, I have to give credit to
Richard Smith for finding the root cause.

[Bug c++/98741] [modules] ICE/SIGSEGV reading compiled module cluster

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
14886cbe300 2021-02-19 | c++: Incorrect module-number ordering [PR 98741]

[Bug c++/98741] [modules] ICE/SIGSEGV reading compiled module cluster

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

https://gcc.gnu.org/g:14886cbe300c144a4390245d0515cdf28fc5f68f

commit r11-7307-g14886cbe300c144a4390245d0515cdf28fc5f68f
Author: Nathan Sidwell 
Date:   Fri Feb 19 13:10:27 2021 -0800

c++: Incorrect module-number ordering [PR 98741]

One of the very strong invariants in modules is that module numbers
are allocated such that (other than the current TU), all imports have
lesser module numbers, and also that the binding vector is only
appended to with increasing module numbers.   This broke down when
module-directives became a thing and the preprocessing became entirely
decoupled from parsing.  We'd load header units and their macros (but
not symbols of course) during preprocessing.  Then we'd load named
modules during parsing.  This could lead to the situation where a
header unit appearing after a named import had a lower module number
than the import.  Consequently, if they both bound the same
identifier, the binding vector would be misorderd and bad things
happen.

This patch restores a pending import queue I previously had, but in
simpler form (hurrah).  During preprocessing we queue all
module-directives and when we meet one for a header unit we do the
minimal loading for all of the queue, so they get appropriate
numbering.  Then we load the preprocessor state for the header unit.

PR c++/98741
gcc/cp/
* module.cc (pending_imports): New.
(declare_module): Adjust test condition.
(name_pending_imports): New.
(preprocess_module): Reimplement using pending_imports.
(preprocessed_module): Move name-getting to name_pending_imports.
* name-lookup.c (append_imported_binding_slot): Assert module
ordering is increasing.
gcc/testsuite/
* g++.dg/modules/pr98741_a.H: New.
* g++.dg/modules/pr98741_b.H: New.
* g++.dg/modules/pr98741_c.C: New.
* g++.dg/modules/pr98741_d.C: New.

c++: Incorrect module-number ordering [PR 98741]

[Nathan Sidwell]

One of the very strong invariants in modules is that module numbers are 
allocated such that (other than the current TU), all imports have lesser 
module numbers, and also that the binding vector is only appended to 
with increasing module numbers.   This broke down when module-directives 
became a thing and the preprocessing became entirely decoupled from 
parsing.  We'd load header units and their macros (but not symbols of 
course) during preprocessing.  Then we'd load named modules during 
parsing.  This could lead to the situation where a header unit appearing 
after a named import had a lower module number than the import. 
Consequently, if they both bound the same identifier, the binding vector 
would be misorderd and bad things happen.


This patch restores a pending import queue I previously had, but in 
simpler form (hurrah).  During preprocessing we queue all 
module-directives and when we meet one for a header unit we do the 
minimal loading for all of the queue, so they get appropriate numbering. 
 Then we load the preprocessor state for the header unit.


PR c++/98741
gcc/cp/
* module.cc (pending_imports): New.
(declare_module): Adjust test condition.
(name_pending_imports): New.
(preprocess_module): Reimplement using pending_imports.
(preprocessed_module): Move name-getting to name_pending_imports.
* name-lookup.c (append_imported_binding_slot): Assert module
ordering is increasing.
gcc/testsuite/
* g++.dg/modules/pr98741_a.H: New.
* g++.dg/modules/pr98741_b.H: New.
* g++.dg/modules/pr98741_c.C: New.
* g++.dg/modules/pr98741_d.C: New.

--
Nathan Sidwell
diff --git c/gcc/cp/module.cc w/gcc/cp/module.cc
index 691381bf995..3d17b8ddcdb 100644
--- c/gcc/cp/module.cc
+++ w/gcc/cp/module.cc
@@ -3873,6 +3873,9 @@ module_state_hash::equal (const value_type existing,
 /* Mapper name.  */
 static const char *module_mapper_name;
 
+/* Deferred import queue (FIFO).  */
+static vec *pending_imports;
+
 /* CMI repository path and workspace.  */
 static char *cmi_repo;
 static size_t cmi_repo_length;
@@ -18944,7 +18947,7 @@ declare_module (module_state *module, location_t from_loc, bool exporting_p,
   gcc_assert (global_namespace == current_scope ());
 
   module_state *current = (*modules)[0];
-  if (module_purview_p () || module->loadedness != ML_NONE)
+  if (module_purview_p () || module->loadedness > ML_CONFIG)
 {
   error_at (from_loc, module_purview_p ()
 		? G_("module already declared")
@@ -19275,6 +19278,70 @@ module_begin_main_file (cpp_reader *reader, line_maps *lmaps,
 }
 }
 
+/* Process the pending_import queue, making sure we know the
+   filenames.   */
+
+static void
+name_pending_imports (cpp_reader *reader, bool at_end)
+{
+  auto *mapper = get_mapper (cpp_main_loc (reader));
+
+  bool only_headers = (flag_preprocess_only
+		   && !bool (mapper->get_flags () & Cody::Flags::NameOnly)
+		   && !cpp_get_deps (reader));
+  if (at_end
+  && (!vec_safe_length (pending_imports) || only_headers))
+/* Not doing anything.  */
+return;
+
+  timevar_start (TV_MODULE_MAPPER);
+
+  dump.push (NULL);
+  dump () && dump ("Resolving direct import names");
+
+  mapper->Cork ();
+  for (unsigned ix = 0; ix != pending_imports->length (); ix++)
+{
+  module_state *module = (*pending_imports)[ix];
+  gcc_checking_assert (module->is_direct ());
+  if (!module->filename)
+	{
+	  Cody::Flags flags
+	= (flag_preprocess_only ? Cody::Flags::None
+	   : Cody::Flags::NameOnly);
+
+	  if (only_headers && !module->is_header ())
+	;
+	  else if (module->module_p
+		   && (module->is_partition () || module->exported_p))
+	mapper->ModuleExport (module->get_flatname (), flags);
+	  else
+	mapper->ModuleImport (module->get_flatname (), flags);
+	}
+}
+  
+  auto response = mapper->Uncork ();
+  auto r_iter = response.begin ();
+  for (unsigned ix = 0; ix != pending_imports->length (); ix++)
+{
+  module_state *module = (*pending_imports)[ix];
+  gcc_checking_assert (module->is_direct ());
+  if (only_headers && !module->is_header ())
+	;
+  else if (!module->filename)
+	{
+	  Cody::Packet const  = *r_iter;
+	  ++r_iter;
+
+	  module->set_filename (p);
+	}
+}
+
+  dump.pop (0);
+
+  timevar_stop (TV_MODULE_MAPPER);
+}
+
 /* We've just lexed a module-specific control line for MODULE.  Mark
the module as a direct import, and possibly load up its macro
state.  Returns the primary module, if this is a module
@@ -19322,17 +19389,22 @@ preprocess_module (module_state *module, location_t from_loc,
 	}
 }
 
+  auto desired = ML_CONFIG;
   if (is_import
-  && !module->is_module () && module->is_header ()
-  && module->loadedness < ML_PREPROCESSOR
+  && module->is_header ()
   && (!cpp_get_options (reader)->preprocessed
 	  || cpp_get_options (reader)->directives_only))
+/* We need preprocessor 

Re: [PATCH v7] Practical improvement to libgcc complex divide

[Joseph Myers]

On Tue, 2 Feb 2021, Patrick McGehearty via Gcc-patches wrote:

> if (mode == TYPE_MODE (double_type_node))
> - ; /* Empty suffix correct.  */
> + {
> +   ; /* Empty suffix correct.  */
> +   memcpy (modename, "DBL", 4);
> + }
> else if (mode == TYPE_MODE (float_type_node))
> - suffix[0] = 'f';
> + {
> +   suffix[0] = 'f';
> +   memcpy (modename, "FLT", 4);
> + }
> else if (mode == TYPE_MODE (long_double_type_node))
> - suffix[0] = 'l';
> + {
> +   suffix[0] = 'l';
> +   memcpy (modename, "LDBL", 4);
> + }
> else
>   {
> bool found_suffix = false;
> @@ -1305,6 +1316,8 @@ c_cpp_builtins (cpp_reader *pfile)
>   sprintf (suffix, "f%d%s", floatn_nx_types[i].n,
>floatn_nx_types[i].extended ? "x" : "");
>   found_suffix = true;
> + sprintf (modename, "FLT%d%s", floatn_nx_types[i].n,
> +  floatn_nx_types[i].extended ? "X" : "");
>   break;
> }
> gcc_assert (found_suffix);

Here you're properly computing the mapping from mode to float.h macro 
prefix (though I think "modename" is a confusing name for the variable 
used for float.h macro prefixes; to me, "modename" suggests the names such 
as SF or DF, which are actually "name" here, and something like 
"float_h_prefix" would be better than "modename").

> +   if ((mode == TYPE_MODE (float_type_node))
> +   || (mode == TYPE_MODE (double_type_node))
> +   || (mode == TYPE_MODE (long_double_type_node)))

But then here you still have the check for the mode matching one of those 
three types, which defeats the point of computing the prefix in a way that 
works for *all* floating-point modes supported in libgcc.  (The above 
"gcc_assert (found_suffix)" asserts that the relevant mapping did get 
found.)

To be able to use the __LIBGCC_* macros in libgcc in all cases, they 
should be defined, using the modename (or float_h_prefix) found above, 
whether or not the mode matches one of float, double and long double.

>  #elif defined(L_multc3) || defined(L_divtc3)
>  # define MTYPE   TFtype
>  # define CTYPE   TCtype
>  # define MODEtc
>  # define CEXT__LIBGCC_TF_FUNC_EXT__
>  # define NOTRUNC (!__LIBGCC_TF_EXCESS_PRECISION__)
> +#if defined(__LIBGCC_TF_MIN__)
> +# define RBIG((__LIBGCC_TF_MAX__)/2)
> +# define RMIN(__LIBGCC_TF_MIN__)
> +# define RMIN2   (__LIBGCC_TF_EPSILON__)
> +# define RMINSCAL (1/__LIBGCC_TF_EPSILON__)
> +#else
> +# define RBIG((__LIBGCC_XF_MAX__)/2)
> +# define RMIN(__LIBGCC_XF_MIN__)
> +# define RMIN2   (__LIBGCC_XF_EPSILON__)
> +# define RMINSCAL (1/__LIBGCC_XF_EPSILON__)
> +#endif

Once you've removed the unnecessary conditional above, you don't need this 
conditional on __LIBGCC_TF_MIN__ being defined either; the *TF* macros 
will always be defined when TFmode is supported in libgcc, so you never 
need to use *XF* macros instead when building TFmode code.

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

[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2021-February/055741.html

[PATCH] PR fortran/99169 - [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument

[Harald Anlauf via Gcc-patches]

Dear all,

we should not clobber the pointer in case of an allocatable scalar being
an intent(out) dummy argument to a procedure.

Regtested on x86_64-pc-linux-gnu.

OK for master?  Since this is a regression, also for backports to 10/9?

Thanks,
Harald


PR fortran/99169 - Do not clobber allocatable intent(out) dummy argument

gcc/fortran/ChangeLog:

* trans-expr.c (gfc_conv_procedure_call): Do not add clobber to
allocatable intent(out) argument.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_optimize_3.f90: New test.

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 103cb31c664..cab58cd1bba 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6077,6 +6079,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 			&& !fsym->attr.allocatable && !fsym->attr.pointer
 			&& !e->symtree->n.sym->attr.dimension
 			&& !e->symtree->n.sym->attr.pointer
+			&& !e->symtree->n.sym->attr.allocatable
 			/* See PR 41453.  */
 			&& !e->symtree->n.sym->attr.dummy
 			/* FIXME - PR 87395 and PR 41453  */
diff --git a/gcc/testsuite/gfortran.dg/intent_optimize_3.f90 b/gcc/testsuite/gfortran.dg/intent_optimize_3.f90
new file mode 100644
index 000..6ecd722da76
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/intent_optimize_3.f90
@@ -0,0 +1,16 @@
+! { dg-do run }
+! { dg-options "-O2" }
+! PR99169 - Segfault passing allocatable scalar into intent(out) dummy argument
+
+program p
+  implicit none
+  integer, allocatable :: i
+  allocate (i)
+  call set (i)
+  if (i /= 5) stop 1
+contains
+  subroutine set (i)
+integer, intent(out) :: i
+i = 5
+  end subroutine set
+end program p

Re: [PATCH] PR 99133, Mark xxspltiw, xxspltidp, and xxsplti32x as being prefixed

[Segher Boessenkool]

On Thu, Feb 18, 2021 at 10:44:14PM -0500, Michael Meissner wrote:
> On Wed, Feb 17, 2021 at 06:09:39PM -0600, Segher Boessenkool wrote:
> > Why test a p10 patch on a p8?
> 
> Well it is just a code gen patch, so I can test it on any system, even an
> x86_64 with a cross compiler.  Given that right now xxsplatiw is only created
> via a built-in,

That in itself should be fixed btw (don't use unspecs).

> > > +   Some prefixed instructions (xxspltiw, xxspltidp, xxsplti32dp, etc.) 
> > > do not
> > > +   have a leading 'p'.  Setting the prefix attribute to special does not 
> > > the 'p'
> > > +   prefix.  */
> > 
> > (grammar)
> > 
> > "special" is the *normal* case.  *Most* prefixed insns will be like
> > this.  They aren't right now, but they will be.
> > 
> > It sounds like you should make a new attribute, "always_prefixed" or
> > something, that then the code that sets "prefixed" can use.
> 
> Yes agreed.

Or better yet, "maybe_prefixed", which you set when something else will
make the decision.  Mmostly the default value of the prefixed attribute
will then do that. See "maybe_var_shift" / "var_shift" for example.

> > >  void
> > >  rs6000_final_prescan_insn (rtx_insn *insn, rtx [], int)
> > >  {
> > > -  next_insn_prefixed_p = (get_attr_prefixed (insn) != PREFIXED_NO);
> > > +  next_insn_prefixed_p = (get_attr_prefixed (insn) != PREFIXED_NO
> > > +   && get_attr_prefixed (insn) != PREFIXED_SPECIAL);
> > >return;
> > >  }
> > 
> > So you set next_insn_prefixed_p when exactly?  The original code was
> > correct, as far as I can see?
> 
> rs6000_final_prescan_insn is called in the FINAL_PRESCAN_INSN target hook, and
> it is the only place we can set the flag for ASM_OUTPUT_OPCODE to print the
> initial 'p'.  As you know, during the development of prefixed support, I went
> through various different methods of generating the prefixed instruction
> (i.e. pld instead of ld).  The current method works for normal load, store and
> add instructions that have a normal form and a prefixed form.  But it doesn't
> work for other instructions that we need to start dealing with. 

Ah, the flag doesn't mean that the next insn is prefixed.  It means we
want to prefix the mnemonic with a "p", instead.  So some name change is
in order (as a separate, trivial, patch at the start of the series) --
this helps bisection if needed later, but it also helps reviewing
enormously).

> > So, for insns like xxspltiw you should just set "prefixed" to "yes",
> > because that makes sense, is not confusing.  The code that prefixes "p"
> > to the mnemonic should change, instead.  It can look at some new
> > attribute, but it could also just use
> >   prefixed_load_p (insn) || prefixed_store_p (insn)
> >   || prefixed_paddi_p (insn)
> > or similar (perhaps make a helper function for that then?)
> 
> Yes.  Pat Haugen will be taking over the PR.

Thanks,


Segher

Re: [committed] jit: fix ICE on BUILT_IN_TRAP [PR99126]

[David Malcolm via Gcc-patches]

On Fri, 2021-02-19 at 11:16 +0100, Andrea Corallo wrote:
> David Malcolm via Gcc-patches  writes:
> 
> > I tried several approaches to fixing this; this seemed the
> > least invasive.
> 
> Hi Dave,
> 
> thanks for fixing this.
> 
> I do have a trivial question: are we guaranteed that the middle-end
> will
> not try to add any build-in other than a trap?

No; the middle-end can add various other builtins.

The C/C++ FE have c_define_builtins, which calls def_builtin_1 on
everything with DEF_BUILTIN, then calls:
  targetm.init_builtins ();
  build_common_builtin_nodes ();

jit_langhook_init calls build_common_builtin_nodes.

The jit builtins_manager creates recording::functions (and their
supporting types) for any builtins that are explicitly used, and these
recording::functions get turned into trees during playback.

I looked at the doing the equivalent of DEF_BUILTIN for any builtins
that haven't been created yet, but when to do it?

(a) in the builtin manager... but not all builtin-types are supported
yet (e.g. BT_FLOAT16), so it would be a big patch to do it that way

(b) in jit_langhook_init... but then if the user creates a builtin that
wasn't referenced before in a 2nd in-memory compile, I think the types
can get out-of-sync.

So I went with the patch I did as it seems to be the least invasive way
of fixing the specific problem.

Dave

Re: [PATCH] rs6000: Use rldimi for vec init instead of shift + ior

[Segher Boessenkool]

Hi!

On Fri, Feb 19, 2021 at 11:06:16AM +0800, Kewen.Lin wrote:
> on 2021/2/19 上午2:33, Segher Boessenkool wrote:
> > Is there a PR you should mention here?
> 
> I thought this is trivial so didn't file one upstream PR.  I did a
> searching in upstream bugzilla, PR93453 looks similar but different.
> I confirmed that the current patch can't make it pass (just two insns
> instead of three insns).
> 
> Do you happen to have one related in mind?  If no, I will commit it
> without PR.

That is fine.  I just asked if perhaps you forgot to mention a PR; I do
that all the time myself!  Filing a new PR if a patch is ready and
approved is just bureaucracy, so let's not (it is useful if it needs
backporting though, to have a place to track that).

Thanks,


Segher

[Bug libstdc++/99172] New: Build failure with slibtool and vtv

[gcc-user at riseup dot net via Gcc-bugs]

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

Bug ID: 99172
   Summary: Build failure with slibtool and vtv
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-user at riseup dot net
  Target Milestone: ---

Created attachment 50227
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50227=edit
Full build log.

When building gcc with slibtool (https://dev.midipix.org/cross/slibtool) the
build will fail in the libstdc++.la make target in libstdc++-v3/src.

  /usr/x86_64-pc-linux-gnu/bin/ld: cannot find -lvtv

This doesn't occur with GNU libtool because it silently filters out the invalid
-lvtv while slibtool does not. I attached a full build log.

Also see this gentoo issue.

https://bugs.gentoo.org/767706

To build gcc with slibtool:

  export MAKE='make LIBTOOL=rdlibtool'

Unfortunately gcc doesn't respect the value of the MAKEFLAGS environment
variable.

[Bug fortran/98686] Namelist group objects shall be defined before appearing in namelist for -std=f2018

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jerry DeLisle :

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

commit r11-7306-gdfa2f821c18b7e926b5f5d6e394a0c915937db5e
Author: Jerry DeLisle 
Date:   Fri Feb 19 12:47:54 2021 -0800

fortran: Object types should be declared before use in NAMELIST.

gcc/fortran/ChangeLog:

PR fortran/98686
* match.c (gfc_match_namelist): If BT_UNKNOWN, check for
IMPLICIT NONE and and issue an error, otherwise set the type
to its IMPLICIT type so that any subsequent use of objects will
will confirm their types.

gcc/testsuite/ChangeLog:

PR fortran/98686
* gfortran.dg/namelist_4.f90: Modify.
* gfortran.dg/namelist_98.f90: New test.

libgo patch committed: Update to Go1.16 release

[Ian Lance Taylor via Gcc-patches]

This patch updates libgo to the final Go 1.16 release.  Bootstrapped
and ran Go testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
c89b42d3b9d76dedb35e8478913ddf5367f3b5e6
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index eed9ce01905..217bdd55f1d 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-c406de0594782b1d6782a732a50f5b76387852dc
+78a840e4940159a66072237f6b002ab79f441b79
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/MERGE b/libgo/MERGE
index b2fc633f06c..183b0245ee2 100644
--- a/libgo/MERGE
+++ b/libgo/MERGE
@@ -1,4 +1,4 @@
-3e06467282c6d5678a6273747658c04314e013ef
+f21be2fdc6f1becdbed1592ea0b245cdeedc5ac8
 
 The first line of this file holds the git revision number of the
 last merge done from the master library sources.
diff --git a/libgo/VERSION b/libgo/VERSION
index a19294250b3..4befab24bc9 100644
--- a/libgo/VERSION
+++ b/libgo/VERSION
@@ -1 +1 @@
-go1.16rc1
+go1.16
diff --git a/libgo/go/archive/tar/strconv.go b/libgo/go/archive/tar/strconv.go
index 6d0a4038082..f0b61e6dba6 100644
--- a/libgo/go/archive/tar/strconv.go
+++ b/libgo/go/archive/tar/strconv.go
@@ -265,8 +265,27 @@ func parsePAXRecord(s string) (k, v, r string, err error) {
return "", "", s, ErrHeader
}
 
+   afterSpace := int64(sp + 1)
+   beforeLastNewLine := n - 1
+   // In some cases, "length" was perhaps padded/malformed, and
+   // trying to index past where the space supposedly is goes past
+   // the end of the actual record.
+   // For example:
+   //"30 
mtime=1432668921.098285006\n30 ctime=2147483649.15163319"
+   //  ^ ^
+   //  | |
+   //  |  afterSpace=35
+   //  |
+   //  beforeLastNewLine=29
+   // yet indexOf(firstSpace) MUST BE before endOfRecord.
+   //
+   // See https://golang.org/issues/40196.
+   if afterSpace >= beforeLastNewLine {
+   return "", "", s, ErrHeader
+   }
+
// Extract everything between the space and the final newline.
-   rec, nl, rem := s[sp+1:n-1], s[n-1:n], s[n:]
+   rec, nl, rem := s[afterSpace:beforeLastNewLine], 
s[beforeLastNewLine:n], s[n:]
if nl != "\n" {
return "", "", s, ErrHeader
}
diff --git a/libgo/go/archive/tar/strconv_test.go 
b/libgo/go/archive/tar/strconv_test.go
index dd3505a758a..add65e272ae 100644
--- a/libgo/go/archive/tar/strconv_test.go
+++ b/libgo/go/archive/tar/strconv_test.go
@@ -368,6 +368,13 @@ func TestParsePAXRecord(t *testing.T) {
{"16 longkeyname=hahaha\n", "16 longkeyname=hahaha\n", "", "", 
false},
{"3 somelongkey=\n", "3 somelongkey=\n", "", "", false},
{"50 tooshort=\n", "50 tooshort=\n", "", "", false},
+   {"30 
mtime=1432668921.098285006\n30 ctime=2147483649.15163319", 
"30 mtime=1432668921.098285006\n30 
ctime=2147483649.15163319", "mtime", "1432668921.098285006", false},
+   {"06 k=v\n", "06 k=v\n", "", "", false},
+   {"6 k=v\n", "6 k=v\n", "", "", false},
+   {"06 k=v\n", "06 k=v\n", "", "", false},
+   {"00 k=v\n", "00 k=v\n", "", "", false},
+   {"0 k=v\n", "0 k=v\n", "", "", false},
+   {"+005 x=\n", "+005 x=\n", "", "", false},
}
 
for _, v := range vectors {
diff --git a/libgo/go/cmd/go/alldocs.go b/libgo/go/cmd/go/alldocs.go
index 49d390297cd..e7c63f0749d 100644
--- a/libgo/go/cmd/go/alldocs.go
+++ b/libgo/go/cmd/go/alldocs.go
@@ -1808,7 +1808,7 @@
 // The directory where the go command will write
 // temporary source files, packages, and binaries.
 // GOVCS
-//   Lists version control commands that may be used with matching servers.
+// Lists version control commands that may be used with matching 
servers.
 // See 'go help vcs'.
 //
 // Environment variables for use with cgo:
@@ -2410,6 +2410,17 @@
 //
 // For a detailed reference on modules, see https://golang.org/ref/mod.
 //
+// By default, the go command may download modules from 
https://proxy.golang.org.
+// It may authenticate modules using the checksum database at
+// https://sum.golang.org. Both services are operated by the Go team at Google.
+// The privacy policies for these services are available at
+// https://proxy.golang.org/privacy and https://sum.golang.org/privacy,
+// respectively.
+//
+// The go command's download behavior may be configured using GOPROXY, GOSUMDB,
+// GOPRIVATE, and other environment variables. See 'go help environment'
+// and 

[Bug fortran/99171] New: [10 Regression] Optional procedure call inside Open MP parallel loop produces Segmentation Fault

[am41119 at hotmail dot com via Gcc-bugs]

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

Bug ID: 99171
   Summary: [10 Regression] Optional procedure call inside Open MP
parallel loop produces Segmentation Fault
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: am41119 at hotmail dot com
  Target Milestone: ---

Created attachment 50226
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50226=edit
Output of using -save-temps during compilation

When calling a passed optional procedure inside an Open MP parallel loop (even
with OMP_NUM_THREADS=1) the address of the optional procedure is no longer set
to the actual passed procedure. Because the address of the optional procedure
is no longer correct we get a Segmentation Fault when calling it.


The below program works on GCC9 and below.


main.f90:
---
program gcc10_omp_optional_bug
implicit none

call function_calling_optionals(print_something)

call function_calling_optionals_in_omp(print_something)

contains

subroutine optional_function_template()
implicit none
end subroutine

subroutine print_something()
implicit none

print *, "Printing Something"

end subroutine print_something

subroutine function_calling_optionals(optional_function)
implicit none
procedure(optional_function_template), optional :: optional_function

print *, "When optional function is called without Open MP directive:"

if (present(optional_function)) then
call optional_function()
end if

end subroutine function_calling_optionals

subroutine function_calling_optionals_in_omp(optional_function)
implicit none
procedure(optional_function_template), optional :: optional_function

print *, "When optional function is called inside Open MP directive:"

!$omp parallel 
if (present(optional_function)) then
call optional_function()
end if
!$omp end parallel

end subroutine function_calling_optionals_in_omp


end program gcc10_omp_optional_bug


-
gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
10.2.0-5ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-WJNXnb/gcc-10-10.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-WJNXnb/gcc-10-10.2.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (Ubuntu 10.2.0-5ubuntu1~20.04)

Compile Command:
gfortran main.f90 -fopenmp -o main

Execution output:

When optional function is called without Open MP directive:
Printing Something
When optional function is called inside Open MP directive:

Program received signal SIGILL: Illegal instruction.

Program received signal SIGILL: Illegal instruction.

Program received signal SIGILL: Illegal instruction.

Backtrace for this error:

Program received signal SIGILL: Illegal instruction.

Backtrace for this error:

Backtrace for this error:

Backtrace for this error:

Program received signal SIGILL: Illegal instruction.

Backtrace for this error:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:

Program received signal SIGILL: Illegal instruction.

Backtrace for this error:

Program received signal SIGILL: Illegal instruction.

Backtrace for this error:
#0  0x7f9e60dd1d01 in ???
#0  0x7f9e60dd1d01 in ???
#0  0x7f9e60dd1d01 in ???
#1  0x7f9e60dd0ed5 in ???
#2  0x7f9e60bc320f in ???
#3  0x7f9e5e993e27 in ???
Illegal instruction (core dumped)

[Bug target/97366] [8/9/10/11 Regression] Redundant load with SSE/AVX vector intrinsics

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

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

--- Comment #8 from Vladimir Makarov  ---
I've tried different approaches to fix it.  The best patch I have now is in the
attachment.

Unfortunately, the best patch results in two new failures on ppc64 (other
patches are even worse):

gcc.target/powerpc/dform-3.c scan-assembler-not mfvsrd
gcc.target/powerpc/dform-3.c scan-assembler-not mfvsrld

I'll think more how to avoid these 2 failures.  If I succeed, I'll submit a
patch.  But there is probability that the PR will not be fixed at all.

[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
The following code in trans-expr.c was added by Thomas, so adding him in CC:

  else if (add_clobber && expr->ref == NULL)
{
  tree clobber;
  tree var;
  /* FIXME: This fails if var is passed by reference, see PR
 41453.  */
  var = expr->symtree->n.sym->backend_decl;
  clobber = build_clobber (TREE_TYPE (var));
  gfc_add_modify (>pre, var, clobber);
}

[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #15 from seurer at gcc dot gnu.org ---
It still fails on gcc 10, though

[Bug target/97366] [8/9/10/11 Regression] Redundant load with SSE/AVX vector intrinsics

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

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

--- Comment #7 from Vladimir Makarov  ---
Created attachment 50225
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50225=edit
A candidate patch

[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
A conservative solution simply disables the clobber:

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 103cb31c664..ce7bfaa89e8 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6082,6 +6084,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
/* FIXME - PR 87395 and PR 41453  */
&& e->symtree->n.sym->attr.save == SAVE_NONE
&& !e->symtree->n.sym->attr.associate_var
+   && !e->symtree->n.sym->attr.allocatable
&& e->ts.type != BT_CHARACTER && e->ts.type !=
BT_DERIVED
&& e->ts.type != BT_CLASS && !sym->attr.elemental;

This should result only in a missed optimization.
Is there a way to get sth. like:

  *i = {CLOBBER};

so that we do not clobber the pointer but the pointer to?

[Bug c++/99170] [modules] ICE in get_merge_kind with std::string NSDMI

[remi.galanalfonso at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Rémi Galan Alfonso  ---
Created attachment 50224
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50224=edit
preprocessed file

... And with the correct preprocessed file this time, apologies for my mistake.

[Bug c++/99170] New: [modules] ICE in get_merge_kind with std::string NSDMI

[remi.galanalfonso at gmail dot com via Gcc-bugs]

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

Bug ID: 99170
   Summary: [modules] ICE in get_merge_kind with std::string NSDMI
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: remi.galanalfonso at gmail dot com
  Target Milestone: ---

Created attachment 50223
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50223=edit
preprocessed file

Hello, I ran into the following ICE when testing modules a bit, it doesn't look
like any currently open module bug (reproduced here with a recent trunk, commit
f86e187e12d).

The reproducer is as follows:

$ cat test_modules.cpp 
export module test;

import ;

export class A {
std::string str{"ayyy"};
};

The  header unit was compiled with the following:

$ g++ -std=c++20 -fmodules-ts -x c++-system-header string

And the command line used and result are the following (along with -v for
information):

$ g++ -v -save-temps -std=c++20 -fmodules-ts -c test_modules.cpp
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/remi/Projects/gcc/build-install
--disable-multilib : (reconfigured) ./configure
--prefix=/home/remi/Projects/gcc/build-install --disable-multilib :
(reconfigured) ./configure --prefix=/home/remi/Projects/gcc/build-install
--disable-multilib CC=gcc-9 CXX=g++-9 --enable-languages=c,c++,fortran,lto,objc
--no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20210219 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-fmodules-ts' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'

/home/remi/Projects/gcc/build-install/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/cc1plus
-E -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE test_modules.cpp
-mtune=generic -march=x86-64 -std=c++20 -fmodules-ts -fpch-preprocess -o
test_modules.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/home/remi/Projects/gcc/build-install/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/home/remi/Projects/gcc/build-install/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0

/home/remi/Projects/gcc/build-install/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/x86_64-pc-linux-gnu

/home/remi/Projects/gcc/build-install/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/backward

/home/remi/Projects/gcc/build-install/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include
 /usr/local/include
 /home/remi/Projects/gcc/build-install/include

/home/remi/Projects/gcc/build-install/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-fmodules-ts' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'

/home/remi/Projects/gcc/build-install/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/cc1plus
-fpreprocessed test_modules.ii -quiet -dumpbase test_modules.cpp -dumpbase-ext
.cpp -mtune=generic -march=x86-64 -std=c++20 -version -fmodules-ts -o
test_modules.s
GNU C++20 (GCC) version 11.0.0 20210219 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.0.0 20210218 (experimental), GMP version
6.2.1, MPFR version 4.1.0, MPC version 1.2.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++20 (GCC) version 11.0.0 20210219 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.0.0 20210218 (experimental), GMP version
6.2.1, MPFR version 4.1.0, MPC version 1.2.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 8e9853a7486525ef35ca23365b38ea4d
test_modules.cpp:1:9: internal compiler error: in get_merge_kind, at
cp/module.cc:10158
1 | export module test;
  | ^~
0x699387 trees_out::get_merge_kind(tree_node*, depset*)
../.././gcc/cp/module.cc:10158
0xa13f63 trees_out::decl_value(tree_node*, depset*)
../.././gcc/cp/module.cc:7618
0xa14ebb trees_out::decl_node(tree_node*, walk_kind)
../.././gcc/cp/module.cc:8613
0xa15eb2 trees_out::tree_node(tree_node*)
../.././gcc/cp/module.cc:9168
0xa1b813 module_state::write_pendings(elf_out*, vec,
depset::hash&, unsigned int, unsigned int*)
../.././gcc/cp/module.cc:15403
0xa1d050 module_state::write(elf_out*, cpp_reader*)
../.././gcc/cp/module.cc:17748
0xa1d71c finish_module_processing(cpp_reader*)
../.././gcc/cp/module.cc:19787
0x9b170b c_parse_final_cleanups()
../.././gcc/cp/decl2.c:5175
Please submit a full bug report,
with preprocessed source if appropriat

[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Note/workaround: the {CLOBBER} disappears if the argument to set_i is declared
INOUT instead of OUT.

[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||8.4.1
   Priority|P3  |P4
Summary|Segfault when passing   |[9/10/11 Regression]
   |allocatable scalar into |Segfault when passing
   |intent(out) dummy argument  |allocatable scalar into
   ||intent(out) dummy argument
 Ever confirmed|0   |1
   Target Milestone|--- |9.4
   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
  Known to fail||10.2.1, 11.0, 9.3.1
   Last reconfirmed||2021-02-19
 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

The tree dump shows that since at least 9.3.1 we clobber the pointer:

  integer(kind=4) * i;
...
  i = (integer(kind=4) *) __builtin_malloc (4);
...
  i = {CLOBBER};
  set_i (i);

New French PO file for 'gcc' (version 11.1-b20210207)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators.  The file is available at:

https://translationproject.org/latest/gcc/fr.po

(This file, 'gcc-11.1-b20210207.fr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #14 from Peter Bergner  ---
(In reply to seurer from comment #13)
> Thanks, that did fix it on trunk.

Marking as fixed then.  Thanks Vlad!

[Bug fortran/99147] Sanitizer detects heap-use-after-free in gfc_add_flavor

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

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

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

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

commit r11-7303-gaf027826292351218785f893d1c42fe28ae3ed9f
Author: Harald Anlauf 
Date:   Fri Feb 19 20:21:27 2021 +0100

PR fortran/99147 - Sanitizer detects heap-use-after-free in gfc_add_flavor

Reverse order of conditions to avoid invalid read.

gcc/fortran/ChangeLog:

* symbol.c (gfc_add_flavor): Reverse order of conditions.

[WIP] Re: [PATCH] openmp: Fix intermittent hanging of task-detach-6 libgomp tests [PR98738]

[Kwok Cheung Yeung]

Hello

Sorry for taking so long in replying.

On 29/01/2021 3:03 pm, Jakub Jelinek wrote:

It can also crash if team is NULL, which will happen any time
this is called outside of a parallel.  Just try (should go into testsuite
too):
#include 

int
main ()
{
   omp_event_handle_t ev;
   #pragma omp task detach (ev)
   omp_fulfill_event (ev);
   return 0;
}



I have included this as task-detach-11.{c|f90}.


Additionally, there is an important difference between fulfill for
included tasks and for non-included tasks, for the former there is no team
or anything to care about, for the latter there is a team and one needs to
take the task_lock, but at that point it can do pretty much everything in
omp_fulfill_event rather than handling it elsewhere.

So, what I'm suggesting is:

Replace
   bool detach;
   gomp_sem_t completion_sem;
with
   struct gomp_task_detach *detach;
and add struct gomp_task_detach that would contain everything that will be
needed (indirect so that we don't waste space for it in every task, but only
for those that have detach clause).
We need:
1) some way to tell if it is an included task or not
2) for included tasks the gomp_sem_t completion_sem
(and nothing but 1) and 2) for those),
3) struct gomp_team * for non-included tasks
4) some way to find out if the task has finished and is just waiting for
fulfill event (perhaps your GOMP_TASK_DETACHED is ok for that)
5) some way to find out if the task has been fulfilled already
(gomp_sem_t for that seems an overkill though)

1) could be done through the struct gomp_team *team; member,
set it to NULL in included tasks (no matter if they are in some team or not)
and to non-NULL team of the task (non-included tasks must have a team).



I have opted for a union of completion_sem (for tasks that are undeferred) and a 
struct gomp_team *detach_team (for deferred tasks) that holds the team if the 
completion event has not yet fulfilled, or NULL if is it. I don't see the point 
of having an indirection to the union here since the union is just the size of a 
pointer, so it might as well be inlined.



And I don't see the point of task_detach_queue if we can handle the
dependers etc. all in omp_fulfill_event, which I think we can if we take the
task_lock.


I have removed the task_detach_queue. The team barrier, taskwait and 
taskgroup_end now just set the task kind to GOMP_TASK_DETACHED without 
decrementing the task_count if a task finishes with detach_team non-NULL.



So, I think omp_fulfill_event should look at the task->detach it got,
if task->detach->team is NULL, it is included task, GOMP_task should have
initialized task->detach->completion_sem and omp_fulfill_event should just
gomp_sem_post it and that is all, GOMP_task for included task needs to
gomp_sem_wait after it finishes before it returns.


omp_fulfill_event now posts completion_sem if the task kind is 
OMP_TASK_UNDEFERRED, and GOMP_task waits for it. Since the task is executed 
within GOMP_task, it already knows if the task has a detach clause or not, so we 
do not need to store that information in gomp_task.



Otherwise, take the team's task_lock, and look at whether the task is still
running, in that case just set the bool that it has been fulfilled (or
whatever way of signalling 5), perhaps it can be say clearing task->detach
pointer).


detach_team is now set to NULL when the event is fulfilled if the task has not 
started yet or is still executing (checked by the kind). In that case, when the 
task finishes executing, it behaves just like a task without detach would and 
finishes normally.


  When creating non-included tasks in GOMP_task with detach clause

through gomp_malloc, it would add the size needed for struct
gomp_task_detach.


Not necessary with the inlined union.


But if the task is already in GOMP_TASK_DETACHED state, instead we need
while holding the task_lock do everything that would have been done normally
on task finish, but we've skipped it because it hasn't been fulfilled.
Including the waking/sem_posts when something could be waiting on that task.

Do you agree with this, or see some reason why this can't work?


The main problem I see is this code in gomp_barrier_handle_tasks:

  if (--team->task_count == 0
  && gomp_team_barrier_waiting_for_tasks (>barrier))
{
  gomp_team_barrier_done (>barrier, state);

We do not have access to state from within omp_fulfill_event, so how should this 
be handled?



And testsuite should include also cases where we wait for the tasks with
detach clause to be fulfilled at the end of taskgroup (i.e. need to cover
all of taskwait, taskgroup end and barrier).


I have changed task-detach-[56].* to test the barrier, task-detach-[78].* to 
test taskwait, and task-detach-(9|10) to test taskgroup (with the first one 
without a target construct, the second with).


I have included the current state of my patch. All task-detach-* tests pass when 
executed without offloading or with 

Re: [PATCH] run -Wnonnull later (PR 87489)

[Martin Sebor via Gcc-patches]

On 2/19/21 2:48 AM, Franz Sirl wrote:

Am 2021-02-01 um 01:31 schrieb Martin Sebor via Gcc-patches:

The initial -Wnonnull implementation in the middle end took place
too late in the pipeline (just before expansion), and as a result
was prone to false positives (bug 78817).  In an attempt to avoid
the worst of those, the warning was moved to the ccp2 pass in
r243874.  However, as the test case in PR 87489 shows, this is
in turn too early and causes other false positives as a result.

A few experiments with running the warning later suggest that
just before the mergephi2 pass is a good point to avoid this class
of false positives without causing any regressions or introducing
any new warnings either in Glibc or in Binutils/GDB.

Since PR 87489 is a GCC 8-11 regression I propose to make this
change on the trunk as well as on the release branches.


Hi Martin,

I tested your patch and it showed also one more warning for this 
testcase with -O2 -Wnonnull:


class b {
public:
   long c();
};
class B {
public:
   B() : f() {}
   b *f;
};
long d, e;
class g : B {
public:
   void h() {
     long a = f->c();
     d = e = a;
   }
};
class j {
   j();
   g i;
};
j::j() { i.h(); }

I hope cvise didn't minimize too much, but at least in the original much 
larger code the warning looks reasonable too.


Thanks.  Yes, the warning would be useful here since the f pointer
in the call to f->c() is null when i.h() is called from j's ctor.
The FRE3 pass clearly exposes this :

void j::j (struct j * const this)
{
  long int _9;

   [local count: 1073741824]:
  MEM[(struct B *)this_3(D)] ={v} {CLOBBER};
  MEM[(struct B *)this_3(D)].f = 0B;
  _9 = b::c (0B);
  ...

Because the warning runs early (after CCP2), the null pointer is
not detected.  To see it the warning code would have to work quite
hard to figure out that the two assignments below refer to the same
location (it would essentially have to do what FRE does):

  MEM[(struct B *)this_3(D)].f = 0B;
  _7 = MEM[(struct b * *)_1];
  _9 = b::c (_7);

It's probably too late to make this change for GCC 11 as Jeff has
already decided that it should be deferred until GCC 12, and even
then there's a concern that doing so might cause false positives.
I think it's worth revisiting the idea in GCC 12 to see if
the concern is founded.  Let me make a note of it in the bug.

Martin

Re: GCC generates non-compliant MIPS relocation data? Obscure GNU extension?

[Maciej W. Rozycki]

On Fri, 19 Feb 2021, Project Revolution via Gcc wrote:

> Gentlemen: this was fixed, although it's a bit of an odd solution. We 
> had to combine both -mno-explicit-relocs and -mno-split-addresses, even 
> though per the MIPS compiler documentation explicit relocs supersedes 
> the split addresses one. Neither of these options on their own work, and 
> it appears as though they're same result individually until you enable 
> both of these. It's really odd, but we're not questioning it since it 
> resolved our issue.

 The GNU extension that permits multiple R_MIPS_HI16 relocations to be 
matched with one R_MIPS_LO16 relocation for the ABIs such as o32 that use 
the REL relocation format lets the compiler make optimisations that would 
otherwise not be possible.  A typical use case is moving a LUI instruction 
targetted by multiple branches into the respective delay slots, resulting 
in overall shrinking of code by one instruction, such as transforming this 
(delay-slot instructions conventionally indented by one space):

.setnoreorder
# ...
beq $2, $3, $L16
 nop
# ...
$L16:
lui $4, %hi(foo)
lw  $5, %lo(foo)($4)
# ...
bltz$4, $L16
 nop

into this:

.setnoreorder
# ...
beq $2, $3, $L16
 lui$4, %hi(foo)
# ...
$L16:
lw  $5, %lo(foo)($4)
# ...
bltz$4, $L16
 lui$4, %hi(foo)

(depending on the execution flow, optimisation options and the ISA level 
chosen branch-likely instructions might be used instead).

 I agree the outcome of the years of MIPS psABI development reflected in 
what GCC and GNU binutils produce nowadays hasn't been properly documented 
and sources of information may be scarce.  The original SVR4 MIPS psABI 
document has had its issues and I believe no exact implementation exists, 
including though not limited to SGI IRIX.

 That said attempts were made in the past to document the state of affairs 
and here's one kept by archive.org that actually mentions the feature: 
.
The original has been lost however in the turbulent history of the various 
MIPS companies.

 I'm glad to hear you have found a usable workaround.  Otherwise I think 
we might consider adding an option to GCC to disable this psABI extension, 
however offhand I am not sure how difficult it would be to implement.

 It looks to me however that you actually have control over the relocation 
processing code you have referred, so how about improving it to handle the 
GNU R_MIPS_HI16 extension as well?

 It should be straightforward as proved by the usual consumers of MIPS 
object code, such as the GNU linker, the Linux kernel module loader, etc.  
It should give you a smaller code footprint too, to say nothing of the 
size regression the use of `-mno-explicit-relocs' usually results in.

 Have you considered it?

  Maciej

Re: [PATCH] clear VLA bounds from all arguments (PR 97172)

[Martin Sebor via Gcc-patches]

On 2/18/21 8:51 PM, Jeff Law wrote:



On 2/18/21 7:23 PM, Martin Sebor wrote:

The fix for PR 97172 that removes non-constant VLA bounds from
attribute access is incomplete: it inadvertently removes the bounds
corresponding to just the first VLA argument, and not from subsequent
arguments.

The attached change removes the vestigial condition that causes this
bug.  Since it's behind a build failure in a Fedora package (cava?)
I'll commit it under the "obvious" clause tomorrow if there are no
concerns.

Martin


gcc-97172-2.diff

PR c/97172 - ICE: tree code 'ssa_name' is not supported in LTO streams

gcc/ChangeLog:

* attribs.c (init_attr_rdwr_indices): Guard vblist use.
(attr_access::free_lang_data): Remove a spurious test.

gcc/testsuite/ChangeLog:

* gcc.dg/pr97172.c: Add test cases.

OK. Thanks.


I just committed this change in g:3599ecb6a01.

Martin

[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57

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

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

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

https://gcc.gnu.org/g:3599ecb6a0145a428def5314d2d67d2e5a88f3c4

commit r11-7301-g3599ecb6a0145a428def5314d2d67d2e5a88f3c4
Author: Martin Sebor 
Date:   Fri Feb 19 11:06:06 2021 -0700

PR c/97172 - ICE: tree code 'ssa_name' is not supported in LTO streams

gcc/ChangeLog:

PR c/97172
* attribs.c (init_attr_rdwr_indices): Guard vblist use.
(attr_access::free_lang_data): Remove a spurious test.

gcc/testsuite/ChangeLog:

PR c/97172
* gcc.dg/pr97172.c: Add test cases.

[Bug tree-optimization/99159] missing -Wnonull on member access through null

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||msebor at gcc dot gnu.org
   Severity|normal  |enhancement
   Last reconfirmed||2021-02-19
Summary|Confusing -Warray-bounds|missing -Wnonull on member
   |warning |access through null
 Ever confirmed|0   |1
 Blocks||95507

--- Comment #2 from Martin Sebor  ---
To expand on what Andrew said in comment #1: The code in test2() is undefined
because it dereferences a null pointer.  It's diagnosed by -Warray-bounds and
(with it disabled) by -Wstringop-overread, both of which expect objects to be
allocated at valid addresses.

-Wnonnull would arguably be a better warning to issue for this case but it
doesn't have the same logic as the other two.  In addition, and by the time
-Wnonnull runs, the null pointer has already been replaced by the non-null
address of the member:

void test2 ()
{
  struct s2 * p;
  struct s2 * pb.0_2;
  struct s1 * _3;

   :
  pb.0_2 = pb;
  _3 = _2->y;
  __builtin_memcpy (_3, 4B, 12);
  return;
}

Issuing -Wnonull here would mean either running the warning earlier (which runs
the risk of issuing more false positives) or also assuming that objects don't
live at constant addresses.

The code test1() is "conditionally undefined" (it's defined when f is zero) and
isn't diagnosed only because -Wnonnull doesn't handle conditionals (PHI nodes).
 A simple test case that shows the limitation is:

void f (void)
{ 
  char *q = 0;
  __builtin_puts (q);   // -Wnonnull
}

void g (char *p)
{
  char *q = *p ? p : 0;
  __builtin_puts (q);   // -Wnonnull
}

I can confirm this as an enhancement request for -Wnonull to diagnose both
problem(s).  That should automatically disable any subsequent warnings for the
same bug.


Referenced Bugs:

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

[Bug c++/99166] [modules] Unable to determine where CMI is being found

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #1 from Nathan Sidwell  ---
bfe83ae38e8 2021-02-19 | c++: Inform of CMI reads [PR 99166]

c++: Inform of CMI reads [PR 99166]

[Nathan Sidwell]

When successfully reading a module CMI,	the user gets no indication of 
where that CMI was located.  I originally didn't consider this a problem 
-- the read was successful after all.  But it can make it difficult to 
interact with build systems, particularly when caching can be involved. 
Grovelling over internal dump files is not really useful to the user. 
Hence this option, which is similar to the -flang-info-include-translate 
variants, and allows the user to ask for all, or specific module read 
notification.


gcc/c-family/
* c.opt (flang-info-module-read, flang-info-module-read=): New. 
gcc/
* doc/invoke.texi (flang-info-module-read): Document.
gcc/cp/
* module.cc (note_cmis): New.
(struct module_state): Add inform_read_p bit.
(module_state::do_import): Inform of CMI location, if enabled.
(init_modules): Canonicalize note_cmis entries.
(handle_module_option): Handle -flang-info-module-read=FOO.
gcc/testsuite/
* g++.dg/modules/pr99166_a.X: New.
* g++.dg/modules/pr99166_b.C: New.
* g++.dg/modules/pr99166_c.C: New.
* g++.dg/modules/pr99166_d.C: New.

--
Nathan Sidwell
diff --git c/gcc/c-family/c.opt w/gcc/c-family/c.opt
index b209d46d32b..3264c646ad3 100644
--- c/gcc/c-family/c.opt
+++ w/gcc/c-family/c.opt
@@ -1752,6 +1752,14 @@ flang-info-include-translate=
 C++ Joined RejectNegative MissingArgError(missing header name)
 Note a #include translation of a specific header.
 
+flang-info-module-read
+C++ Var(note_module_read_yes)
+Note Compiled Module Interface pathnames.
+
+flang-info-module-read=
+C++ Joined RejectNegative MissingArgError(missing module name)
+Note Compiled Module Interface pathname of a specific module or header-unit.
+
 fmax-include-depth=
 C ObjC C++ ObjC++ Joined RejectNegative UInteger
 fmax-include-depth= Set the maximum depth of the nested #include.
diff --git c/gcc/cp/module.cc w/gcc/cp/module.cc
index e801c52069e..691381bf995 100644
--- c/gcc/cp/module.cc
+++ w/gcc/cp/module.cc
@@ -317,6 +317,9 @@ version2string (unsigned version, verstr_t )
 /* Include files to note translation for.  */
 static vec *note_includes;
 
+/* Modules to note CMI pathames.  */
+static vec *note_cmis;
+
 /* Traits to hash an arbitrary pointer.  Entries are not deletable,
and removal is a noop (removal needed upon destruction).  */
 template 
@@ -3547,9 +3550,10 @@ class GTY((chain_next ("%h.parent"), for_user)) module_state {
 			   do it again  */
   bool call_init_p : 1; /* This module's global initializer needs
 			   calling.  */
+  bool inform_read_p : 1; /* Inform of a read.  */
   /* Record extensions emitted or permitted.  */
   unsigned extensions : SE_BITS;
-  /* 12 bits used, 4 bits remain  */
+  /* 13 bits used, 3 bits remain  */
 
  public:
   module_state (tree name, module_state *, bool);
@@ -3782,6 +3786,8 @@ module_state::module_state (tree name, module_state *parent, bool partition)
 
   partition_p = partition;
 
+  inform_read_p = false;
+
   extensions = 0;
   if (name && TREE_CODE (name) == STRING_CST)
 {
@@ -18634,6 +18640,8 @@ module_state::do_import (cpp_reader *reader, bool outermost)
 {
   const char *file = maybe_add_cmi_prefix (filename);
   dump () && dump ("CMI is %s", file);
+  if (note_module_read_yes || inform_read_p)
+	inform (loc, "reading CMI %qs", file);
   fd = open (file, O_RDONLY | O_CLOEXEC | O_BINARY);
   e = errno;
 }
@@ -19545,6 +19553,7 @@ init_modules (cpp_reader *reader)
   headers = BITMAP_GGC_ALLOC ();
 
   if (note_includes)
+/* Canonicalize header names.  */
 for (unsigned ix = 0; ix != note_includes->length (); ix++)
   {
 	const char *hdr = (*note_includes)[ix];
@@ -19567,6 +19576,37 @@ init_modules (cpp_reader *reader)
 	(*note_includes)[ix] = path;
   }
 
+  if (note_cmis)
+/* Canonicalize & mark module names.  */
+for (unsigned ix = 0; ix != note_cmis->length (); ix++)
+  {
+	const char *name = (*note_cmis)[ix];
+	size_t len = strlen (name);
+
+	bool is_system = name[0] == '<';
+	bool is_user = name[0] == '"';
+	bool is_pathname = false;
+	if (!(is_system || is_user))
+	  for (unsigned ix = len; !is_pathname && ix--;)
+	is_pathname = IS_DIR_SEPARATOR (name[ix]);
+	if (is_system || is_user || is_pathname)
+	  {
+	if (len <= (is_pathname ? 0 : 2)
+		|| (!is_pathname && name[len-1] != (is_system ? '>' : '"')))
+	  {
+		error ("invalid header name %qs", name);
+		continue;
+	  }
+	else
+	  name = canonicalize_header_name (is_pathname ? nullptr : reader,
+	   0, is_pathname, name, len);
+	  }
+	if (auto module = get_module (name))
+	  module->inform_read_p = 1;
+	else
+	  error ("invalid module name %qs", name);
+  }
+
   dump.push (NULL);
 
   /* Determine lazy handle bound.  */
@@ -19952,6 +19992,10 @@ handle_module_option (unsigned code, const char *str, int)
   vec_safe_push (note_includes, str);
   return true;
 
+

[Bug fortran/99169] New: Segfault when passing allocatable scalar into intent(out) dummy argument

[townsend at astro dot wisc.edu via Gcc-bugs]

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

Bug ID: 99169
   Summary: Segfault when passing allocatable scalar into
intent(out) dummy argument
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

Created attachment 50222
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50222=edit
Minimal working example

I've encountered a problem when passing an allocatable (and alread allocated)
scalar as an actual argument to a procedure with an intent(out) (but not
allocatable) dummy argument. The attached code illustrates the problem. 

Compiling with gfortran 10.2.0 at optimization level -O1 or -O2 leads to a
segmentation fault at runtime. The segfault arises when the dummy is assigned
within set_i(). This problem does not arise at optimization level -O0, and the
program performs as expected (outputting '5' to the terminal).

The problem also seems to disappear when set_i() is a CONTAINed procedure in
the main program, rather than a module procedure.

cheers,

Rich

[Bug fortran/98890] ICE on reference to module function

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

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

--- Comment #6 from Jerry DeLisle  ---
I should have noted in the above case, if we remove the parens on line 5,

   k = f1 is rejected.

[Bug target/98210] [11 Regression] SHF_GNU_RETAIN breaks gold linker generated binaries

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

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

Jozef Lawrynowicz  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|REOPENED|RESOLVED

--- Comment #10 from Jozef Lawrynowicz  ---
I think its best to close this as WONTFIX.

GCC will only erroneously enable SHF_GNU_RETAIN support if a Binutils version
between:
> commit 99fabbc9739a87ba3433e66792e93b773896790e
> Author: Jozef Lawrynowicz 
> Date:   Wed Nov 18 11:51:13 2020 +
>
>Support SHF_GNU_RETAIN ELF section flag

and

> commit ff4bc37d77a0ca7286883a477adcb3aa145fc782
> Author: Cary Coutant 
> Date:   Mon Dec 14 15:46:47 2020 -0800
> 
> Keep input SHF_GNU_RETAIN sections and strip output SHF_GNU_RETAIN for 
> GNU/FreBSD ELFOSABIs.

is being used. There's no Binutils release in this range.

[Bug fortran/99146] ICE in gfc_find_specific_dtio_proc

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

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

Tobias Burnus  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  ---
FIXED on mainline (GCC 11).

Thanks for the report!

[Bug fortran/99010] [11 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2322 since r11-7054-ge3f9f80bfa9e58a9

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #3 from Tobias Burnus  ---
FIXED. Thanks for the report!

[Bug fortran/99010] [11 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2322 since r11-7054-ge3f9f80bfa9e58a9

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r11-7299-gf86e187e12db14ad1cced26b9f8aafb06498e208
Author: Tobias Burnus 
Date:   Fri Feb 19 18:07:26 2021 +0100

Fortran: Fix coarray handling for gfc_dep_resolver [PR99010]

Check failed if identical = false was requested or for -fcoarray=single
if an array ref was for a coindexed scalar.

gcc/fortran/ChangeLog:

PR fortran/99010
* dependency.c (gfc_dep_resolver): Fix coarray handling.

gcc/testsuite/ChangeLog:

PR fortran/99010
* gfortran.dg/coarray/array_temporary-1.f90: New test.

[Bug fortran/99146] ICE in gfc_find_specific_dtio_proc

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:72d91d6cd41f2987339a98c2c64f70b3850f4e0b

commit r11-7298-g72d91d6cd41f2987339a98c2c64f70b3850f4e0b
Author: Tobias Burnus 
Date:   Fri Feb 19 18:05:31 2021 +0100

Fortran: Fix DTIO with type ICE [PR99146]

gcc/fortran/ChangeLog:

PR fortran/99146
* interface.c:

gcc/testsuite/ChangeLog:

PR fortran/99146
* gfortran.dg/dtio_36.f90: New test.

[Bug web/98875] DWARF5 as default causes perf probe to hang

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

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

--- Comment #5 from Mark Wielaard  ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565587.html

[PATCH] Document the GCC11 change to DWARF5 default.

[Mark Wielaard]

* gcc-11/changes.html (General Improvements): Add a section on
the DWARF version 5 default.
---
 htdocs/gcc-11/changes.html | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index de75b8d6..04c3c449 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -139,6 +139,36 @@ a work-in-progress.
   -fsanitize=kernel-hwaddress to instrument kernel 
code.
 
   
+  
+
+  For targets that produce DWARF debugging information GCC now
+  defaults to http://dwarfstd.org/doc/DWARF5.pdf;>DWARF
+  version 5 (with the exception of VxWorks and Darwin/Mac OS X
+  which default to version 2 and AIX which defaults to version 4).
+  This can produce up to 25% more compact debug information
+  compared to earlier versions.
+
+  To take full advantage of DWARF version 5 GCC needs to be build
+  against binutils version 2.35.2 or higher.  When GCC is build
+  against earlier versions of binutils GCC will still emit DWARF
+  version 5 for most debuginfo data, but will generate version 4
+  debug line tables (even when explicitly given -gdwarf-5).
+
+  The following debug information consumers can process DWARF version 5:
+  
+   GDB 8.0, or higher
+   valgrind 3.17.0
+   elfutils 0.172, or higher (for use with systemtap,
+ dwarves/pahole, perf and libabigail).
+  
+
+  Programs embedding libbacktrace are urged to upgrade to the version
+  shipping with GCC 11.
+
+  To make GCC 11 generate an older DWARF version
+  use -g together with -gdwarf-2,
+  -gdwarf-3 or -gdwarf-4.
+  
 
 
 
-- 
2.18.4

[Bug tree-optimization/91191] vrp and boolean arguments

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #8 from Andrew Macleod  ---
(In reply to Jeffrey A. Law from comment #7)
> If you're V_C_E-ing to a narrower type, you just ignore the bits outside the
> target type, it's a lot like a narrowing subreg in the RTL world.
> 
> I don't know what the semantics are for the widening case.  ISTM that it's
> not really helpful there.
> 

But isn't that the case here?

_6 = VIEW_CONVERT_EXPR(b_4(D));
if (_6 > 1)
  goto ; [INV]
else
  goto ; [INV]

we are widening the single bit BOOL into an 8 bit unsigned char...
so we need to decide if the other bits are always 0 or what

[Bug c/99168] inconsistent behavior on -O0 and -O2 with ASAN on

[zhan3299 at purdue dot edu via Gcc-bugs]

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

--- Comment #1 from zhan3299 at purdue dot edu ---
If we resolved the conflicts on "aligned", it would behave normally. I feel
like the ASAN is confused by the "aligned" somehow.

Should it have thrown some warnings?

[Bug fortran/98890] ICE on reference to module function

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #5 from Jerry DeLisle  ---
(In reply to Tobias Burnus from comment #4)
> Related issue but without an ICE:
> 
>contains
>   integer function f1()
> !f2 = 1   ! gives an error as expected
> j = f2!  accepted; cast of function addr to integer(kind=4)
> f1 = 1! ↑ ifort: 'already been used as an external function name'
>   end function
>   integer function f2()
> f2=1
>   end function
>end

A variation with a question:

program p1
  implicit none
  integer j, k
  j = 99
  k = f1()
  print *, j, k
contains  
  integer function f1()
!f2 = 1
j = f2  ! Should this be warned or rejected?
print *, j
f1 = 1  ! This should not be rejected
  end function
  integer function f2()
f2=1
  end function
end

[Bug c/99168] New: inconsistent behavior on -O0 and -O2 with ASAN on

[zhan3299 at purdue dot edu via Gcc-bugs]

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

Bug ID: 99168
   Summary: inconsistent behavior on -O0 and -O2 with ASAN on
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhan3299 at purdue dot edu
  Target Milestone: ---

I am not sure whether the following problem is caused by ASAN or O2.

Following code has different behaviors between "-fsanitize=address -O0" and
"-fsanitize=address -O2"

It affects my local 7.5.0, 10.2.0, and 11.0.0 on godbolt.

O0 (succ): https://godbolt.org/z/zMKP6K
O1 (succ): https://godbolt.org/z/Yf3oP7
O2 (fail): https://godbolt.org/z/erahvc
O3 (fail): https://godbolt.org/z/7zaqaf
Os (fail): https://godbolt.org/z/38e6xc

-

$ cat test.c
#include 

struct my_struct {
unsigned long volatile x;
} __attribute__((aligned(128)));

static int k[5][6] = {};

static struct my_struct s1 = {0UL};

static struct my_struct s2 __attribute__((aligned(32))) = {0UL};

int main() {
int i, j;
for (i = 0; i < 5; i++) {
for (j = 0; j < 6; j++) {
printf("%d\n", k[i][j]);
}
}

printf("%lu\n", s1.x);
printf("%lu\n", s2.x);

return 0;
}



$ gcc test.c -Wall -fsanitize=address -O0 -o g0.out 
# no any warning or error

$ gcc test.c -Wall -fsanitize=address -O2 -o g2.out 
# no any warning or error

$ ./g0.out
... # normal output

$ ./g2.out
=
==26165==ERROR: AddressSanitizer: global-buffer-overflow on address
0x55a5cf268184 at pc 0x55a5cf267201 bp 0x7ffd23b80f60 sp 0x7ffd23b80f50
READ of size 4 at 0x55a5cf268184 thread T0
#0 0x55a5cf267200 in main
(/root/docker_share/csmith/gcc_self_10/g2.out+0x1200)
#1 0x7efea78c10b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#2 0x55a5cf26726d in _start
(/root/docker_share/csmith/gcc_self_10/g2.out+0x126d)

0x55a5cf268184 is located 4 bytes inside of global variable 'k' defined in
'test.c:7:12' (0x55a5cf268180) of size 120
0x55a5cf268184 is located 4 bytes to the right of global variable 's2' defined
in 'test.c:11:25' (0x55a5cf268100) of size 128
SUMMARY: AddressSanitizer: global-buffer-overflow
(/root/docker_share/csmith/gcc_self_10/g2.out+0x1200) in main
Shadow bytes around the buggy address:
  0x0ab539e44fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab539e44ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab539e45000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab539e45010: 04 f9 f9 f9 f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9 f9
  0x0ab539e45020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ab539e45030:[f9]f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 f9
  0x0ab539e45040: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab539e45050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab539e45060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab539e45070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab539e45080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
  Shadow gap:  cc

Re: [patch, fortran] PR96686 Namelist group objects shall be defined before appearing in namelist

[Tobias Burnus]

Hi Jerry,

On 17.02.21 04:02, Jerry DeLisle wrote:

Attached patch adds to checks.  In the case of IMPLICIT typing it
checks to see if the objects listed in the NAMELIST have defined types
andf if not, sets them to the default implicit types.

In the case of IMPLICIT NONE, the types are required be declared
before the NAMELIST.   If an object type is found to not be declared
already, an error is issued.
Regression tested.

OK for trunk?


After taking a look while being less groggy,
it looks good to me, but I have a few remarks:

I think it looks cleaner to swap inner/outer the conditions, i.e.

if (sym->ts.type == BT_UNKNOWN)
  {
if (!gfc_current_ns->seen_implicit_none)
  ...
else
  ...
  }


+++ b/gcc/testsuite/gfortran.dg/namelist_4.f90
@@ -27,14 +27,14 @@ END module M1
  program P1
  CONTAINS
  ! This has the additional wrinkle of a reference to the object.
+  INTEGER FUNCTION F2()
+F2=1
+  END FUNCTION
INTEGER FUNCTION F1()
  NAMELIST /NML3/ F2 ! { dg-error "PROCEDURE attribute conflicts" }
  ! Used to ICE here
-f2 = 1 ! { dg-error "is not a VALUE" }
+f2 = 1 ! { dg-error "is not a variable" }
  F1=1
END FUNCTION
-  INTEGER FUNCTION F2()
-F2=1
-  END FUNCTION
  END


Unless I made a mistake, there is no need to modify this testcase – even
with the patch, the error remains the same.

However, if the "f2 = 1" line is removed, the previously hidden error in
the NAMELIST line is shown: 'PROCEDURE attribute conflicts with NAMELIST
attribute in ‘f2’ at (1)' is shown.

I think you should retain this testcase – and either add between the two
functions a new one, copying 'f1' but with 'f2 = 1' removed. You then
get the expected NAMELIST error. — Or to add a new testcase for this check.

PLUS: I think it would be useful to add a test of the form:

  namelist /nml/ f
  integer :: f

which then shows the new error (declared before the namelist) which
is currently not checked for.

 * * *

On 19.02.21 16:58, Jerry DeLisle wrote:

On 2/17/21 1:19 AM, Tobias Burnus wrote:

f2 looks like a local and implicitly typed real variable. At least ifort
compiles this program successfully.


I have to admit that I am not sure about this – implicit typing is odd,
if combined with host association. But I think you are right. I also got
confused due to the reordering, which is not needed.

Regarding:


contains
  integer function f1()
!f2 = 1   !This gives an error trying to assign a value to a
   function.

Okay. Also matches ifort: "This name has already been used as an
external function name."

j = f2! This is OK


This one is odd – you assign a function address to an integer (the
compiler does the casting). ifort rejects it with: "This name has
already been used as an external function name."

That looks like a variant of https://gcc.gnu.org/PR98890 – I added it as
additional example.

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf

[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter

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

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

--- Comment #13 from seurer at gcc dot gnu.org ---
Thanks, that did fix it on trunk.

[PATCH][obvious] Fix typo in param description.

[Martin Liška]

Pushed to master as obvious.

Martin

gcc/ChangeLog:

PR translation/99167
* params.opt: Fix typo.
---
 gcc/params.opt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/params.opt b/gcc/params.opt
index a4e1ac0e88e..0dd9ac406eb 100644
--- a/gcc/params.opt
+++ b/gcc/params.opt
@@ -957,7 +957,7 @@ Maximum number of references stored in each modref base.
 
 -param=modref-max-accesses=

 Common Joined UInteger Var(param_modref_max_accesses) Init(16) Param 
Optimization
-Maximum number of accesse stored in each modref reference.
+Maximum number of accesses stored in each modref reference.
 
 -param=modref-max-tests=

 Common Joined UInteger Var(param_modref_max_tests) Init(64) Param Optimization
--
2.30.1

[Bug translation/99167] typo in params.opt: accesse

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug translation/99167] typo in params.opt: accesse

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

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

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

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

commit r11-7297-gc8d13835638ff82f3ba7bfb0a5c2f597851dfb5a
Author: Martin Liska 
Date:   Fri Feb 19 17:29:23 2021 +0100

Fix typo in param description.

gcc/ChangeLog:

PR translation/99167
* params.opt: Fix typo.

Re: *PING**2 Re: [Patch] Fortran: Fix coarray handling for gfc_dep_resolver [PR99010] (was: Re: [Patch] Fortran: Fix Array dependency with local coarrays [PR98913]

[Jerry DeLisle]

On 2/19/21 1:33 AM, Tobias Burnus wrote:


On 09.02.21 12:52, Tobias Burnus wrote:

Hi all, hi Thomas,

On 02.02.21 18:15, Tobias Burnus wrote:

I think I will do a combination: If 'identical' is true, I think I
cannot remove it. If it is false, it can be identical or nonoverlapping
– which makes sense.


Well, it turned out that coarray scalars did not work; for them,
the array ref consists only of the coindexed access: falling through
then triggered as fin_dep == GFC_DEP_ERROR.

To be more careful, I also removed the 'identical &&' check such that
the first loop is now always triggered if coarray != SINGLE not only
if identical – I am not sure whether it is really needed or whether
falling though is the better solution (with updating the comment).

I would be happy if someone could carefully check the logic –
in the details, it is rather confusing.

OK?


Yes OK, thanks for patch.

Jerry

Re: [Patch] Fortran: Fix DTIO with type ICE [PR99146]

[Jerry DeLisle]

On 2/19/21 8:00 AM, Tobias Burnus wrote:

In this example, the formal argument is a derived type
and not a class – hence, there is an ICE.

OK for the trunk?

This is OK, could you also check 89219 and 81499 and see if these are 
the same or similar.


Much appreciated.

Jerry

[Bug translation/99167] typo in params.opt: accesse

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-02-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
I'll fix it.

[Bug fortran/99145] gfortran LOOP

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

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

--- Comment #3 from Jerry DeLisle  ---
Initially it is creating the very large string in the frontend passes and then
via resolution and translation phases, and finally into the middle-end and back
end phases where it I am guessing the optimizers are realizing the
simplifications.

It is a known that some of these special cases are not recognized in the front
end and immediately reduced.  In this case it is creating a literal constant
that big. Normally a program would be attempting to use the parameter in more
than one place in which case it is literally substituted in.

Should we mark this as invalid?

[Bug translation/99167] New: typo in params.opt: accesse

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 99167
   Summary: typo in params.opt: accesse
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

> Maximum number of accesse stored in each modref reference.

Should be 'accesses'.

[Bug fortran/98890] ICE on reference to module function

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

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

--- Comment #4 from Tobias Burnus  ---
Related issue but without an ICE:

   contains
  integer function f1()
!f2 = 1   ! gives an error as expected
j = f2!  accepted; cast of function addr to integer(kind=4)
f1 = 1! ↑ ifort: 'already been used as an external function name'
  end function
  integer function f2()
f2=1
  end function
   end

[Bug libgcc/99157] [ARM] libgcc -mcmse check always fail

[hsuhau617 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hau Hsu  ---
Here are some more info.

This check determines whether macro __ARM_FEATURE_CMSE is set to 3,
and affects CMSE support for function cmse_check_address_range():

void *
__attribute__ ((warn_unused_result))
cmse_check_address_range (void *p, size_t size, int flags)
{
...
#if __ARM_FEATURE_CMSE & 2
case CMSE_MPU_NONSECURE:
  permb = cmse_TTA (pb);
  perme = singleCheck ? permb : cmse_TTA (pe);
  break;
case CMSE_MPU_UNPRIV | CMSE_MPU_NONSECURE:
  permb = cmse_TTAT (pb);
  perme = singleCheck ? permb : cmse_TTAT (pe);
  break;
#endif
...
}

Since the check always fail, CMSE support for all multilibs are disabled.

The objdump results of v8-m.main libgcc for gcc-arm-none-eabi-7-2018-q2-update
and gcc-arm-none-eabi-10-2020-q4-major are attached.

[Bug web/98875] DWARF5 as default causes perf probe to hang

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

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

Mark Wielaard  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |mark at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-02-19
  Component|debug   |web

--- Comment #4 from Mark Wielaard  ---
(In reply to Paul Clarke from comment #3)
> The IBM Advance Toolchain supports SLES 15, where the latest version of
> libdw is 0.168. We'll work around the issue by reverting the commit for the
> version of GCC included with the Advance Toolchain.

Yes, that is probably reasonable when targetting a distro that is so old that
it doesn't have any tooling to support DWARF5.

Still you might want to request that the perf tool be fixed to simply skip the
DWARF5 data instead of going into an infinite loop. That bug could trigger for
any DWARF that old perf/libdw doesn't know about and it really should just skip
it. The fix for that really is just a oneliner.

> I didn't see any update to the GCC documentation regarding the disruptive
> nature of the change causing the problem other than "[DWARF] Version 5
> requires GDB 8.0 or higher".
> 
> Should there be something about libdw as well?  Anything else?

You are right. I'll submit an update for the GCC 11 Release Notes to document
things.

[Bug libgcc/99157] [ARM] libgcc -mcmse check always fail

[hsuhau617 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hau Hsu  ---
Created attachment 50221
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50221=edit
libgcc objdump result for gcc-7 and gcc-10

[Patch] Fortran: Fix DTIO with type ICE [PR99146]

[Tobias Burnus]

In this example, the formal argument is a derived type
and not a class – hence, there is an ICE.

OK for the trunk?

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf
Fortran: Fix DTIO with type ICE [PR99146]

gcc/fortran/ChangeLog:

	PR fortran/99146
	* interface.c:

gcc/testsuite/ChangeLog:

	PR fortran/99146
	* gfortran.dg/dtio_36.f90: New test.

 gcc/fortran/interface.c   |  4 +++-
 gcc/testsuite/gfortran.dg/dtio_36.f90 | 33 +
 2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 87fe14280e6..f7ca52e6550 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -5305,7 +5305,9 @@ gfc_find_specific_dtio_proc (gfc_symbol *derived, bool write, bool formatted)
 }
 
 finish:
-  if (dtio_sub && derived != CLASS_DATA (dtio_sub->formal->sym)->ts.u.derived)
+  if (dtio_sub
+  && dtio_sub->formal->sym->ts.type == BT_CLASS
+  && derived != CLASS_DATA (dtio_sub->formal->sym)->ts.u.derived)
 gfc_find_derived_vtab (derived);
 
   return dtio_sub;
diff --git a/gcc/testsuite/gfortran.dg/dtio_36.f90 b/gcc/testsuite/gfortran.dg/dtio_36.f90
new file mode 100644
index 000..4e53581b86a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dtio_36.f90
@@ -0,0 +1,33 @@
+! { dg-do compile }
+!
+! PR fortran/99146
+!
+  MODULE p
+  TYPE :: person
+  sequence
+  END TYPE person
+  INTERFACE READ(UNFORMATTED)
+   MODULE PROCEDURE pruf
+  END INTERFACE
+
+  CONTAINS
+
+  SUBROUTINE pruf (dtv,unit,iostat,iomsg)
+   type(person), INTENT(INOUT) :: dtv
+   INTEGER, INTENT(IN) :: unit
+   INTEGER, INTENT(OUT) :: iostat
+   CHARACTER (LEN=*), INTENT(INOUT) :: iomsg
+   iostat = 1
+  END SUBROUTINE pruf
+
+  END MODULE p
+
+  PROGRAM test
+  USE p
+  TYPE (person) :: chairman
+
+  OPEN (UNIT=71, status = 'scratch', FORM='UNFORMATTED')
+
+  read(71) chairman
+
+  END PROGRAM test

[Bug fortran/99147] Sanitizer detects heap-use-after-free in gfc_add_flavor

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Vittorio Zecca  ---
I changed symbol.c as per your suggestion and now the address
sanitized gfortran compiles fine.
Now I am going to check it against the testsuite.
Results tomorow.

[Bug tree-optimization/99165] ICE in verify_dominators, at dominance.c:1184 since r11-7205-g95d94b52ea847833

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[11 Regression] ICE in  |ICE in verify_dominators,
   |verify_dominators, at   |at dominance.c:1184 since
   |dominance.c:1184 since  |r11-7205-g95d94b52ea847833
   |r11-7205-g95d94b52ea847833  |

--- Comment #2 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #1)
> Is that really a regression given you need an option that didn't exist
> before?

No, sorry.

[Bug tree-optimization/99165] [11 Regression] ICE in verify_dominators, at dominance.c:1184 since r11-7205-g95d94b52ea847833

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Is that really a regression given you need an option that didn't exist before?

[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
The demangler does the right, although confusing thing.  Because the Itanium
ABI says that g is __float128:
 ::= f  # float
 ::= d  # double
 ::= e  # long double, __float80
 ::= g  # __float128

[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to seurer from comment #0)
> 3 incompatible symbols
> 0
> _ZSt8to_charsPcS_g
> std::to_chars(char*, char*, __float128)


It took me a while to realise that these symbols are not __float128, they're
__ibm128, but the demangler turns 'g' into __float128.

Is that still the case for the latest version of the demangler? Because that's
very confusing.

The actual __float128 type mangles as '__u9__ieee128' not 'g', so if I define
"std::to_chars(char*, char*, __float128)" in my code, it doesn't get mangled as
shown above.

[Bug c/99156] __builtin_expect affects the interpretation of its first operand

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-02-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Yes, I can confirm the issue. Thanks for the report.

[Bug c/99137] ICE in gimplify_scan_omp_clauses, at gimplify.c:9833

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

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

--- Comment #5 from Tobias Burnus  ---
Iff it is decided that it is invalid code, the following patch rejects it:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565576.html

(I forgot to reload the PR before posting.)

Re: [PATCH][PR98791]: IRA: Make sure allocno copy mode's are ordered

[Vladimir Makarov via Gcc-patches]

On 2021-02-19 5:53 a.m., Andre Vieira (lists) wrote:

Hi,

This patch makes sure that allocno copies are not created for 
unordered modes. The testcases in the PR highlighted a case where an 
allocno copy was being created for:

(insn 121 120 123 11 (parallel [
    (set (reg:VNx2QI 217)
    (vec_duplicate:VNx2QI (subreg/s/v:QI (reg:SI 93 [ _2 
]) 0)))

    (clobber (scratch:VNx16BI))
    ]) 4750 {*vec_duplicatevnx2qi_reg}
 (expr_list:REG_DEAD (reg:SI 93 [ _2 ])
    (nil)))

As the compiler detected that the vec_duplicate_reg pattern 
allowed the input and output operand to be of the same register class, 
it tried to create an allocno copy for these two operands, stripping 
subregs in the process. However, this meant that the copy was between 
VNx2QI and SI, which have unordered mode precisions.


So at compile time we do not know which of the two modes is smaller 
which is a requirement when updating allocno copy costs.


Regression tested on aarch64-linux-gnu.

Is this OK for trunk (and after a week backport to gcc-10) ?

OK.  Yes, it is wise to wait a bit and see how the patch behaves on the 
trunk before submitting it to gcc-10 branch.  Sometimes such changes can 
have quite unexpected consequences.  But I guess not in this is case.


Thank you for working on the issue.


gcc/ChangeLog:
2021-02-19  Andre Vieira  

    PR rtl-optimization/98791
    * ira-conflicts.c (process_regs_for_copy): Don't create 
allocno copies for unordered modes.


gcc/testsuite/ChangeLog:
2021-02-19  Andre Vieira  

    PR rtl-optimization/98791
    * gcc.target/aarch64/sve/pr98791.c: New test.

[Bug c++/98967] warning to spot recursive include graph

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
discussing with clang guys, Richard wondered whether we'd make this the default
(eventually?).  to do that, would require a smarter implementation that
explicitly pushed and popped the line table (or an appropriate action with
include translate).  That'd also make it work for #import and #pragma once.

[Bug go/99164] gccgo internal compiler error: alias receiver

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #1 from Ian Lance Taylor  ---
Thanks.  This is already fixed by https://golang.org/cl/291991.

Re: How to decide the what type is currently being used in tree_node?

[Shuai Wang via Gcc]

Hello!

Thank you for the information. I am also quite confused with this issue. I
note that it seems that given the following statement:

m_pstSwtmrCBArray.27_1 = m_pstSwtmrCBArray;

where m_pstSwtmrCBArray is a global variable (a pointer). When passing a
tree pointer `v` referring to m_pstSwtmrCBArray to the following statement:

auto temp = TREE_CODE(v);

It will cause a segmentation fault of my GIMPLE pass. Not sure what's
actually going on here...

Best,
Shuai


On Fri, Feb 19, 2021 at 4:54 PM Prathamesh Kulkarni <
prathamesh.kulka...@linaro.org> wrote:

> On Fri, 19 Feb 2021 at 10:31, Shuai Wang via Gcc  wrote:
> >
> > Hello,
> >
> > I noticed that tree_node is implemented as a union (
> > https://code.woboq.org/gcc/gcc/tree-core.h.html#tree_node). However, I
> > cannot find a way of checking whether the current tree_node is really a
> > base or type.
> >
> > For instance, currently when I am using:
> >
> > is_gimple_constant(v)
> >
> > Given `v` as a tree type but NOT base type, the above statement would
> > crash. I am thinking there should be a method like:
> >
> > is_tree_base(v) == false
> >
> > or something like this; however, I couldn't find one. Can anyone shed
> some
> > lights on this? Thank you very much!
> If you want to ascertain which class the tree node belongs to, you can
> use either TREE_CODE, or one of the _P macros
> defined in tree.h. If you use an accessor that needs tree node
> belonging to a certain class, then you need to check for it before
> hand.
> For example before using DECL_NAME on a tree node, you need to
> explicitly check if it's indeed a decl_node using DECL_P.
> For is_gimple_constant(v), it will return true if v is a one of the
> constant nodes (*_CST), and false otherwise, so I don't see how it
> will crash if you
> pass a non-constant node ?
>
> Thanks,
> Prathamesh
> >
> > best,
> > Shuai
>

RE: [PATCH] slp: fix sharing of SLP only patterns. (PR99149)

[Tamar Christina via Gcc-patches]

Ps. The code in comment is needed, but was commented out due to the early free 
issue described in the patch.

Thanks,
Tamar

> -Original Message-
> From: Tamar Christina 
> Sent: Friday, February 19, 2021 2:42 PM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de
> Subject: [PATCH] slp: fix sharing of SLP only patterns. (PR99149)
> 
> Hi Richi,
> 
> The attached testcase ICEs due to a couple of issues.
> In the testcase you have two SLP instances that share the majority of their
> definition with each other.  One tree defines a COMPLEX_MUL sequence
> and the other tree a COMPLEX_FMA.
> 
> The ice happens because:
> 
> 1. the refcounts are wrong, in particular the FMA case doesn't correctly count
> the references for the COMPLEX_MUL that it consumes.
> 
> 2. when the FMA is created it incorrectly assumes it can just tear apart the
> MUL node that it's consuming.  This is wrong and should only be done when
> there is no more uses of the node, in which case the vector only pattern is no
> longer relevant.
> 
> To fix the last part the SLP only pattern reset code was moved into
> vect_free_slp_tree which results in cleaner code.  I also think it does belong
> there since that function knows when there are no more uses of the node
> and so the pattern should be unmarked, so when the the vectorizer is
> inspecting the BB it doesn't find the now invalid vector only patterns.
> 
> This has the obvious problem in that, eventually after analysis is done, the
> entire SLP tree is dissolved before codegen.  Where we get into trouble as
> we have now dissolved the patterns too...
> 
> My initial thought was to add a parameter to vect_free_slp_tree, but I know
> you wouldn't like that.  So I am sending this patch up as an RFC.
> 
> PS. This testcase actually shows that the codegen we get in these cases is not
> optimal.  Currently this won't vectorize as the compiler thinks the vector
> version is too expensive.
> 
> My guess here is because the patterns now unshare the tree and it's likely
> costing the setup for the vector code twice?
> 
> Even with the shared code (without patterns, so same as GCC 10, or turning
> off the patterns) it won't vectorize it.
> 
> The scalar code is
> 
> mov w0, 0
> ldr x4, [x1, #:lo12:.LANCHOR0]
> ldrsw   x2, [x3, 20]
> ldr x1, [x3, 8]
> lsl x2, x2, 3
> ldrsw   x3, [x3, 16]
> ldp s3, s2, [x4]
> add x5, x1, x2
> ldr s0, [x1, x2]
> lsl x3, x3, 3
> add x4, x1, x3
> fmuls1, s2, s2
> fnmsub  s1, s3, s3, s1
> fmuls0, s2, s0
> fmadd   s0, s3, s2, s0
> ldr s3, [x1, x3]
> ldr s2, [x4, 4]
> fadds3, s3, s1
> fadds2, s0, s2
> str s3, [x1, x3]
> str s2, [x4, 4]
> str s1, [x1, x2]
> str s0, [x5, 4]
> ret
> 
> and turning off the cost model we get
> 
> moviv1.2s, 0
> mov w0, 0
> ldr x4, [x1, #:lo12:.LANCHOR0]
> ldrsw   x3, [x2, 16]
> ldr x1, [x2, 8]
> ldrsw   x2, [x2, 20]
> ldr d0, [x4]
> fcmla   v1.2s, v0.2s, v0.2s, #0
> ldr d2, [x1, x3, lsl 3]
> fcmla   v2.2s, v0.2s, v0.2s, #0
> fcmla   v2.2s, v0.2s, v0.2s, #90
> str d2, [x1, x3, lsl 3]
> fcmla   v1.2s, v0.2s, v0.2s, #90
> str d1, [x1, x2, lsl 3]
> 
> however, if the pattern matcher doesn't create the FMA node because it
> would unshare the tree (which I think is a general heuristic that would work
> out to better code wouldn't it?) then we would get (with the cost model
> enabled even)
> 
> moviv0.2s, 0
> mov w0, 0
> ldr x4, [x1, #:lo12:.LANCHOR0]
> ldrsw   x3, [x2, 16]
> ldr x1, [x2, 8]
> ldr d1, [x4]
> fcmla   v0.2s, v1.2s, v1.2s, #0
> fcmla   v0.2s, v1.2s, v1.2s, #90
> ldrsw   x2, [x2, 20]
> ldr d1, [x1, x3, lsl 3]
> faddv1.2s, v1.2s, v0.2s
> str d1, [x1, x3, lsl 3]
> str d0, [x1, x2, lsl 3]
> ret
> 
> Which is the most optimal form.  So I think this should perhaps be handled in
> GCC 12 if there's a way to detect when you're going to unshare a sub-tree.
> 
> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/99149
>   * tree-vect-slp-patterns.c (vect_detect_pair_op): Don't recreate the
>   buffer.
>   (vect_slp_reset_pattern): Remove.
>   (complex_fma_pattern::matches): Remove call to
> vect_slp_reset_pattern.
>   (complex_mul_pattern::build, complex_fma_pattern::build,
>   complex_fms_pattern::build): Fix ref counts.
>   * tree-vect-slp.c (vect_free_slp_tree): Undo SLP only pattern
> relevancy
>   when node is being deleted.
>   * tree-vectorizer.c (vec_info::new_stmt_vec_info): Initialize value.
> 
> gcc/testsuite/ChangeLog:

[Bug tree-optimization/98357] Bounds check not eliminated

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||aldyh at redhat dot com,
   ||amacleod at redhat dot com

--- Comment #3 from Andrew Macleod  ---
We should be able to handle this in GCC 12 . The WIP relation support in ranger
currently is showing:

 :
_1 = i_6(D) < len_7(D);
_2 = i_6(D) >= j_8(D);
_3 = _1 & _2;
if (_3 != 0)
  goto ; [INV]
else
  goto ; [INV]

=== BB 3 
len_7(D)size_t [1, +INF]
j_8(D)  size_t VARYING
Relational : (i_6(D) >= j_8(D))
Relational : (i_6(D) < len_7(D))
 :
if (len_7(D) > j_8(D))
  goto ; [INV]
else
  goto ; [INV]

So once I get the transitive queries of relations working, we should be able to
recognize
  len_7 > i_6 >= j_8 
and then the condition will fold trivially eliminating the call to exit().

[PATCH] slp: fix sharing of SLP only patterns. (PR99149)

[Tamar Christina via Gcc-patches]

Hi Richi,

The attached testcase ICEs due to a couple of issues.
In the testcase you have two SLP instances that share the majority of their
definition with each other.  One tree defines a COMPLEX_MUL sequence and the
other tree a COMPLEX_FMA.

The ice happens because:

1. the refcounts are wrong, in particular the FMA case doesn't correctly count
the references for the COMPLEX_MUL that it consumes.

2. when the FMA is created it incorrectly assumes it can just tear apart the MUL
node that it's consuming.  This is wrong and should only be done when there is
no more uses of the node, in which case the vector only pattern is no longer
relevant.

To fix the last part the SLP only pattern reset code was moved into
vect_free_slp_tree which results in cleaner code.  I also think it does belong
there since that function knows when there are no more uses of the node and so
the pattern should be unmarked, so when the the vectorizer is inspecting the BB
it doesn't find the now invalid vector only patterns.

This has the obvious problem in that, eventually after analysis is done, the
entire SLP tree is dissolved before codegen.  Where we get into trouble as we
have now dissolved the patterns too...

My initial thought was to add a parameter to vect_free_slp_tree, but I know you
wouldn't like that.  So I am sending this patch up as an RFC.

PS. This testcase actually shows that the codegen we get in these cases is not
optimal.  Currently this won't vectorize as the compiler thinks the vector
version is too expensive.

My guess here is because the patterns now unshare the tree and it's likely
costing the setup for the vector code twice?

Even with the shared code (without patterns, so same as GCC 10, or turning off
the patterns) it won't vectorize it.

The scalar code is

mov w0, 0
ldr x4, [x1, #:lo12:.LANCHOR0]
ldrsw   x2, [x3, 20]
ldr x1, [x3, 8]
lsl x2, x2, 3
ldrsw   x3, [x3, 16]
ldp s3, s2, [x4]
add x5, x1, x2
ldr s0, [x1, x2]
lsl x3, x3, 3
add x4, x1, x3
fmuls1, s2, s2
fnmsub  s1, s3, s3, s1
fmuls0, s2, s0
fmadd   s0, s3, s2, s0
ldr s3, [x1, x3]
ldr s2, [x4, 4]
fadds3, s3, s1
fadds2, s0, s2
str s3, [x1, x3]
str s2, [x4, 4]
str s1, [x1, x2]
str s0, [x5, 4]
ret

and turning off the cost model we get

moviv1.2s, 0
mov w0, 0
ldr x4, [x1, #:lo12:.LANCHOR0]
ldrsw   x3, [x2, 16]
ldr x1, [x2, 8]
ldrsw   x2, [x2, 20]
ldr d0, [x4]
fcmla   v1.2s, v0.2s, v0.2s, #0
ldr d2, [x1, x3, lsl 3]
fcmla   v2.2s, v0.2s, v0.2s, #0
fcmla   v2.2s, v0.2s, v0.2s, #90
str d2, [x1, x3, lsl 3]
fcmla   v1.2s, v0.2s, v0.2s, #90
str d1, [x1, x2, lsl 3]

however, if the pattern matcher doesn't create the FMA node because it would
unshare the tree (which I think is a general heuristic that would work out to
better code wouldn't it?) then we would get (with the cost model enabled even)

moviv0.2s, 0
mov w0, 0
ldr x4, [x1, #:lo12:.LANCHOR0]
ldrsw   x3, [x2, 16]
ldr x1, [x2, 8]
ldr d1, [x4]
fcmla   v0.2s, v1.2s, v1.2s, #0
fcmla   v0.2s, v1.2s, v1.2s, #90
ldrsw   x2, [x2, 20]
ldr d1, [x1, x3, lsl 3]
faddv1.2s, v1.2s, v0.2s
str d1, [x1, x3, lsl 3]
str d0, [x1, x2, lsl 3]
ret

Which is the most optimal form.  So I think this should perhaps be handled in
GCC 12 if there's a way to detect when you're going to unshare a sub-tree.

Thanks,
Tamar

gcc/ChangeLog:

PR tree-optimization/99149
* tree-vect-slp-patterns.c (vect_detect_pair_op): Don't recreate the
buffer.
(vect_slp_reset_pattern): Remove.
(complex_fma_pattern::matches): Remove call to vect_slp_reset_pattern.
(complex_mul_pattern::build, complex_fma_pattern::build,
complex_fms_pattern::build): Fix ref counts.
* tree-vect-slp.c (vect_free_slp_tree): Undo SLP only pattern relevancy
when node is being deleted.
* tree-vectorizer.c (vec_info::new_stmt_vec_info): Initialize value.

gcc/testsuite/ChangeLog:

PR tree-optimization/99149
* gcc.dg/vect/pr99149.C: New test.

--- inline copy of patch -- 
diff --git a/gcc/testsuite/gcc.dg/vect/pr99149.C 
b/gcc/testsuite/gcc.dg/vect/pr99149.C
new file mode 100755
index 
..b12fe17e4ded148ce2bf67486e425dd65461a148
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr99149.C
@@ -0,0 +1,25 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-w -O3 -march=armv8.3-a" { target { aarch64*-*-* } 
} } */
+
+class a {
+  float b;
+  float c;
+
+public:
+  a(float d, float e) : b(d), c(e) {}
+  

[Bug c++/99166] New: [modules] Unable to determine where CMI is being found

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

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

Bug ID: 99166
   Summary: [modules] Unable to determine where CMI is being found
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

If a CMI file is not found one gets a diagnostic saying where it was looking. 
For include translation -flang-info-include-translate and friends are there to
inform.  But there is no information when the compiler reads a found CMI, which
can be confusing to build system debugging.  

Add -flang-info-module-cmi and friends in a similar vein to the
include-translate informs

[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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