[Bug plugins/110610] New: File insn-opinit.h not installed ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 110610
   Summary: File insn-opinit.h not installed ?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Recent linux kernels seem to think that file insn-opinit.h is available
in a gcc install.

  CC  /home/dcb38/linuxKernel/linux-6.4/tools/objtool/arch/x86/special.o
In file included from scripts/gcc-plugins/gcc-common.h:73,
 from scripts/gcc-plugins/stackleak_plugin.c:30:
/home/dcb38/gcc/results.20230701.valgrind/lib/gcc/x86_64-pc-linux-gnu/14.0.0/plugin/include/internal-fn.h:24:10:
fatal error: insn-opinit.h: No such file or directory
   24 | #include "insn-opinit.h"
  |  ^~~

I found a straightforward copy of the file from a gcc build made the problem
go away:

$ history | grep insn | grep cp
 1019  cp /home/dcb38/gcc/working/gcc/insn-opinit.h
/home/dcb38/gcc/results.20230708.asan.ubsan/lib/gcc/x86_64-pc-linux-gnu/14.0.0/plugin/include/
 1022  history | grep insn | grep cp
$ 

I am pretty sure there is a better way than a "cp" command to solve this
problem.
Perhaps the install could do the copy instead ?

[Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons

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

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

--- Comment #60 from Richard Biener  ---
(In reply to Tamar Christina from comment #59)
> after ifcvt we end up with:
> 
>   _162 = chrg_init_70 * iftmp.8_76;
>   _164 = ABS_EXPR <_162>;
>   _167 = -_164;
>   _ifc__166 = distbb_74 < iftmp.0_97 ? _167 : 0.0;
>   prephitmp_169 = distbb_74 >= 0.0 ? _ifc__166 : _168;
>   
> instead of
> 
>   _160 = chrg_init_75 * iftmp.8_80;
>   prephitmp_161 = distbb_79 < 0.0 ? chrg_init_75 : _160;
>   _164 = ABS_EXPR ;
>   _166 = -_164;
>   prephitmp_167 = distbb_79 < iftmp.0_96 ? _166 : 0.0;
> 
> previously we'd make COND_MUL and COND_NEG and so don't need a VCOND in the
> end,
> now we select after the multiplication, so we only have a COND_NEG followed
> by a VCOND.
> 
> This is obviously worse, but I have no idea how to recover it.  Any ideas?

None.  This is with -O3, right?  Can you try selectively disabling parts
of PRE with -fno-tree-partial-pre -fno-code-hoisting?  But I suspect it's
the improvement for general PRE that we hit here.

One idea that was always floating around was to move PRE after loop opts
like we did with predcom.  But the no PRE before loop will likely hurt as well
so we might instead want to limit PRE when it involves generating
constants in PHIs and schedule another PRE after loop opts (at some cost
then).  It's something to experiment with ...

[Bug target/110217] [avr] SREG: use BSET and BCLR instead of load/modify/write

[mx682x at gmail dot com via Gcc-bugs]

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

--- Comment #2 from mx682x at gmail dot com ---
I see, thank you for you input.

> Apart from that, the proposed patch won't work for indirect addressing, or
> when the compiler is turning direct addresses to indirect addresses (using
> CSE etc, common subexpression elimination and similar strategies).
> 
> Also the patch relies on insn combine which only runs when optimization is
> on, thus any application which relies on that optimization will glitch at
> -O0.

However, just out of curiosity, doesn't this also apply to the "Single-Cycle
I/O access" instructions cbi/sbi? Afterall, I've just duplicated the respective
code and andjusted the predicate for the address.

[Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming

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

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

--- Comment #19 from Richard Biener  ---
It seems that the C++ FE change in comment#13 causes libreoffice to fail to
build with

[  553s]
/home/abuild/rpmbuild/BUILD/libreoffice-7.5.4.2/workdir/UnpackedTarball/skia/include/private/SkVx.h:
In function 'interpret_skvm':
[  553s]
/home/abuild/rpmbuild/BUILD/libreoffice-7.5.4.2/workdir/UnpackedTarball/skia/include/private/SkVx.h:150:
error: inlining failed in call to 'always_inline' '__ct_comp ': target specific
option mismatch
[  553s]   150 | using VecStorage::VecStorage;
[  553s]   | 

I have yet to reproduce and extract a testcase though.

[Bug plugins/110610] File insn-opinit.h not installed ?

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #1 from Xi Ruoyao  ---
(In reply to David Binderman from comment #0)
> Recent linux kernels seem to think that file insn-opinit.h is available
> in a gcc install.

Not really "recent linux kernels", it has been use GCC plugins for a long time
(but you can disable it in the configuration).  And it seems r14-1551 has added
#include "insn-opinit.h" into internal-fn.h but did not installed
insn-opinit.h.

[Bug plugins/110610] File insn-opinit.h not installed ?

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

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

 CC||avieira at gcc dot gnu.org

--- Comment #2 from avieira at gcc dot gnu.org ---
I can't reproduce this but it seems like the modula2 build also suffers from
the same issue, see PR110284.

David, what exactly are you trying to build? Can you give us the configure
command?

[Bug middle-end/88873] missing vectorization for decomposed operations on a vector type

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:12b78b0b42d53019eb2c500d386094194e90ad16

commit r14-2406-g12b78b0b42d53019eb2c500d386094194e90ad16
Author: Roger Sayle 
Date:   Mon Jul 10 09:06:52 2023 +0100

i386: Add new insvti_lowpart_1 and insvdi_lowpart_1 patterns.

This patch implements another of Uros' suggestions, to investigate a
insvti_lowpart_1 pattern to improve TImode parameter passing on x86_64.
In PR 88873, the RTL the middle-end expands for passing V2DF in TImode
is subtly different from what it does for V2DI in TImode, sufficiently so
that my explanations for why insvti_lowpart_1 isn't required don't apply
in this case.

This patch adds an insvti_lowpart_1 pattern, complementing the existing
insvti_highpart_1 pattern, and also a 32-bit variant, insvdi_lowpart_1.
Because the middle-end represents 128-bit constants using CONST_WIDE_INT
and 64-bit constants using CONST_INT, it's easiest to treat these as
different patterns, rather than attempt  parameterization.

This patch also includes a peephole2 (actually a pair) to transform
xchg instructions into mov instructions, when one of the destinations
is unused.  This optimization is required to produce the optimal code
sequences below.

For the 64-bit case:

__int128 foo(__int128 x, unsigned long long y)
{
  __int128 m = ~((__int128)~0ull);
  __int128 t = x & m;
  __int128 r = t | y;
  return r;
}

Before:
xchgq   %rdi, %rsi
movq%rdx, %rax
xorl%esi, %esi
xorl%edx, %edx
orq %rsi, %rax
orq %rdi, %rdx
ret

After:
movq%rdx, %rax
movq%rsi, %rdx
ret

For the 32-bit case:

long long bar(long long x, int y)
{
  long long mask = ~0ull << 32;
  long long t = x & mask;
  long long r = t | (unsigned int)y;
  return r;
}

Before:
pushl   %ebx
movl12(%esp), %edx
xorl%ebx, %ebx
xorl%eax, %eax
movl16(%esp), %ecx
orl %ebx, %edx
popl%ebx
orl %ecx, %eax
ret

After:
movl12(%esp), %eax
movl8(%esp), %edx
ret

2023-07-10  Roger Sayle  

gcc/ChangeLog
* config/i386/i386.md (peephole2): Transform xchg insn with a
REG_UNUSED note to a (simple) move.
(*insvti_lowpart_1): New define_insn_and_split.
(*insvdi_lowpart_1): Likewise.

gcc/testsuite/ChangeLog
* gcc.target/i386/insvdi_lowpart-1.c: New test case.
* gcc.target/i386/insvti_lowpart-1.c: Likewise.

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

[arndtthomas at gmx dot de via Gcc-bugs]

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

--- Comment #4 from Thomas Arndt  ---
Sounds good, I would agree on your solution as well. So since it's not related
to clang and can be reproduced with gcc is there a fix planned?

[Bug libstdc++/58338] Add noexcept to functions with a narrow contract

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

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

--- Comment #18 from Jonathan Wakely  ---
Our precondition checks never throw, so those functions never throw.

[Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming

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

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

--- Comment #20 from Richard Biener  ---
(In reply to Richard Biener from comment #19)
> It seems that the C++ FE change in comment#13 causes libreoffice to fail to
> build with
> 
> [  553s]
> /home/abuild/rpmbuild/BUILD/libreoffice-7.5.4.2/workdir/UnpackedTarball/skia/
> include/private/SkVx.h: In function 'interpret_skvm':
> [  553s]
> /home/abuild/rpmbuild/BUILD/libreoffice-7.5.4.2/workdir/UnpackedTarball/skia/
> include/private/SkVx.h:150: error: inlining failed in call to
> 'always_inline' '__ct_comp ': target specific option mismatch
> [  553s]   150 | using VecStorage::VecStorage;
> [  553s]   | 
> 
> I have yet to reproduce and extract a testcase though.

libreoffice has a skia import and links its Library/libskialo.so library
with LTO, combining the AVX, HSW, SSE41, SSE42, SSSE3, CRC32, SKX, ...
SkOpts_*.o objects which likely follow a very similar scheme as the firefox
copy.  SkOpts_hsw.cpp looks like

#include "src/core/SkOpts.h"

#define SK_OPTS_NS hsw
#include "src/core/SkCubicSolver.h"
#include "src/opts/SkBitmapProcState_opts.h"
#include "src/opts/SkBlitRow_opts.h"
#include "src/opts/SkRasterPipeline_opts.h"
#include "src/opts/SkSwizzler_opts.h"
#include "src/opts/SkUtils_opts.h"
#include "src/opts/SkVM_opts.h"

namespace SkOpts {
void Init_hsw() {
blit_row_color32 = hsw::blit_row_color32;
blit_row_s32a_opaque = hsw::blit_row_s32a_opaque;

S32_alpha_D32_filter_DX  = hsw::S32_alpha_D32_filter_DX;

cubic_solver = SK_OPTS_NS::cubic_solver;

RGBA_to_BGRA  = SK_OPTS_NS::RGBA_to_BGRA;
RGBA_to_rgbA  = SK_OPTS_NS::RGBA_to_rgbA;
RGBA_to_bgrA  = SK_OPTS_NS::RGBA_to_bgrA;
gray_to_RGB1  = SK_OPTS_NS::gray_to_RGB1;
grayA_to_RGBA = SK_OPTS_NS::grayA_to_RGBA;
grayA_to_rgbA = SK_OPTS_NS::grayA_to_rgbA;
inverted_CMYK_to_RGB1 = SK_OPTS_NS::inverted_CMYK_to_RGB1;
inverted_CMYK_to_BGR1 = SK_OPTS_NS::inverted_CMYK_to_BGR1;

#define M(st) stages_highp[SkRasterPipeline::st] = (StageFn)SK_OPTS_NS::st;
SK_RASTER_PIPELINE_STAGES(M)
just_return_highp = (StageFn)SK_OPTS_NS::just_return;
start_pipeline_highp = SK_OPTS_NS::start_pipeline;
#undef M

#define M(st) stages_lowp[SkRasterPipeline::st] =
(StageFn)SK_OPTS_NS::lowp::st;
SK_RASTER_PIPELINE_STAGES(M)
just_return_lowp = (StageFn)SK_OPTS_NS::lowp::just_return;
start_pipeline_lowp = SK_OPTS_NS::lowp::start_pipeline;
#undef M

interpret_skvm = SK_OPTS_NS::interpret_skvm;
}
}  // namespace SkOpts

the question in the end is why we fail to process the always_inlines
early here and only discover them late.  Unfortunately the inline
diagnostic doesn't print the original TU name (that would be useful
for all late LTO diagnostics).

I'm not sure whether this is an issue with the C++ frontend change or with
the ODR issues present in Skia.  Eventually since we're dealing with
aliases(?), always_inline isn't appropriately detected or still missing
on some callees.

Unfortunately there isn't a knob to diagnose late inlined always-inline
functions.

[Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming

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

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

--- Comment #21 from Richard Biener  ---
Created attachment 55512
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55512&action=edit
another testcase

This one needs -mavx2 -mf16c -mfma -fPIC -O2 -std=c++17

[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-07-10

--- Comment #18 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #13)
> I think there would need to be a period of deprecation and an optional
> assertion enabled by _GLIBCXX_ASSERTIONS before we can do that (assuming we
> want to).

As I said in the PR 109891 dup, _GLIBCXX_DEBUG_PEDANTIC exists for precisely
this kind of case:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_semantics.html

So let's add that for now.

[Bug target/110611] New: X86 is not honouring POINTERS_EXTEND_UNSIGNED in m32 code.

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

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

Bug ID: 110611
   Summary: X86 is not honouring POINTERS_EXTEND_UNSIGNED in m32
code.
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

I've made this target but not sure exactly where it lies - the gimplifier
output looks suspect already - so maybe it's gimplifer/frontend.

this code is distilled from a version of GDB (7.12) where 'bar' is a system
call that breaks with a sign-extended pointer...

the x86 backend sets:
gcc/config/i386/i386.h:#define POINTERS_EXTEND_UNSIGNED 1
which ought, according to gccint mean that pointers get sign-extended...

t.c 

typedef unsigned long long uint64_t;
typedef uint64_t another_t;
typedef unsigned char byte;

extern void bar (another_t y, another_t z);

void foo (byte *p)
{
   another_t x = (another_t)p;

   bar ((another_t) p, x);
}

===

build : $(compiler) -m32 t.c -S -fdump-tree-gimple -Wall -Wextra

 * If built by the GCC compiler, we get warnings like;
  warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
9 |another_t x = (another_t)p;

 * if built by G++ we get no warnings

However, in both cases, the generated assembler sign-extends *p => x and the
first arg to bar.

gimple:

void foo (byte * p)
{
  another_t x;

  p.0_1 = (int) p;
  x = (another_t) p.0_1;
  p.1_2 = (int) p;
  _3 = (long long unsigned int) p.1_2;
  bar (_3, x);
}

maybe the combination of 'perhaps wrong' user code, plus the maze of typedefs
is confusing something.

[Bug target/110611] X86 is not honouring POINTERS_EXTEND_UNSIGNED in m32 code.

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu,
   ||x86_64-darwin, i686-darwin
   Keywords||wrong-code
  Known to fail||10.5.0, 14.0

--- Comment #1 from Iain Sandoe  ---
Apple GCC-4.2.1 does zero-extend.
I checked back to 5.5 on Darwin the same issue is present to at least then.

[Bug target/110611] X86 is not honouring POINTERS_EXTEND_UNSIGNED in m32 code.

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

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

--- Comment #2 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #0)


> the x86 backend sets:
> gcc/config/i386/i386.h:#define POINTERS_EXTEND_UNSIGNED 1
> which ought, according to gccint mean that pointers get sign-extended...

erm I mean zero-extended:

POINTERS_EXTEND_UNSIGNED [Macro]
A C expression that determines how pointers should be extended from ptr_mode to
either Pmode or word_mode. It is greater than zero if pointers should be
zero-extended, zero if they should be sign-extended, and negative if some other
sort of conversion is needed.

[Bug tree-optimization/109945] Escape analysis hates copy elision: different result with -O1 vs -O2

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #21 from Richard Biener  ---
Yes, probably a duplicate.

Jason, it would be nice to have a handle to fix this old issue.

[Bug debug/109237] csmith: another timeout with -g -O3 this time since r12-156-g8d4c374c4419a875

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
   Keywords|needs-reduction |
 Status|ASSIGNED|NEW

--- Comment #16 from Richard Biener  ---
I wouldn't say "fixed", but at least it's as far as hotspots go.

[Bug plugins/110610] File insn-opinit.h not installed ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
(In reply to avieira from comment #2)
> I can't reproduce this but it seems like the modula2 build also suffers from
> the same issue, see PR110284.
> 
> David, what exactly are you trying to build? Can you give us the configure
> command?

Perhaps I haven't given enough clues. 

I was trying to build linux-6.4 & yesterday's linux-6.5-rc1 with recent gcc
trunk 
dated 20230701 & 20230708.

Configure lines are

make distclean
make allyesconfig
make

[Bug target/110611] X86 is not honouring POINTERS_EXTEND_UNSIGNED in m32 code.

[schwab--- via Gcc-bugs]

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

--- Comment #3 from Andreas Schwab  ---
uint64_t is neither Pmode nor word_mode here.  POINTERS_EXTEND_UNSIGNED is only
relevant if POINTER_SIZE is narrower than Pmode.

[Bug target/110611] X86 is not honouring POINTERS_EXTEND_UNSIGNED in m32 code.

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

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

--- Comment #4 from Iain Sandoe  ---
(In reply to Andreas Schwab from comment #3)
> uint64_t is neither Pmode nor word_mode here.  POINTERS_EXTEND_UNSIGNED is
> only relevant if POINTER_SIZE is narrower than Pmode.

So, just pilot-error, then?

[Bug plugins/110610] File insn-opinit.h not installed ?

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

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

--- Comment #4 from Xi Ruoyao  ---
(In reply to avieira from comment #2)
> I can't reproduce this but it seems like the modula2 build also suffers from
> the same issue, see PR110284.
> 
> David, what exactly are you trying to build? Can you give us the configure
> command?

The OP is building a GCC plugin, it includes internal-fn.h.  But internal-fn.h
includes insn-opinit.h, and insn-opinit.h is not installed.

See
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/gcc-plugins/gcc-common.h#n73

[Bug target/110611] X86 is not honouring POINTERS_EXTEND_UNSIGNED in m32 code.

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #5 from Alexander Monakov  ---
You cannot use this internal macro to deduce how your C testcase should behave.
The language standard says this conversion has implementation-defined behavior,
and GCC manual (the user manual, not the internals manual) has a chapter on
implementation-defined behavior, which explicitly says:

https://gcc.gnu.org/onlinedocs/gcc/Arrays-and-pointers-implementation.html

A cast from pointer to integer [...] sign-extends if the pointer representation
is smaller than the integer type [...].

So the behavior is the same for all targets.

[Bug target/110611] X86 is not honouring POINTERS_EXTEND_UNSIGNED in m32 code.

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #6 from Iain Sandoe  ---
so just wrong code; OK.

[Bug plugins/110610] File insn-opinit.h not installed ?

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

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

--- Comment #5 from avieira at gcc dot gnu.org ---
intenral-fn.h is generated at gcc build-time. I'm not sure we want to 'install'
it with a gcc install. Might make more sense to trigger a the generation of it
when building this gcc-plugin. But I'm not sure... I'll ask around the
community see what people think.

[Bug plugins/110610] File insn-opinit.h not installed ?

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

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

--- Comment #6 from Xi Ruoyao  ---
(In reply to avieira from comment #5)
> intenral-fn.h is generated at gcc build-time.

I guess you mean insn-opinit.h, not internal-fn.h.  internal-fn.h is in the GCC
Git repo.

> I'm not sure we want to
> 'install' it with a gcc install.

We are already installing insn-{addr,attr-common,attr,codes,...}.h anyway.

[Bug plugins/110610] File insn-opinit.h not installed ?

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

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

--- Comment #7 from avieira at gcc dot gnu.org ---
> I guess you mean insn-opinit.h, not internal-fn.h.  internal-fn.h is in the 
> GCC Git repo.

Yeah sorry! I did mean insn-opinit.h

> We are already installing insn-{addr,attr-common,attr,codes,...}.h anyway.

Fair!

[Bug plugins/110610] File insn-opinit.h not installed ?

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

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

--- Comment #8 from avieira at gcc dot gnu.org ---
I'll try adding to one of the header file lists in gcc's makefile. Probably the
INTERNAL_FN_H one.

[Bug plugins/110610] File insn-opinit.h not installed ?

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

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2023-07-10
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |avieira at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

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

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

--- Comment #33 from Florian Weimer  ---
(In reply to Andrew Pinski from comment #32)
> (In reply to Florian Weimer from comment #31)
> > Will propose a backport to 13 in ~2 weeks.
> 
> Any news on the backport? There is aim to release GCC 13.2.0 at the end of
> July.

I managed to produce a warning regression. I should have time this week to fix
that, and do the backport this week.

[Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons

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

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

--- Comment #61 from Tamar Christina  ---
(In reply to Richard Biener from comment #60)
> (In reply to Tamar Christina from comment #59)
> > after ifcvt we end up with:
> > 
> >   _162 = chrg_init_70 * iftmp.8_76;
> >   _164 = ABS_EXPR <_162>;
> >   _167 = -_164;
> >   _ifc__166 = distbb_74 < iftmp.0_97 ? _167 : 0.0;
> >   prephitmp_169 = distbb_74 >= 0.0 ? _ifc__166 : _168;
> >   
> > instead of
> > 
> >   _160 = chrg_init_75 * iftmp.8_80;
> >   prephitmp_161 = distbb_79 < 0.0 ? chrg_init_75 : _160;
> >   _164 = ABS_EXPR ;
> >   _166 = -_164;
> >   prephitmp_167 = distbb_79 < iftmp.0_96 ? _166 : 0.0;
> > 
> > previously we'd make COND_MUL and COND_NEG and so don't need a VCOND in the
> > end,
> > now we select after the multiplication, so we only have a COND_NEG followed
> > by a VCOND.
> > 
> > This is obviously worse, but I have no idea how to recover it.  Any ideas?
> 
> None.  This is with -O3, right?  Can you try selectively disabling parts
> of PRE with -fno-tree-partial-pre -fno-code-hoisting?  But I suspect it's
> the improvement for general PRE that we hit here.
> 

Those don't seem to make a difference sadly.

> One idea that was always floating around was to move PRE after loop opts
> like we did with predcom.  But the no PRE before loop will likely hurt as
> well
> so we might instead want to limit PRE when it involves generating
> constants in PHIs and schedule another PRE after loop opts (at some cost
> then).  It's something to experiment with ...

It looks like `-fno-tree-pre` does the trick, but then of course, messes up
elsewhere.  The conditional statement seem to stay in the most complicated form
possible in scalar code.

I'll try to track down what to turn off and experiment with a pre2 after vect.
Is before predcom a good place?

[Bug tree-optimization/110557] [13/14 Regression] Wrong code for x86_64-linux-gnu with -O3 -mavx2: vectorized loop mishandles signed bit-fields

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Xi Ruoyao :

https://gcc.gnu.org/g:63ae6bc60c0f67fb2791991bf4b6e7e0a907d420

commit r14-2407-g63ae6bc60c0f67fb2791991bf4b6e7e0a907d420
Author: Xi Ruoyao 
Date:   Thu Jul 6 23:08:57 2023 +0800

vect: Fix vectorized BIT_FIELD_REF for signed bit-fields [PR110557]

If a bit-field is signed and it's wider than the output type, we must
ensure the extracted result sign-extended.  But this was not handled
correctly.

For example:

int x : 8;
long y : 55;
bool z : 1;

The vectorized extraction of y was:

vect__ifc__49.29_110 =
  MEM  [(struct Item *)vectp_a.27_108];
vect_patt_38.30_112 =
  vect__ifc__49.29_110 & { 9223372036854775552, 9223372036854775552 };
vect_patt_39.31_113 = vect_patt_38.30_112 >> 8;
vect_patt_40.32_114 =
  VIEW_CONVERT_EXPR(vect_patt_39.31_113);

This is obviously incorrect.  This pach has implemented it as:

vect__ifc__25.16_62 =
  MEM  [(struct Item *)vectp_a.14_60];
vect_patt_31.17_63 =
  VIEW_CONVERT_EXPR(vect__ifc__25.16_62);
vect_patt_32.18_64 = vect_patt_31.17_63 << 1;
vect_patt_33.19_65 = vect_patt_32.18_64 >> 9;

gcc/ChangeLog:

PR tree-optimization/110557
* tree-vect-patterns.cc (vect_recog_bitfield_ref_pattern):
Ensure the output sign-extended if necessary.

gcc/testsuite/ChangeLog:

PR tree-optimization/110557
* g++.dg/vect/pr110557.cc: New test.

[Bug tree-optimization/110557] [13/14 Regression] Wrong code for x86_64-linux-gnu with -O3 -mavx2: vectorized loop mishandles signed bit-fields

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Xi Ruoyao :

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

commit r13-7553-g1e6a948cd22f2f142cdc828296f78c7af9e283c8
Author: Xi Ruoyao 
Date:   Thu Jul 6 23:08:57 2023 +0800

vect: Fix vectorized BIT_FIELD_REF for signed bit-fields [PR110557]

If a bit-field is signed and it's wider than the output type, we must
ensure the extracted result sign-extended.  But this was not handled
correctly.

For example:

int x : 8;
long y : 55;
bool z : 1;

The vectorized extraction of y was:

vect__ifc__49.29_110 =
  MEM  [(struct Item *)vectp_a.27_108];
vect_patt_38.30_112 =
  vect__ifc__49.29_110 & { 9223372036854775552, 9223372036854775552 };
vect_patt_39.31_113 = vect_patt_38.30_112 >> 8;
vect_patt_40.32_114 =
  VIEW_CONVERT_EXPR(vect_patt_39.31_113);

This is obviously incorrect.  This pach has implemented it as:

vect__ifc__25.16_62 =
  MEM  [(struct Item *)vectp_a.14_60];
vect_patt_31.17_63 =
  VIEW_CONVERT_EXPR(vect__ifc__25.16_62);
vect_patt_32.18_64 = vect_patt_31.17_63 << 1;
vect_patt_33.19_65 = vect_patt_32.18_64 >> 9;

gcc/ChangeLog:

PR tree-optimization/110557
* tree-vect-patterns.cc (vect_recog_bitfield_ref_pattern):
Ensure the output sign-extended if necessary.

gcc/testsuite/ChangeLog:

PR tree-optimization/110557
* g++.dg/vect/pr110557.cc: New test.

(cherry picked from commit 63ae6bc60c0f67fb2791991bf4b6e7e0a907d420)

[Bug tree-optimization/110557] [13/14 Regression] Wrong code for x86_64-linux-gnu with -O3 -mavx2: vectorized loop mishandles signed bit-fields

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Target Milestone|13.3|13.2
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Xi Ruoyao  ---
Fixed for 14 and 13.2.

[Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons

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

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

--- Comment #62 from Richard Biener  ---
(In reply to Tamar Christina from comment #61)
> (In reply to Richard Biener from comment #60)
> > (In reply to Tamar Christina from comment #59)
> > > after ifcvt we end up with:
> > > 
> > >   _162 = chrg_init_70 * iftmp.8_76;
> > >   _164 = ABS_EXPR <_162>;
> > >   _167 = -_164;
> > >   _ifc__166 = distbb_74 < iftmp.0_97 ? _167 : 0.0;
> > >   prephitmp_169 = distbb_74 >= 0.0 ? _ifc__166 : _168;
> > >   
> > > instead of
> > > 
> > >   _160 = chrg_init_75 * iftmp.8_80;
> > >   prephitmp_161 = distbb_79 < 0.0 ? chrg_init_75 : _160;
> > >   _164 = ABS_EXPR ;
> > >   _166 = -_164;
> > >   prephitmp_167 = distbb_79 < iftmp.0_96 ? _166 : 0.0;
> > > 
> > > previously we'd make COND_MUL and COND_NEG and so don't need a VCOND in 
> > > the
> > > end,
> > > now we select after the multiplication, so we only have a COND_NEG 
> > > followed
> > > by a VCOND.
> > > 
> > > This is obviously worse, but I have no idea how to recover it.  Any ideas?
> > 
> > None.  This is with -O3, right?  Can you try selectively disabling parts
> > of PRE with -fno-tree-partial-pre -fno-code-hoisting?  But I suspect it's
> > the improvement for general PRE that we hit here.
> > 
> 
> Those don't seem to make a difference sadly.
> 
> > One idea that was always floating around was to move PRE after loop opts
> > like we did with predcom.  But the no PRE before loop will likely hurt as
> > well
> > so we might instead want to limit PRE when it involves generating
> > constants in PHIs and schedule another PRE after loop opts (at some cost
> > then).  It's something to experiment with ...
> 
> It looks like `-fno-tree-pre` does the trick, but then of course, messes up
> elsewhere.  The conditional statement seem to stay in the most complicated
> form possible in scalar code.
> 
> I'll try to track down what to turn off and experiment with a pre2 after
> vect.
> Is before predcom a good place?

I would avoid putting it into the loop pipeline.  Instead I'd turn the
FRE pass that runs after tracer into PRE.  Maybe conditional on whether
there are any loops.

Note it's not so easy to "tame" PRE, the existing things happen at
elimination time in eliminate_dom_walker::eliminate_stmt.  I would
experiment with restricting the use of inserted PHIs in innermost(!)
loops containing invariants, maybe only if the number of PHI args is
more than two ... (but that's somewhat artificial).

That said, I'm not really convinced this is a good idea.

[Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons

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

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

--- Comment #63 from Tamar Christina  ---
> > It looks like `-fno-tree-pre` does the trick, but then of course, messes up
> > elsewhere.  The conditional statement seem to stay in the most complicated
> > form possible in scalar code.
> > 
> > I'll try to track down what to turn off and experiment with a pre2 after
> > vect.
> > Is before predcom a good place?
> 
> I would avoid putting it into the loop pipeline.  Instead I'd turn the
> FRE pass that runs after tracer into PRE.  Maybe conditional on whether
> there are any loops.
> 
> Note it's not so easy to "tame" PRE, the existing things happen at
> elimination time in eliminate_dom_walker::eliminate_stmt.  I would
> experiment with restricting the use of inserted PHIs in innermost(!)
> loops containing invariants, maybe only if the number of PHI args is
> more than two ... (but that's somewhat artificial).
> 
> That said, I'm not really convinced this is a good idea.

I hear you.. there's also the added complexity that this likely only is
beneficial for fully masked architectures.  I wonder, if it might be feasible
and better to pass on additional information from pre to ifcvt to indicate that
the operation was created from a common block.

In which case ifcvt could move the cond to just before the first shared
statement?

[Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons

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

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

--- Comment #64 from Richard Biener  ---
(In reply to Tamar Christina from comment #63)
> > > It looks like `-fno-tree-pre` does the trick, but then of course, messes 
> > > up
> > > elsewhere.  The conditional statement seem to stay in the most complicated
> > > form possible in scalar code.
> > > 
> > > I'll try to track down what to turn off and experiment with a pre2 after
> > > vect.
> > > Is before predcom a good place?
> > 
> > I would avoid putting it into the loop pipeline.  Instead I'd turn the
> > FRE pass that runs after tracer into PRE.  Maybe conditional on whether
> > there are any loops.
> > 
> > Note it's not so easy to "tame" PRE, the existing things happen at
> > elimination time in eliminate_dom_walker::eliminate_stmt.  I would
> > experiment with restricting the use of inserted PHIs in innermost(!)
> > loops containing invariants, maybe only if the number of PHI args is
> > more than two ... (but that's somewhat artificial).
> > 
> > That said, I'm not really convinced this is a good idea.
> 
> I hear you.. there's also the added complexity that this likely only is
> beneficial for fully masked architectures.  I wonder, if it might be
> feasible and better to pass on additional information from pre to ifcvt to
> indicate that the operation was created from a common block.
> 
> In which case ifcvt could move the cond to just before the first shared
> statement?

I don't think PRE "knows" where the operation was created from since it's
transforms from a global dataflow problem solution.

Btw, what's the testcase your last examples are from?

[Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons

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

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

--- Comment #65 from Tamar Christina  ---
> > 
> > In which case ifcvt could move the cond to just before the first shared
> > statement?
> 
> I don't think PRE "knows" where the operation was created from since it's
> transforms from a global dataflow problem solution.
> 
> Btw, what's the testcase your last examples are from?

It's from https://gcc.gnu.org/bugzilla/attachment.cgi?id=54777

See https://godbolt.org/z/KfzW4ob4Y

[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246

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

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

--- Comment #12 from Richard Biener  ---
I can see cprop1 adds the REG_EQUAL note:

(insn 22 21 23 4 (set (reg:V8HI 100)
(zero_extend:V8HI (vec_select:V8QI (subreg:V16QI (reg:V4QI 98) 0)
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
(const_int 4 [0x4])
(const_int 5 [0x5])
 (const_int 6 [0x6])
 (const_int 7 [0x7])
 ] "t.c":12:42 7557 {sse4_1_zero_extendv8qiv8hi2}
- (expr_list:REG_DEAD (reg:V4QI 98)
-(nil)))
+ (expr_list:REG_EQUAL (const_vector:V8HI [
+(const_int 204 [0xcc]) repeated x8
+])
+(expr_list:REG_DEAD (reg:V4QI 98)
+(nil

but I don't see yet what the actual wrong transform based on this REG_EQUAL
note is?

It looks like we CSE the above with

-   46: r122:V8QI=[`*.LC3']
-  REG_EQUAL const_vector
-   48: r125:V8HI=zero_extend(vec_select(r122:V8QI#0,parallel))
-  REG_EQUAL const_vector
-  REG_DEAD r122:V8QI
-   49: r126:V8HI=r124:V8HI*r125:V8HI
-  REG_DEAD r125:V8HI
+   49: r126:V8HI=r124:V8HI*r100:V8HI

but otherwise do nothing.  So the issue is that we rely on the "undefined"
vals to have a specific value (from the earlier REG_EQUAL note) but actual
code generation doesn't ensure this (it doesn't need to).  That said,
the issue isn't the constant folding per-se but that we do not actually
constant fold but register an equality that doesn't hold.

[Bug libgcc/110179] unwind-dw2-fde-dip.c:406: assignment makes integer from pointer without a cast

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

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

Florian Weimer  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-07-10
   Assignee|unassigned at gcc dot gnu.org  |fw at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=109712

[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #12)
> I can see cprop1 adds the REG_EQUAL note:
> 
> (insn 22 21 23 4 (set (reg:V8HI 100)
> (zero_extend:V8HI (vec_select:V8QI (subreg:V16QI (reg:V4QI 98) 0)
> (parallel [
> (const_int 0 [0])
> (const_int 1 [0x1])
> (const_int 2 [0x2])
> (const_int 3 [0x3])
> (const_int 4 [0x4])
> (const_int 5 [0x5])
>  (const_int 6 [0x6])
>  (const_int 7 [0x7])
>  ] "t.c":12:42 7557 {sse4_1_zero_extendv8qiv8hi2}
> - (expr_list:REG_DEAD (reg:V4QI 98)
> -(nil)))
> + (expr_list:REG_EQUAL (const_vector:V8HI [
> +(const_int 204 [0xcc]) repeated x8
> +])
> +(expr_list:REG_DEAD (reg:V4QI 98)
> +(nil
> 
> but I don't see yet what the actual wrong transform based on this REG_EQUAL
> note is?

We constant fold V4QImode const_vector to a V8HImode const_vector with 8
defined elements. We started with undefined top four bytes, but now we
magically define them.

> 
> It looks like we CSE the above with
> 
> -   46: r122:V8QI=[`*.LC3']
> -  REG_EQUAL const_vector
> -   48: r125:V8HI=zero_extend(vec_select(r122:V8QI#0,parallel))
> -  REG_EQUAL const_vector
> -  REG_DEAD r122:V8QI
> -   49: r126:V8HI=r124:V8HI*r125:V8HI
> -  REG_DEAD r125:V8HI
> +   49: r126:V8HI=r124:V8HI*r100:V8HI
> 
> but otherwise do nothing.  So the issue is that we rely on the "undefined"
> vals to have a specific value (from the earlier REG_EQUAL note) but actual
> code generation doesn't ensure this (it doesn't need to).  That said,
> the issue isn't the constant folding per-se but that we do not actually
> constant fold but register an equality that doesn't hold.

The above CSE is the consequence of REG_EQUAL note that compiler set on the
insn. Compiler claims that the value of (insn 22) equals an array of 8 consts {
204 , ... , 204 }, but in reality (c.f. Comment #3) the value in the register
%xmm4 before VPMULLW insn is { 0, 0, 0, 0, 204, 204, 204, 204 }.

[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #10)
> (In reply to Uroš Bizjak from comment #9)
> > and simplify_replace_rtx simplifies the above to:
> > 
> > (gdb) p debug_rtx (src)
> > (const_vector:V8HI [
> > (const_int 204 [0xcc]) repeated x8
> > ])
> 
> Patched compiler simplifies to:
> 
> (gdb) p debug_rtx (src)
> (const_vector:V8HI [
> (const_int 204 [0xcc]) repeated x4
> (const_int 0 [0]) repeated x4
> ])

The patched compiler puts the above in REG_EQUAL note. While the value is "more
correct", I don't think the compiler has the right to set REG_EQUAL note when
the top 4 bytes are actually undefined (as a result of an operation with an
undefined input, which is the case with paradoxical subreg).

[Bug target/110592] [SPARC] GCC should default to TSO memory model when compiling for sparc32

[campbell+gcc-bugzilla at mumble dot net via Gcc-bugs]

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

Taylor R Campbell  changed:

   What|Removed |Added

 CC||campbell+gcc-bugzilla@mumbl
   ||e.net

--- Comment #5 from Taylor R Campbell  
---
(In reply to Eric Botcazou from comment #4)
> Well, you need to elaborate a bit here, because the current configuration
> has been there for a quarter of century and everybody had apparently
> survived it until a couple of days ago.

For most of that quarter century, memory ordering was limited to out-of-line
barrier/fence subroutines implemented in assembly, like membar_sync in Solaris
and NetBSD, or the thread-switch assembly routines in the kernel.

It is only relatively recently, since C11 and C++11, that a lot of programs
started using in-line barriers/fences and ordered memory operations like
store-release/load-acquire.

In that time, sparcv7 and sparcv8 haven't gotten a lot of attention, of course.

But since they were introduced, NetBSD has had a common userland for sparcv7
and sparcv8, just called `NetBSD/sparc', with a special libc loaded on sparcv8
to use v8-only instructions like SMUL and UMUL for runtime multiplication
subroutines to improve performance.  (We could in principle do the same for
LDSTUB in membar_sync on sparcv7, although we don't at the moment.)

But now that programs rely on compiler-generated barriers, there's a conflict
between gcc's v7 and v8 code generation:

1. `gcc -mcpu=v7' generates code that lacks LDSTUB where store-before-load
barriers are needed, so anything that uses Dekker's algorithm with in-line
barriers won't work correctly on a sparcv8 CPU (but it will only manifest in
extremely rare, hard-to-diagnose scenarios, because Dekker's algorithm is so
obscure).

2. `gcc -mcpu=v8' generates code that uses SMUL and UMUL and other instructions
that don't exist on sparcv7.

Evidently gcc can be made to generate SMUL/UMUL but omit LDSTUB barriers by
using `gcc -mcpu=v8 -mmemory-model=sc', but the other way around doesn't work:
`gcc -mcpu=v7 -mmemory-model=tso' still omits the LDSTUB barriers, because the
code generation rules for barriers are all gated on TARGET_V8 || TARGET_V9.

What we would like to do for NetBSD/sparc is use `-mcpu=v7 -mmemory-model=tso'
-- that is, if it worked -- by default.  The original submitter drafted a
relatively small patch to achieve this, mostly by removing TARGET_V8 ||
TARGET_V9 conditionals or changing TARGET_V8 to !TARGET_V9 in membar-related
code generation rules.  But we'd also like to avoid diverging from gcc
upstream.  Could we convince you to take up an approach like this?

Applications built to run on v7-only, of course, could omit the LDSTUBs by
using `-mcpu=v7 -mmemory-model=sc' (or perhaps we could have the default be
`-mcpu=v7 -mmemory-model=sc', but have bare `-mcpu=v7' imply `-mcpu=v7
-mmemory-model=sc' or something), and applications built to run on v8-only can
still use `-mcpu=v8' to take advantage of `SMUL/UMUL'.

I expect this would only affect a tiny fraction of programs in extremely rare
scenarios -- those that actually rely on Dekker's algorithm (already rare), and
hit problems with memory ordering (also rare, only under high contention),
using in-line barriers or ordered memory operations (which wasn't the norm a
quarter century ago when v7 and v8 were relevant).  So you have to go out of
your way to hit problems in practice, and any negative performance impact of
the extra LDSTUBs on v7 CPUs that don't need them is likely negligible.  But
it's clear from code inspection and theory that the problem is there.

[Bug target/54089] [SH] Refactor shift patterns

[klepikov.alex+bugs at gmail dot com via Gcc-bugs]

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

--- Comment #100 from Alexander Klepikov  
---
Created attachment 55513
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55513&action=edit
Arithmetic right shift late expanding

(In reply to Oleg Endo from comment #99)
> Meanwhile, here's my iteration on your patch.

Thank you! I did all checks I did before, added testcases, and edited to fit
the code style.

[Bug target/110268] [14 Regression] arm MVE intrinsics support broken with LTO

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

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

commit r14-2418-geca10aaa3954af3dab56eccc208c90273c2b1732
Author: Christophe Lyon 
Date:   Mon Jun 26 14:39:47 2023 +

arm: Fix MVE intrinsics support with LTO (PR target/110268)

After the recent MVE intrinsics re-implementation, LTO stopped working
because the intrinsics would no longer be defined.

The main part of the patch is simple and similar to what we do for
AArch64:
- call handle_arm_mve_h() from arm_init_mve_builtins to declare the
  intrinsics when the compiler is in LTO mode
- actually implement arm_builtin_decl for MVE.

It was just a bit tricky to handle __ARM_MVE_PRESERVE_USER_NAMESPACE:
its value in the user code cannot be guessed at LTO time, so we always
have to assume that it was not defined.  The led to a few fixes in the
way we register MVE builtins as placeholders or not.  Without this
patch, we would just omit some versions of the inttrinsics when
__ARM_MVE_PRESERVE_USER_NAMESPACE is true. In fact, like for the C/C++
placeholders, we need to always keep entries for all of them to ensure
that we have a consistent numbering scheme.

2023-06-26  Christophe Lyon   

PR target/110268
gcc/
* config/arm/arm-builtins.cc (arm_init_mve_builtins): Handle LTO.
(arm_builtin_decl): Hahndle MVE builtins.
* config/arm/arm-mve-builtins.cc (builtin_decl): New function.
(add_unique_function): Fix handling of
__ARM_MVE_PRESERVE_USER_NAMESPACE.
(add_overloaded_function): Likewise.
* config/arm/arm-protos.h (builtin_decl): New declaration.

gcc/testsuite/
* gcc.target/arm/pr110268-1.c: New test.
* gcc.target/arm/pr110268-2.c: New test.

[Bug target/110268] [14 Regression] arm MVE intrinsics support broken with LTO

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

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #7 from Christophe Lyon  ---
Fixed.

[Bug c/110205] Some new warnings from clang for the range code

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
Nearly a month later, the current list of clang warnings for the range code is:

../../trunk.year/gcc/gimple-range-cache.h:140:17: warning: private field
'm_estimate' is not used [-Wunused-private-field]
../../trunk.year/gcc/range-op-mixed.h:567:8: warning: 'op1_op2_relation_effect'
overrides a member function but is not marked 'override'
[-Winconsistent-missing-override]
../../trunk.year/gcc/range-op.cc:2254:8: warning: 'update_bitmask' overrides a
member function but is not marked 'override' [-Winconsistent-missing-override]
../../trunk.year/gcc/range-op.cc:2392:16: warning: 'op1_range' overrides a
member function but is not marked 'override' [-Winconsistent-missing-override]
../../trunk.year/gcc/range-op.cc:2396:16: warning: 'fold_range' overrides a
member function but is not marked 'override' [-Winconsistent-missing-override]
../../trunk.year/gcc/range-op.cc:2401:16: warning: 'wi_fold' overrides a member
function but is not marked 'override' [-Winconsistent-missing-override]
../../trunk.year/gcc/range-op.cc:2404:16: warning: 'wi_op_overflows' overrides
a member function but is not marked 'override'
[-Winconsistent-missing-override]
../../trunk.year/gcc/range-op.cc:2419:16: warning: 'fold_range' overrides a
member function but is not marked 'override' [-Winconsistent-missing-override]
../../trunk.year/gcc/range-op.cc:2423:16: warning: 'wi_fold' overrides a member
function but is not marked 'override' [-Winconsistent-missing-override]
../../trunk.year/gcc/range-op.cc:2428:16: warning: 'wi_op_overflows' overrides
a member function but is not marked 'override'
[-Winconsistent-missing-override]
../../trunk.year/gcc/range-op.cc:2432:16: warning: 'op1_range' overrides a
member function but is not marked 'override' [-Winconsistent-missing-override]
../../trunk.year/gcc/range-op.cc:2436:25: warning: 'lhs_op1_relation' overrides
a member function but is not marked 'override'
[-Winconsistent-missing-override]

These might be worth fixing.

[Bug c/110612] New: text-art: four clang warnings

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 110612
   Summary: text-art: four clang warnings
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For the text-art directory, here is the list of warnings produced
by a build of gcc trunk by clang:

../../trunk.year/gcc/text-art/table.cc:561:15: warning: comparison of integers
of different signs: 'int' and 'size_type' (aka 'unsigned long')
[-Wsign-compare]
../../trunk.year/gcc/text-art/table.cc:573:15: warning: comparison of integers
of different signs: 'int' and 'size_type' (aka 'unsigned long')
[-Wsign-compare]
../../trunk.year/gcc/text-art/table.h:235:16: warning: private field 'm_table'
is not used [-Wunused-private-field]
../../trunk.year/gcc/text-art/widget.h:151:8: warning:
'update_child_alloc_rects' overrides a member function but is not marked
'override' [-Winconsistent-missing-override]

These might be worth fixing.

[Bug c++/110523] [14 Regression] ICE in redeclare_class_template, at cp/pt.cc:6391 on json-3.11.2

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #9 from Patrick Palka  ---
Simplified:

template class>
class basic_json;

template struct json_pointer {
  template class> friend class basic_json;
};

template struct json_pointer;
template struct json_pointer;
template struct json_pointer;

[Bug target/106966] [12/13/14 Regression] alpha cross build crashes gcc-12 "internal compiler error: in emit_move_insn"

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

--- Comment #11 from matoro  ---
(In reply to Uroš Bizjak from comment #10)
> (In reply to matoro from comment #9)
> > (In reply to Uroš Bizjak from comment #8)
> > > Created attachment 55504 [details]
> > > Proposed patch.
> > > 
> > > Can someone please bootstrap and test the attached patch?
> > 
> > I can queue this up to test on real hardware.  By bootstrap, do you mean
> > with --enable-bootstrap, and by test do you mean a full testsuite run or
> > just checking that it doesn't ICE on the reproducer here?
> 
> I have already checked that it doesn't ICE with a crosscompiler. Regarding
> the bootstrap, please note that --enable-bootstrap is the default nowadays,
> so the option it is not needed to make a full build ("bootstrap"). Also,
> "make -j N -k check-gcc" should be enough to test the compiler, since other
> parts of the compiler never exercise -mbuild-constants (N in the command
> should be substituted with a number of processors to parallelize the
> testsuite run).

I was just checking because alpha hardware is quite antique, it's single-core
so a full compile with bootstrap takes around ~72 hours.  I don't know how long
the test suite takes because I've never run it on this machine, but I would
expect it to add a couple additional days to that.  If that's fine I'll kick it
off, just want to be clear on what exactly you'd like to see.

[Bug libstdc++/110504] std::format("{:%S}", duration>(4)) returns "02.0" instead of "02"

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Jonathan Wakely  ---
The current code in libstdc++ is correct here.

[Bug libstdc++/104167] Implement C++20 std::chrono::utc_clock, std::chrono::tzdb etc.

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

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

Bug 110504 Summary: std::format("{:%S}", duration>(4)) 
returns "02.0" instead of "02"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110504

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

[Bug libstdc++/110354] [C++26] P2587R3 to_string or not to_string

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

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

Bug 110355 Summary: std::format("{}", 1e-7) returns "1e-07" instead of "1e-7"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110355

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

[Bug libstdc++/110355] std::format("{}", 1e-7) returns "1e-07" instead of "1e-7"

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Jonathan Wakely  ---
Libstdc++ is correct, the example in https://wg21.link/p2587r3 is wrong.

[Bug tree-optimization/110613] New: optimization about combined store of adjacent bitfields

[lh_mouse at 126 dot com via Gcc-bugs]

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

Bug ID: 110613
   Summary: optimization about combined store of adjacent
bitfields
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

This is a piece of code taken from a WebSocket frame parser:
```
#include 

struct Header 
  {
// 1st byte
uint8_t opcode : 4;
uint8_t rsv3 : 1;
uint8_t rsv2 : 1;
uint8_t rsv1 : 1;
uint8_t fin : 1;

// 2nd byte
uint8_t reserved_1 : 7;
uint8_t mask : 1;

// 3rd and 4th bytes
uint8_t reserved_2;
uint8_t reserved_3;

// 5th to 7th bytes
union {
  char mask_key[4];
  uint32_t mask_key_u32;
};

// 8th to 15th bytes
uint64_t payload_len;
  };

void
set_header(Header* ph, const uint8_t* bptr)
  {
uint8_t f = bptr[0];
uint8_t t = bptr[1];

ph->fin = f >> 7;
ph->rsv1 = f >> 6;
ph->rsv2 = f >> 5;
ph->rsv3 = f >> 4;
ph->opcode = f;

ph->mask = t >> 7;
ph->reserved_1 = t;
  }
```

The structure is designed to match x86_64 ABI (little endian), so
```
ph->fin = f >> 7;
ph->rsv1 = f >> 6;
ph->rsv2 = f >> 5;
ph->rsv3 = f >> 4;
ph->opcode = f;
```
should be a simple move (https://gcc.godbolt.org/z/9vTqs7axj), and
```
ph->mask = t >> 7;
ph->reserved_1 = t;
```
should also be a simple move (https://gcc.godbolt.org/z/KdchWvEn1), but!

When put these two pieces of code together, guess what?:
(godbolt: https://gcc.godbolt.org/z/hbEaeb3MT)
```
set_header(Header*, unsigned char const*):
movzx   edx, BYTE PTR [rsi]
movzx   ecx, BYTE PTR [rsi+1]
mov eax, edx
mov esi, edx
shr al, 4
and esi, 15
and eax, 1
sal eax, 4
or  eax, esi
mov esi, edx
shr sil, 5
and esi, 1
sal esi, 5
or  eax, esi
mov esi, edx
shr dl, 7
shr sil, 6
movzx   edx, dl
and esi, 1
sal edx, 7
sal esi, 6
or  eax, esi
or  eax, edx
mov edx, ecx
shr cl, 7
and edx, 127
sal ecx, 15
sal edx, 8
or  eax, edx
or  eax, ecx
mov WORD PTR [rdi], ax
ret
```

[Bug c++/110523] [14 Regression] ICE in redeclare_class_template, at cp/pt.cc:6391 on json-3.11.2

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:2c60368ab5706a870a1a3be190acc4d673672c30

commit r14-2421-g2c60368ab5706a870a1a3be190acc4d673672c30
Author: Patrick Palka 
Date:   Mon Jul 10 10:59:40 2023 -0400

c++: redeclare_class_template and ttps [PR110523]

Now that we cache level-lowered ttps we can end up processing the same
ttp multiple times via (multiple calls to) redeclare_class_template, so
we can't assume a ttp's DECL_CONTEXT is initially empty.

PR c++/110523

gcc/cp/ChangeLog:

* pt.cc (redeclare_class_template): Relax the ttp DECL_CONTEXT
assert, and downgrade it to a checking assert.

gcc/testsuite/ChangeLog:

* g++.dg/template/ttp37.C: New test.

[Bug target/106966] [12/13/14 Regression] alpha cross build crashes gcc-12 "internal compiler error: in emit_move_insn"

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

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

--- Comment #12 from Matthias Klose  ---
I'll apply the proposed patch for the next gcc-13 Debian upload, then reporting
back test results.

[Bug c++/110523] [14 Regression] ICE in redeclare_class_template, at cp/pt.cc:6391 on json-3.11.2

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #11 from Patrick Palka  ---
Fixed.

[Bug tree-optimization/110614] New: [14 Regression] ICE in vect_supportable_dr_alignment

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

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

Bug ID: 110614
   Summary: [14 Regression] ICE in vect_supportable_dr_alignment
   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: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc*-*-*

Beginning with

commit dd86a5a69cbda40cf76388a65d3317c91cb2b501
Author: Richard Biener 
Date:   Thu Jun 22 11:40:46 2023 +0200

A number of GCC testsuite test cases ICE in vect_supportable_dr_alignment()

gcc/testsuite/gcc.dg/torture/pr68379.c

$ ./xgcc -B./ -S -O2 -mcpu=power7 pr68379.c 
during GIMPLE pass: vect
pr68379.c: In function ‘fn1’:
pr68379.c:6:1: internal compiler error: Segmentation fault
6 | fn1 ()
  | ^~~
0x10c1d833 crash_signal
/home/dje/src/gcc/gcc/toplev.cc:314
0x11b4ebd0 vect_supportable_dr_alignment(vec_info*, dr_vec_info*, tree_node*,
int)
/home/dje/src/gcc/gcc/tree-vect-data-refs.cc:6833
0x11b53717 vect_enhance_data_refs_alignment(_loop_vec_info*)
/home/dje/src/gcc/gcc/tree-vect-data-refs.cc:2044
0x10fc35bb vect_analyze_loop_2
/home/dje/src/gcc/gcc/tree-vect-loop.cc:2783
0x10fc4d8f vect_analyze_loop_1
/home/dje/src/gcc/gcc/tree-vect-loop.cc:3316
0x10fc56bb vect_analyze_loop(loop*, vec_info_shared*)
/home/dje/src/gcc/gcc/tree-vect-loop.cc:3470
0x110174e7 try_vectorize_loop_1
/home/dje/src/gcc/gcc/tree-vectorizer.cc:1064
0x110174e7 try_vectorize_loop
/home/dje/src/gcc/gcc/tree-vectorizer.cc:1180
0x11017fa3 execute
/home/dje/src/gcc/gcc/tree-vectorizer.cc:1296

The test cases succeed with Power8, Power9, or Power10, but ICE with
-mcpu=power7. command line option.

[Bug tree-optimization/110614] [14 Regression] ICE in vect_supportable_dr_alignment

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

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-07-10
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug libstdc++/110615] New: std::abs converts integers to floats and back

[julien.jorge--- via Gcc-bugs]

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

Bug ID: 110615
   Summary: std::abs converts integers to floats and back
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: julien.jo...@stuff-o-matic.com
  Target Milestone: ---

The implementation of std::abs in current HEAD
(a3ad2301d2f4aab2deeb286fa5bd0282260bfd0a) is as follows (in
libstdc++-v3/include/c_std/cmath):

template
inline typename __gnu_cxx::__enable_if<__is_integer<_Tp>::__value, 
   double>::__type
abs(_Tp __x)
{ return __builtin_fabs(__x); }

The function is only used when _Tp is an integer (due to the __enable_if part),
yet it calls __builtin_fabs where, I believe, __builtin_llabs should have been
used. Unless the intent was to negate the condition in __enable_if?

I observed a lot of int <-> float conversions in the assembly of my program on
an older version of GCC with this implementation, unless I included cstdlib
which defines abs(long long) and co. The int <-> float conversions do not
happen with current HEAD but I believe it is due to a side effect of cmath
transitively including stdlib.h.

I first observed this with GCC 4.8.5. Compiler explorer shows int <-> float
conversions when cstdlib is missing with GCC up to 6.4:
https://godbolt.org/z/bWfEv1jxP

[Bug c/110609] Bogus -Wmismatched-dealloc when allocator defined & used in same TU w/ -fPIC -fno-semantic-interposition

[andres at anarazel dot de via Gcc-bugs]

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

--- Comment #2 from Andres Freund  ---
(In reply to Andrew Pinski from comment #1)
> Dup.
> 
> *** This bug has been marked as a duplicate of bug 110546 ***

Are they really the same? This bug happens at -O0 and requires -fPIC and
-fno-semantic-interposition, whereas #110546 requires -O3? I don't know enough
about gcc, so you probably are right...

[Bug libstdc++/95048] [11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

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

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

--- Comment #26 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

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

commit r11-10903-gd308b11fa94728507984b4ccc949219511273ab6
Author: Jonathan Wakely 
Date:   Fri Nov 11 15:22:02 2022 +

libstdc++: Fix wstring conversions in filesystem::path [PR95048]

In commit r9-7381-g91756c4abc1757 I changed filesystem::path to use
std::codecvt for conversions from all wide
strings to UTF-8, instead of using std::codecvt_utf8. This was
done because for 16-bit wchar_t, std::codecvt_utf8 only
supports UCS-2 and not UTF-16. The rationale for the change was sound,
but the actual fix was not. It's OK to use std::codecvt for char16_t or
char32_t, because the specializations for those types always use UTF-8 ,
but std::codecvt uses the current locale's
encodings, and the narrow encoding is probably ASCII and can't support
non-ASCII characters.

The correct fix is to use std::codecvt only for char16_t and char32_t.
For 32-bit wchar_t we could have continued using std::codecvt_utf8
because that uses UTF-32 which is fine, switching to std::codecvt broke
non-Windows targets with 32-bit wchar_t. For 16-bit wchar_t we did need
to change, but should have changed to std::codecvt_utf8_utf16
instead, as that always uses UTF-16 not UCS-2. I actually noted that in
the commit message for r9-7381-g91756c4abc1757 but didn't use that
option. Oops.

This replaces the unconditional std::codecvt
with a type defined via template specialization, so it can vary
depending on the wide character type. The code is also simplified to
remove some of the mess of #ifdef and if-constexpr conditions.

libstdc++-v3/ChangeLog:

PR libstdc++/95048
* include/bits/fs_path.h (path::_Codecvt): New class template
that selects the kind of code conversion done.
(path::_Codecvt): Select based on sizeof(wchar_t).
(_GLIBCXX_CONV_FROM_UTF8): New macro to allow the same code to
be used for Windows and POSIX.
(path::_S_convert(const EcharT*, const EcharT*)): Simplify by
using _Codecvt and _GLIBCXX_CONV_FROM_UTF8 abstractions.
(path::_S_str_convert(basic_string_view, const A&)):
Simplify nested conditions.
* include/experimental/bits/fs_path.h (path::_Cvt): Define
nested typedef controlling type of code conversion done.
(path::_Cvt::_S_wconvert): Use new typedef.
(path::string(const A&)): Likewise.
* testsuite/27_io/filesystem/path/construct/95048.cc: New test.
* testsuite/experimental/filesystem/path/construct/95048.cc: New
test.

(cherry picked from commit b331bf303bdc1edead41e2b3d11d1a7804b433cf)

[Bug libstdc++/110615] std::abs converts integers to floats and back

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED
Version|unknown |6.5.0

--- Comment #1 from Jonathan Wakely  ---
This is the expected behaviour for those old releases (which are no longer
supported or maintained, and so there's no point reporting bugs in them).

Prior to the resolutions of https://wg21.link/lwg2192 and
https://wg21.link/lwg2294 the integer overloads of std::abs were only declared
in , so if you only include  then you only get the
floating-point overloads.

GCC 7.0 implements the resolutions to those issues, in r7-3447-g37b204de605563

[Bug fortran/102003] [PDT] Length of character component not simplified

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

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

Andre Vehreschild  changed:

   What|Removed |Added

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

--- Comment #3 from Andre Vehreschild  ---
Created attachment 55514
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55514&action=edit
First shot.

[Bug libstdc++/110615] std::abs converts integers to floats and back

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Julien Jorge from comment #0)
> The int <-> float conversions
> do not happen with current HEAD but I believe it is due to a side effect of
> cmath transitively including stdlib.h.

No, it's due to the resolution of LWG 2192.

There is no transitive include of  in , instead both 
and  include  which defines all overloads for integers
and floating-point types.

This is by design, not a side effect.

[Bug tree-optimization/110616] New: [14 regression] ICE after r14-2117-gdd86a5a69cbda4

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

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

Bug ID: 110616
   Summary: [14 regression] ICE after r14-2117-gdd86a5a69cbda4
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:dd86a5a69cbda40cf76388a65d3317c91cb2b501, r14-2117-gdd86a5a69cbda4

commit dd86a5a69cbda40cf76388a65d3317c91cb2b501
Author: Richard Biener 
Date:   Thu Jun 22 11:40:46 2023 +0200

tree-optimization/96208 - SLP of non-grouped loads

The ICE only occurs with -mcpu=power7.  This is cut down from a much larger
test thus the warnings.

Note that this still fails with r14-2421-g2c60368ab5706a 


$ /home/seurer/gcc/git/install/gcc-test/bin/gcc -c -o do_fit.o -DSPEC_CPU
-DNDEBUG  -I. -DHAVE_CONFIG_H -m64 -O2 -mcpu=power7 failsX.c

failsX.c: In function 'calc_similar_ind':
failsX.c:32:14: warning: implicit declaration of function 'sqrt'
[-Wimplicit-function-declaration]
   32 | return 2*sqrt(rd/rs);
  |  ^~~~
failsX.c:1:1: note: include '' or provide a declaration of 'sqrt'
  +++ |+#include 
1 | typedef int atom_id;
failsX.c:32:14: warning: incompatible implicit declaration of built-in function
'sqrt' [-Wbuiltin-declaration-mismatch]
   32 | return 2*sqrt(rd/rs);
  |  ^~~~
failsX.c:32:14: note: include '' or provide a declaration of 'sqrt'
during GIMPLE pass: vect
failsX.c:12:6: internal compiler error: Segmentation fault
   12 | real calc_similar_ind(int bRho,int nind,atom_id *index,real mass[],
  |  ^~~~
0x10cc57eb crash_signal
/home/seurer/gcc/git/gcc-test/gcc/toplev.cc:314
0x11d56c7c vect_supportable_dr_alignment(vec_info*, dr_vec_info*, tree_node*,
int)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-data-refs.cc:6817
0x11d5ec8f vect_enhance_data_refs_alignment(_loop_vec_info*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-data-refs.cc:2044
0x1107d363 vect_analyze_loop_2
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.cc:2772
0x1107ec9b vect_analyze_loop_1
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.cc:3303
0x1107f5f3 vect_analyze_loop(loop*, vec_info_shared*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.cc:3457
0x110d4607 try_vectorize_loop_1
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1064
0x110d4607 try_vectorize_loop
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1180
0x110d4e43 execute
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1296
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.


$ /home/seurer/gcc/git/install/gcc-test/bin/gcc -c -o do_fit.o -DSPEC_CPU
-DNDEBUG  -I. -DHAVE_CONFIG_H -m64 -O2 -mcpu=power8 failsX.c
failsX.c: In function 'calc_similar_ind':
failsX.c:32:14: warning: implicit declaration of function 'sqrt'
[-Wimplicit-function-declaration]
   32 | return 2*sqrt(rd/rs);
  |  ^~~~
failsX.c:1:1: note: include '' or provide a declaration of 'sqrt'
  +++ |+#include 
1 | typedef int atom_id;
failsX.c:32:14: warning: incompatible implicit declaration of built-in function
'sqrt' [-Wbuiltin-declaration-mismatch]
   32 | return 2*sqrt(rd/rs);
  |  ^~~~
failsX.c:32:14: note: include '' or provide a declaration of 'sqrt'


$ cat failsX.c
typedef int atom_id;

typedef float real;

typedef real rvec[3];

static real sqr(real x)
{
  return (x*x);
}

real calc_similar_ind(int bRho,int nind,atom_id *index,real mass[],
rvec x[],rvec xp[])
{
  int i, j, d;
  real m, tm, xs, xd, rs, rd;

  tm=0;
  rs=0;
  rd=0;
  for(j=0; j

[Bug fortran/106050] ICE in reject_statement, at fortran/parse.cc:2879 since r8-3056-g5bab4c9631c478b7

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

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

--- Comment #3 from Paul Thomas  ---
(In reply to Martin Liška from comment #2)
> Likely started with r8-3056-g5bab4c9631c478b7, it was rejected before the
> revision anyway.

With all branches up to 13-branch, I see:
../pr105594/pr106050.f90:3:12:

3 |type t(k)
  |1
Error: Unexpected derived type declaration statement at (1)
(null):0: confused by earlier errors, bailing out

With trunk, I get:
../pr105594/pr106050.f90:3:12:

3 |type t(k)
  |1
Error: Unexpected derived type declaration statement at (1)
f951: internal compiler error: Segmentation fault
0x101683f crash_signal
../../gcc/gcc/toplev.cc:314
0x9228ca delete_root
../../gcc/gcc/fortran/bbt.cc:150
0x922a8e gfc_delete_bbt(void*, void*, int (*)(void*, void*))
../../gcc/gcc/fortran/bbt.cc:197
0xa0923c gfc_delete_symtree(gfc_symtree**, char
..

I will be attaching a patch that works for me.

Paul

[Bug fortran/106050] ICE in reject_statement, at fortran/parse.cc:2879 since r8-3056-g5bab4c9631c478b7

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

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

--- Comment #4 from Paul Thomas  ---
Created attachment 55515
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55515&action=edit
Patch that fixes this PR for me

I had to add to Steve's patch to get this PR sorted out.

Ideally of course, we would locate the culprit in the PDT instantiation and fix
that. However, I am disinclined to do that since PDTs require roots and
branches fixing. At least this patch is mostly harmless!

Paul

[Bug libstdc++/110615] std::abs converts integers to floats and back

[julien.jorge--- via Gcc-bugs]

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

--- Comment #3 from Julien Jorge  ---
> This is the expected behaviour for those old releases (which are no longer 
> supported or maintained, and so there's no point reporting bugs in them).

Well, it was more an attempt to raise awareness on a behaviour I assumed to be
accidental in recent releases rather than an actual bug report for old releases
:) 

Anyway it is clear that I was mistaken! Thank you for the feedback and the
links :)

[Bug other/110205] Some new warnings from clang for the range code

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

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

Xi Ruoyao  changed:

   What|Removed |Added

  Component|c   |other
 CC||xry111 at gcc dot gnu.org

--- Comment #4 from Xi Ruoyao  ---
We need a general decision.  If we think these warning must fixed, we'd better
enable the equivalent GCC warnings for bootstrapping too.

[Bug c++/110523] [14 Regression] ICE in redeclare_class_template, at cp/pt.cc:6391 on json-3.11.2

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

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

--- Comment #12 from Sergei Trofimovich  ---
I confirm ICE gone away for json-3.11.2. json-3.11.2 still odes not compile
same as in https://gcc.gnu.org/PR110580

[Bug fortran/106050] ICE in reject_statement, at fortran/parse.cc:2879 since r8-3056-g5bab4c9631c478b7

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #5 from Mikael Morin  ---
When matching statement "type t(k)", two symbols are created, one for t and one
for k.
t is in gfc_current_ns and k is in t's f2k_derived namespace.
If the statement is rejected, both t and k need to be freed.
But one should care about ordering, as the release of t frees f2k_derived,
which is k's namespace, so k should be released before t.

I haven't checked that the above actually is the problem here, but it might be.
Possibly walking the symbols in reverse order to release them would fix this.

Regarding the patches posted, if sym->refs < 0 is true, then the memory for sym
has already been released and may be garbage (including sym->refs).  A crash is
as good as anything else at this point IMHO.

[Bug c++/110580] [14 Regression] gcc fails to typecheck nix-2.16.1 source: error: invalid initialization of reference of type

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Keywords|needs-bisection |

--- Comment #7 from Patrick Palka  ---
Started with r14-2170-g4cf64d9cc2faf4.

(In reply to Andrew Pinski from comment #5)
> I get the feeling _Up in the default template argument of __usable_key  is
> being replaced with _Key template argument for some reason.

Interesting bug.. Thanks for the nice reduction.

[Bug middle-end/110617] New: RFE: Add a diagnostic-only variant of nonnull attribute

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

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

Bug ID: 110617
   Summary: RFE: Add a diagnostic-only variant of nonnull
attribute
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

Currently nonnull serves as both a diagnostic attribute and an optimization
attribute.  But sometimes we want only the effect for diagnostic, but not the
effect for code generation.

For example, Glibc developers implements many functions as "crash the program
immediately if an unexpected NULL pointer is passed" [1].  So it would be
useful to make the potential crash detectable via -Wnonnull and/or
-Wanalyzer-null-argument.  However they don't like the nonnull attribute on the
function prototype, because the nonnull attribute may cause the optimizer to
break their "immediately crash" design [2].

I'm not sure how to name this variant of nonnull precisely. (Maybe "hate_null
or something?)

[Bug fortran/110618] New: Dependency between arguments when one is allocatable array whose dummy is intent(out)

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

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

Bug ID: 110618
   Summary: Dependency between arguments when one is allocatable
array whose dummy is intent(out)
   Product: gcc
   Version: 11.4.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikael at gcc dot gnu.org
CC: abensonca at gcc dot gnu.org, anlauf at gcc dot gnu.org,
burnus at gcc dot gnu.org, kargl at gcc dot gnu.org,
vladimir.fuka at gmail dot com
Depends on: 92178
Blocks: 87142
  Target Milestone: ---

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

PR 92178 has several cases of dependency between arguments when one of them is
deallocated before the call in the process of argument association.

Here is another example which I don't want to handle there (and which I don't
know how to fix).

program p
  implicit none
  type t
integer :: i
  end type t
  type u
class(t), allocatable :: ta(:)
  end type u
  type(u), allocatable :: c(:)
  class(t), allocatable :: d(:)
  allocate(c, source = [u([t(1), t(3)]), u([t(4), t(9)])])
  allocate(d, source = [t(1), t(5)])
  call bar (   &
  allocated(c(d(1)%i)%ta), &
  d,   &
  c(d(1)%i)%ta,&
  allocated (c(d(1)%i)%ta) &
  )
  if (allocated (c(1)%ta)) stop 11
  if (.not. allocated (c(2)%ta)) stop 12
contains
  subroutine bar (alloc, x, y, alloc2)
logical :: alloc, alloc2
class(t), allocatable, intent(out) :: x(:)
class(t), allocatable, intent(out) :: y(:)
if (allocated (x)) stop 1
if (.not. alloc)   stop 2
if (.not. alloc2)  stop 3
  end subroutine bar
end


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87142
[Bug 87142] Aliasing issue with overloaded assignment and allocatable
components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
[Bug 92178] Segmentation fault after passing allocatable array as intent(out)
and its element as value into the same subroutine

[Bug middle-end/110617] RFE: Add a diagnostic-only variant of nonnull attribute

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

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

--- Comment #1 from Xi Ruoyao  ---
[1]:
https://sourceware.org/glibc/wiki/Style_and_Conventions#Bugs_in_the_user_program
[2]: https://sourceware.org/pipermail/libc-alpha/2023-July/149893.html

[Bug tree-optimization/110614] [14 Regression] ICE in vect_supportable_dr_alignment

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

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

--- Comment #2 from seurer at gcc dot gnu.org ---
This may be a dupe of PR110616 (or vice-versa).

[Bug middle-end/110617] RFE: Add a diagnostic-only variant of nonnull attribute

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #2 from Andrew Pinski  ---
>But sometimes we want only the effect for diagnostic,

I think that is a bad idea.

[Bug c++/110619] New: Dangling pointer returned from constexpr function converts in nullptr

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 110619
   Summary: Dangling pointer returned from constexpr function
converts in nullptr
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

The following function

constexpr auto f() {
int i = 0;
return &i;
};

returns dangling pointer on stack variable, but it is not nullptr. So next
assertion passes in Clang and MSVC:

static_assert( f() != nullptr );


But in GCC the assertion fails. Online demo:
https://gcc.godbolt.org/z/6E4rE963n

[Bug c++/110619] Dangling pointer returned from constexpr function converts in nullptr

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
I would have expected this to be undefined ...
So the static_assert could work or not.

[Bug c++/110619] Dangling pointer returned from constexpr function converts in nullptr

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

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

--- Comment #2 from Andrew Pinski  ---
>but it is not nullptr.

Or is it just undefined so it could be considered a nullptr ...

[Bug c++/110619] Dangling pointer returned from constexpr function converts in nullptr

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Fedor Chelnokov  ---
I think according to https://eel.is/c++draft/basic.stc#general-4 the function
shall return an "invalid pointer valued". And nullptr is not considered such.

And if one modifies the function slightly (see auto p appear):

constexpr auto g() {
int i = 0;
auto p = &i;
return p;
};

Then static_assert passes: https://gcc.godbolt.org/z/5shcxfcxG

[Bug c++/110620] New: spurious array-bounds

[cuzdav at gmail dot com via Gcc-bugs]

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

Bug ID: 110620
   Summary: spurious array-bounds
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

[Bug tree-optimization/110620] spurious array-bounds

[cuzdav at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Chris Uzdavinis  ---
Starting with Gcc12.1 (at least on x86) and through all versions up to the
trunk (post 13.1)
This warning hits with optimization -O2 or higher.

https://godbolt.org/z/q3T39Wf8c


#include 

void foo(std::vector>& vec) {
if (vec.size() > 5) {
vec[3].first = 0;
}
}

int main() {
auto v1 = std::vector{std::pair(1, 2)};
foo(v1);
}

What is interesting to me is that the analyzer is missing the fact that size is
explicitly tested, and the index is a constant expression that is lower.

There are a lot of array-bounds bugs reported, and all have similarities and
I'm not sure if this is a dupe or not, though I went through the open ones in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
And did not see an example quite like this.


In function 'void foo(std::vector >&)',
inlined from 'int main()' at :11:8:
:5:22: error: array subscript 3 is outside array bounds of
'std::pair [1]' [-Werror=array-bounds=]
5 | vec[3].first = 0;
In file included from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/x86_64-linux-gnu/bits/c++allocator.h:33,
 from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/allocator.h:46,
 from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/vector:63,
 from :1:
In member function '_Tp* std::__new_allocator<_Tp>::allocate(size_type, const
void*) [with _Tp = std::pair]',
inlined from 'constexpr _Tp* std::allocator< 
>::allocate(std::size_t) [with _Tp = std::pair]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/allocator.h:198:40,
inlined from 'static constexpr _Tp*
std::allocator_traits >::allocate(allocator_type&,
size_type) [with _Tp = std::pair]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/alloc_traits.h:482:28,
inlined from 'constexpr std::_Vector_base<_Tp, _Alloc>::pointer
std::_Vector_base<_Tp, _Alloc>::_M_allocate(std::size_t) [with _Tp =
std::pair; _Alloc = std::allocator >]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_vector.h:378:33,
inlined from 'constexpr void std::vector<_Tp,
_Alloc>::_M_range_initialize(_ForwardIterator, _ForwardIterator,
std::forward_iterator_tag) [with _ForwardIterator = const std::pair*;
_Tp = std::pair; _Alloc = std::allocator >]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_vector.h:1687:25,
inlined from 'constexpr std::vector<_Tp,
_Alloc>::vector(std::initializer_list<_Tp>, const allocator_type&) [with _Tp =
std::pair; _Alloc = std::allocator >]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_vector.h:677:21,
inlined from 'int main()' at :10:42:
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/new_allocator.h:147:55:
note: at offset 24 into object of size 8 allocated by 'operator new'
  147 | return static_cast<_Tp*>(_GLIBCXX_OPERATOR_NEW(__n *
sizeof(_Tp)));
  |   ^
cc1plus: all warnings being treated as errors
Compiler returned: 1

[Bug tree-optimization/110620] spurious array-bounds

[cuzdav at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Chris Uzdavinis  ---
Created attachment 55516
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55516&action=edit
preprocessed code

[Bug tree-optimization/110620] spurious array-bounds

[cuzdav at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Chris Uzdavinis  ---
Starting with Gcc12.1 (at least on x86) and through all versions up to the
trunk (post 13.1)
This warning hits with optimization -O2 or higher.

https://godbolt.org/z/q3T39Wf8c


#include 

void foo(std::vector>& vec) {
if (vec.size() > 5) {
vec[3].first = 0;
}
}

int main() {
auto v1 = std::vector{std::pair(1, 2)};
foo(v1);
}

What is interesting to me is that the analyzer is missing the fact that size is
explicitly tested, and the index is a constant expression that is lower.

There are a lot of array-bounds bugs reported, and all have similarities and
I'm not sure if this is a dupe or not, though I went through the open ones in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
And did not see an example quite like this.


In function 'void foo(std::vector >&)',
inlined from 'int main()' at :11:8:
:5:22: error: array subscript 3 is outside array bounds of
'std::pair [1]' [-Werror=array-bounds=]
5 | vec[3].first = 0;
In file included from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/x86_64-linux-gnu/bits/c++allocator.h:33,
 from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/allocator.h:46,
 from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/vector:63,
 from :1:
In member function '_Tp* std::__new_allocator<_Tp>::allocate(size_type, const
void*) [with _Tp = std::pair]',
inlined from 'constexpr _Tp* std::allocator< 
>::allocate(std::size_t) [with _Tp = std::pair]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/allocator.h:198:40,
inlined from 'static constexpr _Tp*
std::allocator_traits >::allocate(allocator_type&,
size_type) [with _Tp = std::pair]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/alloc_traits.h:482:28,
inlined from 'constexpr std::_Vector_base<_Tp, _Alloc>::pointer
std::_Vector_base<_Tp, _Alloc>::_M_allocate(std::size_t) [with _Tp =
std::pair; _Alloc = std::allocator >]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_vector.h:378:33,
inlined from 'constexpr void std::vector<_Tp,
_Alloc>::_M_range_initialize(_ForwardIterator, _ForwardIterator,
std::forward_iterator_tag) [with _ForwardIterator = const std::pair*;
_Tp = std::pair; _Alloc = std::allocator >]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_vector.h:1687:25,
inlined from 'constexpr std::vector<_Tp,
_Alloc>::vector(std::initializer_list<_Tp>, const allocator_type&) [with _Tp =
std::pair; _Alloc = std::allocator >]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_vector.h:677:21,
inlined from 'int main()' at :10:42:
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/new_allocator.h:147:55:
note: at offset 24 into object of size 8 allocated by 'operator new'
  147 | return static_cast<_Tp*>(_GLIBCXX_OPERATOR_NEW(__n *
sizeof(_Tp)));
  |   ^
cc1plus: all warnings being treated as errors
Compiler returned: 1

[Bug tree-optimization/110620] spurious array-bounds

[cuzdav at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Chris Uzdavinis  ---
(Sorry I was getting bugzilla errors about collisions when adding comments, but
they seemed to have gone through after all.)

[Bug tree-optimization/110620] spurious array-bounds

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

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

--- Comment #5 from Andrew Pinski  ---
>From the looks of it is just not optimizing enough before the warning happens.

The final optimized code does not have the store in it.

The store for the vector to create the size of one element vector happens and
then a copy loop happens and then loads from start/finish to figure out the
size of the vector but that is not optimized until dom2 which is after vrp2
already ran ...

[Bug target/110621] New: x86_64: Test gcc.target/i386/pr105354-2.c fails with -fstack-protector

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

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

Bug ID: 110621
   Summary: x86_64: Test gcc.target/i386/pr105354-2.c fails with
-fstack-protector
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

...but not -fstack-protector-strong:

$ make check-gcc
RUNTESTFLAGS='--target_board=unix\{-fstack-protector-strong,-fstack-protector\}
i386.exp=pr105354-2.c'

=== gcc Summary for unix/-fstack-protector-strong ===

# of expected passes2


FAIL: gcc.target/i386/pr105354-2.c execution test

=== gcc Summary for unix/-fstack-protector ===

# of expected passes1
# of unexpected failures1

=== gcc Summary ===

# of expected passes3
# of unexpected failures1

[Bug rtl-optimization/104843] signed overflow in compute_const_anchors, at cse.cc:1180

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=108193

--- Comment #2 from Xi Ruoyao  ---
Fixed at r13-4844.

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

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

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

Bug 104843 Summary: signed overflow in compute_const_anchors, at cse.cc:1180
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104843

   What|Removed |Added

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

[Bug fortran/110288] [11/12/13/14] Regression: segfault in findloc with allocatable array of allocatable characters

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
The apparent discrepancy between fndecl and the actual arguments in the call
may be a result from the following block in gfc_conv_procedure_call after:

7390  /* Deferred length dummies pass the character length by reference
7391 so that the value can be returned.  */
7392  if (parmse.string_length && fsym && fsym->ts.deferred)
...

The following patch fixes the testcase and regtests ok so far:

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 7017b652d6e..8ed812bff0d 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -7404,7 +7404,10 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
  tmp = parmse.string_length;
  if (!VAR_P (tmp) && TREE_CODE (tmp) != COMPONENT_REF)
tmp = gfc_evaluate_now (parmse.string_length, &se->pre);
- parmse.string_length = gfc_build_addr_expr (NULL_TREE, tmp);
+ if (fsym->attr.allocatable || fsym->attr.pointer)
+   parmse.string_length = gfc_build_addr_expr (NULL_TREE, tmp);
+ else
+   parmse.string_length = tmp;
}

  if (e && e->expr_type == EXPR_VARIABLE

Needs more checking.

[Bug fortran/110618] Dependency between arguments when one is allocatable array whose dummy is intent(out)

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

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

--- Comment #1 from Mikael Morin  ---
Created attachment 55517
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55517&action=edit
Draft patch

This seems to work for this case, but I'm not sure how reliable it is.

[Bug middle-end/110617] RFE: Add a diagnostic-only variant of nonnull attribute

[alx at kernel dot org via Gcc-bugs]

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

Alejandro Colomar  changed:

   What|Removed |Added

 CC||alx at kernel dot org

--- Comment #3 from Alejandro Colomar  ---
Link:

[Bug plugins/110610] File insn-opinit.h not installed ?

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

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

--- Comment #9 from Andrew Pinski  ---
I am shocked that optabs.h is not included for PLUGIN_HEADERS 

[Bug tree-optimization/110613] optimization about combined store of adjacent bitfields

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2023-07-10

--- Comment #1 from Andrew Pinski  ---
Confirmed.
Note neither independently is optimized at the tree level; only at the RTL
level.

Note moving the load from bptr[1] to right before the first usage fixes it at
the RTL level too (most likely due to aliasing of character types being special
in C/C++).

[Bug middle-end/110617] RFE: Add a diagnostic-only variant of nonnull attribute

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

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

Sam James  changed:

   What|Removed |Added

 CC||bugzilla at tecnocode dot 
co.uk,
   ||sjames at gcc dot gnu.org,
   ||tim.ruehsen at gmx dot de

--- Comment #4 from Sam James  ---
There's a history of people objecting to use of nonnull, although I'm still
sceptical (not that it's my decision) - partly because nonnull has decent
takeup in general so changing its semantics now is not great.

It came up on the glib side at
https://gitlab.gnome.org/GNOME/glib/-/issues/2647, and wget2 considered/has
removed the attribute at https://gitlab.com/gnuwget/wget2/-/issues/200 too.

[Bug rtl-optimization/107013] Add fmin/fmax to RTL codes

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

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

HaoChen Gui  changed:

   What|Removed |Added

 CC||joseph at codesourcery dot com

--- Comment #1 from HaoChen Gui  ---
If fmin/max are added as new RTL codes, the fmin/max unspec in some targets can
be replaced with RTL codes. Do you think it is necessary? If so, I can draft
one. Looking forward to your advice. Thanks.

[Bug libgcc/110179] unwind-dw2-fde-dip.c:406: assignment makes integer from pointer without a cast

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Florian Weimer :

https://gcc.gnu.org/g:104b09005229ef48a79a33511ea192bb3ec3c415

commit r14-2426-g104b09005229ef48a79a33511ea192bb3ec3c415
Author: Florian Weimer 
Date:   Tue Jul 11 06:19:39 2023 +0200

libgcc: Fix -Wint-conversion warning in find_fde_tail

Fixes commit r14-1614-g49310a99330849 ("libgcc: Fix eh_frame fast path
in find_fde_tail").

libgcc/

PR libgcc/110179
* unwind-dw2-fde-dip.c (find_fde_tail): Add cast to avoid
implicit conversion of pointer value to integer.

[Bug libgcc/110179] unwind-dw2-fde-dip.c:406: assignment makes integer from pointer without a cast

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

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

Florian Weimer  changed:

   What|Removed |Added

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

--- Comment #4 from Florian Weimer  ---
Fixed in trunk.