[Bug fortran/86626] New: ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86626 Bug ID: 86626 Summary: ICE Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vivekrao4 at yahoo dot com Target Milestone: --- For the code module xyz implicit none interface repeat module procedure bar end interface repeat contains pure function foo(xx) result(tf) logical, intent(in), optional :: xx logical :: tf if (present(xx)) then tf = .not. xx else tf = .false. end if end function foo ! function bar(n,xx,alternate) result(yy) integer , intent(in) :: n character (len=*), intent(in) :: xx(:) logical , intent(in), optional :: alternate character (len=len(xx)) :: yy(n*size(xx)) integer :: i,j if (foo(alternate)) then yy = (/((xx(j),i=1,n),j=1,size(xx))/) else yy = (/(xx,i=1,n)/) end if end function bar ! subroutine abc(labels) character (len=*), intent(in) :: labels(:) end subroutine abc ! elemental function tappend(xx,yy) result(xy) character (len=*), intent(in) :: xx,yy character (len=len(xx) + len(yy)) :: xy xy = trim(xx) // yy end function tappend end module xyz ! program main use xyz implicit none call abc(labels=tappend(["a"],"_"//repeat(1,["a"]))) end program main compiling gfortran -c xbase_system_bug.f90 using GNU Fortran (GCC) 9.0.0 20180715 (experimental) from equation.com on Windows 10 gives xbase_system_bug.f90:44:0: call abc(labels=tappend(["a"],"_"//repeat(1,["a"]))) internal compiler error: Segmentation fault and gfortran 4.8.4 on Windows sub-system for Linux gives the same result.
[Bug bootstrap/86621] [9 regression] 'alloca' bound is unknown in tree-vect-slp.c:1437:16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86621 --- Comment #4 from H.J. Lu --- i686 target is ok on x86-64 host. The problem is 32 bit host.
[Bug bootstrap/86621] [9 regression] 'alloca' bound is unknown in tree-vect-slp.c:1437:16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86621 Rainer Orth changed: What|Removed |Added Target|i386-pc-solaris2.11,|i386-pc-solaris2.11, |sparc-sun-solaris2.11 |sparc-sun-solaris2.11, ||i686-pc-linux-gnu Host|i386-pc-solaris2.11,| |sparc-sun-solaris2.11 | Build|i386-pc-solaris2.11,| |sparc-sun-solaris2.11 | --- Comment #3 from Rainer Orth --- May affect all 32-bit targets.
[Bug bootstrap/86621] [9 regression] 'alloca' bound is unknown in tree-vect-slp.c:1437:16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86621 Rainer Orth changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #2 from Rainer Orth --- *** Bug 86624 has been marked as a duplicate of this bug. ***
[Bug bootstrap/86624] [9 Regression] GCC failed to bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86624 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ro at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Rainer Orth --- Already reported. *** This bug has been marked as a duplicate of bug 86621 ***
[Bug rtl-optimization/86625] New: funroll-loops doesn't unroll, producing >3x assembly and running 10x slower than manual complete unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86625 Bug ID: 86625 Summary: funroll-loops doesn't unroll, producing >3x assembly and running 10x slower than manual complete unrolling Product: gcc Version: 8.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: elrodc at gmail dot com Target Milestone: --- I wasn't sure where to put this. I posted in the Fortran gcc mailing list initially, but was redirected to bugzilla. I specified RTL-optimization as the component, because the manually unrolled version avoids register spills yet has 13 (unnecessary?) vmovapd instructions between registers, and the loop version is a behemoth of moving data in, out, and between registers. The failure of the loop might also fall under tree optimization? For that reason, completely unrolling the loop actually results in over 3x less assembly than the loop. Unfortunately, funroll-loops did not complete unroll, making the manual unrolling necessary. Assembly is identical whether or not funroll-loops is used. Adding the directive: !GCC$ unroll 31 does lead to complete unrolling, but also use of xmm registers instead of zmm, and thus massive amounts of spilling (and probably extremely slow code -- did not benchmark). Here is the code (a 16x32 * 32x14 matrix multiplication kernel for avx-512 [the 32 is arbitrary]), sans directive: https://github.com/chriselrod/JuliaToFortran.jl/blob/master/fortran/kernels.f90 I compiled with: gfortran -Ofast -march=skylake-avx512 -mprefer-vector-width=512 -funroll-loops -S -shared -fPIC kernels.f90 -o kernels.s resulting in this assembly (without the directive): https://github.com/chriselrod/JuliaToFortran.jl/blob/master/fortran/kernels.s The manually unrolled version has 13 vmovapd instructions that look unnecessary (like a vfmadd should've been able to place the answer in the correct location?). 8 of them move from one register to another, and 5 look something like: vmovapd%zmm20, 136(%rsp) I suspect there should ideally be 0 of these? If not, I'd be interested in learning more about why. This at least seems like an RTL optimization bug/question. The rest of the generated code looks great to me. Repeated blocks of only: 2x vmovupd 7x vbroadcastsd 14x vfmadd231pd In the looped code, however, the `vfmadd231pd` instructions are a rare sight between all the register management. The loop code begins at line 1475 in the assembly file. While the manually unrolled code benchmarked at 135ns, the looped version took 1.4 microseconds on my computer. Trying to understand more about what it's doing: - While the manually unrolled code has the expected 868 = (16/8)*(32-1)*14 vfmadds for the fully unrolled code, the looped version has two blocks of 224 = (16/8)*X*14, where X = 8, indicating it is partially unrolling the loop. One of them is using xmm registers instead of zmm, so it looks like the compiler mistakenly things smaller vectors may be needed to clean up something? (Maybe it is trying to vectorize across loop iterations, rather than within, in some weird way? I don't know why it'd be using all those vpermt2pd, otherwise.)
[Bug bootstrap/86624] New: [9 Regression] GCC failed to bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86624 Bug ID: 86624 Summary: [9 Regression] GCC failed to bootstrap Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: msebor at gcc dot gnu.org Target Milestone: --- Target: i686-pc-linux-gnu On Linux/i686, r262910 caused: In file included from /export/project/git/gcc-regression/gcc/gcc/system.h:691, from /export/project/git/gcc-regression/gcc/gcc/tree-vect-slp.c:23: /export/project/git/gcc-regression/gcc/gcc/tree-vect-slp.c: In function \u2018_slp_tree* vect_build_slp_tree_2(vec_info*, vec, unsigned int, poly_uint64*, vec<_slp_tree*>*, bool*, unsigned int*, unsigned int*, unsigned int)\u2019: /export/project/git/gcc-regression/gcc/gcc/../include/libiberty.h:722:36: error: \u2018alloca\u2019 bound is unknown [-Werror=alloca-larger-than=] # define alloca(x) __builtin_alloca(x) ^~~ /export/project/git/gcc-regression/gcc/gcc/../include/libiberty.h:356:33: note: in expansion of macro \u2018alloca\u2019 #define XALLOCAVEC(T, N) ((T *) alloca (sizeof (T) * (N))) ^~ /export/project/git/gcc-regression/gcc/gcc/tree-vect-slp.c:1437:16: note: in expansion of macro \u2018XALLOCAVEC\u2019 bool *tem = XALLOCAVEC (bool, group_size); ^~ make[3]: *** [Makefile:1112: tree-vect-slp.o] Error 1 make[2]: *** [Makefile:4647: all-stage2-gcc] Error 2 make[1]: *** [Makefile:21362: stage2-bubble] Error 2
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #36 from The Written Word --- (In reply to The Written Word from comment #35) > I am trying to build 4.9.4 with a patched 4.7.4 and am running into the > following failure: > /opt/build/china/gcc-4.9.4/.obj/./gcc/xgcc > -B/opt/build/china/gcc-4.9.4/.obj/./gcc/ > -B/opt/build/gcc49/ia64-hp-hpux11.31/bin/ > -B/opt/build/gcc49/ia64-hp-hpux11.31/lib/ -isystem > /opt/build/gcc49/ia64-hp-hpux11.31/include -isystem > /opt/build/gcc49/ia64-hp-hpux11.31/sys-include-g -O2 -O2 -g -O2 > -DIN_GCC-DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wno-narrowing > -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include -g > -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -I. -I. -I../.././gcc > -I/opt/build/china/gcc-4.9.4/libgcc -I/opt/build/china/gcc-4.9.4/libgcc/. > -I/opt/build/china/gcc-4.9.4/libgcc/../gcc > -I/opt/build/china/gcc-4.9.4/libgcc/../include -DHAVE_CC_TLS -o emutls.o > -MT emutls.o -MD -MP -MF emutls.dep -fexceptions -c > /opt/build/china/gcc-4.9.4/libgcc/emutls.c -fvisibility=hidden -DHIDE_EXPORTS > /opt/build/china/gcc-4.9.4/libgcc/emutls.c: In function > '__emutls_get_address': > /opt/build/china/gcc-4.9.4/libgcc/emutls.c:188:1: internal compiler error: > in simplify_subreg, at simplify-rtx.c:5917 > } > ^ > > Should I build this with -O0 as well? I can build 4.9.3 on HP-UX 11.31/IA but not 4.9.4. So, looks like something changed to break the build in 4.9.4.
[Bug tree-optimization/86622] [9 Regression] incorrect strlen of array of array plus variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622 --- Comment #6 from Martin Sebor --- Sorry, I didn't give enough details in the report. As discussed in the gcc-patches thread referenced in comment #0, the bug is latent on current trunk. It only manifests itself when the fix for bug 86532 is applied.
[Bug bootstrap/86621] [9 regression] 'alloca' bound is unknown in tree-vect-slp.c:1437:16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86621 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-21 CC||jakub at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- i686-linux bootstrap is broken too the same way.
[Bug bootstrap/28756] `make install` is broken, doesn't install `gcc` when program_prefix == "${triplet}-"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28756 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #5 from nightstrike --- Should this be closed as invalid?
[Bug tree-optimization/69224] [6/7 Regression] -Warray-bounds false positive with -O3 and struct pointer parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69224 --- Comment #11 from nightstrike --- Will this be back ported to 6 and 7?
[Bug tree-optimization/86622] [9 Regression] incorrect strlen of array of array plus variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622 --- Comment #5 from U.Mutlu --- I have to correct myself in #2 and #3. The code is correct, and should return n=6.
[Bug tree-optimization/86622] [9 Regression] incorrect strlen of array of array plus variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622 --- Comment #4 from U.Mutlu --- gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) gives the same result as v9: p=123456 n=6
[Bug tree-optimization/86622] [9 Regression] incorrect strlen of array of array plus variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622
--- Comment #3 from U.Mutlu ---
I just tested it with v9:
#include
static const char a[3][8] = { "1234", "12345", "123456" };
int main ()
{
volatile int i = 1;
const char* p = *([1] + i);
int n = __builtin_strlen (p);
printf("p=%s n=%d\n", p, n);// p=123456 n=6
if (n != 6)
__builtin_abort ();
}
Hmm. I would have expected something different, along the lines of
p=[1][1]...
The question is, which result is correct?
[Bug tree-optimization/86622] [9 Regression] incorrect strlen of array of array plus variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622 U.Mutlu changed: What|Removed |Added CC||um at mutluit dot com --- Comment #2 from U.Mutlu --- I think there's no error. IMO the call is wrong as it tests the strlen of a single char (a[1][1], ie. '2'), which of course is bogus.
[Bug c++/86623] New: constexpr evaluation fails to give an error for modifying a const object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86623
Bug ID: 86623
Summary: constexpr evaluation fails to give an error for
modifying a const object
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at doublewise dot net
Target Milestone: ---
The following code is compiled by gcc with -std=c++17
constexpr bool f() {
int const a = 0;
const_cast(a) = 2;
return a == 0;
}
static_assert(f());
This should not be allowed because we modify a const value in a constant
expression.
Here is another example test case that does not use const_cast (and gives a
different answer in the return statement, but I don't think that's especially
relevant because it's undefined behavior anyway):
struct S {
int a = 1;
int * ptr =
};
constexpr bool f() {
auto const s = S{};
*s.ptr = 2;
return s.a == 2;
}
static_assert(f());
[Bug tree-optimization/86622] [9 Regression] incorrect strlen of array of array plus variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||wrong-code Last reconfirmed||2018-07-21 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Blocks||83819 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86532 Ever confirmed|0 |1 Summary|incorrect strlen of array |[9 Regression] incorrect |of array plus variable |strlen of array of array |offset |plus variable offset --- Comment #1 from Martin Sebor --- See also bug 86532 for another problem introduced into this area by r262522. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 [Bug 83819] [meta-bug] missing strlen optimizations
[Bug tree-optimization/86622] New: incorrect strlen of array of array plus variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622
Bug ID: 86622
Summary: incorrect strlen of array of array plus variable
offset
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
As discussed in https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01215.html, GCC
emits incorrect code for the following test case:
$ cat c.c && gcc c.c && ./a.out
static const char a[3][8] = { "1234", "12345", "123456" };
int main ()
{
volatile int i = 1;
int n = __builtin_strlen (*([1] + i));
if (n != 6)
__builtin_abort ();
}
Aborted (core dumped)
The root cause is the handling of POINTER_PLUS expressions in
string_constant(). The original code (before the handling of aggregates was
added in r262522) just dealt with string constants. The new code does much
more but doesn't get this case right in these cases.
[Bug bootstrap/86621] New: [9 regression] 'alloca' bound is unknown in tree-vect-slp.c:1437:16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86621 Bug ID: 86621 Summary: [9 regression] 'alloca' bound is unknown in tree-vect-slp.c:1437:16 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- Host: i386-pc-solaris2.11, sparc-sun-solaris2.11 Target: i386-pc-solaris2.11, sparc-sun-solaris2.11 Build: i386-pc-solaris2.11, sparc-sun-solaris2.11 Between 20180720 (r262899) and 20180721 (r262917), Solaris bootstrap broke like this: In file included from /vol/gcc/src/hg/trunk/local/gcc/system.h:691, from /vol/gcc/src/hg/trunk/local/gcc/tree-vect-slp.c:23: /vol/gcc/src/hg/trunk/local/gcc/tree-vect-slp.c: In function '_slp_tree* vect_build_slp_tree_2(vec_info*, vec, unsigned int, poly_uint64*, vec<_slp_tree*>*, bool*, unsigned int*, unsigned int*, unsigned int)': /vol/gcc/src/hg/trunk/local/gcc/../include/libiberty.h:722:36: error: 'alloca' bound is unknown [-Werror=alloca-larger-than=] # define alloca(x) __builtin_alloca(x) ^~~ /vol/gcc/src/hg/trunk/local/gcc/../include/libiberty.h:356:33: note: in expansion of macro 'alloca' #define XALLOCAVEC(T, N) ((T *) alloca (sizeof (T) * (N))) ^~ /vol/gcc/src/hg/trunk/local/gcc/tree-vect-slp.c:1437:16: note: in expansion of macro 'XALLOCAVEC' bool *tem = XALLOCAVEC (bool, group_size); ^~ This is almost certainly due to 2018-07-20 Martin Sebor PR middle-end/82063 * builtins.c (expand_builtin_alloca): Adjust. * calls.c (alloc_max_size): Simplify. * cgraphunit.c (cgraph_node::expand): Adjust. * common.opt (larger_than_size, warn_frame_larger_than): Remove variables. (frame_larger_than_size): Same. (-Wframe-larger-than, -Wlarger-than, -Wstack-usage): Change options to take a HOST_WIDE_INT argument and accept a byte-size suffix. Initialize. * doc/invoke.texi (GCC Command Options): Document option arguments. Explain byte-size arguments and suffixes. (-Wvla-larger-than, -Wno-alloc-size-larger-than): Update. (-Wno-alloca-larger-than, -Wno-vla-larger-than): Same. (-Wframe-larger-than, -Wlarger-than, -Wstack-usage): Same. * doc/options.texi (UInteger): Expand. (Host_Wide_Int, ByteSize): Document new properties. * final.c (final_start_function_1): Include sizes in an error message. * function.c (frame_offset_overflow): Same. * gimple-ssa-warn-alloca.c (pass_walloca::gate): Adjust. (alloca_call_type_by_arg): Change function argument to HOST_WIDE_INT. Diagnose unbounded alloca calls only for limits of less than PTRDIFF_MAX. (alloca_call_type): Adjust. Diagnose possibly out-of-bounds alloca calls and VLA size only for limits of less than PTRDIFF_MAX. Same for alloca(0). (pass_walloca::execute): Adjust. Diagnose alloca calls in loops only for limits of less than PTRDIFF_MAX. * langhooks-def.h (lhd_handle_option): Change function argument to HOST_WIDE_INT. * langhooks.c (lhd_handle_option): Same. * langhooks.h (handle_option): Same. * opt-functions.awk (switch_bit_fields): Handle Host_Wide_Int and ByteSize flags. (var_type, var_type_struct): Same. (var_set): Handle ByteSize flag. * optc-gen.awk: Add comments to output to ease debugging. Make use of HOST_WIDE_INT where appropriate. * opts-gen-save.awk: Use %lx to format unsigned long. * opth-gen.awk: Change function argument to HOST_WIDE_INT. * opts-common.c (integral_argument): Return HOST_WIDE_INT and add arguments. Parse bytes-size suffixes. (enum_arg_to_value): Change function argument to HOST_WIDE_INT. (enum_value_to_arg): Same. (decode_cmdline_option): Handle cl_host_wide_int. Adjust. (handle_option): Adjust. (generate_option): Change function argument to HOST_WIDE_INT. (cmdline_handle_error): Adjust. (read_cmdline_option): Change function argument to HOST_WIDE_INT. (set_option): Change function argument to HOST_WIDE_INT. (option_enabled): Handle cl_host_wide_int. (get_option_state): Handle CLVC_SIZE. (control_warning_option): Same. * opts.c (common_handle_option): Change function argument to HOST_WIDE_INT. Remove handling of OPT_Walloca_larger_than_ and OPT_Wvla_larger_than_. * opts.h (enum cl_var_type): Add an enumerator. * stor-layout.c (layout_decl): Print a more meaningful w
[Bug c++/86620] New: __attribute__((no inline)) gives incorrect warning with overloaded functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86620
Bug ID: 86620
Summary: __attribute__((no inline)) gives incorrect warning
with overloaded functions
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: shoup at cs dot nyu.edu
Target Milestone: ---
Input file GGG.cpp:
struct X;
void h(X&,X&);
inline void h(X&,int) {}
__attribute__((noinline)) void h(X&,X&) {}
Command line: g++ -c GGG.cpp
Output:
GGG.cpp:4:32: warning: declaration of 'void h(X&, X&)' with attribute
'noinline' follows inline declaration [-Wattributes]
__attribute__((noinline)) void h(X&,X&) {}
^
GGG.cpp:3:13: note: previous definition of 'void h(X&, int)' was here
inline void h(X&,int) {}
Commentary:
This warning seems incorrect.
Previous versions of GCC do not emit this warning, even with -Wall -Wextra.
[Bug c++/86619] New: Missed optimization opportunity with array aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86619
Bug ID: 86619
Summary: Missed optimization opportunity with array aliasing
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mickey.veksler at gmail dot com
Target Milestone: ---
// gcc version 9.0.0 20180720 (experimental)
// Compiled with -O3
int f(std::array & a, std::array & b)
{
a[0] = 1;
b[0] = 2;
return a[0];
}
Produces:
f(std::array&, std::array&):
mov DWORD PTR [rdi], 1
mov DWORD PTR [rsi], 2
mov eax, DWORD PTR [rdi]
ret
Instead of
mov DWORD PTR [rdi], 1
mov eax, 1
mov DWORD PTR [rsi], 2
ret
But this does not seem to be something that libstdc++ can do anything about.
Consider a simplified array implementation:
template
struct ar
{
T ar[size];
T [](size_t offset) { return ar[offset]; }
};
int f1(ar & a, ar & b)
{
a.ar[0] = 1;
b.ar[0] = 2;
return a.ar[0];
// This is perfect:
/*
mov DWORD PTR [rdi], 1
mov eax, 1
mov DWORD PTR [rsi], 2
ret
*/
}
// BUT:
int f2(ar & a, ar & b)
{
a[0] = 1;
b[0] = 2;
return a[0];
// Too conservative alias analysis
/*
mov DWORD PTR [rdi], 1
mov DWORD PTR [rsi], 2
mov eax, DWORD PTR [rdi]
*/
}
It seems that by returning a reference, operator[] makes the compiler lose the
fact that a and b can't alias.
I'm not a language lawyer, but the following also seems to be another lost
optimization opportunity for arrays. After all, a and b have different types:
int g(int ()[2], int ()[3])
{
a[0] = 1;
b[0] = 2;
return a[0];
/*
mov DWORD PTR [rdi], 1
mov DWORD PTR [rsi], 2
mov eax, DWORD PTR [rdi]
ret
*/
}
[Bug c/86617] [6/7/8/9 Regression] Volatile qualifier is ignored sometimes for unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86617
Alexander Monakov changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-07-21
CC||amonakov at gcc dot gnu.org
Summary|Volatile qualifier is |[6/7/8/9 Regression]
|ignored sometimes for |Volatile qualifier is
|unsigned char |ignored sometimes for
||unsigned char
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
Confirmed, 'unsigned short' is similarly mishandled, but not wider integer
types. gcc-4.9 got this right. Appears like over-eager folding in the frontend:
in the .original dump I get
{
u8 = u8 * 2;
u8 = u8, 0;
}
[Bug target/71045] [SH] gcc.dg/torture/pr68264.c -O0 and -Os failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71045 --- Comment #6 from U.Mutlu --- Another difference is: the passing normal compiler was built with itself (so to say, ie. built with v9), whereas the failing cross compiler was built with the default system compiler: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10+deb8u1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 4.9.2-10+deb8u1)
[Bug target/71045] [SH] gcc.dg/torture/pr68264.c -O0 and -Os failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71045 --- Comment #5 from U.Mutlu --- I just see a difference: Target: x86_64-linux-gnu Target: x86_64-linux The pr68264 fails in the latter case (built as a crosscompiler).
[Bug target/71045] [SH] gcc.dg/torture/pr68264.c -O0 and -Os failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71045 --- Comment #4 from U.Mutlu --- (In reply to Eric Gallager from comment #3) > (In reply to Oleg Endo from comment #2) > > (In reply to Kazumoto Kojima from comment #1) > > > (In reply to Oleg Endo from comment #0) > > > > Kaz, do you know what's going wrong there? Some silent wrong code > > > > related > > > > to fenv maybe? > > > > > > Maybe, though I have no idea for what is going on. > > > You can see that those tests fail on several other targets: > > > > > > powerpc-ibm-aix7.1.0.0 > > > https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg00925.html > > > x86_64-unknown-freebsd9.3 > > > https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg00932.html > > > i386-unknown-freebsd10.3 > > > https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg00919.html > > > > Oh, good to know. Thanks for checking. Probably we can close this PR as > > "invalid" after a while... > > U.Mutlu says it still fails here: > https://gcc.gnu.org/ml/gcc-help/2018-07/msg00179.html Today I discovered that with a gcc that was built normally on x86_64 it does not fail! So, we have 2 cases: gcc built as crosscompiler: pr68264 fails gcc built as non-crosscompiler: pr68264 passes The test command was: cd build-gcc rm -fr *.sum make check-gcc-c RUNTESTFLAGS="-a -v -v dg-torture.exp=pr68264.c" 2>&1 | tee /tmp/test_one.t And here are the compiler settings: 1.) normal build (with suffix "-latest", was built with many optimization flags): Executing on host: /data/sw/src/gcc_dev/my_build_dir_for_gcc/gcc/xgcc -v (timeout = 300) pid is 4079 -4079 waitres is 4079 exp8 0 0 output is Using built-in specs. COLLECT_GCC=/data/sw/src/gcc_dev/my_build_dir_for_gcc/gcc/xgcc COLLECT_LTO_WRAPPER=/usr/local/MY_gcc/gcc-latest_34_base_31__bootstrap0_strip1__binutils-latest1/libexec/gcc/x86_64-linux-gnu/9.0.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../gcc_trunk/configure -v --prefix=/usr/local/MY_gcc/gcc-latest_34_base_31__bootstrap0_strip1__binutils-latest1 --program-suffix=-latest --build=x86_64-linux-gnu --host=x86_64-linux-gnu --disable-multilib --enable-checking=release --enable-languages=c,c++ --enable-threads=posix --enable-lto --enable-plugin --enable-shared --with-build-config=bootstrap-lto --with-system-zlib --disable-nls --enable-libstdcxx-time=yes --enable-link-mutex --disable-bootstrap CC=gcc-latest GCC=gcc-latest CXX=g++-latest CC_FOR_BUILD=gcc-latest GCC_FOR_BUILD=gcc-latest CXX_FOR_BUILD=g++-latest CC_FOR_TARGET=gcc-latest GCC_FOR_TARGET=gcc-latest CXX_FOR_TARGET=g++-latest 'CXXFLAGS_FOR_BUILD= -fopt-info -pipe -Ofast-DCLS=64 -fpic -floop-nest-optimize --param simultaneous-prefetches=16 -fprefetch-loop-arrays -msse4.2 -mrecip=all -funroll-loops -fdelete-null-pointer-checks --param prefetch-latency=32 -ffast-math -ftree-vectorize -funsafe-math-optimizations -Wall -Wextra -Werror -Wpedantic -pedantic -g0 -DNDEBUG -Wno-pedantic -Wno-error -I/usr/include ' 'CXXFLAGS_FOR_TARGET= -fopt-info -pipe -Ofast -DCLS=64 -fpic -floop-nest-optimize --param simultaneous-prefetches=16 -fprefetch-loop-arrays -msse4.2 -mrecip=all -funroll-loops -fdelete-null-pointer-checks --param prefetch-latency=32 -ffast-math -ftree-vectorize -funsafe-math-optimizations -Wall -Wextra -Werror -Wpedantic -pedantic -g0 -DNDEBUG -Wno-pedantic -Wno-error -I/usr/include ' LDFLAGS=' -fopt-info -pipe -Ofast-DCLS=64 -fpic -floop-nest-optimize --param simultaneous-prefetches=16 -fprefetch-loop-arrays -msse4.2 -mrecip=all -funroll-loops -fdelete-null-pointer-checks --param prefetch-latency=32 -ffast-math -ftree-vectorize -funsafe-math-optimizations -Wall -Wextra -Werror -Wpedantic -pedantic -g0 -DNDEBUG -Wno-pedantic -Wno-error -I/usr/include -flto' --without-target-libbacktrace --disable-vtable-verify --enable-clocale=gnu --enable-default-pie --enable-gnu-unique-object --with-abi=m64 --with-default-libstdcxx-abi=new --with-tune=generic --with-gcc-arch=x86_64 --with-gnu-as --with-gnu-ld --enable-gnu-indirect-function CFLAGS='-fopt-info -pipe -Wall -Wextra -Werror -Wpedantic -pedantic -g0 -DNDEBUG -Ofast -Wno-pedantic -Wno-error -I/usr/include ' CPPFLAGS='-fopt-info -pipe -Wall -Wextra -Werror -Wpedantic -pedantic -g0 -DNDEBUG -Ofast -Wno-pedantic -Wno-error -I/usr/include ' CXXFLAGS='-fopt-info -pipe -Wall -Wextra -Werror -Wpedantic -pedantic -g0 -DNDEBUG -Ofast -Wno-pedantic -Wno-error -I/usr/include ' 'CFLAGS_FOR_BUILD=-fopt-info -pipe -Wall -Wextra -Werror -Wpedantic -pedantic -g0 -DNDEBUG -Ofast -Wno-pedantic -Wno-error -I/usr/include ' 'CFLAGS_FOR_TARGET=-fopt-info -pipe -Wall -Wextra -Werror -Wpedantic -pedantic -g0 -DNDEBUG -Ofast -Wno-pedantic -Wno-error -I/usr/include ' Thread model: posix gcc version 9.0.0 20180701 (experimental) [trunk revision 262287] (GCC) status 0
[Bug tree-optimization/68356] FAIL: gcc.dg/torture/pr68264.c -O* execution test on x86_64-apple-darwin1(0|4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356 --- Comment #15 from Iain Sandoe --- by coincidence (triaging Darwin bugs at the moment) I was looking at this last night. An alternative, for platforms with math_errhandling and which use MATH_ERREXCEPT, (Darwin and a couple of others) could be to arrange for the tests to check the exception conditions when MATH_ERREXCEPT is set in math_errhandling and errno otherwise (I was thinking of looking into adding an extra field to the TEST macro for the exception bit value). However, if there's not 1:1 mapping (it could be that the exception bits are more fine-grained), then perhaps better to skip the test and add a similar one that is keyed off the exception bits instead.
[Bug c/86618] tree-vect-stmts.c:3340: ubsan error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86618 --- Comment #2 from David Binderman --- gcc compiler flag -O3 required.
[Bug c/86618] tree-vect-stmts.c:3340: ubsan error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86618 David Binderman changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #1 from David Binderman --- svn blame says 262589 rsandifo vec_loop_masks *masks = _VINFO_MASKS (loop_vinfo);
[Bug c/86618] New: tree-vect-stmts.c:3340: ubsan error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86618
Bug ID: 86618
Summary: tree-vect-stmts.c:3340: ubsan error
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
The following C code
register struct a *b asm("%r15");
struct a {
double *c
} d() {
(*b).c[1] = copysign(1, (*b).c[1]);
(*b).c[0] = copysign(0, (*b).c[0]);
}
Seems to generate a new runtime error on a ubsan verison of gcc trunk
../results.262549.ubsan/bin/gcc
../results.262835.ubsan/bin/gcc
../../trunk/gcc/tree-vect-stmts.c:3340:19: runtime error: member access within
n
ull pointer of type 'struct _loop_vec_info'
So the error seems to appeared between revisions 262549 and 262835.
