[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)

2023-09-30 Thread slyfox at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642

Sergei Trofimovich  changed:

   What|Removed |Added

Summary|[14 Regression] |[14 Regression] bootstrap4
   |profiledbootstrap failure:  |or profiledbootstrap
   |poly-int.h:453:5: error:|failure: poly-int.h:453:5:
   |too many initializers for   |error: too many
   |‘long int [1]’ (possibly|initializers for ‘long int
   |since   |[1]’ (possibly since
   |r14-4339-geaa41a6dc127d8)   |r14-4339-geaa41a6dc127d8)

--- Comment #3 from Sergei Trofimovich  ---
(In reply to Sergei Trofimovich from comment #0)

> To reproduce:
> 
> $ ~/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++
> CC='gcc -O1 -g0' CXX='g++ -O1 -g0'
> $ make -j16 profiledbootstrap

Minor note: it has something to do with 4-stage bootstrap (which
profiledbootstrap also happens to be). `make bootstrap4` fails the same way.

[Bug c/111646] New: cos function giving different result for the same input value

2023-09-30 Thread vishwambhar.rathi at puresoftware dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111646

Bug ID: 111646
   Summary: cos function giving different result for the same
input value
   Product: gcc
   Version: 9.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vishwambhar.rathi at puresoftware dot com
  Target Milestone: ---

Hi,

Below are my platform details:

ubuntu@ubuntu:~/code$ gcc --version
gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ubuntu@ubuntu:~/code$ uname -m
aarch64
ubuntu@ubuntu:~/code$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.04.6 LTS
Release:20.04
Codename:   focal

I am running ubuntu on windows using Qemu emulator. I tried the fowlloing
simple code:

#include
#include
#include
void main()
{
double x = -9311848.013224;
printf("x %.6lf cosx_1 %.6f\n",x, cos(x));
printf("x %.6lf cosx_2 %.6f\n",x, cos(x));
}

I got different values as output. The output is:

x -9311848.013224 cosx_1 -0.634393
x -9311848.013224 cosx_2 -0.92

Any thoughts, what is going on?

Thanks,
Vish.

[Bug middle-end/111646] cos function giving different result for the same input value

2023-09-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111646

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-09-30

--- Comment #1 from Andrew Pinski  ---
Works for me on a physical hardware:
```
ubuntu@ubuntu:~/src\# gcc t.c -lm
ubuntu@ubuntu:~/src\# ./a.out
x -9311848.013224 cosx_1 -0.634393
x -9311848.013224 cosx_2 -0.634393
ubuntu@ubuntu:~/src\# gcc t.c -lm -O1
ubuntu@ubuntu:~/src\# ./a.out
x -9311848.013224 cosx_1 -0.634393
x -9311848.013224 cosx_2 -0.634393
ubuntu@ubuntu:~/src\# gcc t.c -lm -O2
ubuntu@ubuntu:~/src\# ./a.out
x -9311848.013224 cosx_1 -0.634393
x -9311848.013224 cosx_2 -0.634393
ubuntu@ubuntu:~/src\# uname -a
Linux ubuntu 5.4.74-10348-gabddb56e7886 #1 SMP PREEMPT Fri Mar 5 18:58:46 PST
2021 aarch64 aarch64 aarch64 GNU/Linux
ubuntu@ubuntu:~/src\# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.1 LTS
Release:18.04
Codename:   bionic
ubuntu@ubuntu:~/src\# lscpu
Architecture:aarch64
Byte Order:  Little Endian
CPU(s):  24
On-line CPU(s) list: 0-23
Thread(s) per core:  1
Core(s) per socket:  24
Socket(s):   1
Vendor ID:   Cavium
Model:   0
Stepping:0x2
BogoMIPS:200.00
L1d cache:   41K
L1i cache:   66K
L2i cache:   1280K
L3 cache:14336K
Flags:   fp asimd aes pmull sha1 sha2 crc32 atomics cpuid asimdrdm
dcpop
```

Maybe this is a bug in qemu.

[Bug analyzer/104940] RFE: integrate analyzer with an SMT solver

2023-09-30 Thread kristerw at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940

Krister Walfridsson  changed:

   What|Removed |Added

 CC||kristerw at gcc dot gnu.org

--- Comment #7 from Krister Walfridsson  ---
I have released a new version of my tool doing GIMPLE IR to SMT conversion.
This is now written in C++, and converts a bigger subset of GIMPLE. The code is
available at https://github.com/kristerw/smtgcc

[Bug middle-end/111646] cos function giving different result for the same input value

2023-09-30 Thread vishwambhar.rathi at puresoftware dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111646

--- Comment #2 from vishwambhar.rathi at puresoftware dot com ---
Thanks. I am using Ubuntu 20.04. Could this be related to that? Or should I
post it on qemu?


From: pinskia at gcc dot gnu.org 
Sent: 30 September 2023 14:15
To: Vishwambhar Rathi 
Subject: [Bug middle-end/111646] cos function giving different result for the
same input value

[You don't often get email from gcc-bugzi...@gcc.gnu.org. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-09-30

--- Comment #1 from Andrew Pinski  ---
Works for me on a physical hardware:
```
ubuntu@ubuntu:~/src\# gcc t.c -lm
ubuntu@ubuntu:~/src\# ./a.out
x -9311848.013224 cosx_1 -0.634393
x -9311848.013224 cosx_2 -0.634393
ubuntu@ubuntu:~/src\# gcc t.c -lm -O1
ubuntu@ubuntu:~/src\# ./a.out
x -9311848.013224 cosx_1 -0.634393
x -9311848.013224 cosx_2 -0.634393
ubuntu@ubuntu:~/src\# gcc t.c -lm -O2
ubuntu@ubuntu:~/src\# ./a.out
x -9311848.013224 cosx_1 -0.634393
x -9311848.013224 cosx_2 -0.634393
ubuntu@ubuntu:~/src\# uname -a
Linux ubuntu 5.4.74-10348-gabddb56e7886 #1 SMP PREEMPT Fri Mar 5 18:58:46 PST
2021 aarch64 aarch64 aarch64 GNU/Linux
ubuntu@ubuntu:~/src\# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.1 LTS
Release:18.04
Codename:   bionic
ubuntu@ubuntu:~/src\# lscpu
Architecture:aarch64
Byte Order:  Little Endian
CPU(s):  24
On-line CPU(s) list: 0-23
Thread(s) per core:  1
Core(s) per socket:  24
Socket(s):   1
Vendor ID:   Cavium
Model:   0
Stepping:0x2
BogoMIPS:200.00
L1d cache:   41K
L1i cache:   66K
L2i cache:   1280K
L3 cache:14336K
Flags:   fp asimd aes pmull sha1 sha2 crc32 atomics cpuid asimdrdm
dcpop
```

Maybe this is a bug in qemu.

--
You are receiving this mail because:
You reported the bug.

[Bug middle-end/111625] valgrind error with ./gcc.dg/bitint-8.c

2023-09-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111625

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

https://gcc.gnu.org/g:09b512466ce302833d1624045fc5fe5afe040f58

commit r14-4349-g09b512466ce302833d1624045fc5fe5afe040f58
Author: Jakub Jelinek 
Date:   Sat Sep 30 11:28:44 2023 +0200

lowerbitint: Fix 2 bitint lowering bugs [PR111625]

This patch fixes 2 issues.  One is when we want to get address of
an uninitialized large/huge bitint SSA_NAME for
multiplication/division/modulo
or conversion to floating point (binary or decimal), the code just creates
an uninitialized limb sized variable and passes address of that, but I
forgot
to initialize *prec in that case, so it invoked UB at compile time rather
than at runtime.  As it is UB, we could use anything valid as precision
there,
say 2 bits for signed, 1 bit for unsigned as smallest possible set of
values,
or full bitint precision as full random value.  Though, because we only
pass
address to a single limb, I think it is best to pass the bitsize of the
limb.

And the other issue is that when ranger in range_to_prec finds some range
is undefined_p (), it will assert {lower,upper}_bound () method isn't
called
on it, but we were.  So, the patch adjusts range_to_proc to treat it like
the !optimized case, full bitint precision.

2023-09-30  Jakub Jelinek  

PR middle-end/111625
PR middle-end/111637
* gimple-lower-bitint.cc (range_to_prec): Use prec or -prec if
r.undefined_p ().
(bitint_large_huge::handle_operand_addr): For uninitialized
operands
use limb_prec or -limb_prec precision.

[Bug middle-end/111637] ICE while building gcc.dg/bitint-8.c with -fsanitize=signed-integer-overflow

2023-09-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111637

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

https://gcc.gnu.org/g:09b512466ce302833d1624045fc5fe5afe040f58

commit r14-4349-g09b512466ce302833d1624045fc5fe5afe040f58
Author: Jakub Jelinek 
Date:   Sat Sep 30 11:28:44 2023 +0200

lowerbitint: Fix 2 bitint lowering bugs [PR111625]

This patch fixes 2 issues.  One is when we want to get address of
an uninitialized large/huge bitint SSA_NAME for
multiplication/division/modulo
or conversion to floating point (binary or decimal), the code just creates
an uninitialized limb sized variable and passes address of that, but I
forgot
to initialize *prec in that case, so it invoked UB at compile time rather
than at runtime.  As it is UB, we could use anything valid as precision
there,
say 2 bits for signed, 1 bit for unsigned as smallest possible set of
values,
or full bitint precision as full random value.  Though, because we only
pass
address to a single limb, I think it is best to pass the bitsize of the
limb.

And the other issue is that when ranger in range_to_prec finds some range
is undefined_p (), it will assert {lower,upper}_bound () method isn't
called
on it, but we were.  So, the patch adjusts range_to_proc to treat it like
the !optimized case, full bitint precision.

2023-09-30  Jakub Jelinek  

PR middle-end/111625
PR middle-end/111637
* gimple-lower-bitint.cc (range_to_prec): Use prec or -prec if
r.undefined_p ().
(bitint_large_huge::handle_operand_addr): For uninitialized
operands
use limb_prec or -limb_prec precision.

[Bug middle-end/111637] ICE while building gcc.dg/bitint-8.c with -fsanitize=signed-integer-overflow

2023-09-30 Thread jakub at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111637

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Should be fixed now.

[Bug middle-end/111625] valgrind error with ./gcc.dg/bitint-8.c

2023-09-30 Thread jakub at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111625

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Should be fixed now.

[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)

2023-09-30 Thread slyfox at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642

--- Comment #4 from Sergei Trofimovich  ---
Looks like `-fchecking=1` and `-fno-checking` handle c++ a bit differently.

Two commands differing only in `-fno-checking`. One works, one does not:

```
$ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu 
-I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
-I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++
-L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs  -fno-PIE -c  
-g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -fno-PIE -I. -I. -I/home/slyfox/dev/git/gcc/gcc
-I/home/slyfox/dev/git/gcc/gcc/. -I/home/slyfox/dev/git/gcc/gcc/../include 
-I/home/slyfox/dev/git/gcc/gcc/../libcpp/include
-I/home/slyfox/dev/git/gcc/gcc/../libcody 
-I/home/slyfox/dev/git/gcc/gcc/../libdecnumber
-I/home/slyfox/dev/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/slyfox/dev/git/gcc/gcc/../libbacktrace   -o rtl-tests.o -MT rtl-tests.o
-MMD -MP -MF ./.deps/rtl-tests.TPo /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc
In file included from /home/slyfox/dev/git/gcc/gcc/coretypes.h:480,
 from /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:22:
/home/slyfox/dev/git/gcc/gcc/poly-int.h: In instantiation of 'constexpr
poly_int::poly_int(poly_int_full, const Cs& ...) [with Cs = {int, int};
unsigned int N = 1; C = long int]':
/home/slyfox/dev/git/gcc/gcc/poly-int.h:439:13:   required from here
/home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:249:25:   in 'constexpr' expansion of
'poly_int<1, long int>(1, 1)'
/home/slyfox/dev/git/gcc/gcc/poly-int.h:453:5: error: too many initializers for
'long int [1]'
  453 |   : coeffs { (typename poly_coeff_traits::
  | ^
  454 |   template init_cast::type (cs))... } {}
  |   ~~~


# fails
```

```
$ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu 
-I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
-I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++
-L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs  -fno-PIE -c  
-g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -fno-PIE -I. -I. -I/home/slyfox/dev/git/gcc/gcc
-I/home/slyfox/dev/git/gcc/gcc/. -I/home/slyfox/dev/git/gcc/gcc/../include 
-I/home/slyfox/dev/git/gcc/gcc/../libcpp/include
-I/home/slyfox/dev/git/gcc/gcc/../libcody 
-I/home/slyfox/dev/git/gcc/gcc/../libdecnumber
-I/home/slyfox/dev/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/slyfox/dev/git/gcc/gcc/../libbacktrace   -o rtl-tests.o -MT rtl-tests.o
-MMD -MP -MF ./.deps/rtl-tests.TPo /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc
-fno-checking

# ok
```

[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)

2023-09-30 Thread slyfox at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642

--- Comment #5 from Sergei Trofimovich  ---
The default value is `-fchecking=2` there. `-fchecking=0` and `-fchecking=1`
work fine. This means `-fchecking=` slightly alters c++ template instantiation.

I'll try to extract smaller example.

The following workaround seems to restore the build:

--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -29302,20 +29302,21 @@ tree
 build_non_dependent_expr (tree expr)
 {
   tree orig_expr = expr;
   tree inner_expr;

   /* When checking, try to get a constant value for all non-dependent
  expressions in order to expose bugs in *_dependent_expression_p
  and constexpr.  This can affect code generation, see PR70704, so
  only do this for -fchecking=2.  */
   if (flag_checking > 1
+  && false
   && cxx_dialect >= cxx11
   /* Don't do this during nsdmi parsing as it can lead to
 unexpected recursive instantiations.  */
   && !parsing_nsdmi ()
   /* Don't do this during concept processing either and for
  the same reason.  */
   && !processing_constraint_expression_p ())
 fold_non_dependent_expr (expr, tf_none);

   STRIP_ANY_LOCATION_WRAPPER (expr);

[Bug fortran/111644] [13 regression] many failures after r13-7923-gd9b3269bdccac2

2023-09-30 Thread vehre at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111644

Andre Vehreschild  changed:

   What|Removed |Added

   Last reconfirmed||2023-09-30
 Target|powerpc64-linux-gnu,|
   |powerpc64le-linux-gnu   |
   Host|powerpc64-linux-gnu,|
   |powerpc64le-linux-gnu   |
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org
  Build|powerpc64-linux-gnu,|
   |powerpc64le-linux-gnu   |

--- Comment #1 from Andre Vehreschild  ---
Fails on all archs.

Mistake identified and fixed. Will publish as soon as regression testing
passes.

Sorry for the mess.

[Bug c++/111647] New: g++ accepts different c++ on -fchecking= anf checking=2

2023-09-30 Thread slyfox at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111647

Bug ID: 111647
   Summary: g++ accepts different c++ on -fchecking= anf
checking=2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Encountered when was reducing PR111642 where `make bootstrap4` fails. Reduced
example:

// $ cat rtl-tests.cc.cc
struct poly_int {
  template  constexpr poly_int() : poly_int() {}
};
template  void run() { poly_int(); }

Here is the mismatch between -fchecking=0 and -fchecking=2:

$ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -c rtl-tests.cc.cc -o bug
-fchecking=0
$ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -c rtl-tests.cc.cc -o bug
-fchecking=2
rtl-tests.cc.cc: In instantiation of ‘constexpr poly_int::poly_int() [with
 = {}]’:
rtl-tests.cc.cc:4:39:   required from here
rtl-tests.cc.cc:2:58: error: constructor delegates to itself
2 |   template  constexpr poly_int() : poly_int() {}
  |  

I think it's an invalid code (clang rejects it as well), but I'm not sure.
AFAIU all -fchecking= options should handle it identically.

gcc is from r14-4339-geaa41a6dc127d8

$ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -v
Reading specs from /tmp/gb/./prev-gcc/specs
COLLECT_GCC=/tmp/gb/./prev-gcc/xg++
COLLECT_LTO_WRAPPER=/tmp/gb/./prev-gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
--enable-languages=c,c++ CC='gcc -O1 -g0' CXX='g++ -O1 -g0'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230929 (experimental) (GCC)

[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)

2023-09-30 Thread slyfox at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642

Sergei Trofimovich  changed:

   What|Removed |Added

 Depends on||111647

--- Comment #6 from Sergei Trofimovich  ---
(In reply to Sergei Trofimovich from comment #5)
> I'll try to extract smaller example.

Got the following, but I'm not sure it's valid C++:

struct poly_int {
  template  constexpr poly_int() : poly_int() {}
};
template  void run() { poly_int(); }

Filed PR111647 and will try to extract something less invalid.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111647
[Bug 111647] g++ accepts different c++ on -fchecking= anf checking=2

[Bug fortran/111644] [13 regression] many failures after r13-7923-gd9b3269bdccac2

2023-09-30 Thread vehre at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111644

Andre Vehreschild  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from Andre Vehreschild  ---
I think it is fixed by 874b895fffd921659b37dc05bc94eea48e9a0157. 

seu...@gcc.gnu.org can you retest and close this PR when fixed, please?

[Bug tree-optimization/111648] New: Wrong code at -O2/3 on x86_64-linux-gnu since r14-3243-ga7dba4a1c05

2023-09-30 Thread shaohua.li at inf dot ethz.ch via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111648

Bug ID: 111648
   Summary: Wrong code at -O2/3 on x86_64-linux-gnu since
r14-3243-ga7dba4a1c05
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

gcc at -O2/3 produced the wrong code

Bisected to r14-3243-ga7dba4a1c05

Compiler explorer: https://godbolt.org/z/1bvWTrEK1

$ cat a.c
int printf(const char *, ...);
int a;
int *b = &a;
static int **c = &b;
static int d;
short e;
char f;
int main() {
  f = -21;
  for (; f < -5; f++) {
e = f ^ 3;
d = *b;
**c = e;
  }
  printf("%d\n", d);
}
$
$ gcc -O0 a.c && ./a.out
-6
$ gcc -O2 a.c && ./a.out
2
$

[Bug middle-end/111646] cos function giving different result for the same input value

2023-09-30 Thread xry111 at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111646

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #3 from Xi Ruoyao  ---
Are you compiling with optimization?  If you are not enabling any optimization,
the result of cos actually comes from Glibc and it's not a GCC issue.

[Bug target/108851] gcc -pie generates unwanted PE export table

2023-09-30 Thread pali at kernel dot org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108851

Pali Rohár  changed:

   What|Removed |Added

   See Also|https://sourceware.org/bugz |https://sourceware.org/bugz
   |illa/show_bug.cgi?id=30004  |illa/show_bug.cgi?id=30922

--- Comment #4 from Pali Rohár  ---
No response here, so I reported it to binutils bugtracker:
https://sourceware.org/bugzilla/show_bug.cgi?id=30922

[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)

2023-09-30 Thread slyfox at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642

--- Comment #7 from Sergei Trofimovich  ---
If I try to build the file with `clang++-16` I'm getting the following error:

In file included from /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:22:
In file included from /home/slyfox/dev/git/gcc/gcc/coretypes.h:480:
/home/slyfox/dev/git/gcc/gcc/poly-int.h:453:14: error: excess elements in array
initializer
  : coeffs { (typename poly_coeff_traits::
 ^~~~
/home/slyfox/dev/git/gcc/gcc/poly-int.h:438:5: note: in instantiation of
function template specialization 'poly_int<1, long>::poly_int'
requested here
  : poly_int (typename poly_int_fullness= N>::type (),
^
/home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:249:26: note: in instantiation of
function template specialization 'poly_int<1, long>::poly_int'
requested here
  rtx x1 = gen_int_mode (poly_int64 (1, 1), QImode);
 ^

Which sounds like we should not try to create polynomials with values more than
`NUM_POLY_INT_COEFFS` (== 1 on x86_64).

I'm still not sure if the templates are expected to defer build failure in this
case or it's a c++ syntax error in gcc's code.

[Bug target/111645] Intrinsics vec_sldb /vec_srdb fail with __vector unsigned __int128

2023-09-30 Thread bergner at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111645

Peter Bergner  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-09-30
 CC||bergner at gcc dot gnu.org,
   ||dje at gcc dot gnu.org,
   ||linkw at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #1 from Peter Bergner  ---
I see that we have created built-in overloads for signed and unsigned vector
char through vector long long.  That said, the rs6000-builtins.def only seems
to support the signed vector types though, which is why you're seeing an error.
 So confirmed.

That said, I believe your 3rd argument needs to be a real constant integer,
since the vsldbi instruction requires that.  It doesn't allow for a const int
variable.  I notice some older (not trunk) gcc versions are ICEing with that,
so another bug to look at.

I do not see any documentation that says we support the vector __int128 type. 
Where exactly did you see that?  However, from the instruction description, it
seems like the hw instruction could support that.

[Bug tree-optimization/111648] Wrong code at -O2/3 on x86_64-linux-gnu since r14-3243-ga7dba4a1c05

2023-09-30 Thread prathamesh3492 at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111648

--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
Hi,
Sorry for the breakage, will take a look.

Thanks,
Prathamesh

[Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr

2023-09-30 Thread gjl at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639

--- Comment #2 from Georg-Johann Lay  ---
(In reply to Jonathan Wakely from comment #0)
> The  in avr-libc does things like this:
> 
> extern double acos(double __x) __ATTR_CONST__;
> #define acosf acos/**< The alias for acos().  */

This is no more the case with current AVR-LibC, which uses proper prototypes
and symbols for acos, acosf and acosl etc.

Here is math.h from the AVR-LibC v2.1 release (Jan 2022) :
https://github.com/avrdudes/avr-libc/blob/c466ef11ebf6cf774b7148dbd78c250789989ce0/include/math.h
(which has only acos and acosf, where the alias is implemented using assembly
name __asm("")).

The next release will also include long double prototypes, and they are proper
prototypes (without __asm("") names).

math.h from current HEAD:
https://github.com/avrdudes/avr-libc/blob/main/include/math.h

[Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr

2023-09-30 Thread redi at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639

--- Comment #3 from Jonathan Wakely  ---
Ah, good to know, thanks.

Which versions of avr-libc are supported with gcc? The version of avr-libc in
Fedora has the macros, which means I can't build avr-gcc with the patch for pr
79700 applied.

[Bug target/111649] New: [14 Regression] Bootstrap failure in stage 1 on riscv*-*-* since r14-4348-g9d249b7e31e

2023-09-30 Thread patrick at rivosinc dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649

Bug ID: 111649
   Summary: [14 Regression] Bootstrap failure in stage 1 on
riscv*-*-* since r14-4348-g9d249b7e31e
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Caused by r14-4348-g9d249b7e31e

Observed on glibc, newlib
rv{32|64}{gc|gcv|gcv_zvbb_zvbc_zvkg_zvkn_zvknc_zvkned_zvkng_zvknha_zvknhb_zvks_zvksc_zvksed_zvksg_zvksh_zvkt}

Likely not riscv-specific.

Failure:

In file included from ../../../gcc/gcc/hash-table.h:248,
 from ../../../gcc/gcc/coretypes.h:491,
 from ../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:82:
../../../gcc/gcc/vec.h: In instantiation of ‘void vec::quick_grow(unsigned int) [with T = riscv_vector::vector_insn_info; A
= va_heap]’:
../../../gcc/gcc/vec.h:2125:23:   required from ‘void
vec::safe_grow(unsigned int, bool) [with T =
riscv_vector::vector_insn_info]’
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:2420:31:   required from here
../../../gcc/gcc/vec.h:1419:63: error: static assertion failed
 1419 |   static_assert (std::is_trivially_default_constructible ::value,
"");
  |   ^
../../../gcc/gcc/vec.h:1419:63: note: ‘std::integral_constant::value’ evaluates to false
../../../gcc/gcc/vec.h: In instantiation of ‘void vec::quick_grow(unsigned int) [with T = riscv_vector::vector_block_info;
A = va_heap]’:
../../../gcc/gcc/vec.h:2125:23:   required from ‘void
vec::safe_grow(unsigned int, bool) [with T =
riscv_vector::vector_block_info]’
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:2421:32:   required from here
../../../gcc/gcc/vec.h:1419:63: error: static assertion failed
../../../gcc/gcc/vec.h:1419:63: note: ‘std::integral_constant::value’ evaluates to false
g++  -fno-PIE -c   -g -O2   -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H
-fno-PIE -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/.
-I../../../gcc/gcc/../include  -I../../../gcc/gcc/../libcpp/include
-I../../../gcc/gcc/../libcody  -I../../../gcc/gcc/../libdecnumber
-I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../../gcc/gcc/../libbacktrace   -o sbitmap.o -MT sbitmap.o -MMD -MP -MF
./.deps/sbitmap.TPo ../../../gcc/gcc/sbitmap.cc
make[2]: *** [../../../gcc/gcc/config/riscv/t-riscv:69: riscv-vsetvl.o] Error 1

[Bug c++/111647] g++ accepts different c++ on -fchecking= anf checking=2

2023-09-30 Thread slyfox at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111647

--- Comment #1 from Sergei Trofimovich  ---
More realistic example extracted from gcc's poly_int:

// $ cat rtl-tests.cc
template struct poly_int {
  template constexpr poly_int (const Cs &... cs)
  : coeffs { cs... } {}

  int coeffs[N];
};

#define TARGET_DEFINED_VALUE 1
// this works:
//#define TARGET_DEFINED_VALUE 2

// Is instantiated only for N == 2.
template struct const_poly_int_tests {
  static void run () {
poly_int (1, 1);
  }
};

$ g++ -c rtl-tests.cc -fchecking=1
# did not fail, BAD!

$ g++ -c rtl-tests.cc -fchecking=2
rtl-tests.cc: In instantiation of 'constexpr poly_int::poly_int(const Cs&
...) [with Cs = {int, int}; unsigned int N = 1]':
rtl-tests.cc:15:42:   required from here
rtl-tests.cc:3:5: error: too many initializers for 'int [1]'
3 |   : coeffs { cs... } {}
  | ^~~~
# failed, GOOD

$ clang++ -c rtl-tests.cc
rtl-tests.cc:3:14: error: excess elements in array initializer
  : coeffs { cs... } {}
 ^~
rtl-tests.cc:15:5: note: in instantiation of function template specialization
'poly_int<1>::poly_int' requested here
poly_int (1, 1);
^
1 error generated.
# failed, GOOD

[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)

2023-09-30 Thread slyfox at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642

--- Comment #8 from Sergei Trofimovich  ---
With https://gcc.gnu.org/PR111647#c1 I'm convinced it's a gcc's source code bug
and we should not try to write calls like `poly_int<1, T>(1, 1)` with
mismatching arity.

[Bug target/111649] [14 Regression] Bootstrap failure in stage 1 on riscv*-*-* since r14-4348-g9d249b7e31e

2023-09-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649

--- Comment #1 from Andrew Pinski  ---
What is the host compiler?

[Bug target/111649] [14 Regression] Bootstrap failure in stage 1 on riscv*-*-* since r14-4348-g9d249b7e31e

2023-09-30 Thread jakub at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Target|riscv   |
   Target Milestone|--- |14.0

--- Comment #2 from Jakub Jelinek  ---
This is riscv specific.
As the diagnostics explains, riscv_vector::vector_insn_info has non-trivial
default
constructor, so either it should be used only in {quick,safe}_grow_cleared and
not
{quick,safe}_grow vec operation, or should be changed not to have non-trivial
default constructor, because *_grow doesn't invoke the constructors, only
*_grow_cleared does.
--- gcc/config/riscv/riscv-vsetvl.cc.jj 2023-09-28 11:32:15.966436424 +0200
+++ gcc/config/riscv/riscv-vsetvl.cc2023-09-30 21:30:05.880134900 +0200
@@ -2417,7 +2417,7 @@ vector_infos_manager::vector_infos_manag
   vector_antin = nullptr;
   vector_antout = nullptr;
   vector_earliest = nullptr;
-  vector_insn_infos.safe_grow (get_max_uid ());
+  vector_insn_infos.safe_grow_cleared (get_max_uid ());
   vector_block_infos.safe_grow (last_basic_block_for_fn (cfun));
   if (!optimize)
 {

[Bug target/111649] [14 Regression] Bootstrap failure in stage 1 on riscv*-*-* since r14-4348-g9d249b7e31e

2023-09-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-09-30
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
Confirmed.

[Bug target/111649] [14 Regression] Bootstrap failure in stage 1 on riscv*-*-* since r14-4348-g9d249b7e31e

2023-09-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649

--- Comment #4 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #2)
> This is riscv specific.
> As the diagnostics explains, riscv_vector::vector_insn_info has non-trivial
> default
> constructor, so either it should be used only in {quick,safe}_grow_cleared
> and not
> {quick,safe}_grow vec operation, or should be changed not to have non-trivial
> default constructor, because *_grow doesn't invoke the constructors, only
> *_grow_cleared does.
> --- gcc/config/riscv/riscv-vsetvl.cc.jj   2023-09-28 11:32:15.966436424 
> +0200
> +++ gcc/config/riscv/riscv-vsetvl.cc  2023-09-30 21:30:05.880134900 +0200
> @@ -2417,7 +2417,7 @@ vector_infos_manager::vector_infos_manag
>vector_antin = nullptr;
>vector_antout = nullptr;
>vector_earliest = nullptr;
> -  vector_insn_infos.safe_grow (get_max_uid ());
> +  vector_insn_infos.safe_grow_cleared (get_max_uid ());
>vector_block_infos.safe_grow (last_basic_block_for_fn (cfun));
>if (!optimize)
>  {

This patch fixes the build for me; have not tested it otherwise.

[Bug target/111649] [14 Regression] Bootstrap failure in stage 1 on riscv*-*-* since r14-4348-g9d249b7e31e

2023-09-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> This patch fixes the build for me; have not tested it otherwise.

Actually both need to be _cleared:
  vector_insn_infos.safe_grow_cleared (get_max_uid ());
  vector_block_infos.safe_grow_cleared (last_basic_block_for_fn (cfun));

[Bug target/111645] Intrinsics vec_sldb /vec_srdb fail with __vector unsigned __int128

2023-09-30 Thread munroesj at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111645

Steven Munroe  changed:

   What|Removed |Added

  Attachment #56018|0   |1
is obsolete||

--- Comment #2 from Steven Munroe  ---
Created attachment 56019
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56019&action=edit
Updated test case with static inline functions

[Bug target/111645] Intrinsics vec_sldb /vec_srdb fail with __vector unsigned __int128

2023-09-30 Thread munroesj at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111645

--- Comment #3 from Steven Munroe  ---
(In reply to Peter Bergner from comment #1)
> I see that we have created built-in overloads for signed and unsigned vector
> char through vector long long.  That said, the rs6000-builtins.def only
> seems to support the signed vector types though, which is why you're seeing
> an error.  So confirmed.
> 
> That said, I believe your 3rd argument needs to be a real constant integer,
> since the vsldbi instruction requires that.  It doesn't allow for a const
> int variable.  I notice some older (not trunk) gcc versions are ICEing with
> that, so another bug to look at.
The original code is static inline, so the const int parm should transfer
intact to the builtin const.

It seems I over-simplified the deduced test case.
> 
> I do not see any documentation that says we support the vector __int128
> type.  Where exactly did you see that?  However, from the instruction
> description, it seems like the hw instruction could support that.

I stand corrected. The documentation only describes vector unsigned long long.
But the instruction is like vsldoi and does not really care what the type is.

[Bug target/111649] [14 Regression] Bootstrap failure in stage 1 on riscv*-*-* since r14-4348-g9d249b7e31e

2023-09-30 Thread jakub at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649

--- Comment #6 from Jakub Jelinek  ---
(In reply to Andrew Pinski from comment #4)
> This patch fixes the build for me; have not tested it otherwise.

It will make stuff slower but more correct.
I think it is up to the riscv maintainers to decide what they want.

(In reply to Andrew Pinski from comment #5)
>   vector_block_infos.safe_grow_cleared (last_basic_block_for_fn (cfun));

Indeed.  While vector_block_info has defaulted default constructor, as its
members are vector_insn_info which have non-trivial default constructors, it
has non-trivial one as well.

[Bug target/111649] [14 Regression] Bootstrap failure in stage 1 on riscv*-*-* since r14-4348-g9d249b7e31e

2023-09-30 Thread patrick at rivosinc dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649

--- Comment #7 from Patrick O'Neill  ---
Thanks for the quick fix. Confirmed that changing both safe_grow ->
safe_grow_cleared resolves the bootstrap failure on rv64gc glibc.

Would it be possible to commit this fix as a stopgap (or rollback the assert)
until the riscv target maintainers decide what they want to do?

[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)

2023-09-30 Thread arsen at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org

--- Comment #9 from Arsen Arsenović  ---
interestingly, I reproduced this with '../gcc/configure --enable-languages=d
--disable-bootstrap' so, perhaps it's not just bootstrap4 that fails (though,
my host GCC is 13.. will try a 14 snapshot in a moment..)

[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)

2023-09-30 Thread arsen at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642

--- Comment #10 from Arsen Arsenović  ---
ah, yeah, seems that the common thread is checking.  my system compiler is
built with --enable-checking=yes,extra,rtl.

'make -j17 CXXFLAGS=-fno-checking' also seems to work around it

[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)

2023-09-30 Thread slyfox at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Sergei Trofimovich  ---
Proposed the possible fix as
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631739.html

It #ifdefs out any attempts to create multi-coefficient polynomials on the
system with a single polynomial like `poly_int<1, T>(1, 1)`.

[Bug d/111650] New: ICE in build_deref, at d/d-codegen.cc:1650

2023-09-30 Thread arsen at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111650

Bug ID: 111650
   Summary: ICE in build_deref, at d/d-codegen.cc:1650
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: arsen at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56020
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56020&action=edit
reduced reproducer, reduced from btdu

the attached code, with gdc -c , produces the following ICE:

~/gcc/d-ice$ /usr/x86_64-pc-linux-gnu/gcc-bin/14/gdc -c
reduced.reduced/btdu/sample.d
reduced.reduced/btdu/sample.d: In function ‘__lambda3’:
reduced.reduced/btdu/sample.d:12:22: internal compiler error: in build_deref,
at d/d-codegen.cc:1650
   12 | Root result;
  |  ^
0x55e60d72b7b0 build_deref(tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/d-codegen.cc:1650
0x55e60df1a6c6 declare_local_var(VarDeclaration*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/decl.cc:1637
0x55e60df1a9fd DeclVisitor::visit(VarDeclaration*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/decl.cc:850
0x55e60defff7f DeclVisitor::build_dsymbol(Dsymbol*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/decl.cc:254
0x55e60defff7f build_decl_tree(Dsymbol*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/decl.cc:1092
0x55e60df39c39 ExprVisitor::visit(DeclarationExp*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/expr.cc:1946
0x55e60df20560 build_expr(Expression*, bool, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/expr.cc:3025
0x55e60df21a8b build_expr_dtor(Expression*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/expr.cc:3048
0x55e60df29531 IRVisitor::visit(ExpStatement*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/toir.cc:1076
0x55e60df207ef IRVisitor::build_stmt(Statement*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/toir.cc:274
0x55e60df207ef IRVisitor::visit(CompoundStatement*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/toir.cc:1093
0x55e60df207ef IRVisitor::visit(CompoundStatement*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/toir.cc:1083
0x55e60df207ef IRVisitor::build_stmt(Statement*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/toir.cc:274
0x55e60df207ef IRVisitor::visit(CompoundStatement*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/toir.cc:1093
0x55e60df207ef IRVisitor::visit(CompoundStatement*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/toir.cc:1083
0x55e60df2088f IRVisitor::build_stmt(Statement*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/toir.cc:274
0x55e60df2088f build_function_body(FuncDeclaration*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/toir.cc:1505
0x55e60df1b271 DeclVisitor::visit(FuncDeclaration*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/decl.cc:1051
0x55e60defff7f DeclVisitor::build_dsymbol(Dsymbol*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/decl.cc:254
0x55e60defff7f build_decl_tree(Dsymbol*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230924/gcc-14-20230924/gcc/d/decl.cc:1092
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/d-ice 1 $ 

testcase reduced from https://github.com/CyberShadow/btdu

it is possible the reduction went awry, but the backtrace is identical before
and after reduction, so I hope it still homes in on the same bug

I've very little experience with D, so, apologies for the lack of analysis or
additional information.

[Bug target/111649] [14 Regression] Bootstrap failure in stage 1 on riscv*-*-* since r14-4348-g9d249b7e31e

2023-09-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Patrick O'Neill :

https://gcc.gnu.org/g:04e772bbdcbc1cea67cd498c1a45e4360bf5f8e1

commit r14-4351-g04e772bbdcbc1cea67cd498c1a45e4360bf5f8e1
Author: Patrick O'Neill 
Date:   Sat Sep 30 15:50:11 2023 -0700

RISC-V: Use safe_grow_cleared for vector info [PR111649]

Resolves a riscv*-*-* bootstrap failure due to a newly-turned-on assert.

2023-09-30  Jakub Jelinek  

gcc/ChangeLog:

PR target/111649

* config/riscv/riscv-vsetvl.cc
(vector_infos_manager::vector_infos_manager):
Replace safe_grow with safe_grow_cleared.

[Bug ipa/111643] __attribute__((flatten)) with -O1 runs out of memory (killed cc1)

2023-09-30 Thread lukas.graetz--- via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643

--- Comment #4 from Lukas Grätz  ---
Sorry, just to clarify, whether I understood your two comments correctly.
Should foo() be inlined in the following example because flatten works
recursively?

void foo (void) {
// CODE
}

int bar_original (void) {
// CODE
foo();
// CODE
}

__attribute__((flatten))
int bar (void) {
// INSTRUMENTATION CAN GO HERE
return bar_original();
}

I thought that according to the documentation of flatten, foo() would not be
affected by the flatten attribute of bar(). It says: "For a function marked
with this attribute, every call inside this function is inlined, if possible."
The call to foo() is not directly inside the function bar(). Only if
bar_original() had also the __attribute__((flatten)), I would expect foo() to
be made inline in bar() because of recursive flatten. Of course, it could still
be inlined because some heuristics...

[Bug ipa/111643] __attribute__((flatten)) with -O1 runs out of memory (killed cc1)

2023-09-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #5 from Andrew Pinski  ---
>It says: "For a function marked with this attribute, every call inside this 
>function is inlined, if possible." The call to foo() is not directly inside 
>the function bar().

The definition of "every call" is definitely ambious in the documentation. It
could mean every mentioned call or it could mean recusively every call. In this
case, it means flatten all calls including ones called from other functions
("indirectly"). It was originally added to workaround some (not so good)
inlining heurstics at the time for some C++ code (early 2000s).  inlining
heurstics has changed since then and has gotten better over the years so folks
don't use it as much.

Also if you have any code where GCC's inlining heurstics does not do what you
think it should please file that so we can improve them instead of workarounds
like always_inline and flatten don't need to be used ...

[Bug bootstrap/110180] On Fedora 38, egrep is now obsolescent

2023-09-30 Thread sjames at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110180

Sam James  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org

--- Comment #3 from Sam James  ---
I think this one got fixed with the top-level syncing arsen did?

[Bug target/111566] RISC-V Vector Fortran: ICE in final_scan_insn_1 (final RTL pass)

2023-09-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111566

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Joern Rennecke :

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

commit r14-4353-gf416a3fdbee32ae12b055b8e3e4ee11c3df7c117
Author: Joern Rennecke 
Date:   Sun Oct 1 06:13:37 2023 +0100

Make riscv_vector::legitimize_move adjust SRC in the caller.

2023-09-29  Joern Rennecke  
Juzhe-Zhong  

PR target/111566

gcc/
* config/riscv/riscv-protos.h (riscv_vector::legitimize_move):
Change second parameter to rtx *.
* config/riscv/riscv-v.cc (risv_vector::legitimize_move): Likewise.
* config/riscv/vector.md: Changed callers of
riscv_vector::legitimize_move.
(*mov_mem_to_mem): Remove.

gcc/testsuite/

* gcc.target/riscv/rvv/autovec/vls/mov-1.c: Adapt test.
* gcc.target/riscv/rvv/autovec/vls/mov-10.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/mov-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/mov-5.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/mov-7.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/mov-8.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/mov-9.c: Ditto.1
* gcc.target/riscv/rvv/autovec/vls/mov-2.c: Removed.
* gcc.target/riscv/rvv/autovec/vls/mov-4.c: Removed.
* gcc.target/riscv/rvv/autovec/vls/mov-6.c: Removed.
* gcc.target/riscv/rvv/fortran/pr111566.f90: New test.

Co-Authored-By: Juzhe-Zhong

[Bug middle-end/111646] cos function giving different result for the same input value

2023-09-30 Thread vishwambhar.rathi at puresoftware dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111646

--- Comment #4 from vishwambhar.rathi at puresoftware dot com ---
I am not using any optimization flag in compiling. Where should I post about
this bug? Thanks.

From: xry111 at gcc dot gnu.org 
Sent: 30 September 2023 19:48
To: Vishwambhar Rathi 
Subject: [Bug middle-end/111646] cos function giving different result for the
same input value

[You don't often get email from gcc-bugzi...@gcc.gnu.org. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #3 from Xi Ruoyao  ---
Are you compiling with optimization?  If you are not enabling any optimization,
the result of cos actually comes from Glibc and it's not a GCC issue.

--
You are receiving this mail because:
You reported the bug.