[Bug lto/114662] [14 regression] new test case c_lto_pr113359-2 from r14-9841-g1e3312a25a7b34 fails

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

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

Kewen Lin  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 CC||linkw at gcc dot gnu.org
   Last reconfirmed||2024-04-10
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Kewen Lin  ---
I think this is a test issue, with -m32 unsigned long is 4 bytes while CL1,CL2
are 8 bytes constants, then it considers some checks would always fail and the
abort will happen, since the optimization aggressively optimize away the call
to getb, there is no chance to further check "semantic equality". The IR for
main at *.015t.cfg looks like:

int main (int argc, char * * argv)
{
  struct SB b;
  struct SA a;
  int D.3983;

   :
  init ();
  geta (, );
  _1 = a.ax;
  if (_1 != 3735928559)
goto ; [INV]
  else
goto ; [INV]

   :
  __builtin_abort ();

   :
  __builtin_abort ();

}

[Bug middle-end/114653] Not vectorizing the loop with openmp reduction.

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

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

--- Comment #4 from kugan at gcc dot gnu.org ---
This particular loop has loop->safelen set to 16. Does this mean this can never
be loop vectorized for VLA?

[Bug tree-optimization/114672] New: during GIMPLE pass: widening_mul ICE: verify_gimple failed: type mismatch in 'widen_mult_plus_expr' at -O2

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114672
   Summary: during GIMPLE pass: widening_mul ICE: verify_gimple
failed: type mismatch in 'widen_mult_plus_expr' at -O2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

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

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -O2 testcase.c 
testcase.c: In function 'foo':
testcase.c:9:1: error: type mismatch in 'widen_mult_plus_expr'
9 | foo ()
  | ^~~

signed int
signed int

_8 = WIDEN_MULT_PLUS_EXPR <_11, _12, _1>;
during GIMPLE pass: widening_mul
testcase.c:9:1: internal compiler error: verify_gimple failed
0x1396f9d verify_gimple_in_cfg(function*, bool, bool)
/repo/gcc-trunk/gcc/tree-cfg.cc:5663
0x1202df4 execute_function_todo
/repo/gcc-trunk/gcc/passes.cc:2089
0x120334e execute_todo
/repo/gcc-trunk/gcc/passes.cc:2143
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.

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

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |14.0

--- Comment #15 from Xi Ruoyao  ---
(In reply to Yang Yujie from comment #14)
> Is it not really necessary for now, since there is no LSX/LASX support in
> GCC 12 / 13?

So closing the ticket as fixed.

[Bug middle-end/114653] Not vectorizing the loop with openmp reduction.

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

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

--- Comment #3 from kugan at gcc dot gnu.org ---
For SVE mode in vect_analyze_loop_2, we have

(gdb) p min_vf
$15 = {coeffs = {4, 4}}
(gdb) p max_vf
$16 = 16

Thus maybe_lt (max_vf, min_vf)) is false. This results in bad data dependence.

[Bug middle-end/114653] Not vectorizing the loop with openmp reduction.

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

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

--- Comment #2 from kugan at gcc dot gnu.org ---
Thanks. I see the following in the log:
test.cpp:33:53: missed:   not vectorized: relevant stmt not supported: _54 =
.MASK_LOAD (_53, 32B, _171);
test.cpp:22:19: missed:  bad operation or unsupported loop bound.
test.cpp:22:19: note:  * Analysis  failed with vector mode V4SF


test.cpp:22:19: note:   === vect_analyze_data_ref_dependences ===
test.cpp:22:19: missed:  bad data dependence.
test.cpp:22:19: note:  * Analysis  failed with vector mode VNx16QI

test.cpp:33:53: missed:   not vectorized: relevant stmt not supported: _54 =
.MASK_LOAD (_53, 32B, _171);
test.cpp:22:19: missed:  bad operation or unsupported loop bound.
test.cpp:22:19: note:  * Analysis  failed with vector mode V8QI

test.cpp:22:19: note:   === vect_analyze_data_ref_dependences ===
test.cpp:22:19: missed:  bad data dependence.
test.cpp:22:19: note:  * Analysis  failed with vector mode VNx8QI

test.cpp:33:53: missed:   not vectorized: relevant stmt not supported: _54 =
.MASK_LOAD (_53, 32B, _171);
test.cpp:22:19: missed:  bad operation or unsupported loop bound.
test.cpp:22:19: note:  * Analysis  failed with vector mode V4HI

test.cpp:22:19: note:   === vect_analyze_data_ref_dependences ===
test.cpp:22:19: missed:  bad data dependence.
test.cpp:22:19: note:  * Analysis  failed with vector mode VNx4QI

test.cpp:33:53: missed:   not vectorized: relevant stmt not supported: _54 =
.MASK_LOAD (_53, 32B, _171);
test.cpp:22:19: missed:  bad operation or unsupported loop bound.
test.cpp:22:19: note:  * Analysis  failed with vector mode V2SI

test.cpp:22:19: note:   worklist: examine stmt: _57 = D.4803[_20];
test.cpp:22:19: note:   === vect_analyze_data_ref_dependences ===
test.cpp:22:19: missed:  bad data dependence.
test.cpp:22:19: note:  * Analysis  failed with vector mode VNx2QI
test.cpp:22:19: missed: couldn't vectorize loop
test.cpp:22:19: missed: bad data dependence.

[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #13 from Li Pan  ---
overriding TARGET_CLASS_LIKELY_SPILLED_P hook may not be a fix as it will
generate sorts of spill for the below sample code.

vbool2_t test_vmfge_vf_f16m8_b2(vfloat16m8_t op1, float16_t op2, size_t vl) {
  return __riscv_vmfge_vf_f16m8_b2(op1, op2, vl);  
   
 }

need to re-think from the mode-switch side.

[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package

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

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

--- Comment #8 from Kewen Lin  ---
(In reply to Peter Bergner from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > Pre-IRA fix was done to specifically reject this:
> > https://inbox.sourceware.org/gcc-patches/
> > ab3a61990702021658w4dc049cap53de8010a7d86...@mail.gmail.com/
> 
> Then that would seem to indicate that mentioning the frame pointer reg in
> the asm clobber list is an error, but how are users supposed to know whether
> -fno-omit-frame-pointer is in effect or not?  I've looked and there is no
> pre-defined macro a user could check.

I noticed even without -fno-omit-frame-pointer, the test case still fails with
the same symptom (with error msg rather than ICE), did I miss something?

[Bug libfortran/107031] endfile truncates file at wrong position

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

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #11 from Jerry DeLisle  ---
Fixed on trunk, closing.

[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8

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

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

--- Comment #18 from GCC Commits  ---
The master branch has been updated by Peter Bergner :

https://gcc.gnu.org/g:7924e352523b37155ed9d76dc426701de9d11a22

commit r14-9884-g7924e352523b37155ed9d76dc426701de9d11a22
Author: Peter Bergner 
Date:   Tue Apr 9 15:24:39 2024 -0500

rs6000: Replace OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR
[PR101865]

This is a cleanup patch in preparation to fixing the real bug in PR101865.
TARGET_DIRECT_MOVE is redundant with TARGET_P8_VECTOR, so alias it to that.
Also replace all usages of OPTION_MASK_DIRECT_MOVE with
OPTION_MASK_P8_VECTOR
and delete the now dead mask.

2024-04-09  Peter Bergner  

gcc/
PR target/101865
* config/rs6000/rs6000.h (TARGET_DIRECT_MOVE): Define.
* config/rs6000/rs6000.cc (rs6000_option_override_internal):
Replace
OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR.  Delete
redundant
OPTION_MASK_DIRECT_MOVE usage.  Delete TARGET_DIRECT_MOVE dead
code.
(rs6000_opt_masks): Neuter the "direct-move" option.
* config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Replace
OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR.  Delete useless
comment.
* config/rs6000/rs6000-cpus.def (ISA_2_7_MASKS_SERVER): Delete
OPTION_MASK_DIRECT_MOVE.
(OTHER_VSX_VECTOR_MASKS): Likewise.
(POWERPC_MASKS): Likewise.
* config/rs6000/rs6000.opt (mdirect-move): Remove Mask and Var.

[Bug fortran/56744] [meta-bug] Namelist bugs

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

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

Bug 107068 Summary: Run-time error when reading logical arrays with a namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068

   What|Removed |Added

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

[Bug libfortran/107068] Run-time error when reading logical arrays with a namelist

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

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #10 from Jerry DeLisle  ---
Fixed on trunk. Closing.

[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 #15 from Kewen Lin  ---
(In reply to Michael Matz from comment #14)
> Hmm?  But this is not how the global-to-local hand-off is implemented (and
> expected by tooling): a fall-through.  The global entry sets up the GOT
> register, there simply is no '[b localentry]'.
> 
> If you mean to imply that also the '[b localentry]' should be patched in at
> live-patch application time (and hence the GOT setup would need to be moved
> to still somewhere else), then you have the problem that (in the
> not-yet-patched 
> case) as long as the L1-nops sit between global and local entry they will
> always 
> be executed when the global entry is called.

Sorry for confusion, I meant the sequence like:

global entry:
  [TOC base setup] // always here
  [b localentry] // which is added when patching
L1:
  [patched code] // from patching
  localentry: 
  [b L1] // from patching

> That's wasteful.

I agree, nops are not zero cost on Power8/Power9.

> 
> Additionally tooling will be surprised if the address difference between
> global and local entry isn't exactly 8 (i.e. two instructions).  The psABI
> allows for different values, of course.  But I'm willing to bet that there
> are
> bugs in the wild when different values would be actually used.
> 

It's possible that some tooling doesn't conform the ABI doc well, but I think
the tooling should fix itself if that is the case. :)

> So, the nops-between-gep-and-lep could probably be somehow made to work with
> userspace live patching, but your most recent patch here makes this all mood.
> It generates exactly the sequence we want: a single nop at the LEP, and
> a configurable patching area outside of, but near to, the function (here: in
> front of the GEP).

I agree, thanks for the comments! btw, I'm not fighting for the current
implementation, just want to know more details why users are unable to make use
of the current implementation, is it just due to its inefficiency (like the
above sequence) or un-usability (unused at all). As your comments, I think it's
due to the former (inefficiency)?!

[Bug target/114671] New: [RISC-V] -fvar-tracking -gas-locview-support -ggdb emits a non-constant .uleb128

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 114671
   Summary: [RISC-V] -fvar-tracking -gas-locview-support -ggdb
emits a non-constant .uleb128
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
int main() { int a = 0; }

Backtrace:
> /scratch/tc-testing/tc-apr-9/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -fvar-tracking -gas-locview-support -ggdb red.c -o red.out
/scratch/tmp/ccEGxw5q.s: Assembler messages:
/scratch/tmp/ccEGxw5q.s:174: Error: .uleb128 only supports constant or subtract
expressions
/scratch/tmp/ccEGxw5q.s:175: Error: .uleb128 only supports constant or subtract
expressions

Godbolt: https://godbolt.org/z/Pao7459f3

I'm not sure if this is the intended behavior of these flags since
-gas-locview-support tells the compiler that gas has support for "view
assignment and reset assertion checking in .loc directives". AFAICT risc-v GAS
doesn't have support for this.

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[yangyujie at loongson dot cn via Gcc-bugs]

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

--- Comment #14 from Yang Yujie  ---
Is it not really necessary for now, since there is no LSX/LASX support in GCC
12 / 13?

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

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

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

Bug 104040 Summary: linker: when exported template class from module is used in 
several .cpp with same tpl arg ~ undefined reference to not default non-inline 
destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104040

   What|Removed |Added

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

[Bug c++/104040] linker: when exported template class from module is used in several .cpp with same tpl arg ~ undefined reference to not default non-inline destructor

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||nshead at gcc dot gnu.org
   Target Milestone|--- |14.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org

--- Comment #2 from Nathaniel Shead  ---
Fixed for GCC 14.

[Bug c++/104040] linker: when exported template class from module is used in several .cpp with same tpl arg ~ undefined reference to not default non-inline destructor

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:0774240b4df9a9bc48ce33a9625788e402498f5a

commit r14-9883-g0774240b4df9a9bc48ce33a9625788e402498f5a
Author: Nathaniel Shead 
Date:   Fri Mar 29 13:53:54 2024 +1100

c++: Keep DECL_SAVED_TREE of cdtor instantiations in modules [PR104040]

A template instantiation still needs to have its DECL_SAVED_TREE so that
its definition is emitted into the CMI. This way it can be emitted in
the object file of any importers that use it, in case it doesn't end up
getting emitted in this TU.

This is true even for maybe-in-charge functions, because we don't
currently stream the clones directly but instead regenerate them from
this function.

PR c++/104040

gcc/cp/ChangeLog:

* semantics.cc (expand_or_defer_fn_1): Keep DECL_SAVED_TREE for
all vague linkage cdtors with modules.

gcc/testsuite/ChangeLog:

* g++.dg/modules/pr104040_a.C: New test.
* g++.dg/modules/pr104040_b.C: New test.

Signed-off-by: Nathaniel Shead 
Reviewed-by: Jason Merrill 

[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux

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

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

--- Comment #23 from Jonathan Wakely  ---
Re https://github.com/cplusplus/draft/issues/6922

It can't possibly mean that the returned time zone *needs* to be the same as
the C library, because that's impossible in general, because the C library
isn't required to use IANA zones at all. See my TZ=garbage23nonsense example.
There is no way to match that with std::chrono::time_zone without pointer
lifetime issues and inconsistencies like returning a time_zone that isn't in
the tzdb.

And if the C++ standard intended to require that TZ is respected on POSIX
systems, then it would say so. The absence of any requirement means it's not
required. TZ is not mentioned in the standard at all. The standard probably
isn't going to say it *must not* be used, because it's not in the business of
listing (or forbidding) possible vendor extensions. There might be systems
where a TZ environment var is the only way the time zone can be set, and it
always is an IANA zone. But I don't believe any of the targets libstdc++
supports fit into that category.

[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux

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

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

--- Comment #22 from Jonathan Wakely  ---
I do still consider it incorrect. 

But what I mean re libc++ is that *even ignoring* the general problems with
using TZ, *their implementation* of using TZ isn't even correct. If the
intention is to follow POSIX, it fails to do that.

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

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

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

Bug 99377 Summary: [modules] undefined std::string_view::empty() if referenced 
in inline exported function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99377

   What|Removed |Added

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

[Bug c++/99377] [modules] undefined std::string_view::empty() if referenced in inline exported function

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||nshead at gcc dot gnu.org
 Status|REOPENED|RESOLVED

--- Comment #18 from Nathaniel Shead  ---
Fixed in GCC 14.

[Bug c++/99377] [modules] undefined std::string_view::empty() if referenced in inline exported function

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

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

--- Comment #17 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:77c0b5b23f91404004a9bf710981f6d615b63f57

commit r14-9881-g77c0b5b23f91404004a9bf710981f6d615b63f57
Author: Nathaniel Shead 
Date:   Thu Apr 4 23:16:08 2024 +1100

c++: Track declarations imported from partitions [PR99377]

The testcase in comment 15 of the linked PR is caused because the
following assumption in depset::hash::make_dependency doesn't hold:

  if (DECL_LANG_SPECIFIC (not_tmpl)
  && DECL_MODULE_IMPORT_P (not_tmpl))
{
  /* Store the module number and index in cluster/section,
 so we don't have to look them up again.  */
  unsigned index = import_entity_index (decl);
  module_state *from = import_entity_module (index);
  /* Remap will be zero for imports from partitions, which
 we want to treat as-if declared in this TU.  */
  if (from->remap)
{
  dep->cluster = index - from->entity_lwm;
  dep->section = from->remap;
  dep->set_flag_bit ();
}
}

This is because at least for template specialisations, we first see the
declaration in the header unit imported from the partition, and then the
instantiation provided by the partition itself.  This means that the
'import_entity_index' lookup doesn't report that the specialisation was
declared in the partition and thus should be considered as-if it was
part of the TU, and get emitted into the CMI.

We always need to emit definitions from module partitions into the
primary module interface's CMI, as unlike with other kinds of transitive
imports the built CMIs for module partitions are not visible to
importers.

To fix this, this patch allows, as a special case for installing an
entity from a partition, to overwrite the entity_map entry with the
(later) index into the partition so that this assumption holds again.

We only do this for the first time we override with a partition, so that
entities are at least still reported as originating from the first
imported partition that declares them (rather than the last); existing
tests check for this and this seems to be a friendlier approach to go
for, albeit slightly more expensive.

PR c++/99377

gcc/cp/ChangeLog:

* module.cc (trees_in::install_entity): Overwrite entity map
index if installing from a partition.

gcc/testsuite/ChangeLog:

* g++.dg/modules/pr99377-3_a.H: New test.
* g++.dg/modules/pr99377-3_b.C: New test.
* g++.dg/modules/pr99377-3_c.C: New test.
* g++.dg/modules/pr99377-3_d.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux

[harald at gigawatt dot nl via Gcc-bugs]

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

--- Comment #21 from Harald van Dijk  ---
(In reply to Jonathan Wakely from comment #20)
> (In reply to Harald van Dijk from comment #18)
> > (In reply to Jonathan Wakely from comment #16)
> > > ... incorrectly though?
> > 
> > Given that you have expressed your view that *any* attempt at using TZ is
> > inherently incorrect, I am not surprised that you view libc++'s attempt as
> > incorrect. :)
> 
> That's not what I mean.

You wrote in 
which you referenced in comment #1: "And in any case, I don't think we want to
depend on $TZ. That's not the intended design of the std::chrono API." Earlier
in that thread, you had written in
: "In any case,
the C++ standard requires that current_zone() refers to the computer's zone,
not just the current process' TZ setting:"

It's fine if you changed your mind since then, but it is hard for me to read
this as any other way than that any attempt at using TZ is inherently
incorrect.

[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux

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

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

--- Comment #20 from Jonathan Wakely  ---
(In reply to Harald van Dijk from comment #18)
> (In reply to Jonathan Wakely from comment #16)
> > ... incorrectly though?
> 
> Given that you have expressed your view that *any* attempt at using TZ is
> inherently incorrect, I am not surprised that you view libc++'s attempt as
> incorrect. :)

That's not what I mean. I do consider it ill-advised and unsafe to use TZ
(since getenv can introduce data races, and I don't think they document
potentially concurrent calls to current_zone() and setenv as being unsafe), but
libc++ is free to define current_zone() that way if they think that is right
for their users. The comment in libc++ notes other problems like the lifetime
and ownership one I noted in comment 8, and the inconsistency between "MST"
being recognized as an IANA zone but "MST-3" not being. They say "the
documentation is unclear" but I disagree, "MST-3" is perfectly valid according
to POSIX. And so is TZ="garbage23nonsense", because there is no requirement in
POSIX for POSIX-style time zone definitions to have any relation to a real IANA
zone. The std and dst names in a POSIX zone are effectively arbitrary.

Glibc gets this right:
$ date
Wed 10 Apr 01:04:17 BST 2024
$ TZ=garbage23nonsense date
Tue  9 Apr 02:04:18 nonsense 2024

But quite aside from that, my point in comment 16 is that if they're going to
use TZ, I would expect TZ=":Europe/London" to work.

[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux

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

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

--- Comment #19 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #16)
> I would expect TZ=:Europe/London to work according to POSIX,

Well, POSIX says ":characters" is implementation-defined, but for Glibc it
looks up an IANA zone.

I would also expect "7" to work, since the current POSIX spec
describes that.

[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux

[harald at gigawatt dot nl via Gcc-bugs]

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

--- Comment #18 from Harald van Dijk  ---
(In reply to Jonathan Wakely from comment #16)
> ... incorrectly though?

Given that you have expressed your view that *any* attempt at using TZ is
inherently incorrect, I am not surprised that you view libc++'s attempt as
incorrect. :)

I am not intending to get involved in discussion of what the correct behaviour
is, I merely wanted to correct the record about what other implementations do.

[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux

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

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

--- Comment #17 from Jonathan Wakely  ---
And "Factory" isn't a valid POSIX zone, so remove that one from the list. So if
I'm reading it correctly, some European zones and the US zones can be used in
$TZ with libc++ but most IANA zones won't work. And then it just silently
ignores $TZ and falls back to /etc/localtime so an application still can't
actually rely on $TZ being used. It might work, for a small set of zones, or it
might not work.

[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux

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

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

--- Comment #16 from Jonathan Wakely  ---
(In reply to Harald van Dijk from comment #14)
> (In reply to Jonathan Wakely from comment #8)
> > None of libstdc++, LLVM libc++, MSVC STL or the
> > date/tz.h reference implementation uses $TZ for chrono::current_zone,
> 
> This does not appear to be accurate.
> 
> libc++ appears to always uses $TZ on POSIX-like platforms if it is set:
> https://github.com/llvm/llvm-project/blob/
> 788be0d9fc6aeca548c90bac5ebe6990dd3c66ec/libcxx/src/tzdb.cpp#L708

... incorrectly though?

I would expect TZ=:Europe/London to work according to POSIX, but it seems they
don't remove the ':' before the lookup. So it only works for a string like
"MST7MDT" which means only the following entries in the IANA database can be
matched by a value in $TZ:

Z CET 1 c CE%sT
Z CST6CDT -6 u C%sT
Z EET 2 E EE%sT
Z EST -5 - EST
Z EST5EDT -5 u E%sT
Z Factory 0 - -00
Z HST -10 - HST
Z MET 1 c ME%sT
Z MST -7 - MST
Z MST7MDT -7 u M%sT
Z PST8PDT -8 u P%sT
Z WET 0 E WE%sT

That doesn't seem very well thought out or tested.

[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux

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

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

--- Comment #15 from Jonathan Wakely  ---
(In reply to Hristo Venev from comment #13)
> > $TZ allows you to override it per-process (and even change it during the 
> > lifetime of a process by using setenv and tzset). We don't support that for 
> > current_zone().
> 
> /etc/localtime can also change.

But not in a racy way. The filesystem serializes those changes so that
inspecting the symlink with readlink(3) gives a single race-free answer at any
one time. And if the application wants to query current_zone() once and then
reuse the result of that query, it can, because the time_zone* is a value held
by the application itself. That's an advantage of the std::chrono design which
is absent from libc, where the application has very little control over the
hidden state that libc maintains for time zone info.

> > The intent is to infer an IANA time zone from the /etc/localtime symlink, 
> > if possible. If the intent was to match libc, it would look at $TZ. I've 
> > discussed this exact question with the author of that library (which is the 
> > origin of the std::chrono components too). What I said in comment 8 above 
> > is paraphrasing what he said.
> 
> Point taken. Still, do you have any explanation for why this behavior was
> chosen?

Because the environment cannot be accessed safely, and because $TZ was
traditionally used for POSIX time zones, which are inferior to the IANA zones
in nearly every way (see the "POSIX style time zones" section of
https://stackoverflow.com/tags/timezone/info for more details).

> > Just do the easy thing yourself.
> 
> The easy thing being to fix all applications that currently use or will ever
> use current_zone(). Fun times ahead...

Well they should not be assuming current_zone() uses $TZ in the first place -
that has never been claimed or documented by any reputable source. You only
need to "fix" the ones that were relying on something that was never part of
the API.

[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux

[harald at gigawatt dot nl via Gcc-bugs]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #14 from Harald van Dijk  ---
(In reply to Jonathan Wakely from comment #8)
> None of libstdc++, LLVM libc++, MSVC STL or the
> date/tz.h reference implementation uses $TZ for chrono::current_zone,

This does not appear to be accurate.

libc++ appears to always uses $TZ on POSIX-like platforms if it is set:
https://github.com/llvm/llvm-project/blob/788be0d9fc6aeca548c90bac5ebe6990dd3c66ec/libcxx/src/tzdb.cpp#L708
MSVC STL calls into __icu_ucal_getDefaultTimeZone. ICU's
ucal_getDefaultTimeZone uses the platform-specific way of getting the default
time zone, which on POSIX-like platforms does check getenv("TZ"), although of
course MSVC's STL would not likely be used on POSIX-like platforms.

[Bug libstdc++/114633] [14 Regression] A cross to rx fails to build in libstdc++

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Thanks for testing it, so this should be fixed now.

[Bug libstdc++/114633] [14 Regression] A cross to rx fails to build in libstdc++

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:92b38ec84f2990d217f036dc6c5a32cde5ecfb93

commit r14-9879-g92b38ec84f2990d217f036dc6c5a32cde5ecfb93
Author: Jonathan Wakely 
Date:   Mon Apr 8 17:37:32 2024 +0100

libstdc++: Fix build for targets without FP std::from_chars [PR114633]

If the faster std::from_chars is not supported for floating-point types
then just extract the value from the stream using operator>>.

This fixes a build error for targets where __cpp_lib_to_chars is not
defined.

libstdc++-v3/ChangeLog:

PR libstdc++/114633
* include/bits/chrono_io.h (_Parser::operator()) <'S'>: Use
stream extraction if std::from_chars is not available.

[Bug tree-optimization/114670] New: `(a ^ 1) <= 3` can be optimized to `a <= 3`

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

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

Bug ID: 114670
   Summary: `(a ^ 1) <= 3` can be optimized to `a <= 3`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

While looking into PR 114666, I noticed this:
```
int f(unsigned a)
{
  return (a^1) <= 3;
}

int fa(unsigned a)
{
  return (a) <= 3;
}
```

These 2 are the same functions should produce the same code.

Basically if we have `(a ^ CST1) <= MASK` where MASK is a (lower) mask which
contain the bits of CST1.

[Bug tree-optimization/114666] [14 Regression] Signed single bit comparison miscompile at -O2

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

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

--- Comment #6 from Andrew Pinski  ---
Note fixing the `!A ? B : C` pattern generates worse code in this case but that
is a different issue where we don't convert `a <= 2` into `a == 1` if we know
only 1 could be the value that works (I have a patch which I need to work on
for GCC 15).

[Bug tree-optimization/114669] use >= comparison when testing high bits

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
   Last reconfirmed||2024-04-09
 Ever confirmed|0   |1

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

[Bug tree-optimization/114669] use >= comparison when testing high bits

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization
 CC||pinskia at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---
This is almost definitely a dup ...

[Bug middle-end/114669] New: use >= comparison when testing high bits

[goon.pri.low at gmail dot com via Gcc-bugs]

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

Bug ID: 114669
   Summary: use >= comparison when testing high bits
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goon.pri.low at gmail dot com
  Target Milestone: ---

Example C functions

#include 
#include 

bool unopt(uint32_t x) {
return (x & 0xfff0) == 0xfff0;
}

bool opt(uint32_t x) {
return x >= 0xfff0;
}

Generated assembly

unopt:
not edi
and edi, -1048576
seteal
ret
opt:
cmp edi, -1048577
setaal
ret

[Bug middle-end/114661] Bit operations not optimized to multiplication

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-04-09
 Ever confirmed|0   |1

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

[Bug target/114668] [14] RISC-V rv64gcv: miscompile at -O3

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

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

--- Comment #1 from Andrew Pinski  ---
Looks to be working on aarch64 (both with/without SVE):
```
[apinski@xeond2 upstream-cross-aarch64]$ ./install/bin/aarch64-linux-gnu-gcc
-O3 -fno-vect-cost-model t6.c -static -fno-vect-cost-model
[apinski@xeond2 upstream-cross-aarch64]$ ./install-qemu/bin/qemu-aarch64 a.out
1
1
[apinski@xeond2 upstream-cross-aarch64]$ ./install/bin/aarch64-linux-gnu-gcc
-O3 -fno-vect-cost-model t6.c -static -march=armv9-a+sve -fno-vect-cost-model
[apinski@xeond2 upstream-cross-aarch64]$ ./install-qemu/bin/qemu-aarch64 a.out
1
1

```

[Bug libstdc++/102918] Undefined behaviour in regex header (uininitialized boolean)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #2 from Andrew Pinski  ---
No feedback or a testcase in over 2 years so closing as invalid. If you provide
a testcase we will be able to look into it but until then, closing as invalid.

[Bug target/114668] New: [14] RISC-V rv64gcv: miscompile at -O3

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 114668
   Summary: [14] RISC-V rv64gcv: miscompile at -O3
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
char a;
int b;
short e[14];
char f[4][12544];
_Bool c[4][5];
int main() {
  for (int i = 0; i < 4; ++i)
for (int l = 0; l < 15; ++l)
  for (int m = 0; m < 15; ++m)
f[i][l * m] = 3;
  for (int j = 0; j < 4; j += 1)
for (int k = 3; k < 13; k += 3)
  for (_Bool l = 0; l < 1; l = 1)
for (int m = 0; m < 4; m += 1) {
  a = 0;
  b -= e[k];
  c[j][m] = f[j][6];
}
  for (long i = 2; i < 4; ++i)
__builtin_printf("%X\n", c[3][3]);
}

Commands:
> /scratch/tc-testing/tc-apr-9/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -march=rv64gcv -O3 red.c -o red.out
> /scratch/tc-testing/tc-apr-9/build-rv64gcv/bin/qemu-riscv64 red.out
1
FF

> /scratch/tc-testing/tc-apr-9/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -march=rv64gcv -O2 red.c -o red.out
> /scratch/tc-testing/tc-apr-9/build-rv64gcv/bin/qemu-riscv64 red.out
1
1

Adjusting the f array to its minimal size of f[4][255] makes the issue go away.

Looks similar to pr114665 so this might be a duplicate/related. Submitting this
bug in case it's easier to understand the root cause.

Found via fuzzer.

[Bug debug/112878] ICE: in ctf_add_slice, at ctfc.cc:499 with _BitInt > 255 in a struct and -gctf1

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

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

--- Comment #5 from Indu Bhagat  ---
Hmm, thanks. Using sorry in some cases will be a viable option.

For this specific case though, I am thinking emitting CTF_K_UNKNOWN instead
should be okay.  We have precedent in CTF generation in GCC where if a type is
not representable, we use a type of kind CTF_K_UNKNOWN instead.

[Bug tree-optimization/114666] [14 Regression] Signed single bit comparison miscompile at -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #5 from Andrew Pinski  ---
Send out an email on the issue of COND_EXPR:
https://gcc.gnu.org/pipermail/gcc/2024-April/243709.html

Tomorrow I will fix post a fix for this (maybe both fixes for folks to select
from).

Note I think this is a P1 even though signed 1bit integer bitfields are less
likely to show up in the wild this is a miscompile which was reported before
the release ...

[Bug middle-end/114667] New: `gcc -O2 t.c -fdump-tree-optimized=/dev/stdout -fdump-tree-all` produces `error: could not open dump file`

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

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

Bug ID: 114667
   Summary: `gcc -O2 t.c -fdump-tree-optimized=/dev/stdout
-fdump-tree-all` produces `error: could not open dump
file`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: diagnostic, rejects-valid
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

```
[apinski@xeond2 gcc]$ ~/upstream-gcc/bin/gcc -O2  -S 
-fdump-tree-optimized=/dev/stdout -fdump-tree-all t.c
t.c: In function ‘main’:
t.c:5:5: error: could not open dump file ‘/usr/local/include’: Is a directory
5 | int main()
  | ^~~~

```

This has been failing this way since at least 9.1.0 .

[Bug tree-optimization/114666] [14 Regression] Signed single bit comparison miscompile at -O2

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

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

--- Comment #4 from Andrew Pinski  ---
Note the other pattern which uses logical_inverted_value where it depends on
the type does:

/* -(type)!A -> (type)A - 1.  */
(simplify
 (negate (convert?:s (logical_inverted_value:s @0)))
 (if (INTEGRAL_TYPE_P (type)
  && TREE_CODE (type) != BOOLEAN_TYPE
  && TYPE_PRECISION (type) > 1
  && TREE_CODE (@0) == SSA_NAME
  && ssa_name_has_boolean_range (@0))
  (plus (convert:type @0) { build_all_ones_cst (type); })))

But that is ok because of the check of >1 for precision. The other one dealing
with cond is a problem there.

[Bug tree-optimization/114666] [14 Regression] Signed single bit comparison miscompile at -O2

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

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

--- Comment #3 from Andrew Pinski  ---
With match.pd:7103 disable we get:

Folding statement: _2 = (long unsigned int) _1;
Global Exported: _2 = [irange] long unsigned int [0, 0][+INF, +INF]
Not folded
Folding statement: _3 = _2 ^ 1;
Matching expression match.pd:2835, gimple-match-2.cc:35
Matching expression match.pd:2838, gimple-match-1.cc:66
Matching expression match.pd:2845, gimple-match-2.cc:96
Matching expression match.pd:2243, gimple-match-5.cc:20
Matching expression match.pd:2835, gimple-match-2.cc:35
Matching expression match.pd:2838, gimple-match-1.cc:66
Matching expression match.pd:2845, gimple-match-2.cc:96
Applying pattern match.pd:6795, gimple-match-4.cc:1721
Matching expression match.pd:2243, gimple-match-5.cc:20
Matching expression match.pd:2286, gimple-match-3.cc:23
Matching expression match.pd:2255, gimple-match-4.cc:67
Matching expression match.pd:2243, gimple-match-5.cc:20
Applying pattern match.pd:5898, gimple-match-7.cc:51777
gimple_simplified to _3 = _1 ? 18446744073709551614 : 1;
Global Exported: _3 = [irange] long unsigned int [1, 1][18446744073709551614,
18446744073709551614]
Folded into: _3 = _1 ? 18446744073709551614 : 1;


But _1 here is an 1bit signed integer which I am 100% sure is really invalid
gimple but we don't reject it.

We don't check the operand 0 for COND_EXPR in verify_gimple_assign_ternary at
all .

[Bug tree-optimization/114666] [14 Regression] Signed single bit comparison miscompile at -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---

Folding statement: _3 = _2 ^ 1;
Matching expression match.pd:2835, gimple-match-2.cc:35
Matching expression match.pd:2838, gimple-match-1.cc:66
Matching expression match.pd:2845, gimple-match-2.cc:96
Matching expression match.pd:2243, gimple-match-5.cc:20
Matching expression match.pd:2835, gimple-match-2.cc:35
Matching expression match.pd:2838, gimple-match-1.cc:66
Matching expression match.pd:2845, gimple-match-2.cc:96
Applying pattern match.pd:6795, gimple-match-4.cc:1721
Matching expression match.pd:2243, gimple-match-5.cc:20
Matching expression match.pd:2286, gimple-match-3.cc:23
Matching expression match.pd:2255, gimple-match-4.cc:67
Matching expression match.pd:2243, gimple-match-5.cc:20
Applying pattern match.pd:7103, gimple-match-8.cc:47279
Applying pattern match.pd:5898, gimple-match-8.cc:47191
gimple_simplified to _7 = (long unsigned int) _1;
_8 = -_7;
_3 = _8 ^ 1;

That is wrong.

I can't figure out how we got there though. 
match.pd:6795 is the pattern which does `(convert)a CMP b` into `a CMP
(convert)b` which I assume VRP does `_3 == 0 ? 1 : -2u` which then we get `_1
== 0 ? 1 : -2u` (which seems reasonable) and then we apply match.pd:5898 which
gets us to `_1 ? -2u : 1` which seems wrong as not a boolean  type nor an one
bit unsigned integer.

So the problem is with:
 /* !A ? B : C -> A ? C : B.  */
 (simplify
  (cnd (logical_inverted_value truth_valued_p@0) @1 @2)
  (cnd @0 @2 @1)))

which does not check the types correctly for gimple. Note this pattern has been
there since 2014.
Just been exposed the issue when I added match.pd:7103 in
r14-3110-g7fb65f10285124.

Let me try to figure out what to do here to fix the issue.

[Bug middle-end/114666] [14 Regression] Signed single bit comparison miscompile at -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-04-09
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed, semi looking it into further. it has some match vs VRP going on here
...

[Bug middle-end/114666] [14 Regression] Signed single bit comparison miscompile at -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug middle-end/114666] New: [14 Regression] Signed single bit comparison miscompile at -O2

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 114666
   Summary: [14 Regression] Signed single bit comparison
miscompile at -O2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
struct {
  signed a : 1;
} b = {-1};
char c;
int main()
{
  if ((b.a ^ 1UL) < 3)
__builtin_abort();
}

Commands:
> /scratch/tc-testing/tc-apr-9/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -O2 red.c -o red.out
> /scratch/tc-testing/tc-apr-9/build-rv64gcv/bin/qemu-riscv64 red.out
zsh: IOT instruction (core dumped) 
/scratch/tc-testing/tc-apr-9/build-rv64gcv/bin/qemu-riscv64 red.out

> /scratch/tc-testing/tc-apr-9/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -O1 red.c -o red.out
> /scratch/tc-testing/tc-apr-9/build-rv64gcv/bin/qemu-riscv64 red.out
> echo $?
0

Godbolt showing the same issue on x86: https://godbolt.org/z/1dx8YKG3e

Discovered/tested using r14-9877-g1f719aa7c0d (not bisected)

Found via fuzzer.

[Bug analyzer/114472] [14 Regression] ICE: in falls_short_of_p, at analyzer/store.cc:365 (in exceeds_p, at analyzer/store.cc:342) with -fanalyzer

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

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

--- Comment #3 from David Malcolm  ---
I'm testing a fix for this.

[Bug middle-end/114661] Bit operations not optimized to multiplication

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---
Seems like another example where -fwrapv improves code ...

[Bug target/114665] New: [14] RISC-V rv64gcv: miscompile at -O3

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 114665
   Summary: [14] RISC-V rv64gcv: miscompile at -O3
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
signed char b;
_Bool c[15][15];
int main()
{
  for (long f = 0; f < 5; ++f)
for (long g = 0; g < 5; ++g)
  c[f][g] = 1;
  _Bool(*h)[15] = c;
  for (int f = 0; f < 15; f += 1)
for (int g = 0; g < 15; g += 1)
  b -= c[g][g] ? c[g][g] : h[f][g];
  __builtin_printf("%X\n", b);
}

Commands:
> /scratch/tc-testing/tc-apr-9/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -march=rv64gcv -O3 red.c -o red.out
> /scratch/tc-testing/tc-apr-9/build-rv64gcv/bin/qemu-riscv64 red.out
35
> /scratch/tc-testing/tc-apr-9/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -march=rv64gcv -O2 red.c -o red.out
> /scratch/tc-testing/tc-apr-9/build-rv64gcv/bin/qemu-riscv64 red.out
FFB5

Discovered/tested using r14-9877-g1f719aa7c0d (not bisected)

Found via fuzzer.

[Bug middle-end/114661] Bit operations not optimized to multiplication

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package

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

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

--- Comment #7 from Peter Bergner  ---
(In reply to Andrew Pinski from comment #6)
> Pre-IRA fix was done to specifically reject this:
> https://inbox.sourceware.org/gcc-patches/
> ab3a61990702021658w4dc049cap53de8010a7d86...@mail.gmail.com/

Then that would seem to indicate that mentioning the frame pointer reg in the
asm clobber list is an error, but how are users supposed to know whether
-fno-omit-frame-pointer is in effect or not?  I've looked and there is no
pre-defined macro a user could check.

[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package

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

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

--- Comment #6 from Andrew Pinski  ---
Pre-IRA fix was done to specifically reject this:
https://inbox.sourceware.org/gcc-patches/ab3a61990702021658w4dc049cap53de8010a7d86...@mail.gmail.com/

[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package

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

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

--- Comment #5 from Andrew Pinski  ---
I wonder why they are not using getcontext/savecontext/swapcontext instead ...

[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package

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

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

--- Comment #4 from Peter Bergner  ---
(In reply to Andrew Pinski from comment #3)
> Well I am going to say this about the code in that repo, the inline-asm in
> slp_switch looks very broken anyways.

100% agree, but broken for other reasons.  I think still TBD whether the
minimal test case here is supposed to work or not.

[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org,
   ||law at gcc dot gnu.org,
   ||linkw at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
   Last reconfirmed||2024-04-09
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package

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

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

--- Comment #3 from Andrew Pinski  ---
Well I am going to say this about the code in that repo, the inline-asm in
slp_switch looks very broken anyways.

[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package

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

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

--- Comment #2 from Peter Bergner  ---
CC'ing some architecture and RA experts for their input.

I believe the riscv64 test showing the same issue would be:

void
bug (void)
{
  __asm__ volatile ("" : : : "s0");
}

...but I don't have a cross compiler right now to verify.

Interestingly, I tried what I thought would be the aarch64 test case
(clobbering x29), but it did not ICE.  Did I use the wrong hard frame pointer
register or is aarch64 doing something different here?

[Bug lto/114662] [14 regression] new test case c_lto_pr113359-2 from r14-9841-g1e3312a25a7b34 fails

[ewlu at rivosinc dot com via Gcc-bugs]

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

Edwin Lu  changed:

   What|Removed |Added

 CC||ewlu at rivosinc dot com,
   ||patrick at rivosinc dot com

--- Comment #1 from Edwin Lu  ---
We are also seeing this for rv32 targets on linux and newlib
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/746#issuecomment-2045727038

[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package

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

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

--- Comment #1 from Andrew Pinski  ---
Let me find the dups ...

[Bug target/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #9 from Bruno Haible  ---
(In reply to Andrew Pinski from comment #7)
> Much more related to PR 56831 and PR 57484 rather than the other two ...

Well, bug #56831 is more about function calls and the ABI, whereas this bug
here and bug #58416 and bug #93271 are about the compiler picking a memory
location which holds convert_snan_to_qnan(value) rather than a memory location
which holds the original value.

[Bug target/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #8 from Bruno Haible  ---
(In reply to Andrew Pinski from comment #6)
> I doubt there is not much to be done here.

I see it as an incorrect modelization of the x87 hardware, together with a
missing distinction in the common expression elimination / aliasing analysis.
In detail:

* Incorrect modelization of the x87 hardware: The compiler seems to assume that
flds MEM_LOCATION_1
fsts MEM_LOCATION_2
  will result in MEM_LOCATION_2 having the same value as MEM_LOCATION_1. This
is wrong;
  this is not how the x87 hardware behaves. The actual result is:
*MEM_LOCATION_2 = convert_snan_to_qnan(*MEM_LOCATION_1).

* In the common expression elimination / aliasing analysis, the compilers seems
to keep
  track of a set of memory locations MEM_LOCATION_1, ..., MEM_LOCATION_n which
have the
  same value. In fact, this set needs to be partitioned into two sets: a subset
which
  contains the same value, and the complementary subset which contains
  convert_snan_to_qnan(value).

  In other words, each element of the set needs to be annotated with a bit that
tells
  whether the value has been subject to the convert_snan_to_qnan.

[Bug debug/112878] ICE: in ctf_add_slice, at ctfc.cc:499 with _BitInt > 255 in a struct and -gctf1

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

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

--- Comment #4 from Andrew Pinski  ---
Another option to ouput a sorry message and then suspend this until libctf gets
fixed/changed.

[Bug rtl-optimization/114664] New: -fno-omit-frame-pointer causes an ICE during the build of the greenlet package

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

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

Bug ID: 114664
   Summary: -fno-omit-frame-pointer causes an ICE during the build
of the greenlet package
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

Current builds of the greenlet package on one specific distro, are seeing an
ICE on multiple architectures (ppc64le & riscv64) when being built with
-fno-omit-frame-pointer.  The upstream github issue is here:

  https://github.com/python-greenlet/greenlet/issues/395

A minimized test case on Power is:

bergner@ltcden2-lp1:$ cat bug.c 
void
bug (void)
{
  __asm__ volatile ("" : : : "r31");
}
bergner@ltcden2-lp1:$ /opt/gcc-nightly/trunk/bin/gcc -S -fno-omit-frame-pointer
bug.c
bug.c: In function ‘bug’:
bug.c:5:1: error: 31 cannot be used in ‘asm’ here
5 | }
  | ^
bug.c:5:1: error: 31 cannot be used in ‘asm’ here

This is not a regression, as all gcc's I have easy access to (back to gcc v8)
ICE the same way.

The code that is ICEing here is in ira.c:ira_setup_eliminable_regset():

  /* Build the regset of all eliminable registers and show we can't
 use those that we already know won't be eliminated.  */
  for (i = 0; i < (int) ARRAY_SIZE (eliminables); i++)
{
  bool cannot_elim
= (! targetm.can_eliminate (eliminables[i].from, eliminables[i].to)
   || (eliminables[i].to == STACK_POINTER_REGNUM &&
frame_pointer_needed));

  if (!TEST_HARD_REG_BIT (crtl->asm_clobbers, eliminables[i].from))
{
SET_HARD_REG_BIT (eliminable_regset, eliminables[i].from);

if (cannot_elim)
  SET_HARD_REG_BIT (ira_no_alloc_regs, eliminables[i].from);
}
  else if (cannot_elim)
error ("%s cannot be used in % here",
   reg_names[eliminables[i].from]);
  else
df_set_regs_ever_live (eliminables[i].from, true);
}

On Power, targetm.can_eliminate(r31,r1) returns true (ie, the port will allow
us to eliminate r31 into r1) even in the face of -fno-omit-frame-pointer, but
it's the RA specific test (eliminables[i].to == STACK_POINTER_REGNUM &&
frame_pointer_needed) that is catching us here.

The question I have is, is it legal to mention the hard frame pointer register
in an asm clobber list when using -fno-omit-frame-pointer?  Ie, is this user
error or should the compiler be able to handle this?

[Bug c++/114663] New: Several contracts test cases fail with -fsanitize=undefined -fsanitize-trap

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

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

Bug ID: 114663
   Summary: Several contracts test cases fail with
-fsanitize=undefined -fsanitize-trap
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail, wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

I found this while working on -funreachable-traps (but the failure equally
occurs with -fsanitize=undefined -fsanitize-trap)

FAIL: g++.dg/contracts/contracts10.C   execution test
FAIL: g++.dg/contracts/contracts18.C   execution test
FAIL: g++.dg/contracts/contracts19.C   execution test
FAIL: g++.dg/contracts/contracts2.C   execution test

Initial analysis is that somehow the lowering of the contracts code is
exploiting UB [which has a large measure of irony if true] to make these cases
pass, for example contracts2.C optimised tree dump contains:

;; Function main (main, funcdef_no=0, decl_uid=2531, cgraph_uid=1,
symbol_order=0)

int main ()
{
  int x;
  int D.2551;
  const struct  D.2542;
  int _2;

   :
  x_1 = 1;
  if (x_1 < 0)
goto ; [INV]
  else
goto ; [INV]

   :
  __builtin_unreachable ();

   :
  if (x_1 <= 0)
goto ; [INV]
  else
goto ; [INV]

   :

=

When (default) the __builtin_unreachable () is replaced with nothing (i.e. it
falls though) the test case passes.

When we replace the __builtin_unreachable () with a trap (either using the
ubsan or -funreachable-traps style) the test case fails with the trap.

This seems to be unlikely to be what was intended (or if it was intended it's
terribly fragile); I'm labelling it wrong code for now.

Similar code patterns exist in the other cases mentioned.

[Bug debug/112878] ICE: in ctf_add_slice, at ctfc.cc:499 with _BitInt > 255 in a struct and -gctf1

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

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

--- Comment #3 from Indu Bhagat  ---
The limit of 255 is somewhat arbitrary but we need to follow it for now,
because libctf has a check in ctf_add_slice () in libctf/ctf-create.c :

  if ((ep->cte_bits > 255) || (ep->cte_offset > 255))
return (ctf_set_typed_errno (fp, ECTF_SLICEOVERFLOW));
  ...
  slice.cts_bits = ep->cte_bits;
  slice.cts_offset = ep->cte_offset; 

The CTF generation in GCC does not have a mechanism to roll-back an already
added type.  In this testcase presented in the PR, we hit a representation
limit in CTF slices (for a member of a struct) and ICE, after the type for
struct (CTF_K_STRUCT) has already been added to the container.

To exit gracefully instead in GCC, one option is to simply check for both the
offset and size of the bitfield to be explicitly <= 255.  If the check fails,
we emit the member with type CTF_K_UNKNOWN instead.

[Bug target/110027] [11/12/13/14 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #17 from Jakub Jelinek  ---
Both of the posted patches are incorrect, this needs to be fixed in
asan_emit_stack_protection, account for the different offsets[0] which happens
when a stack pointer guard is created.
I'll deal with it tomorrow.

[Bug tree-optimization/114660] Exponentiating by squaring not performed for x * y * y * y * y

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

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

--- Comment #4 from Jakub Jelinek  ---
I think we've been discussing an idea of turning on flag_wrapv very late among
the GIMPLE passes and reassociate again.  Because RTL also kind of assumes
flag_wrapv, there is no difference between signed/unsigned
addition/subtraction/non-widening multiplication.
Though, a question is if it wouldn't screw up range info for use during
expansion too much.  Other option is to rewrite into unsigned operations only
what we've successfully reassociated in the late reassoc pass.

[Bug lto/114662] New: [14 regression] new test case c_lto_pr113359-2 from r14-9841-g1e3312a25a7b34 fails

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

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

Bug ID: 114662
   Summary: [14 regression] new test case c_lto_pr113359-2 from
r14-9841-g1e3312a25a7b34 fails
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:1e3312a25a7b34d6e3f549273e1674c7114e4408, r14-9841-g1e3312a25a7b34

I am seeing this on our big endian machines for -m32


 make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}' lto.exp=*"

FAIL: gcc-dg-lto-pr113359-2-01.exe scan-wpa-ipa-dump icf "Semantic equality
hit:geta/.*getb/"
FAIL: gcc.dg/lto/pr113359-2 c_lto_pr113359-2_0.o assemble, -O2 -flto
-fno-strict-aliasing -fno-ipa-cp  --disable-tree-esra -fdump-ipa-icf-details 
FAIL: gcc.dg/lto/pr113359-2 c_lto_pr113359-2_0.o-c_lto_pr113359-2_1.o execute
-O2 -flto -fno-strict-aliasing -fno-ipa-cp  --disable-tree-esra
-fdump-ipa-icf-details 


commit 1e3312a25a7b34d6e3f549273e1674c7114e4408 (HEAD)
Author: Martin Jambor 
Date:   Mon Apr 8 18:53:23 2024 +0200

ICF: Make ICF and SRA agree on padding

[Bug target/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=56831,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=57484

--- Comment #7 from Andrew Pinski  ---
Much more related to PR 56831 and PR 57484 rather than the other two ...

[Bug target/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |target

--- Comment #6 from Andrew Pinski  ---
I doubt there is not much to be done here. It is a x87 issue where we do the
store of the float register stack register to the stack to get 32bits (or
64bit) version. And then load it into a GPR.




  float t = *x;
  float t1 = *y;

 __builtin_memcpy (, , sizeof (float));
 __builtin_memcpy (, , sizeof (float));

Produces exactly the same issue.

[Bug testsuite/114642] new test case gcc.dg/debug/btf/btf-datasec-3.c from r14-6195-gb8cf266f4ca4ff fails for 32 bits

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by David Faust :

https://gcc.gnu.org/g:639215c5eb6c56ba3830cd868d1d3ddd700b4c90

commit r14-9878-g639215c5eb6c56ba3830cd868d1d3ddd700b4c90
Author: David Faust 
Date:   Mon Apr 8 13:33:48 2024 -0700

btf: improve btf-datasec-3.c test [PR114642]

This test failed on powerpc --target_board=unix'{-m32}' because two
variables were not placed in sections where the test silently (and
incorrectly) assumed they would be.

The important thing for the test is only that BTF_KIND_DATASEC entries
are NOT generated for the extern variable declarations without an
explicit section attribute.  Make the test more robust by placing the
non-extern variables in explicit sections, and invert the checks to
more accurately verify what we care about in this test.

gcc/testsuite/
PR testsuite/114642
* gcc.dg/debug/btf/btf-datasec-3.c: Make test more robust on
different
architectures.

[Bug tree-optimization/114660] Exponentiating by squaring not performed for x * y * y * y * y

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-04-09
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> We don't do as much reassociation as we should with signed integers due to
> overflow. If you use -fwrapv, you get the reassociation; I am 99% sure there
> is a dup for this bug too.

I should say we also do it for unsigned already (see PR 95867), -fwrapv case we
just treat signed similar to unsigned here. Anyways what needs to happen is we
need 2 levels of gimple, one with signed integer overflow behavior and then one
with wrapping behavior. RTL does not distinguish between signed and unsigned
behaviors for many operations (plus and multiple) so we get some optimizations
there but not all.

[Bug tree-optimization/114660] Exponentiating by squaring not performed for x * y * y * y * y

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
  Component|middle-end  |tree-optimization

--- Comment #2 from Andrew Pinski  ---
We don't do as much reassociation as we should with signed integers due to
overflow. If you use -fwrapv, you get the reassociation; I am 99% sure there is
a dup for this bug too.

[Bug driver/114658] branch "releases/gcc-13" builds "gcc version 14.0.1 (experimental)"

[felix-gcc at fefe dot de via Gcc-bugs]

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

felix-gcc at fefe dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from felix-gcc at fefe dot de ---
ok it looks like it was my fault (surprise) and I fixed it.
Here's what I did:

  $ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
  $ git branch -D releases/gcc-13
Deleted branch releases/gcc-13 (was 32fb04adae9).
  $ git checkout releases/gcc-13
Updating files: 100% (40334/40334), done.
branch 'releases/gcc-13' set up to track 'origin/releases/gcc-13'.
Switched to a new branch 'releases/gcc-13'
  $ cat gcc/BASE-VER
13.2.1

Sorry again for the noise. Hope this helps the next git noob :)

[Bug driver/114658] branch "releases/gcc-13" builds "gcc version 14.0.1 (experimental)"

[felix-gcc at fefe dot de via Gcc-bugs]

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

--- Comment #2 from felix-gcc at fefe dot de ---
I'm probably doing something really stupid wrong, sorry for the noise.

Here's what I'm doing:

$ git checkout releases/gcc-13
Switched to branch 'releases/gcc-13'
$ git branch
  master
* releases/gcc-13
$ cat gcc/BASE-VER
14.0.1

[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux

[hristo at venev dot name via Gcc-bugs]

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

--- Comment #13 from Hristo Venev  ---
> $TZ allows you to override it per-process (and even change it during the 
> lifetime of a process by using setenv and tzset). We don't support that for 
> current_zone().

/etc/localtime can also change.

> The intent is to infer an IANA time zone from the /etc/localtime symlink, if 
> possible. If the intent was to match libc, it would look at $TZ. I've 
> discussed this exact question with the author of that library (which is the 
> origin of the std::chrono components too). What I said in comment 8 above is 
> paraphrasing what he said.

Point taken. Still, do you have any explanation for why this behavior was
chosen?

> Just do the easy thing yourself.

The easy thing being to fix all applications that currently use or will ever
use current_zone(). Fun times ahead...

[Bug libfortran/114646] libgfortran still doesn't define GTHREAD_USE_WEAK to 0 for newer glibc

[skpgkp2 at gmail dot com via Gcc-bugs]

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

--- Comment #17 from Sunil Pandey  ---
(In reply to H.J. Lu from comment #10)
> Created attachment 57906 [details]
> A patch
> 
> I am testing this.

This patch resolved my static testing issue.

[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux

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

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Hristo Venev from comment #9)
> I stumbled upon this comment in the library you linked:
> 
> https://github.com/HowardHinnant/date/blob/
> 0e65940a7fbc4ed617a1ee111a60311eccbead9a/include/date/tz.h#L35
> 
> That comment is wrong in its explanation of the mechanism used to determine
> the local time zone on Linux. However, it clearly shows that the intent is
> to match the platform's "local time" as closely as reasonably possible.

The intent is for current_zone() to be "the time zone which the computer has
set as its local time zone", not the time zone that _the process_ has set via
TZ. That's /etc/localtime on GNU/Linux and many unixes. Which is what the
comment says.

$TZ allows you to override it per-process (and even change it during the
lifetime of a process by using setenv and tzset). We don't support that for
current_zone().

> The implementation also has some comments:
> 
> https://github.com/HowardHinnant/date/blob/
> 0e65940a7fbc4ed617a1ee111a60311eccbead9a/src/tz.cpp#L3936
> 
> The intent seems to be clear -- apply a lot of heuristics to try to match
> what libc would do as closely as possible.

The intent is to infer an IANA time zone from the /etc/localtime symlink, if
possible. If the intent was to match libc, it would look at $TZ. I've discussed
this exact question with the author of that library (which is the origin of the
std::chrono components too). What I said in comment 8 above is paraphrasing
what he said.

> Even on Linux there are no guarantees whatsoever that it is possible to
> extract a IANA time zone from /etc/localtime.

And so current_zone() can fail.

> In fact, the problem is
> exactly identical to that with $TZ, if not worse -- $TZ is normally an IANA
> time zone name, whereas /etc/localtime is a symlink (but sometimes a
> hardlink or a copy) of a file in some OS-specific directory  (sometimes, but
> not always, /usr/share/zoneinfo) where the name of the file relative to the
> base directory is a IANA time zone name.

If $TZ is an IANA name then you can just look that name up with locate_zone,
it's easy.

If $TZ is a POSIX time zone spec, things are more complicated.

So the most we could do is handle the easy case, but not in a thread-safe way
(because the environment is mutable and not synchronized). So we could support
something that is already easy for users to do, by introducing possible data
races into the program. That doesn't seem like a good trade off to me. Just do
the easy thing yourself.

[Bug target/114656] ~5% slowdown of 538.imagick_r on aarch64

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

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

--- Comment #2 from Filip Kastl  ---
(In reply to Jakub Jelinek from comment #1)
> Can you try to revert r14-9692 if that commit isn't the cause?

I have tried reverting r14-9692 and that indeed removed the slowdown. The
benchmark ran as fast as on r14-9649-gbb04a11418f54c. So it seems that r14-9692
is the cause of this slowdown.

[Bug middle-end/114661] New: Bit operations not optimized to multiplication

[antoshkka at gmail dot com via Gcc-bugs]

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

Bug ID: 114661
   Summary: Bit operations not optimized to multiplication
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the example:

unsigned mul(unsigned char c) {
if (c > 3) __builtin_unreachable();
return c << 18 | c << 15 |
c << 12 | c << 9 |
c << 6 | c << 3 | c;
}

GCC with -O2 generates the following assembly:

mul(unsigned char):
  movzx edi, dil
  lea edx, [rdi+rdi*8]
  lea eax, [0+rdx*8]
  mov ecx, edx
  sal edx, 15
  or eax, edi
  sal ecx, 9
  or eax, ecx
  or eax, edx
  ret

However it could be optimized to just:

mul(unsigned char):
  imul eax, edi, 299593
  ret

Compiling with -Os does not help.

Godbolt playground: https://godbolt.org/z/YszzMbovK

P.S.: without `c << 18 | c << 15 |` the bit operations are transformed to
multiplication.

[Bug target/114431] bpf: GCC generates unverifiable code for systemd restrict_fs_bpf

[david.faust at oracle dot com via Gcc-bugs]

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

David Faust  changed:

   What|Removed |Added

 CC||david.faust at oracle dot com

--- Comment #7 from David Faust  ---
Patch above had some fallout for non-BPF targets.  I pushed the below to fix
that. The behavior for BPF is unchanged.

https://gcc.gnu.org/g:8075477f81ae8d0abf64b80dfbd179151f91b417

commit r14-9876-g8075477f81ae8d0abf64b80dfbd179151f91b417
Author: David Faust 
Date:   Mon Apr 8 11:10:41 2024 -0700

btf: emit symbol refs in DATASEC entries only for BPF [PR114608]

[Bug c/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #5 from Bruno Haible  ---
Related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271

[Bug c/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #4 from Bruno Haible  ---
Related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416

[Bug middle-end/114660] Exponentiating by squaring not performed for x * y * y * y * y

[antoshkka at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Antony Polukhin  ---
The above godbolt link for an old version of GCC, here's for 14.0
https://godbolt.org/z/dTPYY1T9W

[Bug debug/114608] [14 Regression] Undefined reference in output asm with -fipa-reference -fipa-reference-addressable -fsection-anchors -gbtf

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

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

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

https://gcc.gnu.org/g:8075477f81ae8d0abf64b80dfbd179151f91b417

commit r14-9876-g8075477f81ae8d0abf64b80dfbd179151f91b417
Author: David Faust 
Date:   Mon Apr 8 11:10:41 2024 -0700

btf: emit symbol refs in DATASEC entries only for BPF [PR114608]

The behavior introduced in
  fa60ac54964 btf: Emit labels in DATASEC bts_offset entries.

is only fully correct when compiling for the BPF target with BPF CO-RE
enabled.  In other cases, depending on optimizations, it can result in
an incorrect symbol reference in the entry bts_offset field for a symbol
which may not be emitted at all, causing link-time undefined symbol
reference errors like in PR114608.

The offending bts_offset field of BTF_KIND_DATASEC entries is in reality
only currently useful to consumers of BTF information for BPF programs
anyway.  Correct the regression by only emitting symbol references in
these entries when compiling for the BPF target.  For other targets, the
behavior returns to that prior to fa60ac54964.

The underlying cause is related to PR 113566 "btf: incorrect
BTF_KIND_DATASEC entries for variables which are optimized out." A
complete fix for 113566 is more involved and unsuitable for stage 4,
but will be addressed in the near future.

gcc/
PR debug/114608
* btfout.cc (btf_asm_datasec_entry): Only emit a symbol reference
when
generating BTF for BPF CO-RE target.

gcc/testsuite/
PR debug/114608
* gcc.dg/debug/btf/btf-datasec-1.c: Check bts_offset symbol
references
only for BPF target.
* gcc.dg/debug/btf/btf-datasec-2.c: Likewise.
* gcc.dg/debug/btf/btf-pr106773.c: Likewise.

[Bug debug/113566] btf: incorrect BTF_KIND_DATASEC entries for variables which are optimized out

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by David Faust :

https://gcc.gnu.org/g:8075477f81ae8d0abf64b80dfbd179151f91b417

commit r14-9876-g8075477f81ae8d0abf64b80dfbd179151f91b417
Author: David Faust 
Date:   Mon Apr 8 11:10:41 2024 -0700

btf: emit symbol refs in DATASEC entries only for BPF [PR114608]

The behavior introduced in
  fa60ac54964 btf: Emit labels in DATASEC bts_offset entries.

is only fully correct when compiling for the BPF target with BPF CO-RE
enabled.  In other cases, depending on optimizations, it can result in
an incorrect symbol reference in the entry bts_offset field for a symbol
which may not be emitted at all, causing link-time undefined symbol
reference errors like in PR114608.

The offending bts_offset field of BTF_KIND_DATASEC entries is in reality
only currently useful to consumers of BTF information for BPF programs
anyway.  Correct the regression by only emitting symbol references in
these entries when compiling for the BPF target.  For other targets, the
behavior returns to that prior to fa60ac54964.

The underlying cause is related to PR 113566 "btf: incorrect
BTF_KIND_DATASEC entries for variables which are optimized out." A
complete fix for 113566 is more involved and unsuitable for stage 4,
but will be addressed in the near future.

gcc/
PR debug/114608
* btfout.cc (btf_asm_datasec_entry): Only emit a symbol reference
when
generating BTF for BPF CO-RE target.

gcc/testsuite/
PR debug/114608
* gcc.dg/debug/btf/btf-datasec-1.c: Check bts_offset symbol
references
only for BPF target.
* gcc.dg/debug/btf/btf-datasec-2.c: Likewise.
* gcc.dg/debug/btf/btf-pr106773.c: Likewise.

[Bug middle-end/114660] New: Exponentiating by squaring not performed for x * y * y * y * y

[antoshkka at gmail dot com via Gcc-bugs]

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

Bug ID: 114660
   Summary: Exponentiating by squaring not performed for x * y * y
* y * y
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

For the following code:

int mul(int x, int y) {
return x * y * y * y * y;
}


with -O2 GCC produces the frollowing assembly:

mul(int, int):
  mov eax, edi
  imul eax, esi
  imul eax, esi
  imul eax, esi
  imul eax, esi
  ret


However, a more optimal code could be generated with less multiplications:

mul(int, int):
mov eax, edi
imulesi, esi
imuleax, esi
imuleax, esi
ret

Godbolt playground: https://godbolt.org/z/6dP11jPfx

[Bug c/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #3 from Bruno Haible  ---
Also reproducible in 64-bit mode, with '-mfpmath=387':

$ gcc -mfpmath=387 -Wall tf.c
$ ./a.out ; echo $?
0
$ gcc -mfpmath=387 -Wall -O2 tf.c
$ ./a.out ; echo $?
1

$ gcc -mfpmath=387 -Wall td.c
$ ./a.out ; echo $?
0
$ gcc -mfpmath=387 -Wall -O2 td.c
$ ./a.out ; echo $?
1

[Bug c/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

[bruno at clisp dot org via Gcc-bugs]

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

Bruno Haible  changed:

   What|Removed |Added

  Build||x86_64-linux-gnu
   Host||x86_64-linux-gnu
 Target||x86_64-linux-gnu

--- Comment #2 from Bruno Haible  ---
Note: "gcc-version 13.2.0" just invokes gcc-13.2.0, which I built from source.

[Bug c/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #1 from Bruno Haible  ---
Created attachment 57913
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57913=edit
test case td.c

[Bug c/114659] New: gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

[bruno at clisp dot org via Gcc-bugs]

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

Bug ID: 114659
   Summary: gcc miscompiles a __builtin_memcpy on i386, leading to
wrong results for SNaN
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 57912
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57912=edit
test case tf.c

In the two attached test cases, gcc miscompiles a __builtin_memcpy invocation.
In the first test case, the data type is a 'float' (4 bytes).
In the second test case, the data type is a 'double' (8 bytes).

A value of this data type exists in memory, given as *x and *y.
A modified copy of this value, convert_snan_to_qnan(value), exists
also in the stack, among the local variables.
gcc implements the __builtin_memcpy operation by accessing
convert_snan_to_qnan(value) instead of the original value.

How to reproduce:

$ gcc-version 13.2.0 -m32 -Wall tf.c
$ ./a.out ; echo $?
0
$ gcc-version 13.2.0 -m32 -Wall -O2 tf.c
$ ./a.out ; echo $?
1

$ gcc-version 13.2.0 -m32 -Wall td.c
$ ./a.out ; echo $?
0
$ gcc-version 13.2.0 -m32 -Wall -O2 td.c
$ ./a.out ; echo $?
1

Analysis:

$ gcc-version 13.2.0 -m32 -Wall -O2 -S tf.c

tf.c has this function:

int
my_totalorderf (float const *x, float const *y)
{
  int xs = __builtin_signbit (*x);
  int ys = __builtin_signbit (*y);
  if (!xs != !ys)
return xs;

  int xn = __builtin_isnan (*x);
  int yn = __builtin_isnan (*y);
  if (!xn != !yn)
return !xn == !xs;
  if (!xn)
return *x <= *y;

  unsigned int extended_sign = -!!xs;
  union { unsigned int i; float f; } xu = {0}, yu = {0};
  __builtin_memcpy (, x, sizeof (float));
  __builtin_memcpy (, y, sizeof (float));
  return (xu.i ^ extended_sign) <= (yu.i ^ extended_sign);
}

tf.s looks like this:

my_totalorderf:
pushl   %ebx
subl$8, %esp
;;  int xs = __builtin_signbit (*x);
movl16(%esp), %eax
flds(%eax)
fsts(%esp);; [%esp+0] := convert_snan_to_qnan(*x)
fxam
fnstsw  %ax
movl%eax, %edx
movl20(%esp), %eax
andl$512, %edx
;;  int ys = __builtin_signbit (*y);
flds(%eax)
sete%cl
fsts4(%esp)   ;; [%esp+4] := convert_snan_to_qnan(*y)
fxam
fnstsw  %ax
testb   $2, %ah
sete%al
;;  if (!xs != !ys)
cmpb%al, %cl
jne .L12
;;  int xn = __builtin_isnan (*x);
fxch%st(1)
fucomi  %st(0), %st
fxch%st(1)
setnp   %bl
;;  int yn = __builtin_isnan (*y);
fucomip %st(0), %st
setnp   %al
;;  if (!xn != !yn)
cmpb%al, %bl
jne .L11
fstp%st(0)
flds(%esp)
fucomi  %st(0), %st
jp  .L9
flds4(%esp)
xorl%edx, %edx
fcomip  %st(1), %st
fstp%st(0)
setnb   %dl
jmp .L6
.p2align 4,,10
.p2align 3
.L12:
fstp%st(0)
fstp%st(0)
.L6:
addl$8, %esp
movl%edx, %eax
popl%ebx
ret
.p2align 4,,10
.p2align 3
.L11:
fucomip %st(0), %st
setp%dl
addl$8, %esp
xorl%ecx, %edx
popl%ebx
movzbl  %dl, %edx
movl%edx, %eax
ret
.p2align 4,,10
.p2align 3
.L9:
fstp%st(0)
negl%edx  ;; computes -xs
movl(%esp), %eax  ;; fetches convert_snan_to_qnan(*x)
instead of *x
movl4(%esp), %ebx ;; fetches convert_snan_to_qnan(*y)
instead of *y
sbbl%edx, %edx;; computes extended_sign = -!!xs;
xorl%edx, %eax;; computes (xu.i ^ extended_sign)
xorl%ebx, %edx;; computes (yu.i ^ extended_sign)
cmpl%eax, %edx;; compares (xu.i ^ extended_sign) and
(xu.i ^ extended_sign)
setnb   %dl
movzbl  %dl, %edx
jmp .L6

As you can see, (%esp) and 4(%esp) contain *not* the original
*x and *y respectively, but the result of an flds/fsts instruction pair,
that is, convert_snan_to_qnan(*x) and convert_snan_to_qnan(*y), respectively.

See https://lists.gnu.org/archive/html/bug-gnulib/2023-10/msg00060.html
for some background about these instructions on i386.

The analysis of td.c is similar; here the value is stored to
memory through an fldl/fstl pair.

[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #12 from Li Pan  ---
#include 

extern unsigned long get_vl ();

#if 0

#else

vint32m1_t test (vint32m1_t a)
{
  unsigned b;
  return __riscv_vadd_vx_i32m1 (a, b, get_vl ()); // No ICE
}

vbool16_t test (vuint64m4_t a)
{
  unsigned long b;
  return __riscv_vmsne_vx_u64m4_b16 (a, b, get_vl ()); // ICE
}

#endif

This is comes from the below parts:

!(targetm.class_likely_spilled_p (REGNO_REG_CLASS (ret_start)));

For RVV, the reg_class values are listed as below. Because the Vector Mask has
only one reg, then it will be considered as likely spilled as the hook
TARGET_CLASS_LIKELY_SPILLED_P default returns true if reg_class_size[class] ==
1.

Not very sure if overriding TARGET_CLASS_LIKELY_SPILLED_P hook for riscv is a
reasonable fix, trying to understand TARGET_CLASS_LIKELY_SPILLED_P...


panli-reg_class_size[0]=0
panli-reg_class_size[1]=14 
   

panli-reg_class_size[2]=26
panli-reg_class_size[3]=32 
   

panli-reg_class_size[4]=32
panli-reg_class_size[5]=2  
   

panli-reg_class_size[6]=1  <= VM
panli-reg_class_size[7]=31 <= VD   
   

panli-reg_class_size[8]=32 <= V
panli-reg_class_size[9]=98

[Bug driver/114658] branch "releases/gcc-13" builds "gcc version 14.0.1 (experimental)"

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
That doesn't seem possible.
Are you sure you've correctly checked out the releases/gcc-13 branch?
That branch should contain gcc/BASE-VER with 13.2.1 in it and the resulting
compiler should report that, like in:
./xgcc -B ./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--enable-languages=default,ada,obj-c++,lto,go,d,m2
--enable-checking=yes,rtl,extra --enable-libstdcxx-backtrace=yes
--with-isl=/usr/src/isl-0.24/obji/
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20240329 (GCC)

[Bug driver/114658] New: branch "releases/gcc-13" builds "gcc version 14.0.1 (experimental)"

[felix-gcc at fefe dot de via Gcc-bugs]

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

Bug ID: 114658
   Summary: branch "releases/gcc-13" builds "gcc version 14.0.1
(experimental)"
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix-gcc at fefe dot de
  Target Milestone: ---

Not sure how and where to file this bug, sorry.

I'm trying to build the current stable release branch, i.e. 13.2 with bug fixes
from git.
So I do git checkout releases/gcc-13 and build gcc, but the result doesn't say
it is gcc 13.2.1, it says it's gcc 14.0.1 (experimental).

Shouldn't this branch contain the non-experimental version?

[Bug c/114657] Invalid type conversion from some _BitInt bit-fields

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

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

--- Comment #3 from Joseph S. Myers  ---
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2958.htm has my analysis of
the various notions of "type" used in relation to bit-fields and the questions
of what expressions are considered to have special properties associated with
referring to a bit-field.