[Bug libstdc++/91748] New: doesn't compile std::for_each_n for random access iterator range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91748
Bug ID: 91748
Summary: doesn't compile std::for_each_n for random access
iterator range
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: faithandbrave at gmail dot com
Target Milestone: ---
#include
int main() {
int ar[] = {1, 2, 3};
std::for_each_n(ar, 3, [](int) {});
}
doesn't compile the code. compilation error is follow:
In file included from /opt/wandbox/gcc-head/include/c++/10.0.0/algorithm:62,
from prog.cc:1:
/opt/wandbox/gcc-head/include/c++/10.0.0/bits/stl_algo.h: In instantiation of
'_InputIterator std::for_each_n(_InputIterator, _Size, _Function) [with
_InputIterator = int*; _Size = int; _Function = main()::]':
prog.cc:5:36: required from here
/opt/wandbox/gcc-head/include/c++/10.0.0/bits/stl_algo.h:3996:22: error: cannot
convert 'main()::' to 'int*' in return
3996 | return std::for_each(__first, __first + __n2, __f);
| ~^~
| |
| main()::
It seems mistake return type. The function should returns iterator, but the
function returns function object.
https://github.com/gcc-mirror/gcc/blob/b8f684bc811e410d9cd82de83e8e6d4cc15dca8c/libstdc%2B%2B-v3/include/bits/stl_algo.h#L3996
[Bug other/91744] -fno-pie is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91744 --- Comment #5 from Andrew Pinski --- (In reply to Eric Gallager from comment #4) > > That's confusing. Is there anywhere in the documentation or somewhere that > this could be clarified? Maybe a "Commonly Confused Compiler Options" page > in the wiki or something? The documentation is clear here and even mentions -pie option for the link side: -fpie -fPIE These options are similar to -fpic and -fPIC, but the generated position-independent code can be only linked into executables. Usually these options are used to compile code that will be linked using the -pie GCC option. -fpie and -fPIE both define the macros __pie__ and __PIE__. The macros have the value 1 for -fpie and 2 for -fPIE. CUT --- I think someone did not read the documentation after all.
[Bug other/91744] -fno-pie is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91744 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- (In reply to Andrew Pinski from comment #2) > You want -no-pie; not -fno-pie. > -no-pie turns off the linking and -fno-pie just turns off the compiler > option. That's confusing. Is there anywhere in the documentation or somewhere that this could be clarified? Maybe a "Commonly Confused Compiler Options" page in the wiki or something?
[Bug fortran/91731] Configure error on building MPICH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91731 --- Comment #7 from Steve Kargl --- On Thu, Sep 12, 2019 at 01:06:12AM +, damian at sourceryinstitute dot org wrote: > > --- Comment #6 from Damian Rouson --- > Steve, I'm so incredibly glad you posted the details of your workaround. > Thank you! I had seen the FCFLAG environment variable, but I hadn't > noticed the > FFLAG variable listed just a few lines lower in the output of "configure > --help". I was pulling my hair out until I noticed that one extra character! > > Also, what is -w doing? From your message on the email list, I'm guessing it -w suppresses all warnings. It is the only way (intentionally!) to suppress the argument mismatch warning. > converts an error message to a warning. Is it needed with > -fallow-argument-mismatch? -fallow-argument-mismatch degrades the error to a warning. > I don't find -w in the output of "gfortran --help" It's a general gcc option. Look in gcc.info. > and I don't see it mentioned in gfortran's online documentation at > https://gcc.gnu.org/onlinedocs/gfortran/Option-Summary.html. General gcc options are not documented in the gfortran.info file. I don't use mpich, but poking around in its scripts, I think that mpifort is the general script to compile a Fortran program. This script does not honor FFLAGS.
[Bug fortran/91731] Configure error on building MPICH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91731 --- Comment #6 from Damian Rouson --- Steve, I'm so incredibly glad you posted the details of your workaround. Thank you! I had seen the FCFLAG environment variable, but I hadn't noticed the FFLAG variable listed just a few lines lower in the output of "configure --help". I was pulling my hair out until I noticed that one extra character! Also, what is -w doing? From your message on the email list, I'm guessing it converts an error message to a warning. Is it needed with -fallow-argument-mismatch? I don't find -w in the output of "gfortran --help" and I don't see it mentioned in gfortran's online documentation at https://gcc.gnu.org/onlinedocs/gfortran/Option-Summary.html.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #15 from Steve Kargl --- On Thu, Sep 12, 2019 at 12:10:21AM +, manfred99 at gmx dot ch wrote: > > c.f:4:15: > > 4 | ww=CMPLX(1.0_8, 1.0_8) > | 1 > Warning: Conversion from REAL(8) to default-kind COMPLEX(4) at (1) might lose > precision, consider using the KIND argument [-Wconversion] CMPLX() has historical baggage from Fortran 77. By default (ie., without a kind= argument), it will convert whatever the arguments are to default real kind. Most other intrinsic routines obtain the results kind from an argument, e.g., 'AIMAG(Z)' with 'Z' complex(8) will return a REAL(8) value. Note, also the RHS is evaluated without regards to the type of LHS variable, so the warning applies to the result of CMPLX() not from the assignment.
[Bug inline-asm/85185] Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185 --- Comment #10 from Jim Wilson --- It is the same basic problem as before, but more serious. The original testcase uses a short variable, and can be fixed by adding a cast to int. But the new testcase does not use any short variables. There seems to be a disconnect between the C parser and the RTL expander here. the C parser is giving the asm operand a type of short unsigned int, which is the smallest integer type that the constant can fit in. The RTL expander is then generating a HImode reg for it, but loading a constant into an HImode reg will implicitly sign extend it, which is wrong for a short unsigned int asm operand. Before the expand_expr call... Breakpoint 6, expand_asm_stmt (stmt=stmt@entry=0x76274108) at ../../gcc-git/gcc/cfgexpand.c:3247 (gdb) print val $11 = (gdb) pt warning: Expression is not an assignment (and might have no effect) constant 65532> (gdb) after the expand_expr call... gdb) print op $12 = (rtx) 0x76163450 (gdb) pr warning: Expression is not an assignment (and might have no effect) (const_int -4 [0xfffc]) (gdb) then it does op = force_reg (TYPE_MODE (type), op); and we end up with gdb) print op $13 = (rtx) 0x76272828 (gdb) pr warning: Expression is not an assignment (and might have no effect) (reg:HI 72) Maybe what we need here is some equivalent to PROMOTE_MODES to force asm operands to word mode on targets where this makes more sense. But this needs to happen before the constant gets sign extended, which means it has to happen before or inside the expand_expr call.
[Bug fortran/91731] Configure error on building MPICH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91731 --- Comment #5 from Damian Rouson --- MPICH must find ISO_Fortran_binding.h in order to build the modern Fortran bindings that the MPI standard provides through the "mpi_f08" Fortran module. Gfortran only started providing ISO_Fortran_binding.h in release 9.1. In fact, ISO_Fortran_binding.h was primarily motivated by the need for modern MPI bindings. Hopefully someone on the MPICH project will implement more modern bindings now. I'll ask when I report this.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #14 from Manfred Schwarb --- >FWIW, I briefly looked at conversions of complex variables >and did not find any similar -Wconversion warnings for a patched compiler. Well, I only looked at REAL,REALPART,AIMAG,IMAG,IMAGPART,DIMAG. For CMPLX, there is some warning: complex(4) ww complex(8) xx ww=CMPLX(1.0_8, 1.0_8) ww=CMPLX(1.0_8, 1.0_8, kind=4) ww=COMPLEX(1.0_8, 1.0_8) xx=CMPLX(1.0_10, 1.0_10) xx=CMPLX(1.0_10, 1.0_10, kind=8) xx=COMPLEX(1.0_10, 1.0_10) end c.f:4:15: 4 | ww=CMPLX(1.0_8, 1.0_8) | 1 Warning: Conversion from REAL(8) to default-kind COMPLEX(4) at (1) might lose precision, consider using the KIND argument [-Wconversion] c.f:7:15: 7 | xx=CMPLX(1.0_10, 1.0_10) | 1 Warning: Conversion from REAL(10) to default-kind COMPLEX(4) at (1) might lose precision, consider using the KIND argument [-Wconversion] This seems very reasonable though, no warnings when using an explicit kind statement. So no action needed here, from my point of view.
[Bug fortran/91731] Configure error on building MPICH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91731 --- Comment #4 from Steve Kargl --- On Wed, Sep 11, 2019 at 10:36:20PM +, damian at sourceryinstitute dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91731 > > --- Comment #3 from Damian Rouson --- > So do I need to report this to the MPICH developers or is a gfortran bug? I > tried "-w -fallow-argument-mismatch" and got the same error message. > With mpich-3.3.1, I do % setenv PATH ~/work/x/bin:$PATH# set path to find gfortran 10 % setenv FFLAGS "-w -fallow-argument-mismatch -O2" % ./configure |& tee sgk.log % grep mismatched sgk.log checking whether gfortran allows mismatched arguments... yes checking whether gfortran allows mismatched arguments... yes % make -j5 % grep mismatch src/env/* src/env/mpif77.bash:final_fflags=" -w -fallow-argument-mismatch -O2" src/env/mpif77.sh:final_fflags=" -w -fallow-argument-mismatch -O2" works for me. I suppose that someone should file a bug report with MPICH developers to alert them to gfortran's ability to detect argument mismatches in 10.0.0 (aka 10.1 when released). They should be able to 1) fix configure to detect 10 or newer versions to add the appropriate options; and 2) fix their broken code. PS: Frankly, I'm shocked to see that mpich defaults to only F77 in 2019.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #13 from Manfred Schwarb --- FWIW, I briefly looked at conversions of complex variables and did not find any similar -Wconversion warnings for a patched compiler.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #12 from Steve Kargl --- On Wed, Sep 11, 2019 at 11:08:52PM +, manfred99 at gmx dot ch wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 > > --- Comment #11 from Manfred Schwarb --- > >> !---LONG not allowed anymore in gfortran 10 (?): > >> !!ff=LONG(a) > >> !!ff=LONG(b) > >> !!ff=LONG(c) > >> !!ff=LONG(d) > >> !!ff=LONG(g) > > > >LONG was removed by by BOZ patch. It was documented > >to convert its argument to C's 32-bit long type. Not > >a good thing as long can be 64-bit. Note, SHORT was > >also removed. Fortunately, LONG and SHORT were in-line > >conversion, so no change to libgfortran was needed. > > > Well, the error message is >92 | ff=LONG(a) > | 1 > Error: 'long' intrinsic subprogram at (1) has been deprecated. Use INT > intrinsic subprogram. > > The message talks about "deprecated", so I assumed I could eliminate > this error with "-std=legacy" or something similar. But in fact you > have deleted this feature. This is very OK for me, but I find the message > a bit confusing. LONG and SHORT have been removed. There is no fallback via -std=legacy. I suppose I could (or someone who cares) can change the word "deprecated" to "removed".
[Bug other/91744] -fno-pie is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91744 --- Comment #3 from Jeffrey Walton --- (In reply to Andrew Pinski from comment #2) > You want -no-pie; not -fno-pie. > -no-pie turns off the linking and -fno-pie just turns off the compiler > option. Thanks Andrew.
[Bug c++/91747] New: Using a type alias leads to wrong static values.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91747
Bug ID: 91747
Summary: Using a type alias leads to wrong static values.
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.frey at gmx dot de
Target Milestone: ---
Sorry for the title, I have no idea how to describe the problem in any better
way :-/
The following program fails, the static_assert() is (wrongly) triggered:
#include
template< typename T, typename = std::make_index_sequence< T::size() > >
struct inclusive_scan;
template< std::size_t... Ns, std::size_t... Is >
struct inclusive_scan< std::index_sequence< Ns... >, std::index_sequence< Is...
> >
{
template< std::size_t I >
using part = std::integral_constant< std::size_t, ( 0 + ... + ( ( Is <= I )
? Ns : 0 ) ) >;
using type = std::index_sequence< part< Is >::value... >;
};
int main()
{
using S = std::index_sequence<3,1,2,1,3>;
using IS = inclusive_scan::type;
static_assert( std::is_same_v> );
}
Clang and MSVC accept the code.
If you change
template< std::size_t I >
using part = std::integral_constant< std::size_t, ( 0 + ... + ( ( Is <= I )
? Ns : 0 ) ) >;
into
template< std::size_t I >
struct part : std::integral_constant< std::size_t, ( 0 + ... + ( ( Is <= I
) ? Ns : 0 ) ) >{};
the code is also compiled correctly with GCC. This problem is present in GCC 7,
8, 9 and trunk, see Compiler Explorer https://godbolt.org/z/KOdhTV
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #11 from Manfred Schwarb --- >> !---LONG not allowed anymore in gfortran 10 (?): >> !!ff=LONG(a) >> !!ff=LONG(b) >> !!ff=LONG(c) >> !!ff=LONG(d) >> !!ff=LONG(g) > >LONG was removed by by BOZ patch. It was documented >to convert its argument to C's 32-bit long type. Not >a good thing as long can be 64-bit. Note, SHORT was >also removed. Fortunately, LONG and SHORT were in-line >conversion, so no change to libgfortran was needed. Well, the error message is 92 | ff=LONG(a) | 1 Error: 'long' intrinsic subprogram at (1) has been deprecated. Use INT intrinsic subprogram. The message talks about "deprecated", so I assumed I could eliminate this error with "-std=legacy" or something similar. But in fact you have deleted this feature. This is very OK for me, but I find the message a bit confusing.
[Bug inline-asm/85185] Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185
--- Comment #9 from Zev Weiss ---
I've just encountered another related-looking problem -- the inline asm sees
0xfffc here instead of the intended 0xfffc:
$ cat x.c
static inline void foo(unsigned short n)
{
__asm__("foo %0" :: "r" (n));
}
void bar(void)
{
foo(0xfffc);
}
$ riscv64-unknown-elf-gcc -S -o - -Og -fdump-rtl-expand x.c
.file "x.c"
.option nopic
.text
.align 2
.globl bar
.type bar, @function
bar:
li a5,-4
#APP
# 3 "x.c" 1
foo a5
# 0 "" 2
#NO_APP
ret
.size bar, .-bar
.ident "GCC: (GNU) 7.2.0"
$ cat x.c.229r.expand
;; Function bar (bar, funcdef_no=1, decl_uid=1412, cgraph_uid=1,
symbol_order=1)
;; Generating RTL for gimple basic block 2
try_optimize_cfg iteration 1
Merging block 3 into block 2...
Merged blocks 2 and 3.
Merged 2 and 3 without moving.
Merging block 4 into block 2...
Merged blocks 2 and 4.
Merged 2 and 4 without moving.
try_optimize_cfg iteration 2
;;
;; Full RTL generated for this function:
;;
(note 1 0 3 NOTE_INSN_DELETED)
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)
(insn 5 2 6 2 (set (reg:HI 72)
(const_int -4 [0xfffc])) "x.c":3 -1
(nil))
(insn 6 5 0 2 (asm_operands/v ("foo %0") ("") 0 [
(reg:HI 72)
]
[
(asm_input:HI ("r") x.c:3)
]
[] x.c:3) "x.c":3 -1
(nil))
I don't really know how to read these RTL dumps, so I can't say for sure, but
my guess is that this is probably another manifestation of the same underlying
problem. Jim (or anyone else with input), can you confirm that's the case?
Unlike the original case, this one, for what it's worth, also occurs at -O1,
-O2, and -O3 in addition to -Og.
[Bug c++/91746] Bogus error due to a type and variable with the same name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91746 --- Comment #2 from Andrew Pinski --- Just for refernce of the C++ standard wording: [basic.scope.class] paragraph 2: "A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S. No diagnostic is required for a violation of this rule." NOTE the "No dianostic is required" part. So even though it is invalid to do this, compilers don't need to check for volations. If you want clang/MSVC to detect the violation of this rule, please file a bug with them.
[Bug c++/91746] Bogus error due to a type and variable with the same name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91746 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- No GCC is correct. this is invalid C++ though there is no diagnostic required by the C++ standard. GCC checks for this case while the other two compilers you citied don't.
[Bug fortran/91731] Configure error on building MPICH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91731 --- Comment #3 from Damian Rouson --- So do I need to report this to the MPICH developers or is a gfortran bug? I tried "-w -fallow-argument-mismatch" and got the same error message.
[Bug c/91745] New: Documentation for __builtin_speculation_safe_value() doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91745 Bug ID: 91745 Summary: Documentation for __builtin_speculation_safe_value() doesn't compile Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: andrew.cooper3 at citrix dot com Target Milestone: --- https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fspeculation_005fsafe_005fvalue-1 The 3rd code sample in the documentation talks about how to transform the code when element 0 of the array isn't safe to speculatively access. https://godbolt.org/z/98LNs8 Unfortunately, it doesn't compile, citing: [x86-64 gcc 9.2 #1] error: both arguments must be compatible Replacing NULL with (int *)0 does allow the sample to compile. I'm not wel- versed enough in the C spec to comment on whether NULL and (int *)0 are compatible or not, but the intention of the documentation is clearly that NULL should be acceptable in this circumstance. Is this a documentation bug, or a diagnostics bug?
[Bug c++/91746] New: Bogus error due to a type and variable with the same name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91746
Bug ID: 91746
Summary: Bogus error due to a type and variable with the same
name
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
GCC fails to compile:
struct pixel {
int x;
int y;
};
struct master {
pixel pixel;
};
:9:11: error: declaration of 'pixel master::pixel' changes meaning of
'pixel' [-fpermissive]
9 | pixel pixel;
| ^
:3:8: note: 'pixel' declared here as 'struct pixel'
3 | struct pixel {
|^
Clang, ICC, MSVC - compiles it just fine.
[Bug target/85482] unnecessary vmovaps/vmovapd/vmovdqa emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85482 --- Comment #3 from Matthias Kretz --- Seems like trunk (10.0.0 20190910) resolves the issue.
[Bug target/85538] kortest for 32 and 64 bit masks incorrectly uses k0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85538 Matthias Kretz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Matthias Kretz --- I can't figure out what the issue here was. Because k0 can certainly be written to and used for kortest. The only restriction is that k0 cannot be used as a writemask (predicate operand), which is not the case here. Codegen wrt. mask registers has improved considerably as well.
[Bug middle-end/91725] [10 Regression] ICE in get_nonzero_bits starting with r275587
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91725 Jakub Jelinek changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #6 from Jakub Jelinek --- *** Bug 91743 has been marked as a duplicate of this bug. ***
[Bug c/91743] ice: tree check: expected ssa_name, have mult_expr in get_nonzero_bits, at tree-ssanames.c:524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91743 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Resolution|FIXED |DUPLICATE --- Comment #2 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 91725 ***
[Bug c++/91740] [9/10 Regression] ICE in fold_convert_loc, at fold-const.c:2429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91740 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #3 from Marek Polacek --- https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00819.html
[Bug middle-end/83889] [8 regression] new failures on some arm targets after r256644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83889 --- Comment #4 from sandra at gcc dot gnu.org --- Author: sandra Date: Wed Sep 11 20:53:46 2019 New Revision: 275667 URL: https://gcc.gnu.org/viewcvs?rev=275667=gcc=rev Log: 2019-09-11 Sandra Loosemore PR testsuite/83889 gcc/testsuite/ * gcc.dg/vect/pr81740-2.c: Remove explicit dg-do run. * gcc.dg/vect/pr88598-1.c: Likewise. * gcc.dg/vect/pr88598-2.c: Likewise. * gcc.dg/vect/pr88598-3.c: Likewise. * gcc.dg/vect/pr88598-4.c: Likewise. * gcc.dg/vect/pr88598-5.c: Likewise. * gcc.dg/vect/pr88598-6.c: Likewise. * gcc.dg/vect/pr89440.c: Likewise. * gcc.dg/vect/pr90018.c: Likewise. * gcc.dg/vect/pr91293-1.c: Likewise. * gcc.dg/vect/pr91293-2.c: Likewise. * gcc.dg/vect/pr91293-3.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr81740-1.c trunk/gcc/testsuite/gcc.dg/vect/pr81740-2.c trunk/gcc/testsuite/gcc.dg/vect/pr88598-1.c trunk/gcc/testsuite/gcc.dg/vect/pr88598-2.c trunk/gcc/testsuite/gcc.dg/vect/pr88598-3.c trunk/gcc/testsuite/gcc.dg/vect/pr88598-4.c trunk/gcc/testsuite/gcc.dg/vect/pr88598-5.c trunk/gcc/testsuite/gcc.dg/vect/pr88598-6.c trunk/gcc/testsuite/gcc.dg/vect/pr89440.c trunk/gcc/testsuite/gcc.dg/vect/pr90018.c trunk/gcc/testsuite/gcc.dg/vect/pr91293-1.c trunk/gcc/testsuite/gcc.dg/vect/pr91293-2.c trunk/gcc/testsuite/gcc.dg/vect/pr91293-3.c
[Bug other/91744] -fno-pie is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91744 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |other Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- You want -no-pie; not -fno-pie. -no-pie turns off the linking and -fno-pie just turns off the compiler option.
[Bug c/91744] -fno-pie is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91744 --- Comment #1 from Jeffrey Walton --- My bad, this should have been included: $ lsb_release -rd Description:Ubuntu 18.04.3 LTS Release:18.04 $ gcc --version gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0 Copyright (C) 2017 Free Software Foundation, Inc.
[Bug c/91744] New: -fno-pie is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91744
Bug ID: 91744
Summary: -fno-pie is not honored
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
From Initial SUPERCOP Haswell results for round 2
(https://groups.google.com/a/list.nist.gov/d/msg/pqc-forum/kiMo-1jBwDI/KS8VtDwWAgAJ):
$ cat x.c
#include
extern int thenumber(void);
int main() { printf("%d\n",thenumber()); return 0; }
$ cat y.c
static int myconstant = 5;
int thenumber(void) { return myconstant; }
And then:
$ gcc -c x.c; clang -c y.c; gcc -o x x.o y.o
/usr/bin/ld: y.o: relocation R_X86_64_32S against `.data' can not be used when
making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
And finally with -fno-pie:
$ gcc -c x.c; clang -c y.c; gcc -fno-pie -o x x.o y.o
/usr/bin/ld: y.o: relocation R_X86_64_32S against `.data' can not be used when
making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
[Bug target/85401] segfault building code for VAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401 --- Comment #6 from coypu --- I imagine I didn't write scheduling for the broken instruction, so it doesn't ever happen. something silly like that, rather than it being a valid fix.
[Bug c/91743] ice: tree check: expected ssa_name, have mult_expr in get_nonzero_bits, at tree-ssanames.c:524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91743 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from David Binderman --- Problem seems to have gone away by revision 275650.
[Bug target/85401] segfault building code for VAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401 --- Comment #5 from coypu --- Created attachment 46872 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46872=edit providing instruction scheduling avoids this crash So, I am trying to beat gcc/vax into shape and incorporate changes from netbsd's patches. I noticed one of the changes I made for another reason avoids this crash. It is providing a (trivial) instruction scheduling.
[Bug fortran/91553] ICE in gfc_real2complex, at fortran/arith.c:2208
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91553 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Sep 11 18:37:31 2019 New Revision: 275657 URL: https://gcc.gnu.org/viewcvs?rev=275657=gcc=rev Log: 2019-09-11 Steven G. Kargl PR fortran/91553 * simplify.c (gfc_convert_constant): During conversion check if the constant is enclosed in parenthesis, and simplify expression. 2019-09-11 Steven G. Kargl PR fortran/91553 * gfortran.dg/pr91553.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr91553.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/91642] ICE: Bad IO basetype (transfer_expr, at fortran/trans-io.c:2507)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91642 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Sep 11 18:27:17 2019 New Revision: 275655 URL: https://gcc.gnu.org/viewcvs?rev=275655=gcc=rev Log: 2019-09-11 Steven G. Kargl PR fortran/91642 * io.c (gfc_match_inquire): null() cannot be in an iolength inquire list. 2019-09-11 Steven G. Kargl PR fortran/91642 * gfortran.dg/pr91642.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr91642.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog
[Bug c++/91678] [9/10 Regression] decltype returns wrong type under certain conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91678 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #2 from Marek Polacek --- Patch posted Sep 5: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00330.html
[Bug c++/91742] User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742
--- Comment #7 from Diego Franco ---
This works:
#include
#include
struct A
{
operator const int&() const
{
return a_;
}
int a_;
};
int main()
{
A a {};
const auto& b1 {static_cast(a)};
const int& b2 {a};
assert(_ == );
assert( == ); // works
[Bug c++/91742] User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742 --- Comment #6 from Diego Franco --- Also the brace initialization works with primitive types for the code I posted in the first place. That's definitely a code smell.
[Bug c++/91742] User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742
--- Comment #5 from Jonathan Wakely ---
(In reply to Diego Franco from comment #4)
> It worked on linaro 7.4.1 gcc with c++17, gcc 7.1.0 with c++17 only.
Yes, sometimes old versions have incorrect behaviour and they get fixed.
I agree this is surprising, but it's not the only weird property of {}
initialization.
[Bug c++/91742] User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742
--- Comment #4 from Diego Franco ---
> It's not implementation defined, but I think all implementations are required
> to do what GCC 8 does (and other compilers agree).
It worked on linaro 7.4.1 gcc with c++17, gcc 7.1.0 with c++17 only.
> If "const X& b2 (a)" is used instead of list-init, the second assertion
> passes.
That seems like an issue no working with {}.
[Bug c/91743] New: ice: tree check: expected ssa_name, have mult_expr in get_nonzero_bits, at tree-ssanames.c:524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91743
Bug ID: 91743
Summary: ice: tree check: expected ssa_name, have mult_expr in
get_nonzero_bits, at tree-ssanames.c:524
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this two line C code:
a, b;
c() { unsigned long d = b * d / (1 << a); }
compiled by recent gcc trunk I get this:
bug541.c: In function ‘c’:
bug541.c:2:1: internal compiler error: tree check: expected ssa_name, have
mult_expr in get_nonzero_bits, at tree-ssanames.c:524
0x734b85 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../trunk/gcc/tree.c:9932
0x71ce8c tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../trunk/gcc/tree.h:3519
0x71ce8c get_nonzero_bits(tree_node const*)
../../trunk/gcc/tree-ssanames.c:524
0x1393e52 generic_simplify_124
/home/dcb/gcc/working/gcc/generic-match.c:5656
The bug seems to first appear sometime from revision 275550
to revision 275600.
[Bug target/91738] [10 regression] gcc.target/arm/pr53447-5.c fails since r274823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91738 Wilco changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-09-11 CC||wilco at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Wilco --- (In reply to Christophe Lyon from comment #0) > Since r274823, this arm test fails: > > FAIL: gcc.target/arm/pr53447-5.c scan-assembler-times (ldrd|vldr\\.64) 20 > FAIL: gcc.target/arm/pr53447-5.c scan-assembler-times (strd|vstr\\.64) 18 > > I open this PR to keep track of the discussion started here: > https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01728.html Patch: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02005.html
[Bug c++/91742] User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742
--- Comment #3 from Jonathan Wakely ---
Reduced:
#define assert(C) if (!(C)) { __builtin_puts("Assertion failed: " #C);
__builtin_abort(); }
struct X {
X() { }
X(const X&) { }
};
struct A
{
operator const X&() const
{
return a_;
}
X a_;
};
int main()
{
A a {};
const auto& b1 {static_cast(a)};
const X& b2 {a};
assert(_ == );
assert( == ); // does not work with gcc 8.3.0 any standard
}
Assertion failed: ==
Aborted (core dumped)
If "const X& b2 (a)" is used instead of list-init, the second assertion passes.
[Bug c++/91742] User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742 --- Comment #2 from Jonathan Wakely --- (In reply to Diego from comment #0) > I read through the c++17 standard and did not find any information about > this behavior being implementation defined. It's not implementation defined, but I think all implementations are required to do what GCC 8 does (and other compilers agree). The current behaviour started with r259123 (before that there was an ICE, introduced by r258755).
[Bug c++/91741] Implement new warning -Wsizeof-array-div
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91741 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- I thought we already had this, but I guess I was thinking of -Wsizeof-pointer-div instead...
[Bug c++/91741] Implement new warning -Wsizeof-array-div
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91741 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-11 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Looks like a good idea for a warning. But please don't make the diagnostic say "every element", since I hope all the elements of an array have the same size, so you don't need to consider every one of them ;-)
[Bug c++/91742] User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742 --- Comment #1 from Diego --- The code does work when changing std::vector for any primitive types, i.e. int.
[Bug c++/91742] New: User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742
Bug ID: 91742
Summary: User defined conversion references
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: di...@franco-technologies.com
Target Milestone: ---
The following code does not work as intended:
//Example-
#include
#include
struct A
{
operator const std::vector&() const
{
return a_;
}
std::vector a_;
};
int main()
{
A a {};
const auto& b1 {static_cast&>(a)};
const std::vector& b2 {a};
assert(_ == );
assert( == ); // does not work with gcc 8.3.0 any standard
// works with gcc 7.1.0 with c++17 only
}
//End of example-
I read through the c++17 standard and did not find any information about this
behavior being implementation defined.
Diego
[Bug c++/91741] New: Implement new warning -Wsizeof-array-div
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91741 Bug ID: 91741 Summary: Implement new warning -Wsizeof-array-div Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Target Milestone: --- ... to detect things like: https://www.viva64.com/en/examples/v706/
[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734 --- Comment #6 from Jakub Jelinek --- Created attachment 46871 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46871=edit gcc10-pr91734.patch Untested patch that does the 2), though for LE_EXPR only.
[Bug c++/91740] [9/10 Regression] ICE in fold_convert_loc, at fold-const.c:2429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91740 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r267272. Will take a look.
[Bug c++/91740] [9/10 Regression] ICE in fold_convert_loc, at fold-const.c:2429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91740 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-11 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |9.3 Summary|ICE in fold_convert_loc, at |[9/10 Regression] ICE in |fold-const.c:2429 |fold_convert_loc, at ||fold-const.c:2429 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/91740] New: ICE in fold_convert_loc, at fold-const.c:2429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91740
Bug ID: 91740
Summary: ICE in fold_convert_loc, at fold-const.c:2429
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: julien at vivenot dot fr
Target Milestone: ---
The following causes an internal compiler error on gcc 9.2.0 on x86-64.
I do not have access to other versions myself but tested on godbolt: It seems
to say that 9.1, 9.2 and current trunk are affected, while 8.3 is unaffected.
$ cat test.cpp
constexpr bool f(const char*) { return true; }
template const char c = "FOO"[f("BAR") ? 1 : 0];
$ g++ test.cpp
test.cpp:2:59: internal compiler error: in fold_convert_loc, at
fold-const.c:2429
2 | template const char c = "FOO"[f("BAR") ? 1 : 0];
| ^
The current code is obviously meaningless because it has been slowly scaled
down from production code.
I have noted that any of the following changes make the issue disappear :
- removing the argument to f()
- removing the templatization
- removing the ternary operator
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #10 from Steve Kargl --- On Wed, Sep 11, 2019 at 02:25:23PM +, manfred99 at gmx dot ch wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 > > --- Comment #9 from Manfred Schwarb --- > Hi Steve, > > I tried your patch in comment 4, it is a good starting point. > However, SNGL and DBLE still throw warnings: A patch similar to what appears in comment #4 need to be applied to gfc_simplify_dble and gfc_simplify_sngl. > !---unknown but documented type conversions: > !!aa=FLOATI(e) > !!aa=FLOATJ(f) > !!aa=FLOATK(g) The above are under the -fdec option. > !---LONG not allowed anymore in gfortran 10 (?): > !!ff=LONG(a) > !!ff=LONG(b) > !!ff=LONG(c) > !!ff=LONG(d) > !!ff=LONG(g) LONG was removed by by BOZ patch. It was documented to convert its argument to C's 32-bit long type. Not a good thing as long can be 64-bit. Note, SHORT was also removed. Fortunately, LONG and SHORT were in-line conversion, so no change to libgfortran was needed.
[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734 --- Comment #5 from Jakub Jelinek --- Even in the default rounding mode, cases where c2 is equal to zero are clearly problematic as this testcase shows, but also cases where c is subnormal. E.g. sqrtf (x) < 0x1.2dd3d0p-65f is true for x 0x1.63dbc0p-130f, because sqrtf (0x1.63dbc0p-130f) == 0x1.2dd3cep-65. But c2 is 0x1.63dbc0p-130f and so 0x1.63dbc0p-130f < 0x1.63dbc0p-130f is false. So, 1) shall we somehow guard some of these optimizations on !HONOR_SIGN_DEPENDENT_ROUNDING (or is flag_unsafe_math_optimizations it is guarded on incompatible with -frounding-math)? 2) after computing the c2, try to real_sqrt it again and if cmp is LT_EXPR or GE_EXPR, adjust cmp depending on how the boundary value compares?
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #9 from Manfred Schwarb --- Hi Steve, I tried your patch in comment 4, it is a good starting point. However, SNGL and DBLE still throw warnings: real*4 a,aa real*8 b,bb real*10 c,cc real*16 d integer*2 e,ee integer*4 f,ff integer*8 g,gg PARAMETER(a=3.1415927_4) PARAMETER(b=3.1415927_8) PARAMETER(c=3.1415927_10) PARAMETER(d=3.1415927_16) PARAMETER(e=123_2) PARAMETER(f=123_4) PARAMETER(g=123_8) aa=REAL(b) aa=REAL(c) aa=REAL(d) aa=REAL(e) aa=REAL(f) aa=REAL(g) aa=FLOAT(f) aa=FLOOR(b) aa=FLOOR(c) aa=FLOOR(d) aa=CEILING(b) aa=CEILING(c) aa=CEILING(d) !---unknown but documented type conversions: !!aa=FLOATI(e) !!aa=FLOATJ(f) !!aa=FLOATK(g) !---documentation is wrong for sngl: aa=SNGL(c) aa=SNGL(d) bb=REAL(c, kind=8) bb=REAL(d, kind=8) bb=DBLE(c) bb=DBLE(d) bb=DFLOAT(g) bb=FLOOR(c) bb=FLOOR(d) bb=CEILING(c) bb=CEILING(d) cc=REAL(d, kind=10) cc=FLOOR(d) cc=CEILING(d) aa=AINT(b) aa=ANINT(b) aa=AINT(c) aa=ANINT(c) aa=AINT(d) aa=ANINT(d) bb=DINT(b) bb=DNINT(b) ee=INT(a, kind=2) ee=NINT(a, kind=2) ee=INT(b, kind=2) ee=NINT(b, kind=2) ee=INT(c, kind=2) ee=NINT(c, kind=2) ee=INT(d, kind=2) ee=NINT(d, kind=2) ee=INT(f, kind=2) ee=INT(g, kind=2) ee=IFIX(a) ee=IDINT(b) ee=IDNINT(b) ee=INT2(a) ee=INT2(b) ee=INT2(c) ee=INT2(d) ee=INT2(f) ee=INT2(g) ff=INT(a, kind=4) ff=NINT(a, kind=4) ff=INT(b, kind=4) ff=NINT(b, kind=4) ff=INT(c, kind=4) ff=NINT(c, kind=4) ff=INT(d, kind=4) ff=NINT(d, kind=4) ff=INT(f, kind=4) ff=INT(g, kind=4) ff=IFIX(a) ff=IDINT(b) ff=IDNINT(b) !---LONG not allowed anymore in gfortran 10 (?): !!ff=LONG(a) !!ff=LONG(b) !!ff=LONG(c) !!ff=LONG(d) !!ff=LONG(g) gg=INT(a, kind=8) gg=NINT(a, kind=8) gg=INT(b, kind=8) gg=NINT(b, kind=8) gg=INT(c, kind=8) gg=NINT(c, kind=8) gg=INT(d, kind=8) gg=NINT(d, kind=8) gg=INT(f, kind=8) gg=INT(g, kind=8) gg=IFIX(a) gg=IDINT(b) gg=IDNINT(b) gg=INT8(a) gg=INT8(b) gg=INT8(c) gg=INT8(d) gg=INT8(g) end a.f:34:14: 34 | aa=SNGL(c) | 1 Warning: Change of value in conversion from 'REAL(10)' to 'REAL(4)' at (1) [-Wconversion] a.f:35:14: 35 | aa=SNGL(d) | 1 Warning: Change of value in conversion from 'REAL(16)' to 'REAL(4)' at (1) [-Wconversion] a.f:38:14: 38 | bb=DBLE(c) | 1 Warning: Change of value in conversion from 'REAL(10)' to 'REAL(8)' at (1) [-Wconversion] a.f:39:14: 39 | bb=DBLE(d) | 1 Warning: Change of value in conversion from 'REAL(16)' to 'REAL(8)' at (1) [-Wconversion]
[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-11 CC||jsm28 at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jakub Jelinek --- Likely introduced in r64619.
[Bug middle-end/91739] New: Missed optimization for arithmetic operations of integers and floating point constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91739
Bug ID: 91739
Summary: Missed optimization for arithmetic operations of
integers and floating point constants
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:
double foo(unsigned i, unsigned j) {
return i * 4.0 + j * 7.0;
}
Right now GCC emits code that converts integers to a floating points and does
the multiplications:
foo(unsigned int, unsigned int): # @foo(unsigned int, unsigned int)
mov eax, edi
cvtsi2sd xmm1, rax
mulsd xmm1, qword ptr [rip + .LCPI0_0]
mov eax, esi
cvtsi2sd xmm0, rax
mulsd xmm0, qword ptr [rip + .LCPI0_1]
addsd xmm0, xmm1
ret
However it is possible to do better. If the max value of integer multiplied by
the floating point constant fits into the mantissa and there is an integral
type that could also hold the value then do the multiplication using integers:
double foo2(unsigned i, unsigned j) {
return i * 4ull + j * 7ull;
}
This results in a much better code:
foo2(unsigned int, unsigned int): # @foo2(unsigned int, unsigned int)
mov eax, edi
mov ecx, esi
lea rdx, [8*rcx]
sub rdx, rcx
lea rax, [rdx + 4*rax]
cvtsi2sd xmm0, rax
ret
[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
This is:
/* sqrt(x) < c is the same as x < c*c, if we ignore NaNs. */
(if (! HONOR_NANS (@0))
(cmp @0 { build_real (TREE_TYPE (@0), c2); })
/* sqrt(x) < c is the same as x >= 0 && x < c*c. */
(if (GENERIC)
(truth_andif
(ge @0 { build_real (TREE_TYPE (@0), dconst0); })
(cmp @0 { build_real (TREE_TYPE (@0), c2); })
c here is 1.1754943508222875079687365374567781866555677208752151e-38f,
so c2 is 0.0f because the product is smaller than smallest positive subnormal
float. Obviously, in that case we can't use < c2, but need to use <= c2.
Maybe we probably should compute c2 with rounding towards positive infinity,
then we could keep using < c2.
[Bug target/91738] [10 regression] gcc.target/arm/pr53447-5.c fails since r274823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91738 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 --- Comment #10 from Richard Biener --- Can't really decipher what clang does here. it seems to handle even/odd lanes separately, doing 24 vpextrb stores per loop iteration. Possibly simply an interleaving scheme...
[Bug target/91738] New: [10 regression] gcc.target/arm/pr53447-5.c fails since r274823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91738 Bug ID: 91738 Summary: [10 regression] gcc.target/arm/pr53447-5.c fails since r274823 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Since r274823, this arm test fails: FAIL: gcc.target/arm/pr53447-5.c scan-assembler-times (ldrd|vldr\\.64) 20 FAIL: gcc.target/arm/pr53447-5.c scan-assembler-times (strd|vstr\\.64) 18 I open this PR to keep track of the discussion started here: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01728.html
[Bug go/91700] Document go version for gcc 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91700 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Ian Lance Taylor --- Thanks. Fixed.
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 --- Comment #9 from Richard Biener --- (In reply to Richard Biener from comment #8) > The most trivial improvement is likely to recognize the vector parts we can > store via HImode. There's already support for that but only if we can > uniformly > use HImode and not a mix of sizes. While for loads we need N "same" pieces to be able to build the CONSTRUCTOR for stores we can do arbitrary extracts so the strided store code could be refactored to decide on that in the main loop walking over the actual elements to store rather than computing this upfront (I sort-of copied the handling from the strided load code retaining this restriction). Might get rid of 1/3 of the pextracts.
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 --- Comment #8 from Richard Biener --- The most trivial improvement is likely to recognize the vector parts we can store via HImode. There's already support for that but only if we can uniformly use HImode and not a mix of sizes.
[Bug go/91712] [10 regression] ICE in bind_field_or_method, at go/gofrontend/types.cc:11878
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91712 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Ian Lance Taylor --- Should be fixed by SVN revision 275648 (I forgot to add the PR reference to the commit message).
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 --- Comment #7 from rguenther at suse dot de --- On Wed, 11 Sep 2019, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #4 from Jakub Jelinek --- > The endless series of vpextrb look terrible, can't that be handled by possibly > masked permutation? Sure, just nobody implemented support for that into the strided store code (likewise for strided loads). I'm also not sure it is really faster in the end. Maybe VPMULTISHIFTQB can also help.
[Bug tree-optimization/91732] Adding omp simd pragma prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91732 --- Comment #3 from Jed Brown --- > why not use gsym[Q*2*j+i] instead of g[j][0] and similarly gsym[Q*2-j*Q+i] > instead of g[j][1]? The pattern here is that gsym is packed storage of a symmetric 2x2 matrix, while g unpacks it so that inner loops (intended for unrolling) can be written using index notation. This case (a finite element quadrature routine for 2D anisotropic Poisson) is reduced from more complicated examples (such as 3D nonlinear solid and fluid mechanics) where this technique provides substantial clarity and correspondence to mathematical notation. The suggested transformation (eliminating the temporary g[][] in exchange for fancy indexing of g) is problematic when representing higher order tensors (https://en.wikipedia.org/wiki/Voigt_notation#Mnemonic_rule). It's also sometimes desirable to roll the second loop instead of repeating, in which case you don't get to have a different indexing rule for g[j][0] and g[j][1]. for (int i=0; i
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 --- Comment #6 from rguenther at suse dot de --- On Wed, 11 Sep 2019, ubizjak at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 > > --- Comment #5 from Uroš Bizjak --- > (In reply to Richard Biener from comment #3) > > Reducing the VF here should be the goal. For the particular case "filling" > > the holes with neutral data and blending in the original values at store > > time > > will likely be optimal. So do > > > > tem = vector load > > zero all [4] elements > > compute > > blend in 'tem' into the [4] elements > > vector store > > MASKMOVDQU [1] should be an excellent fit here. Yes, but it's probably slower. And it avoids store data races, of course plus avoids epilogue peeling (eventually).
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 --- Comment #5 from Uroš Bizjak --- (In reply to Richard Biener from comment #3) > Reducing the VF here should be the goal. For the particular case "filling" > the holes with neutral data and blending in the original values at store time > will likely be optimal. So do > > tem = vector load > zero all [4] elements > compute > blend in 'tem' into the [4] elements > vector store MASKMOVDQU [1] should be an excellent fit here. [1] https://www.felixcloutier.com/x86/maskmovdqu
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- The endless series of vpextrb look terrible, can't that be handled by possibly masked permutation?
[Bug target/91736] Runtime regression for SPEC2000 252.eon on Haswell around beginning of February 2019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91736 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Blocks||26163 --- Comment #2 from Richard Biener --- As expected it regressed with r268448 which dropped max-inline-insns-single from 400 to 200. Honza should remember what was importrant to optimize here (but certainly SPEC 2000 ceased to be relevant). 5.93% 9002 eon_base.none eon_base.none [.] mrGrid::viewingHit 5.57% 8478 eon_base.none eon_base.none [.] mrSurfaceList::viewingHit 5.50% 8296 eon_peak.none eon_peak.none [.] mrSurfaceList::viewingHit 5.17% 7789 eon_peak.none eon_peak.none [.] ggGridIterator::ggGridIterato 4.34% 6533 eon_peak.none eon_peak.none [.] mrGrid::viewingHit 4.18% 6332 eon_base.none eon_base.none [.] mrGrid::shadowHit 3.26% 4908 eon_peak.none eon_peak.none [.] mrGrid::shadowHit suggests that inlining ggGridIterator is important and missing now, likely into viewingHit. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug rtl-optimization/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795 --- Comment #16 from Jakub Jelinek --- *** Bug 91720 has been marked as a duplicate of this bug. ***
[Bug debug/82738] [meta-bug] issues with the -Og optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738 Bug 82738 depends on bug 91720, which changed state. Bug 91720 Summary: [10 Regression] wrong code with -Og -fno-forward-propagate -frerun-cse-after-loop -fno-tree-fre https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91720 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug rtl-optimization/91720] [10 Regression] wrong code with -Og -fno-forward-propagate -frerun-cse-after-loop -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91720 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #13 from Jakub Jelinek --- Fixed by the PR89795 fix. *** This bug has been marked as a duplicate of bug 89795 ***
[Bug rtl-optimization/89435] [7/8/9 Regression] wrong code with -O1 -march=armv4 -fno-forward-propagate with __builtin_sub_overflow()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89435 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Wed Sep 11 11:37:39 2019 New Revision: 275642 URL: https://gcc.gnu.org/viewcvs?rev=275642=gcc=rev Log: PR rtl-optimization/89435 PR rtl-optimization/89795 PR rtl-optimization/91720 * gcc.dg/pr89435.c: New test. * gcc.dg/pr89795.c: New test. * gcc.dg/pr91720.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr89435.c trunk/gcc/testsuite/gcc.dg/pr89795.c trunk/gcc/testsuite/gcc.dg/pr91720.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795 --- Comment #15 from Jakub Jelinek --- Author: jakub Date: Wed Sep 11 11:37:39 2019 New Revision: 275642 URL: https://gcc.gnu.org/viewcvs?rev=275642=gcc=rev Log: PR rtl-optimization/89435 PR rtl-optimization/89795 PR rtl-optimization/91720 * gcc.dg/pr89435.c: New test. * gcc.dg/pr89795.c: New test. * gcc.dg/pr91720.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr89435.c trunk/gcc/testsuite/gcc.dg/pr89795.c trunk/gcc/testsuite/gcc.dg/pr91720.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/91720] [10 Regression] wrong code with -Og -fno-forward-propagate -frerun-cse-after-loop -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91720 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Wed Sep 11 11:37:39 2019 New Revision: 275642 URL: https://gcc.gnu.org/viewcvs?rev=275642=gcc=rev Log: PR rtl-optimization/89435 PR rtl-optimization/89795 PR rtl-optimization/91720 * gcc.dg/pr89435.c: New test. * gcc.dg/pr89795.c: New test. * gcc.dg/pr91720.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr89435.c trunk/gcc/testsuite/gcc.dg/pr89795.c trunk/gcc/testsuite/gcc.dg/pr91720.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/90387] [9 Regression] __builtin_constant_p and -Warray-bounds warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387 Richard Biener changed: What|Removed |Added Known to work||10.0 Summary|[9/10 Regression] |[9 Regression] |__builtin_constant_p and|__builtin_constant_p and |-Warray-bounds warnings |-Warray-bounds warnings Known to fail|10.0| --- Comment #11 from Richard Biener --- Fixed on trunk sofar, not sure if backporting.
[Bug tree-optimization/90387] [9/10 Regression] __builtin_constant_p and -Warray-bounds warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387 --- Comment #10 from Richard Biener --- Author: rguenth Date: Wed Sep 11 11:16:54 2019 New Revision: 275639 URL: https://gcc.gnu.org/viewcvs?rev=275639=gcc=rev Log: 2019-09-11 Richard Biener PR tree-optimization/90387 * vr-values.c (vr_values::extract_range_basic): After inlining simplify non-constant __builtin_constant_p to false. * gcc.dg/Warray-bounds-44.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-44.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/vr-values.c
[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734 --- Comment #2 from Chinoune --- Replacing `if( az
[Bug target/91736] Runtime regression for SPEC2000 252.eon on Haswell around beginning of February 2019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91736 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-11 Version|unknown |9.1.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Last known good r268430, first known bad r268456. Note it's a regression during GCC 9 development so compared to GCC 8 it's not a regression.
[Bug rtl-optimization/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Eric Botcazou --- Fixed on all branches.
[Bug rtl-optimization/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795 --- Comment #13 from Eric Botcazou --- Author: ebotcazou Date: Wed Sep 11 10:44:06 2019 New Revision: 275638 URL: https://gcc.gnu.org/viewcvs?rev=275638=gcc=rev Log: PR rtl-optimization/89795 * rtlanal.c (nonzero_bits1) : Do not propagate results from inner REGs to paradoxical SUBREGs if WORD_REGISTER_OPERATIONS is set. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/rtlanal.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gcc.target/sparc/2016-1.c
[Bug rtl-optimization/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795 --- Comment #12 from Eric Botcazou --- Author: ebotcazou Date: Wed Sep 11 10:43:19 2019 New Revision: 275637 URL: https://gcc.gnu.org/viewcvs?rev=275637=gcc=rev Log: PR rtl-optimization/89795 * rtlanal.c (nonzero_bits1) : Do not propagate results from inner REGs to paradoxical SUBREGs if WORD_REGISTER_OPERATIONS is set. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/rtlanal.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.target/sparc/2016-1.c
[Bug rtl-optimization/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795 --- Comment #11 from Eric Botcazou --- Author: ebotcazou Date: Wed Sep 11 10:42:31 2019 New Revision: 275636 URL: https://gcc.gnu.org/viewcvs?rev=275636=gcc=rev Log: PR rtl-optimization/89795 * rtlanal.c (nonzero_bits1) : Do not propagate results from inner REGs to paradoxical SUBREGs if WORD_REGISTER_OPERATIONS is set. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/rtlanal.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gcc.target/sparc/2016-1.c
[Bug rtl-optimization/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795 --- Comment #10 from Eric Botcazou --- Author: ebotcazou Date: Wed Sep 11 10:41:27 2019 New Revision: 275635 URL: https://gcc.gnu.org/viewcvs?rev=275635=gcc=rev Log: PR rtl-optimization/89795 * rtlanal.c (nonzero_bits1) : Do not propagate results from inner REGs to paradoxical SUBREGs if WORD_REGISTER_OPERATIONS is set. Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sparc/2016-1.c
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 --- Comment #3 from Richard Biener --- Reducing the VF here should be the goal. For the particular case "filling" the holes with neutral data and blending in the original values at store time will likely be optimal. So do tem = vector load zero all [4] elements compute blend in 'tem' into the [4] elements vector store eliding all the shuffling/striding. Should end up at a VF of 4 (SSE) or 8 (AVX). Doesn't fit very well into the current vectorizer architecture. So currently we can only address this from the costing side. arm can probably leverage load/store-lanes here. With char elements and an SLP size of 3 it's probably the worst case we can think of.
[Bug libgcc/91737] New: On Alpine Linux (libmusl) a statically linked C++ program which throws the first exception in two threads at the same time can busy spin on shutdown after main().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91737 Bug ID: 91737 Summary: On Alpine Linux (libmusl) a statically linked C++ program which throws the first exception in two threads at the same time can busy spin on shutdown after main(). Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: max at arangodb dot com Target Milestone: --- Created attachment 46870 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46870=edit Program exposing the problem when compiled under Alpine Linux and linked statically. My statically linked program runs a busy loop after main() has terminated, provided that the very first exception that is thrown in the run is thrown in two threads at the very same time. The attached program shows the problem. This only happens on Linux, and only if one does not use glibc as C-library, and only if the executable is statically linked and does not explicitly use the `pthread_cancel` function. I tested with g++ 8.3.0, but I think the problem is present in other versions as well. Here is what is happening: In the file `libgcc/unwind-dw2-fde.c` in the function `_Unwind_Find_FDE` there is a mutex which is only acquired if the underlying program is detected to be "multi-threaded". This test for multi-threadedness is done differently on various platforms (see file `libgcc/gthr-posix.h` lines 156 to 306). On Linux without glibc and if it is not the Android bionic C library, a weak reference to the symbol `pthread_cancel` is used. If the underlying program does not explicitly use `pthread_cancel` (and few C++ programs will, because cancelling threads is not in the C++ standard), and the linking is done statically, the program will link `libpthread` but not have a symbol `pthread_cancel`. In this case the mutex is not used at all. If now the first exception in the program happens in two exceptions concurrently, the function `_Unwind_Find_FDE` will move an object from the static list `unseen_objects` to the static list `seen_objects` and a data race occurs. Sometimes, the same object is moved twice from one list to the other. This leads to the fact that the `seen_objects` list ends in an object which points to itself (with the `next` pointer). In this case, on shutdown, well after main() and all static destructors, the function `__deregister_frame_info_bases` will busy loop running around the circular data structure `seen_objects`. I think this is overoptimized and the multi-threadedness detection does not work for many statically linked programs when libmusl is used as underlying C-library.
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 --- Comment #2 from Richard Biener --- Errr, before we _dont_ vectorize.
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |NEW Known to work||8.3.1 Version|unknown |9.1.0 Keywords||missed-optimization Last reconfirmed||2019-09-11 CC||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Blocks||53947, 26163 Ever confirmed|0 |1 Summary|Runtime regression for |[9/10 Regression] Runtime |SPEC2000 177.mesa on|regression for SPEC2000 |Haswell around the end of |177.mesa on Haswell around |August 2018 |the end of August 2018 Target Milestone|--- |9.3 --- Comment #1 from Richard Biener --- From the testers data last good r263752, first bad r263787. Bisecting points to Richards vectorizer series r26377[1-4], more specifically r263772. Perf shows nothing conclusive but all functions slower by the same percentage. SPEC 2000 build scripts are oddly redirecting and mangling output so -fopt-info output is illegible. Huh, or rather it's even in the dumps when dumping with -optimized: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: loop vectorized using 32 byte vectors anyhow, differences are for example: fog.c:157:10: note: loop vectorized using 32 byte vectors +fog.c:157:10: note: fog.c:157:10: note: loop versioned for vectorization because of possible aliasing the above is void gl_fog_color_vertices( GLcontext *ctx, GLuint n, GLfloat v[][4], GLubyte color[][4] ) ... case GL_EXP: d = -ctx->Fog.Density; for (i=0;ihttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug target/91736] New: Runtime regression for SPEC2000 252.eon on Haswell around beginning of February 2019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91736 Bug ID: 91736 Summary: Runtime regression for SPEC2000 252.eon on Haswell around beginning of February 2019 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Target Milestone: --- The SUSE SPECint2000 continuous regression tester shows a ~8% runtime regression on Haswell around the beginning of February 2019. [1] https://gcc.opensuse.org/gcc-old/SPEC/CINT/sb-czerny-head-64/252_eon_big.png
[Bug c++/90767] [9/10 Regression] jumbled error message with this and const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90767
Bartosz Szreder changed:
What|Removed |Added
CC||bartosz.szreder@huuugegames
||.com
--- Comment #4 from Bartosz Szreder ---
Another testcase, slightly different error message. Making A::f() a
non-template member function gives sensible results.
struct A {
struct B
{
B(int) {}
};
template void f()
{
int x = 0;
g(x);
}
void g(B& arg) {}
};
$ g++ test.cpp
test.cpp: In member function ‘void A::f()’:
test.cpp:10:11: error: cannot convert ‘#‘view_convert_expr’ not supported by
dump_type#’ to ‘A::B&’
10 | g(x);
| ^
| |
| #‘view_convert_expr’ not supported by dump_type#
test.cpp:13:16: note: initializing argument 1 of ‘void A::g(A::B&)’
13 | void g( B& arg ) {}
|
[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734 --- Comment #1 from Andrew Pinski --- So two things: -funsafe-math-optimizations assumes there are no denormals (subnormals) or they are flushed to zero. -ffinite-math-only assumes that infinite and nans don't exists (IIRC).
[Bug tree-optimization/91732] Adding omp simd pragma prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91732 Jakub Jelinek changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- The routine is obfuscated too much, why not use gsym[Q*2*j+i] instead of g[j][0] and similarly gsym[Q*2-j*Q+i] instead of g[j][1]? The reason this isn't vectorized is that we need to effectively privatize the g variable, because every SIMD lane needs different values for it, and SRA isn't able to split that appart into scalars indexed by the simd lane. So, in the end this is pretty much a dup of PR91020.
[Bug tree-optimization/91732] Adding omp simd pragma prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91732
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization, openmp
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-09-11
CC||jakub at gcc dot gnu.org
Component|c |tree-optimization
Blocks||53947
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
The runtime alias test is between the two stores of the inner unrolled loop.
That's dv[i] vs. dv[i+Q].
Creating dr for *_61
analyze_innermost: success.
base_address: dv_44(D)
offset from base address: 0
constant offset from base address: 0
step: 8
base alignment: 8
base misalignment: 0
offset alignment: 512
step alignment: 8
base_object: *dv_44(D)
Access function 0: {0B, +, 8}_1
Creating dr for *_79
analyze_innermost: success.
base_address: (double *) dv_44(D) + (sizetype) ((long unsigned int)
Q_35(D) * 8)
offset from base address: 0
constant offset from base address: 0
step: 8
base alignment: 8
base misalignment: 0
offset alignment: 512
step alignment: 8
base_object: *(double *) dv_44(D) + (sizetype) ((long unsigned int)
Q_35(D) * 8)
Access function 0: {0B, +, 8}_1
it's probably unfortunate association since we compute inside the loop
_11 = Q_35(D) + i_39;
_12 = (long unsigned int) _11;
_13 = _12 * 8;
With OpenMP SIMD we fail to analyze the data-refs:
Creating dr for D.4113[_37][1][0]
analyze_innermost: t.c:4:18: missed: failed: evolution of offset is not
affine.
base_address:
offset from base address:
constant offset from base address:
step:
base alignment: 0
base misalignment: 0
offset alignment: 0
step alignment: 0
base_object: D.4113
Access function 0: 0
Access function 1: 1
Access function 2: scev_not_known;
where _37 is the SIMD lane.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug fortran/91726] [8/9/10 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91726 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |8.4
[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91724 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |8.4 --- Comment #1 from Richard Biener --- Hmm, can you bisect this a bit? It may be a latent issue is uncovered. Disabling compare-debug might also help getting better backtraces. Looks like loop-invariant has inconsistent DF state somehow. In the ../../src/gcc/df-core.c:1594 frame it is interesting to know the problem causing this. Maybe the backtrace is also completely bogus since there shoud be no hash-tables involved here... P1 until we know some more.
[Bug fortran/91729] [10 Regression] ICE in gfc_match_select_rank, at fortran/match.c:6586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91729 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |10.0
[Bug fortran/91556] Problems with better interface checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556 Thomas Koenig changed: What|Removed |Added CC||damian at sourceryinstitute dot or ||g --- Comment #27 from Thomas Koenig --- *** Bug 91731 has been marked as a duplicate of this bug. ***
