date:20221026

[Bug c/105581] new warning about boolean types and relational operators

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c/105581] new warning about boolean types and relational operators

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||87403
Summary|boolean types and   |new warning about boolean
   |relational operators|types and relational
   |problem |operators

--- Comment #5 from Andrew Pinski  ---
This is just a style issue really ...


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug target/96544] ICE in simplify_gen_subreg_concatn, at lower-subreg.c:717

2022-10-26 Thread linkw at gcc dot gnu.org via Gcc-bugs

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

Kewen Lin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-10-27
 Ever confirmed|0   |1
 CC||linkw at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #2 from Kewen Lin  ---
The bisection shows this issue was gone since r12-4428 (for fixing PR102682),
not sure if we want this to be backport-ed, CC Richi.

[Bug rtl-optimization/90259] ICE: verify_flow_info failed (error: missing REG_EH_REGION note at the end of bb 4)

2022-10-26 Thread linkw at gcc dot gnu.org via Gcc-bugs

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

Kewen Lin  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-27
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
 CC||linkw at gcc dot gnu.org

--- Comment #2 from Kewen Lin  ---
I'm going to do bisection to see which commit makes this pass, but it's weird
that even with the mentioned snapshot r270485, I still can't reproduce this.

[Bug c++/83167] decltype((x)) inside lambda is considered odr-use if x is not a reference

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Andrew Pinski  ---
I might have seen a dup of this bug before.

[Bug c++/104358] signature of template function with template lambda(converted to function pointer) mistakenly regards it as type of "int"

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||107430
   Keywords||c++-lambda, rejects-valid,
   ||wrong-code

--- Comment #3 from Andrew Pinski  ---
There is a definitely a few dups of this bug.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430
[Bug 107430] [meta-bug] lambda in decltype

[Bug c++/107430] New: [meta-bug] lambda in decltype

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 107430
   Summary: [meta-bug] lambda in decltype
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: c++-lambda, meta-bug, rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

I noticed there are many issues with lambda inside a decltype issues.
Especially dealing with template alias.

[Bug c++/105583] Syntax error when alias template in requires-clause

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug c++/105583] Syntax error when alias template in requires-clause

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||c++-lambda

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

[Bug target/107357] [RISC-V]RVV broken with zve32x/f

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/105558] [10 Regression] simple 8-bit integer calculation fails with -O3 / march=core-avx2 on some gfortran 8/9/10 versions

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|simple 8-bit integer|[10 Regression] simple
   |calculation fails with -O3  |8-bit integer calculation
   |/ march=core-avx2 on some   |fails with -O3 /
   |gfortran 8/9/10 versions|march=core-avx2 on some
   ||gfortran 8/9/10 versions
  Known to work||7.3.0
  Known to fail||8.1.0
   Target Milestone|--- |10.5
   Keywords||needs-bisection

--- Comment #6 from Andrew Pinski  ---
Would be interesting to find what patch broke this and what patch fixed the
-mtune=generic case.

[Bug target/107357] [RISC-V]RVV broken with zve32x/f

2022-10-26 Thread jiawei at iscas dot ac.cn via Gcc-bugs

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

jiawei  changed:

   What|Removed |Added

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

--- Comment #3 from jiawei  ---
Fixed.

[Bug target/107357] [RISC-V]RVV broken with zve32x/f

2022-10-26 Thread jiawei at iscas dot ac.cn via Gcc-bugs

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

--- Comment #2 from jiawei  ---
Verified, Thanks!

[Bug tree-optimization/105558] simple 8-bit integer calculation fails with -O3 / march=core-avx2 on some gfortran 8/9/10 versions

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Martin Liška from comment #4)
> Fixed on master with r11-3718-g91ae6930ed4a87d7.

If anything that just made the issue latent I suspect.

[Bug driver/105568] [13 Regression] Superfluous --jobserver-auth= check taints further diagnostics

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/105616] Using regex_replace throws "maybe-uninitialized" warnings with -fsanitize=address

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Andrew Pinski  ---
Most likely -fsanitize=address is confusing things. There are a few other bugs
which talk about -fsanitize=address and -Wuninitialized interactions too.

[Bug rtl-optimization/101806] Extra zero extends for some arguments in some cases

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Andrew Pinski  ---
I think this will be fixed/improved by
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602089.html .

[Bug c++/64989] constant-initialization of self-referencing array

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

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

[Bug c++/105619] Wrong "used in its own initializer" with class prvalue

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Yes this is a dup of bug 64989.

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

[Bug target/105162] [9/10/11/12/13 Regression] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[AArch64] outline-atomics   |[9/10/11/12/13 Regression]
   |drops dmb ish barrier on|[AArch64] outline-atomics
   |__sync builtins |drops dmb ish barrier on
   ||__sync builtins
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=65697

--- Comment #15 from Andrew Pinski  ---
This was a regression as outline is the default on most aarch64 targets.

[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.5
  Known to work||10.4.0, 12.2.0, 9.5.0
  Known to fail||10.3.0, 12.1.0, 9.4.0

[Bug target/105627] -fcompare-debug failure at -Og for powerpc64le-unknown-linux-gnu

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
  Component|debug   |target

[Bug debug/107414] dwarf 5 C macro support

2022-10-26 Thread simon.marchi at polymtl dot ca via Gcc-bugs

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

Simon Marchi  changed:

   What|Removed |Added

 CC||simon.marchi at polymtl dot ca

--- Comment #5 from Simon Marchi  ---
The original reproducer Ulrich gave indeed seems like what was fixed in GDB
master recently.  Macros in the main source file didn't work with DWARF 5. 
That works fine now.

But he pointed me to a real-life case in gawk, where it didn't work:

https://sourceware.org/bugzilla/show_bug.cgi?id=29725#c2

That seems to highlight a new problem, that is the use of macros combined with
#line directives.  I don't think that the debug info is sufficient for GDB to
figure this out.

For convenience, here's a copy of what I posted on the GDB bug.

---

With a simple case, it works as expected:

$ cat test.c
#define FOO 2
int main() { return FOO; }
$ gcc test.c -g3 -O0
$ ./gdb --data-directory=data-directory -nx -q -iex "set debuginfod enabled
off" ./a.out -ex start -ex "info macro FOO" -batch
...
Defined at /home/simark/build/binutils-gdb/gdb/test.c:1
#define FOO 2

But then if you add a line control directive, like you have for a .c file
generated from a .y file:
$ cat test.c
#define FOO 2
#line 17 "potato.c"
int main() { return FOO; }
$ gcc test.c -g3 -O0
$ ./gdb --data-directory=data-directory -nx -q -iex "set debuginfod enabled
off" ./a.out -ex start -ex "info macro FOO" -batch
...
The symbol `FOO' has no definition as a C/C++ preprocessor macro
at /home/simark/build/binutils-gdb/gdb/test.c:-1

Looking at the macro debug info (my annotations after the #s):

$ readelf --debug-dump=macro a.out

 DW_MACRO_import - offset : 0x20 # built-in macros
 DW_MACRO_start_file - lineno: 0 filenum: 2 # test.c
 DW_MACRO_start_file - lineno: 0 filenum: 3 # stdc-predef.h
 DW_MACRO_import - offset : 0x900 # STDC macros
 DW_MACRO_end_file # end of stdc-predef.h
 DW_MACRO_define_strp - lineno : 1 macro : FOO 2
<--- here
 DW_MACRO_end_file # end of test.c

The line table tells GDB that the current PC is in potato.c, line 17:

CU: ./test.c:
File nameLine numberStarting addressView   
Stmt
potato.c  17  0x1119   
   x
potato.c  17  0x111d   
   x
potato.c  17  0x1122   
   x
potato.c   -  0x1124

But GDB has no way to figure out where this is in the macro inclusion tree, as
potato.c is never represented in there.  Ideally, GDB would figure out that we
are where I maked `here`, above.

Looking at the DWARF opcodes for macro, I don't really see a way to describe
the #line stuff.  There's only DW_MACRO_start_file, which represents the
inclusion of a complete file.

[Bug c++/105631] GCC internal compiler error: Segmentation fault when trying to compile Qt 6.3

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=105725

--- Comment #4 from Andrew Pinski  ---
No preprocessed source in over 5 months.
Also this is most likely a dup of bug 105725 which is fixed in GCC 12.2.0.

[Bug c/61469] language feature: Support for enum underlying type

2022-10-26 Thread jsm28 at gcc dot gnu.org via Gcc-bugs

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #10 from Joseph S. Myers  ---
I'm working on implementing this C2x feature for GCC 13.

[Bug tree-optimization/105646] g++ does not raise "xxx may be used uninitialized" warning on dead code when optimizing

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug rtl-optimization/105653] [10/11/12/13 Regression] '-fcompare-debug' failure w/ -O2

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
IRA adds the REG_EQUIV note even for both with/without -g.

But it was removed in peephole2 for -g case.
In the -g case we get the following extra output in -g for peephole2 starting
with:

df_worklist_dataflow_doublequeue: n_basic_blocks 8 n_edges 10 count 9 (  1.1)

DCE: Deleting insn 15
deleting insn with uid = 15.
...

insn 15 was:
(insn:TI 15 13 16 2 (set (reg/f:DI 1 x1 [101])
(plus:DI (reg/f:DI 0 x0 [orig:99 thisD.4083 ] [99])
(const_int 8 [0x8]))) "/app/example.cpp":9:25 discrim 1 141
{*adddi3_aarch64}
 (expr_list:REG_UNUSED (reg/f:DI 1 x1 [101])
(nil)))

in sched_fusion.

But in the -g0 case, it was not removed inside peephole2.

Someone who understands DF DCE better should look into this on why it was not
removed inside peephole2 without -g.

The instruction without -g:
(insn:TI 8 3 9 2 (set (reg/f:DI 1 x1 [101])
(plus:DI (reg/f:DI 0 x0 [orig:99 this ] [99])
(const_int 8 [0x8]))) "/app/example.cpp":9:25 discrim 1 141
{*adddi3_aarch64}
 (expr_list:REG_UNUSED (reg/f:DI 1 x1 [101])
(nil)))

Which looks exactly the same even.

[Bug fortran/107426] [12/13 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636

2022-10-26 Thread kargl at gcc dot gnu.org via Gcc-bugs

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
I don't see this on x86_64-*-freebsd, but I also build with
--enable-checking=yes which may or may not mask issues.  I'll note that running
valgrind on `f951 a.f90` yields a long listing which starts with

Error: END INTERFACE statement expected at (1)
==81746== Invalid read of size 8
==81746==at 0x899905: gfc_find_typebound_intrinsic_op(gfc_symbol*, bool*,
gfc_intrinsic_op, bool, locus*) (class.cc:3023)
==81746==by 0x8CDED8: matching_typebound_op(gfc_expr**,
gfc_actual_arglist*, gfc_intrinsic_op, char const*, char const**)
(interface.cc:4415)
==81746==by 0x8CE72C: gfc_extend_assign(gfc_code*, gfc_namespace*)
(interfac

probably not a good thing.

[Bug fortran/107423] ICE in parse_spec, at fortran/parse.cc:4017

2022-10-26 Thread kargl at gcc dot gnu.org via Gcc-bugs

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-10-27
 Status|UNCONFIRMED |NEW
   Priority|P3  |P4
 Ever confirmed|0   |1
   Keywords|ice-on-valid-code   |ice-on-invalid-code
 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
It is actually an ICE on invalid code as type-params were added in F2008 or
F2018.  This is an ICE caused by run-on errors where a NULL pointer is
dereferenced.  Fixed by

diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index 5b13441912a..25b987c7bef 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -3994,7 +3994,7 @@ parse_spec (gfc_statement st)
   gfc_symbol* proc = gfc_current_ns->proc_name;
   gcc_assert (proc);

-  if (proc->result->ts.type == BT_UNKNOWN)
+  if (proc->result && proc->result->ts.type == BT_UNKNOWN)
function_result_typed = true;
 }

[Bug rtl-optimization/105661] Comparisons to atomic variables generates less efficient code

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1) 
> Basically we don't optimize anything related to volatile memory even into
> the address part. This is basically PR 50677 really.

I should say internally for RTL level we do atomic loads as volatile memory.

(insn 5 4 0 (set (reg:QI 83 [ _5 ])
(mem/v:QI (symbol_ref:DI ("atomic") [flags 0x2]  ) [-1  S1 A8]))
"/opt/compiler-explorer/gcc-trunk-20221026/include/c++/13.0.0/bits/atomic_base.h":505:24
-1
 (nil))

[Bug rtl-optimization/105661] Comparisons to atomic variables generates less efficient code

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||50677
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Severity|normal  |enhancement
  Component|target  |rtl-optimization
   Last reconfirmed||2022-10-26

--- Comment #1 from Andrew Pinski  ---
The aarch64 issue is not really a big difference but it is the same issue
really.

Basically we don't optimize anything related to volatile memory even into the
address part. This is basically PR 50677 really.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50677
[Bug 50677] volatile forces load into register

[Bug rtl-optimization/105686] [10/11/12/13 Regression] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 8 with -fnon-call-exceptions

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Martin Liška from comment #2)
> Btw. 2092f134b7180cd2542cff93bd8a876b3e59a77b revision made it visible.

r10-358-g2092f134b7180c

[Bug debug/107414] dwarf 5 C macro support

2022-10-26 Thread drepper.fsp+rhbz at gmail dot com via Gcc-bugs

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

--- Comment #4 from Ulrich Drepper  ---
Actually, Jakub was right.  This is a gdb issue.  The gdb maintainers pointed
me to the trunk version and this indeed works with this simple code sequence. 
There might have been a bug as in 107012 but even after that fix gdb didn't
handle the dwarf data correctly before a recent commit.

[Bug c++/107428] trying to define a partial specialized concept does not give a good error message

2022-10-26 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug target/99435] avr: incorrect I/O address ranges for some cores

2022-10-26 Thread gjl at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Georg-Johann Lay  ---
I am really confused.

To all of my knowledge, IN and OUT can address a range of 64 bytes.  For
example, the opcode of OUT is

1011 1AAr  

where "r" bits encode for the register number (2^5 = 32 of them) and "A" bits
encode absolute target addresses (2^6 = 64 of them). So there isn't even enough
space in the instruction encoding to provide an address range as clained by
this PR.

Similar for, say, SBI with opcode encoding

1011 1010  Abbb

where "A" bits encode for absolute target address (2^5 = 32 of them) and "b"
encode target bit number (2^3 = 8 of them).

Are you sure you didn't just stumble upon a typo in the data sheet?

All AVRs are using these encodings.  The only difference is between Xmega and
non-Xmega which use different, implicit SFR_OFFSETs (which don't affect the
encoding or the number of address that can be encoded).

[Bug c++/107429] New: misdiagnosed "constraint depends on itself" in overloaded functions

2022-10-26 Thread jwjagersma at gmail dot com via Gcc-bugs

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

Bug ID: 107429
   Summary: misdiagnosed "constraint depends on itself" in
overloaded functions
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwjagersma at gmail dot com
  Target Milestone: ---

Given the following code:

  struct tag_foo { } inline constexpr foo;
  struct tag_bar { } inline constexpr bar;

  template
  auto f(tag_foo, T... x)
  {
return (x + ...);
  }

  template
  concept fooable = requires (T... x) { f(foo, x...); };

  template requires (fooable)
  auto f(tag_bar, T... x)
  {
return f(foo, x...);
  }

  auto test()
  {
return f(bar, 1, 2, 3);
  }

g++ claims that "satisfaction of atomic constraint [...] depends on itself",
but the overload of 'f()' that is checked by 'fooable' is not constrained in
any way.

I am not 100% sure if this is valid code, but clang and msvc do not make the
same complaint, so I'm inclined to believe g++ is in error here.

[Bug c++/107428] New: trying to define a partial specialized concept does not give a good error message

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 107428
   Summary: trying to define a partial specialized concept does
not give a good error message
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
template
concept same = false;
template
concept same = true;
```

GCC produces:
```
:6:13: error: expected '=' before '<' token
6 | concept same = true;
  | ^
```

While clang produces:
```
:6:9: error: name defined in concept definition must be an identifier
concept same = true;
^
```

While clang is definitely better than GCC. We could do even better at
sugguesting you can't do a partial specialization of a concept.

[Bug fortran/103474] ICE in simplify_cobound, at fortran/simplify.c:4415

2022-10-26 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
I am now stuck with the following code, which I believe is valid.
(It is accepted by Crayftn and rejected by Intel, but I thought it is
covered by F2018:5.4.7(5)):

program p
  type t
 integer :: a(1,2)
  end type
  class(t), allocatable :: x[:]
  print *, ucobound (x%a)
end

The problem I have is that gfc_conv_expr_descriptor invokes walk_coarray,
but the result depends on the rank of the array a in type t.
The comment before walk_coarray states:

/* Convert the last ref of a scalar coarray from an AR_ELEMENT to an
   AR_FULL, suitable for the scalarizer.  */

However, we should find a way to only extract the "co-descriptor".
We might also need that when implement COSHAPE.

[Bug c++/105693] Requires-clause constructor that is deleted is not overriding the "= default" one

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Requires-clause constructor |Requires-clause constructor
   |is not selected |that is deleted is not
   ||overriding the "= default"
   ||one

--- Comment #2 from Andrew Pinski  ---
Note the Requires-clause constructor is selected as you can see if you do:
```
template
constexpr bool same = true;

template
struct A {
A() = default;
A() requires (same){};
};

A a;
```
And see a constructor is called. Just that the "= delete" is not being
rejected.

[Bug c++/105693] Requires-clause constructor is not selected

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed. reduced testcase without includes:
```
template
constexpr bool same = false;
template
constexpr bool same = true;

template
struct A {
A() = default;
A() requires (same) = delete;
};

A a;
```

[Bug target/103975] DWARF .debug_frame incorrect for ISRs on AVR; pushing SREG creates off-by-one error

2022-10-26 Thread gjl at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Georg-Johann Lay  ---
If someone is going to fix this, the following changes might also play a role:

* v8+ may emit optimized ISR prologues / epilogues using PR81268: gcc will just
emit pseudo-instruction __gcc_isr which will be resolved by gas.  Debug info
might be incorrect or missing; gas would have to add respective debug info.

* v12+ PR92729 changed condition code from implicit cc0 to explicit REG_CC and
introduced a new hard register "cc" with hard register number REG_CC = 36. The
highest hard regno before that transition was 35.

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

2022-10-26 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

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

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

commit r13-3513-gf7d28818179247685f3c101f9f2f16366f56309b
Author: Harald Anlauf 
Date:   Wed Oct 26 21:00:44 2022 +0200

Fortran: BOZ literal constants are not compatible to any type [PR103413]

gcc/fortran/ChangeLog:

PR fortran/103413
* symbol.cc (gfc_type_compatible): A boz-literal-constant has no
type
and thus is not considered compatible to any type.

gcc/testsuite/ChangeLog:

PR fortran/103413
* gfortran.dg/illegal_boz_arg_4.f90: New test.

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

2022-10-26 Thread sgk at troutmask dot apl.washington.edu via Gcc-bugs

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

--- Comment #15 from Steve Kargl  ---
On Wed, Oct 26, 2022 at 07:22:47PM +, anlauf at gcc dot gnu.org wrote:
>  Status|NEW |ASSIGNED
> 
> --- Comment #14 from anlauf at gcc dot gnu.org ---
> Submitted: https://gcc.gnu.org/pipermail/fortran/2022-October/058384.html
> 

Looks good to me.  I think you can commit.

[Bug tree-optimization/107427] ICE Segmentation fault when -O1 -fdisable-tree-lower -fdisable-tree-eh is given

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
You cannot disable these passes and not have crashes.

The -fdisable- option is documented:
These options are intended for use for debugging GCC.

[Bug tree-optimization/107427] New: ICE Segmentation fault when -O1 -fdisable-tree-lower -fdisable-tree-eh is given

2022-10-26 Thread volker.weissmann at gmx dot de via Gcc-bugs

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

Bug ID: 107427
   Summary: ICE Segmentation fault when -O1 -fdisable-tree-lower
-fdisable-tree-eh is given
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: volker.weissmann at gmx dot de
  Target Milestone: ---

$ cat main.c
void func(){}

$ gcc -c main.c -O1 -fdisable-tree-lower -fdisable-tree-eh
cc1: note: disable pass tree-lower for functions in the range of [0,
4294967295]
cc1: note: disable pass tree-eh for functions in the range of [0, 4294967295]
during GIMPLE pass: local-pure-const
main.c: In function ‘func’:
main.c:1:1: internal compiler error: Segmentation fault
1 | void func(){}
  | ^~~~
0x1840d78 internal_error(char const*, ...)
???: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
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC)

[Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang

2022-10-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Just use the attribute, I'd prefer not to add the builtin, especially when
clang makes it pretty much useless (as it warns about side-effects in the arg,
doesn't evaluate them and ignores it completely in that case).

[Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Andrew Pinski  ---
Now the assume for C++23's assume attribute has been added, adding this builtin
should be straight forward I think.

Because the builtin is exactly the same as the attribute in that the expression
supplied to the builtin would not execute for side effects.

[Bug fortran/107426] [12/13 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636

2022-10-26 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

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

Adding an ,only to any of the use, intrinsic :: iso_c_binding statements
avoids the ICE.

However, I get an ICE down to gcc-7, so I am not sure that the reported
regression is accurate.

[Bug target/93177] PPC: Missing many useful platform intrinsics

2022-10-26 Thread iains at gcc dot gnu.org via Gcc-bugs

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

--- Comment #21 from Iain Sandoe  ---
(In reply to Segher Boessenkool from comment #18)
> (In reply to Sergey Fedorov from comment #16)
> > For Darwin, PPC intrinsics already is there in Apple headers. Can it be
> > added into current GCC?
> 
> If it is in the Apple headers already, why would you need a separate copy
> in GCC?

it's an internal header in apple-gcc-4.x so not accessible to end users unless
using those compiles (nor usable like  by GCC for example).

Some projects appear to depend on it (whether broken or not)...
.. but I'd welcome some persuasive evidence that it does make things better.

[Bug target/93177] PPC: Missing many useful platform intrinsics

2022-10-26 Thread iains at gcc dot gnu.org via Gcc-bugs

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

--- Comment #20 from Iain Sandoe  ---
the patch above does not seek to answer questions on validity - it simply
publishes the same header that was made available in the darwin toolchains (so
will be neither better nor worse than that)>

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

2022-10-26 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-October/058384.html

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

2022-10-26 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

--- Comment #13 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #12)
> > pr103413-boz.f90:4:6:
> > 
> > 4 |   r = z'1234'
> >   |  1
> > Error: BOZ literal constant at (1) is neither a DATA statement value nor an
> > actual argument of INT/REAL/DBLE/CMPLX intrinsic subprogram [see
> > '-fno-allow-invalid-boz']
> 
> This I need to look up in F2023.  The statement may be allowed
> only in an initialization expression.

Given that F2023 is not yet official, I'd say we defer that.
Maybe open a new (Meta-)PR that collects or references the new features.

Oh boy, there's still a lot of F2018 that needs implementing...

[Bug c++/107422] [12/13 Regression] ICE in lvalue_kind, at cp/tree.cc:293

2022-10-26 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-26
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Priority|P3  |P5
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed with -fno-pretty-templates.

[Bug target/93177] PPC: Missing many useful platform intrinsics

2022-10-26 Thread iains at gcc dot gnu.org via Gcc-bugs

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

--- Comment #19 from Iain Sandoe  ---
Created attachment 53779
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53779&action=edit
introduce ppc_intrinsics.h for powerpc*-darwin.

This takes the header from the GCC-4.x apple debt branch (as present in SVN:
r113478) and 
 - updates the license.
 - installs for powerpc*-darwin

It needs the test cases forward porting too.
However, it would be good to know if this solves the problems folks have
encountered here (if other ports want to try it, why only need to amend their
entry in gcc/config.gcc)

[Bug c++/106393] Add warnings for common dangling problems

2022-10-26 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
The first test in the original post is now diagnosed.  The rest may have to be
implemented in the analyzer.  I'm not sure if I should close the BZ.

[Bug c++/106393] Add warnings for common dangling problems

2022-10-26 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r13-3511-gd2249cd9adf5ae638577139177a50f7e62d8abd9
Author: Marek Polacek 
Date:   Fri Oct 14 10:05:57 2022 -0400

c++: Implement -Wdangling-reference [PR106393]

This patch implements a new experimental warning (enabled by -Wall) to
detect references bound to temporaries whose lifetime has ended.  The
primary motivation is the Note in
:

  Capturing the result of std::max by reference produces a dangling
reference
  if one of the parameters is a temporary and that parameter is returned:

  int n = 1;
  const int& r = std::max(n-1, n+1); // r is dangling

That's because both temporaries for n-1 and n+1 are destroyed at the end
of the full expression.  With this warning enabled, you'll get:

g.C:3:12: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
3 | const int& r = std::max(n-1, n+1);
  |^
g.C:3:24: note: the temporary was destroyed at the end of the full
expression 'std::max((n - 1), (n + 1))'
3 | const int& r = std::max(n-1, n+1);
  |^~

The warning works by checking if a reference is initialized with a function
that returns a reference, and at least one parameter of the function is
a reference that is bound to a temporary.  It assumes that such a function
actually returns one of its arguments!  (I added code to check_return_expr
to suppress the warning when we've seen the definition of the function
and we can say that it can return a variable with static storage
duration.)

It warns when the function in question is a member function, but only if
the function is invoked on a temporary object, otherwise the warning
would emit loads of warnings for valid code like obj.emplace({0}, 0).
It does detect the dangling reference in:

  struct S {
const S& self () { return *this; }
  };
  const S& s = S().self();

It warns in member initializer lists as well:

  const int& f(const int& i) { return i; }
  struct S {
const int &r;
S() : r(f(10)) { }
  };

I've run the testsuite/bootstrap with the warning enabled by default.
There were just a few FAILs, all of which look like genuine bugs.
A bootstrap with the warning enabled by default passed as well.

When testing a previous version of the patch, there were many FAILs in
libstdc++'s 22_locale/; all of them because the warning triggered on

  const test_type& obj = std::use_facet(std::locale());

but this code looks valid -- std::use_facet doesn't return a reference
to its parameter.  Therefore I added a #pragma and code to suppress the
warning.

PR c++/106393

gcc/c-family/ChangeLog:

* c.opt (Wdangling-reference): New.

gcc/cp/ChangeLog:

* call.cc (expr_represents_temporary_p): New, factored out of...
(conv_binds_ref_to_temporary): ...here.  Don't return false just
because a ck_base is missing.  Use expr_represents_temporary_p.
(do_warn_dangling_reference): New.
(maybe_warn_dangling_reference): New.
(extend_ref_init_temps): Call maybe_warn_dangling_reference.
* cp-tree.h: Adjust comment.
* typeck.cc (check_return_expr): Suppress -Wdangling-reference
warnings.

gcc/ChangeLog:

* doc/invoke.texi: Document -Wdangling-reference.

libstdc++-v3/ChangeLog:

* include/bits/locale_classes.tcc: Add #pragma to disable
-Wdangling-reference with std::use_facet.

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/elision4.C: Use -Wdangling-reference, add
dg-warning.
* g++.dg/cpp23/elision7.C: Likewise.
* g++.dg/warn/Wdangling-pointer-2.C: Use -Wno-dangling-reference.
* g++.dg/warn/Wdangling-reference1.C: New test.
* g++.dg/warn/Wdangling-reference2.C: New test.
* g++.dg/warn/Wdangling-reference3.C: New test.

[Bug c++/95148] -Wtype-limits always-false warning triggered despite comparison being avoided

2022-10-26 Thread eyalroz1 at gmx dot com via Gcc-bugs

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

--- Comment #4 from Eyal Rozenberg  ---
(In reply to Jonathan Wakely from comment #3)

> > I should not be getting this warning, because when x is unsigned, the
> > comparison is never performed, due to the short-circuit semantics of `and`.
> 
> Those semantics only apply at runtime.

But the semantics are known at compile time, and so are the argument values.

> > No less
> > importantly, the author of such a line in a program clearly specified
> > his/her intent here with this check. 
> 
> But `x && y` doesn't prevent y being instantiated, it only prevents it being
> evaluated at runtime.

You mean, it only prevents a comparison of an unsigned and signed values to
actually ever being carried out? Yeah :-)


> >   a.cpp:5:52: warning: comparison of unsigned expression < 0 is always false
> > [-Wtype-limits]
> 
> Both branches of the condition must be instantiated by the compiler, and so
> this warning (which happens in the front-end, not after optimizing the AST)
> gets triggered.

Well, that's a bug. If you're saying that the front-end produces the warning,
then delay it to a later stage, in which you can figure out whether the warning
is called for. 

clang doesn't produce this warning.

> I think to avoid this warning the front end would have to disable this
> particular warning for branches that depend on a compile-time constant. I
> don't know if that's currently possible in GCC.

Ok, I didn't say that the solution would be easy...

[Bug c++/107417] g++ fails to recognize parameter pack in requires-expression

2022-10-26 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

2022-10-26 Thread sgk at troutmask dot apl.washington.edu via Gcc-bugs

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

--- Comment #12 from Steve Kargl  ---
On Wed, Oct 26, 2022 at 06:24:04PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413
> 
> --- Comment #11 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #10)
> > Well, a boz is typeless, so it cannot be compatible with any other type.
> > So, I would assume, you could do 
> > 
> > if (ts1->type == BT_BOZ || ts2->type == BT_BOZ)
> >return false;
> 
> Yes, that's better.
> 
> > There is a caveat in that Fortran 2023 is going to allow
> > things like
> > 
> > real :: x = z'1234'
> > 
> > if gfc_type_compatible is used in simple assignments, gfortran will
> > need to deal with that.
> 
> It is currently not used in those cases.

Hmmm, I wonder if there is duplicate code within gfortran
that re-implements gfc_type_compatible.  If time permits, 
I'll see what comes with a grep of "->type == *->type".


> The following is already rejected:
> 
> program p
>   real :: r
>   data r / z'1234' /
>   r = z'1234'
>   print *, r
> end
> 
> pr103413-boz.f90:3:18:
> 
> 3 |   data r / z'1234' /
>   |  1
> Error: BOZ literal constant near (1) cannot be assigned to a REAL variable 
> [see
> '-fno-allow-invalid-boz']

F2018

If a data-stmt-constant is a boz-literal-constant, the corresponding
variable shall be of type integer.

F2023 is unchanged.

> pr103413-boz.f90:4:6:
> 
> 4 |   r = z'1234'
>   |  1
> Error: BOZ literal constant at (1) is neither a DATA statement value nor an
> actual argument of INT/REAL/DBLE/CMPLX intrinsic subprogram [see
> '-fno-allow-invalid-boz']

This I need to look up in F2023.  The statement may be allowed
only in an initialization expression.

> Interestingly, -fno-allow-invalid-boz is not an allowed option...
> But even when using -fallow-invalid-boz, which degrades the above
> to a warning, I never get to gfc_type_compatible.

The lack of -fno-allow-invalid-boz was intentional.  A BOZ in
an invalid context is an error.  -fallow-invalid-boz allows
that invalid context, but issues a warning.  The only way to
disable the warning is with -w (ie., you disable all warnings).

[Bug tree-optimization/107413] Perf loss ~14% on 519.lbm_r SPEC cpu2017 benchmark

2022-10-26 Thread rvmallad at amazon dot com via Gcc-bugs

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

--- Comment #3 from Rama Malladi  ---
I will get the effect of this revert for the overall SPEC FP score. I haven't
tried experimenting with fp_reassoc_width values. Will try it and update.

[Bug analyzer/106703] during IPA pass: analyzer ICE: error reporting routines re-entered. with -fanalyzer -fsanitize-address-use-after-scope -fsanitize=kernel-address -fdiagnostics-format=sarif-stderr

2022-10-26 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from David Malcolm  ---
Looks like a dup of 107366; possibly fixed by
r13-3469-g2e8a0553918adc919f98ac5c0224fc6ce1fef68d.

[Bug fortran/107426] New: [12/13 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636

2022-10-26 Thread gscfq--- via Gcc-bugs

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

Bug ID: 107426
   Summary: [12/13 Regression] ICE in gfc_compare_derived_types,
at fortran/interface.cc:636
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210905 and 20210919 :


$ cat z1.f90
module m
contains
   subroutine p() bind(c)
  use, intrinsic :: iso_c_binding
  integer, target :: a = 1
  type(c_ptr) :: z
  interface
 subroutine s(x) bind(cc)   !!
use, intrinsic :: iso_c_binding
integer(c_int), value :: x
 end
  end interface
  z = c_loc(a)
  call s(z)
   end
end


$ gfortran-13-20221023 -c z0.f90   # corrected cc -> c at marker !!
z0.f90:14:15:

   14 |   call s(z)
  |   1
Error: Type mismatch in argument 'x' at (1); passed TYPE(c_ptr) to INTEGER(4)


$ gfortran-13-20221023 -c z1.f90
z1.f90:8:32:

8 |  subroutine s(x) bind(cc)   !!
  |1
Error: Missing closing paren for binding label at (1)
z1.f90:9:43:

9 | use, intrinsic :: iso_c_binding
  |   1
Error: Unexpected USE statement in INTERFACE block at (1)
z1.f90:10:38:

   10 | integer(c_int), value :: x
  |  1
Error: Unexpected data declaration statement in INTERFACE block at (1)
z1.f90:11:12:

   11 |  end
  |1
Error: END INTERFACE statement expected at (1)
f951: internal compiler error: Segmentation fault
0xf43b3f crash_signal
../../gcc/toplev.cc:314
0x806bce gfc_compare_derived_types(gfc_symbol*, gfc_symbol*)
../../gcc/fortran/interface.cc:636
0x800803 gfc_check_assign(gfc_expr*, gfc_expr*, int, bool)
../../gcc/fortran/expr.cc:3830
0x86d655 resolve_ordinary_assign
../../gcc/fortran/resolve.cc:11222
0x87628b gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.cc:12123
0x878307 resolve_codes
../../gcc/fortran/resolve.cc:17624
0x87823e resolve_codes
../../gcc/fortran/resolve.cc:17607
0x8783ce gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.cc:17659
0x85ff92 gfc_parse_file()
../../gcc/fortran/parse.cc:6837
0x8aec0f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug fortran/107425] New: [12/13 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.cc:3060

2022-10-26 Thread gscfq--- via Gcc-bugs

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

Bug ID: 107425
   Summary: [12/13 Regression] ICE in gimplify_var_or_parm_decl,
at gimplify.cc:3060
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20220116 and 20220123 :
(j has no value)


$ cat z1.f90
program p
   integer :: x(8)
   !$omp taskwait depend(iterator(i=1:8), in:x(j))
end


$ gfortran-12-20220116 -c z1.f90 -fopenmp
$
$ gfortran-13-20221023 -c z1.f90 -fopenmp
z1.f90:3:50:

3 |!$omp taskwait depend(iterator(i=1:8), in:x(j))
  |  ^
internal compiler error: in gimplify_var_or_parm_decl, at gimplify.cc:3060
0xc030eb gimplify_var_or_parm_decl
../../gcc/gimplify.cc:3060
0xc0fd1f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16815
0xc0dc52 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16457
0xc0d7f3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:17134
0xc19633 gimplify_compound_lval
../../gcc/gimplify.cc:3303
0xc0d87a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16306
0xc20d8a gimplify_addr_expr
../../gcc/gimplify.cc:6555
0xc0f47d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16401
0xc1f78f gimplify_modify_expr
../../gcc/gimplify.cc:6147
0xc0fc37 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16354
0xc13b18 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7213
0xc0ef0b gimplify_statement_list
../../gcc/gimplify.cc:2021
0xc0ef0b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16799
0xc13b18 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7213
0xc144a3 gimplify_bind_expr
../../gcc/gimplify.cc:1430
0xc0f41a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16555
0xc13b18 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7213
0xc0ef0b gimplify_statement_list
../../gcc/gimplify.cc:2021
0xc0ef0b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16799
0xc13b18 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7213

[Bug fortran/107424] New: [13 Regression] ICE in gfc_trans_omp_do, at fortran/trans-openmp.cc:5397

2022-10-26 Thread gscfq--- via Gcc-bugs

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

Bug ID: 107424
   Summary: [13 Regression] ICE in gfc_trans_omp_do, at
fortran/trans-openmp.cc:5397
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20220501 and 20220508 :


$ cat z1.f90
program p
   integer :: i, j
   !$omp do simd collapse(2)
   do i = 1, 9, 2
  do j = 1, i
  end do
   end do
end


$ gfortran-13-20220501 -c z1.f90 -fopenmp
z1.f90:5:17:

5 |   do j = 1, i
  | 1
Error: !$OMP DO SIMD collapsed loops don't form rectangular iteration space at
(1)


$ gfortran-13-20221023 -c z1.f90 -fopenmp
z1.f90:3:28:

3 |!$omp do simd collapse(2)
  |1
internal compiler error: in gfc_trans_omp_do, at fortran/trans-openmp.cc:5397
0x953457 gfc_trans_omp_do
../../gcc/fortran/trans-openmp.cc:5397
0x9549a1 gfc_trans_omp_do_simd
../../gcc/fortran/trans-openmp.cc:6526
0x956cd2 gfc_trans_omp_directive(gfc_code*)
../../gcc/fortran/trans-openmp.cc:7554
0x8b7897 trans_code
../../gcc/fortran/trans.cc:2245
0x8ef2a9 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7659
0x8608de translate_all_program_units
../../gcc/fortran/parse.cc:6696
0x8608de gfc_parse_file()
../../gcc/fortran/parse.cc:7002
0x8aec0f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug fortran/107423] New: ICE in parse_spec, at fortran/parse.cc:4017

2022-10-26 Thread gscfq--- via Gcc-bugs

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

Bug ID: 107423
   Summary: ICE in parse_spec, at fortran/parse.cc:4017
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to r8 with option -std=f95
and file gfortran.dg/pdt_12.f03 or this reduction :


$ cat z1.f90
program p
   type t(k)
  integer, kind :: k
  integer :: a
   end type
contains
   function f()
  type(t(4)), allocatable :: x
  allocate (t(4) :: x)
   end
end


$ gfortran-13-20221023 -c z1.f90
$
$ gfortran-13-20221023 -c z1.f90 -std=f95
z1.f90:3:23:

3 |   integer, kind :: k
  |   1
Error: Fortran 2003: KIND attribute at (1) in a TYPE definition
z1.f90:8:15:

8 |   type(t(4)), allocatable :: x
  |   1
Error: Invalid character in name at (1)
z1.f90:9:18:

9 |   allocate (t(4) :: x)
  |  1
Error: Derived type 't' cannot be used as a variable at (1)
z1.f90:10:6:

   10 |end
  |  1
Error: Fortran 2008: END statement instead of END FUNCTION statement at (1)
z1.f90:11:3:

   11 | end
  |   1
Error: Fortran 2008: END statement instead of END FUNCTION statement at (1)
f951: internal compiler error: Segmentation fault
0xf43b3f crash_signal
../../gcc/toplev.cc:314
0x85c4de parse_spec
../../gcc/fortran/parse.cc:4017
0x85ea5c parse_progunit
../../gcc/fortran/parse.cc:6237
0x85ee41 parse_contained
../../gcc/fortran/parse.cc:6138
0x85ece6 parse_progunit
../../gcc/fortran/parse.cc:6309
0x860121 gfc_parse_file()
../../gcc/fortran/parse.cc:6782
0x8aec0f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug c++/107422] New: [12/13 Regression] ICE in lvalue_kind, at cp/tree.cc:293

2022-10-26 Thread gscfq--- via Gcc-bugs

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

Bug ID: 107422
   Summary: [12/13 Regression] ICE in lvalue_kind, at
cp/tree.cc:293
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r12 before 20210502 :
(gcc configured with --enable-checking=yes)


$ cat z1.cc
typedef decltype (__builtin_trap) t;
template  struct s;
union
{
  template  using b = decltype (t () (s  {}));
  template  b  get ();
};  // } u;


$ g++-13-20221023 -c z1.cc -fno-pretty-templates
z1.cc:5:26: error: 'template using::b = decltype
(t()(s{}))' invalid; an anonymous union may only have public non-static data
members [-fpermissive]
5 |   template  using b = decltype (t () (s  {}));
  |  ^
'
Segmentation fault
7 | };  // } u;
  | ^
0x11d0e4f crash_signal
../../gcc/toplev.cc:314
0xb15510 lvalue_kind(tree_node const*)
../../gcc/cp/tree.cc:293
0xae9fa7 finish_decltype_type(tree_node*, bool, int)
../../gcc/cp/semantics.cc:11488
0xb271af strip_typedefs(tree_node*, bool*, unsigned int)
../../gcc/cp/tree.cc:1788
0x91ae45 dump_type
../../gcc/cp/error.cc:538
0x91a6fc dump_type_prefix
../../gcc/cp/error.cc:981
0x92578d dump_function_decl
../../gcc/cp/error.cc:1804
0x9287f6 decl_to_string
../../gcc/cp/error.cc:3297
0x9287f6 cp_printer
../../gcc/cp/error.cc:4471
0x2202490 pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.cc:1475
0x21e13c0 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.cc:1548
0x21e1b0a diagnostic_impl
../../gcc/diagnostic.cc:1712
0x21e224a permerror(unsigned int, char const*, ...)
../../gcc/diagnostic.cc:1979
0x8c30e7 fixup_anonymous_aggr(tree_node*)
../../gcc/cp/decl.cc:5194
0x8ea67c shadow_tag(cp_decl_specifier_seq*)
../../gcc/cp/decl.cc:5498
0xa011c9 cp_parser_simple_declaration
../../gcc/cp/parser.cc:15422
0xa35d9b cp_parser_declaration
../../gcc/cp/parser.cc:14970
0xa368b8 cp_parser_translation_unit
../../gcc/cp/parser.cc:5076
0xa368b8 c_parse_file()
../../gcc/cp/parser.cc:48860
0xbcef21 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1247

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

2022-10-26 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #10)
> Well, a boz is typeless, so it cannot be compatible with any other type.
> So, I would assume, you could do 
> 
> if (ts1->type == BT_BOZ || ts2->type == BT_BOZ)
>return false;

Yes, that's better.

> There is a caveat in that Fortran 2023 is going to allow
> things like
> 
> real :: x = z'1234'
> 
> if gfc_type_compatible is used in simple assignments, gfortran will
> need to deal with that.

It is currently not used in those cases.

The following is already rejected:

program p
  real :: r
  data r / z'1234' /
  r = z'1234'
  print *, r
end

pr103413-boz.f90:3:18:

3 |   data r / z'1234' /
  |  1
Error: BOZ literal constant near (1) cannot be assigned to a REAL variable [see
'-fno-allow-invalid-boz']
pr103413-boz.f90:4:6:

4 |   r = z'1234'
  |  1
Error: BOZ literal constant at (1) is neither a DATA statement value nor an
actual argument of INT/REAL/DBLE/CMPLX intrinsic subprogram [see
'-fno-allow-invalid-boz']

Interestingly, -fno-allow-invalid-boz is not an allowed option...
But even when using -fallow-invalid-boz, which degrades the above to a warning,
I never get to gfc_type_compatible.

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed. reduced testcase:
int t();
void f(int);

void j()
{
const int& e = t();
f(e);
}

Someone who understands the uininit pass should look into this but the IR at
that point we get is (with -fno-exceptions due to extra clobbers otherwise
which don't make a difference):
  _1 = .DEFERRED_INIT (4, 2, &"D.2374"[0]);
  D.2374 = _1;
  e_6 = .DEFERRED_INIT (8, 2, &"e"[0]);
  _2 = t ();
  D.2374 = _2;
  e_9 = &D.2374;
  _3 = *e_9;
  f (_3);
  D.2374 ={v} {CLOBBER(eol)};

There is no read from D.2374 in the call to t at all and then we do a full
write after the call.

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

2022-10-26 Thread seurer at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from seurer at gcc dot gnu.org ---
*** Bug 107420 has been marked as a duplicate of this bug. ***

[Bug bootstrap/107420] [13 regression] ICE when building trunk with ieee128 after r13-3307-g8efc38347a7444

2022-10-26 Thread seurer at gcc dot gnu.org via Gcc-bugs

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from seurer at gcc dot gnu.org ---
Argh.  Sorry about the duplicate.

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

[Bug bootstrap/107420] [13 regression] ICE when building trunk with ieee128 after r13-3307-g8efc38347a7444

2022-10-26 Thread aldyh at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Aldy Hernandez  ---
Can this be reproduced on a cross?  Could you provide a preprocessed source?

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

2022-10-26 Thread joseph at codesourcery dot com via Gcc-bugs

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

--- Comment #13 from joseph at codesourcery dot com  ---
If the real issue in a particular place in the kernel is that a single 
(anonymous) enum type is being used for lots of different kinds of 
constants, then the appropriate fix in the kernel might be to split up the 
enum, so that large constants of one kind don't affect the types of small 
constants of a different kind.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

2022-10-26 Thread joseph at codesourcery dot com via Gcc-bugs

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

--- Comment #25 from joseph at codesourcery dot com  ---
On Wed, 26 Oct 2022, jakub at gcc dot gnu.org via Gcc-bugs wrote:

> Seems LLVM currently only supports _BitInt up to 128, which is kind of useless
> for users, those sizes can be easily handled as bitfields and performing 
> normal
> arithmetics on them.

Well, it would be useful for users of 32-bit targets who want 128-bit 
arithmetic, since we only support __int128 for 64-bit targets.

> As for implementation, I'd like to brainstorm about it a little bit.
> I'd say we want a new tree code for it, say BITINT_TYPE.

OK.  The signed and unsigned types of each precision do need to be 
distinguished from all the existing kinds of integer types (including the 
ones used for bit-fields: _BitInt types aren't subject to integer 
promotions, whereas bit-fields narrower than int are).

In general the types operate like integer types (in terms of allowed 
operations etc.) so INTEGRAL_TYPE_P would be true for them.  The main 
difference at front-end level is the lack of integer promotions, so that 
arithmetic can be carried out directly on narrower-than-int operands (but 
a bit-field declared with a _BitInt type gets promoted to that _BitInt 
type, e.g. unsigned _BitInt(7):2 acts as unsigned _BitInt(7) in 
arithmetic).

Unlike the bit-field types, there's no such thing as a signed _BitInt(1); 
signed bit-precise integer types must havet least two bits.

> TYPE_PRECISION unfortunately is only 10-bit, that is not enough, so it 
> would need the full precision to be specified somewhere else.

That may complicate things because of code expecting TYPE_PRECISION to be 
meaningful for all integer types.  But that could be addressed without 
needing to review every use of TYPE_PRECISION by e.g. changing 
TYPE_PRECISION to check wherever the _BitInt precision is specified, and 
instead using e.g. TYPE_RAW_PRECISION for direct access to the tree field 
(so only lvalue uses of TYPE_PRECISION would then need updating, other 
accesses would automatically get the full precision).

> And have targetm specify the ABI
> details (size of a limb (which would need to be exposed to libgcc with
> -fbuilding-libgcc), unless it is everywhere the same whether the limbs are
> least significant to most significant or vice versa, and whether the highest
> limb is sign/zero extended or unspecified beyond the precision.

I haven't seen an ABI specified for any architecture supporting big-endian 
yet, but I'd tend to expect such architectures to use big-endian ordering 
for the _BitInt representation to be consistent with existing integer 
types.

> What about the large ones?

I think we can at least slightly simplify things by assuming for now 
_BitInt multiplication / division / modulo are unlikely to be used much 
for arguments large enough that Karatsuba or asymptotically faster 
algorithms become relevant; that is, that naive quadratic-time algorithms 
are sufficient for those operations.

[Bug rtl-optimization/97684] [11 Regression] ICE in reg_preferred_class, at reginfo.c:789 by r11-4577

2022-10-26 Thread torbjorn.svensson at foss dot st.com via Gcc-bugs

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

Torbjörn SVENSSON  changed:

   What|Removed |Added

 CC||torbjorn.svensson at foss dot 
st.c
   ||om

--- Comment #9 from Torbjörn SVENSSON  ---
In https://gcc.gnu.org/g:081c96621da658760b4a67c07530805f770fa22c, a regression
was introduced that causes GCC to segfault randomly.

The regression is due to that resize_reg_info() is no longer called after
remove_scratches() and remove_scratches() can increase the number of registers.
Due to the increase of number of registers in remove_scratches(), the resulting
out-of-bounds usage of the reg_renumber global array will have unpredictable
result.

I sent a proposal patch to resolve this issue that can be reviewed here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604295.html

>From what I can tell, this regression exist in gcc-11, gcc-12 and master.

[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||michael.meier at hexagon dot 
com

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

[Bug tree-optimization/107415] RISCV-gcc: Leaf function compiles as recursive with -O3

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug other/107353] frontends sometimes select wrong (too strong) TLS access model

2022-10-26 Thread amonakov at gcc dot gnu.org via Gcc-bugs

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

Alexander Monakov  changed:

   What|Removed |Added

Summary|[13 regression] Numerous|frontends sometimes select
   |ICEs after  |wrong (too strong) TLS
   |r13-3416-g1d561e1851c466|access model

--- Comment #15 from Alexander Monakov  ---
C FE issue was broken out as PR 107419 and Fortran FE issue as PR 107421, which
now "block" this PR together with PR 107393 for the earlier C++ testcase. The
offending assert is gone, so retitling (not a regression anymore).

[Bug tree-optimization/107407] [12/13 Regression] Wrong code at -Os on x86_64-linux-gnu since r12-383-g32955416d8040b1f

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|13.0|12.3

[Bug fortran/107421] New: problematic interaction of 'common' and 'threadprivate'

2022-10-26 Thread amonakov at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 107421
   Summary: problematic interaction of 'common' and
'threadprivate'
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, asolokha at gmx dot com,
bergner at gcc dot gnu.org, iains at gcc dot gnu.org,
law at gcc dot gnu.org, marxin at gcc dot gnu.org,
segher at gcc dot gnu.org, seurer at gcc dot gnu.org,
unassigned at gcc dot gnu.org
Blocks: 107353
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #107353 +++

integer :: i

common /c/ i

!$omp threadprivate (/c/)

i = 0

end

f951 -fopenmp invokes decl_default_tls_model before assigning DECL_COMMON in
fortran/trans-common.cc:build_common_decl. This causes 'c' to have local-exec
model rather than initial-exec, breaking internal verification that was
weakened to solve PR 107353.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353
[Bug 107353] [13 regression] Numerous ICEs after r13-3416-g1d561e1851c466

[Bug bootstrap/107420] [13 regression] ICE when building trunk with ieee128 after r13-3307-g8efc38347a7444

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |13.0

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|enums can be wrongly long   |[13 Regression] enum change
   |in gcc-13 (in gnu99)|causing Linux kernel to
   ||fail to build due to Linux
   ||depending on old behavior

--- Comment #12 from Andrew Pinski  ---
See bug 107314 comment #1 really.
The Linux sources will most likely should be fixed for this enum fix.

[Bug bootstrap/107420] New: [13 regression] ICE when building trunk with ieee128 after r13-3307-g8efc38347a7444

2022-10-26 Thread seurer at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 107420
   Summary: [13 regression] ICE when building trunk with ieee128
after r13-3307-g8efc38347a7444
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:8efc38347a7444dde3fb173f0f2c59a60b7db53d, r13-3307-g8efc38347a7444 

Seen on powerpc64 when building a non-bootstrap trunk with ieee128.  

configure --enable-languages=c,fortran,c++ --with-cpu=power9
--disable-bootstrap --disable-multilib --with-long-double-format=ieee

make
. . .
/home/seurer/gcc/git/build/gcc-test/./gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/./gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
   -g -O2 -O2  -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include  -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -fPIC -mlong-double-128
-mno-minimal-toc -I. -I. -I../.././gcc -I/home/seurer/gcc/git/gcc-test/libgcc
-I/home/seurer/gcc/git/gcc-test/libgcc/.
-I/home/seurer/gcc/git/gcc-test/libgcc/../gcc
-I/home/seurer/gcc/git/gcc-test/libgcc/../include
-I/home/seurer/gcc/git/gcc-test/libgcc/../libdecnumber/dpd
-I/home/seurer/gcc/git/gcc-test/libgcc/../libdecnumber -DHAVE_CC_TLS 
-Wno-type-limits -mvsx -mfloat128 -mno-float128-hardware -mno-gnu-attribute
-I/home/seurer/gcc/git/gcc-test/libgcc/soft-fp
-I/home/seurer/gcc/git/gcc-test/libgcc/config/rs6000 -DFLOAT128_HW_INSNS
-DFLOAT128_HW_INSNS_ISA3_1  -o _mulkc3.o -MT _mulkc3.o -MD -MP -MF _mulkc3.dep 
-c /home/seurer/gcc/git/gcc-test/libgcc/config/rs6000/_mulkc3.c
-fvisibility=hidden -DHIDE_EXPORTS
during GIMPLE pass: evrp
/home/seurer/gcc/git/gcc-test/libgcc/config/rs6000/_mulkc3.c: In function
'__mulkc3_sw':
/home/seurer/gcc/git/gcc-test/libgcc/config/rs6000/_mulkc3.c:97:1: internal
compiler error: in fold_stmt, at gimple-range-fold.cc:514
   97 | }
  | ^
0x11b11a83 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
/home/seurer/gcc/git/gcc-test/gcc/gimple-range-fold.cc:514
0x11afe213 gimple_ranger::fold_range_internal(vrange&, gimple*, tree_node*)
/home/seurer/gcc/git/gcc-test/gcc/gimple-range.cc:258
0x11afe213 gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
/home/seurer/gcc/git/gcc-test/gcc/gimple-range.cc:319
0x110a2e1b range_query::value_of_stmt(gimple*, tree_node*)
/home/seurer/gcc/git/gcc-test/gcc/value-query.cc:135
0x1104d0a7 rvrp_folder::value_of_stmt(gimple*, tree_node*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vrp.cc:4300
0x10ed2cab
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-propagate.cc:816
0x11ab6def dom_walker::walk(basic_block_def*)
/home/seurer/gcc/git/gcc-test/gcc/domwalk.cc:311
0x10ed1387 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-propagate.cc:987
0x1103fd7b execute_ranger_vrp(function*, bool)
/home/seurer/gcc/git/gcc-test/gcc/tree-vrp.cc:4351


commit 8efc38347a7444dde3fb173f0f2c59a60b7db53d (HEAD)
Author: Aldy Hernandez 
Date:   Thu Oct 13 17:51:29 2022 +0200

Implement range-op entry for __builtin_copysign.

[Bug debug/107012] [debug, dwarf-5] Missing line information for evaluating macros

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
See https://sourceware.org/pipermail/gdb-patches/2022-April/187555.html So
moved to the gdb bug.

[Bug c/107419] New: attributes are ignored when selecting TLS model

2022-10-26 Thread amonakov at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 107419
   Summary: attributes are ignored when selecting TLS model
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, asolokha at gmx dot com,
bergner at gcc dot gnu.org, iains at gcc dot gnu.org,
law at gcc dot gnu.org, marxin at gcc dot gnu.org,
segher at gcc dot gnu.org, seurer at gcc dot gnu.org,
unassigned at gcc dot gnu.org
Blocks: 107353
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #107353 +++

__attribute__((common))
__thread int i;

int *f()
{
return &i;
}

C frontend invokes decl_default_tls_model before processing attributes,
assigning local-exec model as if the 'common' attribute was not present.
Recomputing it later would select initial-exec model, breaking internal
verification that was weakened to solve PR 107353.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353
[Bug 107353] [13 regression] Numerous ICEs after r13-3416-g1d561e1851c466

[Bug tree-optimization/106433] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032

2022-10-26 Thread asolokha at gmx dot com via Gcc-bugs

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

--- Comment #2 from Arseny Solokha  ---
JFTR, I believe I can reproduce the same issue on x86_64 w/ the current gcc
13.0.0 20221023 (g:0e37fd4dc74c1db99cdc7d71ef378e1221253c6f) snapshot:

int m;
int *p;

__attribute__ ((simd)) int
bar (int x)
{
  if (x)
{
  if (m < 1)
for (m = 0; m < 1; ++m)
  ++x;

  p = &x;

  for (;;)
++m;
}

  return 0;
}

__attribute__ ((simd)) int
foo (int x)
{
  return bar (x);
}

% x86_64-unknown-linux-gnu-gcc-13 -O2 -c rf5yfvga.c
during GIMPLE pass: vect
rf5yfvga.c: In function 'foo.simdclone.0':
rf5yfvga.c:23:1: internal compiler error: in vect_transform_loops, at
tree-vectorizer.cc:1032
   23 | foo (int x)
  | ^~~
0x7ac573 vect_transform_loops
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-vectorizer.cc:1032
0x11dd81f try_vectorize_loop_1
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-vectorizer.cc:1153
0x11dd81f try_vectorize_loop
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-vectorizer.cc:1183
0x11ddbd4 execute
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-vectorizer.cc:1299

[Bug c++/107417] g++ fails to recognize parameter pack in requires-expression

2022-10-26 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||accepts-invalid,
   ||rejects-valid
 Ever confirmed|0   |1
   Last reconfirmed||2022-10-26

--- Comment #1 from Jonathan Wakely  ---
I think the underlying issue is that it accepts the pack without expansion:

template
  requires (requires (T x) { x; })
  auto func(T...) { }

And so the error about "no unexpanded parameter packs" is correct, the AST
doesn't contain any. But it should do, the requires-expression is a pack
expression that must be expanded (e.g. in a fold expression).

[Bug other/107353] [13 regression] Numerous ICEs after r13-3416-g1d561e1851c466

2022-10-26 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Alexander Monakov :

https://gcc.gnu.org/g:82e629c26647313be406c41a01e6868cfad0f289

commit r13-3509-g82e629c26647313be406c41a01e6868cfad0f289
Author: Alexander Monakov 
Date:   Wed Oct 26 16:37:34 2022 +0300

ipa-visibility: remove assert in TLS optimization [PR107353]

When upgrading TLS access model based on optimized symbol visibility
status, we attempted to assert that recomputing the model would not
weaken it. It turns out that C, C++, and Fortran front-ends all can
(unintentionally) assign a stronger model than what can be derived
from the declaration.

Let's act conservatively instead of asserting, at least as long as
such pre-existing issues remain.

gcc/ChangeLog:

PR other/107353
* ipa-visibility.cc (function_and_variable_visibility):
Conditionally upgrade TLS model instead of asserting.

[Bug target/93177] PPC: Missing many useful platform intrinsics

2022-10-26 Thread segher at gcc dot gnu.org via Gcc-bugs

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

--- Comment #18 from Segher Boessenkool  ---
(In reply to Sergey Fedorov from comment #16)
> For Darwin, PPC intrinsics already is there in Apple headers. Can it be
> added into current GCC?

If it is in the Apple headers already, why would you need a separate copy
in GCC?

Also please note that as said many of those things do not work with current
GCC, and arguably didn't work with older GCC either, the user just got lucky
that the random translation he got did what he wanted :-/  Things like "sync"
or "dcbst" need proper dependencies, things like lwarx are *impossible* to
do, etc.

But thought-out patches are welcome :-)

[Bug lto/107418] lto-dump -gimple-stats Segmentation Fault

2022-10-26 Thread volker.weissmann at gmx dot de via Gcc-bugs

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

--- Comment #1 from Volker Weißmann  ---
If you don't like that I enabled -flto, but disabled the optimizer, tell me,
then I minify another example that triggers the same segfault, even if -Os is
given.

[Bug lto/107418] New: lto-dump -gimple-stats Segmentation Fault

2022-10-26 Thread volker.weissmann at gmx dot de via Gcc-bugs

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

Bug ID: 107418
   Summary: lto-dump -gimple-stats Segmentation Fault
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: volker.weissmann at gmx dot de
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I don't understand what -gimple-stats does, but I don't think it should
segfault:

$ g++ bug.cpp -c -flto && lto-dump bug.o -gimple-stats
during IPA pass: modref
lto-dump: internal compiler error: Segmentation fault
0x1788bc4 internal_error(char const*, ...)
???:0
0x6e8ba3 cgraph_node::get_untransformed_body()
???:0
0x67ebd7 lto_main()
???: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.

bug.cpp:
class MyClass  {
  public:
  MyClass(){}
};
void func() {
  new MyClass();
}

I used the gcc from the Archlinux repository:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC) 

If I build gcc myself, I get a backtrace with line numbers:
$ g++ bug.cpp -c -flto && lto-dump bug.o -gimple-stats  
/home/volker/Documents/localgcc/../gcc/gcc/cgraph.cc:4001:23: runtime error:
member access within null pointer of type 'struct lto_in_decl_state'
during IPA pass: modref
lto-dump: internal compiler error: Segmentation fault
0x2e693dd crash_signal
/home/volker/Documents/localgcc/../gcc/gcc/toplev.cc:314
0x10203df cgraph_node::get_untransformed_body()
/home/volker/Documents/localgcc/../gcc/gcc/cgraph.cc:4001
0xbd1cee lto_main()
/home/volker/Documents/localgcc/../gcc/gcc/lto/lto-dump.cc:350
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.

Self-build-gcc:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/volker/Documents/myroot/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/volker/Documents/localgcc/../gcc/configure
--enable-checking --disable-bootstrap --prefix=/home/volker/Documents/myroot
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221023 (experimental) (GCC)

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

2022-10-26 Thread tomas.kalibera at gmail dot com via Gcc-bugs

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

Tomas Kalibera  changed:

   What|Removed |Added

  Attachment #52007|0   |1
is obsolete||

--- Comment #12 from Tomas Kalibera  ---
Created attachment 53778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53778&action=edit
Draft patch to ignore built-in format attribute for a builtin, if there is
another one

This is a draft of an alternative patch, which addresses the concern that in
theory the built in format attribute may not be the first one in the list of
attributes of a built-in function. This patch puts attribute flags inside
TREE_PURPOSE of the attribute, so that it can be checked later whether it is a
built in attribute. I am not sure whether this is legal, but it should be easy
to update it to store the flags somewhere else, if needed.

[Bug c++/107417] New: g++ fails to recognize parameter pack in requires-expression

2022-10-26 Thread jwjagersma at gmail dot com via Gcc-bugs

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

Bug ID: 107417
   Summary: g++ fails to recognize parameter pack in
requires-expression
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwjagersma at gmail dot com
  Target Milestone: ---

Given the following code:

  $ cat fold.cpp
  template
  requires (requires (T x) { x; } and ...)
  auto func(T...) { }

g++ seems to forget that T is a parameter pack:

  $ g++ -std=c++20 fold.cpp
  fold.cpp:2:11: error: operand of fold expression has no unexpanded parameter
packs
  2 | requires (requires (T x) { x; } and ...)
|   ^

This issue is present on both 12.2 and latest 13.0.  Clang and msvc do accept
it.

[Bug target/93177] PPC: Missing many useful platform intrinsics

2022-10-26 Thread iains at gcc dot gnu.org via Gcc-bugs

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

--- Comment #17 from Iain Sandoe  ---
(In reply to Sergey Fedorov from comment #16)
> For Darwin, PPC intrinsics already is there in Apple headers. Can it be
> added into current GCC?

There is a version of the header on the FSF Apple branch, which means we can
forward port / check / add to the installation / test it.  It might/might not
be useful to any other ppc sub-ports.

[Bug target/93177] PPC: Missing many useful platform intrinsics

2022-10-26 Thread vital.had at gmail dot com via Gcc-bugs

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

--- Comment #16 from Sergey Fedorov  ---
For Darwin, PPC intrinsics already is there in Apple headers. Can it be added
into current GCC?

[Bug debug/107416] removed

2022-10-26 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
.

[Bug debug/107416] A heap buffer overflow was fould in find_section_in_set() of binutils-2.39 (commit 49c843e6)

2022-10-26 Thread bjchan9an at foxmail dot com via Gcc-bugs

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

--- Comment #2 from bjchan9an at foxmail dot com ---
(In reply to Andrew Pinski from comment #1)
> Binutils bugzilla is located at https://sourceware.org/bugzilla/ .

Sorry, can you delete this report? We will report it to binutils bugzilla.

[Bug debug/107416] A heap buffer overflow was fould in find_section_in_set() of binutils-2.39 (commit 49c843e6)

2022-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Andrew Pinski  ---
Binutils bugzilla is located at https://sourceware.org/bugzilla/ .

[Bug debug/107416] New: A heap buffer overflow was fould in find_section_in_set() of binutils-2.39 (commit 49c843e6)

2022-10-26 Thread bjchan9an at foxmail dot com via Gcc-bugs

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

Bug ID: 107416
   Summary: A heap buffer overflow was fould in
find_section_in_set() of binutils-2.39 (commit
49c843e6)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bjchan9an at foxmail dot com
  Target Milestone: ---

Created attachment 53777
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53777&action=edit
readelf poc file

Hi

There is a heap buffer overflow bug in binutils-2.39 (commit 49c843e6). 

The bug is triggered in find_section_in_set() at binutils/readelf.c:970 when
parsing the debug sections of a malformed ELF file.

The bug is caused by improper checks of the array boundary when iterating
through the array "section_subset" of ELF debug section.

To reproduce this bug, use:

1. compile binutils-2.39 with clang-6.0 and address sanitizer:
```sh
./configure --disable-shared --disable-gdb --disable-werror
make
```

2. use readelf to process the PoC file (see attachment):
```sh
readelf -w ./PoC
```

The address sanitizer reports are as follows.

readelf: Error: Internal error: out of space in the shndx pool.
readelf: Error: Internal error: out of space in the shndx pool.
readelf: Error: Internal error: out of space in the shndx pool.
readelf: Error: Internal error: out of space in the shndx pool.
readelf: Error: Internal error: out of space in the shndx pool.
readelf: Error: Internal error: out of space in the shndx pool.
Contents of the .debug_names section:

readelf: Warning: Debug info is corrupted, .debug_names header at 0 has length
0x4c457f
Contents of the .debug_names section:

=
==29074==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x61a00bd8 at pc 0x005143de bp 0x7fffd6c0 sp 0x7fffd6b8
READ of size 4 at 0x61a00bd8 thread T0
#0 0x5143dd in find_section_in_set
/binutils-gdb/obj-asan/binutils/../../binutils/readelf.c:970:19
#1 0x5130b6 in load_debug_section
/binutils-gdb/obj-asan/binutils/../../binutils/readelf.c:16160:9
#2 0x612472 in load_debug_section_with_follow
/binutils-gdb/obj-asan/binutils/../../binutils/dwarf.c:3453:7
#3 0x606ce0 in display_debug_names
/binutils-gdb/obj-asan/binutils/../../binutils/dwarf.c:10002:3
#4 0x558c9b in display_debug_section
/binutils-gdb/obj-asan/binutils/../../binutils/readelf.c:16258:18
#5 0x558c9b in process_section_contents
/binutils-gdb/obj-asan/binutils/../../binutils/readelf.c:16354
#6 0x52ae91 in process_object
/binutils-gdb/obj-asan/binutils/../../binutils/readelf.c:22372:9
#7 0x517f9e in process_file
/binutils-gdb/obj-asan/binutils/../../binutils/readelf.c:22795:13
#8 0x517f9e in main
/binutils-gdb/obj-asan/binutils/../../binutils/readelf.c:22866
#9 0x76e22c86 in __libc_start_main
/build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
#10 0x41a909 in _start (/binutils-gdb/obj-asan/binutils/readelf+0x41a909)

0x61a00bd8 is located 0 bytes to the right of 1368-byte region
[0x61a00680,0x61a00bd8)
allocated by thread T0 here:
#0 0x4dac40 in realloc (/binutils-gdb/obj-asan/binutils/readelf+0x4dac40)
#1 0x74eeed in xrealloc
/binutils-gdb/obj-asan/libiberty/../../libiberty/xmalloc.c:181:14

SUMMARY: AddressSanitizer: heap-buffer-overflow
/binutils-gdb/obj-asan/binutils/../../binutils/readelf.c:970:19 in
find_section_in_set
Shadow bytes around the buggy address:
  0x0c347fff8120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c347fff8130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c347fff8140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c347fff8150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c347fff8160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c347fff8170: 00 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa fa
  0x0c347fff8180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c347fff8190: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c347fff81a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c347fff81b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c347fff81c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb

Found

[Bug fortran/107397] [10/11/12/13 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654

2022-10-26 Thread kargl at gcc dot gnu.org via Gcc-bugs

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
Interesting bug.  The BOZ on the rhs is eventually rejected,
but if any error/warning that might be queued is lost during
a pass through  add_init_expr_to_sym().  Eventually, the rhs
expr is freed and the pointer to the initializer is wrong.

This patch fixes the ICE and issues an error.  It has passed
regression testing.

diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 0f9b2ced4c2..1562dc22bc6 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2221,6 +2221,14 @@ add_init_expr_to_sym (const char *name, gfc_expr
**initp, locus *var_locus)
sym->ts.f90_type = init->ts.f90_type;
}

+  /* Catch the case:  type(t), parameter :: x = z'1'.  */
+  if (sym->ts.type == BT_DERIVED && init->ts.type == BT_BOZ)
+   {
+ gfc_error ("Entity %qs at %L is incompatible with a BOZ "
+"literal constant", name, &sym->declared_at);
+ return false;
+   }
+
   /* Add initializer.  Make sure we keep the ranks sane.  */
   if (sym->attr.dimension && init->rank == 0)
{

[Bug tree-optimization/107415] RISCV-gcc: Leaf function compiles as recursive with -O3

2022-10-26 Thread michael.meier at hexagon dot com via Gcc-bugs

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

--- Comment #2 from Michael Meier  ---
(In reply to Andrew Pinski from comment #1)
> Gcc can detect memset and optimize it to memset. And this is what is
> happening. 
> This is documented too.

Thanks for your quick reply. I understand what is happening now.

Now that you pointed me in this direction, I found many references to this
behavior only, including that I can use -fno-tree-loop-distribute-patterns to
disable the optimization. However I didn't find mention of the feature in the
official documentation. Can you provide me with a reference, please?

1 2 >

1 - 100 of 151 matches

Mail list logo