[Bug target/94103] Wrong optimization: reading value of a variable changes its representation for optimizer

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #6 from Jeffrey A. Law  ---
It was pr93270.

I agree.  It feels like something should be looking at the TYPE_PRECISION that
is instead looking at TYPE_SIZE.

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[vincent-gcc at vinc17 dot net]

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

--- Comment #46 from Vincent Lefèvre  ---
(In reply to Alexander Cherepanov from comment #45)
> (In reply to Vincent Lefèvre from comment #44)
> > (In reply to Alexander Cherepanov from comment #43)
> > > GCC on x86-64 uses the binary encoding for the significand.
> > 
> > In general, yes. This includes the 32-bit ABI under Linux. But it seems to
> > be different under MS-Windows, at least with MinGW using the 32-bit ABI:
> > according to my tests of MPFR,
[...]
> > i.e. GCC uses DPD instead of the usual BID.
> 
> Strange, I tried mingw from stable Debian on x86-64 and see it behaving the
> same way as the native gcc:

Sorry, I've looked at the code (the detection is done by the configure script),
and in case of cross-compiling, MPFR just assumes that this is DPD. I confirm
that this is actually BID. So MPFR's guess is wrong. It appears that this does
not currently have any consequence on the MPFR build and the tests, so that the
issue remained unnoticed.

> > In C, it is valid to choose any possible encoding. Concerning the IEEE 754
> > conformance, this depends on the bindings. But IEEE 754 does not define the
> > ternary operator. It depends whether C considers encodings before or
> > possibly after optimizations (in the C specification, this does not matter,
> > but when IEEE 754 is taken into account, there may be more restrictions).
> 
> The ternary operator is not important, let's replace it with `if`:
> 
> --
> #include 
> 
> _Decimal32 f(_Decimal32 x)
> {
> _Decimal32 inf = (_Decimal32)INFINITY + 0;
> 
> if (x == inf)
> return inf;
> else
> return x;
> }
> --
> 
> This is optimized into just `return x;`.

I'm still wondering whether the optimization is valid, since this affects only
the encoding, not the value, and in general, C allows the encoding to change
when accessing an object. I don't know whether the C2x draft says something
special about the decimal formats.

> N2478, a recent draft of C2x, lists bindings in F.3 and "convertFormat -
> different formats" corresponds to "cast and implicit conversions". Is this
> enough?

But ditto, is optimization that just modifies the encoding allowed?

[Bug c++/93425] [9/10 Regression] Template parameter deduction failure when template parameters have template template parameter since r9-3807-g5d9a0e3b99e31a21

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed, presumably by

commit 6b3302da9ef26aa11940f8c0dc92bec19e15c09b
Author: Marek Polacek 
Date:   Tue Mar 3 17:56:44 2020 -0500

c++: Fix mismatch in template argument deduction [PR90505]

[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data

[casner at acm dot org]

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

--- Comment #13 from Stephen Casner  ---
(In reply to Stephen Casner from comment #9)
(Commenting on my own comment)
> 1. pdp11-aout does not have a .lcommon or .lcomm section, just .text, .data
> and .bss.  But also I'm missing something about the concept of a
> NOSWITCH_SECTION that you can't switch to with an assembler directive -- how
> do you tell the assembler to assign a variable to that section if you don't
> emit a directive?

The a.out file format produced by the assembler or linker includes only the
.text, .data and .bss sections.  However, that does not mean the compiler could
not pass a .comm or .lcomm directive to the assembler.  I now understand those
and the NOSWITCH concept.  In fact, I found that the Unix v6 cc produces the
.comm directive which I had not seen before:

# cat > static.c
int zero;
int one;
int main() {
static int two;
zero = 0;
one = 1;
two = 2;
}
# cc -S static.s static.c
# cat static.s
.globl  _zero
.comm   _zero,2
.globl  _one
.comm   _one,2
.globl  _main
.text
_main:
~~main:
.bss
L2:.=.+2
.text
~two=L2
jsr r5,csv
clr _zero
mov $1,_one
mov $2,L2
L1:jmp  cret
.globl
.data
# 

So presumably the ASM_OUTPUT{_ALIGNED{,_DECL}_}_LOCAL functions could generate
.comm and .lcomm directives to be allocated to the .bss section by as.  I don't
know if there is enough size information in the relocation section of the a.out
file to allow merging global .comm declarations.

[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data

[casner at acm dot org]

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

--- Comment #12 from Stephen Casner  ---
(In reply to pkoning from comment #11)
> (In reply to Stephen Casner from comment #9)
> > 7. Emitting the zero-initialized variable into .data when it happens to
> > follow a nonzero-initialized variable is also not correct, or at least
> > suboptimal.  If there is a vary large uninitialized array, that would make
> > the final executable output file much larger.  (OK, these days a full 64KB
> > is still a pittance, but on principal it's suboptimal.)  Therefore,
> > switching to .bss in ASM_OUTPUT{_ALIGNED{,_DECL}_}_LOCAL is good.
> 
> Yes, if the assembler/linker supports that, but my understanding is that
> they do not.  It would be lovely if we could have ELF for pdp11...

Although .bss is not defined as a general GNU Assembler directive, it is
defined as a PDP-11 dependent feature.  It was also included in the PDP11 Unix
assembly language as produced by cc on 2.11BSD, for example:

user[47] cat > array.c
static int zero[1000];
static int one[1000] = { 1 };
int main() {}
user[48] cc -S -o array.s array.c
user[49] cat array.s
.globl  
.bss
_zero:
.=.+3720
.data
_one:
1
.=.+3716
.globl  _main
.text
_main:
~~main:
jsr r5,csv
jbr L1
L2:L3:jmp   cret
L1:jbr  L2
.globl
.data
user[50] 

This array.s is not accepted by GNU as because of the .globl without a symbol,
the constant 1 without .word, and the jbr mnemonic.

[Bug target/94145] Longcalls mis-optimize loading the function address

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #4 from Alan Modra  ---
Created attachment 48022
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48022=edit
gcc fix to make plt loads volatile

This patch has some commentary explaining what is going on.  Strictly speaking
what is in the PLT is *not* the "address of a function".  I haven't
bootstrapped it yet, but Mike has used it to build spec with -mlongcalls which
probably is better testing for this patch than a bootstrap anyway.

[Bug target/94145] Longcalls mis-optimize loading the function address

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com
   Last reconfirmed||2020-03-11
 Ever confirmed|0   |1

[Bug c++/93596] [10 Regression] ICE related to templates and vectors.

[pacoarjonilla at yahoo dot es]

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

--- Comment #7 from Paco Arjonilla  ---
It's bug error 93596, not 93956.
Thanks for the fix.

[Bug target/94136] GCC doc for built-in function __builtin___clear_cache() not 100% correct

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #3 from Jim Wilson  ---
Another possible issue is that __clear_cache is defined in the libgcc docs. 
But only some platforms are defining CLEAR_INSN_CACHE so only some targets have
a usable __clear_cache function.

[Bug tree-optimization/94131] [10 Regression] ICE: tree check: expected integer_cst, have plus_expr in get_len, at tree.h:5927 since r10-2814-g22fca489eaf98f26

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Keywords|ice-on-invalid-code |ice-on-valid-code
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #4 from Martin Sebor  ---
The code looks valid to me.  It may be undefined because of the missing
initialization but with the VLA initialized the ICE is still there because the
function isn't prepared to deal with the VLA's non-constant bound.

[Bug target/94145] Longcalls mis-optimize loading the function address

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
C11 6.6/9 says it *always* is constant, even.

[Bug target/94145] Longcalls mis-optimize loading the function address

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
How could the function address ever not be constant?

Hoisting it to somewhere where it is (dynamically) more expensive is a
bad idea, of course.

[Bug lto/94150] New: Improve LTO diagnosis for LTO triggered warnings/error: print source.o or source.a(lib.o) when printing location

[romain.geissler at amadeus dot com]

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

Bug ID: 94150
   Summary: Improve LTO diagnosis for LTO triggered
warnings/error: print source.o or source.a(lib.o) when
printing location
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hi,

When LTO warnings/error are reported and print a given location, it would be
nice to not only print the C/C++ file name, but also from which .o or .a
library it comes from.

Example of -Werror=lto-type-mistmatch I just got because I was mixing
incompatible .o built against different version of the same header file
"toolbox/UTF8Utils.h":

/remote/intdeliv/components/mdw/Toolbox/18-0-0-56/include/toolbox/UTF8Utils.h:106:
error: type of ‘operator[]’ does not match original declaration
[-Werror=lto-type-mismatch]
 char operator[] (size_t x);

src/UTF8Utils.cpp:148: note: implicit this pointer type mismatch
include/toolbox/UTF8Utils.h:23: note: type ‘struct UTF8Char’ itself violates
the C++ One Definition Rule
/remote/tmp/rnd-aqg/software_factory/bms_replication/mdw/Toolbox/18-0-0-48/include/toolbox/UTF8Utils.h:22:
note: the incompatible type is defined here
 class TOOLBOX_EXPORT UTF8Char

src/UTF8Utils.cpp:148: note: ‘operator[]’ was previously declared here
src/UTF8Utils.cpp:148: note: code may be misoptimized unless
-fno-strict-aliasing is used


The problem here is that I mixed our own version of a library named "Toolbox"
from version 18-0-0-56 and 18-0-0-48 which are incompatible. I need to rebuild
the .o which is using version 18-0-0-48 as given in the error, however I have
no idea which libraries is that, and I have hundreds of them, which
unfortunately I can't rebuild massively easily.

So if the location in LTO mode could print something like:

/path/to/wrong/lib.a(name_of_o_file.o):/remote/tmp/rnd-aqg/software_factory/bms_replication/mdw/Toolbox/18-0-0-48/include/toolbox/UTF8Utils.h:22:
note: the incompatible type is defined here
 class TOOLBOX_EXPORT UTF8Char

that would help identifying which files need rebuilding.

Cheers,
Romain

[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data

[pkoning at gcc dot gnu.org]

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

--- Comment #11 from pkoning at gcc dot gnu.org ---
(In reply to Stephen Casner from comment #9)

A lot of these questions should have answers in the GCC Internals manual, which
is quite good.  And also quite dense.  I know it a little, enough for a bunch
of cleanup on the pdp11 target in recent years, but I'm certainly not an
expert.  The gcc mailing list is where you find experts.  Some comments below
for the parts I can answer:

> ...
> 2. Good point about optimization possibly omitting the variables in my test
> case.  Of course, the variables were used in my real program where I first
> observed this problem, and I was trying to reduce my test case to the
> minimum.  If I had tried optimization and seen them removed, I would have
> expanded the test case.

The test case was fine.  What I meant is that when I compiled with -O1, the
back end would emit b followed by a, which wouldn't show the problem because
emitting b would correctly send the .data even in the old code.
> 
> 3. The goal that I am working toward is to have gcc and ld work correctly
> for the -msplit option in pdp11-aout.  For that case, instructions and data
> are stored in separate, overlapping 64KB address spaces, so even if a
> variable is const it can't go in the .text section.

Yes.  Ideally as/ld would support .rodata, but without that it has to be .data. 

>... 
> 5. Fixing the extra blank line for .globl is also good, but I was unsure why
> the code was as it is.  Also I didn't figure out how there was a tab before
> .globl since it wasn't in the string constant.

The assembler doesn't actually care about any of that, so it's just a matter of
aiming for reasonable consistency to make the assembly code somewhat readable. 
The code generator isn't all that consistent, but there isn't any reason for
that as far as I am aware.

>...
> 7. Emitting the zero-initialized variable into .data when it happens to
> follow a nonzero-initialized variable is also not correct, or at least
> suboptimal.  If there is a vary large uninitialized array, that would make
> the final executable output file much larger.  (OK, these days a full 64KB
> is still a pittance, but on principal it's suboptimal.)  Therefore,
> switching to .bss in ASM_OUTPUT{_ALIGNED{,_DECL}_}_LOCAL is good.

Yes, if the assembler/linker supports that, but my understanding is that they
do not.  It would be lovely if we could have ELF for pdp11...

---
On the linker option tied to -msplit, I haven't used this but the GCC Internals
manual gives the answer, in "18.2 Controlling the Compilation Driver, ‘gcc’" --
LINK_SPEC will do this.

[Bug c++/93907] [10 Regression] internal compiler error: in hashtab_chk_error, at hash-table.c:137

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |10.0
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Jason Merrill  ---
Fixed in r10-7133-gbde31a76ba48be49dbe26317ce5e19d10ae9f310

[Bug target/94135] PPC: subfic instead of neg used for rotate right

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-03-11
 Status|UNCONFIRMED |NEW

[Bug target/94135] PPC: subfic instead of neg used for rotate right

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #1 from Segher Boessenkool  ---
On what CPU do subfic and neg execute at different speed?

(neg is better, of course, it doesn't write CA).

GCC does not know rotates work for any masking of the amount (with 1's in
the low 5 (resp. 6) bits); the rs6000 target code does not know about any
masking (the SHIFT_COUNT_TRUNCATED macro cannot be used, but we could have
more patterns, and then combine can do this in many cases).

[Bug c++/94074] [10 Regression] bogus modifying a const object error with const COMPONENT_REF

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Hopefully fixed.

[Bug c++/94074] [10 Regression] bogus modifying a const object error with const COMPONENT_REF

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
commit 7eb5be6ab91ec03f93038ac2bcf3028cf2e7c82b
Author: Marek Polacek 
Date:   Fri Mar 6 17:30:11 2020 -0500

c++: Fix wrong modifying const object error for COMPONENT_REF [PR94074]

I got a report that building Chromium fails with the "modifying a const
object" error.  After some poking I realized it's a bug in GCC, not in
their codebase.

Much like with ARRAY_REFs, which can be const even though the array
itself isn't, COMPONENT_REFs can be const although neither the object
nor the field were declared const.  So let's dial down the checking.
Here the COMPONENT_REF was const because of the "const_cast(m)"
thing -- cxx_eval_component_reference then builds a COMPONENT_REF with
TREE_TYPE (t).

While looking into this I noticed that we don't detect modifying a const
object in certain cases like in
.  That's because
we never evaluate an X::X() CALL_EXPR -- there's none.  Fixed as per
Jason's suggestion by setting TREE_READONLY on a CONSTRUCTOR after
initialization in cxx_eval_store_expression.

2020-03-11  Marek Polacek  
Jason Merrill  

PR c++/94074 - wrong modifying const object error for
COMPONENT_REF.
* constexpr.c (cref_has_const_field): New function.
(modifying_const_object_p): Consider a COMPONENT_REF
const only if any of its fields are const.
(cxx_eval_store_expression): Mark a CONSTRUCTOR of a const type
as readonly after its initialization has been done.

* g++.dg/cpp1y/constexpr-tracking-const17.C: New test.
* g++.dg/cpp1y/constexpr-tracking-const18.C: New test.
* g++.dg/cpp1y/constexpr-tracking-const19.C: New test.
* g++.dg/cpp1y/constexpr-tracking-const20.C: New test.
* g++.dg/cpp1y/constexpr-tracking-const21.C: New test.
* g++.dg/cpp1y/constexpr-tracking-const22.C: New test.

[Bug c++/94149] __is_constructible doesn't know about C++20 parenthesized init for arrays

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #3 from Ville Voutilainen  ---
(In reply to Marek Polacek from comment #2)
> C++20 paren-init -> mine.

This goes from constructible_expr into
perform_direct_initialization_if_possible, which then goes into
implicit_conversion, which fails to build a conversion.

[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data

[casner at acm dot org]

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

--- Comment #10 from Stephen Casner  ---
One more question:  I'm working on binutils ld as well, wanting to implement a
new option --imagic for pdp11-aout that outputs magic number 0413 and sets both
.text and .data at address 0 (with .bss to follow .data).  If -msplit is
included as a compilation option, then --imagic should be passed to the linker.
 I'd appreciate a pointer to where that should happen.

[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data

[casner at acm dot org]

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

--- Comment #9 from Stephen Casner  ---
Thank you all for your prompt action on this bug.  I have some comments and
questions if you are willing to help with my education about gcc internals:

1. pdp11-aout does not have a .lcommon or .lcomm section, just .text, .data and
.bss.  But also I'm missing something about the concept of a NOSWITCH_SECTION
that you can't switch to with an assembler directive -- how do you tell the
assembler to assign a variable to that section if you don't emit a directive?

2. Good point about optimization possibly omitting the variables in my test
case.  Of course, the variables were used in my real program where I first
observed this problem, and I was trying to reduce my test case to the minimum. 
If I had tried optimization and seen them removed, I would have expanded the
test case.

3. The goal that I am working toward is to have gcc and ld work correctly for
the -msplit option in pdp11-aout.  For that case, instructions and data are
stored in separate, overlapping 64KB address spaces, so even if a variable is
const it can't go in the .text section.

4. I assumed that putting switch_to_section in the ASM_OUTPUT_ALIGNED_LOCAL
function might not be legal since that is in the callback of a section so it
might confuse the state of the caller.  But if that is valid, then switching to
bss_section is the right thing to do because pdp11-aout does have .bss. 
Emitting the variable in whatever section was currently active is clearly
wrong.

5. Fixing the extra blank line for .globl is also good, but I was unsure why
the code was as it is.  Also I didn't figure out how there was a tab before
.globl since it wasn't in the string constant.

6. I agree that verifying the generated assembly language is a sufficient
check.  But the way I run this code now is in emulation using SimH.

7. Emitting the zero-initialized variable into .data when it happens to follow
a nonzero-initialized variable is also not correct, or at least suboptimal.  If
there is a vary large uninitialized array, that would make the final executable
output file much larger.  (OK, these days a full 64KB is still a pittance, but
on principal it's suboptimal.)  Therefore, switching to .bss in
ASM_OUTPUT{_ALIGNED{,_DECL}_}_LOCAL is good.

8. When the variables are not static (hence global), then TREE_PUBLIC is true
so it is not assigned to the lcomm_section and instead falls through to be
assigned to the .data section.  It seems that zero-initialized variables should
be assigned to the same section whether local or global.  So I think we do need
a TARGET_ASM_SELECT_SECTION function for the pdp11-aout target implemented by a
pdp11_select_section function that looks at bss_initializer_p (decl) to choose
between .data and .bss.  Or does it need anything more of the logic like this
from get_variable_section, or maybe define bss_noswitch_section to be
bss_section if that makes sense?

  if (ADDR_SPACE_GENERIC_P (as)
  && !DECL_THREAD_LOCAL_P (decl)
  && !(prefer_noswitch_p && targetm.have_switchable_bss_sections)
  && bss_initializer_p (decl))
{
  if (!TREE_PUBLIC (decl)
  && !((flag_sanitize & SANITIZE_ADDRESS)
   && asan_protect_global (decl)))
return lcomm_section;
  if (bss_noswitch_section)
return bss_noswitch_section;
}

[Bug c++/94149] __is_constructible doesn't know about C++20 parenthesized init for arrays

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
C++20 paren-init -> mine.

[Bug target/94123] [10 regression] r10-1734, SVN r273240, causes gcc.target/powerpc/pr87507.c to fail

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-11
 Ever confirmed|0   |1

--- Comment #5 from Segher Boessenkool  ---
Confirmed.

On p9 it is all fine.

On p7 it is worse, you get std's followed by an lxvd2x from the same stack
address (big LHS/SHL hazard there), and then two stxvd2x.

On p8 the TImode values aren't split at all, not until final output anyway.

[Bug c++/93805] [8/9/10 Regression] A suspicious -Werror=noexcept warning since r8-2461-g9fb82e652cee118b

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
Looking into it.

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[ch3root at openwall dot com]

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

--- Comment #45 from Alexander Cherepanov  ---
(In reply to Vincent Lefèvre from comment #44)
> (In reply to Alexander Cherepanov from comment #43)
> > GCC on x86-64 uses the binary encoding for the significand.
> 
> In general, yes. This includes the 32-bit ABI under Linux. But it seems to
> be different under MS-Windows, at least with MinGW using the 32-bit ABI:
> according to my tests of MPFR,
> 
> MPFR config.status 4.1.0-dev
> configured by ./configure, generated by GNU Autoconf 2.69,
>   with options "'--host=i686-w64-mingw32' '--disable-shared'
> '--with-gmp=/usr/local/gmp-6.1.2-mingw32' '--enable-assert=full'
> '--enable-thread-safe' 'host_alias=i686-w64-mingw32'"
> [...]
> CC='i686-w64-mingw32-gcc'
> [...]
> [tversion] Compiler: GCC 8.3-win32 20191201
> [...]
> [tversion] TLS = yes, float128 = yes, decimal = yes (DPD), GMP internals = no
> 
> i.e. GCC uses DPD instead of the usual BID.

Strange, I tried mingw from stable Debian on x86-64 and see it behaving the
same way as the native gcc:

$ echo 'int main() { return (union { _Decimal32 d; int i; }){0.df}.i; }' >
test.c

$ gcc -O3 -fdump-tree-optimized=test.out test.c && grep -h return test.out
  return 847249408;
$ gcc --version | head -n 1
gcc (Debian 8.3.0-6) 8.3.0

$ x86_64-w64-mingw32-gcc -O3 -fdump-tree-optimized=test.out test.c && grep -h
return test.out
  return 847249408;
$ x86_64-w64-mingw32-gcc --version | head -n 1
x86_64-w64-mingw32-gcc (GCC) 8.3-win32 20190406

$ i686-w64-mingw32-gcc -O3 -fdump-tree-optimized=test.out test.c && grep -h
return test.out
  return 847249408;
$ i686-w64-mingw32-gcc --version | head -n 1
i686-w64-mingw32-gcc (GCC) 8.3-win32 20190406

Plus some other cross-compilers:

$ powerpc64-linux-gnu-gcc -O3 -fdump-tree-optimized=test.out test.c && grep -h
return test.out
  return 575668224;
$ powerpc64-linux-gnu-gcc --version | head -n 1
powerpc64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0

$ powerpc64le-linux-gnu-gcc -O3 -fdump-tree-optimized=test.out test.c && grep
-h return test.out
  return 575668224;
$ powerpc64le-linux-gnu-gcc --version | head -n 1
powerpc64le-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0

$ s390x-linux-gnu-gcc -O3 -fdump-tree-optimized=test.out test.c && grep -h
return test.out
  return 575668224;
$ s390x-linux-gnu-gcc --version | head -n 1
s390x-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0

AIUI the value 847249408 (= 0x3280) is right for 0.df with BID and
575668224 (= 0x2250) is right with DPD.

> > So the first question: does any platform (that gcc supports) use the decimal
> > encoding for the significand (aka densely packed decimal encoding)?
> 
> DPD is also used on PowerPC (at least the 64-bit ABI), as these processors
> now have hardware decimal support.

Oh, this means that cohorts differs by platform.

> > Then, the rules about (non)propagation of some encodings blur the boundary
> > between values and representations in C. In particular this means that
> > different encodings are _not_ equivalent. Take for example the optimization
> > `x == C ? C + 0 : x` -> `x` for a constant C that is the unique member of
> > its cohort and that has non-canonical encodings (C is an infinity according
> > to the above analysis). Not sure about encoding of literals but the result
> > of addition `C + 0` is required to have canonical encoding. If `x` has
> > non-canonical encoding then the optimization is invalid.
> 
> In C, it is valid to choose any possible encoding. Concerning the IEEE 754
> conformance, this depends on the bindings. But IEEE 754 does not define the
> ternary operator. It depends whether C considers encodings before or
> possibly after optimizations (in the C specification, this does not matter,
> but when IEEE 754 is taken into account, there may be more restrictions).

The ternary operator is not important, let's replace it with `if`:

--
#include 

_Decimal32 f(_Decimal32 x)
{
_Decimal32 inf = (_Decimal32)INFINITY + 0;

if (x == inf)
return inf;
else
return x;
}
--

This is optimized into just `return x;`.

> > While at it, convertFormat is required to return canonical encodings, so
> > after `_Decimal32 x = ..., y = (_Decimal32)(_Decimal64)x;` `y` has to have
> > canonical encoding? But these casts are nop in gcc now.
> 
> A question is whether casts are regarded as explicit convertFormat
> operations 

N2478, a recent draft of C2x, lists bindings in F.3 and "convertFormat -
different formats" corresponds to "cast and implicit conversions". Is this
enough?

BTW "convertFormat - same format" corresponds to "canonicalize", so I guess a
cast to the same type is not required to canonicalize.

> or whether simplification is allowed as it does not affect the
> value, in which case the canonicalize() function would be needed here. 

Not sure what this means.

> And
> in any case, when 

[Bug c++/94149] __is_constructible doesn't know about C++20 parenthesized init for arrays

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-11
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
And of course __is_constructible(int[3], int, int) should work too.

[Bug c++/94149] New: __is_constructible doesn't know about C++20 parenthesized init for arrays

[redi at gcc dot gnu.org]

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

Bug ID: 94149
   Summary: __is_constructible doesn't know about C++20
parenthesized init for arrays
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

In C++20 this is well-formed:

  using T = int[2];
  T t(1, 2);

which means that std::is_constructible_v should be true.

The FE intrinsic gives the wrong answer, and the std::is_nothrow_constructible
library trait isn't going to work even if the intrinsic starts to give the
right answer.


i.e. this should compile with -std=gnu++2a

#include 

int main()
{
  using T = int[2];
  T t(1, 2);

  static_assert(__is_constructible(T, int, int));
  static_assert(std::is_constructible_v);
  static_assert(std::is_nothrow_constructible_v);

  return t[0];
}


a.cc: In function 'int main()':
a.cc:8:17: error: static assertion failed
8 |   static_assert(__is_constructible(T, int, int));
  | ^~~
a.cc:9:22: error: static assertion failed
9 |   static_assert(std::is_constructible_v);
  | ~^~~
a.cc:10:22: error: static assertion failed
   10 |   static_assert(std::is_nothrow_constructible_v);
  | ~^~~

[Bug libstdc++/94003] is_constructible seems to have sideeffects

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Depends on||41437

--- Comment #2 from Jonathan Wakely  ---
Almost certainly due to one of the bugs linked to PR 59002, probably PR 41437.

Inside the function template access checking doesn't work properly, so you can
use the private constructor, and the first instantiation of the trait gives the
wrong answer:

template  static bool why() {
  Class c;
  return std::is_constructible::value;
}

Then when the trait is rechecked later it has already been instantiated, and so
continues to give the wrong answer.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
[Bug 41437] No access control for classes in template functions

[Bug target/94145] Longcalls mis-optimize loading the function address

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 48021
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48021=edit
Example code

Compile with -mcpu=future -mpcrel -O3 to see the load of the address being
moved out of the loop.

[Bug c++/91484] Error message: std::is_constructible with incomplete types.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Jonathan Wakely  ---
The second example is:

#include 

using std::is_constructible_v;

template
struct basic_mixin
{
basic_mixin(T);
};

template
struct basic_iterator : basic_mixin
{
static_assert(is_constructible_v, Cur>);
};

template
struct view_interface
{
template,
 bool = is_constructible_v>
operator int() const;
};

struct iota_view : view_interface
{
};

using I = basic_iterator;
template struct basic_iterator;
static_assert(is_constructible_v);

GCC 9 rejects it (the static assertion fails) but doesn't diagnose the UB for
an incomplete type (probably due to PR 92067).

GCC 10 diagnoses the UB:

In file included from 91484.cc:1:
/home/jwakely/gcc/10/include/c++/10.0.1/type_traits: In instantiation of
'struct std::is_constructible,
basic_iterator >':
/home/jwakely/gcc/10/include/c++/10.0.1/type_traits:3107:25:   required from
'constexpr const bool std::is_constructible_v,
basic_iterator >'
91484.cc:21:21:   required by substitution of 'template > view_interface::operator int >() const
[with I = basic_iterator; bool  = ]'
/home/jwakely/gcc/10/include/c++/10.0.1/type_traits:901:30:   required from
'struct std::__is_constructible_impl, iota_view>'
/home/jwakely/gcc/10/include/c++/10.0.1/type_traits:906:12:   required from
'struct std::is_constructible, iota_view>'
/home/jwakely/gcc/10/include/c++/10.0.1/type_traits:3107:25:   required from
'constexpr const bool std::is_constructible_v,
iota_view>'
91484.cc:14:19:   required from 'struct basic_iterator'
91484.cc:30:17:   required from here
/home/jwakely/gcc/10/include/c++/10.0.1/type_traits:909:52: error: static
assertion failed: template argument must be a complete class or an unbounded
array
  909 |  
static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
  |
~~~^~~~
91484.cc:31:15: error: static assertion failed
   31 | static_assert(is_constructible_v);
  |   ^~~


So I think this is fixed.

[Bug middle-end/94146] [10 Regression] Merging functions with same bodies stopped working

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
If not already marked clearly as an ICF created thunk, I'd say it should be and
then inliner should take it into account (and only inline if the function
became very small or not at all).

[Bug middle-end/94146] [10 Regression] Merging functions with same bodies stopped working

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
My guess is that ICF works fine but then inliner inlines it back into the
thunk, which it didn't before.

[Bug middle-end/94146] [10 Regression] Merging functions with same bodies stopped working

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-03-11
   Target Milestone|--- |10.0
 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
Summary|Merging functions with same |[10 Regression] Merging
   |bodies stopped working  |functions with same bodies
   ||stopped working
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r10-3583-g562d1e9556777988ae46c5d1357af2636bc272ea

[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
commit r10-7129-gd42ff1d3b62521829d90e5b972baba2a0339e2bf
Author: Jakub Jelinek 
Date:   Wed Mar 11 18:35:13 2020 +0100

pdp11: Fix handling of common (local and global) vars [PR94134]

As mentioned in the PR, the generic code decides to put the a variable into
lcomm_section, which is a NOSWITCH section and thus the generic code
doesn't
switch into a particular section before using
ASM_OUTPUT{_ALIGNED{,_DECL}_}_LOCAL, on many targets that results just in
.lcomm (or for non-local .comm) directives which don't need a switch to
some
section, other targets put switch_to_section (bss_section) at the start of
that macro.
pdp11 doesn't do that (and doesn't have bss_section), and so emits the
lcomm/comm variables in whatever section is current (it has only
.text/.data
and for DEC assembler rodata).

The following patch fixes that by putting it always into data section, and
additionally avoids emitting an empty line in the assembly for the lcomm
vars.

2020-03-11  Jakub Jelinek  

PR target/94134
* config/pdp11/pdp11.c (pdp11_asm_output_var): Call
switch_to_section
at the start to switch to data section.  Don't print extra newline
if
.globl directive has not been emitted.

* gcc.c-torture/execute/pr94134.c: New test.

[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data

[pkoning at gcc dot gnu.org]

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

--- Comment #7 from pkoning at gcc dot gnu.org ---
Thanks Jakub.

Inspecting the generated assembly language is a sufficient check of the fix in
my view.  It's interesting that the test case shows the problem only with -O0. 
When optimizing, things are emitted in a different order (in particular, b then
a, I'm not sure why).

[Bug rtl-optimization/94148] New: The DF framework uses bb->aux, which is for passes only

[segher at gcc dot gnu.org]

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

Bug ID: 94148
   Summary: The DF framework uses bb->aux, which is for passes
only
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

df-core.c:df_worklist_dataflow_doublequeue uses bb->aux, clobbering it,
while that field is documented as

  /* Auxiliary info specific to a pass.  */
  PTR GTY ((skip (""))) aux;

and some passes that do use DF also use bb->aux.  This gives problems
with overlapping lifetimes.


This blocks fixing PR94042 properly.

[Bug rtl-optimization/94148] The DF framework uses bb->aux, which is for passes only

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Blocks||94042
   Target Milestone|--- |10.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
[Bug 94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[Bug tree-optimization/94131] [10 Regression] ICE: tree check: expected integer_cst, have plus_expr in get_len, at tree.h:5927 since r10-2814-g22fca489eaf98f26

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I see multiple issues:
1)
   if (base
  && DECL_P (base)
  && TREE_CODE (TREE_TYPE (base)) == ARRAY_TYPE
  && TYPE_SIZE_UNIT (TREE_TYPE (base))
  && poff.is_constant ())
{
  tree basetype = TREE_TYPE (base);
  tree size = TYPE_SIZE_UNIT (basetype);
  ++off;   /* Increment for the terminating nul.  */
  pdata->maxlen = fold_build2 (MINUS_EXPR, size_type_node, size,
   build_int_cst (size_type_node,
off));
  pdata->maxbound = pdata->maxlen;
}
One can't use TYPE_SIZE_UNIT this way during GIMPLE passes.  Gimplification
(gimplify_type_sizes) will create when needed temporary VAR_DECLs for the
sizes and during gimplification they are valid:
  char[0:D.1936] * a.1;
  char a[0:D.1936] [value-expr: *a.1];
...
  x.0 = x;
  _1 = (long int) x.0;
  _2 = _1 + -1;
  D.1936 = (sizetype) _2;
...
  a.1 = __builtin_alloca_with_align (D.1940, 8);
  _12 = &(*a.1)[0];
(and could be used the way the pass wants assuming the use is added somewhere
dominated by the setting of the var) but in the actual IL nothing actually
ensures those variables aren't optimized away as unused later on; typically
they'll be around only during -O0 or with -g if lucky they might have debug
statements for them:
  # DEBUG D#2 => (long int) x_1(D)
  # DEBUG D#1 => D#2 + -1
  # DEBUG D.1936 => (sizetype) D#1
but it isn't something that can be actually used in the IL for anything.  What
you could is track down the __builtin_alloca_with_align call that allocates the
memory for the array and derive something from the argument it is called with,
that is the actual byte size of the object.

2) another thing is as clearly maxlen and maxbound can be non-INTEGER_CSTs
(minlen is probably ok), then the code can't pass it to tree_int_cst_lt and
similar; there is one TREE_CODE (pdata->maxbound) != INTEGER_CST but no similar
checks

3) and the last one is that exactly for that TREE_CODE (pdata->maxbound) !=
INTEGER_CST case, IMNSHO the function needs to punt if the trees aren't say
operand_equal_p, if we have in a PHI "abcdef" and a VLA (or vice versa), unless
we'd have a SSA_NAME + const and VRP would tell us something, I'm afraid we
can't determine which of those two will be longer at runtime

[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr

[jakub at gcc dot gnu.org]

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

--- Comment #61 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #60)
> There's no wiggle room, we're definitely non-conforming.
> 
> Maybe the changes could be limited to -std=gnu++NN modes only, although
> Paolo argued strongly against that in this bug report.
> 
> It doesn't seem to be causing any issues for anybody though, so I'm not very
> motivated to "fix" our non-conformance by removing features (and probably
> breaking somebody's code).

I'd say we should (but perhaps for GCC11 only) remove those constexpr markings
and users that really need constexpr behavior will just need to use
__builtin_sinh etc. instead which ought to be constexpr because it is a
builtin.

[Bug c++/94147] mangling of lambdas in initializers is wrong

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-03-11

[Bug c++/94147] New: mangling of lambdas in initializers is wrong

[nathan at gcc dot gnu.org]

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

Bug ID: 94147
   Summary: mangling of lambdas in initializers is wrong
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

inline auto var = [] (int) {};

should mangle the lambda as _ZN3varMUlE_clEv

likewise for static member variables

[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr

[redi at gcc dot gnu.org]

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

--- Comment #60 from Jonathan Wakely  ---
There's no wiggle room, we're definitely non-conforming.

Maybe the changes could be limited to -std=gnu++NN modes only, although Paolo
argued strongly against that in this bug report.

It doesn't seem to be causing any issues for anybody though, so I'm not very
motivated to "fix" our non-conformance by removing features (and probably
breaking somebody's code).

[Bug rtl-optimization/94119] MIPS: Invalid use of branch delay slots leading to corrupt jump

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
> The addiu s0,s0,0 instruction must only be issued once but instead is in
> several places. This leads to an invalid call at 9c.

Duplicating the instruction is not a problem per se if it is executed only once
on any execution path.  Are you sure that the problem is for the call at 9c?

>   8c: 3c10lui s0,0x0
>   8c: R_MIPS_HI16 memcmp_
>   90: 24060006li  a2,6
>   94: 27a50014addiu   a1,sp,20
>   98: 2610addiu   s0,s0,0
>   98: R_MIPS_LO16 memcmp_
>   9c: 0200f809jalrs0

AFAICS there is only one "addiu s0,s0,0" executed after the "lui s0,0x0" in
this basic block.  Doesn't the problem occur for the call in the following
basic block instead?

[Bug tree-optimization/94131] [10 Regression] ICE: tree check: expected integer_cst, have plus_expr in get_len, at tree.h:5927 since r10-2814-g22fca489eaf98f26

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Slightly adjusted testcase that still ICEs the same way, without warnings:

void
foo (int x)
{
  char a[x];
  int b = (int) (__INTPTR_TYPE__) [0];

  __builtin_memset (a, '\0', sizeof (a));
  __builtin_printf ("%s", b ? [0] : "");
}

[Bug bootstrap/93962] bootstrap fails with gcc/value-prof.c:268:28 : error: format '%lld' expects argument of type 'long long int', but argument 3 hastype 'int'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #16 from Jakub Jelinek  ---
.

[Bug middle-end/94146] New: Merging functions with same bodies stopped working

[antoshkka at gmail dot com]

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

Bug ID: 94146
   Summary: Merging functions with same bodies stopped working
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the example:

extern int x , y;

int ternary(int i) { return i > 0 ? x : y; }
int ternary2(int i) { return i > 0 ? x : y; }


GCC9 was merging the functions with -O2:

ternary2(int):
jmp ternary(int)


With GCC10 merging at -O2 is missing and function bodies are duplicated even
for very big functions: https://godbolt.org/z/2kH8VR

[Bug target/94145] New: Longcalls mis-optimize loading the function address

[meissner at gcc dot gnu.org]

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

Bug ID: 94145
   Summary: Longcalls mis-optimize loading the function address
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

I'm working on a feature where we convert some/all built-in function calls to
use the longcall sequence.  I discovered that the compiler is mis-optimizing
loading up the function address.  This showed up in the Spec 2017 wrf_r
benchmark where I replaced some 60,000 direct calls to longcalls.

In particular, the PowerPC backend is not marking the load of the function
address as being volatile.  This allows the compiler to move the load out of a
loop.

However with the current ELF semantics, you don't want to do this because the
function address changes.  The first call to the function, the address is the
PLT stub, but in subsequent calls it is the address of the function itself
after the shared library is loaded.

In addition, because UNSPECs are used, the compiler is likely to store the
function address in the stack and reload it.  Given that the UNSPEC is just a
load, it would be better not to optimize this to doing the extra load/store.

In fixing the linker bug that this feature uncovered, Alan Modra has a simple
patch to fix it.

[Bug target/94123] [10 regression] r10-1734, SVN r273240, causes gcc.target/powerpc/pr87507.c to fail

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[10 regression] r10-7093|[10 regression] r10-1734,
   |causes  |SVN r273240, causes
   |gcc.target/powerpc/pr87507. |gcc.target/powerpc/pr87507.
   |c to fail   |c to fail
 CC||segher at gcc dot gnu.org

--- Comment #4 from seurer at gcc dot gnu.org ---
g:b18081df8cca5f2306e99709fa2c06b9cbeea8d0, r10-1734, SVN r273240

Sorry about the confusion with the reverted patch.

The current code generated for this test case is really messed up.  Prior to
r10-1734 this is what was generated for gcc.target/powerpc/pr87507.c

.cfi_startproc
cmpdi 0,3,0
beqlr 0
std 5,0(4)
std 6,8(4)
std 5,16(4)
std 6,24(4)
blr

Starting with r10-1734 (and still today) this is what is generated:

.cfi_startproc
cmpdi 0,3,0
beqlr 0
std 30,-16(1)
std 31,-8(1)
.cfi_offset 30, -16
.cfi_offset 31, -8
mr 30,6
mr 31,5
addi 9,4,16
mr 10,30
mr 11,31
std 31,0(4)
std 30,8(4)
std 11,0(9)
std 10,8(9)
ld 30,-16(1)
ld 31,-8(1)
.cfi_restore 31
.cfi_restore 30
blr

All sorts of extra moves, loads, and stores.

Options used:  -O2 -mdejagnu-cpu=power8

[Bug testsuite/94019] [9 regression] gcc.dg/vect/vect-over-widen-17.c fails starting with g:370c2ebe8fa20e0812cd2d533d4ed38ee2d37c85, r9-1590

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Oh sorry, we are awaiting a backport.  Never mind.

[Bug testsuite/94019] [9 regression] gcc.dg/vect/vect-over-widen-17.c fails starting with g:370c2ebe8fa20e0812cd2d533d4ed38ee2d37c85, r9-1590

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
Looks like this could be closed, Kewen?

[Bug target/94144] New: ICE on aarch64-linux-gnu: in aarch64_print_operand at gcc/config/aarch64/aarch64.c:9528

[andrea.corallo at arm dot com]

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

Bug ID: 94144
   Summary: ICE on aarch64-linux-gnu: in aarch64_print_operand at
gcc/config/aarch64/aarch64.c:9528
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrea.corallo at arm dot com
  Target Milestone: ---

The compiler get ICE in final when compiling at -O3 the code below.

Note: this appears to be a regression to gcc 9.

---

int a, b, z;
int c(int d, int e) { return d && e > 0 && d > 5 - e ? 0 : d + e; }
int k();
void h(int);
void f(short d) {
  int g = !(0 < d);
  h(d);
  if (b) {
unsigned i[1];
i[0] = g = 0;
for (; g <= 8; g++)
  d || k();
if (c(!(i[0] <= z) >= d, d) != a)
  k();
  }
}

---

during RTL pass: final
test.c: In function ‘f’:
test.c:20:1: internal compiler error: in aarch64_print_operand, at
config/aarch64/aarch64.c:9528
   20 | }
  | ^
0xde435f aarch64_print_operand
../../gcc/config/aarch64/aarch64.c:9528
0x85acfb output_operand(rtx_def*, int)
../../gcc/final.c:4051
0x85b76f output_asm_insn(char const*, rtx_def**)
../../gcc/final.c:3944
0x85f06f output_asm_insn(char const*, rtx_def**)
../../gcc/final.c:3840
0x85f06f final_scan_insn_1
../../gcc/final.c:3106
0x85f537 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/final.c:3152
0x85f7ff final_1
../../gcc/final.c:2020
0x85ff73 rest_of_handle_final
../../gcc/final.c:4658
0x85ff73 execute
../../gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/93709] [10 regression] fortran.dg/minlocval_4.f90 fails on power 9 after r10-4161

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-11
 Ever confirmed|0   |1

--- Comment #7 from Bill Schmidt  ---
Confirmed, since fixed on trunk.  Do we want any backports?

[Bug target/94095] Modifier 'a' do not work as described

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Martin Liška from comment #3)
I did not notice the git to bugzilla comment connection was not working until
yesterday and then forgot to update this one.  THanks for doing it.

[Bug fortran/94129] Using almost any openacc !$acc directive causes ICE "compressed stream: data error"

[doko at debian dot org]

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

--- Comment #7 from Matthias Klose  ---
$ gfortran-10 -flto -c program.f90

$ readelf -SW program.o  | grep lto_.lto
  [ 6] .gnu.lto_.lto.c7eb6f75a94ea29a PROGBITS cc
08 00   E  0   0  1

$ objdump -s -j .gnu.lto_.lto.c7eb6f75a94ea29a program.o 

program.o: file format elf64-x86-64

Contents of section .gnu.lto_.lto.c7eb6f75a94ea29a:
  0900 01000100

Yes, I get the very same stacktrace ending in lto_uncompression_zlib.

[Bug libfortran/94143] New: [9/10 Regression] Asynchronous execute_command_line() breaks following synchronous calls

[trnka at scm dot com]

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

Bug ID: 94143
   Summary: [9/10 Regression] Asynchronous execute_command_line()
breaks following synchronous calls
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trnka at scm dot com
  Target Milestone: ---

Since PR90038 introduced a SIGCHLD handler into execute_command_line(), calling
an asynchronous execute_command_line(wait=.false.) breaks all subsequent
synchronous calls (no matter if those are through
execute_command_line(wait=.true.) or through various libraries), because the
signal handler stays around forever and indiscriminately reaps any child
processes.

The result is that the internal wait() at the end of system()-like calls fails
with ECHILD if the signal handler fires earlier and does a wait() on that
process.

Given that this is a race between the signal handler and the synchronous
wait(), it's somewhat tricky to reproduce reliably. The following test case
triggers it on my machine

program asyncexec
   implicit none

   integer :: i

!$omp parallel default(shared)
!$omp single
   call execute_command_line('sleep 30', wait=.false.)
   do i = 1, 10
  write(*,*) i
  call execute_command_line('/bin/true')
   end do
!$omp end single
!$omp end parallel
end program

This typically leads to the following error on the first or second iteration:

Fortran runtime error: EXECUTE_COMMAND_LINE: Termination status of the
command-language interpreter cannot be obtained

Error termination. Backtrace:
#0  0x7f979747c5fa in set_cmdstat
at ../../../libgfortran/intrinsics/execute_command_line.c:63
#1  0x7f979747c829 in set_cmdstat
at ../../../libgfortran/intrinsics/execute_command_line.c:58
#2  0x7f979747c829 in execute_command_line
at ../../../libgfortran/intrinsics/execute_command_line.c:133

The issue has nothing to do with OpenMP, I'm just using it to get multiple
concurrent threads to maximize the chance that the signal handler will run on a
different thread before the forking thread has a chance to call wait(). In real
life, this issue affects MPI applications because MPI libraries typically spawn
some background event-handling threads even if the program itself is
single-threaded.

I don't see a way to workaround this in user code, so I'd suggest removing the
offending SIGCHLD handler as a quick "fix". That'll leave zombie processes
around, but those are mostly harmless. IMHO there are two possible proper
solutions:

1) Spawn a dedicated thread to specifically wait for the PID launched by the
asynchronous call, instead of a blanket wait(-1).
2) Record all asynchronously launched PIDs in a global list. The SIGCHLD
handler would then extract the PID from siginfo and consult the list to see
whether it should call wait().

Option #1 seems easier to implement to me. I can try to come up with a patch if
desired.

[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-03-11
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #6 from Jakub Jelinek  ---
Created attachment 48020
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48020=edit
gcc10-pr94134.patch

Untested fix.  I have no way to actually test it though.
The changes in the emitted assembly on the testcase in the patch are:
@@ -1,8 +1,7 @@
 .text
+.data
 .even
-
 _a: .=.+ 02
-.data
 .even
 _b:
 .word   01

[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Good, now I can see a similar issue:

$ gcc  -o cache_locality_test -L. libfolly.so -pthread CacheLocalityTest.o
-shared
/usr/bin/ld: /tmp/cache_locality_test.Kz3DE7.ltrans0.ltrans.o: relocation
R_X86_64_TPOFF32 against `_ZL10testingCpu' can not be used when making a shared
object; recompile with -fPIC
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status

and I can confirm adding -fPIC helps.

[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||pkoning at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
The generic code wants to emit this into lcomm_section:
1203  if (ADDR_SPACE_GENERIC_P (as)
1204  && !DECL_THREAD_LOCAL_P (decl)
1205  && !(prefer_noswitch_p && targetm.have_switchable_bss_sections)
1206  && bss_initializer_p (decl))
1207{
1208  if (!TREE_PUBLIC (decl)
1209  && !((flag_sanitize & SANITIZE_ADDRESS)
1210   && asan_protect_global (decl)))
1211return lcomm_section;
1212  if (bss_noswitch_section)
1213return bss_noswitch_section;
1214}
which is a NOSWITCH section, see
https://gcc.gnu.org/ml/gcc-patches/2006-02/msg01857.html
pdp11 defines ASM_OUTPUT_ALIGNED_LOCAL to pdp11_asm_output_var (similarly for
ASM_OUTPUT_ALIGNED_COMMON), but as both are NOSWITCH sections, I think it is
wrong to emit it in whatever section is currently active.

[Bug c++/94132] Valid usage of flexible array member failing to compile

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Blocks||69698
 Resolution|--- |INVALID

--- Comment #5 from Martin Sebor  ---
Right, the code is invalid according to the C rules.  It's accepted by the C
front end with a pedantic warning.  It's intentionally rejected by the C++
front-end which supports fewer of the GCC extensions.  The zero-length array
extension can be used in this context instead, though accessing elements of the
zero-length array may be diagnosed.  (In both cases, GCC assumes that the array
doesn't overlap other members so accesses to its elements are undefined.)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69698
[Bug 69698] [meta-bug] flexible array members

[Bug c++/69698] [meta-bug] flexible array members

[msebor at gcc dot gnu.org]

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

Bug 94132 Summary: Valid usage of flexible array member failing to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94132

   What|Removed |Added

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

[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
Ok, I see in the .s file:

$ grep _ZN5folly14AccessSpreaderISt6atomicE8cpuCacheE
cache_locality_test.ltrans0.s
leaq_ZN5folly14AccessSpreaderISt6atomicE8cpuCacheE@tpoff, %rbp
leaq_ZN5folly14AccessSpreaderISt6atomicE8cpuCacheE@tpoff, %rbx

So the symbols is a TLS static variable:
$ grep cpuCache *.ii
  static __thread CpuCache cpuCache;

Can you please reduce the .ii file with creduce:
https://gcc.gnu.org/bugs/minimize.html
?

That should be doable by grepping for the:
 unresolvable R_X86_64_TPOFF32 relocation against symbol
`_ZN5folly14AccessSpreaderISt6atomicE8cpuCacheE'

error message.

[Bug rtl-optimization/94119] MIPS: Invalid use of branch delay slots leading to corrupt jump

[d.dorau at avm dot de]

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

--- Comment #2 from d.dorau at avm dot de ---
(In reply to Eric Botcazou from comment #1)
> Please post the output of 'gcc -v' for the affected compiler.

We could reproduce this with several gcc builds of which I post the output
below:

1. buildroot cross compile toolchain (which we used for bisecting)

Using built-in specs.
COLLECT_GCC=/home/ddorau/gu/GU_PSQ19/tmp/sysroot/b831bdc30cd51d5f4ae435bcd40a3b66260fe956/bin/mips-buildroot-linux-musl-gcc.br_real
COLLECT_LTO_WRAPPER=/home/ddorau/gu/GU_PSQ19/tmp/sysroot/b831bdc30cd51d5f4ae435bcd40a3b66260fe956/bin/../libexec/gcc/mips-buildroot-linux-musl/8.3.0/lto-wrapper
Target: mips-buildroot-linux-musl
Configured with: ./configure --prefix=/GU/GCC_grx5_build/build/build/host
--sysconfdir=/GU/GCC_grx5_build/build/build/host/etc --enable-static
--target=mips-buildroot-linux-musl
--with-sysroot=/GU/GCC_grx5_build/build/build/host/mips-buildroot-linux-musl/sysroot
--enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--disable-decimal-float --with-gmp=/GU/GCC_grx5_build/build/build/host
--with-mpc=/GU/GCC_grx5_build/build/build/host
--with-mpfr=/GU/GCC_grx5_build/build/build/host --with-pkgversion='Buildroot
2018.11.4-ga8fcc4740' --with-bugurl=http://bugs.buildroot.net/ --disable-libmpx
--disable-libquadmath --disable-libsanitizer --enable-tls --enable-plugins
--enable-lto --disable-libmudflap --enable-threads --without-isl
--without-cloog --with-float=soft --with-arch=interaptiv --with-abi=32
--with-nan=legacy --enable-languages=c,c++
--with-build-time-tools=/GU/GCC_grx5_build/build/build/host/mips-buildroot-linux-musl/bin
--enable-shared --enable-libgomp
Thread model: posix
gcc version 8.3.0 (Buildroot 2018.11.4-ga8fcc4740)

2. Ubuntu mips cross compiler, gcc 7.5 (for verification)

# mips-linux-gnu-gcc-7 -v
Using built-in specs.
COLLECT_GCC=mips-linux-gnu-gcc-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/mips-linux-gnu/7/lto-wrapper
Target: mips-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support
--enable-plugin --with-system-zlib --enable-multiarch --disable-werror
--enable-multilib --with-arch-32=mips32r2 --with-fp-32=xx --with-lxc1-sxc1=no
--enable-targets=all --with-arch-64=mips64r2 --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=mips-linux-gnu
--program-prefix=mips-linux-gnu- --includedir=/usr/mips-linux-gnu/include
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) 

3. Ubuntu mips cross compiler, gcc 8.3 (for verification)

# mips-linux-gnu-gcc-8 -v
Using built-in specs.
COLLECT_GCC=mips-linux-gnu-gcc-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/mips-linux-gnu/8/lto-wrapper
Target: mips-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.3.0-6ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support
--enable-plugin --with-system-zlib --disable-libphobos --enable-multiarch
--disable-werror --enable-multilib --with-arch-32=mips32r2 --with-fp-32=xx
--with-lxc1-sxc1=no --enable-targets=all --with-arch-64=mips64r2
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=mips-linux-gnu --program-prefix=mips-linux-gnu-
--includedir=/usr/mips-linux-gnu/include
Thread model: posix
gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1~18.04.1)

[Bug c/94142] typeof enum member appears to give wrong signedness

[matthew.fernandez at gmail dot com]

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

Matthew Fernandez  changed:

   What|Removed |Added

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

--- Comment #2 from Matthew Fernandez  ---
Ah I see. I had missed the subtlety in the standard there. Thanks for
explaining and for the pointer to the docs, Jonathan. I'll close as INVALID.

[Bug sanitizer/85777] [8/9/10 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[vincent-gcc at vinc17 dot net]

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

--- Comment #14 from Vincent Lefèvre  ---
(In reply to Vincent Lefèvre from comment #1)
> I've cleaned up the testcase:
> 
> int d;
> int h(void);
> void e(void)
> {
>   int f[2];
>   int g = 0;
>   if (d)
> g++;
>   if (d == 1)
> f[g++] = 2;
>   (void) (f[0] || (g && h()));
> }
[...]
> but
> 
> cventin% gcc-snapshot -Werror=uninitialized -Werror=maybe-uninitialized -O2
> -c file.c -fsanitize=undefined
> cventin%

I now get a warning/error as expected:

file.c: In function ‘e’:
file.c:11:12: error: ‘f[0]’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
   11 |   (void) (f[0] || (g && h()));
  |   ~^~~
cc1: some warnings being treated as errors

with gcc-10 (Debian 10-20200304-1) 10.0.1 20200304 (experimental) [master
revision 0b0908c1f27:cb0a7e0ca53:94f7d7ec6ebef49a50da777fd71db3d03ee03aa0].

But here's a new testcase:

int foo1 (void);
int foo2 (int);

int bar (void)
{
  int i;
  auto void cf (int *t) { foo2 (i); }
  int t __attribute__ ((cleanup (cf)));

  t = 0;

  if (foo1 ())
i = foo1 ();

  i = ! foo1 () || i;
  foo2 (i);

  return 0;
}

What's strange is that if I change the line

  i = ! foo1 () || i;

to

  i = foo1 () || i;

(i.e. if I just remove the "!", though this shouldn't change anything since GCC
does not have any knowledge on what foo1 returns), I get an error as expected:

uninit-test.c: In function ‘bar’:
uninit-test.c:15:15: error: ‘FRAME.1.i’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
   15 |   i = foo1 () || i;
  |   ^~~~
cc1: some warnings being treated as errors

[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated

[laurent.stacul at gmail dot com]

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

--- Comment #9 from Laurent Stacul  ---
Here is the command line:

g++ -E 
-DFOLLY_XLOG_STRIP_PREFIXES=\"/home/docker/development/opensource-pack-builder/components/folly/BUILD/folly-2020.03.02.00:/home/docker/development/opensource-pack-builder/components/folly/BUILD/folly-2020.03.02.00/_build_shared\"
-D_GNU_SOURCE -D_REENTRANT -I../ -I.
-I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/Boost/latest/osp/include
-I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/DoubleConversion/latest/osp/include
-I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/Gflags/latest/osp/include
-I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/Glog/latest/osp/include
-I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/Libevent/latest/osp/include
-I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/OpenSSL/latest/osp/include
-I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/ZLib/latest/osp/include
-I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/BZip2/latest/osp/include
-I/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/Aio/latest/osp/include
-isystem
/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/Gmock/latest/osp/include
-isystem
/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/Gtest/latest/osp/include
-isystem
/home/docker/development/opensource-pack-builder/components/folly/DEPS/osp/Fmt/latest/osp/include
-DNDEBUG -O3 -flto -ffat-lto-objects -fuse-linker-plugin -std=gnu++20
-fno-working-directory -ggdb3 -Wno-error=maybe-uninitialized
-Wno-error=shadow=compatible-local -Wno-error=array-bounds
-Wno-error=stringop-overflow -O2 -g -DNDEBUG -fPIE   -g -std=gnu++2a
-finput-charset=UTF-8 -fsigned-char -Wall -Wno-deprecated
-Wno-deprecated-declarations -Wno-sign-compare -Wno-unused -Wunused-label
-Wunused-result -Wshadow-compatible-local -Wno-noexcept-type -faligned-new
-fopenmp -std=gnu++14 -MD -MT
CMakeFiles/cache_locality_test.dir/folly/concurrency/test/CacheLocalityTest.cpp.o
-MF
CMakeFiles/cache_locality_test.dir/folly/concurrency/test/CacheLocalityTest.cpp.o.d
-o
CMakeFiles/cache_locality_test.dir/folly/concurrency/test/CacheLocalityTest.cpp.o
-c ../folly/concurrency/test/CacheLocalityTest.cpp

[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
(In reply to Laurent Stacul from comment #7)
> Created attachment 48019 [details]
> preprocessed sources

Thanks and last missing piece is command line how lityTest.cpp.o is compiled?

[Bug c/94142] typeof enum member appears to give wrong signedness

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Matthew Fernandez from comment #0)
> This seems surprising to me. Shouldn't x and y have the same signedness as
> they're both the type of the enum? It seems like somehow the type of an enum
> member differs from the type of the enum itself.

Because that's what C says:
"The identifiers in an enumerator list are declared as constants that have type
int"

So as the warning tells you, y has type int. Which is because A has type int,
so __typeof__(A) is int, i.e. not the same as t.

As documented at
https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html
your enumeration type has an underlying type of unsigned int, because it has no
enumeration constants with negative values.

Although your example has no enumeration constants that could cause a problem,
this similar example shows a case where the warning is correct:

typedef enum { A, B, C = -1u } t;
t x = C;
__typeof__(A) y = -1;

int main() {
  if (x == y)
return 0;

  return 1;
}

This causes an implicit conversion that alters the values, which is ecactly
what -Wsign-compare is designed to warn about.

> Some cursory testing suggests to me this behaviour extends back to at least
> the GCC 4 series. I could not find a version of Clang that has this
> behaviour.

Clang doesn't warn about my example above, despite having the same "wrong"
result.

[Bug c/94142] New: typeof enum member appears to give wrong signedness

[matthew.fernandez at gmail dot com]

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

Bug ID: 94142
   Summary: typeof enum member appears to give wrong signedness
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthew.fernandez at gmail dot com
  Target Milestone: ---

Consider the following code:

typedef enum { A, B } t;
t x;
__typeof__(A) y;

int foo() {
  if (x == y)
return 0;

  return 1;
}

With GCC 9.2.0, compiling with -Wsign-compare has the following to say:

$ gcc-9.2.0 -std=gnu11 -c -Wsign-compare goo.c
foo.c: In function 'foo':
foo.c:6:9: warning: comparison of integer expressions of different
sightedness: 't' {aka 'enum '} and 'int' [-Wsign-compare]
6 |   if (x == y)
  | ^~

This seems surprising to me. Shouldn't x and y have the same signedness as
they're both the type of the enum? It seems like somehow the type of an enum
member differs from the type of the enum itself. Either way, the warning seems
spurious here. Maybe #66773 is relevant.

Some cursory testing suggests to me this behaviour extends back to at least the
GCC 4 series. I could not find a version of Clang that has this behaviour.

[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated

[laurent.stacul at gmail dot com]

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

--- Comment #7 from Laurent Stacul  ---
Created attachment 48019
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48019=edit
preprocessed sources

[Bug c++/94141] New: c++20 rewritten operator== recursive call mixing friend and external operators for template class

[glisse at gcc dot gnu.org]

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

Bug ID: 94141
   Summary: c++20 rewritten operator== recursive call mixing
friend and external operators for template class
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

(reduced from a user of boost/operators.hpp)

template  class A;
template  bool operator==(const A&, int) { return false; }

template  class A {
  friend bool operator==(int y, const A& x) { return x == y; }
};

int main(){
  A q;
  q==3;
  3==q;
}

$ g++ -std=c++2a a.c -Wall && ./a.out
a.c: In instantiation of 'bool operator==(int, const A&)':
a.c:10:6:   required from here
a.c:5:56: warning: in C++20 this comparison calls the current function
recursively with reversed arguments
5 |   friend bool operator==(int y, const A& x) { return x == y; }
  |  ~~^~~~
zsh: segmentation fault  ./a.out

If I make both operators friends, or move both outside, gcc is happy, but in
this mixed case, it doesn't seem to want to use the first operator== and
prefers the rewritten second operator==. Of course removing the second
operator== completely also works.
Clang is fine with this version of the code.

I have trouble parsing the standard wording, but IIRC one of the principles
when adding <=> was that explicitly written functions should have priority over
new, invented ones.

Bug 93807 is the closest I could find.

[Bug rtl-optimization/94119] MIPS: Invalid use of branch delay slots leading to corrupt jump

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-03-11
 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org

--- Comment #1 from Eric Botcazou  ---
Please post the output of 'gcc -v' for the affected compiler.

[Bug rtl-optimization/90378] [9/10 regression] -Os -flto miscompiles 454.calculix after r266385 on Arm

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

   Last reconfirmed||2020-03-11
 CC||clyon at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #7 from Christophe Lyon  ---
I am able to reproduce the failure with the same commit mentioned by Maxim in
comment #3. Using a more recent trunk (Feb 21, 2020) made the problem
disappear.

I'm using -Os -flto -mthumb, with a GCC bootstrapped on an armv7 machine
(cortex-a15, NVidia jetson-tk1).

Like Maxim said in comment #1, if I copy the binary and runtime libs
(libgfortran, etc) to an ARMv8 machine with AArch32 mode support, the
execution is successful.

The failure looks like this:

[...]
increment 1 attempt 1 
increment size= 5.00e-02
sum of previous increments=0.00e+00

ilin=0
iteration 1

Segmentation fault


Under gdb:
Program received signal SIGSEGV, Segmentation fault.
0xb6deab58 in ?? () from /home/christophe.lyon/calculix.broken/lib/libc.so.6
(gdb) bt
#0  0xb6deab58 in ?? () from
/home/christophe.lyon/calculix.broken/lib/libc.so.6
#1  0xb6deb01e in ?? () from
/home/christophe.lyon/calculix.broken/lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


When using valgrind (3.11.0), several errors are reported before reaching the
point where the code normally crashes, but execution continues:

[...]
increment 1 attempt 1 
increment size= 5.00e-02
sum of previous increments=0.00e+00

ilin=0
iteration 1

largest residual force= 203.899659
no convergence

iteration 2

Most of the errors are "Invalid write of size 4" or "Use of uninitialised value
of size 4" in bpabi.S lines 256-259, which correspond to macro expansion of
push_for_divide and pop_for_divide in aeabi_uldivmod. The errors are about
reading/writing in the stack.


When using valgrind (3.13.0) on ARMv8 hardware, it does not report any error,
so I'm puzzled: was it a bug in valgrind-3.11.0, or are some glibc ifuncs
changing the behaviour?


Anyway, I still don't know where the program crashes on ARMv7 hardware.

[Bug middle-end/94120] [OpenACC] ICE in gimplify_adjust_omp_clauses_1 for 'declare' for variable outside scope

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #3)
> Patch for Fortran:
>   https://gcc.gnu.org/pipermail/gcc-patches/current/541774.html

Patch for C + C++:
https://gcc.gnu.org/pipermail/gcc-patches/current/541840.html

See also PR 94140 for declare and 'class' and OpenACC's Issue 288.

[Bug c++/93699] Invalid operator== (returning non-bool type) candidate

[laurent.stacul at gmail dot com]

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

--- Comment #4 from Laurent Stacul  ---
Sorry for this, I will follow your recommendations next time.

[Bug fortran/94129] Using almost any openacc !$acc directive causes ICE "compressed stream: data error"

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Matthias Klose from comment #3)
> $ gfortran-10 -v -fopenacc program.f90 2>&1 |grep zstd
> Supported LTO compression algorithms: zlib zstd
> Supported LTO compression algorithms: zlib zstd
> 
> afaics both builds are correctly configured.

Then you can dump lto header in a .o file:

$ gcc -flto -c bss.c
$ readelf -SW bss.o  | grep lto_.lto
  [ 6] .gnu.lto_.lto.2cfeb5fb4c8095f PROGBITS 62
08 00   E  0   0  1

$ objdump -s -j .gnu.lto_.lto.2cfeb5fb4c8095f bss.o

bss.o: file format elf64-x86-64

Contents of section .gnu.lto_.lto.2cfeb5fb4c8095f:
  0900 01000100

that ending 0100 is zstd == 1.

[Bug fortran/94129] Using almost any openacc !$acc directive causes ICE "compressed stream: data error"

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Btw, your backtrace ends up in lto_uncompression_zlib but Matthias shows the
Ubuntu packages have zstd enabled.  I'd have expected only zstd compressed
sections there.  Matthias, can you reproduce the issue?

[Bug fortran/94129] Using almost any openacc !$acc directive causes ICE "compressed stream: data error"

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
So I tried it with the SUSE GCC 10 packages and it works fine (I've
double-checked nvptx is offloaded).  But my packages are only configured for
zlib ...
(I'm testing on Leap 15.1 which doesn't have zstd I think).

[Bug tree-optimization/94130] [8/9/10 Regression] Unintended result with optimization option when assigning two structures, memset and 0

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 48018
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48018=edit
gcc10-pr94130.patch

Untested fix.

[Bug fortran/94129] Using almost any openacc !$acc directive causes ICE "compressed stream: data error"

[doko at debian dot org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #3 from Matthias Klose  ---
$ gfortran-10 -v -fopenacc program.f90 2>&1 |grep zstd
Supported LTO compression algorithms: zlib zstd
Supported LTO compression algorithms: zlib zstd

afaics both builds are correctly configured.

[Bug c++/94140] New: [OpenACC] declare directive in class currently rejected

[burnus at gcc dot gnu.org]

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

Bug ID: 94140
   Summary: [OpenACC] declare directive in class currently
rejected
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc, rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

The following test case gives:
   error: ‘foo::A’ is not a variable in ‘map’ clause

>From the wording, it seems to be valid and pg++ accepts and runs it (only tried
on shared memory).


#include 
#include 

class foo {
  public:
int A[3];
#pragma acc declare copyin(A)
};

int main () {
  class foo var;
  if (!acc_is_present (var.A, sizeof (var.A)))
abort ();
  return 0;
}

[Bug driver/93645] Support -fuse-ld=/absolute/path/to/ld

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
   Last reconfirmed||2020-03-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Version|unknown |10.0
 CC||marxin at gcc dot gnu.org
   Keywords||patch

[Bug tree-optimization/94130] [8/9/10 Regression] Unintended result with optimization option when assigning two structures, memset and 0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Even simpler testcase:
int
main ()
{
  int a[8];
  char *b = __builtin_memset (a, 0, sizeof (a));
  a[0] = 1;
  a[1] = 2;
  a[2] = 3;
  if (b != (char *) a)
__builtin_abort ();
  else
asm volatile ("" : : "g" (a) : "memory");
  return 0;
}

[Bug tree-optimization/94130] [8/9/10 Regression] Unintended result with optimization option when assigning two structures, memset and 0

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
And the b.d = 0; store isn't needed either.

[Bug tree-optimization/94130] [8/9/10 Regression] Unintended result with optimization option when assigning two structures, memset and 0

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Slightly reduced testcase:
struct A { char a[6]; void *b; };
struct B { unsigned int c, d; };

static void __attribute__((noipa))
foo (struct A *x)
{
  struct B *b = (struct B *) x->b;
  if (b->c != 1234 || b->d)
__builtin_abort ();
}

int
main ()
{
  struct A a;
  struct B b;
  __builtin_memset (, 0, sizeof (a));
  __builtin_strncpy (a.a, "Hello", sizeof (a.a));
  a.b = __builtin_memset (, 0, sizeof (b));
  b.c = 1234;
  b.d = 0;
  foo ();
  return 0;
}

[Bug target/89346] Unnecessary EVEX encoding

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
commit r10-7078-g6733ecaf3fe77871d86bfb36bcda5497ae2aaba7
Author: H.J. Lu 
Date:   Sun Mar 8 05:01:03 2020 -0700

gcc.target/i386/pr89229-3c.c: Include "pr89229-3a.c"

PR target/89229
PR target/89346
* gcc.target/i386/pr89229-3c.c: Include "pr89229-3a.c", instead
of "pr89229-5a.c".

[Bug target/91598] [8/9 regression] 60% speed drop on neon intrinsic loop

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #6 from Martin Liška  ---
commit r10-7073-g0b8393221177617f19e7c5c5c692b8c59f85fffb
Author: Wilco Dijkstra 
Date:   Fri Mar 6 18:29:02 2020 +

[AArch64] Use intrinsics for widening multiplies (PR91598)

Inline assembler instructions don't have latency info and the scheduler
does
not attempt to schedule them at all - it does not even honor latencies of
asm source operands.  As a result, SIMD intrinsics which are implemented
using
inline assembler perform very poorly, particularly on in-order cores.
Add new patterns and intrinsics for widening multiplies, which results in a
63% speedup for the example in the PR, thus fixing the reported regression.

gcc/
PR target/91598
* config/aarch64/aarch64-builtins.c (TYPES_TERNOPU_LANE): Add
define.
* config/aarch64/aarch64-simd.md
(aarch64_vec_mult_lane): Add new insn for widening lane
mul.
(aarch64_vec_mlal_lane): Likewise.
* config/aarch64/aarch64-simd-builtins.def: Add intrinsics.
* config/aarch64/arm_neon.h:
(vmlal_lane_s16): Expand using intrinsics rather than inline asm.
(vmlal_lane_u16): Likewise.
(vmlal_lane_s32): Likewise.
(vmlal_lane_u32): Likewise.
(vmlal_laneq_s16): Likewise.
(vmlal_laneq_u16): Likewise.
(vmlal_laneq_s32): Likewise.
(vmlal_laneq_u32): Likewise.
(vmull_lane_s16): Likewise.
(vmull_lane_u16): Likewise.
(vmull_lane_s32): Likewise.
(vmull_lane_u32): Likewise.
(vmull_laneq_s16): Likewise.
(vmull_laneq_u16): Likewise.
(vmull_laneq_s32): Likewise.
(vmull_laneq_u32): Likewise.
* config/aarch64/iterators.md (Vcondtype): New iterator for lane
mul.
(Qlane): Likewise.

[Bug c++/93729] [concepts] binding bit-field to lvalue reference in requires expression should be SFINAE

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
commit r10-7080-g5e1b4e60c1823115ba7ff0e8c4b35f6058ad9969
Author: Patrick Palka 
Date:   Tue Mar 3 12:27:33 2020 -0500

c++: Fix missing SFINAE when binding a bit-field to a reference (PR 93729)

We are unconditionally emitting an error here, without first checking
complain.

gcc/cp/ChangeLog:

PR c++/93729
* call.c (convert_like_real): Check complain before emitting an
error
about binding a bit-field to a reference.

gcc/testsuite/ChangeLog:

PR c++/93729
* g++.dg/concepts/pr93729.C: New test.

[Bug c++/94027] [10 Regression] ice in comptypes, at cp/typeck.c:1489 since r10-6907

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
commit r10-7074-g191bcd0f30dd37dec773efb0125afdcae9bd90ef
Author: Nathan Sidwell 
Date:   Fri Mar 6 10:51:26 2020 -0800

Fix mangling ICE [PR94027]

PR c++/94027
* mangle.c (find_substitution): Don't call same_type_p on template
args that cannot match.

Now same_type_p rejects argument packs, we need to be more careful
calling it with template argument vector contents.

The mangler needs to do some comparisons to find the special
substitutions.  While that code looks a little ugly, this seems the
smallest fix.

[Bug target/89229] Incorrect xmm16-xmm31/ymm16-ymm31 in vector move

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #29 from Martin Liška  ---
commit r10-7078-g6733ecaf3fe77871d86bfb36bcda5497ae2aaba7
Author: H.J. Lu 
Date:   Sun Mar 8 05:01:03 2020 -0700

gcc.target/i386/pr89229-3c.c: Include "pr89229-3a.c"

PR target/89229
PR target/89346
* gcc.target/i386/pr89229-3c.c: Include "pr89229-3a.c", instead
of "pr89229-5a.c".

[Bug testsuite/94019] [9 regression] gcc.dg/vect/vect-over-widen-17.c fails starting with g:370c2ebe8fa20e0812cd2d533d4ed38ee2d37c85, r9-1590

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
commit r10-7084-gcb2c60206f4f2218f84ccde21663b00de068d8c7
Author: Kewen Lin 
Date:   Sun Mar 8 21:55:11 2020 -0500

[testsuite] Fix PR94019 to check vector char when vect_hw_misalign

As PR94019 shows, without misaligned vector access support but with
realign load, the vectorized loop will end up with realign scheme.
It generates mask (control vector) with return type vector signed
char which breaks the not check.

gcc/testsuite/ChangeLog

2020-03-09  Kewen Lin  

PR testsuite/94019
* gcc.dg/vect/vect-over-widen-17.c: Don't expect vector char if
it's without misaligned vector access support.

[Bug testsuite/94023] [9 regression] gcc.dg/vect/slp-perm-12.c fails starting with r9-5008

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
commit r10-7083-gd5114529228f97c2a433fa72ddea3fadeb6465b3
Author: Kewen Lin 
Date:   Sun Mar 8 21:34:13 2020 -0500

[testsuite] Fix PR94023 to guard case under vect_hw_misalign

As PR94023 shows, the expected SLP requires misaligned vector access
support.  This patch is to guard the check under the target condition
vect_hw_misalign to ensure that.

gcc/testsuite/ChangeLog

2020-03-09  Kewen Lin  

PR testsuite/94023
* gcc.dg/vect/slp-perm-12.c: Expect loop vectorized messages only on
vect_hw_misalign targets.

[Bug target/94095] Modifier 'a' do not work as described

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
commit r10-7092-ga931bb50fe77446058166b50eea4e53223ad7ef7
Author: Andrew Pinski 
Date:   Mon Mar 9 09:45:23 2020 -0700

Fix 'A' operand modifier: PR inline-asm/94095

The problem here is there was a typo in the documentation
for the 'A' modifier in the table, it was recorded as 'a'
in the table on the modifier column.

Committed as obvious.

2020-03-09  Andrew Pinski  

PR inline-asm/94095
* doc/extend.texi (x86 Operand Modifiers): Fix column
for 'A' modifier.

[Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
commit r10-7095-gea182fe63634bb5b7913b3f1b6846e1900c5e0c4
Author: Jonathan Wakely 
Date:   Mon Mar 9 23:22:57 2020 +

libstdc++: Handle type-changing path concatenations (PR 94063)

The filesystem::path::operator+= and filesystem::path::concat functions
operate directly on the native format of the path and so can cause a
path to mutate to a completely different type.

For Windows combining a filename "x" with a filename ":" produces a
root-name "x:". Similarly, a Cygwin root-directory "/" combined with a
root-directory and filename "/x" produces a root-name "//x".

Before this patch the implemenation didn't support those kind of
mutations, assuming that concatenating two filenames would always
produce a filename and concatenating with a root-dir would still have a
root-dir.

This patch fixes it simply by checking for the problem cases and
creating a new path by re-parsing the result of the string
concatenation. This is slightly suboptimal because the argument has
already been parsed if it's a path, but more importantly it doesn't
reuse any excess capacity that the path object being modified might
already have allocated. That can be fixed later though.

PR libstdc++/94063
* src/c++17/fs_path.cc (path::operator+=(const path&)): Add kluge
to
handle concatenations that change the type of the first component.
(path::operator+=(basic_string_view)): Likewise.
* testsuite/27_io/filesystem/path/concat/94063.cc: New test.

[Bug rtl-optimization/93564] [10 Regression] 470.lbm regresses by 25% on znver2 with -Ofast -march=native LTO and PGO since r10-6384-g2a07345c4f8dabc2

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
commit r10-7093-g5dc1390b41db5c1765e25fd21dad1a930a015aac
Author: Vladimir N. Makarov 
Date:   Mon Mar 9 14:05:09 2020 -0400

Revert: One more patch for PR93564: Prefer smaller hard regno when we do
not honor reg alloc order.

2020-03-09  Vladimir Makarov  

Revert:

2020-02-28  Vladimir Makarov  

PR rtl-optimization/93564
* ira-color.c (assign_hard_reg): Prefer smaller hard regno when we
do not honor reg alloc order.

[Bug tree-optimization/94130] [8/9/10 Regression] Unintended result with optimization option when assigning two structures, memset and 0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r7-5965-g7c9560a578a06125cb30458a26605f91feb29b0d

[Bug target/90763] PowerPC vec_xl_len should take const

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
commit r10-7109-ge00cb200f39d8144de226e76c5d0257b613dbbf6
Author: Will Schmidt 
Date:   Tue Mar 10 14:38:13 2020 -0500

PR90763: PowerPC vec_xl_len should take const argument.

PR target/90763
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
Add
clause to handle P9V_BUILTIN_VEC_LXVL with const arguments.

* gcc.target/powerpc/pr90763.c: New.

[Bug c++/94117] deferred noexcept specifications and friend fns

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #10 from Martin Liška  ---
commit r10-7103-gc222eabcf8be0e3f644e4bd4c3316b40dba4b514
Author: Jonathan Wakely 
Date:   Tue Mar 10 10:50:40 2020 +

libstdc++: Fix invalid noexcept-specifier (PR 94117)

G++ fails to diagnose this non-dependent expression, but Clang doesn't
like it.

PR c++/94117
* include/std/ranges
(ranges::transform_view::_Iterator::iter_move):
Change expression in noexcept-specifier to match function body.

[Bug target/93709] [10 regression] fortran.dg/minlocval_4.f90 fails on power 9 after r10-4161

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #6 from Martin Liška  ---
commit r10-7114-g37e0df8a9be5a8232f4ccb73cdadb02121ba523f
Author: Jiufu Guo 
Date:   Tue Mar 10 13:51:57 2020 +0800

rs6000: Check -+0 and NaN for smax/smin generation

PR93709 mentioned regressions on maxlocval_4.f90 and minlocval_f.f90 which
relates to max of '-inf' and 'nan'. This regression occur on P9 because
P9 new instruction 'xsmaxcdp' is generated.
And for C code `a < b ? b : a` is also generated as `xsmaxcdp` under -O2
for P9. While this instruction behavior more like C/C++ semantic (a>b?a:b).

This generates prevents 'xsmaxcdp' to be generated for those cases.
'xsmincdp' also is handled in patch.

gcc/
2020-03-10  Jiufu Guo  

PR target/93709
* gcc/config/rs6000/rs6000.c (rs6000_emit_p9_fp_minmax): Check
NAN and SIGNED_ZEROR for smax/smin.

gcc/testsuite
2020-03-10  Jiufu Guo  

PR target/93709
* gcc.target/powerpc/p9-minmax-3.c: New test.

[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
commit r10-7115-gdf15a82804e1f7f4a7432670b33387779de46549
Author: Jason Merrill 
Date:   Tue Mar 10 17:51:46 2020 -0400

c++: Fix ICE with omitted template args [PR93956].

reshape_init only wants to work on BRACE_ENCLOSED_INITIALIZER_P, i.e. raw
initializer lists, and here was getting a CONSTRUCTOR that had already been
processed for type A.  maybe_aggr_guide should also use that test.

gcc/cp/ChangeLog
2020-03-10  Jason Merrill  

PR c++/93956
* pt.c (maybe_aggr_guide): Check BRACE_ENCLOSED_INITIALIZER_P.