[Bug target/107316] [aarch64] Init big const value should be improved compare to llvm

[zhongyunde at huawei dot com via Gcc-bugs]

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

--- Comment #2 from vfdff  ---
(In reply to Andrew Pinski from comment #1)
> I suspect this is just a dup of bug 106583 and will be fixed by the patch
> which was submitted recently
> (https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603905.html).

Thanks very much, I'll check that after the patch will be committed to the
upstream.

[Bug c/107359] New: [aarch64] should avoid the punpklo/punpkhi compare to llvm

[zhongyunde at huawei dot com via Gcc-bugs]

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

Bug ID: 107359
   Summary: [aarch64] should avoid the punpklo/punpkhi compare to
llvm
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

* case, https://godbolt.org/z/38bcszxdo
```
int check (char *mask, double *result, int n) {
int count = 0;
for (int i=0; i

[Bug c++/105823] -Wrestrict / -Wstringop-overflow / -Warray-bounds warnings for uninitialized values

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

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

--- Comment #1 from Andrew Pinski  ---
Note the parentheses changes from a xvalue to an rvalue in C++11+ IIRC which
might be why there is an effect here ...

[Bug target/106095] Some AVX builtins produce invalid asm with -masm=intel

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/104490] Cannot inherit consteval constructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug libstdc++/104056] --disable-hosted-libstdcxx does not work for x86_64-linux-gnu

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #3 from cqwrteur  ---
Can --disable-hosted-libstdcxx disable Link tests are not allowed after
GCC_NO_EXECUTABLES. on all targets???

[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)

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

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

--- Comment #3 from Sergei Trofimovich  ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 53757 [details]
> gcc13-pr107358.patch
> 
> Untested fix.

The proposed patch fixes libjxl-0.7.0 build for me.

[Bug c++/102258] dynamic_cast to derived type fails during constant evaluation

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=106107
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-22

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

[Bug c++/106107] dynamic_cast for polymorphic types fail within constant expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=93413
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-22
 Ever confirmed|0   |1
Summary|dynamic_cast fail within|dynamic_cast for
   |constant expression |polymorphic types fail
   ||within constant expression

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

[Bug c++/106109] [12/13 Regression] ICE with auto and pointer to method

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.2
Summary|Internal compiler error |[12/13 Regression] ICE with
   ||auto and pointer to method
   Keywords||ice-on-valid-code

[Bug tree-optimization/101991] bit_and or bit_ior with an invariant inside loop is not pulled out of the loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |13.0

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

[Bug target/107356] -fcompare-debug failure (length) with -fsanitize=undefined

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

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

--- Comment #1 from Andrew Pinski  ---
long double uses x87 and reg-stack.cc still.  So a target issue.

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

--- Comment #45 from Segher Boessenkool  ---
Yes, that is fine afaics.

[Bug c++/105774] Bogus overflow in constant expression with signed char++

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

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

--- Comment #4 from Andrew Pinski  ---
And one for short:
constexpr signed short f(void){
signed short x = 0x7fff;
return ++x;
}
int main() {
constexpr auto _ = f();
}

[Bug c++/105774] Bogus overflow in constant expression with signed char++

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Bogus overflow in constant  |Bogus overflow in constant
   |expression with char++  |expression with signed
   ||char++
  Known to fail||5.1.0

--- Comment #3 from Andrew Pinski  ---
Here is a C++14 testcase (lambdas were not constexpr in C++14) which shows the
issue has been there since GCC 5 (which didn't have C++17 support):
constexpr signed char f(void){
signed char x = 127;
return ++x;
}
int main() {
constexpr auto _ = f();
}

[Bug c++/99241] [modules] ICE in install_entity, at cp/module.cc:7584

[cgreeley at student dot bridgew.edu via Gcc-bugs]

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

--- Comment #7 from Christopher Greeley  
---
Created attachment 53759
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53759=edit
The pre processed header I tried to import into my module and the module code

This is the preprocessed header, -E on the module file only gives: 
"g++: warning: Source/Common.mpp: linker input file unused because linking not
done"

[Bug c++/99241] [modules] ICE in install_entity, at cp/module.cc:7584

[cgreeley at student dot bridgew.edu via Gcc-bugs]

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

--- Comment #6 from Christopher Greeley  
---
When I say the compiler segfaulted, it is similar too:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99238

[Bug c++/99241] [modules] ICE in install_entity, at cp/module.cc:7584

[cgreeley at student dot bridgew.edu via Gcc-bugs]

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

Christopher Greeley  changed:

   What|Removed |Added

 CC||cgreeley at student dot 
bridgew.ed
   ||u

--- Comment #5 from Christopher Greeley  
---
This is still an issue for me using the latest GCC 13 snapshot 
"gcc-latest_13.0.0-20221016git6366e3e8847a.deb"
from: https://jwakely.github.io/pkg-gcc-latest/

I was getting segfaults when compiling modules with 11/12.1/12.2

No more segfaults but importing some include files are giving me trouble namely
trying to include: 

https://github.com/peter-winter/ctpg/blob/6ab0502fc8cffa128bb8ff383f1c4b13cf21b86a/include/ctpg/ctpg.hpp

I am using xmake: 

https://tboox.org/2022/08/25/xmake-update-v2.7.1/

root@fe9917e74f33:~/workdir# xmake
[  0%]: generating.cxx.module.deps Source/Common.mpp
[ 26%]: generating.cxx.headerunit.bmi ctpg/ctpg.hpp
error: In file included from /opt/gcc-latest/include/c++/13.0.0/ios:43,
 from /opt/gcc-latest/include/c++/13.0.0/ostream:40,
 from
/root/.conan/data/ctpg/1.3.7/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include/ctpg/ctpg.hpp:14:
/opt/gcc-latest/include/c++/13.0.0/bits/localefwd.h:156:48: internal compiler
error: in install_entity, at cp/module.cc:7611
  156 |   template >
  |^~~
0x9aeda3 trees_in::install_entity(tree_node*)
../../gcc/cp/module.cc:7611
0x9c04e1 trees_in::decl_value()
../../gcc/cp/module.cc:8125
0x9c2597 trees_in::tree_node(bool)
../../gcc/cp/module.cc:9325
0x9cb4db module_state::read_cluster(unsigned int)
../../gcc/cp/module.cc:15025
0x9cb895 module_state::load_section(unsigned int, binding_slot*)
../../gcc/cp/module.cc:18397
0x9cba77 lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*)
../../gcc/cp/module.cc:19105
0x9e0c52 name_lookup::search_namespace_only(tree_node*)
../../gcc/cp/name-lookup.cc:920
0x9e2bdb name_lookup::search_unqualified(tree_node*, cp_binding_level*)
../../gcc/cp/name-lookup.cc:1142
0x9eb283 lookup_name(tree_node*, LOOK_where, LOOK_want)
../../gcc/cp/name-lookup.cc:7562
0x9f793d lookup_name(tree_node*, LOOK_want)
../../gcc/cp/name-lookup.h:402
0x9f793d cp_parser_lookup_name
../../gcc/cp/parser.cc:30746
0xa3103e cp_parser_template_name
../../gcc/cp/parser.cc:18619
0xa31770 cp_parser_template_id
../../gcc/cp/parser.cc:18227
0xa3220e cp_parser_class_name
../../gcc/cp/parser.cc:25825
0xa2b23f cp_parser_qualifying_entity
../../gcc/cp/parser.cc:7186
0xa2b23f cp_parser_nested_name_specifier_opt
../../gcc/cp/parser.cc:6866
0xa27adc cp_parser_simple_type_specifier
../../gcc/cp/parser.cc:19805
0xa152ad cp_parser_type_specifier
../../gcc/cp/parser.cc:19463
0xa17155 cp_parser_type_specifier_seq
../../gcc/cp/parser.cc:24431
0xa23239 cp_parser_type_id_1
../../gcc/cp/parser.cc:24226
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.

g++ (GCC) 13.0.0 20221016 (experimental)

GCC 12.1/12.2 was still giving me these problems, I think 11 did too.

[Bug preprocessor/88974] [9 Regression] ICE: Segmentation fault (in linemap_resolve_location)

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---
(In reply to Jakub Jelinek from comment #6)
> And this updated patch, while it bootstrapped, had quite a few testsuite
> regressions.  So, I'm afraid I don't know where would in some cases the
> src_loc be preinitialized from earlier and where it wouldn't.  Mystery.

Thanks for looking into this. It doesn't look all that important to me,
but, for the record, it is still producing valgrind errors over 2 years later:

./c-c++-common/cpp/pr88974.c:4:31: error: missing terminating > character
4 | #if __has_include (

[Bug tree-optimization/107342] Optimization opportunity where integer '/' corresponds to '>>'

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

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

Aldy Hernandez  changed:

   What|Removed |Added

  Attachment #53749|0   |1
is obsolete||

--- Comment #3 from Aldy Hernandez  ---
Created attachment 53758
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53758=edit
tested

[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-22
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 53757
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53757=edit
gcc13-pr107358.patch

Untested fix.

[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC|jakub at redhat dot com|

--- Comment #1 from Jakub Jelinek  ---
I think that is the preexisting C issue I've talked about in
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603265.html
typedef float __attribute__((vector_size (16))) float32x4_t;
float32x4_t foo(float32x4_t x, float y) { return x + y; }
where C also fails for years with -fexcess-precision=standard.

[Bug c++/106644] [C++23] P2468R2 - The Equality Operator You Are Looking For

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

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

--- Comment #3 from Jakub Jelinek  ---
As for implementation, I'd say in call.cc (add_candidates) we could do
something like:
  if ((flags & (LOOKUP_REWRITTEN | LOOKUP_REVERSE))
  && DECL_OVERLOADED_OPERATOR_IS (fn, EQ_EXPR))
{
}

before the loop on the overloads and depending on whether fn is in class scope
or namespace scope perform lookup (again argument dependent or not?) for
ovl_op_identifier (false, NE_EXPR) in the same scope.
But am not really sure what to do next if this finds something (supposedly in
the loop over the overloads?); I suppose if no template is involved, compare
the argument types (what else?), but for templates it is unclear (to me) if it
should try to instantiate them and compare types only afterwards, or what
exactly should be checked whether they correspond ([basic.scope.scope]).
Because e.g. http://eel.is/c++draft/basic.scope.scope#4.3.1 talks about
equivalent trailing requires clauses etc.

[Bug c++/106644] [C++23] P2468R2 - The Equality Operator You Are Looking For

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

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

--- Comment #2 from Jakub Jelinek  ---
The A-J cases are from the paper to be precise.

[Bug c++/107358] New: [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)

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

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

Bug ID: 107358
   Summary: [13 Regression] i686-linux: Since
r13-3290-g98e341130f8798 code fails to build
libjxl-0/7.0 (vector float code)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jakub at redhat dot com
  Target Milestone: ---

Initially observed build failure on libjxl-0.7.0 on i686-linux target.

Seems to happen only on i686-unknown-linux-gnu and only on -std=c++11.

PR107295 does not seem to be enough to fix it. Here is the minimal example:

// $ cat skcms.cc
// this works:
float approx_scal(float e) {
return e - 124.225514990f;
}

typedef float __attribute__((vector_size(4*sizeof(float F;

// this fails:
//   error: conversion of scalar 'long double' to vector 'F' {aka '__vector(4)
float'} involves truncation
F approx_vec(F e) {
return e - 124.225514990f;
//return e - 1.0f; // this works, does 'f' get ignored when float does not
fit?
}


$ g++-13 -fPIC -std=c++11 -o skcms.cc.o -c skcms.cc
skcms.cc: In function 'F approx_vec(F)':
skcms.cc:10:17: warning: SSE vector return without SSE enabled changes the ABI
[-Wpsabi]
   10 | F approx_vec(F e) {
  | ^
skcms.cc:11:14: error: conversion of scalar 'long double' to vector 'F' {aka
'__vector(4) float'} involves truncation
   11 | return e - 124.225514990f;
  |~~^~~~

$ g++-12 -fPIC -std=c++11 -o skcms.cc.o -c skcms.cc
skcms.cc: In function 'F approx_vec(F)':
skcms.cc:10:17: warning: SSE vector return without SSE enabled changes the ABI
[-Wpsabi]
   10 | F approx_vec(F e) {
  | ^
skcms.cc:10:3: note: the ABI for passing parameters with 16-byte alignment has
changed in GCC 4.6
   10 | F approx_vec(F e) {
  |   ^~
skcms.cc:10:3: warning: SSE vector argument without SSE enabled changes the ABI 

Note: gcc-12 works, gcc-13 fails.

[Bug c++/106644] [C++23] P2468R2 - The Equality Operator You Are Looking For

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
FYI, clang trunk now implements this DR.

Rough testcase distilled from the paper + some extra tests from the LLVM test
coverage of the paper, with just // ERR
to mark expected diagnostics (details to be filled only once it is
implemented).

// P2468R2 - The Equality Operator You Are Looking For
// { dg-do compile { target c++20 } }

struct A {
  bool operator== (const A &) { return true; }
  bool operator!= (const A &) { return false; }
};
bool a = A{} != A{};

template 
struct B {
  bool operator== (const T &) const;
  bool operator!= (const T &) const;
};
struct B1 : B { };
bool b1 = B1{} == B1{};
bool b2 = B1{} != B1{};

template 
struct C {
  using C1 = C;
  using C2 = C;
  C () = default;
  C (const C2 &);
  bool operator== (C1) const;
  bool operator!= (C1) const;
};
using C3 = C;
bool c = C3{} == C3{};

struct D {
  D ();
  D (int *);
  bool operator== (const D &) const;
  operator int * () const;
};
bool d = nullptr != D{};// ERR

struct E {
  operator bool () const;
};
unsigned char operator== (E, E);
unsigned char e = E{} != E{};   // ERR

struct F {};
template 
bool operator== (F, T);
bool f1 = 0 == F ();
template 
bool operator!= (F, T);
bool f2 = 0 == F ();// ERR

struct G {
  bool operator== (const G &);
};
struct G1 : G {
  G1 ();
  G1 (G);
  bool operator!= (const G &);
};
bool g1 = G () == G1 ();
bool g2 = G1 () == G ();// ERR

struct H {};
template 
bool operator== (H, T);
inline namespace H1 {
  template 
  bool operator!= (H, T);
}
bool h = 0 == H ();

template 
struct I {
  int operator== (const double &) const;
  friend inline int operator== (const double &, const T &) { return 1; }
};
struct I1 : I { };
bool i = I1{} == 0.;// ERR

struct J {
  bool operator== (const J &) const;
  bool operator!= (const J &) const;
};
struct J1 : J {
  J1 (const J &);
  bool operator== (const J1 ) const {
return static_cast (*this) == x; // ERR
  }
};

struct K {
  bool operator== (const K &);
};
bool k = K{} == K{};// ERR

struct L {
  bool operator== (const L &) const;
};
bool l = L{} == L{};

struct M {
  bool operator== (M);
};
bool m = M () == M ();

struct N {
  virtual bool operator== (const N &) const;
};
struct N1 : N {
  bool operator== (const N &) const override;
};
bool n = N1 () == N1 ();// ERR

struct O {
  virtual signed char operator== (const O &) const;
  signed char operator!= (const O ) const { return !operator== (x); }
};
struct O1 : O {
  signed char operator== (const O &) const override;
};
bool o = O1 () != O1 ();// ERR

template 
bool
foo (T x, T y)
requires requires { x == y; }
{
  return x == y;
}
bool b3 = foo (B1 (), B1 ());

struct P {};
template 
bool operator== (P, T);
template 
bool operator!= (P, T);
bool p = 0 == P ();

struct Q {};
template 
bool operator== (Q, T);
template 
bool operator!= (Q, U);
bool q = 0 == Q (); // ERR

struct R {
  template 
  bool operator== (const T &);
};
bool r = R () == R ();  // ERR

struct S {
  template 
  bool operator== (const T &) const;
  bool operator!= (const S &);
};
bool s = S () == S ();

struct T {};
template 
bool operator== (T, int);
bool operator!= (T, int);
bool t = 0 == T ();

struct U {};
bool operator== (U, int);
bool u1 = 0 == U ();
namespace U1 { bool operator!= (U, int); }
bool u2 = 0 == U ();
using U1::operator!=;
bool u3 = 0 == U ();// ERR

struct V {};
template 
bool operator== (V, T);
bool v1 = 0 == V ();
namespace V1 { template  bool operator!= (V, T); }
bool v2 = 0 == V ();
using V1::operator!=;
bool v3 = 0 == V ();// ERR

template 
struct W {
bool operator== (int) requires (N == 1);
bool operator!= (int) requires (N == 2);
};
int w = 0 == W<1> ();

struct X { 
  bool operator== (X const &);
  static bool operator!= (X const &, X const &);
};
bool x = X () == X ();  // ERR

[Bug middle-end/106799] `forming offset [32, 36] is out of the bounds` error with precompiled headers

[michal at sawicz dot net via Gcc-bugs]

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

--- Comment #4 from michal at sawicz dot net ---
Created attachment 53756
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53756=edit
Preprocessed header source

I believe that should be it.

[Bug other/107357] New: [RISC-V]RVV broken with zve32x/f

[jiawei at iscas dot ac.cn via Gcc-bugs]

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

Bug ID: 107357
   Summary: [RISC-V]RVV  broken with zve32x/f
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiawei at iscas dot ac.cn
  Target Milestone: ---

When build target riscv with arch "rv64gc_zve32x" or "rv64gc_zve32f" it will
got an error:

/root/riscv-gnu-toolchain/gcc/gcc/simplify-rtx.cc:8369:
test_vector_subregs_modes: FAIL: ASSERT_TRUE ((outer_x != (rtx) 0))
cc1: internal compiler error: in fail, at selftest.cc:47
0x1a9f331 selftest::fail(selftest::location const&, char const*)
/root/riscv-gnu-toolchain/gcc/gcc/selftest.cc:47
0xf7e430 test_vector_subregs_modes
/root/riscv-gnu-toolchain/gcc/gcc/simplify-rtx.cc:8369
0xf7e557 test_vector_subregs_repeating
/root/riscv-gnu-toolchain/gcc/gcc/simplify-rtx.cc:8417
0xf84a66 test_vector_subregs
/root/riscv-gnu-toolchain/gcc/gcc/simplify-rtx.cc:8466
0xf84a66 test_vector_ops
/root/riscv-gnu-toolchain/gcc/gcc/simplify-rtx.cc:8487
0xf84a66 selftest::simplify_rtx_cc_tests()
/root/riscv-gnu-toolchain/gcc/gcc/simplify-rtx.cc:8547
0x19b842c selftest::run_tests()
/root/riscv-gnu-toolchain/gcc/gcc/selftest-run-tests.cc:115
0xfa7add toplev::run_self_tests()
/root/riscv-gnu-toolchain/gcc/gcc/toplev.cc:2184

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

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

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

--- Comment #4 from Iain Sandoe  ---
Emulated TLS targets can test targetm.have_tls.

The patch below fixes the fails on Fortran for x86_64-darwin, libgomp in test
now.

I do not really like that it means pulling in the whole of target.h, and
imagine that this will not fix the powerpc64le-linux-gnu cases?

The TLS varieties are "ELF" (AFAIU).. so this would not fix things if/when I
implement native TLS on Darwin (since that has Mach-O semantics for TLS).

so, perhaps there's a better test (or we should make the targetm test more
fine-grained).  In any event we should not test things that pertain to the
platform in the inner loop - but either punt on the whole opt (or choose a
different flavour) for other targets.


diff --git a/gcc/ipa-visibility.cc b/gcc/ipa-visibility.cc
index 3ed2b7cf679..acea49f8b1f 100644
--- a/gcc/ipa-visibility.cc
+++ b/gcc/ipa-visibility.cc
@@ -86,6 +86,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "ipa-utils.h"
 #include "stringpool.h"
 #include "attribs.h"
+#include "target.h"

 /* Return true when NODE cannot be local. Worker for cgraph_local_node_p.  */

@@ -873,7 +874,7 @@ function_and_variable_visibility (bool whole_program)
}
 }

-  if (symtab->state >= IPA_SSA)
+  if (symtab->state >= IPA_SSA && targetm.have_tls)
 {
   FOR_EACH_VARIABLE (vnode)
{

[Bug ada/107309] GNAT does not apply type conversion to dependent expressions of conditional expressions

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Fixing.

[Bug ada/107309] GNAT does not apply type conversion to dependent expressions of conditional expressions

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-10-22
 Status|UNCONFIRMED |NEW
Summary|GNAT does not apply type|GNAT does not apply type
   |conversion rules to |conversion to dependent
   |dependent expressions of|expressions of conditional
   |conditional expressions |expressions
 CC||ebotcazou at gcc dot gnu.org
   Target Milestone|--- |13.0

--- Comment #1 from Eric Botcazou  ---
The RM 4.5.7(10/3) rule is quite irregular but should be applied indeed.

[Bug debug/107356] New: -fcompare-debug failure (length) with -fsanitize=undefined

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 107356
   Summary: -fcompare-debug failure (length) with
-fsanitize=undefined
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: compare-debug-failure
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

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

Maybe related to PR107183

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fsanitize=undefined -fcompare-debug testcase.c
-save-temps
x86_64-pc-linux-gnu-gcc: error: testcase.c: '-fcompare-debug' failure (length)

$ diff -u *gkd
--- a-testcase.c.gkd2022-10-22 10:58:05.863774954 +0200
+++ a-testcase.gk.c.gkd 2022-10-22 10:58:05.893774995 +0200
@@ -15,21 +15,21 @@
 (nil)))
 (note # 0 0 NOTE_INSN_PROLOGUE_END)
 (note # 0 0 NOTE_INSN_FUNCTION_BEG)
+(insn # 0 0 2 (set (reg:SF 8 st)
+(const_double:SF 0.0 [0x0.0p+0])) "testcase.c":6:18# {*movsf_internal}
+ (expr_list:REG_EQUIV (const_double:SF 0.0 [0x0.0p+0])
+(nil)))
 (insn # 0 0 2 (set (reg:XF 8 st)
 (mem/c:XF (plus:DI (reg/f:DI 7 sp)
 (const_int 16 [0x10])) [ f+0 S16 A128])) "testcase.c":6:18#
{*movxf_internal}
  (expr_list:REG_EQUIV (mem/c:XF (reg/f:DI 16 argp) [ f+0 S16 A128])
 (nil)))
-(insn # 0 0 2 (set (reg:SF 8 st)
-(const_double:SF 0.0 [0x0.0p+0])) "testcase.c":6:18# {*movsf_internal}
- (expr_list:REG_EQUIV (const_double:SF 0.0 [0x0.0p+0])
-(nil)))
 (insn # 0 0 2 (set (reg:CCFP 17 flags)
 (unspec:CCFP [
 (compare:CCFP (reg:XF 8 st)
 (reg:XF 9 st(1)))
 ] UNSPEC_NOTRAP)) "testcase.c":6:18# {*cmpiuxf_i387}
- (expr_list:REG_DEAD (reg:XF 8 st)
+ (expr_list:REG_DEAD (reg:XF 8 st [91])
 (nil)))
 (insn # 0 0 2 (set (reg:XF 8 st)
 (reg:XF 8 st)) "testcase.c":6:18# {*movxf_internal}


$ 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-r13-3440-20221021201743-g4cfdaeb2755-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/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-r13-3440-20221021201743-g4cfdaeb2755-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221021 (experimental) (GCC)

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

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Host|powerpc64le-linux-gnu   |powerpc64le-linux-gnu,*-*-d
   ||arwin*
 CC||iains at gcc dot gnu.org
  Build|powerpc64le-linux-gnu   |powerpc64le-linux-gnu,*-*-d
   ||arwin*
 Target|powerpc64le-linux-gnu   |powerpc64le-linux-gnu,*-*-d
   ||arwin*

--- Comment #3 from Iain Sandoe  ---
also on Darwin (and as per Jeff's comment, probably all other emulated TLS
targets).

likely also on any other non-ELF target?

[Bug fortran/107317] [10/11/12/13 Regression] ICE in emit_redzone_byte, at asan.cc:1508

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

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

Thomas Koenig  changed:

   What|Removed |Added

   Priority|P2  |P3

[Bug tree-optimization/106717] [13 Regression] ICE: tree check: expected integer_cst, have poly_int_cst in get_len, at tree.h:6247

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #2 from Arseny Solokha  ---
Indeed, this particular case works now.