[Bug c++/104708] RV64: gcc does not pass all library directories to linker

2022-02-27 Thread rui314 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104708

--- Comment #1 from Rui Ueyama  ---
Here is the link to the original bug report:
https://github.com/rui314/mold/issues/358

[Bug c++/104708] RV64: gcc does not pass all library directories to linker

2022-02-27 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104708

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 104707.

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

[Bug target/104707] gcc on riscv64 isn't passing entire library path to the linker

2022-02-27 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

Andrew Pinski  changed:

   What|Removed |Added

 CC||rui314 at gmail dot com

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

[Bug middle-end/80270] [9/10/11/12 Regression ICE in extract_bit_field_1 at gcc/expmed.c:1798

2022-02-27 Thread roger at nextmovesoftware dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80270

Roger Sayle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com
 Status|NEW |ASSIGNED
   Keywords|ice-on-invalid-code |ice-on-valid-code
 CC||roger at nextmovesoftware dot 
com

--- Comment #6 from Roger Sayle  ---
Patch proposed.
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590952.html

[Bug middle-end/104705] [12 regression] ICE ‘global_options’ are modified in local context in cl_optimization_compare

2022-02-27 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104705

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Mine.

[Bug c++/104709] New: A translated error message will include untanslated parts

2022-02-27 Thread goeran at uddeborg dot se via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104709

Bug ID: 104709
   Summary: A translated error message will include untanslated
parts
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goeran at uddeborg dot se
  Target Milestone: ---

In the function open_module_client in gcc/cp/mapper-client.cc there an error
message

failed %s mapper %qs line %u

and a similar without a line. This message is properly marked for translation.
The first %s in this message however will be a string which will be
untranslated, resulting in a mixed language message.

At the very least, the strings assigned (in various places) to "errmsg" need to
be marked for translation. Composing a message in this way is however a bad
idea in general, and might be hard to translate properly for some locales. If
possible it would be better to have more complete messages, not inserting parts
of it through a %s substitution. 

(See
https://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html#Decent-English-style
for a longer discussion.)

[Bug target/104610] memcmp () == 0 can be optimized better for avx512f

2022-02-27 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104610

--- Comment #13 from H.J. Lu  ---
(In reply to Hongtao.liu from comment #8)
> Created attachment 52495 [details]
> untested patch.

I see these regressions with -m32:

FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 "Splitting reg"
FAIL: gcc.target/i386/iamcu/test_basic_64bit_returning.c execution,  -O0 
FAIL: gcc.target/i386/iamcu/test_basic_64bit_returning.c execution,  -O1 
FAIL: gcc.target/i386/iamcu/test_basic_64bit_returning.c execution,  -O2 
FAIL: gcc.target/i386/iamcu/test_basic_64bit_returning.c execution,  -O3 -g 
FAIL: gcc.target/i386/iamcu/test_basic_64bit_returning.c execution,  -Os 
FAIL: gcc.target/i386/iamcu/test_struct_returning.c execution,  -O0 
FAIL: gcc.target/i386/iamcu/test_struct_returning.c execution,  -O1 
FAIL: gcc.target/i386/iamcu/test_struct_returning.c execution,  -Og -g

[Bug target/104610] memcmp () == 0 can be optimized better for avx512f

2022-02-27 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104610

--- Comment #14 from H.J. Lu  ---
(In reply to H.J. Lu from comment #13)
> (In reply to Hongtao.liu from comment #8)
> > Created attachment 52495 [details]
> > untested patch.
> 
> I see these regressions with -m32:
> 
> FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 "Splitting reg"
> FAIL: gcc.target/i386/iamcu/test_basic_64bit_returning.c execution,  -O0 
> FAIL: gcc.target/i386/iamcu/test_basic_64bit_returning.c execution,  -O1 
> FAIL: gcc.target/i386/iamcu/test_basic_64bit_returning.c execution,  -O2 
> FAIL: gcc.target/i386/iamcu/test_basic_64bit_returning.c execution,  -O3 -g 
> FAIL: gcc.target/i386/iamcu/test_basic_64bit_returning.c execution,  -Os 
> FAIL: gcc.target/i386/iamcu/test_struct_returning.c execution,  -O0 
> FAIL: gcc.target/i386/iamcu/test_struct_returning.c execution,  -O1 
> FAIL: gcc.target/i386/iamcu/test_struct_returning.c execution,  -Og -g

-m64 regression:

FAIL: gcc.target/i386/pr82580.c scan-assembler-not \\mmovzb

[Bug fortran/104570] [12 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.cc:3681 since r12-7217-g57da34939703a6e6

2022-02-27 Thread mikael at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104570

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #3 from Mikael Morin  ---
Created attachment 52521
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52521&action=edit
Draft patch, regtests cleanly

My bug, I guess.
Here is a (very ad hoc) fix.
I have yet to see how much of it is really necessary, and whether I want this
rather than reverting the regressing revision.

[Bug ada/104710] New: Ada-Bootstrap fails with gcc-4.8.4

2022-02-27 Thread bernd.edlinger at hotmail dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104710

Bug ID: 104710
   Summary: Ada-Bootstrap fails with gcc-4.8.4
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Configured as ususal with
.../configure --prefix=/home/ed/gnu/install --enable-languages=all

make fails in stage1:
gcc -std=gnu99 -c -g  -gnatpg -gnatwns -gnata -W -Wall -I- -I. -Iada/generated
-Iada -I../../gcc-trunk/gcc/ada ../../gcc-trunk/gcc/ada/osint.adb -o
ada/osint.o
osint.adb:438:31: "strlen" not declared in "CRTL"
osint.adb:441:14: "strncpy" not declared in "CRTL"
osint.adb:675:21: "strlen" not declared in "CRTL"
osint.adb:728:16: "Open_Append" is undefined
osint.adb:1108:41: "int64" not declared in "CRTL"
osint.adb:3130:28: "strlen" not declared in "CRTL"
osint.adb:3133:11: "strncpy" not declared in "CRTL"

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.4-2ubuntu1~14.04.4' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.4) 


git Bisect shows this started with

commit a6eae6a9bbf83ada3aab7f5a2a74e7024889d237
Author: Arnaud Charlet 
Date:   Mon Nov 29 10:15:26 2021 +

[Ada] Reduce runtime dependencies on stage1

gcc/ada/

* gcc-interface/Make-lang.in (ADA_GENERATED_FILES): Remove
s-casuti.ad?, s-crtl.ad?, s-os_lib.ad?.  Update list of object
files accordingly.


I wonder if this is intentional, since boot-strap with gcc-4.8.x works
otherwise.

[Bug ada/104710] Ada-Bootstrap fails with gcc-4.8.4

2022-02-27 Thread charlet at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104710

Arnaud Charlet  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX
 CC||charlet at gcc dot gnu.org

--- Comment #1 from Arnaud Charlet  ---
This is indeed now expected, see https://gcc.gnu.org/install/prerequisites.html

[Bug c/104711] New: Unnecessary -Wshift-negative-value warning

2022-02-27 Thread arnd at linaro dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711

Bug ID: 104711
   Summary: Unnecessary -Wshift-negative-value warning
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

During the discussion of increasing the C standard version of the Linux kernel
fro m gnu89 to gnu99 or higher, it turned out that gcc warns about code that
shifts negative signed integers [2].

This is undefined behavior in standard C99, but defined as a GNU extension in
GCC.[3]. This warning is enabled by default at the -Wextra level for C99/GNU99
or higher, but disabled for C89/GNU89. In clang, the warning is enabled by
default at the -Wall level but in turn disabled when building with -fwrapv or
-fno-strict-overflow (as the Linux kernel does).

It would be nice if future compiler releases could either demote the warning
from being enabled at -Wextra to -Wpedantic, or follow clang and disable it
when used with -fwrapv/-fno-strict-overflow.

[1] https://lore.kernel.org/lkml/20220227010956.gw...@gate.crashing.org/
[2] https://www.godbolt.org/z/s1TzxrGz4
[3] https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Integers-implementation.html

[Bug c/104711] Unnecessary -Wshift-negative-value warning

2022-02-27 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #1 from Andrew Pinski  ---
However, -fsanitize=shift (and -fsanitize=undefined) will diagnose such cases.
They are also diagnosed where constant expressions are required.

So they are still caught by the undefined sanitizers. Maybe the documentation
should mention the warning too.

[Bug c/104711] Unnecessary -Wshift-negative-value warning

2022-02-27 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
Our documentation says in


  As an extension to the C language, GCC does not use the latitude given in C99
  and C11 only to treat certain aspects of signed ‘<<’ as undefined. However,
  -fsanitize=shift (and -fsanitize=undefined) will diagnose such cases. They
are
  also diagnosed where constant expressions are required.

It would be much saner / much more practical if we actually implemented this,
i.e. don't have -Wshift-negative-value in -Wextra (the above text does not make
much sense if that was the design!)

This warning does have a good enough balance between amount of false positives,
detection of serious problems, and usefulness to be included in -Wextra.  The
considerations for -Wall and -W are exactly the same, just the bar is lower for
the latter.

Confirmed.

[Bug c/104711] Unnecessary -Wshift-negative-value warning

2022-02-27 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711

--- Comment #3 from Segher Boessenkool  ---
... does NOT have a good enough balance ...

Sorry :-)

[Bug c/104711] Unnecessary -Wshift-negative-value warning

2022-02-27 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711

--- Comment #4 from Segher Boessenkool  ---
Created attachment 52522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52522&action=edit
testcase

[Bug c++/104618] [12 Regression] trunk 20220221 on x86_64-linux-gnu ICEs building sh.cc for sh4-linux-gnu (in build_call_a, at cp/call.cc:381)

2022-02-27 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104618

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:0096b0b467b2c98ed258f0ead9a8b87b2a6d8466

commit r12-7398-g0096b0b467b2c98ed258f0ead9a8b87b2a6d8466
Author: Jason Merrill 
Date:   Fri Feb 25 15:26:17 2022 -0400

c++: (*(fn))() [PR104618]

The patch for PR90451 deferred marking to the point of actual use; we
missed
this one because of the parens.

PR c++/104618

gcc/cp/ChangeLog:

* typeck.cc (cp_build_addr_expr_1): Also
maybe_undo_parenthesized_ref.

gcc/testsuite/ChangeLog:

* g++.dg/overload/paren1.C: New test.

[Bug target/104686] [12 Regression] Huge compile-time regression building SPEC 2017 538.imagick_r with -march=skylake

2022-02-27 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104686

--- Comment #11 from Hongtao.liu  ---
(In reply to Martin Liška from comment #8)
> (In reply to Martin Liška from comment #7)
> > (In reply to Richard Biener from comment #6)
> > > Both revisions affect vectorizer cost modeling only.  With
> > > -fno-vect-cost-model it compiles faster for me but still a slow 30s and 
> > > 91%
> > > in RA.
> > 
> > There are numbers with -fno-vect-cost-model:
> > 
> > Bisecting latest revisions
> >   a9e2ebe839d56416(24 Feb 2022 22:16)(ol...@adacore.com): [took: 36.06 s]
> > result: OK
> >   250f234988b62316(20 Apr 2021 09:51)(stefa...@linux.ibm.com): [took: 18.35
> > s] result: OK
> > 
> > I'm going to find out where the change happensed.
> 
> Which started with r12-2463-ga6291d88d5b6c17d.

Wonder if it's related to hard register usage in pass_expand
op1 = ix86_gen_scratch_sse_rtx (mode);

[Bug target/101908] [12 regression] cray regression with -O2 -ftree-slp-vectorize compared to -O2

2022-02-27 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908

--- Comment #26 from Hongtao.liu  ---
(In reply to Richard Biener from comment #22)
> (In reply to Hongtao.liu from comment #21)
> > Now we have SLP node available in vector cost hook, maybe we can do sth in
> > cost model to prevent vectorization when node's definition from big-size
> > parameter.
> 
> Note we vectorize a load here for which we do not pass down an SLP node.
> But of course there's the stmt-info one could look at - but the issue
> is that for SLP that doesn't tell you which part of the variable is accessed.
> Also even if we were to pass down the SLP node we do not know exactly how
> it is going to vectorize - but sure, we could play with some heuristics
> there.
> 
> For x86 we can just assume that all aggregates > 16 bytes are passed on the
> stack, correct?  Note I see for
> 
> #include 
> 
> struct X { double x[3]; };
> typedef double v2df __attribute__((vector_size(16)));
> 
> v2df __attribute__((noipa))
> foo (struct X x, struct X y)
> {
>   return (v2df) {x.x[1], x.x[2] } + (v2df) { y.x[0], y.x[1] };
> }
> 
> struct X y;
> int main(int argc, char **argv)
> {
>   struct X x = y;
>   int cnt = atoi (argv[1]);
>   for (int i = 0; i < cnt; ++i)
> foo (x, x);
>   return 0;
> }
> 
> the structs passed as
> 
> movups  %xmm0, 24(%rsp)
> movq%rax, 40(%rsp)
> movq%rax, 16(%rsp)
> movups  %xmm0, (%rsp)
> callfoo
> 
> so alignment of the stack variable depends on the position of the
> function argument (and thus preceeding parameters).  That means
> we cannot rely on &y being 16 byte aligned and it seems we cannot
> rely on a particular store sequence order either here.
We can start with disabling vectorization with very cheap cost model to fix O2
regressions, then fine tune that in GCC 13.

[Bug target/101908] [12 regression] cray regression with -O2 -ftree-slp-vectorize compared to -O2

2022-02-27 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908

--- Comment #27 from Hongtao.liu  ---
> We can start with disabling vectorization with very cheap cost model to fix
Of course only for (>=)16-byte struct passing.

[Bug target/104704] [12 Regression] ix86_gen_scratch_sse_rtx doesn't work with explicit XMM7/XMM15/XMM31 usage

2022-02-27 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104704

--- Comment #2 from Hongtao.liu  ---
Yes, thanks for the reproduced testcase.

[Bug target/104704] [12 Regression] ix86_gen_scratch_sse_rtx doesn't work with explicit XMM7/XMM15/XMM31 usage

2022-02-27 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104704

--- Comment #3 from Hongtao.liu  ---
(In reply to H.J. Lu from comment #1)
> ix86_expand_vector_move shouldn't use ix86_gen_scratch_sse_rtx.

Is it problematic for TARGET_GEN_MEMSET_SCRATCH_RTX?

[Bug target/104686] [12 Regression] Huge compile-time regression building SPEC 2017 538.imagick_r with -march=skylake

2022-02-27 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104686

--- Comment #12 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #11)
> (In reply to Martin Liška from comment #8)
> > (In reply to Martin Liška from comment #7)
> > > (In reply to Richard Biener from comment #6)
> > > > Both revisions affect vectorizer cost modeling only.  With
> > > > -fno-vect-cost-model it compiles faster for me but still a slow 30s and 
> > > > 91%
> > > > in RA.
> > > 
> > > There are numbers with -fno-vect-cost-model:
> > > 
> > > Bisecting latest revisions
> > >   a9e2ebe839d56416(24 Feb 2022 22:16)(ol...@adacore.com): [took: 36.06 s]
> > > result: OK
> > >   250f234988b62316(20 Apr 2021 09:51)(stefa...@linux.ibm.com): [took: 
> > > 18.35
> > > s] result: OK
> > > 
> > > I'm going to find out where the change happensed.
> > 
> > Which started with r12-2463-ga6291d88d5b6c17d.
> 
> Wonder if it's related to hard register usage in pass_expand
in ix86_expand_vector_move which will be called by emit_move_insn.
> op1 = ix86_gen_scratch_sse_rtx (mode);

[Bug target/104704] [12 Regression] ix86_gen_scratch_sse_rtx doesn't work with explicit XMM7/XMM15/XMM31 usage

2022-02-27 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104704

--- Comment #4 from H.J. Lu  ---
(In reply to Hongtao.liu from comment #3)
> (In reply to H.J. Lu from comment #1)
> > ix86_expand_vector_move shouldn't use ix86_gen_scratch_sse_rtx.
> 
> Is it problematic for TARGET_GEN_MEMSET_SCRATCH_RTX?

It is OK as long as it is used only by memset expander.

[Bug c++/104712] New: -fkeep-inline-functions causing link errors (debian but not godbolt?)

2022-02-27 Thread ajrh at ajrh dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104712

Bug ID: 104712
   Summary: -fkeep-inline-functions causing link errors  (debian
but not godbolt?)
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ajrh at ajrh dot net
  Target Milestone: ---

For use with gcov, I'm trying to use the --keep-inline-functions flag, as
suggested in the GCC manual,  but it's causing a lot of link errors on various
types of objects.   The undefined references were my initial problem,  I'm not
sure about the relocation errors also.

Possibly it's config-specific, as I made one example via creduce, which gives
the error below,  but it appears to compile fine in godbolt.Debian config
attached below also.



template  void g(T, T) { }

class C {
  static int XYZZY;
  int x;
  void f() { g(x, XYZZY); }
};

int main()
{
return 0;
}



This compiles and runs cleanly with 'g++ -Wall foo.cpp && a.out'

But with the flag added:

g++ -Wall -fkeep-inline-functions foo.cpp

/usr/bin/ld: /tmp/ccewh7OH.o: warning: relocation against `_ZN1C5XYZZYE' in
read-only section `.text._ZN1C1fEv[_ZN1C1fEv]'
/usr/bin/ld: /tmp/ccewh7OH.o: in function `C::f()':
foo.cpp:(.text._ZN1C1fEv[_ZN1C1fEv]+0xe): undefined reference to `C::XYZZY'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status



gcc -v  

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 11.2.0-14'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-y1lmfE/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-y1lmfE/gcc-11-11.2.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Debian 11.2.0-14)

[Bug c++/104712] -fkeep-inline-functions causing link errors (debian but not godbolt?)

2022-02-27 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104712

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
You only have a declaration and not a definition.
You need to add:
int C::XYZZY;

And that will fix the issue you are seeing.

[Bug c++/104712] -fkeep-inline-functions causing link errors (debian but not godbolt?)

2022-02-27 Thread ajrh at ajrh dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104712

--- Comment #2 from ajrh at ajrh dot net ---
Oh drat,  reduced test cases are maddening...  it's an inline static const in
my original.   I'll try to reduce something again.

[Bug c++/104712] -fkeep-inline-functions causing link errors (debian but not godbolt?)

2022-02-27 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104712

--- Comment #3 from Andrew Pinski  ---
(In reply to ajrh from comment #2)
> Oh drat,  reduced test cases are maddening...  it's an inline static const
> in my original.   I'll try to reduce something again.

I think even with inline static const, you still have to have a definition
depending on how it is used.

[Bug target/101908] [12 regression] cray regression with -O2 -ftree-slp-vectorize compared to -O2

2022-02-27 Thread lili.cui at intel dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908

--- Comment #28 from cuilili  ---
(In reply to H.J. Lu from comment #25)
> Can this be mitigated by removing redundant load and store?
Yes, inlining say_sphere can remove redundant loads and stores, O3 does
inlining, but O2 is more sensitive to code size and cannot be inlined.

[Bug rtl-optimization/104664] [12 Regression] ICE: in extract_constrain_insn, at recog.cc:2670 (insn does not satisfy its constraints) with -Og -ffinite-math-only

2022-02-27 Thread wwwhhhyyy333 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104664

--- Comment #4 from Hongyu Wang  ---
(In reply to Uroš Bizjak from comment #3)

> Reconfirmed as RA issue.

I'm afraid we'd avoid pattern like

(insn 180 179 182 2 (set (reg:V8HF 220)
(subreg:V8HF (reg:HF 221) 0)) "pr104664.c":12:7 1710 {movv8hf_internal}

since we don't have corresponding pattern with subreg. Reload might not aware
of the newly inserted regs properly, as the message shows

Set class ALL_REGS for r221
Set class ALL_REGS for r220

I'm testing

diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
index 6cf1a0b9cb6..658516d86a2 100644
--- a/gcc/config/i386/i386-expand.cc
+++ b/gcc/config/i386/i386-expand.cc
@@ -14883,7 +14883,12 @@ ix86_expand_vector_init_duplicate (bool mmx_ok,
machine_mode mode,
  dperm.one_operand_p = true;

  if (mode == V8HFmode)
-   tmp1 = lowpart_subreg (V8HFmode, force_reg (HFmode, val), HFmode);  
+   {
+ tmp1 = force_reg (HFmode, val);
+ tmp2 = gen_reg_rtx (mode);
+ emit_insn (gen_vec_setv8hf_0 (tmp2, CONST0_RTX (mode), tmp1));
+ tmp1 = gen_lowpart (mode, tmp2);
+   }

[Bug target/104686] [12 Regression] Huge compile-time regression building SPEC 2017 538.imagick_r with -march=skylake

2022-02-27 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104686

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r12-7401-ga8250bbaeb2e8250c20db477fe67fd085214be7c
Author: Richard Biener 
Date:   Fri Feb 25 14:19:44 2022 +0100

rtl-optimization/104686 - speed up conflict iteration

The following replaces

   /* Skip bits that are zero.  */
   for (; (word & 1) == 0; word >>= 1)
 bit_num++;

idioms in ira-int.h in the attempt to speedup
update_conflict_hard_regno_costs
which we're bound on in PR104686.  The trick is to use ctz_hwi here
which should pay off even with dense bitmaps on architectures that
have HW support for this.

For the PR in question this speeds up compile-time from 31s to 24s for
me.

2022-02-25  Richard Biener  

PR rtl-optimization/104686
* ira-int.h (minmax_set_iter_cond): Use ctz_hwi to elide loop
skipping bits that are zero.
(ira_object_conflict_iter_cond): Likewise.

[Bug target/104686] [12 Regression] Huge compile-time regression building SPEC 2017 538.imagick_r with -march=skylake

2022-02-27 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104686

--- Comment #14 from Richard Biener  ---
The pushed change is a micro-optimization not really addressing the underlying
issue which needs more analysis.

[Bug tree-optimization/104700] [12 Regression] ICE on valid code at -O2 and -O3 with -fno-tree-ccp -fno-tree-dce -fno-tree-vrp on x86_64-linux-gnu: in find_or_generate_expression, at tree-ssa-pre.cc:2

2022-02-27 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104700

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Thanks for the testcases.

[Bug tree-optimization/104700] [12 Regression] ICE on valid code at -O2 and -O3 with -fno-tree-ccp -fno-tree-dce -fno-tree-vrp on x86_64-linux-gnu: in find_or_generate_expression, at tree-ssa-pre.cc:2

2022-02-27 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104700

--- Comment #5 from Martin Liška  ---
Btw. I see the same ICE on libreoffice.

[Bug tree-optimization/104700] [12 Regression] ICE on valid code at -O2 and -O3 with -fno-tree-ccp -fno-tree-dce -fno-tree-vrp on x86_64-linux-gnu: in find_or_generate_expression, at tree-ssa-pre.cc:2

2022-02-27 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104700

--- Comment #6 from Richard Biener  ---
Fix in testing.