[Bug c++/113498] ICE in GCC trunk: tree check: have using_decl in get_template_info, at cp/pt.cc:357

[bobmiller at nvidia dot com via Gcc-bugs]

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

--- Comment #2 from Bob Miller  ---
Apologies, I should have reduced this test case further before submission, but
I was under the mistaken impression that the template weirdness was the cause.
I believe this is a minimized example: https://godbolt.org/z/s3vGEh4Wx

template
struct S_Base
{
static constexpr int D = d;
};

template
struct S : public S_Base
{
using S_Base::D;
constexpr void f() const
requires(D > 0) {}

};

int main(int, char**)
{
S<1> s;
s.f();
return 0;
}

[Bug libstdc++/64064] basic_filebuf seekoff return value is unusable for files opened in text mode on Windows

[lh_mouse at 126 dot com via Gcc-bugs]

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

LIU Hao  changed:

   What|Removed |Added

 CC||lh_mouse at 126 dot com

--- Comment #1 from LIU Hao  ---
AFAICT the only issue here is that one can't pass the result of `pubseekoff()`
back to `pubseekpos()`. Both MSVCRT GCC and UCRT GCC are affected, but MSVC
isn't.


```
#include 
#include 

int main(int, char* argv[])
{
  using traits   = std::filebuf::traits_type;
  using int_type = std::filebuf::int_type;

  std::filebuf fb;
  fb.open(argv[1], std::ios::in);

  int_type c;
  while (!traits::eq_int_type(c = fb.sbumpc(), traits::eof()))
  {
std::cout << static_cast(c);
auto pos = fb.pubseekoff(0, std::ios::cur, std::ios::in);
fb.pubseekpos(pos, std::ios::in);
  }

  std::cout << '\n';
}
```

This outputs
```
hl
ol
```

[Bug libstdc++/113500] Using std::format with float or double based std::chrono::time_point causes error: no match for 'operator<<'

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Hirthammer from comment #0)
> Consider the following code snippet:

As stated at https://gcc.gnu.org/bugs we want a complete test case, not a
snippet.

#include 
#include 
std::chrono::sys_time> tp = {};
auto time_string = std::format("{:%S}", tp);

[Bug libstdc++/113500] Using std::format with float or double based std::chrono::time_point causes error: no match for 'operator<<'

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.3
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-01-19

--- Comment #1 from Jonathan Wakely  ---
(In reply to Hirthammer from comment #0)
> error: no match for 'operator<<' (operand types are
> 'std::__cxx11::basic_ostringstream' and 'const
> std::chrono::time_point std::chrono::duration >')
>   726 |   __os << __t;
>   |   ~^~
> ---
> 
> If you change the type def `Representation` to an integer or unsigned
> integer type, the code compiles.

Confirmed.


> Side note: 
> Don't know if it helps, but the latest clang compiler version produces the
> same error. The related bug report can be found here:
> 
> https://github.com/llvm/llvm-project/issues/78555

Since this is a bug in libstdc++ headers it's not at all surprising that you
get the same error with any compiler using those headers. This should not have
been reported to llvm.

[Bug debug/113488] [14 Regression] ICE in add_AT_die_ref with LTO since r14-5546

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
I will have a look.

(gdb) p debug_dwarf_die (die)
DIE0: DW_TAG_label (0x768dc410)
  abbrev id: 0 offset: 0 mark: 0
(gdb) p attr_kind
$2 = DW_AT_abstract_origin

and in gen_label_die we do

  tree origin = decl_ultimate_origin (decl);
  dw_die_ref lbl_die = lookup_decl_die (decl);
  rtx insn;
  char label[MAX_ARTIFICIAL_LABEL_BYTES];

  if (!lbl_die)
{ 
  lbl_die = new_die (DW_TAG_label, context_die, decl);
  equate_decl_number_to_die (decl, lbl_die);

  if (origin != NULL)
add_abstract_origin_attribute (lbl_die, origin);

but origin == decl here.

(gdb) p decl->decl_common.abstract_origin 
$6 = 

that's read this way from the LTO data.  A workaround right in dwarf2out
is possible, but I'll see if this self-reference makes sense (and where
it comes from).

[Bug tree-optimization/113487] Missed optimization:simplify demanded bits on multi-use instructions like select

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

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

--- Comment #3 from Richard Biener  ---
Feels more like reassoc to me.  You could also view it as "bit-DCE", eliding
defs of dead bits.  Which might make it suitable for backprop (currently
doing sth similar for the sign "bit").

[Bug target/113485] [14 regrssion] ICE with -fno-guess-branch-probability on aarch64 starting with r14-7187-g74e3e839ab2d36

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||aarch64
   Priority|P3  |P1

[Bug libstdc++/113500] New: Using std::format with float or double based std::chrono::time_point causes error: no match for 'operator<<'

[Hirthammer--- via Gcc-bugs]

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

Bug ID: 113500
   Summary: Using std::format with float or double based
std::chrono::time_point causes error: no match for
'operator<<'
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hirtham...@allterra-dno.de
  Target Milestone: ---

Consider the following code snippet:

---
using Representation = double;
using Duration   = std::chrono::duration;
using Clock  = std::chrono::system_clock;
using TimePoint  = std::chrono::time_point;

TimePoint tp = {};

std::string time_string = std::format("{:%d.%m.%Y %H:%M:%S}", tp);
---


This results in the compile error:


---
error: no match for 'operator<<' (operand types are
'std::__cxx11::basic_ostringstream' and 'const
std::chrono::time_point >')
  726 |   __os << __t;
  |   ~^~
---

If you change the type def `Representation` to an integer or unsigned integer
type, the code compiles.

System Info:

~~~
OS: Ubuntu 22.04 LTS
GCC-Version: 13.1.0
arguments: -std=c++20
~~~

Here is a link with the code that produces the error in Compiler Explorer:

https://godbolt.org/z/hhPrG1z37

Side note: 
Don't know if it helps, but the latest clang compiler version produces the same
error. The related bug report can be found here:

https://github.com/llvm/llvm-project/issues/78555

[Bug debug/113488] [14 Regression] ICE in add_AT_die_ref with LTO since r14-5546

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[14 Regression] ICE in  |[14 Regression] ICE in
   |add_AT_die_ref with LTO |add_AT_die_ref with LTO
   ||since r14-5546

--- Comment #5 from Jakub Jelinek  ---
Verified we ICE on this starting with r14-5546

[Bug rust/113499] crab1 fails to link when configuring with --disable-plugin

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

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

--- Comment #1 from Richard Biener  ---
Note it might also be because the failing build is using glibc-2.31, IIRC
newer glibc might include libdl directly (at least that's the case for
libpthreads ...)

[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

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

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

--- Comment #15 from Richard Biener  ---
(In reply to Sam James from comment #14)
> I tried 'if (candidate && candidate->src != EDGE_PRED (loop->latch,
> 0)->src)' as well given that seems way more sensible and that works too, but
> obviously if I pick something eager or always true, it's going to help, so
> I'll wait for you now.

Yeah, that's what it meant to read - sorry for fat-fingering this so many
times.

Your other choice makes it simply never vectorize anything while this should
really just disable all early-exit-peeled variants.

[Bug debug/113488] [14 Regression] ICE in add_AT_die_ref with LTO

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-01-19

--- Comment #4 from Jakub Jelinek  ---
I think the assert has been added in
r14-5546-g1bcb7fe60544bba8b88028f9ffa062336d399664
but will try to verify if it really ICEs since then.

[Bug target/99913] GCC11 fails to build for MinGW-w64 for Windows 32-bit

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

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

Brecht Sanders  changed:

   What|Removed |Added

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

--- Comment #5 from Brecht Sanders  
---
I can confirm GCC 13.2.0 builds with MinGW-w64 11.0.1 without explicitly
configuring with LDFLAGS="-pthread"

[Bug rust/113499] New: crab1 fails to link when configuring with --disable-plugin

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

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

Bug ID: 113499
   Summary: crab1 fails to link when configuring with
--disable-plugin
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rust
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org
  Target Milestone: ---

With --disable-plugin we probably elide -ldl but crab1 calls dlopen even when
plugin support is disabled leading to

[  949s]
/home/abuild/rpmbuild/BUILD/gcc-14.0.1+git8231/obj-x86_64-suse-linux/./prev-gcc/xg++
-B/home/abuild/rpmbuild/BUILD/gcc-14.0.1+git8231/obj-x86_64-suse-linux/./prev-gcc/
-B/usr/x
86_64-suse-linux/bin/ -nostdinc++
-B/home/abuild/rpmbuild/BUILD/gcc-14.0.1+git8231/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/src/.libs
-B/home/abuild/rpmbuild/BUILD/gcc-
14.0.1+git8231/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/libsupc++/.libs

-I/home/abuild/rpmbuild/BUILD/gcc-14.0.1+git8231/obj-x86_64-suse-linux/prev-x86_64-suse-linux/l
ibstdc++-v3/include/x86_64-suse-linux 
-I/home/abuild/rpmbuild/BUILD/gcc-14.0.1+git8231/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include
 -I/home/abuild/rpmbuild/BUILD/
gcc-14.0.1+git8231/libstdc++-v3/libsupc++
-L/home/abuild/rpmbuild/BUILD/gcc-14.0.1+git8231/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/src/.libs
-L/home/abuild/rpmbuild/BU
ILD/gcc-14.0.1+git8231/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/libsupc++/.libs
-no-pie   -fmessage-length=0 -grecord-gcc-switches -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack
-protector-strong -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -g -fno-checking -gtoggle -fprofile-generate -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-macro
s -Wno-overlength-strings   -DHAVE_CONFIG_H -no-pie -static-libstdc++
-static-libgcc  -L./../libgrust/libproc_macro_internal -o crab1 \
[  949s]   rust/rust-lang.o rust/rust-object-export.o rust/rust-linemap.o
rust/rust-diagnostics.o rust/rust-gcc.o rust/rust-token.o rust/rust-lex.o
rust/rust-cfg-parser.o rust/rust-
parse.o rust/rust-ast.o rust/rust-ast-formatting.o rust/rust-path.o
rust/rust-pattern.o rust/rust-ast-fragment.o rust/rust-ast-dump.o
rust/rust-ast-collector.o rust/rust-ast-visitor.o r
ust/rust-hir-dump.o rust/rust-session-manager.o rust/rust-compile.o
rust/rust-mangle.o rust/rust-compile-resolve-path.o rust/rust-macro-expand.o
rust/rust-cfg-strip.o rust/rust-expand-v
isitor.o rust/rust-ast-builder.o rust/rust-derive.o rust/rust-derive-clone.o
rust/rust-derive-copy.o rust/rust-proc-macro.o rust/rust-macro-invoc-lexer.o
rust/rust-proc-macro-invoc-lexe
r.o rust/rust-macro-substitute-ctx.o rust/rust-macro-builtins.o rust/rust-hir.o
rust/rust-hir-map.o rust/rust-attributes.o rust/rust-keyword-values.o
rust/rust-abi.o rust/rust-token-con
verter.o rust/rust-macro.o rust/rust-ast-lower.o rust/rust-ast-lower-base.o
rust/rust-ast-lower-pattern.o rust/rust-ast-lower-item.o
rust/rust-ast-lower-expr.o rust/rust-ast-lower-type.
o rust/rust-ast-lower-stmt.o rust/rust-rib.o
rust/rust-name-resolution-context.o rust/rust-default-resolver.o
rust/rust-toplevel-name-resolver-2.0.o rust/rust-early-name-resolver-2.0.o 
rust/rust-early-name-resolver.o rust/rust-name-resolver.o
rust/rust-ast-resolve.o rust/rust-ast-resolve-base.o
rust/rust-ast-resolve-item.o rust/rust-ast-resolve-pattern.o rust/rust-ast
-resolve-expr.o rust/rust-ast-resolve-type.o rust/rust-ast-resolve-path.o
rust/rust-ast-resolve-stmt.o rust/rust-ast-resolve-struct-expr-field.o
rust/rust-hir-type-check.o rust/rust-pri
vacy-check.o rust/rust-privacy-ctx.o rust/rust-reachability.o
rust/rust-visibility-resolver.o rust/rust-pub-restricted-visitor.o
rust/rust-privacy-reporter.o rust/rust-tyty.o rust/rust-
tyty-util.o rust/rust-tyty-call.o rust/rust-tyty-subst.o
rust/rust-typecheck-context.o rust/rust-tyty-bounds.o
rust/rust-hir-trait-resolve.o rust/rust-hir-trait-reference.o rust/rust-hi
r-type-check-item.o rust/rust-hir-type-check-type.o
rust/rust-hir-type-check-struct.o rust/rust-hir-type-check-pattern.o
rust/rust-hir-type-check-expr.o rust/rust-hir-type-check-stmt.o 
rust/rust-hir-type-check-enumitem.o rust/rust-hir-type-check-implitem.o
rust/rust-borrow-checker.o rust/rust-bir-builder-expr-stmt.o
rust/rust-bir-dump.o rust/rust-hir-dot-operator.o ru
st/rust-hir-path-probe.o rust/rust-type-util.o rust/rust-coercion.o
rust/rust-casts.o rust/rust-unify.o rust/rust-hir-type-check-base.o
rust/rust-autoderef.o rust/rust-substitution-mapp
er.o rust/rust-const-checker.o rust/rust-lint-marklive.o
rust/rust-lint-unused-var.o rust/rust-readonly-check.o

[Bug c++/113498] ICE in GCC trunk: tree check: have using_decl in get_template_info, at cp/pt.cc:357

[bobmiller at nvidia dot com via Gcc-bugs]

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

--- Comment #1 from Bob Miller  ---
Bug also occurs on GCC Trunk in Compiler Explorer.
Small test case to reproduce bug: https://godbolt.org/z/TorE88bMT

#include 

template class ThisTT,
typename T,
size_t...Dims>
struct S_Base
{
static constexpr size_t D = (Dims *...);
};

template class ThisTT,
typename T,
size_t...Dims>
struct S : public S_Base
{
using S_Base::D;
constexpr ThisTT f() const
requires(D > 0) {return {};}

};

template
struct S2 : public S
{
};

int main(int, char**)
{
S2 s2;
s2.f();
return 0;
}

[Bug c++/113498] New: ICE in GCC trunk: tree check: have using_decl in get_template_info, at cp/pt.cc:357

[bobmiller at nvidia dot com via Gcc-bugs]

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

Bug ID: 113498
   Summary: ICE in GCC trunk: tree check: have using_decl in
get_template_info, at cp/pt.cc:357
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bobmiller at nvidia dot com
  Target Milestone: ---

Created attachment 57154
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57154=edit
GCC Bug report generated via -freport-bug

the exact version of GCC: Any GCC trunk at/after 14.0.0-20240107gita6b8d8f919c4

the system type: x86_64-pc-linux-gnu

the options given when GCC was configured/built: ../configure
--prefix=/opt/gcc-latest --enable-languages=c,c++ --enable-libstdcxx-debug
--enable-libstdcxx-backtrace --disable-bootstrap --disable-multilib
--disable-libvtv --with-system-zlib --without-isl --enable-multiarch

the complete command line that triggers the bug: ./g++ -O3 --std=c++23 -Wall
-Wextra -pedantic -freport-bug /test.cpp -o /test


the compiler output (error messages, warnings, etc.):




the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, or, in the case of a bug
report for the GNAT front end, a complete set of source files (see below): This
is the file attached to this bug.

root@ceceda56193b:/opt/gcc-latest/bin# ./g++ -O3 --std=c++23 -Wall -Wextra
-pedantic -freport-bug /test.cpp -o /test
/test.cpp: In instantiation of 'constexpr ThisTT S::f() const requires ('using_decl' not supported by expression) > 0 [with
ThisTT = S2; T = int; long unsigned int ...Dims = {1, 1}]':
/test.cpp:30:9:   required from here
   30 | s2.f();
  | ^~
/test.cpp:18:26: error: no return statement in 'constexpr' function returning
non-void
   18 | requires(D > 0) {}
  |  ^
/test.cpp: In instantiation of 'constexpr ThisTT S::f() const requires ('using_decl' not supported by expression) > 0 [with
ThisTT = S2; T = int; long unsigned int ...Dims = {1, 1}]':
/test.cpp:17:34: internal compiler error: tree check: expected var_decl or
function_decl or field_decl or type_decl or concept_decl or template_decl, have
using_decl in get_template_info, at cp/pt.cc:357
   17 | constexpr ThisTT f() const
  |  ^
0x7994c4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.cc:8954
0xafa224 template_info_decl_check(tree_node const*, char const*, int, char
const*)
../../gcc/cp/cp-tree.h:665
0xafa224 get_template_info(tree_node const*)
../../gcc/cp/pt.cc:357
0xb0455f most_general_template(tree_node const*)
../../gcc/cp/pt.cc:26017
0xa063f2 write_unqualified_name
../../gcc/cp/mangle.cc:1601
0xa12561 write_nested_name
../../gcc/cp/mangle.cc:1273
0xa13159 write_encoding
../../gcc/cp/mangle.cc:938
0xa1338b write_mangled_name
../../gcc/cp/mangle.cc:820
0xa0a00f write_expression
../../gcc/cp/mangle.cc:3441
0xa08f8e write_expression
../../gcc/cp/mangle.cc:3942
0xa1327d write_constraint_expression
../../gcc/cp/mangle.cc:860
0xa1327d write_encoding
../../gcc/cp/mangle.cc:968
0xa1338b write_mangled_name
../../gcc/cp/mangle.cc:820
0xa15138 mangle_decl_string
../../gcc/cp/mangle.cc:4420
0xa153d8 get_mangled_id
../../gcc/cp/mangle.cc:4441
0xa153d8 mangle_decl(tree_node*)
../../gcc/cp/mangle.cc:4479
0x16a2175 decl_assembler_name(tree_node*)
../../gcc/tree.cc:719
0xd947ab symtab_node::get_comdat_group_id()
../../gcc/cgraph.h:258
0xd947ab analyze_functions
../../gcc/cgraphunit.cc:1200
0xd960cd symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2555
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.


Please let me know if additional information is required :D

[Bug libgcc/113497] error: implicit declaration of function 'abort' on enable-execute-stack.c on i686-w64-mingw32 target

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #2 from cqwrteur  ---
https://github.com/gcc-mirror/gcc/blob/9693459e030977d6e906ea7eb587ed09ee4fddbd/libgcc/config/i386/enable-execute-stack-mingw32.c#L31

Looks like it misses stdlib.h

[Bug libgcc/113497] error: implicit declaration of function 'abort' on enable-execute-stack.c

[unlvsur at live dot com via Gcc-bugs]

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

cqwrteur  changed:

   What|Removed |Added

 CC||unlvsur at live dot com

--- Comment #1 from cqwrteur  ---
Created attachment 57153
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57153=edit
config.log

[Bug libgcc/113497] New: error: implicit declaration of function 'abort' on enable-execute-stack.c

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 113497
   Summary: error: implicit declaration of function 'abort' on
enable-execute-stack.c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

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

[Bug target/113312] Add __attribute__((no_callee_saved_registers)) for Intel FRED

[xin at zytor dot com via Gcc-bugs]

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

--- Comment #25 from Xin Li  ---
(In reply to Xin Li from comment #22)
> Per Peter's suggestion, I added __attribute__((no_callee_saved_registers))
> to a linux source tree containing FRED patches:
> https://github.com/xinli-intel/linux-fred-public/commit/
> 12c38143a5c33e89f2b3d8906629dd4f23f8d79c

It's better to refer to branch 'gcc-no_callee_saved_registers' instead:

https://github.com/xinli-intel/linux-fred-public/commits/gcc-no_callee_saved_registers/

[Bug target/113312] Add __attribute__((no_callee_saved_registers)) for Intel FRED

[xin at zytor dot com via Gcc-bugs]

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

--- Comment #24 from Xin Li  ---
(In reply to H.J. Lu from comment #23)
> (In reply to Xin Li from comment #22)
> > Per Peter's suggestion, I added __attribute__((no_callee_saved_registers))
> > to a linux source tree containing FRED patches:
> > https://github.com/xinli-intel/linux-fred-public/commit/
> > 12c38143a5c33e89f2b3d8906629dd4f23f8d79c.  And I compiled the linux code
> > with a gcc built from
> > https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/pr113312/gcc-13.
> > 
> > Following are my observations:
> > 1) the generated kernel boots fine on both FRED Simics model and bare metal.
> > 2) the asm code generated for fred_entry_from_{user,kernel}() are the same,
> > i.e., __attribute__((no_callee_saved_registers)) makes no difference (Peter
> > said the FRED dispatch points simply do not have significant register
> > pressure – intentionally).
> > 3) other functions with __attribute__((no_callee_saved_registers)) do get
> > rid of pushing/popping clobbered registers, and cause no issues because they
> > are top-level functions, only invoked by tail call, meaning the following
> > case won't happen:
> > 
> > :
> > ...
> > mov (%rbx), %r13
> > call foo
> > mov %rax, (%r13)
> > ...
> > 
> > otherwise foo() is NOT a top-level function.
> 
> Do these mean that __attribute__((no_callee_saved_registers)) works for you?

Yes, it works as expected.

> BTW, my patches also avoid saving callee-saved registers in
> __attribute__((noreturn))
> functions.

I also checked do_exit, which is the same as what you posted.

[Bug debug/113488] [14 Regression] ICE in add_AT_die_ref with LTO

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

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 57151
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57151=edit
v8_turboshaft.late-optimization-phase.ii

./cc1plus -fpreprocessed v8_turboshaft.late-optimization-phase.ii -quiet -g1
-O3 -std=gnu++17 -fPIC -flto=4 -fuse-linker-plugin -o
v8_turboshaft.late-optimization-phase.s; ./xg++ -B ./ -shared -nostdlib -flto=4
-fuse-linker-plugin -ffat-lto-objects -o libnode.so.115
-Wl,-soname=libnode.so.115 v8_turboshaft.late-optimization-phase.s

Reduced testcase

[Bug analyzer/113496] New: ICE: in cmp, at analyzer/constraint-manager.cc:782 with -fanalyzer -fdump-analyzer

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113496
   Summary: ICE: in cmp, at analyzer/constraint-manager.cc:782
with -fanalyzer -fdump-analyzer
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 57150
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57150=edit
auto-reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fanalyzer -fdump-analyzer u_format_latc.c.i
u_format_latc.c.i: In function
'util_format_colormask_descutil_format_colormask':
u_format_latc.c.i:11:5: warning: infinite loop [CWE-835]
[-Wanalyzer-infinite-loop]
   11 | case UTIL_FORMAT_COLORSPACE_ZS:;
  | ^~~~
  'util_format_colormask_descutil_format_colormask': event 1
|
|   11 | case UTIL_FORMAT_COLORSPACE_ZS:;
|  | ^~~~
|  | |
|  | (1) infinite loop here
|
  'util_format_colormask_descutil_format_colormask': event 2
|
|cc1:
| (2): looping back...
|
  'util_format_colormask_descutil_format_colormask': event 3
|
|   11 | case UTIL_FORMAT_COLORSPACE_ZS:;
|  | ^~~~
|  | |
|  | (3) ...to here
|
during IPA pass: analyzer
At top level:
cc1: internal compiler error: in cmp, at analyzer/constraint-manager.cc:782
0xdd2429 ana::bounded_ranges::cmp(ana::bounded_ranges const*,
ana::bounded_ranges const*)
/repo/gcc-trunk/gcc/analyzer/constraint-manager.cc:782
0xdd2429 ana::bounded_ranges::cmp(ana::bounded_ranges const*,
ana::bounded_ranges const*)
/repo/gcc-trunk/gcc/analyzer/constraint-manager.cc:770
0x29fcbd8 cmp1
/repo/gcc-trunk/gcc/sort.cc:151
0x29fcc31 netsort
/repo/gcc-trunk/gcc/sort.cc:168
0x29fcc31 mergesort
/repo/gcc-trunk/gcc/sort.cc:205
0x29fce7d mergesort
/repo/gcc-trunk/gcc/sort.cc:212
0x29fd22f gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
/repo/gcc-trunk/gcc/sort.cc:268
0x291b316 vec::qsort(int
(*)(void const*, void const*))
/repo/gcc-trunk/gcc/vec.h:1217
0x291b316 vec::qsort(int (*)(void
const*, void const*))
/repo/gcc-trunk/gcc/vec.h:2240
0x291b316 ana::bounded_ranges_manager::log_stats(ana::logger*, bool) const
/repo/gcc-trunk/gcc/analyzer/constraint-manager.cc:1040
0x195f957 ana::region_model_manager::log_stats(ana::logger*, bool) const
/repo/gcc-trunk/gcc/analyzer/region-model-manager.cc:1929
0x190fc1f ana::exploded_graph::log_stats() const
/repo/gcc-trunk/gcc/analyzer/engine.cc:4551
0x19113f7 ana::impl_run_checkers(ana::logger*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:6230
0x191227b ana::run_checkers()
/repo/gcc-trunk/gcc/analyzer/engine.cc:6300
0x1900f38 execute
/repo/gcc-trunk/gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8259-20240118193928-gb6c4fcda7fe-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8259-20240118193928-gb6c4fcda7fe-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240118 (experimental) (GCC)

[Bug c++/113443] GCC rejects valid program involving parameter packs with in between class type

[jlame646 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Jason Liam  ---
Clang is also wrong in rejecting the code. Here is the clang bub:
https://github.com/llvm/llvm-project/issues/78449

[Bug go/113447] [14 regression] issue20185.go etc. FAIL

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Fixed, sorry about that.

[Bug go/113447] [14 regression] issue20185.go etc. FAIL

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Ian Lance Taylor :

https://gcc.gnu.org/g:7e949ffaafb415150047127f529377502097d897

commit r14-8268-g7e949ffaafb415150047127f529377502097d897
Author: Ian Lance Taylor 
Date:   Thu Jan 18 20:46:30 2024 -0800

gcc/testsuite/go.test: update for lowering pass move

The change to move the  lowering pass after the check types pass
changed some error messages.  Update the testsuite accordingly.

Fixes PR go/113447

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

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

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

Bug 104355 Summary: Misleading -Warray-bounds documentation says "always out of 
bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104355

   What|Removed |Added

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

[Bug middle-end/104355] Misleading -Warray-bounds documentation says "always out of bounds"

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
 CC||sandra at gcc dot gnu.org

--- Comment #6 from sandra at gcc dot gnu.org ---
Looks like this was fixed by Martin's commit 2 years ago, closing now.

[Bug rtl-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #17 from JuzheZhong  ---
Ok. Confirm the original test 33383M -> 4796k now.

[Bug rtl-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #16 from JuzheZhong  ---
(In reply to Andrew Pinski from comment #15)
> (In reply to JuzheZhong from comment #14)
> > Oh. I known the reason now.
> > 
> > The issue is not RISC-V backend VSETVL PASS.
> > 
> > It's memory bug of rtx_equal_p I think.
> 
> 
> It is not rtx_equal_p but rather RVV_VLMAX which is defined as:
> riscv-protos.h:#define RVV_VLMAX gen_rtx_REG (Pmode, X0_REGNUM)
> 
> Seems like you could cache that somewhere ...

Oh. Make sense to me. Thank you so much.
I think memory-hog issue will be fixed soon.

But the compile-time hog issue of loop invariant motion is still not fixed.

[Bug rtl-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

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

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

--- Comment #15 from Andrew Pinski  ---
(In reply to JuzheZhong from comment #14)
> Oh. I known the reason now.
> 
> The issue is not RISC-V backend VSETVL PASS.
> 
> It's memory bug of rtx_equal_p I think.


It is not rtx_equal_p but rather RVV_VLMAX which is defined as:
riscv-protos.h:#define RVV_VLMAX gen_rtx_REG (Pmode, X0_REGNUM)

Seems like you could cache that somewhere ...

[Bug rtl-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #14 from JuzheZhong  ---
Oh. I known the reason now.

The issue is not RISC-V backend VSETVL PASS.

It's memory bug of rtx_equal_p I think.

We are calling rtx_equal_p which is very costly.

For example, has_nonvlmax_reg_avl is calling rtx_equal_p.

So I keep all codes unchange, then replace comparison as follows:

diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index 93a1238a5ab..1c85c8ee3c6 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -4988,7 +4988,7 @@ nonvlmax_avl_type_p (rtx_insn *rinsn)
 bool
 vlmax_avl_p (rtx x)
 {
-  return x && rtx_equal_p (x, RVV_VLMAX);
+  return x && REG_P (x) && REGNO (x) == X0_REGNUM/*rtx_equal_p (x,
RVV_VLMAX)*/;
 }

Use REGNO (x) == X0_REGNUM instead of rtx_equal_p.

Memory-hog issue is gone:

939M -> 725k.

So I am gonna send a patch to walk around rtx_equal_p issues which cause
memory-hog.

[Bug rtl-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #13 from JuzheZhong  ---
So I think we should investigate why calling has_nonvlmax_reg_avl cost so much
memory.

[Bug rtl-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #12 from JuzheZhong  ---
Ok. Here is a simple fix which give some hints:


diff --git a/gcc/config/riscv/riscv-vsetvl.cc
b/gcc/config/riscv/riscv-vsetvl.cc
index 2067073185f..ede818140dc 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -2719,10 +2719,11 @@ pre_vsetvl::compute_lcm_local_properties ()
  for (int i = 0; i < num_exprs; i += 1)
{
  const vsetvl_info  = *m_exprs[i];
- if (!info.has_nonvlmax_reg_avl () && !info.has_vl ())
+ bool has_nonvlmax_reg_avl_p = info.has_nonvlmax_reg_avl ();
+ if (!has_nonvlmax_reg_avl_p && !info.has_vl ())
continue;

- if (info.has_nonvlmax_reg_avl ())
+ if (has_nonvlmax_reg_avl_p)
{
  unsigned int regno;
  sbitmap_iterator sbi;
@@ -3556,7 +3557,7 @@ const pass_data pass_data_vsetvl = {
   RTL_PASS, /* type */
   "vsetvl", /* name */
   OPTGROUP_NONE, /* optinfo_flags */
-  TV_NONE,  /* tv_id */
+  TV_MACH_DEP,  /* tv_id */
   0,/* properties_required */
   0,/* properties_provided */
   0,/* properties_destroyed */


Memory usage from 931M -> 781M. Memory usage reduce significantly.

Note that I didn't change all has_nonvlmax_reg_avl, We have so many places
calling  has_nonvlmax_reg_avl...

[Bug c++/113405] Can't access member type alias of concept-constrained class template specialization in global module fragment via alias template in different module

[nathanieloshead at gmail dot com via Gcc-bugs]

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||nathanieloshead at gmail dot 
com

--- Comment #4 from Nathaniel Shead  ---
The issue seems to be that 'depset::hash::add_specializations' only adds the
first of a set of constrained specialisations that use the same arguments. This
comes down to the fact that the 'type_specializations' hashset is only hashed
on the base template and the provided arguments: differently constrained
specialisations just aren't added.

Other parts of the dependency walker seem to handle this OK, by walking the
DECL_TEMPLATE_SPECIALIZATIONS list, but not the base 'specialization_add'
function.

I'm not entirely sure yet what the best way to approach solving this is.

[Bug rtl-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #11 from JuzheZhong  ---
It should be compute_lcm_local_properties. The memory usage reduce 50% after I
remove this function. I am still investigating.

[Bug rtl-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #10 from JuzheZhong  ---
No, it's not caused here. I removed the whole function compute_avl_def_data.

The memory usage doesn't change.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

Bug 113429 Summary: RISC-V: SPEC2017 527 cam4 miscompilation in autovec VLA 
build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429

   What|Removed |Added

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

[Bug target/113429] RISC-V: SPEC2017 527 cam4 miscompilation in autovec VLA build

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

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

Vineet Gupta  changed:

   What|Removed |Added

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

--- Comment #11 from Vineet Gupta  ---
Verified works now.

[Bug rtl-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> How sparse is this bitmap will be?  bitmap instead of sbitmap should be used
> if the bitmap is going to be sparse. sbitmap is a fixed sized based on the
> bitmap size while bitmap is better for sparse bitmaps as it is implemented
> as linked list.

Also it seems like DF already has def_in/def_out info, how much is duplicated
information from there?

[Bug rtl-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Patrick O'Neill from comment #7)
> I believe the memory hog is caused by this:
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/riscv-vsetvl.cc;
> h=2067073185f8c0f398908b164a99b592948e6d2d;
> hb=565935f93a7da629da89b05812a3e8c43287598f#l2427
> 
> In the slightly reduced test program I was using to debug there were ~35k
> bb's leading to num_expr being roughly 1 million. vsetvl then makes 35k
> bitmaps of ~1 million bits.

How sparse is this bitmap will be?  bitmap instead of sbitmap should be used if
the bitmap is going to be sparse. sbitmap is a fixed sized based on the bitmap
size while bitmap is better for sparse bitmaps as it is implemented as linked
list.

[Bug rtl-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

 CC||patrick at rivosinc dot com

--- Comment #7 from Patrick O'Neill  ---
I believe the memory hog is caused by this:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/riscv-vsetvl.cc;h=2067073185f8c0f398908b164a99b592948e6d2d;hb=565935f93a7da629da89b05812a3e8c43287598f#l2427

In the slightly reduced test program I was using to debug there were ~35k bb's
leading to num_expr being roughly 1 million. vsetvl then makes 35k bitmaps of
~1 million bits.

[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

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

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

--- Comment #14 from Sam James  ---
I tried 'if (candidate && candidate->src != EDGE_PRED (loop->latch, 0)->src)'
as well given that seems way more sensible and that works too, but obviously if
I pick something eager or always true, it's going to help, so I'll wait for you
now.

[Bug c++/102397] Documentation of attribute syntax does not discuss C++11 / C23 attribute syntax

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #1 from sandra at gcc dot gnu.org ---
I committed a patch a few months ago to say that the new C++/C standard
attribute syntax is supported with a gnu:: prefix, so at least the
originally-reported problem has already been fixed.

However, all the examples still use the old syntax.  Given that there is an
awful lot of legacy code using the old syntax already out there, examples are
useful in helping people grok what it means, but at some point we probably want
to encourage people to use the new syntax in new code for all the usual reasons
why it's better to do things in a standard way, and use it also as the primary
form for documentation.  

OTOH, I don't think we're quite there yet.  Presently the manual describes C23
support as "experimental and incomplete" and says the default C language
dialect is -std=gnu17.  My sense is that it's not appropriate to tell users to
make the switch until GCC's default dialect is advanced to something based on
C23.

So I'm going to leave this issue open for now instead of closing it as fixed,
as a reminder that there is still more work to be done here a little farther
down the road.

[Bug testsuite/113437] [14 Regression] gcc.dg/tree-ssa/pr95906.c fails on arm since g:6686e16fda4

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

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

Hongtao Liu  changed:

   What|Removed |Added

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

--- Comment #8 from Hongtao Liu  ---
Fixed.

[Bug testsuite/113437] [14 Regression] gcc.dg/tree-ssa/pr95906.c fails on arm since g:6686e16fda4

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:1c51d0109a4730827c40c3bbd3a59d459828017e

commit r14-8266-g1c51d0109a4730827c40c3bbd3a59d459828017e
Author: liuhongt 
Date:   Fri Jan 19 09:22:39 2024 +0800

Fix testcase failure on many platforms which don't support vect_int_max.

After r14-7124-g6686e16fda4190, the testcase can be optimized to
MAX_EXPR if the backends support that. So I adjust the testcase to
scan for MAX_EXPR, but it failed many platforms which don't support
that.
As pinski mentioned, target vect_no_int_min_max is only available
under vect directory, so for simplicity, I adjust the testcase to scan
either MAX_EXPR or original VEC_COND_EXPR.

gcc/testsuite/ChangeLog:

PR testsuite/113437
* gcc.dg/tree-ssa/pr95906.c: Scan either MAX_EXPR or
VEC_COND_EXPR.

[Bug testsuite/113437] [14 Regression] gcc.dg/tree-ssa/pr95906.c fails on arm since g:6686e16fda4

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Target|arm, sparc* |arm, sparc*, cris
 CC||hp at gcc dot gnu.org

--- Comment #6 from Hans-Peter Nilsson  ---
cris-elf too...

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 113038 Summary: [14 regression] Excess errors for 
g++.dg/modules/hello-1_b.C  after r14-6569-gfe54b57728c09a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038

   What|Removed |Added

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

[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

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

--- Comment #10 from Hans-Peter Nilsson  ---
(In reply to Hans-Peter Nilsson from comment #9)
> I'm going to reclose this if
> I can find support for it being fixed on one more target.

So, https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/805640.html
says it's fixed for power8 too, compared to the previous report, for r14-8195.

[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

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

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

--- Comment #13 from Sam James  ---
if I just cast RHS to basic_block (doubt that's the right thing), then
libgcrypt tests pass!

this also fixes mpfr + gmp tests, thank you!

[Bug c/110029] more precise documentation for cleanup attribute

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from sandra at gcc dot gnu.org ---
Fixed.

[Bug c/110029] more precise documentation for cleanup attribute

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Sandra Loosemore :

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

commit r14-8263-ged28a835058d2e72036f4adb1dd60edf735c7d00
Author: Sandra Loosemore 
Date:   Fri Jan 19 02:06:55 2024 +

More precise documentation for cleanup attribute [PR110029]

gcc/ChangeLog
PR c/110029
* doc/extend.texi (Common Variable Attributes): Explain what
happens when multiple variables with cleanups are in the same
scope.

[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point

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

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

--- Comment #4 from Kewen Lin  ---
(In reply to Naveen N Rao from comment #2)
> I don't really have a preference, though I tend to agree that nops before
> the local entry point aren't that useful. Even with the current approach,
> not all functions have instructions at the GEP and for those, the nops are
> being generated outside the function. We also won't have a separate GEP/LEP
> with pcrel, so we won't need a separate option eventually.

Thanks for the input! Looking forward to the comments from the others,
especially Segher, David and Peter.

(In reply to Michael Matz from comment #3)
> (In reply to Kewen Lin from comment #1)
> > 
> > As Segher's review comments in [2], to support "before NOPs" before global
> > entry and "after NOPs" after global entry,
> 
> Just to be perfectly clear here: the "after NOPs" need to come after local
> entry
> (which strictly speaking is of course after the global one as well, but I'm
> being anal :) ).

Oops, good catch, I meant to type "after local entry", thanks for the
correction making it perfectly clear. :)

[Bug rtl-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #6 from JuzheZhong  ---
(In reply to Andrew Pinski from comment #5)
> Note "loop invariant motion" is the RTL based loop invariant motion pass.

So you mean it should be still RISC-V issue, right ?

[Bug rtl-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |rtl-optimization

--- Comment #5 from Andrew Pinski  ---
Note "loop invariant motion" is the RTL based loop invariant motion pass.

[Bug tree-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #4 from JuzheZhong  ---
Also, the original file with -fno-move-loop-invariants reduce compile time from
60 minutes into 7 minutes:

real7m12.528s
user6m55.214s
sys 0m17.147s


machine dep reorg  :  75.93 ( 18%)  14.23 ( 88%)  90.15 ( 21%)
33383M ( 95%

The memory report is quite obvious (consume 95% memory).

So, I believe VSETVL PASS is not the main reason of compile-time-hog,
it should be loop invariant PASS.

But VSETVL PASS is main reason of memory-hog.

I am not familiar with loop invariant pass. Can anyone help to debug
compile-time
hog of loop invariant PASS. Or should we disable loop invariant pass by default
for RISC-V ?

[Bug tree-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #3 from JuzheZhong  ---
Ok. The reduced case:

# 1 "module_first_rk_step_part1.fppized.f90"
# 1 ""
# 1 ""
# 1 "module_first_rk_step_part1.fppized.f90"
!WRF:MEDIATION_LAYER:SOLVER


MODULE module_first_rk_step_part1

CONTAINS

  SUBROUTINE first_rk_step_part1 (   grid , config_flags  &
 , moist , moist_tend   &
 , chem  , chem_tend&
 , tracer, tracer_tend  &
 , scalar , scalar_tend &
 , fdda3d, fdda2d   &
 , aerod&
 , ru_tendf, rv_tendf   &
 , rw_tendf, t_tendf&
 , ph_tendf, mu_tendf   &
 , tke_tend &
 , adapt_step_flag , curr_secs  &
 , psim , psih , wspd , gz1oz0 , br , chklowq &
 , cu_act_flag , hol , th_phy   &
 , pi_phy , p_phy , t_phy   &
 , dz8w , p8w , t8w &
 , ids, ide, jds, jde, kds, kde &
 , ims, ime, jms, jme, kms, kme &
 , ips, ipe, jps, jpe, kps, kpe &
 , imsx,imex,jmsx,jmex,kmsx,kmex&
 , ipsx,ipex,jpsx,jpex,kpsx,kpex&
 , imsy,imey,jmsy,jmey,kmsy,kmey&
 , ipsy,ipey,jpsy,jpey,kpsy,kpey&
 , k_start , k_end  &
 , f_flux   &
)
USE module_state_description
USE module_model_constants
USE module_domain, ONLY : domain, domain_clock_get, get_ijk_from_subgrid
USE module_configure, ONLY : grid_config_rec_type, model_config_rec
USE module_radiation_driver, ONLY : pre_radiation_driver, radiation_driver
USE module_surface_driver, ONLY : surface_driver
USE module_cumulus_driver, ONLY : cumulus_driver
USE module_shallowcu_driver, ONLY : shallowcu_driver
USE module_pbl_driver, ONLY : pbl_driver
USE module_fr_fire_driver_wrf, ONLY : fire_driver_em_step
USE module_fddagd_driver, ONLY : fddagd_driver
USE module_em, ONLY : init_zero_tendency
USE module_force_scm
USE module_convtrans_prep
USE module_big_step_utilities_em, ONLY : phy_prep
use module_scalar_tables
USE module_dm, ONLY : local_communicator, mytask, ntasks, ntasks_x,
ntasks_y, local_communicator_periodic, wrf_dm_maxval
USE module_comm_dm, ONLY :
halo_em_phys_a_sub,halo_em_fdda_sfc_sub,halo_pwp_sub,halo_em_chem_e_3_sub, &
halo_em_chem_e_5_sub, halo_em_hydro_noahmp_sub
USE module_utility
IMPLICIT NONE

TYPE ( domain ), INTENT(INOUT) :: grid
TYPE ( grid_config_rec_type ), INTENT(IN) :: config_flags
TYPE(WRFU_Time):: currentTime

INTEGER, INTENT(IN) :: ids, ide, jds, jde, kds, kde, &
   ims, ime, jms, jme, kms, kme, &
   ips, ipe, jps, jpe, kps, kpe, &
   imsx,imex,jmsx,jmex,kmsx,kmex,&
   ipsx,ipex,jpsx,jpex,kpsx,kpex,&
   imsy,imey,jmsy,jmey,kmsy,kmey,&
   ipsy,ipey,jpsy,jpey,kpsy,kpey


LOGICAL ,INTENT(IN):: adapt_step_flag
REAL, INTENT(IN)   :: curr_secs

REAL,DIMENSION(ims:ime,kms:kme,jms:jme,num_moist),INTENT(INOUT)   ::
moist
REAL,DIMENSION(ims:ime,kms:kme,jms:jme,num_moist),INTENT(INOUT)   ::
moist_tend
REAL,DIMENSION(ims:ime,kms:kme,jms:jme,num_chem),INTENT(INOUT)   ::
chem
REAL,DIMENSION(ims:ime,kms:kme,jms:jme,num_chem),INTENT(INOUT)   ::
chem_tend
REAL,DIMENSION(ims:ime,kms:kme,jms:jme,num_tracer),INTENT(INOUT)   ::
tracer
REAL,DIMENSION(ims:ime,kms:kme,jms:jme,num_tracer),INTENT(INOUT)   ::
tracer_tend
REAL,DIMENSION(ims:ime,kms:kme,jms:jme,num_scalar),INTENT(INOUT)   ::
scalar
REAL,DIMENSION(ims:ime,kms:kme,jms:jme,num_scalar),INTENT(INOUT)   ::
scalar_tend
REAL,DIMENSION(ims:ime,kms:kme,jms:jme,num_fdda3d),INTENT(INOUT)  ::
fdda3d
REAL,DIMENSION(ims:ime,1:1,jms:jme,num_fdda2d),INTENT(INOUT)  ::
fdda2d
REAL,DIMENSION(ims:ime,kms:kme,jms:jme,num_aerod),INTENT(INOUT)   ::
aerod
REAL,DIMENSION(ims:ime,jms:jme), INTENT(INOUT) :: psim
REAL,DIMENSION(ims:ime,jms:jme), INTENT(INOUT) :: psih
REAL,DIMENSION(ims:ime,jms:jme), INTENT(INOUT) :: wspd
REAL

[Bug tree-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #2 from JuzheZhong  ---
To build the attachment file, we need these following file from SPEC2017:

module_big_step_utilities_em.mod  module_cumulus_driver.mod 
module_fddagd_driver.modmodule_model_constants.mod  
module_shallowcu_driver.mod
module_comm_dm.modmodule_dm.mod 
module_first_rk_step_part1.mod  module_pbl_driver.mod   
module_state_description.mod 
module_configure.mod  module_domain.mod 
module_force_scm.modmodule_radiation_driver.mod 
module_surface_driver.mod
module_convtrans_prep.mod module_em.mod 
module_fr_fire_driver_wrf.mod   module_scalar_tables.mod module_utility.mod

But I failed to create attachment for them since they are too big.

[Bug tree-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #1 from JuzheZhong  ---
Created attachment 57149
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57149=edit
spec2017 wrf

spec2017 wrf

[Bug testsuite/113437] [14 Regression] gcc.dg/tree-ssa/pr95906.c fails on arm since g:6686e16fda4

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

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

--- Comment #5 from Hongtao Liu  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Hongtao Liu from comment #2)
> > Maybe we can add target vect_int.
> 
> Not really because vect_int depends on the vect.exp framework still.  See PR
> 113418 and the emails linked from there.

I see, then I'll adjust testcase to scan either MAX_EXPR or VEC_COND_EXPR

[Bug c/113495] New: RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

Bug ID: 113495
   Summary: RISC-V: Time and memory awful consumption of SPEC2017
wrf benchmark
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

riscv64-unknown-linux-gnu-gfortran -march=rv64gcv_zvl256b -O3 -S -ftime-report

real63m18.771s
user60m19.036s
sys 2m59.787s

60+ minutes.

After investigation, the time report show 2 PASS are critical:

loop invariant motion  :2600.28 ( 72%)   1.68 (  1%)2602.12 ( 69%) 
2617k (  0%)

loop invariant consume most of the time 72% time.

The other is the VSETVL PASS:

vsetvl: earliest_fuse_vsetvl_info  : 438.26 ( 12%)  79.82 ( 47%) 518.08 (
14%)221807M ( 75%)
 vsetvl: pre_global_vsetvl_info : 135.98 (  4%)  31.71 ( 19%) 167.69 (  4%)
71950M ( 24%)

The phase 2 and phase 3 of VSETVL PASS consume 16% times and 99% memory.

I will look into VSETVL PASS issue but I am not able to take care of loop
invariant issue.

[Bug c++/112588] [modules] ICE in make_decl_rtl when returning str literal when string header imported in module

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #5 from Hans-Peter Nilsson  ---
Looks like that commit also fixed the remaining g++.dg/modules/hello-1
execution failure for PR113038!

[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

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

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

--- Comment #9 from Hans-Peter Nilsson  ---
For cris-elf, a change in the range (known to fail, known to pass]
(r14-8193-g3340878009acfc, r14-8200-g9a5e8f9d112adb] seems to have fixed the
remaining hello-1 execution failure, so fixed by r14-8196-g3471a61ed0ddef
(being a change to the c++ modules code and the only code change outside
riscv).

Being the person that reopened the PR, I think I'm going to reclose this if I
can find support for it being fixed on one more target.

[Bug target/113458] Missed SLP for reduction of multiplication/addition with promotion

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

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

--- Comment #6 from Hongtao Liu  ---

> thus
> 
>   vect__16.5_40 = MEM  [(short int *)a_22(D)];
>   vect__17.6_41 = (vector(4) int) vect__16.5_40;
>   vect__18.9_44 = MEM  [(signed char *)b_23(D)];
>   vect_patt_36.10_45 = (vector(4) signed short) vect__18.9_44;
>   vect_patt_37.11_46 = (vector(4) int) vect_patt_36.10_45;
>   vect__20.12_48 = vect__17.6_41 * vect_patt_37.11_46;
>   _49 = VIEW_CONVERT_EXPR(vect__20.12_48);
>   _50 = .REDUC_PLUS (_49); [tail call]
>   _51 = (int) _50;
> 
>
Ideally, it should be recognized as DOT_PROD_EXPR, but
vect_recog_dot_prod_pattern only works for loop vectorizer. We may add some
pattern match in match.pd for


vect__17.6_41 = (vector(4) int) vect__16.5_40;
vect_patt_37.11_46 = (vector(4) int) vect_patt_36.10_45
vect__20.12_48 = vect__17.6_41 * vect_patt_37.11_46;
_49 = VIEW_CONVERT_EXPR(vect__20.12_48);
_50 = .REDUC_PLUS (_49); [tail call]

to

vect__20.12_48 = DOT_PRDO_EXPR (vect__16.5_40, vect_patt_36.10_45, 0);
_49 = VIEW_CONVERT_EXPR(vect__20.12_48);
_50 = .REDUC_PLUS (_49); [tail call]

[Bug ipa/108470] Missing documentation for alternate uses of __attribute__((noinline))

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from sandra at gcc dot gnu.org ---
Fixed.

[Bug ipa/108470] Missing documentation for alternate uses of __attribute__((noinline))

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Sandra Loosemore :

https://gcc.gnu.org/g:9b6b7d615543d73381cb1f994825d9bca024c838

commit r14-8261-g9b6b7d615543d73381cb1f994825d9bca024c838
Author: Sandra Loosemore 
Date:   Thu Jan 18 23:19:39 2024 +

Improve documentation of noinline and noipa attributes [PR108470]

gcc/ChangeLog
PR ipa/108470
* doc/extend.texi (Common Function Attributes): Document that
noinline also disables some interprocedural optimizations and
improve flow to the part about using inline asm instead to
disable calls from being optimized away completely.  Remove the
sentence that says noipa is mainly for internal compiler testing.

[Bug middle-end/113415] ICE: RTL check: -mstringop-strategy=byte_loop vs inline-asm goto with block copies

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

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

--- Comment #4 from Andrew Pinski  ---
Note without RTL checking we get:
```
:7:3: error: impossible constraint in 'asm'
7 |   __asm__ goto("" : "=r"(bitint0) : : : lab);
  |   ^~~
:8:1: error: wrong number of branch edges after unconditional jump in
bb 5
8 | }
  | ^
:8:1: error: wrong number of branch edges after unconditional jump in
bb 3
during RTL pass: cse1
dump file: /app/output.cpp.272r.cse1
:8:1: internal compiler error: verify_flow_info failed
0x2332cfc internal_error(char const*, ...)
???:0
0xb27bd3 verify_flow_info()
???:0
0x2003c7c cleanup_cfg(int)
???: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.
```

With release checking we get an ICE after the first error; the `confused by
earlier errors, bailing out`.

[Bug c++/109640] Spurious Wdangling-reference for argument to temporary lambda cast to rvalue reference

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Last reconfirmed||2024-01-18
 Ever confirmed|0   |1

[Bug middle-end/113415] ICE: RTL check: -mstringop-strategy=byte_loop vs inline-asm goto with block copies

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||inline-asm
  Known to fail||11.1.0, 13.2.0

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> This might fail the same way:

It fails in the same way. And it has failed since asm goto was added too.

[Bug tree-optimization/113466] ICE: verify_flow_info failed: returns_twice call is not first in basic block 7 with a __returns_twice__ function with _BitInt() argument

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-18
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

  _7 = VIEW_CONVERT_EXPR<_BitInt(313)>(bitint.2);

is placed in the same BB as the call to foo.

[Bug c++/111410] Bogus Wdangling-reference warning with ranges pipe expression in for loop

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

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

--- Comment #1 from Marek Polacek  ---
Thanks for the report.  I think we should disable the warning for operator|
coming from std::ranges.

[Bug tree-optimization/69807] FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of SCoPs: 0" 1

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

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

--- Comment #4 from John David Anglin  ---
Fixed for hppa64-hp-hpux11.11 on trunk.

[Bug tree-optimization/69807] FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of SCoPs: 0" 1

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by John David Anglin :

https://gcc.gnu.org/g:0c7c65c4c359f8bfa1ebcb7b1c409af314064da2

commit r14-8260-g0c7c65c4c359f8bfa1ebcb7b1c409af314064da2
Author: John David Anglin 
Date:   Thu Jan 18 22:46:19 2024 +

hppa: Always enable PIE on 64-bit target

2024-01-18  John David Anglin  

gcc/ChangeLog:

PR tree-optimization/69807
* config/pa/pa.cc (pa_option_override): Set flag_pie on
TARGET_64BIT.

gcc/testsuite/ChangeLog:

* gcc.dg/pic-2.c: Skip on hppa*64*-*-*.

[Bug middle-end/113494] [14 Regression] ICE (segfault) in slpeel_tree_duplicate_loop_to_edge_cfg since r14-8206-g0f38666680d6ad0e

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-01-18

--- Comment #1 from Andrew Pinski  ---
Looks like it also caused the same ICE with AVX512 enabled:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643395.html

[Bug c/113489] aarch64: ICE on gcc/gcc/tree-vect-slp.cc

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

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #2 from Christophe Lyon  ---
(In reply to Adhemerval Zanella from comment #0)

> 
> The configuration used can be found at
> https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-aarch64-build/
> 1215/artifact/artifacts/08-build_abe-stage2/console.log.xy (line 356).

There's a typo in the link, it should end with '.xz' not '.xy':
https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-aarch64-build/1215/artifact/artifacts/08-build_abe-stage2/console.log.xz


Anyway we now extract the configure / make commands, the relevant one is at
step 08-build_abe-stage2 in
https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-aarch64-build/1215/artifact/artifacts/notify/configure-make.txt

[Bug middle-end/113494] [14 Regression] ICE (segfault) in slpeel_tree_duplicate_loop_to_edge_cfg since r14-8206-g0f38666680d6ad0e

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug debug/113481] avr: internal compiler error in decompose, at rtl.h:2298

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

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

--- Comment #10 from Andrew Pinski  ---
Note the code in dw2_asm_output_data has been zeroing the top bits on value
since at least 2001. So I really doubt this is a new issue. It just folks are
now testing with checking enabled more it seems.

[Bug debug/113481] avr: internal compiler error in decompose, at rtl.h:2298

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

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

--- Comment #9 from Andrew Pinski  ---
This fixes the ICE but I am not 100% sure it is correct:
```
diff --git a/gcc/dwarf2asm.cc b/gcc/dwarf2asm.cc
index 6c835bafbc4..7bd9c5f8bcc 100644
--- a/gcc/dwarf2asm.cc
+++ b/gcc/dwarf2asm.cc
@@ -146,11 +146,11 @@ dw2_asm_output_data (int size, unsigned HOST_WIDE_INT
value,

   va_start (ap, comment);

-  if (size * 8 < HOST_BITS_PER_WIDE_INT)
-value &= ~(HOST_WIDE_INT_M1U << (size * 8));
-
   if (op)
 {
+  if (size * 8 < HOST_BITS_PER_WIDE_INT)
+   value &= ~(HOST_WIDE_INT_M1U << (size * 8));
+
   fputs (op, asm_out_file);
   fprint_whex (asm_out_file, value);
 }

```

[Bug middle-end/113494] New: [14 Regression] ICE (segfault) in slpeel_tree_duplicate_loop_to_edge_cfg since r14-8206-g0f38666680d6ad0e

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

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

Bug ID: 113494
   Summary: [14 Regression] ICE (segfault) in
slpeel_tree_duplicate_loop_to_edge_cfg since
r14-8206-g0f3880d6ad0e
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following fails on aarch64:

./xgcc -B . -c
~/toolchain/src/gcc/gcc/testsuite/gcc.c-torture/execute/20150611-1.c -S -o
/dev/null -O3
during GIMPLE pass: vect
/home/alecop01/toolchain/src/gcc/gcc/testsuite/gcc.c-torture/execute/20150611-1.c:
In function ‘main’:
/home/alecop01/toolchain/src/gcc/gcc/testsuite/gcc.c-torture/execute/20150611-1.c:5:1:
internal compiler error: Segmentation fault
5 | main ()
  | ^~~~
0x30bdd30 crash_signal
/home/alecop01/toolchain/src/gcc/gcc/toplev.cc:317
0x7f38d1b6708f ???
   
/build/glibc-wuryBv/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x26e6cf6 gimple_phi_result(gphi const*)
/home/alecop01/toolchain/src/gcc/gcc/gimple.h:4608
0x34b7f10 slpeel_tree_duplicate_loop_to_edge_cfg(loop*, edge_def*, loop*,
edge_def*, edge_def*, edge_def**, bool, vec*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop-manip.cc:1751
0x34bceea vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*, tree_node**,
tree_node**, tree_node**, int, bool, bool, tree_node**)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop-manip.cc:3342
0x34a85f3 vect_transform_loop(_loop_vec_info*, gimple*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop.cc:11929
0x34fdcda vect_transform_loops
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.cc:1006
0x34fe445 try_vectorize_loop_1
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.cc:1152
0x34fe57e try_vectorize_loop
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.cc:1182
0x34fe844 execute
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.cc:1298
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 debug/113481] avr: internal compiler error in decompose, at rtl.h:2298

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |debug

--- Comment #8 from Andrew Pinski  ---
(note 21 19 24 (var_location num (const_int -3355444 [0xffcc]))
NOTE_INSN_VAR_LOCATION)


It is sign extended in the RTL.

[Bug middle-end/113481] avr: internal compiler error in decompose, at rtl.h:2298

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-18
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Component|debug   |middle-end

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

(gdb) p x.first
$1 = (rtx_def *) 0x77542b50
(gdb) p debug_rtx(x.first)
(const_int 13421772 [0xcc])


Definitely not sign extended like it should be.

[Bug fortran/113471] [14 regression] wrong array bound check failure on valid code

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #3)
> Thanks for the quick reaction, indeed with your fix, all our tests do work
> again when all check flags are switched on (we don't do it in our CI with
> gfortran, but with only with nagfor, so I just noticed it now).

Great!  And thanks for the quick feedback!

I'll package the fix tomorrow.

[Bug fortran/113471] [14 regression] wrong array bound check failure on valid code

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #3 from Jürgen Reuter  ---
(In reply to anlauf from comment #2)
> The following patch fixes the reduced testcase for me, as well as the
> full testcase in comment#0:
> 
> diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
> index 26e7adaa03f..3e1a400fa33 100644
> --- a/gcc/fortran/trans-array.cc
> +++ b/gcc/fortran/trans-array.cc
> @@ -3600,7 +3600,9 @@ array_bound_check_elemental (gfc_se * se, gfc_ss * ss,
> gfc_expr * expr)
> continue;
>   }
>  
> -   if (ref->type == REF_ARRAY && ref->u.ar.dimen > 0)
> +   if (ref->type == REF_ARRAY
> +   && ref->u.ar.type == AR_SECTION
> +   && ref->u.ar.dimen > 0)
>   {
> ar = >u.ar;
> for (dim = 0; dim < ar->dimen; dim++)
> 
> Can you give it a spin?

Thanks for the quick reaction, indeed with your fix, all our tests do work
again when all check flags are switched on (we don't do it in our CI with
gfortran, but with only with nagfor, so I just noticed it now).

[Bug c++/111410] Bogus Wdangling-reference warning with ranges pipe expression in for loop

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-18
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

[Bug c++/111607] False positive -Wdangling-reference

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

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=113256
   Last reconfirmed||2024-01-18
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Marek Polacek  ---
Thanks for the report.  I suppose we should not warn when the argument is a
lambda type.  This might also fix bug 113256.

--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -14123,7 +14123,8 @@ do_warn_dangling_reference (tree expr, bool arg_p)
   tree e = expr;
   while (handled_component_p (e))
e = TREE_OPERAND (e, 0);
-  if (!reference_like_class_p (TREE_TYPE (e)))
+  if (!reference_like_class_p (TREE_TYPE (e))
+ && !LAMBDA_TYPE_P (TREE_TYPE (e)))
return expr;
 }

@@ -14180,10 +14181,10 @@ do_warn_dangling_reference (tree expr, bool arg_p)
   initializing this reference parameter.  */
if (do_warn_dangling_reference (arg, /*arg_p=*/true))
  return expr;
- /* Don't warn about member function like:
+ /* Don't warn about member functions like:
  std::any a(...);
  S& s = a.emplace({0}, 0);
-which constructs a new object and returns a reference to it, but
+which construct a new object and return a reference to it, but
 we still want to detect:
   struct S { const S& self () { return *this; } };
   const S& s = S().self();

[Bug target/113486] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -mgeneral-regs-only and __builtin_apply() on aarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-January
   ||/643394.html

--- Comment #3 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643394.html

[Bug other/113317] New test case libgomp.c++/ind-base-2.C fails with ICE

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

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

--- Comment #6 from seurer at gcc dot gnu.org ---
>From experimenting this seems to be an issue with the system compiler

gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04) 

I tried an older compiler (8.4) and it worked ok.

I just experimented a bit and it fails with the current gcc 11 and 12 used as
the build compiler as well.  It works when I use gcc 13.

[Bug fortran/67277] segfault when passing a missing optional argument to an elemental intrinsic

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:09301f083d86b04753d93e84dc1b8a313285e40a

commit r13-8239-g09301f083d86b04753d93e84dc1b8a313285e40a
Author: Harald Anlauf 
Date:   Sat Jan 13 22:00:21 2024 +0100

Fortran: intrinsic ISHFTC and missing optional argument SIZE [PR67277]

gcc/fortran/ChangeLog:

PR fortran/67277
* trans-intrinsic.cc (gfc_conv_intrinsic_ishftc): Handle optional
dummy argument for SIZE passed to ISHFTC.  Set default value to
BIT_SIZE(I) when missing.

gcc/testsuite/ChangeLog:

PR fortran/67277
* gfortran.dg/ishftc_optional_size_1.f90: New test.

(cherry picked from commit 20da56165273c8814b3c53e6d71549ba6a37e0cd)

[Bug c++/113256] False -Wdangling-reference positive

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-01-18
 Ever confirmed|0   |1

[Bug other/111287] doc: "strict ISO mode" definition is not up-to-date

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

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

--- Comment #3 from Joseph S. Myers  ---
"even in strict ISO C90 mode" is used, correctly, when referring to C90 mode as
the one with the fewest built-in functions; it's talking about __builtin_*,
which are valid in all standards modes.

"except in strict ISO C90 mode" is used, correctly, when talking about built-in
versions of C99 functions (accepted in all modes other than strict C90).

__STRICT_ANSI__ is properly defined for strict ISO C modes (any version).

The "Outside strict ISO C mode" paragraph mostly lists functions not in any
version of the C standard, but a few of them (exp10, roundeven, strdup, etc.)
are in C23 and thus defined using DEF_C23_BUILTIN, and arguably should be moved
to a separate paragraph to reflect that they are defined in strict ISO C23
mode.

[Bug other/111287] doc: "strict ISO mode" definition is not up-to-date

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #2 from sandra at gcc dot gnu.org ---
I think the problem here goes beyond this one line of documentation.  E.g,
there's a reference to "strict ISO C90 mode" later in the same paragraph that
probably ought to refer to any later C standard as well, and it's not clear
whether "Outside strict ISO C mode" means that these builtins are always
available in C++.  (IOW, does strict ISO C mode disable things that are
otherwise normally supported by C-family dialects, or do non-strict ISO C mode
enable things that are normally are *not* supported?)

Re __STRICT_ANSI__, invoke.texi only says that is defined when -ansi is used,
so either defining it for all those later standards is wrong or the
documentation is wrong (and it needs to be moved out of the description of the
-ansi option).

I think we at least need a formal definition in the manual of what "strict ISO
mode" means, for both C and C++, and to implement/document additional #defines
for different dialects.  It's probably too late to fix __STRICT_ANSI__, though.

In any case, I think the standards compliance section, the -std= options
documentation, and the builtins section all need to be made consistent.

[Bug target/113484] Add support for _Float16 type on PowerPC

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

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

--- Comment #1 from Joseph S. Myers  ---
It would of course be necessary to define the ABI used for _Float16 (and
_Complex _Float16) argument passing and return (in each PowerPC ABI for which
we support use of this feature).

[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:5240df78a07303a37b1f0b83165624d2a648089e

commit r13-8238-g5240df78a07303a37b1f0b83165624d2a648089e
Author: Jonathan Wakely 
Date:   Wed Jan 17 21:40:25 2024 +

libstdc++: Fix std::format test for Solaris [PR113450]

When int8_t is a typedef for char (rather than signed char) this test
fails because it tries to format a char, which is treated differently
from formatting other integral types (including signed char).

Use signed char explicitly so the result doesn't depend on the
non-portable definition of int8_t.

libstdc++-v3/ChangeLog:

PR libstdc++/113450
* testsuite/std/format/functions/format.cc: Use signed char
instead of int8_t.

(cherry picked from commit db42a0a98916340af8c08e6a7d328121b958)

[Bug testsuite/113366] g++.dg/cpp2a/concepts-pr67774.C FAIL

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:35000c65470792aed3a3c23a3b3fc45db4bec2c4

commit r13-8237-g35000c65470792aed3a3c23a3b3fc45db4bec2c4
Author: Jonathan Wakely 
Date:   Sat Jan 13 12:13:33 2024 +

libstdc++: Use variable template to fix -fconcepts-ts error [PR113366]

There's an error for -fconcepts-ts due to using a concept where a bool
NTTP is required, which is fixed by using the vraiable template that
already exists in the class scope.

This doesn't fix the problem with -fconcepts-ts as changes to the
placement of attributes is also needed.

libstdc++-v3/ChangeLog:

PR testsuite/113366
* include/std/format (basic_format_arg): Use __formattable
variable template instead of __format::__formattable_with
concept.

(cherry picked from commit 6c703b4eb68cbc32de1d62e5b573cb1b9857af29)

[Bug testsuite/113437] [14 Regression] gcc.dg/tree-ssa/pr95906.c fails on arm since g:6686e16fda4

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

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #4 from John David Anglin  ---
Also FAILS on 32 and 64-bit HPPA.

[Bug debug/113481] avr: internal compiler error in decompose, at rtl.h:2298

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

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

--- Comment #6 from Georg-Johann Lay  ---
This is as simple as it gets:

void Afun5 (__uint24 num)
{
  __asm volatile ("" :: "r" (num));
}

void func (void)
{
  Afun5 (0xcc);
}

[Bug tree-optimization/113493] New: FAIL: gcc.dg/tree-ssa/slsr-13.c scan-tree-dump-times optimized

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

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

Bug ID: 113493
   Summary: FAIL: gcc.dg/tree-ssa/slsr-13.c scan-tree-dump-times
optimized
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

Created attachment 57148
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57148=edit
Tree dump

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/xgcc
-B/home/dave/gnu/gcc/o
bjdir64/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/slsr-13.c
-fdi
agnostics-plain-output -O3 -fdump-tree-optimized -S -o slsr-13.s
Executing on host: /home/dave/gnu/gcc/objdir64/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir64/gcc/  exceptions_enabled9669.cc-fdiagnostics-plain-output 
-Wno-compla
in-wrong-lang -S -o exceptions_enabled9669.s(timeout = 300)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/xgcc
-B/home/dave/gnu/gcc/o
bjdir64/gcc/ exceptions_enabled9669.cc -fdiagnostics-plain-output
-Wno-complain-
wrong-lang -S -o exceptions_enabled9669.s
PASS: gcc.dg/tree-ssa/slsr-13.c (test for excess errors)
gcc.dg/tree-ssa/slsr-13.c: pattern found 0 times
FAIL: gcc.dg/tree-ssa/slsr-13.c scan-tree-dump-times optimized " \\* 4" 2
gcc.dg/tree-ssa/slsr-13.c: pattern found 2 times
FAIL: gcc.dg/tree-ssa/slsr-13.c scan-tree-dump-times optimized " \\* 5" 0

This has been around since at least gcc-12.

[Bug c/113492] New: [14 Regression] ICE: in composite_type_internal, at c/c-typeck.cc:557 with -std=c2x -funsigned-bitfields

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113492
   Summary: [14 Regression] ICE: in composite_type_internal, at
c/c-typeck.cc:557 with -std=c2x -funsigned-bitfields
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 57147
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57147=edit
reduced testcase (from gcc.dg/c23-tag-composite-3.c)

Compiler output:
$ x86_64-pc-linux-gnu-gcc -std=c2x -funsigned-bitfields testcase.c 
testcase.c: In function 'foo':
testcase.c:11:3: internal compiler error: in composite_type_internal, at
c/c-typeck.cc:557
   11 |   1 ? a : c;
  |   ^
0x6eabe7 composite_type_internal(tree_node*, tree_node*, composite_cache*)
/repo/gcc-trunk/gcc/c/c-typeck.cc:557
0xe267e0 composite_type(tree_node*, tree_node*)
/repo/gcc-trunk/gcc/c/c-typeck.cc:748
0xe267e0 build_conditional_expr(unsigned int, tree_node*, bool, tree_node*,
tree_node*, unsigned int, tree_node*, tree_node*, unsigned int)
/repo/gcc-trunk/gcc/c/c-typeck.cc:5733
0xe59a26 c_parser_conditional_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:9238
0xe59d64 c_parser_expr_no_commas
/repo/gcc-trunk/gcc/c/c-parser.cc:9072
0xe5a1c1 c_parser_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:12762
0xe5a697 c_parser_expression_conv
/repo/gcc-trunk/gcc/c/c-parser.cc:12802
0xe7c5ef c_parser_statement_after_labels
/repo/gcc-trunk/gcc/c/c-parser.cc:7761
0xe516c6 c_parser_compound_statement_nostart
/repo/gcc-trunk/gcc/c/c-parser.cc:7248
0xe78d44 c_parser_compound_statement
/repo/gcc-trunk/gcc/c/c-parser.cc:6533
0xe7b058 c_parser_declaration_or_fndef
/repo/gcc-trunk/gcc/c/c-parser.cc:3017
0xe84c9b c_parser_external_declaration
/repo/gcc-trunk/gcc/c/c-parser.cc:2046
0xe85683 c_parser_translation_unit
/repo/gcc-trunk/gcc/c/c-parser.cc:1900
0xe85683 c_parse_file()
/repo/gcc-trunk/gcc/c/c-parser.cc:26815
0xefb1b1 c_common_parse_file()
/repo/gcc-trunk/gcc/c-family/c-opts.cc:1301
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

I would even say that with -funsigned-bitfields, the code is valid, but I am
not a language lawyer.
gcc-13, or gcc-14 without -std=2x, rejects the code though. On the other hand,
changing the "unsigned" to "signed", makes the code to be accepted, with the
default "signed" bitfields, so "int" and "signed" bitfield types are equal;
maybe my understanding of the "-funsigned-bitfields" as "any plain 'int'
bitfield is 'unsigned'" is incorrect.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8251-20240118071416-g48c8d26d771-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8251-20240118071416-g48c8d26d771-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240118 (experimental) (GCC)

[Bug target/113484] Add support for _Float16 type on PowerPC

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug analyzer/113150] FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c -std=c++98 (test for excess errors)

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

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

--- Comment #3 from Iain Sandoe  ---
on darwin we also get (all with the same diagnostic - about a leaked fd)

I can report them separately if you like - but it seems likely to be a common
cause:

FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c  -std=c++98 (test for
excess errors)
FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c  -std=c++14 (test for
excess errors)
FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c  -std=c++17 (test for
excess errors)
FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c  -std=c++20 (test for
excess errors)
FAIL: c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c  -std=c++98 (test
for excess errors)
FAIL: c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c  -std=c++14 (test
for excess errors)
FAIL: c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c  -std=c++17 (test
for excess errors)
FAIL: c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c  -std=c++20 (test
for excess errors)
FAIL: c-c++-common/analyzer/fd-mappage-getaddrinfo-server.c  -std=c++98 (test
for excess errors)
FAIL: c-c++-common/analyzer/fd-mappage-getaddrinfo-server.c  -std=c++14 (test
for excess errors)
FAIL: c-c++-common/analyzer/fd-mappage-getaddrinfo-server.c  -std=c++17 (test
for excess errors)
FAIL: c-c++-common/analyzer/fd-mappage-getaddrinfo-server.c  -std=c++20 (test
for excess errors)
FAIL: c-c++-common/analyzer/fd-symbolic-socket.c  -std=c++98 (test for excess
errors)
FAIL: c-c++-common/analyzer/fd-symbolic-socket.c  -std=c++14 (test for excess
errors)
FAIL: c-c++-common/analyzer/fd-symbolic-socket.c  -std=c++17 (test for excess
errors)
FAIL: c-c++-common/analyzer/fd-symbolic-socket.c  -std=c++20 (test for excess
errors)