[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

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

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

Bug 94916 Summary: Failure to optimize pattern into difference or zero selector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94916

   What|Removed |Added

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

[Bug tree-optimization/94916] Failure to optimize pattern into difference or zero selector

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=3507
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
GCC 13 gets:
movl%edi, %eax
xorl%edx, %edx
subl%esi, %eax
cmpl%esi, %edi
cmovl   %edx, %eax
ret


The rest is recorded as PR 3507.

So closing as fixed.

[Bug rtl-optimization/3507] appalling optimisation with sub/cmp on multiple targets

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #61 from Andrew Pinski  ---
Rask Ingemann Lambertsen has not been around working on GCC for over 10 years
so unassigning.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Thomas Koenig  writes:

> C99, 6.7.2, "Type specifiers"
>
> # Constraints
>
> # At least one type specifier shall be given in the declaration
> # specifiers in each declaration, and in the specifier-qualifier
> # list in each struct declaration and type name.

And?

> In C99 and onwards, this is an error (a violation of a "shall"
> directive).

There are no ``errors'' in Standard C (with the possible exception of
the #error preprocessing directive), only constraint and syntax rule
violations.  Such violations are required to generate diagnostic
messages, after which the behavior of the translator ceases to be
defined by the Standard, but GNU C defines it to mean that the type is
int.

Nor does GCC conform to the Standard by default: while it is okay for a
conforming implementation to translate programs relying on implicit int,
as there is no way doing so will alter the behavior of any strictly
conforming program, it is not okay to reserve keywords such as `asm'.

The following strictly conforming program is thus not acceptable to GCC,
unless GCC is operating in standards-conformance mode:

  int
  main (argc, argv)
  int argc;
  char **argv;
  {
int asm;
return asm = 0;
  }

which shows that debating features based on the Standard is entirely
pointless, as the Standard allows implementations to provide almost
anything it prohibits.

So I ask you again: what is unclear about declarations which are
implicitly int, in a way that is likely to cause program errors?

[Bug tree-optimization/95408] Failure to optimize bitwise and with negated conditional using the same operand to conditional with decremented operand

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Last reconfirmed||2023-05-13
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Andrew Pinski  ---
For unsigned x (to simplify things first).
In forwardprop4 we have
  _1 = x_4(D) <= 121211;
  _3 = _1 ? x_4(D) : 0;
  _5 = _3 != 0;

This could be done as:
x_4(D) <= 121211 ? x_4(D) != 0 : 0

Which then would be:
(x_4(D) <= 121211 & x_4(D) != 0) 
((x_4(D) - 1) <= 121210)

So I have a patch which does the second step into the 3rd expression (there is
another bug or 2 about it). the 3rd expression into the final is already done.
It is just the first that needs to happen to written up.

Something like this for the first step.
(for op (tcc_comparison)
/* (c ? a : CST0) op CST1  -->  c ? (a op CST1) : (CST0 op CST1) */
 (simplify
  (op (cond:s @0 @1 CONSTANT_CLASS_P@2) CONSTANT_CLASS_P@3)
  (cond! @0 (op @1 @3) (op @2 @4)))

So mine.

Re: More C type errors by default for GCC 14

[Thomas Koenig via Gcc]

On 13.05.23 02:45, Po Lu via Gcc wrote:

Gabriel Ravier  writes:


...You're joking, right ? You can't possibly be seriously arguing
this, you have to be kidding... right ?


No, I'm not.  The meaning of a variable declaration with only a storage
class specifier is extremely clear: the type of the variable is `int'.


C99, 6.7.2, "Type specifiers"

# Constraints

# At least one type specifier shall be given in the declaration
# specifiers in each declaration, and in the specifier-qualifier
# list in each struct declaration and type name.


There's absolutely nothing ambiguous about it whatsoever:


In C99 and onwards, this is an error (a violation of a "shall"
directive).


   register i;
   extern   limit, *k, do_some_computation ();

   for (i = 0; i < limit; ++i)
 k[i] = do_some_computation (i);

Please try to prove me wrong.


Happy to oblige.

[Bug c++/106943] GCC building clang/llvm with LTO flags causes ICE in clang

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

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

--- Comment #30 from Xi Ruoyao  ---
https://reviews.llvm.org/D150505.

[Bug tree-optimization/94893] Sign function not getting optimized to simple compare

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

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

--- Comment #3 from Andrew Pinski  ---
Note we also don't optimize:

inline int sign1(int x)
{
return (x < 0 ? -1 : 0) | (x > 0 ? 1 : 0);
}
bool f1(int x)
{
return sign1(x) < 1;
}

To be just `x <= 0`

[Bug middle-end/98710] missing optimization (x | c) & ~(y | c) -> x & ~(y | c)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2021-04-26 00:00:00 |2023-5-12

--- Comment #2 from Andrew Pinski  ---
(x | c) & ~(y | c) ->
(x | c) & (~y & ~c) ->
(x & ~y & ~c) | (c & ~y & ~c) ->
(x & ~y & ~c) ->
x & ~(y | c)


Just this simple:
(simplify
 (bit_and:c (bit_ior:c @0 @1) (bit_not@3 (bit_ior:c @1 @2)))
 (bit_and @0 @3))

No reason to rewrite @3 part again.

[Bug middle-end/104069] Wuse-after-free=2 -O0 false positive "may be used"

[mkaracsony81 at gmail dot com via Gcc-bugs]

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

--- Comment #34 from Miklos Karacsony  ---
(In reply to Sergei Trofimovich from comment #32)
> Created attachment 55068 [details]
> gzip.c.c
> 
> > > You should be able to extract preprocessed file using
> > > https://gcc.gnu.org/bugs/#need: you will need to find exact `gcc` 
> > > invocation
> > > that causes build failure, add `-save-temps` parameter to it, grab '*.i'
> > > file and attach it along with exact command you used to produce it.
> > 
> > That gcc page does not say how to extract the command from the makefile that
> > triggers the error, so I've tried to reproduce this bug manually and after
> > like the 8th attempt when all the header files were finally found by the
> > compiler, the linker errored out with some undefined references, so no luck.
> > The good new is that this error is reproducible if the
> > cflags/ldflags/configure...etc switches set up like in c#29
> 
> gcc help can't cover specifics of external build systems. You have to have a
> bit of expertise to extract the actual command build system runs.
> 
> As elfutils is an automake-maked '$ make V=1' will print you every gcc
> command the build system is running. It should be in a form you can copy and
> paste as is (modulo current directory and a few environment variables).
> 
> I think I reproduced it on gcc-12.2.0 and elfutils-0.189. Attached as
> gzip.c.c.
> 
> Trigger on gcc-12.2.0:
> 
> $ gcc  -std=gnu99 -Wall  -Werror -Os -mtune=generic -c gzip.c.c
> In function 'bigger_buffer',
> inlined from '__libdw_gunzip' at gzip.c.c:7751:13:
> gzip.c.c:7609:13: error: pointer may be used after 'realloc'
> [-Werror=use-after-free]
>  7609 | b = realloc (state->buffer, more -= 1024);
>   | ^
> gzip.c.c:7605:15: note: call to 'realloc' here
>  7605 | char *b = realloc (state->buffer, more);
>   |   ^
> cc1: all warnings being treated as errors
> 
> gcc-master does not seem to reproduce the failure. I did not test gcc-13.

Thank you for your last comment, it was really helpful.
This bug is still present for me, which makes me think that gcc-master is a
different branch than gcc-12. I grabbed the latest gcc tarball to test it using
the following commands:

git clone --depth 1 git://gcc.gnu.org/git/gcc.git gcc-dir.tmp
git --git-dir=gcc-dir.tmp/.git fetch --depth 1 origin
0bfba6442264af83382c26f60286bd33c901178a
git --git-dir=gcc-dir.tmp/.git archive --prefix=gcc-12.3.1-20230513/
0bfba6442264af83382c26f60286bd33c901178a | xz -3 > gcc-12.3.1-20230513.tar.xz

then built gcc (gcc -v):
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /sources/gcc-12.3.1-20230513/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --enable-bootstrap --enable-languages=c,c++,lto
--enable-multilib --enable-install-libiberty --enable-checking=release
--enable-default-pie --enable-default-ssp --with-abi=m64 --with-arch=x86-64
--with-arch_32=x86-64 --with-build-config=bootstrap-lto
--with-multilib-list=m64,m32 --with-fpmath=sse --with-linker-hash-style=gnu
--with-system-zlib --with-tune=generic --with-zstd --without-isl
--disable-libitm --disable-libquadmath --disable-libsanitizer --disable-libvtv
--disable-nls --disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.3.1 20230513 (Netux R1) (GCC)

and finally ran the elfutils build test, using the same environment, parameters
as before.

See attachment for the preprocessed file.

The invocation of gcc that triggered the bug was:
gcc -D_GNU_SOURCE -DHAVE_CONFIG_H -DLOCALEDIR='"/usr/share/locale"' -I. -I.. 
-I. -I. -I../lib -I.. -I. -I./../libelf -I./../libebl -I./../libdw
-I./../libdwelf -I./../debuginfod  -std=gnu99 -Wall -Wshadow -Wformat=2
-Wold-style-definition -Wstrict-prototypes -Wtrampolines -Wlogical-op
-Wduplicated-cond -Wnull-dereference -Wimplicit-fallthrough=5
-Wuse-after-free=3 -Werror -Wunused -Wextra -Wstack-usage=262144  
-D_FORTIFY_SOURCE=3 -Os -mtune=generic -MT gzip.o -MD -MP -MF .deps/gzip.Tpo -c
-o gzip.o gzip.c

[Bug middle-end/104069] Wuse-after-free=2 -O0 false positive "may be used"

[mkaracsony81 at gmail dot com via Gcc-bugs]

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

--- Comment #33 from Miklos Karacsony  ---
Created attachment 55073
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55073=edit
gcc 12.3.1 preprocessed source file

[Bug tree-optimization/94911] Failure to optimize comparisons of VLA sizes

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-13
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #4 from Andrew Pinski  ---
  # RANGE [irange] int [1, +INF] NONZERO 0x7fff
  intD.7 n_11(D) = nD.4385;
  sizetype _2;
  _BoolD.4372 _16;

;;   basic block 2, loop depth 0, count 1073741824 (estimated locally), maybe
hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred:   ENTRY [always]  count:1073741824 (estimated locally)
(FALLTHRU,EXECUTABLE)
  # RANGE [irange] sizetype [1, 2147483647] NONZERO 0x7fff
  _1 = (sizetype) n_11(D);
  # RANGE [irange] sizetype [4, 8589934588] NONZERO 0x1fffc
  _2 = _1 * 4;
  _16 = _2 > 3;


We have the information to do the folding in optimize but not earlier ...

Re: [PATCH] libstdc++: use __bool_constant instead of integral_constant

[Ken Matsui via Gcc-patches]

It appears that GCC 13 has been released, but I am wondering if there
are any issues preventing this patch from being merged yet. Can you
provide any information on this?

On Sat, Apr 8, 2023 at 2:08 PM Ken Matsui  wrote:
>
> I see. Thank you!
>
> On Sat, Apr 8, 2023 at 12:52 AM Jonathan Wakely  wrote:
> >
> > This looks good, thanks, but we're too close to the gcc 13 release now, and 
> > this isn't fixing any bugs. I'll push it after the release.
> >
> >
> > On Thu, 23 Mar 2023, 11:07 Ken Matsui via Libstdc++, 
> >  wrote:
> >>
> >> In the type_traits header, both integral_constant and __bool_constant
> >> are used. This patch unifies those usages into __bool_constant.
> >>
> >> libstdc++-v3/ChangeLog:
> >>
> >> * include/std/type_traits: Use __bool_constant instead of
> >> integral_constant.
> >>
> >> Signed-off-by: Ken Matsui 
> >> ---
> >>  libstdc++-v3/include/std/type_traits | 32 ++--
> >>  1 file changed, 16 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/libstdc++-v3/include/std/type_traits 
> >> b/libstdc++-v3/include/std/type_traits
> >> index 2bd607a8b8f..bc6982f9e64 100644
> >> --- a/libstdc++-v3/include/std/type_traits
> >> +++ b/libstdc++-v3/include/std/type_traits
> >> @@ -578,19 +578,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >>/// is_enum
> >>template
> >>  struct is_enum
> >> -: public integral_constant
> >> +: public __bool_constant<__is_enum(_Tp)>
> >>  { };
> >>
> >>/// is_union
> >>template
> >>  struct is_union
> >> -: public integral_constant
> >> +: public __bool_constant<__is_union(_Tp)>
> >>  { };
> >>
> >>/// is_class
> >>template
> >>  struct is_class
> >> -: public integral_constant
> >> +: public __bool_constant<__is_class(_Tp)>
> >>  { };
> >>
> >>/// is_function
> >> @@ -784,7 +784,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >>/// is_trivial
> >>template
> >>  struct is_trivial
> >> -: public integral_constant
> >> +: public __bool_constant<__is_trivial(_Tp)>
> >>  {
> >>
> >> static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
> >> "template argument must be a complete class or an unbounded 
> >> array");
> >> @@ -793,7 +793,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >>/// is_trivially_copyable
> >>template
> >>  struct is_trivially_copyable
> >> -: public integral_constant
> >> +: public __bool_constant<__is_trivially_copyable(_Tp)>
> >>  {
> >>
> >> static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
> >> "template argument must be a complete class or an unbounded 
> >> array");
> >> @@ -802,7 +802,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >>/// is_standard_layout
> >>template
> >>  struct is_standard_layout
> >> -: public integral_constant
> >> +: public __bool_constant<__is_standard_layout(_Tp)>
> >>  {
> >>
> >> static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
> >> "template argument must be a complete class or an unbounded 
> >> array");
> >> @@ -817,7 +817,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >>  struct
> >>  _GLIBCXX20_DEPRECATED_SUGGEST("is_standard_layout && is_trivial")
> >>  is_pod
> >> -: public integral_constant
> >> +: public __bool_constant<__is_pod(_Tp)>
> >>  {
> >>
> >> static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
> >> "template argument must be a complete class or an unbounded 
> >> array");
> >> @@ -831,7 +831,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >>  struct
> >>  _GLIBCXX17_DEPRECATED
> >>  is_literal_type
> >> -: public integral_constant
> >> +: public __bool_constant<__is_literal_type(_Tp)>
> >>  {
> >>
> >> static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
> >> "template argument must be a complete class or an unbounded 
> >> array");
> >> @@ -840,13 +840,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >>/// is_empty
> >>template
> >>  struct is_empty
> >> -: public integral_constant
> >> +: public __bool_constant<__is_empty(_Tp)>
> >>  { };
> >>
> >>/// is_polymorphic
> >>template
> >>  struct is_polymorphic
> >> -: public integral_constant
> >> +: public __bool_constant<__is_polymorphic(_Tp)>
> >>  { };
> >>
> >>  #if __cplusplus >= 201402L
> >> @@ -855,14 +855,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >>/// @since C++14
> >>template
> >>  struct is_final
> >> -: public integral_constant
> >> +: public __bool_constant<__is_final(_Tp)>
> >>  { };
> >>  #endif
> >>
> >>/// is_abstract
> >>template
> >>  struct is_abstract
> >> -: public integral_constant
> >> +: public __bool_constant<__is_abstract(_Tp)>
> >>  { };
> >>
> >>/// @cond undocumented
> >> @@ -873,7 +873,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >>
> >>template
> >>  struct 

[Bug c++/106943] GCC building clang/llvm with LTO flags causes ICE in clang

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

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

--- Comment #29 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #28)
> (In reply to Alexander Monakov from comment #21)
> > (In reply to Xi Ruoyao from comment #18)
> > > Maybe.  Should we send a patch?
> > 
> > Yes, if we have a volunteer.
> 
> I'm creating it, but from the description of the LLVM issue 24952:
> 
> "To put it simply, operator delete for class User inspects memory of the
> object after the end of its lifetime. This shows as a use-after-dtor error
> when running under MemorySanitizer."
> 
> So it seems technically we'll need -fno-lifetime-dse here?  Our docs say
> -flifetime-dse only "preserve stores before the constructor starts" but
  ^^  I mean, -flifetime-dse=1
> "still treat the object as dead after the destructor".

[Bug c++/106943] GCC building clang/llvm with LTO flags causes ICE in clang

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

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

--- Comment #28 from Xi Ruoyao  ---
(In reply to Alexander Monakov from comment #21)
> (In reply to Xi Ruoyao from comment #18)
> > Maybe.  Should we send a patch?
> 
> Yes, if we have a volunteer.

I'm creating it, but from the description of the LLVM issue 24952:

"To put it simply, operator delete for class User inspects memory of the object
after the end of its lifetime. This shows as a use-after-dtor error when
running under MemorySanitizer."

So it seems technically we'll need -fno-lifetime-dse here?  Our docs say
-flifetime-dse only "preserve stores before the constructor starts" but "still
treat the object as dead after the destructor".

Re: [PATCH] RISC-V: Optimize vsetvl AVL for VLS VLMAX auto-vectorization

[Kito Cheng via Gcc-patches]

Hmmm here is alternative approach for this:

diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index b8dc333f54e1..c88056024e7d 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -50,6 +50,21 @@ using namespace riscv_vector;

namespace riscv_vector {

+/* Return true if vlmax is constant value instead and can be used
+   in vsetivli.  */
+static bool
+const_vlmax_p (machine_mode mode)
+{
+  poly_uint64 nunits = GET_MODE_NUNITS (mode);
+
+  /* Only allowed in VLS-VLMAX mode.  */
+  if (!nunits.is_constant ())
+return false;
+
+  /* vsetivli can only hold 0~31.  */
+  return (IN_RANGE (nunits.to_constant (), 0, 31));
+}
+
template  class insn_expander
{
public:
@@ -101,15 +116,26 @@ public:

  void set_len_and_policy (rtx len, bool force_vlmax = false)
{
-  bool vlmax_p = force_vlmax;
+  bool vlmax_p = force_vlmax || !len;
  gcc_assert (has_dest);

-  if (!len)
+  if (vlmax_p)
   {
- vlmax_p = true;
- len = gen_reg_rtx (Pmode);
- emit_vlmax_vsetvl (dest_mode, len);
-   }
+ if (const_vlmax_p (dest_mode))
+   {
+ /* Optimize VLS-VLMAX code gen, we can use vsetivli instead of
+vsetvli to obtain the value of vlmax.  */
+ poly_uint64 nunits = GET_MODE_NUNITS (dest_mode);
+ len = gen_int_mode (nunits, Pmode);
+ /* It has become NONVLMAX now. */
+ vlmax_p = false;
+   }
+ else if (!len)
+   {
+ len = gen_reg_rtx (Pmode);
+ emit_vlmax_vsetvl (dest_mode, len);
+   }
+}

  add_input_operand (len, Pmode);

-- 



On Sat, May 13, 2023 at 10:09 AM  wrote:
>
> From: Juzhe-Zhong 
>
> This patch is optimizing the AVL for VLS auto-vectorzation.
>
> Consider such case:
>
> typedef int8_t vnx2qi __attribute__ ((vector_size (2)));
>
> __attribute__ ((noipa)) void
> f_vnx2qi (int8_t a, int8_t b, int8_t *out)
> {
>   vnx2qi v = {a, b};
>   *(vnx2qi *) out = v;
> }
>
> Before this patch:
>
> f_vnx2qi:
> vsetvli a5,zero,e8,mf8,ta,ma
> vmv.v.x v1,a0
> vslide1down.vx  v1,v1,a1
> vse8.v  v1,0(a2)
> ret
>
> After this patch:
>
> f_vnx2qi:
> vsetivlizero,2,e8,mf8,ta,ma
> vmv.v.x v1,a0
> vslide1down.vx  v1,v1,a1
> vse8.v  v1,0(a2)
> ret
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-protos.h (emit_vlmax_vsetvl): Change argument 
> type.
> * config/riscv/riscv-v.cc (emit_vlmax_vsetvl): Optimize AVL for vlmax 
> VLS.
> (emit_vlmax_reg_op): Ditto.
> * config/riscv/vector.md: Adapt argument.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/vf_avl-1.c: New test.
>
> ---
>  gcc/config/riscv/riscv-protos.h   |  2 +-
>  gcc/config/riscv/riscv-v.cc   | 25 +++
>  gcc/config/riscv/vector.md|  4 +--
>  .../gcc.target/riscv/rvv/base/vf_avl-1.c  | 15 +++
>  4 files changed, 38 insertions(+), 8 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vf_avl-1.c
>
> diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
> index bc71f9cbbba..90934d43430 100644
> --- a/gcc/config/riscv/riscv-protos.h
> +++ b/gcc/config/riscv/riscv-protos.h
> @@ -164,7 +164,7 @@ bool check_builtin_call (location_t, vec, 
> unsigned int,
>tree, unsigned int, tree *);
>  bool const_vec_all_same_in_range_p (rtx, HOST_WIDE_INT, HOST_WIDE_INT);
>  bool legitimize_move (rtx, rtx, machine_mode);
> -void emit_vlmax_vsetvl (machine_mode, rtx);
> +void emit_vlmax_vsetvl (machine_mode, rtx *);
>  void emit_hard_vlmax_vsetvl (machine_mode, rtx);
>  void emit_vlmax_op (unsigned, rtx, rtx, machine_mode);
>  void emit_vlmax_reg_op (unsigned, rtx, rtx, rtx, machine_mode);
> diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
> index d844c305320..382cc4b6311 100644
> --- a/gcc/config/riscv/riscv-v.cc
> +++ b/gcc/config/riscv/riscv-v.cc
> @@ -120,7 +120,9 @@ public:
>{
> vlmax_p = true;
> len = gen_reg_rtx (Pmode);
> -   emit_vlmax_vsetvl (dest_mode, len);
> +   emit_vlmax_vsetvl (dest_mode, );
> +   if (CONST_INT_P (len))
> + vlmax_p = false;
>}
>
>  add_input_operand (len, Pmode);
> @@ -183,16 +185,29 @@ emit_hard_vlmax_vsetvl (machine_mode vmode, rtx vl)
>  }
>
>  void
> -emit_vlmax_vsetvl (machine_mode vmode, rtx vl)
> +emit_vlmax_vsetvl (machine_mode vmode, rtx *vl)
>  {
>unsigned int sew = get_sew (vmode);
>enum vlmul_type vlmul = get_vlmul (vmode);
>unsigned int ratio = calculate_ratio (sew, vlmul);
>
> +  /* For VLS VLMAX auto-vectorization, we change
> + VL into const_int value of VF so that we
> + will emit "vsetivli zero, CONST_INT" instead of
> + "vsetvli a5, zero".
> +
> + TODO: Support VLS min-length in the future.  */
> +  

[Bug tree-optimization/109834] [14 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (ssa_name) in gimple_simplify_191 when building harfbuzz

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
Fixed.

[Bug tree-optimization/109834] [14 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (ssa_name) in gimple_simplify_191 when building harfbuzz

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

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

--- Comment #12 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:99488a6048745a7b999c22f46e5814d02ebf88d9

commit r14-804-g99488a6048745a7b999c22f46e5814d02ebf88d9
Author: Andrew Pinski 
Date:   Fri May 12 16:33:44 2023 -0700

MATCH: Fix PR 109834, ICE with popcount combined with bswap

After r14-673-gc0dd80e4c4c3, there was a check in the match
patterns which was checking the type is unsigned but
instead of using the type, the patch used the expression.
This adds the needed TREE_TYPE so get the correct answer and don't ICE.

Committed as obvious after a bootstrap/test on x86_64-linux-gnu.

PR tree-optimization/109834

gcc/ChangeLog:

* match.pd (popcount(bswap(x))->popcount(x)): Fix up unsigned type
checking.
(popcount(rotate(x,y))->popcount(x)): Likewise.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/pr109834-1.c: New test.
* gcc.dg/tree-ssa/pr109834-1.c: New test.

[PATCH] MATCH: Fix PR 109834, ICE with popcount combined with bswap

[Andrew Pinski via Gcc-patches]

After r14-673-gc0dd80e4c4c3, there was a check in the match
patterns which was checking the type is unsigned but
instead of using the type, the patch used the expression.
This adds the needed TREE_TYPE so get the correct answer and don't ICE.

Committed as obvious after a bootstrap/test on x86_64-linux-gnu.

PR tree-optimizion/109834

gcc/ChangeLog:

* match.pd (popcount(bswap(x))->popcount(x)): Fix up unsigned type 
checking.
(popcount(rotate(x,y))->popcount(x)): Likewise.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/pr109834-1.c: New test.
* gcc.dg/tree-ssa/pr109834-1.c: New test.
---
 gcc/match.pd |  4 ++--
 gcc/testsuite/gcc.c-torture/compile/pr109834-1.c |  4 
 gcc/testsuite/gcc.dg/tree-ssa/pr109834-1.c   | 11 +++
 3 files changed, 17 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr109834-1.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr109834-1.c

diff --git a/gcc/match.pd b/gcc/match.pd
index 60b01643be5..3089fe309fd 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -7867,7 +7867,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   && INTEGRAL_TYPE_P (TREE_TYPE (@1)))
(with { unsigned int prec0 = TYPE_PRECISION (TREE_TYPE (@0));
unsigned int prec1 = TYPE_PRECISION (TREE_TYPE (@1)); }
- (if (prec0 == prec1 || (prec0 > prec1 && TYPE_UNSIGNED (@1)))
+ (if (prec0 == prec1 || (prec0 > prec1 && TYPE_UNSIGNED (TREE_TYPE 
(@1
(popcount @2)))
 
 /* popcount(rotate(X Y)) is popcount(X).  */
@@ -7880,7 +7880,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   && (GIMPLE || !TREE_SIDE_EFFECTS (@3)))
(with { unsigned int prec0 = TYPE_PRECISION (TREE_TYPE (@0));
unsigned int prec1 = TYPE_PRECISION (TREE_TYPE (@1)); }
- (if (prec0 == prec1 || (prec0 > prec1 && TYPE_UNSIGNED (@1)))
+ (if (prec0 == prec1 || (prec0 > prec1 && TYPE_UNSIGNED (TREE_TYPE 
(@1
(popcount @2)))
 
 /* Canonicalize POPCOUNT(x)&1 as PARITY(X).  */
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr109834-1.c 
b/gcc/testsuite/gcc.c-torture/compile/pr109834-1.c
new file mode 100644
index 000..e6c015249b2
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr109834-1.c
@@ -0,0 +1,4 @@
+int f (char v)
+{
+  return __builtin_popcount((int)__builtin_bswap16(v));
+}
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr109834-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr109834-1.c
new file mode 100644
index 000..f2af18b0cd0
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr109834-1.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -fdump-tree-optimized" } */
+
+int f (char v)
+{
+  return __builtin_popcount((int)__builtin_bswap16(v));
+}
+
+/* We should be able to remove the bswap here as it does not matter
+   for the popcount.  */
+/* { dg-final { scan-tree-dump-not "bswap" "optimized"} } */
-- 
2.39.1

Re: [PATCH] i386: Allow -mlarge-data-threshold with -mcmodel=large

[Fangrui Song via Gcc-patches]

On Wed, May 10, 2023 at 2:58 AM Uros Bizjak  wrote:
>
> On Fri, Apr 28, 2023 at 2:47 AM Fangrui Song  wrote:
> >
> > When using -mcmodel=medium, large data is placed into .l* sections.  GNU ld
> > places .l* sections into separate output sections.  If small and medium
> > code model object files are mixed, the .l* sections won't cause
> > relocation overflow pressure on sections in -mcmodel=small object files.
> >
> > However, when using -mcmodel=large, -mlarge-data-threshold doesn't apply.  
> > This
> > means that the .rodata/.data/.bss sections may cause relocation overflow
> > pressure on sections in -mcmodel=small object files.
> >
> > This patch allows -mcmodel=large to generate .l* sections.
>
> The x86_64 psABI does not specify how -mlarge-threshold is handled
> with -mcmodel=large and it also doesn't mention that -mcmodel=large
> inherits handling from -mcmodel=medium. The ABI does say that the
> -mcmodel=large is strictly only required if the text of a single
> function becomes larger than what the medium model allows.
>
> OTOH, the ABI also doesn't prohibit large sections with -mcmodel=large
> and IMO, the introduction of -mlarge-threshold with -mcmodel=large
> does not create an ABI change.
>
> I think the best way is to first discuss the issue with the x86_64
> psABI group, to clarify how -mlarge-threshold and large data is
> handled under a large code model.
>
> Uros.

Thank you for the suggestion. I started
https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU ("Large data
sections for the large code model")
and created https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/42/
to clarify large data sections usage.

In the psABI, "Table 4.4: Additional Special Sections for the Large
Code Model"  lists the large data sections.
Perhaps it should be "Table 4.4: Additional Special Sections for the
Medium and Large Code Models".

> >
> > Signed-off-by: Fangrui Song 
> > ---
> >  gcc/config/i386/i386.cc| 15 +--
> >  gcc/config/i386/i386.opt   |  2 +-
> >  gcc/doc/invoke.texi|  7 ---
> >  gcc/testsuite/gcc.target/i386/large-data.c | 13 +
> >  4 files changed, 27 insertions(+), 10 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/large-data.c
> >
> > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> > index a3db55642e3..c68c66a5567 100644
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -637,7 +637,8 @@ ix86_can_inline_p (tree caller, tree callee)
> >  static bool
> >  ix86_in_large_data_p (tree exp)
> >  {
> > -  if (ix86_cmodel != CM_MEDIUM && ix86_cmodel != CM_MEDIUM_PIC)
> > +  if (ix86_cmodel != CM_MEDIUM && ix86_cmodel != CM_MEDIUM_PIC &&
> > +  ix86_cmodel != CM_LARGE && ix86_cmodel != CM_LARGE_PIC)
> >  return false;
> >
> >if (exp == NULL_TREE)
> > @@ -848,8 +849,9 @@ x86_elf_aligned_decl_common (FILE *file, tree decl,
> > const char *name, unsigned HOST_WIDE_INT size,
> > unsigned align)
> >  {
> > -  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
> > -  && size > (unsigned int)ix86_section_threshold)
> > +  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC ||
> > +  ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC) &&
> > + size > (unsigned int)ix86_section_threshold)
> >  {
> >switch_to_section (get_named_section (decl, ".lbss", 0));
> >fputs (LARGECOMM_SECTION_ASM_OP, file);
> > @@ -869,9 +871,10 @@ void
> >  x86_output_aligned_bss (FILE *file, tree decl, const char *name,
> > unsigned HOST_WIDE_INT size, unsigned align)
> >  {
> > -  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
> > -  && size > (unsigned int)ix86_section_threshold)
> > -switch_to_section (get_named_section (decl, ".lbss", 0));
> > +  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC ||
> > +   ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC) &&
> > +  size > (unsigned int)ix86_section_threshold)
> > +switch_to_section(get_named_section(decl, ".lbss", 0));
> >else
> >  switch_to_section (bss_section);
> >ASM_OUTPUT_ALIGN (file, floor_log2 (align / BITS_PER_UNIT));
> > diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
> > index d74f6b1f8fc..de8e722cd62 100644
> > --- a/gcc/config/i386/i386.opt
> > +++ b/gcc/config/i386/i386.opt
> > @@ -282,7 +282,7 @@ Branches are this expensive (arbitrary units).
> >
> >  mlarge-data-threshold=
> >  Target RejectNegative Joined UInteger Var(ix86_section_threshold) 
> > Init(DEFAULT_LARGE_SECTION_THRESHOLD)
> > --mlarge-data-threshold=Data greater than given threshold 
> > will go into .ldata section in x86-64 medium model.
> > +-mlarge-data-threshold=Data greater than given threshold 
> > will go into a large data section in x86-64 medium and large code models.
> >
> >  mcmodel=
> >  Target 

[Bug analyzer/109839] New: -Wanalyzer-fd-leak false positive with routine dup2

[eggert at cs dot ucla.edu via Gcc-bugs]

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

Bug ID: 109839
   Summary: -Wanalyzer-fd-leak false positive with routine dup2
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 55072
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55072=edit
test program illustrating false positive with -Wanalyzer-fd-leak

I ran into this problem when compiling GNU Emacs with GCC 13.1.1 20230426 (Red
Hat 13.1.1-1) on x86-64. Compile the attached program (which is a stripped-down
version) with:

gcc -fanalyzer dup2-analyzer.c

The output is as follows. This is a false alarm, as the dup2 is a routine I/O
redirection and should not be considered to be a leak. In typical use, it's
better to not consider dup2's return value to be a leak.

dup2-analyzer.c: In function ‘main’:
dup2-analyzer.c:6:6: warning: leak of file descriptor ‘dup2(1, 2)’ [CWE-775]
[-Wanalyzer-fd-leak]
6 |   if (dup2 (STDOUT_FILENO, STDERR_FILENO) < 0)
  |  ^
  ‘main’: events 1-2
|
|6 |   if (dup2 (STDOUT_FILENO, STDERR_FILENO) < 0)
|  |  ~^~~
|  |  ||
|  |  |(1) opened here
|  |  (2) ‘dup2(1, 2)’ leaks here; was opened at (1)
|

[PATCH] RISC-V: Optimize vsetvl AVL for VLS VLMAX auto-vectorization

[juzhe . zhong]

From: Juzhe-Zhong 

This patch is optimizing the AVL for VLS auto-vectorzation.

Consider such case:

typedef int8_t vnx2qi __attribute__ ((vector_size (2)));

__attribute__ ((noipa)) void
f_vnx2qi (int8_t a, int8_t b, int8_t *out)
{
  vnx2qi v = {a, b};
  *(vnx2qi *) out = v;
}

Before this patch:

f_vnx2qi:
vsetvli a5,zero,e8,mf8,ta,ma
vmv.v.x v1,a0
vslide1down.vx  v1,v1,a1
vse8.v  v1,0(a2)
ret

After this patch:

f_vnx2qi:
vsetivlizero,2,e8,mf8,ta,ma
vmv.v.x v1,a0
vslide1down.vx  v1,v1,a1
vse8.v  v1,0(a2)
ret

gcc/ChangeLog:

* config/riscv/riscv-protos.h (emit_vlmax_vsetvl): Change argument type.
* config/riscv/riscv-v.cc (emit_vlmax_vsetvl): Optimize AVL for vlmax 
VLS.
(emit_vlmax_reg_op): Ditto.
* config/riscv/vector.md: Adapt argument.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/vf_avl-1.c: New test.

---
 gcc/config/riscv/riscv-protos.h   |  2 +-
 gcc/config/riscv/riscv-v.cc   | 25 +++
 gcc/config/riscv/vector.md|  4 +--
 .../gcc.target/riscv/rvv/base/vf_avl-1.c  | 15 +++
 4 files changed, 38 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vf_avl-1.c

diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index bc71f9cbbba..90934d43430 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -164,7 +164,7 @@ bool check_builtin_call (location_t, vec, 
unsigned int,
   tree, unsigned int, tree *);
 bool const_vec_all_same_in_range_p (rtx, HOST_WIDE_INT, HOST_WIDE_INT);
 bool legitimize_move (rtx, rtx, machine_mode);
-void emit_vlmax_vsetvl (machine_mode, rtx);
+void emit_vlmax_vsetvl (machine_mode, rtx *);
 void emit_hard_vlmax_vsetvl (machine_mode, rtx);
 void emit_vlmax_op (unsigned, rtx, rtx, machine_mode);
 void emit_vlmax_reg_op (unsigned, rtx, rtx, rtx, machine_mode);
diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index d844c305320..382cc4b6311 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -120,7 +120,9 @@ public:
   {
vlmax_p = true;
len = gen_reg_rtx (Pmode);
-   emit_vlmax_vsetvl (dest_mode, len);
+   emit_vlmax_vsetvl (dest_mode, );
+   if (CONST_INT_P (len))
+ vlmax_p = false;
   }
 
 add_input_operand (len, Pmode);
@@ -183,16 +185,29 @@ emit_hard_vlmax_vsetvl (machine_mode vmode, rtx vl)
 }
 
 void
-emit_vlmax_vsetvl (machine_mode vmode, rtx vl)
+emit_vlmax_vsetvl (machine_mode vmode, rtx *vl)
 {
   unsigned int sew = get_sew (vmode);
   enum vlmul_type vlmul = get_vlmul (vmode);
   unsigned int ratio = calculate_ratio (sew, vlmul);
 
+  /* For VLS VLMAX auto-vectorization, we change
+ VL into const_int value of VF so that we
+ will emit "vsetivli zero, CONST_INT" instead of
+ "vsetvli a5, zero".
+
+ TODO: Support VLS min-length in the future.  */
+  poly_uint64 nunits = GET_MODE_NUNITS (vmode);
+  if (nunits.is_constant () && IN_RANGE (nunits.to_constant (), 0, 31))
+{
+  *vl = gen_int_mode (nunits, Pmode);
+  return;
+}
+
   if (!optimize)
-emit_hard_vlmax_vsetvl (vmode, vl);
+emit_hard_vlmax_vsetvl (vmode, *vl);
   else
-emit_insn (gen_vlmax_avl (Pmode, vl, gen_int_mode (ratio, Pmode)));
+emit_insn (gen_vlmax_avl (Pmode, *vl, gen_int_mode (ratio, Pmode)));
 }
 
 /* Calculate SEW/LMUL ratio.  */
@@ -323,7 +338,7 @@ emit_vlmax_reg_op (unsigned icode, rtx dest, rtx src, rtx 
len,
   machine_mode mask_mode)
 {
   emit_pred_op (icode, NULL_RTX, dest, src, len, mask_mode,
-   /* Force VLMAX */ true);
+   /* Force VLMAX */ CONST_INT_P (len) ? false : true);
 }
 
 void
diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index 328fce8d632..b02ecf92c00 100644
--- a/gcc/config/riscv/vector.md
+++ b/gcc/config/riscv/vector.md
@@ -720,7 +720,7 @@
   emit_insn (gen_rtx_SET (operands[0], operands[1]));
   else
 {
-  riscv_vector::emit_vlmax_vsetvl (mode, operands[2]);
+  riscv_vector::emit_vlmax_vsetvl (mode, [2]);
   riscv_vector::emit_vlmax_reg_op (code_for_pred_mov (mode),
   operands[0], operands[1], operands[2],
   mode);
@@ -741,7 +741,7 @@
   emit_insn (gen_rtx_SET (operands[0], operands[1]));
   else
 {
-  riscv_vector::emit_vlmax_vsetvl (mode, operands[2]);
+  riscv_vector::emit_vlmax_vsetvl (mode, [2]);
   riscv_vector::emit_vlmax_reg_op (code_for_pred_mov (mode),
   operands[0], operands[1], operands[2],
   mode);
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/vf_avl-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/vf_avl-1.c
new file mode 100644
index 

[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP

[janezz55 at gmail dot com via Gcc-bugs]

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

--- Comment #24 from Janez Zemva  ---
I'll go libm shopping them, I know just the thing to try out first:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/libm/

Re: [committed] Convert xstormy16 to LRA

[Hans-Peter Nilsson via Gcc-patches]

> From: Hans-Peter Nilsson 
> Date: Sat, 13 May 2023 02:56:39 +0200
> 
> > From: "Roger Sayle" 
> > Date: Fri, 12 May 2023 15:04:03 +0100
> 
> > Hi H-P,
> > This patch should now already be on trunk:
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d8a6945c6ea22efa4d5e42fe1922d2
> > b27953c8cd
> > Many thanks to Jeff for the review/approval.
> > There have been no reported adverse effects so far.
> > Please let me/us know if this has helped CRIS.
> 
> TL;DR:
> It sure helped for the big offender; arith-rand-ll with LRA
> is now 1.3% faster!  Not everything is rosy though.

Coremark regressed slightly for LRA, cris-elf, -O2
-march=v10; with/without the patch: 100.0014% by speed,
100.037% by size.

brgds, H-P

Re: [committed] Convert xstormy16 to LRA

[Hans-Peter Nilsson via Gcc-patches]

> From: "Roger Sayle" 
> Date: Fri, 12 May 2023 15:04:03 +0100

> Hi H-P,
> This patch should now already be on trunk:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d8a6945c6ea22efa4d5e42fe1922d2
> b27953c8cd
> Many thanks to Jeff for the review/approval.
> There have been no reported adverse effects so far.
> Please let me/us know if this has helped CRIS.

TL;DR:
It sure helped for the big offender; arith-rand-ll with LRA
is now 1.3% faster!  Not everything is rosy though.

It's not a complete win for CRIS with LRA, as other of my
mini-regression tests (like, a trivial loop with 0<=i<=10
fprintf (f, "%s: %d\n", "Hello, world", i); with newlib),
where it got 0.04% larger.  On average though, 0.5% smaller.
Actually, it's more accurate to state it in terms of the
code that changed: newlib's _vfprintf_r improved slightly
performance-wise on some paths (1 cycle per call), but
regressed on others (7 cycles per call).  It got 0.2%
bigger.  Libgcc's __moddi3 regressed slightly (1 cycle per
11 calls) but stayed the same size.  The main function in
arith-rand-ll (where I guess all small functions got
inlined) improved 3% by size, performance as above.

Those clobbers must have helped reload, because with reload
there was a 0.15% performance regression for arith-rand-ll
(and 0.2% by size because main got 1.6% larger) with this
patch.  But size was smaller or equal for all other tests
using reload with this patch, if only by 0.04% on average.
 Or in other numbers: _vfprintf_r got 4 cycles faster per
call on some paths and 2 on others.  It got 0.05% bigger.  A
similar function, __vfiprintf_r, shrank by 0.5%.  Go figure.
For all but arith-rand-ll, this patch was a wash for reload.
 (Yes: the case with reload is now artificial; for that, I
was using master before Jeff's commit and added my own
commits since then, to keep track of my fight against LRA
regressions; the current score is that code is still 0.34%
slower and 0.17% larger with this applied just for LRA.)

Can we ask Vladimir for a statement; perhaps LRA could just
have handled those clobbers better (referring to the commit)?

brgds, H-P

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Gabriel Ravier  writes:

> ...You're joking, right ? You can't possibly be seriously arguing
> this, you have to be kidding... right ?

No, I'm not.  The meaning of a variable declaration with only a storage
class specifier is extremely clear: the type of the variable is `int'.
There's absolutely nothing ambiguous about it whatsoever:

  register i;
  extern   limit, *k, do_some_computation ();

  for (i = 0; i < limit; ++i)
k[i] = do_some_computation (i);

Please try to prove me wrong.

Re: Re: [PATCH V4] RISC-V: Using merge approach to optimize repeating sequence in vec_init

[钟居哲]

Address comments.
V5 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618398.html 

Thanks.


juzhe.zh...@rivai.ai
 
From: Kito Cheng
Date: 2023-05-13 00:16
To: juzhe.zhong
CC: gcc-patches; palmer; jeffreyalaw
Subject: Re: [PATCH V4] RISC-V: Using merge approach to optimize repeating 
sequence in vec_init
> +/* Get the mask for merge approach.
> +
> + Consider such following case:
> +   {a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b}
> + To merge "a", the mask should be 1010
> + To merge "b", the mask should be 0101
> +*/
> +rtx
> +rvv_builder::get_merge_mask_bitfield (unsigned int index) const
> +{
> +  uint64_t base_mask = (1ULL << index);
> +  uint64_t mask = 0;
> +  for (unsigned int i = 0; i < (64 / npatterns ()); i++)
 
What the magic 64 means?
...
 
> +static void
> +expand_vector_init_merge_repeating_sequence (rtx target,
> +const rvv_builder )
> +{
> +  machine_mode mask_mode;
> +  gcc_assert (get_mask_mode (builder.mode ()).exists (_mode));
> +
> +  machine_mode dup_mode = builder.mode ();
> +  if (known_gt (GET_MODE_SIZE (dup_mode), BYTES_PER_RISCV_VECTOR))
> +{
> +  poly_uint64 nunits
> +   = exact_div (BYTES_PER_RISCV_VECTOR, builder.inner_units ());
> +  gcc_assert (
> +   get_vector_mode (builder.inner_int_mode (), nunits).exists 
> (_mode));
 
gcc_assert will removed at release mode, so it's not you want I guess?
 
> +}
> +  else
> +{
> +  if (FLOAT_MODE_P (dup_mode))
> +   gcc_assert (get_vector_mode (builder.inner_int_mode (),
> +GET_MODE_NUNITS (dup_mode))
> + .exists (_mode));
 
Same issue
 
> +}
> +
> +  machine_mode dup_mask_mode;
> +  gcc_assert (get_mask_mode (dup_mode).exists (_mask_mode));
 
Same issue
 

[PATCH V5] RISC-V: Using merge approach to optimize repeating sequence in vec_init

[juzhe . zhong]

From: Juzhe-Zhong 

1. Remove magic number of V4
2. Remove unnecessary gcc_assert

Consider this following case:
typedef int64_t vnx32di __attribute__ ((vector_size (256)));


__attribute__ ((noipa)) void
f_vnx32di (int64_t a, int64_t b, int64_t *out)
{
  vnx32di v
= {a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b, 
a, b, a, b, a, b, a, b};
  *(vnx32di *) out = v;
}

Since we dont't have SEW = 128 in vec_duplicate, we can't combine ab into SEW = 
128 element and then
broadcast this big element.

This patch is optimize the case as above.

-march=rv64gcv_zvl256b --param riscv-autovec-preference=fixed-vlmax

Before this patch:

..
vslide1down.vx (x31 times)
..

After this patch:
li  a5,-1431654400
addia5,a5,-1365
li  a3,-1431654400
addia3,a3,-1366
sllia5,a5,32
add a5,a5,a3
vsetvli a4,zero,e64,m8,ta,ma
vmv.v.x v8,a0
vmv.s.x v0,a5
vmerge.vxm  v8,v8,a1,v0
vs8r.v  v8,0(a2)
ret

gcc/ChangeLog:

* config/riscv/riscv-v.cc 
(rvv_builder::can_duplicate_repeating_sequence_p): New function.
(rvv_builder::get_merged_repeating_sequence): Ditto.
(rvv_builder::repeating_sequence_use_merge_profitable_p): Ditto.
(rvv_builder::get_merge_mask_bitfield): Ditto.
(emit_scalar_move_op): Ditto.
(emit_merge_op): Ditto.
(expand_vector_init_merge_repeating_sequence): Ditto.
(expand_vec_init): Add merge approach for reapeating sequence.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/vls-vlmax/repeat-10.c: New test.
* gcc.target/riscv/rvv/autovec/vls-vlmax/repeat-11.c: New test.
* gcc.target/riscv/rvv/autovec/vls-vlmax/repeat-7.c: New test.
* gcc.target/riscv/rvv/autovec/vls-vlmax/repeat-8.c: New test.
* gcc.target/riscv/rvv/autovec/vls-vlmax/repeat-9.c: New test.
* gcc.target/riscv/rvv/autovec/vls-vlmax/repeat_run-11.c: New test.
* gcc.target/riscv/rvv/autovec/vls-vlmax/repeat_run-7.c: New test.
* gcc.target/riscv/rvv/autovec/vls-vlmax/repeat_run-8.c: New test.

---
 gcc/config/riscv/riscv-v.cc   | 243 --
 .../riscv/rvv/autovec/vls-vlmax/repeat-10.c   |  19 ++
 .../riscv/rvv/autovec/vls-vlmax/repeat-11.c   |  25 ++
 .../riscv/rvv/autovec/vls-vlmax/repeat-7.c|  25 ++
 .../riscv/rvv/autovec/vls-vlmax/repeat-8.c|  15 ++
 .../riscv/rvv/autovec/vls-vlmax/repeat-9.c|  16 ++
 .../rvv/autovec/vls-vlmax/repeat_run-11.c |  45 
 .../rvv/autovec/vls-vlmax/repeat_run-7.c  |  45 
 .../rvv/autovec/vls-vlmax/repeat_run-8.c  |  41 +++
 9 files changed, 451 insertions(+), 23 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/repeat-10.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/repeat-11.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/repeat-7.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/repeat-8.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/repeat-9.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/repeat_run-11.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/repeat_run-7.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/repeat_run-8.c

diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index b8dc333f54e..d844c305320 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -72,11 +72,14 @@ public:
   {
 add_input_operand (RVV_VUNDEF (mode), mode);
   }
-  void add_policy_operand (enum tail_policy vta, enum mask_policy vma)
+  void add_policy_operand (enum tail_policy vta)
   {
 rtx tail_policy_rtx = gen_int_mode (vta, Pmode);
-rtx mask_policy_rtx = gen_int_mode (vma, Pmode);
 add_input_operand (tail_policy_rtx, Pmode);
+  }
+  void add_policy_operand (enum mask_policy vma)
+  {
+rtx mask_policy_rtx = gen_int_mode (vma, Pmode);
 add_input_operand (mask_policy_rtx, Pmode);
   }
   void add_avl_type_operand (avl_type type)
@@ -99,25 +102,36 @@ public:
 add_vundef_operand (dest_mode);
   }
 
-  void set_len_and_policy (rtx len, bool force_vlmax = false)
-{
-  bool vlmax_p = force_vlmax;
-  gcc_assert (has_dest);
+  void set_dest_merge (rtx dest)
+  {
+dest_mode = GET_MODE (dest);
+has_dest = true;
+add_output_operand (dest, dest_mode);
+add_vundef_operand (dest_mode);
+  }
 
-  if (!len)
-   {
- vlmax_p = true;
- len = gen_reg_rtx (Pmode);
- emit_vlmax_vsetvl (dest_mode, len);
-   }
+  void set_len_and_policy (rtx len, bool force_vlmax = false, bool ta_p = true,
+  bool ma_p = true)
+  {
+bool vlmax_p = force_vlmax;
+gcc_assert (has_dest);
 
-  add_input_operand (len, Pmode);
+if (!len)
+  {
+   

[Bug target/109825] [14 Regression] ICE in ix86_widen_mult_cost, at config/i386/i386.cc:20442 since r14-666-g608e7f3ab47fe7

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-05-13

--- Comment #6 from Andrew Pinski  ---
.

[Bug middle-end/109838] [14 Regression] ICE on libaom-3.6.0: in ix86_widen_mult_cost, at config/i386/i386.cc:20444

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 109825.

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

[Bug target/109825] [14 Regression] ICE in ix86_widen_mult_cost, at config/i386/i386.cc:20442 since r14-666-g608e7f3ab47fe7

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

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

[Bug middle-end/109838] New: [14 Regression] ICE on libaom-3.6.0: in ix86_widen_mult_cost, at config/i386/i386.cc:20444

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

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

Bug ID: 109838
   Summary: [14 Regression] ICE on libaom-3.6.0: in
ix86_widen_mult_cost, at config/i386/i386.cc:20444
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

This week's gcc r14-799-g6190a74ebee694 ICEs on libaom-3.6.0. Minimal
reproducer:

// $ cat pickrst_avx2.c.c
unsigned char acc_stat_win7_one_line_avx2_X1;
int acc_stat_win7_one_line_avx2(int M_int[][0]) {
  int k, l;
  for (; k; k++) {
unsigned char *dgd_ijk;
l = 0;
for (; l < 2; l++)
  M_int[k][l] += dgd_ijk[l] * acc_stat_win7_one_line_avx2_X1;
  }
}

$ gcc -O3 -fPIC -mavx2 -c pickrst_avx2.c.c
during GIMPLE pass: slp
pickrst_avx2.c.c: In function 'acc_stat_win7_one_line_avx2':
pickrst_avx2.c.c:2:5: internal compiler error: in ix86_widen_mult_cost, at
config/i386/i386.cc:20444
2 | int acc_stat_win7_one_line_avx2(int M_int[][0]) {
  | ^~~
0x1b27814 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x1b28677 internal_error(char const*, ...)
???:0
0x6ea7cc fancy_abort(char const*, int, char const*)
???:0
0x6d377f ix86_vector_costs::add_stmt_cost(int, vect_cost_for_stmt,
_stmt_vec_info*, _slp_tree*, tree_node*, int, vect_cost_model_location) [clone
.cold]
???:0
0xf17c8a vect_bb_vectorization_profitable_p(_bb_vec_info*, vec<_slp_instance*,
va_heap, vl_ptr>, loop*)
???:0
0xf1c316 vect_slp_region(vec,
vec, vec*, unsigned
int, loop*)
???:0
0xf1d04b vect_slp_bbs(vec const&, loop*)
???:0
0xf1d340 vect_slp_function(function*)
???:0
0xf24ec9 (anonymous namespace)::pass_slp_vectorize::execute(function*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

$ gcc -v |& unnix
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0  (experimental) (GCC)

[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP

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

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

--- Comment #23 from Jonathan Wakely  ---
No, the built-in functions just call the functions defined in libm. GCC doesn't
implement them.

Look at the code for a call to __builtin_acosh:
https://godbolt.org/z/dPf46sKxx

[Bug c++/109824] aligned attribute lost when using it on a typedef of a struct if there was not an usage of the struct beforehand

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-05-12

--- Comment #5 from Andrew Pinski  ---
Here is a better testcase:
```
struct a {
int aa;
};
typedef struct a less_aligned_a __attribute__ ((aligned (1)));
static_assert(alignof(less_aligned_a) == 1);
struct a aa __attribute__((unused));
static_assert(alignof(less_aligned_a) == 1);
```
Which shows the issue.
The first static_assert works but the second one does not.

[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP

[janezz55 at gmail dot com via Gcc-bugs]

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

--- Comment #22 from Janez Zemva  ---
They are very sloppy, so I doubt even what they provide is working 100%. This
is why I suggested the generative approach. gcc has many built-in functions,
surely a rudimentary  could be cobbled out of them.

[Bug c++/109824] aligned attribute lost when using it on a typedef of a struct if there was not an usage of the struct beforehand

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|aligned attribute lost on   |aligned attribute lost when
   |first usage |using it on a typedef of a
   ||struct if there was not an
   ||usage of the struct
   ||beforehand
   Keywords||accepts-invalid, wrong-code

--- Comment #4 from Andrew Pinski  ---
Right, the error message is correct when using it before hand; the alignment
attribute is there.

In the case of the used struct not used before hand, the alignment is lost.

This is the opposite of what you wrote even. You thought it was being lost if
there was an use before hand, rather the alignment is correct then.

[PATCH] aarch64: Add SVE instruction types

[Evandro Menezes via Gcc-patches]

This patch adds the attribute `type` to most SVE1 instructions, as in the other 
instructions.

-- 
Evandro Menezes



0002-aarch64-Add-SVE-instruction-types.patch
Description: Binary data

[Bug libgomp/109837] New: [OpenMP] despite 'requires unified_address' there is segfault when 'is_device_ptr' is not used

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

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

Bug ID: 109837
   Summary: [OpenMP] despite 'requires unified_address' there is
segfault when 'is_device_ptr' is not used
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Cf. https://github.com/SOLLVE/sollve_vv/pull/734 for a testcase.

For nvptx, we currently have:

GOMP_OFFLOAD_get_num_devices (unsigned int omp_requires_mask)
...
  && ((omp_requires_mask
   & ~(GOMP_REQUIRES_UNIFIED_ADDRESS
   | GOMP_REQUIRES_REVERSE_OFFLOAD)) != 0))

That is: we accept for nvptx

  omp requires unfied_address

However, while the address space is the same, the following is not handled:

> the is_device_ptr clause is not necessary to obtain device addresses from 
> device pointers for use inside target regions.

Expected:
(A) Mapping related: is_device_ptr can be left out.
(B) omp_target_is_accessible - will properly work for such pointers.


For nvptx, the check can be done via cudaPointerGetAttributes
if I understand
https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__UNIFIED.html
correctly.

 * * *

NOTE: Something similar is needed for GCN, except that its
GOMP_OFFLOAD_get_num_devices currently returns -1 when
GOMP_REQUIRES_UNIFIED_ADDRESS has been requested.

It seems as if hsa_amd_pointer_info is the function to be used,
cf.
https://github.com/RadeonOpenCompute/ROCR-Runtime/blob/master/src/inc/hsa_ext_amd.h

[Bug c++/109824] aligned attribute lost on first usage

[stsp at users dot sourceforge.net via Gcc-bugs]

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

Stas Sergeev  changed:

   What|Removed |Added

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

--- Comment #3 from Stas Sergeev  ---
Andrew, why not to read the bug description
at least, or try what was said in it?
It says:

But comment out the line 9 under "ifndef BUG"
and it compiles without an error.

This has nothing to do with the bug you
referred as a duplicate.
Please indicate that you tried that, only
then close.

[Bug tree-optimization/109834] [14 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (ssa_name) in gimple_simplify_191 when building harfbuzz

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
Mine I will take care of this.

Re: Re: [PATCH V4] RISC-V: Using merge approach to optimize repeating sequence in vec_init

[钟居哲]

>> What the magic 64 means?
uint64_t mask = 0;
64 = sizeof (uint64_t)

>> gcc_assert will removed at release mode, so it's not you want I guess?
You mean I need to remove it?


juzhe.zh...@rivai.ai
 
From: Kito Cheng
Date: 2023-05-13 00:16
To: juzhe.zhong
CC: gcc-patches; palmer; jeffreyalaw
Subject: Re: [PATCH V4] RISC-V: Using merge approach to optimize repeating 
sequence in vec_init
> +/* Get the mask for merge approach.
> +
> + Consider such following case:
> +   {a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b}
> + To merge "a", the mask should be 1010
> + To merge "b", the mask should be 0101
> +*/
> +rtx
> +rvv_builder::get_merge_mask_bitfield (unsigned int index) const
> +{
> +  uint64_t base_mask = (1ULL << index);
> +  uint64_t mask = 0;
> +  for (unsigned int i = 0; i < (64 / npatterns ()); i++)
 
What the magic 64 means?
...
 
> +static void
> +expand_vector_init_merge_repeating_sequence (rtx target,
> +const rvv_builder )
> +{
> +  machine_mode mask_mode;
> +  gcc_assert (get_mask_mode (builder.mode ()).exists (_mode));
> +
> +  machine_mode dup_mode = builder.mode ();
> +  if (known_gt (GET_MODE_SIZE (dup_mode), BYTES_PER_RISCV_VECTOR))
> +{
> +  poly_uint64 nunits
> +   = exact_div (BYTES_PER_RISCV_VECTOR, builder.inner_units ());
> +  gcc_assert (
> +   get_vector_mode (builder.inner_int_mode (), nunits).exists 
> (_mode));
 
gcc_assert will removed at release mode, so it's not you want I guess?
 
> +}
> +  else
> +{
> +  if (FLOAT_MODE_P (dup_mode))
> +   gcc_assert (get_vector_mode (builder.inner_int_mode (),
> +GET_MODE_NUNITS (dup_mode))
> + .exists (_mode));
 
Same issue
 
> +}
> +
> +  machine_mode dup_mask_mode;
> +  gcc_assert (get_mask_mode (dup_mode).exists (_mask_mode));
 
Same issue
 

gcc-12-20230512 is now available

[GCC Administrator via Gcc]

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

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-12 revision 866beb0a04d7e5ad21f2d7b5c7acca2307f38817

You'll find:

 gcc-12-20230512.tar.xz   Complete GCC

  SHA256=f58ef4846b4af50d5d81b6b7573404ea3e2bfe838f8d321e2322c1876f5cfdd0
  SHA1=3a7e35a0dfb158e571faf92252866273707e86f0

Diffs from 12-20230428 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
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 libstdc++/109814] [13/14 Regression] freestanding using cmath does not compile anymore

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

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

--- Comment #10 from Arsen Arsenović  ---
(In reply to lesto fante from comment #9)
> To be fair I have no idea what would be the impact of removing freestanding,
> from a quick test does not seems to have a realistic impact.
> 
> I guess what happen here is that the freestanding option should remove as
> much as possible, and the -specs=nano.specs should re-enable only the
> minimum necessary.
> 
> Seems like the proper way to do so is to just specify -specs=nano.specs, or
> go full freestanding?

I was hinting at the former.  -ffreestanding doesn't do much (grep for
flag_hosted in gcc/), so it *should* be safe to drop.

(it changes __STDC_HOSTED__, and hence _GLIBCXX_HOSTED, and silences some
main-related warnings)

-specs=nano.specs is a newlib thing - I'm not sure how it's meant to be used
(but it seems fine to keep it from a quick read)

> My user case is industrial robot that have to be as reliable as possible.
> 
> Being able to write embedded code using C++ give me RAII, constexpr,
> templating, function overload, runtime and compile time polymorphism. 
> 
> Generally the manufacturer IDE disable allocation and exception, so I pretty
> much avoid STL as it is a mine field.

libstdc++ ought to work without those.  std::allocator isn't part of the
freestanding subset, but many bits of the STL work regardless of that.

> In pure freestanding, I would expect smart pointer and at least parts cmath
> to work; the compiler offer me only the FPU accelerated functionality, and
> is up to me to implement the remaining.

a good bit is, but not cmath, as a large part of it required a runtime.  you
should be able to use it in your configuration without -ffreestanding, probably

> Unofficial AVR-gcc used the trick of making double into float, i would
> prefer compilation error than those switcheroo under the hoods.

arm-none-eabi-gcc seems to be built with a hosted libstdc++ configuration, so
my guess is (without trying) that removing -ffreestanding should recover


I want to add more code to the freestanding subset to GCC 14, but have not had
time for such experimentation yet.  cmath is on that list.

[Bug tree-optimization/109834] [14 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (ssa_name) in gimple_simplify_191 when building harfbuzz

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-12
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #10 from Andrew Pinski  ---
(In reply to Sam James from comment #8)
> Created attachment 55071 [details]
> graphite2-GlyphCache.cpp.ii (maybe related)

bit_set_count is optimized to __builtin_popcount and read/_peek gets optimized
to __builtin_bswap16 so it is exactly the same just the long way of hitting the
same bug.

[Bug tree-optimization/109834] [14 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (ssa_name) in gimple_simplify_191 when building harfbuzz

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

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

--- Comment #9 from Sam James  ---
(In reply to Sam James from comment #8)
> Created attachment 55071 [details]
> graphite2-GlyphCache.cpp.ii (maybe related)

I guess this is really the same given the operations it's doing (its own
bswaps).

[Bug tree-optimization/109834] [14 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (ssa_name) in gimple_simplify_191 when building harfbuzz

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

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

--- Comment #8 from Sam James  ---
Created attachment 55071
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55071=edit
graphite2-GlyphCache.cpp.ii (maybe related)

[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP

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

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

--- Comment #21 from Jonathan Wakely  ---
Oh, checking FLT_EVAL_METHOD doesn't work, because that's defined in 
not . So another djgpp-specific "NO_FLOAT_TYPES" macro will be needed.
Sigh.

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Sam James:

> Florian Weimer  writes:
>
>> * Sam James:
>>
>>> Florian Weimer  writes:
>>>
 [...]
 In summary, all these seems to be good candidates for errors by default:

 * int-conversion as errors (already raised separately
 * -Wint-conversion for ?:
 * parameter names in non-prototype function declarations
 * the union wait function pointer compatibility kludge
 * return-with-out-value for non-void functions
 * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)

 This are more “maybe“:

 * incompatible-pointer-types as errors (already raised separately)
 * int-conversion and incompatible-pointer-types in comparisons
 * return with value in a function returning void
>>>
>>> -Wreturn-type tends to bite people with C++.
>>
>> Sorry, what do you mean?
>
> Falling off the end of a function in C++ is UB and people fall
> victim to it often, but in C, it's only UB if you try to use
> its return value.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364 is one
> example of many.
>
> What I meant was: I see this a lot in C++ and sometimes in C
> but it's usually trivial to fix, even if it's less harmful
> for some of the instances.

Ohh, I was thinking just about the -Wreturn-type issues for return
statements (value vs no value), not “control reaches end of non-void
function”.  That's a separate issue, and yes, it's more confusing for
C++ due to undefined behavior back-propagation within the same
function.

[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP

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

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

--- Comment #20 from Jonathan Wakely  ---
Created attachment 55070
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55070=edit
Patch to make cmath configure tests more granular

Something like this might work, but it's horrible.

Re: [PATCH] i386: Honour -mdirect-extern-access when calling __fentry__

[Ard Biesheuvel via Gcc-patches]

On Fri, 12 May 2023 at 19:05, Uros Bizjak  wrote:
>
> On Fri, May 12, 2023 at 4:07 PM Ard Biesheuvel  wrote:
>
> > > > > > Note that the GOT reference in question is in fact a data 
> > > > > > reference: we
> > > > > > explicitly load the address of __fentry__ from the GOT, which 
> > > > > > amounts to
> > > > > > eager binding, rather than emitting a PLT call that could bind 
> > > > > > eagerly,
> > > > > > lazily or directly at link time.
> > > > > >
> > > > > > gcc/ChangeLog:
> > > > > >
> > > > > > * config/i386/i386.cc (x86_function_profiler): Take
> > > > > >   ix86_direct_extern_access into account when generating 
> > > > > > calls
> > > > > >   to __fentry__()
> > > > >
> > > > > HJ, is the patch OK with you?
> > > >
> > > > LGTM.
> > >
> > > OK then.
> > >
> >
> > Thanks all. Is anything expected of me at this point?
>
> Do you have write access to the repository? If not I can commit the
> patch for you

Yes, please.

, but you should state this [1] in your patch submission.
>
> [1] https://gcc.gnu.org/contribute.html
>

Signed-off-by: Ard Biesheuvel 

Thanks,

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Florian Weimer  writes:

> * Sam James:
>
>> Florian Weimer  writes:
>>
>>> [...]
>>> In summary, all these seems to be good candidates for errors by default:
>>>
>>> * int-conversion as errors (already raised separately
>>> * -Wint-conversion for ?:
>>> * parameter names in non-prototype function declarations
>>> * the union wait function pointer compatibility kludge
>>> * return-with-out-value for non-void functions
>>> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)
>>>
>>> This are more “maybe“:
>>>
>>> * incompatible-pointer-types as errors (already raised separately)
>>> * int-conversion and incompatible-pointer-types in comparisons
>>> * return with value in a function returning void
>>
>> -Wreturn-type tends to bite people with C++.
>
> Sorry, what do you mean?

Falling off the end of a function in C++ is UB and people fall
victim to it often, but in C, it's only UB if you try to use
its return value.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364 is one
example of many.

What I meant was: I see this a lot in C++ and sometimes in C
but it's usually trivial to fix, even if it's less harmful
for some of the instances.

[Bug c/59905] Unfriendly abort when calling a fucntion via a function pointer cast

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Sam James:

> Florian Weimer  writes:
>
>> [...]
>> In summary, all these seems to be good candidates for errors by default:
>>
>> * int-conversion as errors (already raised separately
>> * -Wint-conversion for ?:
>> * parameter names in non-prototype function declarations
>> * the union wait function pointer compatibility kludge
>> * return-with-out-value for non-void functions
>> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)
>>
>> This are more “maybe“:
>>
>> * incompatible-pointer-types as errors (already raised separately)
>> * int-conversion and incompatible-pointer-types in comparisons
>> * return with value in a function returning void
>
> -Wreturn-type tends to bite people with C++.

Sorry, what do you mean?

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Florian Weimer  writes:

> [...]
> In summary, all these seems to be good candidates for errors by default:
>
> * int-conversion as errors (already raised separately
> * -Wint-conversion for ?:
> * parameter names in non-prototype function declarations
> * the union wait function pointer compatibility kludge
> * return-with-out-value for non-void functions
> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)
>
> This are more “maybe“:
>
> * incompatible-pointer-types as errors (already raised separately)
> * int-conversion and incompatible-pointer-types in comparisons
> * return with value in a function returning void

-Wreturn-type tends to bite people with C++. Obviously the behaviour
is different for C, but it's a serious code smell. I've been playing
with it for C for a while and I don't get that many hits with it of
this type.

> * dereferencing void *
> * taking the address of void

I think I've seen these but they've been accompanied by other issues.

> * "function types not truly compatible in ISO C"
>   and "types are not quite compatible" (depending on what they actually mean)
> * qualifier mismatches (may need separate opt-out)

This has been common for func. ptrs. but not too bad. I haven't
got any data on other cases but am a bit worried about how noisy it'll
be for those.

> * sign mismatches in pointers (definitely needs separate opt-out)
>


signature.asc
Description: PGP signature

[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP

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

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

--- Comment #19 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #15)
> A proper fix would be to split up the configure test for USE_C99_MATH_TR1 to
> be more fine-grained, so that we use the subset of functions that are
> supported, instead of all or nothing.

Ugh, the set of functions defined by djgpp's  seems really arbitraty.

exp2 only has the double form, not float or long double.
expm1 has double and float forms, not long double.
trunc has all three forms.

Even within a group like the Gamma functions, lgamma and lgammaf are present
(but no lgammal) but none of tgamma, tgammaf and tgammal are present.

So there's no clear way to split them up into groups that can be tested
together, it ends up just being incredibly djgpp-specific (and we might as well
just manually add #ifndef __DJGPP__ in very specific places).

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Florian Weimer  writes:

> * Jason Merrill:
>
>> On Fri, May 12, 2023 at 11:03 AM Florian Weimer  wrote:
>>>
>>> * Joseph Myers:
>>>
>>> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
>>> >
>>> >> That is not the case we are discussing, AFAIU.  Or at least no one has
>>> >> yet explained why accepting those old K programs will adversely
>>> >> affect the ability of GCC to compile C2x programs.
>>> >
>>> > At block scope,
>>> >
>>> >   auto x = 1.5;
>>> >
>>> > declares x to have type double in C2x (C++-style auto), but type int in
>>> > C89 (and is invalid for versions in between).  In this case, there is an
>>> > incompatible semantic change between implicit int and C++-style auto.
>>> > Giving an error before we make -std=gnu2x the default seems like a
>>> > particularly good idea, to further alert anyone who has been ignoring the
>>> > warnings about implicit int that semantics will change incompatibly.
>>>
>>> Obviously makes sense to me.
>>
>> Agreed.  But we could safely continue to accept
>>
>>   static x = 42;
>>
>> or even
>>
>>   auto x = 42; // meaning of 'auto' changes, meaning of the declaration does 
>> not
>>
>> We might make -Wimplicit-int an error by default only if the
>> initializer has a type other than 'int'.
>
> Based on what I saw fixing Fedora, these cases are not very common.
> Sure, sometimes common program such as valgrind have an instance
> , but that's really an
> exception.
>
> Implicit int is common as the return type of main (especially in
> autoconf tests), and due to a missing declaration list entry of an
> old-style function definition.  The main case could be treated as an
> exception.  The old-style function definition case is a common source
> of bugs and therefore worth fixing.  The addition of unnamed function
> parameters as an extension actually created a new class of bugs here
> (a typo in the type name of a single unnamed parameter results in an
> old-style function definition by accident).
>
>>> > In cases where the standard requires a diagnostic, some are errors, some
>>> > are pedwarns-by-default or unconditional pedwarns, some are
>>> > pedwarns-if-pedantic - the choice depending on how suspicious the
>>> > construct in question is and whether it corresponds to a meaningful
>>> > extension (this is not making an automatic choice for every such situation
>>> > in the standard, it's a case-by-case judgement by maintainers).  By now,
>>> > the cases discussed in this thread are sufficiently suspicious -
>>> > sufficiently likely to result in unintended execution at runtime (not, of
>>> > course, reliably detected because programs with such dodgy code are very
>>> > unlikely to have thorough automated tests covering all their code) - that
>>> > is it in the interests of users for them to be errors by default (for C99
>>> > and later modes, in the cases that were valid in C89).
>>>
>>> Just to recap, those are controlled by
>>> -Wimplicit-function-declaration, -Wimplicit-int, -Wint-conversion, and
>>> -Wincompatible-pointer-types, roughly in increasing order of
>>> compatibility impact with old sources.
>>
>> What would the impact be of making -Wint-conversion an error by
>> default only if the types are different sizes?
>
> From a distribution perspective, it does not change anything because
> we build everything on 64-bit anyway.  Unlike e.g. Fedora, Debian
> doesn't require all builds to succeed before the new package can be
> installed, but given that the primary targets are 64 bit, I don't
> think a restricted -Wint-conversion error would be much of a
> simplification.  The target-dependent nature of the warning is
> probably more confusing.

I don't see us really gaining anything from restricting it. Like you
said, the cases in the wild are actually all of the same "class".


signature.asc
Description: PGP signature

[Bug c++/109745] [13 Regression] Incorrect code generated with -O1 when having a constexpr object modifying a mutable member

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Carlos Galvez  ---
Thanks a lot for the quick fix!

[Bug c/109835] -Wincompatible-function-pointer-types as a subset of -Wincompatible-pointer-types?

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

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

--- Comment #2 from Sam James  ---
Okay, fair point, I gave examples but not *motivating* examples.

I have some non-harmless examples:
1.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1e0e5c4d289004fa779c86da9319cf2bb18548b1
(a nasty one)
2.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=71ae0b143a55fd45d4fd56cff13438cdbc602089
(sort example)
3.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=996809c0e52057ec8e5f32dd1d9f8f9bea559c18
(interesting example wrt attributes)
4.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=573dae0ef553e180e7f5c85a333adce34237f59b
(completely wrong)

I can dig some more for general examples I've seen, but I tried to pick out
those above w/ different characteristics.

I've seen a lot of e.g. qsort mismatched signatures but struggled for a bit
with finding ABI concerns (SA I feel is something which is hard to manifest as
a problem here because you need that "second order" manipulation which isn't
that common.) But David Seifert (cc'd) came up with this wrt ABI:
```
#include 

void fun(long long x, long long y) {
printf("x = %lld, y = %lld\n", x, y);
}

void (*fun_ptr)(int, int) = fun;

int main() {
int x = 1;
int y = 2;
fun_ptr(x, y);
}
```
... which gives different results on x86_64-unknown-linux-gnu vs
x86_64-unknown-linux-gnu -m32, but the only warning you get is
-Wincompatible-pointer-types with GCC, rather than anything about the mismatch. 

I'll spend some more time reviewing -Wincompatible-pointer-types results when
used on a global build but the last time I tried, it was unreasonably noisy
given the other work we have ahead of us.

[Bug tree-optimization/109834] [14 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (ssa_name) in gimple_simplify_191 when building harfbuzz

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

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

--- Comment #7 from Andrew Pinski  ---
Reduced further:
int split_subtables(char v)
{
  return __builtin_popcount((int)__builtin_bswap16(v));
}

[Bug tree-optimization/109834] [14 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (ssa_name) in gimple_simplify_191 when building harfbuzz

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

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

--- Comment #6 from Sam James  ---
Created attachment 55069
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55069=edit
reduced.ii

I might reduce the graphite2 one for fun just to see how different it is but no
promises.

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Jason Merrill:

> On Fri, May 12, 2023 at 11:03 AM Florian Weimer  wrote:
>>
>> * Joseph Myers:
>>
>> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
>> >
>> >> That is not the case we are discussing, AFAIU.  Or at least no one has
>> >> yet explained why accepting those old K programs will adversely
>> >> affect the ability of GCC to compile C2x programs.
>> >
>> > At block scope,
>> >
>> >   auto x = 1.5;
>> >
>> > declares x to have type double in C2x (C++-style auto), but type int in
>> > C89 (and is invalid for versions in between).  In this case, there is an
>> > incompatible semantic change between implicit int and C++-style auto.
>> > Giving an error before we make -std=gnu2x the default seems like a
>> > particularly good idea, to further alert anyone who has been ignoring the
>> > warnings about implicit int that semantics will change incompatibly.
>>
>> Obviously makes sense to me.
>
> Agreed.  But we could safely continue to accept
>
>   static x = 42;
>
> or even
>
>   auto x = 42; // meaning of 'auto' changes, meaning of the declaration does 
> not
>
> We might make -Wimplicit-int an error by default only if the
> initializer has a type other than 'int'.

Based on what I saw fixing Fedora, these cases are not very common.
Sure, sometimes common program such as valgrind have an instance
, but that's really an
exception.

Implicit int is common as the return type of main (especially in
autoconf tests), and due to a missing declaration list entry of an
old-style function definition.  The main case could be treated as an
exception.  The old-style function definition case is a common source
of bugs and therefore worth fixing.  The addition of unnamed function
parameters as an extension actually created a new class of bugs here
(a typo in the type name of a single unnamed parameter results in an
old-style function definition by accident).

>> > In cases where the standard requires a diagnostic, some are errors, some
>> > are pedwarns-by-default or unconditional pedwarns, some are
>> > pedwarns-if-pedantic - the choice depending on how suspicious the
>> > construct in question is and whether it corresponds to a meaningful
>> > extension (this is not making an automatic choice for every such situation
>> > in the standard, it's a case-by-case judgement by maintainers).  By now,
>> > the cases discussed in this thread are sufficiently suspicious -
>> > sufficiently likely to result in unintended execution at runtime (not, of
>> > course, reliably detected because programs with such dodgy code are very
>> > unlikely to have thorough automated tests covering all their code) - that
>> > is it in the interests of users for them to be errors by default (for C99
>> > and later modes, in the cases that were valid in C89).
>>
>> Just to recap, those are controlled by
>> -Wimplicit-function-declaration, -Wimplicit-int, -Wint-conversion, and
>> -Wincompatible-pointer-types, roughly in increasing order of
>> compatibility impact with old sources.
>
> What would the impact be of making -Wint-conversion an error by
> default only if the types are different sizes?

>From a distribution perspective, it does not change anything because
we build everything on 64-bit anyway.  Unlike e.g. Fedora, Debian
doesn't require all builds to succeed before the new package can be
installed, but given that the primary targets are 64 bit, I don't
think a restricted -Wint-conversion error would be much of a
simplification.  The target-dependent nature of the warning is
probably more confusing.

[PATCH RFC] c-family: make -fno-permissive upgrade pedwarns

[Jason Merrill via Gcc-patches]

In the context of the recent discussion, it occurred to me that this semantic
would be useful, but currently there is no easy way to access it.  Bikeshedding
welcome; the use of this flag is a bit odd, but it has the advantage of being
accepted without error going back at least to 4.3.

-- 8< --

Currently there is no flag to use to upgrade all currently-enabled pedwarns
from warning to error.  -pedantic-errors also enables the -Wpedantic
pedwarns, while -Werror=pedantic uselessly makes only the -Wpedantic
pedwarns errors.

I suggest that since -fpermissive lowers some diagnostics from error to
warning, -fno-permissive could do the reverse.

gcc/ChangeLog:

* doc/invoke.texi: Document -fno-permissive.

gcc/c-family/ChangeLog:

* c.opt (fpermissive): Accept in C and ObjC as well.
* c-opts.cc (c_common_post_options): -fno-permissive sets
global_dc->pedantic_errors.
---
 gcc/doc/invoke.texi| 7 +++
 gcc/c-family/c.opt | 2 +-
 gcc/c-family/c-opts.cc | 4 
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b92b8576027..6198df14382 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -3438,11 +3438,18 @@ issue.  Currently, the only such diagnostic issued by 
G++ is the one for
 a name having multiple meanings within a class.
 
 @opindex fpermissive
+@opindex fno-permissive
 @item -fpermissive
 Downgrade some diagnostics about nonconformant code from errors to
 warnings.  Thus, using @option{-fpermissive} allows some
 nonconforming code to compile.
 
+Conversely, @option{-fno-permissive} can be used to upgrade some
+diagnostics about nonconformant code from warnings to errors.  This
+differs from @option{-pedantic-errors} in that the latter also implies
+@option{-Wpedantic}; this option does not enable additional
+diagnostics, only upgrades the severity of those that are enabled.
+
 @opindex fno-pretty-templates
 @opindex fpretty-templates
 @item -fno-pretty-templates
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index cddeece..07165d2bbe8 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -2075,7 +2075,7 @@ C ObjC C++ ObjC++
 Look for and use PCH files even when preprocessing.
 
 fpermissive
-C++ ObjC++ Var(flag_permissive)
+C ObjC C++ ObjC++ Var(flag_permissive)
 Downgrade conformance errors to warnings.
 
 fplan9-extensions
diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index c68a2a27469..1973c068d59 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -1021,6 +1021,10 @@ c_common_post_options (const char **pfilename)
   SET_OPTION_IF_UNSET (_options, _options_set,
   flag_delete_dead_exceptions, true);
 
+  if (!global_options_set.x_flag_pedantic_errors
+  && global_options_set.x_flag_permissive)
+global_dc->pedantic_errors = !flag_permissive;
+
   if (cxx_dialect >= cxx11)
 {
   /* If we're allowing C++0x constructs, don't warn about C++98

base-commit: 62c4d34ec005e95f000ffabd34da440dc62ac346
-- 
2.31.1

[Bug tree-optimization/109834] [14 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (ssa_name) in gimple_simplify_191 when building harfbuzz

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Mikael Morin from comment #4)
> (In reply to Andrew Pinski from comment #2)
> > I am 99% sure it was introduced by r14-673-g5fdcfe3c5776
> > 
> I think the correct link is r14-673-gc0dd80e4c4c3

Yes, I copied the wrong git commit hash in there :). I really need to update my
gcc-git-customization for this git tree to produce the correct thing in the
first place.

[Bug c++/109654] unnecessary "cannot bind packed field to reference" error when referenced type has aligned(1) attribute

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||stsp at users dot 
sourceforge.net

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

[Bug c++/109824] aligned attribute lost on first usage

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=77388
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Andrew Pinski  ---
This is by design.

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

[Bug tree-optimization/109834] [14 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (ssa_name) in gimple_simplify_191 when building harfbuzz

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #4 from Mikael Morin  ---
(In reply to Andrew Pinski from comment #2)
> I am 99% sure it was introduced by r14-673-g5fdcfe3c5776
> 
I think the correct link is r14-673-gc0dd80e4c4c3

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Joseph Myers:

> On Fri, 12 May 2023, Florian Weimer wrote:
>
>> This sone seems to be a good candidate for additional errors, though:
>> 
>>   warned_here = pedwarn
>> (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0,
>>  "% with no value, in function returning non-void");
>> 
>> It's a clear type volation that can lead to obscure bugs.  Maybe the
>> converse as well.
>
> This one is valid before C99 (the pedwarn is conditional on flag_isoc99, 
> otherwise it's a warning).

Ahh, I see now, this is required for making “return;” work in
functions returning an implied int type.  So it's tied to implicit-int
removal.  I'm going to add checking this to a future run.

> The converse is unconditionally invalid 
> (though the case where the returned expression from the function with void 
> return type itself has void type is valid in C++ and only a 
> pedwarn-if-pedantic for C; that case is a reasonable extension).

Agreed.

Thanks,
Florian

[Bug c/109828] [13/14 Regression] C2x:static compound literal (with flexible array) in initializer leads to invalid size and ICE

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

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

--- Comment #6 from Andrew Pinski  ---
here is another example where we output a bogus `.zero` (though it does not
ICE):
struct s { int i; char c[]; };
const struct s *t = &(struct s) { .c = {'2','\0'}, };

We get:
.size   __compound_literal.0, 4
__compound_literal.0:
.long   1
.byte   50
.byte   0
.zero   18446744073709551613 ;; -3
.zero   1

[Bug libfortran/109662] bad namelist input but gfortran accepted it

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

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

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

https://gcc.gnu.org/g:96cc09dea48b562a0fc93d43fb3b702ac20b89fd

commit r14-802-g96cc09dea48b562a0fc93d43fb3b702ac20b89fd
Author: Jerry DeLisle 
Date:   Fri May 12 13:38:25 2023 -0700

Fortran: Revise a namelist test case.

PR fortran/109662

gcc/testsuite/ChangeLog:

* gfortran.dg/pr109662-a.f90: Add a section to verify that
a short namelist read does not modify the variable.

[Bug libfortran/109662] bad namelist input but gfortran accepted it

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

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

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

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

commit r14-801-gcf3b032b8fb681516ccacbe3689f1cad43a1773a
Author: Jerry DeLisle 
Date:   Fri May 12 12:23:00 2023 -0700

Fortran: Initialize last_char for internal units.

PR fortran/109662

libgfortran/ChangeLog:

* io/unit.c (set_internal_unit): Set the internal unit
last_char to zero so that previous EOF characters do not
influence the next read.

[Bug analyzer/109577] -Wanalyzer-allocation-size mishandles __builtin_mul_overflow

[eggert at cs dot ucla.edu via Gcc-bugs]

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

Paul Eggert  changed:

   What|Removed |Added

 CC||eggert at cs dot ucla.edu

--- Comment #1 from Paul Eggert  ---
I ran into the same problem with gcc (GCC) 13.1.1 20230426 (Red Hat 13.1.1-1)
but I don't know how to update the version number in Bugzilla.

Also, I came up with the following simpler test case. Compile this with "gcc
-O2 -S -fanalyzer foo.c", and it will complain "allocated buffer size is not a
multiple of the pointee's size" in the function "safer", but it will not
complain about the function "unsafe" (which, unlike "safer", does not check for
integer overflow and so is less safe).

void *malloc (unsigned long);

double *
unsafe (unsigned long n)
{
  return malloc (n * sizeof (double));
}

double *
safer (unsigned long n)
{
  unsigned long nbytes;
  if (__builtin_mul_overflow (n, sizeof (double), ))
return 0;
  return malloc (nbytes);
}

Re: [patch, fortran] PR109662 Namelist input with comma after name accepted

[Jerry D via Gcc-patches]

I plan to commit the following as simple.

The issue was a value was being modified on a short namelist read. After 
tthe first read gives the correct EOF, a second read would give the 
error but modify the variable.


diff --git a/libgfortran/io/unit.c b/libgfortran/io/unit.c
index 82664dc5f98..36d025949c2 100644
--- a/libgfortran/io/unit.c
+++ b/libgfortran/io/unit.c
@@ -504,6 +504,7 @@ set_internal_unit (st_parameter_dt *dtp, gfc_unit 
*iunit, int kind)

   iunit->current_record=0;
   iunit->read_bad = 0;
   iunit->endfile = NO_ENDFILE;
+  iunit->last_char = 0;

   /* Set flags for the internal unit.  */


The revised test case attached.  It has been regression tested OK.

Regards,

Jerry! { dg-do run }
! { dg-options "-std=f2003" }
! PR109662-a semi-colon after namelist name accepted on input. 
program testnmlread
  implicit none
  character(16) :: line = ' n = 759/'
  character(100)::message
  integer   :: n, i, ioresult
  namelist/stuff/n
  message = ""
  ioresult = 0
  n = 99
  read(line,nml=stuff,iostat=ioresult)
  if (ioresult == 0) STOP 13 ! Should error with the semi-colon in there.

  ! Intentional short input (-> EOF)
  line = ""
  ! Problem manifests on two bad reads on same string.
  do i = 1, 6
n = -1
ioresult = 0

read (line,nml=stuff,iostat=ioresult)
if (n /= -1) STOP 24
if (ioresult == 0) STOP 25
  end do

end program testnmlread

[Bug middle-end/104069] Wuse-after-free=2 -O0 false positive "may be used"

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

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

--- Comment #32 from Sergei Trofimovich  ---
Created attachment 55068
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55068=edit
gzip.c.c

> > You should be able to extract preprocessed file using
> > https://gcc.gnu.org/bugs/#need: you will need to find exact `gcc` invocation
> > that causes build failure, add `-save-temps` parameter to it, grab '*.i'
> > file and attach it along with exact command you used to produce it.
> 
> That gcc page does not say how to extract the command from the makefile that
> triggers the error, so I've tried to reproduce this bug manually and after
> like the 8th attempt when all the header files were finally found by the
> compiler, the linker errored out with some undefined references, so no luck.
> The good new is that this error is reproducible if the
> cflags/ldflags/configure...etc switches set up like in c#29

gcc help can't cover specifics of external build systems. You have to have a
bit of expertise to extract the actual command build system runs.

As elfutils is an automake-maked '$ make V=1' will print you every gcc command
the build system is running. It should be in a form you can copy and paste as
is (modulo current directory and a few environment variables).

I think I reproduced it on gcc-12.2.0 and elfutils-0.189. Attached as gzip.c.c.

Trigger on gcc-12.2.0:

$ gcc  -std=gnu99 -Wall  -Werror -Os -mtune=generic -c gzip.c.c
In function 'bigger_buffer',
inlined from '__libdw_gunzip' at gzip.c.c:7751:13:
gzip.c.c:7609:13: error: pointer may be used after 'realloc'
[-Werror=use-after-free]
 7609 | b = realloc (state->buffer, more -= 1024);
  | ^
gzip.c.c:7605:15: note: call to 'realloc' here
 7605 | char *b = realloc (state->buffer, more);
  |   ^
cc1: all warnings being treated as errors

gcc-master does not seem to reproduce the failure. I did not test gcc-13.

RE: [EXTERNAL] Re: [PATCH] Fixes and workarounds for warnings during autoprofiledbootstrap build

[Eugene Rozenfeld via Gcc-patches]

Thank you, Richard. I went with your suggestion. New patch:


[PATCH] Disable warnings as errors for STAGEautofeedback.

Compilation during STAGEautofeedback produces additional warnings
since inlining decisions with -fauto-profile are different from
other builds.

This patches disables warnings as errors for STAGEautofeedback.

Tested on x86_64-pc-linux-gnu.

ChangeLog:

* Makefile.in: Disable warnings as errors for STAGEautofeedback
---
 Makefile.in | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Makefile.in b/Makefile.in
index 33f3c862557..4c14c73ea61 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -590,8 +590,7 @@ STAGEautofeedback_CXXFLAGS = $(CXXFLAGS)
 STAGEautofeedback_CXXFLAGS = $(STAGEautofeedback_CFLAGS)
 @endif target-libstdc++-v3-bootstrap
 STAGEautofeedback_TFLAGS = $(STAGE_TFLAGS)
-STAGEautofeedback_CONFIGURE_FLAGS = $(STAGE_CONFIGURE_FLAGS)
-
+STAGEautofeedback_CONFIGURE_FLAGS = $(filter-out 
--enable-werror-always,$(STAGE_CONFIGURE_FLAGS))
 
 # By default, C and C++ are the only stage1 languages, because they are the
 # only ones we require to build with the bootstrap compiler, and also the
-- 
2.25.1

Thanks,

Eugene

-Original Message-
From: Richard Biener  
Sent: Thursday, May 11, 2023 1:58 AM
To: Eugene Rozenfeld 
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [EXTERNAL] Re: [PATCH] Fixes and workarounds for warnings during 
autoprofiledbootstrap build

On Thu, May 11, 2023 at 4:23 AM Eugene Rozenfeld 
 wrote:
>
> I'm ok with disabling warnings as errors for autoprofiledbootstrap. What's 
> the proper way to do that? Searching for "--disable-werror" I see matches in 
> lib configure files but not in gcc files.

We have --with-build-config selecting things like bootstrap-O3 and configure 
then disables werror by default if the build config is anything other than the 
default or bootstrap-debug.

Of course profiledbootstrap and autoprofiledbootstrap are not build configs but 
make targets - that makes it more difficult (or impossible) to use the 
--disable-werror machinery here.

There is

STAGE_CONFIGURE_FLAGS=@stage2_werror_flag@

so it might be possible to filter out --enable-werror-always from 
STAGEautofeedback_CONFIGURE_FLAGS?

Richard.

> Thanks,
>
> Eugene
>
> -Original Message-
> From: Richard Biener 
> Sent: Tuesday, May 9, 2023 11:40 PM
> To: Eugene Rozenfeld 
> Cc: gcc-patches@gcc.gnu.org
> Subject: [EXTERNAL] Re: [PATCH] Fixes and workarounds for warnings 
> during autoprofiledbootstrap build
>
> On Wed, May 10, 2023 at 3:38 AM Eugene Rozenfeld via Gcc-patches 
>  wrote:
> >
> > autoprofiledbootstrap build produces new warnings since inlining 
> > decisions are different from other builds. This patch contains fixes 
> > and workarounds for those warnings.
> >
> > Tested on x86_64-pc-linux-gnu.
>
> Rather than this would it make sense to add --disable-werror to 
> autoprofiledbootstrap configs like we do for others?  I also wonder how 
> "stable" the afdo bootstrap inlining decisions are, so applying these 
> workarounds may not be sustainable?
>
> > gcc/ChangeLog:
> >
> > * config/i386/i386-expand.cc (expand_vec_perm_interleave2): Work 
> > around
> > -Wstringop-overflow false positive during autoprofiledbootstrap
> > * ipa-devirt.cc (debug_tree_odr_name): Fix for -Wformat-overflow
> > warning during autoprofiledbootstrap
> > * lra-eliminations.cc (setup_can_eliminate): Work around
> > -Wmaybe-uninitialized false positive during autoprofiledbootstrap
> > * opts-common.cc (candidates_list_and_hint): Work around
> > -Wstringop-overflow false positive during autoprofiledbootstrap
> > * tree-ssa-ccp.cc (bit_value_unop): Work around 
> > -Wmaybe-uninitialized
> > false positive during autoprofiledbootstrap
> > * wide-int.h (wi::copy): Work around -Wmaybe-uninitialized false
> > positive during autoprofiledbootstrap
> > ---
> >  gcc/config/i386/i386-expand.cc | 11 +++
> >  gcc/ipa-devirt.cc  |  3 ++-
> >  gcc/lra-eliminations.cc| 11 +++
> >  gcc/opts-common.cc |  1 +
> >  gcc/tree-ssa-ccp.cc| 11 +++
> >  gcc/wide-int.h | 11 +++
> >  6 files changed, 47 insertions(+), 1 deletion(-)
> >
> > diff --git a/gcc/config/i386/i386-expand.cc 
> > b/gcc/config/i386/i386-expand.cc index 634fe61ba79..be9f912775b 
> > 100644
> > --- a/gcc/config/i386/i386-expand.cc
> > +++ b/gcc/config/i386/i386-expand.cc
> > @@ -20419,6 +20419,13 @@ expand_vec_perm_pblendv (struct 
> > expand_vec_perm_d *d)
> >
> >  static bool expand_vec_perm_interleave3 (struct expand_vec_perm_d 
> > *d);
> >
> > +/* Work around -Wstringop-overflow false positive during 
> > +autoprofiledbootstrap.  */
> > +
> > +# if GCC_VERSION >= 7001
> > +#pragma GCC diagnostic push
> > +#pragma GCC diagnostic ignored "-Wstringop-overflow"
> > +#endif
> > +
> >  /* A subroutine of ix86_expand_vec_perm_const_1.  Try 

[Bug ada/106168] Errors with empty array aggregate.

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|REOPENED|SUSPENDED

--- Comment #5 from Eric Botcazou  ---
Probably not, but I'm not sure we can do better for now.

Re: More C type errors by default for GCC 14

[Jason Merrill via Gcc]

On Fri, May 12, 2023 at 11:03 AM Florian Weimer  wrote:
>
> * Joseph Myers:
>
> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
> >
> >> That is not the case we are discussing, AFAIU.  Or at least no one has
> >> yet explained why accepting those old K programs will adversely
> >> affect the ability of GCC to compile C2x programs.
> >
> > At block scope,
> >
> >   auto x = 1.5;
> >
> > declares x to have type double in C2x (C++-style auto), but type int in
> > C89 (and is invalid for versions in between).  In this case, there is an
> > incompatible semantic change between implicit int and C++-style auto.
> > Giving an error before we make -std=gnu2x the default seems like a
> > particularly good idea, to further alert anyone who has been ignoring the
> > warnings about implicit int that semantics will change incompatibly.
>
> Obviously makes sense to me.

Agreed.  But we could safely continue to accept

  static x = 42;

or even

  auto x = 42; // meaning of 'auto' changes, meaning of the declaration does not

We might make -Wimplicit-int an error by default only if the
initializer has a type other than 'int'.

> > In cases where the standard requires a diagnostic, some are errors, some
> > are pedwarns-by-default or unconditional pedwarns, some are
> > pedwarns-if-pedantic - the choice depending on how suspicious the
> > construct in question is and whether it corresponds to a meaningful
> > extension (this is not making an automatic choice for every such situation
> > in the standard, it's a case-by-case judgement by maintainers).  By now,
> > the cases discussed in this thread are sufficiently suspicious -
> > sufficiently likely to result in unintended execution at runtime (not, of
> > course, reliably detected because programs with such dodgy code are very
> > unlikely to have thorough automated tests covering all their code) - that
> > is it in the interests of users for them to be errors by default (for C99
> > and later modes, in the cases that were valid in C89).
>
> Just to recap, those are controlled by
> -Wimplicit-function-declaration, -Wimplicit-int, -Wint-conversion, and
> -Wincompatible-pointer-types, roughly in increasing order of
> compatibility impact with old sources.

What would the impact be of making -Wint-conversion an error by
default only if the types are different sizes?

Jason

[Bug tree-optimization/109829] Optimizing __builtin_signbit(x) ? -x : x or abs for FP

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #4)
> Or does match.pd try to invert all the COND_EXPR conditions and swap the
> operands?

match does not try but phiopt does in gimple_simplify_phiopt .

Or even something like this would work better. 
(for neeq (ne eq)
 (simplify
  (cond (neeq (SIGNBIT @0) zero_p@1) (neg @0) @0)
   (if (neqeq == NE_EXPR)
(abs @0)
(neg (abs @0))
   )
  )
 )
)

I need to double check if == 1 will show up here though.

[pushed] wwwdocs: gcc-13/buildstat: Remove trace of XHTML

[Gerald Pfeifer]

Hi Jakub,

do you recall how this snuck in? None of other other pages has had
  <..." />
instead of
  <...">
for a while. Not a biggie at all, just curious.

Pushed.


On a related note, the buildstat pages for GCC 9, 10, 11, 12, and 13
all are empty and I suggest to remove them. Any concerns?

Gerald

---
 htdocs/gcc-13/buildstat.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/gcc-13/buildstat.html b/htdocs/gcc-13/buildstat.html
index fd6ee9e7..a54d0214 100644
--- a/htdocs/gcc-13/buildstat.html
+++ b/htdocs/gcc-13/buildstat.html
@@ -4,7 +4,7 @@
 
 
 Build status for GCC 13
-https://gcc.gnu.org/gcc.css; />
+https://gcc.gnu.org/gcc.css;>
 
 
 
-- 
2.40.1

[Bug libstdc++/109814] [13/14 Regression] freestanding using cmath does not compile anymore

[lestofante88 at gmail dot com via Gcc-bugs]

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

--- Comment #9 from lesto fante  ---
To be fair I have no idea what would be the impact of removing freestanding,
from a quick test does not seems to have a realistic impact.

I guess what happen here is that the freestanding option should remove as much
as possible, and the -specs=nano.specs should re-enable only the minimum
necessary.

Seems like the proper way to do so is to just specify -specs=nano.specs, or go
full freestanding?

My user case is industrial robot that have to be as reliable as possible.

Being able to write embedded code using C++ give me RAII, constexpr,
templating, function overload, runtime and compile time polymorphism. 

Generally the manufacturer IDE disable allocation and exception, so I pretty
much avoid STL as it is a mine field.

In pure freestanding, I would expect smart pointer and at least parts cmath to
work; the compiler offer me only the FPU accelerated functionality, and is up
to me to implement the remaining.

Unofficial AVR-gcc used the trick of making double into float, i would prefer
compilation error than those switcheroo under the hoods.

[Bug tree-optimization/109829] Optimizing __builtin_signbit(x) ? -x : x or abs for FP

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

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

--- Comment #5 from Jakub Jelinek  ---
Or canonicalize COND_EXPRs such that only ne and not eq appears in condition
(and similarly to other comparisons)?

[Bug tree-optimization/109829] Optimizing __builtin_signbit(x) ? -x : x or abs for FP

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Don't you need also
(simplify
 (cond (eq (SIGNBIT @0) zero_p@1) (neg @0) @0)
 (neg (abs @0)))
(simplify
 (cond (eq (SIGNBIT @0) zero_p@1) @0 (neg @0))
 (abs @0))
?
Or does match.pd try to invert all the COND_EXPR conditions and swap the
operands?

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

--- Comment #26 from matoro  ---
We also had somebody report on IRC that they observed this on powerpc (not sure
what tuple), again with -j1.  It does not seem to show up with -j2, so likely
-j1 is necessary to trigger.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

--- Comment #25 from matoro  ---
Created attachment 55067
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55067=edit
build.log for gcc-13.1

This bug is still present on 13.1.0, attaching log

Re: More C type errors by default for GCC 14

[Joseph Myers]

On Fri, 12 May 2023, Florian Weimer wrote:

> This sone seems to be a good candidate for additional errors, though:
> 
>   warned_here = pedwarn
> (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0,
>  "% with no value, in function returning non-void");
> 
> It's a clear type volation that can lead to obscure bugs.  Maybe the
> converse as well.

This one is valid before C99 (the pedwarn is conditional on flag_isoc99, 
otherwise it's a warning).  The converse is unconditionally invalid 
(though the case where the returned expression from the function with void 
return type itself has void type is valid in C++ and only a 
pedwarn-if-pedantic for C; that case is a reasonable extension).

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

[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

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

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)
> If you e.g. put breakpoint on the spot I changed and stopon the testcase
> with -Os when t == global_trees[TI_VOID_LIST_NODE] you can then see in
> e->callee the FUNCTION_TYPE with just 5 arguments.

I am not too experienced to debug this kind of stuff, but I guess I've seen
what happens.  I was then wondering if one of the dump files would show the
function decl, like we can see it for normal procedures, but did not succeed.

The following (partial) patch seems to fix the decl:

diff --git a/gcc/fortran/iresolve.cc b/gcc/fortran/iresolve.cc
index 7880aba63bb..615d3ec98d4 100644
--- a/gcc/fortran/iresolve.cc
+++ b/gcc/fortran/iresolve.cc
@@ -2664,6 +2664,10 @@ gfc_resolve_spread (gfc_expr *f, gfc_expr *source,
gfc_expr *dim,
f->value.function.name = PREFIX ("spread");
 }

+  /* Take formal argument type from SOURCE so that a function decl with the
+ right number of arguments is generated (hidden character length).  */
+  f->value.function.isym->formal->ts = source->ts;
+
   if (dim && gfc_is_constant_expr (dim)
   && ncopies && gfc_is_constant_expr (ncopies) && source->shape[0])
 {

It would be interesting to see if you see issues with the following code:

program p
  character(3) :: a = 'abc'
  real :: b = 42.0
  complex  :: c = (2.0,0.0)
  type t
 integer :: i
  end type t
  type(t)  :: d = t(3)
  associate (y => spread(a,1,2) // "d")
  end associate
  associate (x => spread(b,1,2))
  end associate
  associate (z => spread(c,1,2))
  end associate
  associate (w => spread(d,1,2))
  end associate
end program p

The library function _gfortran_spread_char_scalar should now have 6 arguments,
while the uses of _gfortran_spread_scalar have 4 arguments, which are in part
pointers to either intrinsic or user-defined types.  I do hope that does not
lead to new problems.

[Bug c/109826] Incompatible pointer types in ?: not covered by -Wincompatible-pointer-types

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

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

--- Comment #2 from Andrew Pinski  ---
The warning is not even controlled by an option either so only -Werror turns it
into an error.

[Bug tree-optimization/109829] Optimizing __builtin_signbit(x) ? -x : x or abs for FP

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

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

--- Comment #3 from Andrew Pinski  ---
Should add this one too:

(simplify
 (cond (ne (SIGNBIT @0) zero_p@1) @0 (neg @0))
 (neg (abs @0)))

[Bug c++/106943] GCC building clang/llvm with LTO flags causes ICE in clang

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

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

--- Comment #27 from Andrew Pinski  ---
(In reply to Alexander Monakov from comment #26)
> Would that help? GCC raises its own stack limit to 64MB:
> 
> gcc.cc:  stack_limit_increase (64 * 1024 * 1024);
> toplev.cc:  stack_limit_increase (64 * 1024 * 1024);

Oh I forgot about that.

[Bug c++/106943] GCC building clang/llvm with LTO flags causes ICE in clang

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

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

--- Comment #26 from Alexander Monakov  ---
Would that help? GCC raises its own stack limit to 64MB:

gcc.cc:  stack_limit_increase (64 * 1024 * 1024);
toplev.cc:  stack_limit_increase (64 * 1024 * 1024);

[Bug ada/106168] Errors with empty array aggregate.

[p.p11 at orange dot fr via Gcc-bugs]

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

Pascal Pignard  changed:

   What|Removed |Added

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

--- Comment #4 from Pascal Pignard  ---
That's suppress the warnings.
But it remains strange as the example came from the Ada 2022 standard, see 3.6
Array Types, Examples at §26 and 4.3.3 Array Aggregates, Examples at § 47/5.
Is it correct?

[Bug tree-optimization/109829] Optimizing __builtin_signbit(x) ? -x : x or abs for FP

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
I will implement this since it is only 3 lines or so. Just need some testcases.

Re: [PATCH] ipa: Self-DCE of uses of removed call LHSs (PR 108007)

[Bernhard Reutner-Fischer via Gcc-patches]

On 12 May 2023 14:45:14 CEST, Martin Jambor  wrote:

>gcc/ChangeLog:
>
>2023-05-11  Martin Jambor  
>
>   PR ipa/108007
>   * cgraph.h (cgraph_edge): Add a parameter to
>   redirect_call_stmt_to_callee.
>   * ipa-param-manipulation.h (ipa_param_adjustments): Added a
>   parameter to modify_call.
>   * cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee): New
>   parameter killed_ssas, pass it to padjs->modify_call.
>   * ipa-param-manipulation.cc (purge_transitive_uses): New function.
>   (ipa_param_adjustments::modify_call): New parameter killed_ssas.
>   Instead of substitutin uses, invoke purge_transitive_uses.  If
>   hash of killed SSAs has not been provided, create a temporary one
>   and release SSAs that have been added to it.
>   * tree-inline.cc (redirect_all_calls): Create
>   id->killed_new_ssa_names earlier, pass it to edge redirection,
>   adjust a comment.
>   (copy_body): Release SSAs in id->killed_new_ssa_names.

Nit: Please use present tense in the ChangeLog.
s/Added/Add/
And there is a trailing 'g' missing in substitutin
thanks,

[Bug c++/106943] GCC building clang/llvm with LTO flags causes ICE in clang

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

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

--- Comment #25 from Andrew Pinski  ---
(In reply to Alexander Monakov from comment #24)
> Appreciate the advice. So far I've managed to reduce the number of LTO
> inputs down to two files, RegisterBankInfo.cpp.o plus APInt.cpp.o. I also
> built gcc-12.3 with lineinfo and have a better backtrace:
> 
> during GIMPLE pass: thread
> /tmp/llvm-project-llvmorg-13.0.1/llvm/lib/CodeGen/GlobalISel/
> RegisterBankInfo.cpp: In member function 'verify':
> /tmp/llvm-project-llvmorg-13.0.1/llvm/lib/CodeGen/GlobalISel/
> RegisterBankInfo.cpp:548:6: internal compiler error: Segmentation fault
>   548 | bool RegisterBankInfo::ValueMapping::verify(unsigned
> MeaningfulBitWidth) const {
>   |  ^
> 0xb369ef crash_signal
> ../../gcc-12.3.0/gcc/toplev.cc:322
> 0x17f8977 operator_bitwise_not::fold_range(irange&, tree_node*, irange
> const&, irange const&, tree_code) const
> ../../gcc-12.3.0/gcc/range-op.cc:3479
> 0x17f8977 operator_bitwise_not::fold_range(irange&, tree_node*, irange
> const&, irange const&, tree_code) const
> ../../gcc-12.3.0/gcc/range-op.cc:3465
> 0x171cd0a fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
> ../../gcc-12.3.0/gcc/gimple-range-fold.cc:608
> 0x171e7e0 fold_using_range::fold_stmt(irange&, gimple*, fur_source&,
> tree_node*)
> ../../gcc-12.3.0/gcc/gimple-range-fold.cc:554
> 0x171eb4c fold_range(irange&, gimple*, range_query*)
> ../../gcc-12.3.0/gcc/gimple-range-fold.cc:315
> 0xc985fd path_range_query::range_of_stmt(irange&, gimple*, tree_node*)
> ../../gcc-12.3.0/gcc/gimple-range-path.cc:771
> 0xc99bc4 path_range_query::range_defined_in_block(irange&, tree_node*,
> basic_block_def*)
> ../../gcc-12.3.0/gcc/gimple-range-path.cc:356
> 0xc99dde path_range_query::internal_range_of_expr(irange&, tree_node*,
> gimple*)
> ../../gcc-12.3.0/gcc/gimple-range-path.cc:209
> 0xc99dde path_range_query::internal_range_of_expr(irange&, tree_node*,
> gimple*)
> ../../gcc-12.3.0/gcc/gimple-range-path.cc:193
> 0xc99ef0 path_range_query::range_of_expr(irange&, tree_node*, gimple*)
> ../../gcc-12.3.0/gcc/gimple-range-path.cc:225
> 0x171cabf fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
> ../../gcc-12.3.0/gcc/gimple-range-fold.cc:602
> 0x171e7e0 fold_using_range::fold_stmt(irange&, gimple*, fur_source&,
> tree_node*)
> ../../gcc-12.3.0/gcc/gimple-range-fold.cc:554
> 0x171eb4c fold_range(irange&, gimple*, range_query*)
> ../../gcc-12.3.0/gcc/gimple-range-fold.cc:315
> 0xc985fd path_range_query::range_of_stmt(irange&, gimple*, tree_node*)
> ../../gcc-12.3.0/gcc/gimple-range-path.cc:771
> 0xc99bc4 path_range_query::range_defined_in_block(irange&, tree_node*,
> basic_block_def*)
> ../../gcc-12.3.0/gcc/gimple-range-path.cc:356
> 0xc99dde path_range_query::internal_range_of_expr(irange&, tree_node*,
> gimple*)
> ../../gcc-12.3.0/gcc/gimple-range-path.cc:209
> 0xc99dde path_range_query::internal_range_of_expr(irange&, tree_node*,
> gimple*)
> ../../gcc-12.3.0/gcc/gimple-range-path.cc:193
> 0xc99ef0 path_range_query::range_of_expr(irange&, tree_node*, gimple*)
> ../../gcc-12.3.0/gcc/gimple-range-path.cc:225
> 0x171ccab fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
> ../../gcc-12.3.0/gcc/gimple-range-fold.cc:602
> Please submit a full bug report, with preprocessed source (by using
> -freport-bug).

This looks like a stack overflow happening. To speed up reducing, reducing the
stack size from 8MB (default) down to 4MB might help speed up things.

[Bug c/109828] [13/14 Regression] C2x:static compound literal (with flexible array) in initializer leads to invalid size and ICE

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Yann Droneaud from comment #4)
> I'm still playing with this, for example https://godbolt.org/z/dfjr8veh5,
> and I've noticed the size of the compound_initializer is incorrect too:
> Maybe it's the result of computing the size as 3 + -3 + 1, but it's far
> fetched.

Yes the .size is wrong. But it does not matter much as the ICE on the trunk is
definitely showing there are more issues.

Also yes the ICE is due to checking being enabled:
  gcc_checking_assert (check_string_literal (exp, size));

static bool
check_string_literal (tree string, unsigned HOST_WIDE_INT size)
{
  tree type = TREE_TYPE (string);
  tree eltype = TREE_TYPE (type);
  unsigned HOST_WIDE_INT elts = tree_to_uhwi (TYPE_SIZE_UNIT (eltype));
  unsigned HOST_WIDE_INT mem_size = tree_to_uhwi (TYPE_SIZE_UNIT (type));


The ICE is in that last tree_to_uhwi .

Re: [PATCH] Machine_Mode: Extend machine_mode from 8 to 16 bits

[Bernhard Reutner-Fischer via Gcc-patches]

On 12 May 2023 08:49:53 CEST, Richard Biener via Gcc-patches 
 wrote:

>> gcc/ChangeLog:
>> 
>>  * combine.cc (struct reg_stat_type): Extended machine mode to 16 bits.
>>  * cse.cc (struct qty_table_elem): Ditto.
>>  (struct table_elt): Ditto.
>>  (struct set): Ditto.
>>  * genopinit.cc (main): Reconciled the machine mode limit.
>>  * ira-int.h (struct ira_allocno): Extended machine mode to 16 bits.
>>  * ree.cc (struct ATTRIBUTE_PACKED): Ditto.
>
>please go over the ChangeLog and properly specify the structure types
>altered.  The script generating the changelog isn't perfect.

And a nitpick, please use present tense in the ChangeLog: Extend, etc
And I wouldn't have said reconcile.

thanks,

[Bug c/109828] [13/14 Regression] C2x:static compound literal (with flexible array) in initializer leads to invalid size and ICE

[yann at droneaud dot fr via Gcc-bugs]

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

--- Comment #4 from Yann Droneaud  ---
I'm still playing with this, for example https://godbolt.org/z/dfjr8veh5, and
I've noticed the size of the compound_initializer is incorrect too:

struct s { char i; char c[]; };
const struct s *const s = &(static const struct s) { .c = "1", };

Compile too:

.quad   __compound_literal.4
.type   __compound_literal.4, @object
.size   __compound_literal.4, 1
__compound_literal.4:
.zero   1
.string "1"
.zero   18446744073709551613
.zero   1

I would have have expected .size to be 3, not 1.

Maybe it's the result of computing the size as 3 + -3 + 1, but it's far
fetched.

[Bug c++/106943] GCC building clang/llvm with LTO flags causes ICE in clang

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

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

--- Comment #24 from Alexander Monakov  ---
Appreciate the advice. So far I've managed to reduce the number of LTO inputs
down to two files, RegisterBankInfo.cpp.o plus APInt.cpp.o. I also built
gcc-12.3 with lineinfo and have a better backtrace:

during GIMPLE pass: thread
/tmp/llvm-project-llvmorg-13.0.1/llvm/lib/CodeGen/GlobalISel/RegisterBankInfo.cpp:
In member function 'verify':
/tmp/llvm-project-llvmorg-13.0.1/llvm/lib/CodeGen/GlobalISel/RegisterBankInfo.cpp:548:6:
internal compiler error: Segmentation fault
  548 | bool RegisterBankInfo::ValueMapping::verify(unsigned
MeaningfulBitWidth) const {
  |  ^
0xb369ef crash_signal
../../gcc-12.3.0/gcc/toplev.cc:322
0x17f8977 operator_bitwise_not::fold_range(irange&, tree_node*, irange const&,
irange const&, tree_code) const
../../gcc-12.3.0/gcc/range-op.cc:3479
0x17f8977 operator_bitwise_not::fold_range(irange&, tree_node*, irange const&,
irange const&, tree_code) const
../../gcc-12.3.0/gcc/range-op.cc:3465
0x171cd0a fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
../../gcc-12.3.0/gcc/gimple-range-fold.cc:608
0x171e7e0 fold_using_range::fold_stmt(irange&, gimple*, fur_source&,
tree_node*)
../../gcc-12.3.0/gcc/gimple-range-fold.cc:554
0x171eb4c fold_range(irange&, gimple*, range_query*)
../../gcc-12.3.0/gcc/gimple-range-fold.cc:315
0xc985fd path_range_query::range_of_stmt(irange&, gimple*, tree_node*)
../../gcc-12.3.0/gcc/gimple-range-path.cc:771
0xc99bc4 path_range_query::range_defined_in_block(irange&, tree_node*,
basic_block_def*)
../../gcc-12.3.0/gcc/gimple-range-path.cc:356
0xc99dde path_range_query::internal_range_of_expr(irange&, tree_node*, gimple*)
../../gcc-12.3.0/gcc/gimple-range-path.cc:209
0xc99dde path_range_query::internal_range_of_expr(irange&, tree_node*, gimple*)
../../gcc-12.3.0/gcc/gimple-range-path.cc:193
0xc99ef0 path_range_query::range_of_expr(irange&, tree_node*, gimple*)
../../gcc-12.3.0/gcc/gimple-range-path.cc:225
0x171cabf fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
../../gcc-12.3.0/gcc/gimple-range-fold.cc:602
0x171e7e0 fold_using_range::fold_stmt(irange&, gimple*, fur_source&,
tree_node*)
../../gcc-12.3.0/gcc/gimple-range-fold.cc:554
0x171eb4c fold_range(irange&, gimple*, range_query*)
../../gcc-12.3.0/gcc/gimple-range-fold.cc:315
0xc985fd path_range_query::range_of_stmt(irange&, gimple*, tree_node*)
../../gcc-12.3.0/gcc/gimple-range-path.cc:771
0xc99bc4 path_range_query::range_defined_in_block(irange&, tree_node*,
basic_block_def*)
../../gcc-12.3.0/gcc/gimple-range-path.cc:356
0xc99dde path_range_query::internal_range_of_expr(irange&, tree_node*, gimple*)
../../gcc-12.3.0/gcc/gimple-range-path.cc:209
0xc99dde path_range_query::internal_range_of_expr(irange&, tree_node*, gimple*)
../../gcc-12.3.0/gcc/gimple-range-path.cc:193
0xc99ef0 path_range_query::range_of_expr(irange&, tree_node*, gimple*)
../../gcc-12.3.0/gcc/gimple-range-path.cc:225
0x171ccab fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
../../gcc-12.3.0/gcc/gimple-range-fold.cc:602
Please submit a full bug report, with preprocessed source (by using
-freport-bug).

[Bug c/109828] [13/14 Regression] C2x:static compound literal (with flexible array) in initializer leads to invalid size and ICE

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|C2x:static compound literal |[13/14 Regression]
   |(with flexible array) in|C2x:static compound literal
   |initializer leads to|(with flexible array) in
   |invalid size and ICE|initializer leads to
   ||invalid size and ICE
   Last reconfirmed||2023-05-12
 Status|UNCONFIRMED |NEW

--- Comment #3 from Andrew Pinski  ---
With:
```
struct s { int i; char c[]; };
const struct s *t = &(struct s) { .c = "2", };
```
GCC 12 used to reject it:
:3:44: error: non-static initialization of a flexible array member
3 | const struct s *t = &(struct s) { .c = "2", };
  |^~~
:3:44: note: (near initialization for '(anonymous)')


Note I think the ICE would happen in GCC 13 with checking enabled too.

[Bug c/23087] Misleading warning, "... differ in signedness" with the character types

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|REOPENED|NEW
Summary|Misleading warning, "...|Misleading warning, "...
   |differ in signedness"   |differ in signedness" with
   ||the character types

[Bug c/23087] Misleading warning, "... differ in signedness"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ideasman42 at gmail dot com

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