[Bug tree-optimization/89043] strcat (strcpy (d, a), b) not folded to stpcpy (strcpy (d, a), b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89043 --- Comment #7 from Eric Gallager --- Anyways my point about bringing up which standards stpcpy() is in is to remind people to keep portability concerns in mind when doing this change. Please check the gnulib docs on stpcpy() for specifics: https://www.gnu.org/software/gnulib/manual/html_node/stpcpy.html
[Bug c/37874] gcc sometimes accepts attribute in identifier list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37874 Eric Gallager changed: What|Removed |Added Keywords||accepts-invalid --- Comment #6 from Eric Gallager --- (In reply to Eric Gallager from comment #5) > (In reply to Chris Lattner from comment #0) > > GCC rejects the former, but not the later. > > > > void f2(y, __attribute__(()) x); > > void f3(__attribute__(()) x, y); > > GCC can be made to reject f3() with -Werror: > > $ /usr/local/bin/gcc -c -Wall -Wextra -pedantic -Werror 37874.c > 37874.c:1:12: error: expected ‘)’ before ‘__attribute__’ > void f2(y, __attribute__(()) x); > ^ > 37874.c:2:1: error: parameter names (without types) in function declaration > [-Werror] > void f3(__attribute__(()) x, y); > ^~~~ > cc1: all warnings being treated as errors > > I see you fixed this for f4() at least for clang: > > $ /sw/opt/llvm-3.1/bin/clang-3.1 -c 37874.c > 37874.c:1:12: error: expected identifier > void f2(y, __attribute__(()) x); >^ > 37874.c:2:27: warning: type specifier missing, defaults to 'int' > [-Wimplicit-int] > void f3(__attribute__(()) x, y); > ~ ^ > 37874.c:2:30: warning: type specifier missing, defaults to 'int' > [-Wimplicit-int] > void f3(__attribute__(()) x, y); > ^ > 37874.c:3:9: error: expected parameter declarator > void f4(__attribute__(())); > ^ > 2 warnings and 2 errors generated. Since clang rejects this, I'm making this an accepts-invalid
[Bug c/26613] Corner case causes garbage to be output by -aux-info switch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26613 --- Comment #9 from Eric Gallager --- (In reply to Andrew Pinski from comment #8) > (In reply to Eric Gallager from comment #7) > > (In reply to Mark F. Haigh from comment #5) > > > Created attachment 11005 [details] > > > Fix for trunk (against 2006-03-03 CVS) > > > > Could you submit a newer version of this patch to the gcc-patches mailing > > list please? > > I doubt c-aux-info.c has changed in the last 10 years ... I tried applying it and the second hunk was rejected...
[Bug other/63613] dejagnu.h needs to be fix included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63613 Eric Gallager changed: What|Removed |Added CC||bkorb at gnu dot org --- Comment #13 from Eric Gallager --- (In reply to Eric Gallager from comment #12) > (In reply to David Malcolm from comment #11) > > Patch posted as https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00468.html > > Does this still apply? So after reviewing this thread, it looks like Jeff Law approved the patch, but Bruce Korb requested a minor tweak. It should be pretty easy to make Bruce's requested change; can you do that and resubmit, David? Or are we assuming that dejagnu 1.6 has been out long enough now that this bug doesn't really matter any longer?
[Bug tree-optimization/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106 --- Comment #9 from JunMa --- (In reply to JunMa from comment #7) > yes, the transformation in CDEC prevent the tail call optimization. let's > check the return stmt in CDEC pass. Sorry for the confused comment. As the discussion above, The cdce pass looks for calls to built-in functions that set errno and whose result is used. It tries to transform these calls into conditionally executes calls with a simple range check on the arguments which can detect most cases and the errno does not need to be set. The transform looks like: y = sqrt (x); ==> y = IFN_SQRT (x); if (__builtin_isless (x, 0)) sqrt (x); However when the call is in tail position, this transformation breaks tailcall optimizations, since the conditionally call does not have return value. This is what this PR tries to explain and fix. Alexander gives two suggestions: first: y = IFN_SQRT (x); if (__builtin_isless (x, 0)) y = sqrt (x); second(LLVM's approach): if (__builtin_isless (x, 0)) y = sqrt (x); else y = IFN_SQRT (x); So what I want to do here is looking for tailcall and transforming as first one. I did some hacks locally, but then I found gcc generated even worse code in 'y = IFN_SQRT' part: f: pxor %xmm1, %xmm1 movaps %xmm0, %xmm2 ucomiss %xmm0, %xmm1 sqrtss %xmm2, %xmm2 ja .L4 movaps %xmm2, %xmm0 ret .L4: jmp sqrtf Then I used LLVM's approach no matter call is in tail position or not, and it gives: f: pxor %xmm1, %xmm1 ucomiss %xmm0, %xmm1 ja .L4 sqrtss %xmm0, %xmm0 ret .L4: jmp sqrtf Also in comment 6, I did some test for LLVM's approach. Sorry for the confused comment again.
[Bug go/68931] gccgo fails to build using MUSL libc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68931 Daniel Santos changed: What|Removed |Added CC||daniel.santos at pobox dot com --- Comment #3 from Daniel Santos --- Confirmed. Also present with gcc 7.3.0 and musl 1.1.19 (in addition to some multiply defined structs)
[Bug fortran/85541] ICE with parameterized derived type (PDT) and allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85541 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #2 from Arseny Solokha --- I believe the following testcase demonstrates the same issue (I'll file a new PR if it doesn't): subroutine uc type z4(pj) integer, len :: pj end type z4 type tp(q6) integer, len :: q6 type(z4(q6)), pointer :: kz end type tp type(tp(:)), allocatable :: ng end subroutine uc % powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190421 -c y2s4yo8l.f90 f951: internal compiler error: Segmentation fault 0xd84686 crash_signal /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/toplev.c:326 0x7796dd insert_parameter_exprs /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/decl.c:3488 0x7796dd insert_parameter_exprs /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/decl.c:3468 0x7975c0 gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*, gfc_symbol*, int*), int) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/expr.c:5142 0x77cbdf gfc_get_pdt_instance(gfc_actual_arglist*, gfc_symbol**, gfc_actual_arglist**) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/decl.c:3907 0x782d25 gfc_match_decl_type_spec(gfc_typespec*, int) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/decl.c:4129 0x785471 gfc_match_data_decl() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/decl.c:5950 0x7e937b match_word /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/parse.c:65 0x7e937b decode_statement /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/parse.c:376 0x7ed141 next_free /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/parse.c:1241 0x7ed141 next_statement /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/parse.c:1473 0x7eeaec parse_spec /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/parse.c:3865 0x7f188f parse_progunit /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/parse.c:5680 0x7f28eb gfc_parse_file() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/parse.c:6234 0x84064e gfc_be_parse_file /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/f95-lang.c:204
[Bug tree-optimization/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #8 from JunMa ---
(In reply to Alexander Monakov from comment #6)
> Reopening and confirming, GCC's code looks less efficient than possible for
> no good reason.
>
> CDCE does
>
> y = sqrt (x);
> ==>
> y = IFN_SQRT (x);
> if (__builtin_isless (x, 0))
> sqrt (x);
>
> but it could do
>
> y = IFN_SQRT (x);
> if (__builtin_isless (x, 0))
> y = sqrt (x);
>
> (note two assignments to y)
>
what is the difference between this and LLVM's approach ?
> or to mimic LLVM's approach:
>
> if (__builtin_isless (x, 0))
> y = sqrt (x);
> else
> y = IFN_SQRT (x);
I have finished a patch which do as same as LLVM in cdce pass, and test with
case below:
#include
int main () {
float x = 1.0;
float y;
for (int i=0; i<1; i++) {
y += sqrtf (x+i);
}
return y;
}
And I've got, for x86-64 with O2:
# original asm of IFN_SQRT part
.L4:
pxor %xmm0, %xmm0
cvtsi2ssl %ebx, %xmm0
addss %xmm3, %xmm0
ucomiss %xmm0, %xmm4
movaps %xmm0, %xmm2
sqrtss %xmm2, %xmm2
ja .L7
and perf stat :
1,423,652,277 cycles#2.180 GHz
(83.31%)
1,121,862,980 stalled-cycles-frontend # 78.80% frontend cycles
idle (83.31%)
634,957,413 stalled-cycles-backend# 44.60% backend cycles
idle (66.62%)
1,102,109,423 instructions #0.77 insn per cycle
#1.02 stalled cycles per
insn (83.31%)
200,400,940 branches # 306.873 M/sec
(83.44%)
7,734 branch-misses #0.00% of all branches
(83.44%)
#transformed asm :
.L4:
pxor %xmm0, %xmm0
cvtsi2ssl %ebx, %xmm0
addss %xmm3, %xmm0
ucomiss %xmm0, %xmm2
ja .L8
sqrtss %xmm0, %xmm0
and perf stat:
1,418,560,722 cycles#2.180 GHz
(83.25%)
1,116,732,674 stalled-cycles-frontend # 78.72% frontend cycles
idle (83.25%)
674,837,417 stalled-cycles-backend# 47.57% backend cycles
idle (66.81%)
1,003,067,037 instructions #0.71 insn per cycle
#1.11 stalled cycles per
insn (83.41%)
200,619,151 branches # 308.272 M/sec
(83.40%)
5,637 branch-misses #0.00% of all branches
(83.28%)
The transformed case has less instructions and gets better performance which
looks good to me. However, one thing that I noticed is the original case gets
less 'stalled-cycles-backend', since its code has better ILP.
I'm not sure which approach is better.
Environment:
gcc version: gcc trunk@270488
OS: centos7.2
HW: Intel(R) Xeon(R) CPU E5-2430 0 @ 2.20GHz
[Bug middle-end/90238] Bogus warning from -Warray-bounds, triggered by zero-length character literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90238 --- Comment #5 from Rich Townsend --- (In reply to Steve Kargl from comment #4) > It's certainly confusing. gfortran.info includes > -Warray-bounds as a warning option, but there is no > description for the option. Grepping the gfortran > source code found the error was not coming from the > Fortran frontend. Grepping the GCC source finds > two instances of the warning string tree-vrp.c. I > know nothing of the middle-end code and how Fortran > strings are represented. Hopeefully, one the > middle-end developers can provide a clue to > suppressing the warning for Fortran strings. That might be nice. In the meantime, the workaround consists of passing blank strings ' ' instead of zero-length strings '', since the production code behaves the same either way. And for the write statement, write(*,*) does the same as write(*,*) '' cheers, Rich
[Bug debug/90231] ivopts causes iterator in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231 bin cheng changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org --- Comment #5 from bin cheng --- I will try to fix it for GCC10. Thanks
[Bug middle-end/90238] Bogus warning from -Warray-bounds, triggered by zero-length character literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90238 --- Comment #4 from Steve Kargl --- On Thu, Apr 25, 2019 at 12:41:10AM +, townsend at astro dot wisc.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90238 > > --- Comment #3 from Rich Townsend --- > (In reply to kargl from comment #2) > > -Warray-bounds is a generic GCC option, and is used in the > > middle end for reporting warnings. When you use this option > > it does not recognize that a Fortran string is not an array. > > So, it gleefully reports an array bounds option. In other > > words, either ignore the warning or stop using -Warray-bounds. > > Thanks for the quick response, Steve. I think I can figure a workaround that > allows us to continue using -Warray-bounds. > It's certainly confusing. gfortran.info includes -Warray-bounds as a warning option, but there is no description for the option. Grepping the gfortran source code found the error was not coming from the Fortran frontend. Grepping the GCC source finds two instances of the warning string tree-vrp.c. I know nothing of the middle-end code and how Fortran strings are represented. Hopeefully, one the middle-end developers can provide a clue to suppressing the warning for Fortran strings.
[Bug middle-end/90238] Bogus warning from -Warray-bounds, triggered by zero-length character literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90238 --- Comment #3 from Rich Townsend --- (In reply to kargl from comment #2) > -Warray-bounds is a generic GCC option, and is used in the > middle end for reporting warnings. When you use this option > it does not recognize that a Fortran string is not an array. > So, it gleefully reports an array bounds option. In other > words, either ignore the warning or stop using -Warray-bounds. Thanks for the quick response, Steve. I think I can figure a workaround that allows us to continue using -Warray-bounds. cheers, Rich
[Bug target/90088] 3 ops LEA should be avoided on Intel CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90088 --- Comment #6 from Sunil Pandey --- We look into this issue and tested lea vs lea equivalent on following processor. On Haswell/Broadwell/Skylake/CoffeeLake processors, lea is faster than alternative.
[Bug d/90086] libphobos: warning: type and size of dynamic symbol `fiber_switchContext' are not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90086 --- Comment #1 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Wed Apr 24 22:46:59 2019 New Revision: 270560 URL: https://gcc.gnu.org/viewcvs?rev=270560=gcc=rev Log: libphobos: Fix linker warning and SEGV in core.thread tests. The monolithic core/threadasm.S source has been removed, and split into multiple parts, one for each intended target CPU/OS. Added .type and .size directives for all asm implementations of fiber_switchContent and callWithStackShell where they were missing. libphobos/ChangeLog: 2019-04-25 Iain Buclaw PR d/90086 * m4/druntime/cpu.m4 (DRUNTIME_CPU_SOURCES): New macro. * configure.ac: Use it. * configure: Regenerate. * libdruntime/Makefile.am: Add new config sources to DRUNTIME_SOURCES_CONFIGURED. * libdruntime/Makefile.in: Regenerate. * libdruntime/config/aarch64/switchcontext.S: New file. * libdruntime/config/arm/switchcontext.S: New file. * libdruntime/config/common/threadasm.S: New file. * libdruntime/config/mingw/switchcontext.S: New file. * libdruntime/config/mips/switchcontext.S: New file. * libdruntime/config/powerpc/switchcontext.S: New file. * libdruntime/config/powerpc64/callwithstack.S: New file. * libdruntime/config/x86/switchcontext.S: New file. * libdruntime/core/threadasm.S: Remove. Added: trunk/libphobos/libdruntime/config/ trunk/libphobos/libdruntime/config/aarch64/ trunk/libphobos/libdruntime/config/aarch64/switchcontext.S trunk/libphobos/libdruntime/config/arm/ trunk/libphobos/libdruntime/config/arm/switchcontext.S trunk/libphobos/libdruntime/config/common/ trunk/libphobos/libdruntime/config/common/threadasm.S trunk/libphobos/libdruntime/config/mingw/ trunk/libphobos/libdruntime/config/mingw/switchcontext.S trunk/libphobos/libdruntime/config/mips/ trunk/libphobos/libdruntime/config/mips/switchcontext.S trunk/libphobos/libdruntime/config/powerpc/ trunk/libphobos/libdruntime/config/powerpc/switchcontext.S trunk/libphobos/libdruntime/config/powerpc64/ trunk/libphobos/libdruntime/config/powerpc64/callwithstack.S trunk/libphobos/libdruntime/config/x86/ trunk/libphobos/libdruntime/config/x86/switchcontext.S Removed: trunk/libphobos/libdruntime/core/threadasm.S Modified: trunk/libphobos/ChangeLog trunk/libphobos/configure trunk/libphobos/configure.ac trunk/libphobos/libdruntime/Makefile.am trunk/libphobos/libdruntime/Makefile.in trunk/libphobos/m4/druntime/cpu.m4
[Bug d/90086] libphobos: warning: type and size of dynamic symbol `fiber_switchContext' are not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90086 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- Fixed in r270560.
[Bug fortran/90237] Bogus warning from -Wdo-subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90237 --- Comment #2 from Steve Kargl --- On Wed, Apr 24, 2019 at 10:01:13PM +, tkoenig at gcc dot gnu.org wrote: > --- Comment #1 from Thomas Koenig --- > We should probably rename the option. It works as advertised: A renaming is probably not needed. A better description including a clearer statement about false-positives may be helpful. > `-Wdo-subscript' > Warn if an array subscript inside a DO loop could lead to an > out-of-bounds access even if the compiler cannot prove that the > statement is actually executed, in cases like > real a(3) > do i=1,4 > if (condition(i)) then > a(i) = 1.2 > end if > end do > This option is implied by `-Wextra'. > > > but people keep stumbling over it. > `-Wdo-subscript' Warn if an array subscript inside a DO loop could lead to an out-of-bounds access. This warning currently does not consider conditional statement that may prevent an out-of-bounds access. For example, a false-positive will be emitted for real a(3) do i=1,4 if (i > 1) then a(i-1) = 1.2 end if end do This option is implied by `-Wextra'. See also the -fcheck=bounds option.
[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #23 from qinzhao at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #7) > Created attachment 27869 [details] > Patch for adding merge-gcda > > here is the patch which adds merge-gcda . I don't add any testcases as it > is currently designed only for how Cavium's Simple-exec works in that each > core writes out its own gcda file. I recently found this bug due to a similar problem. looks like that there are two parts of work for this problem: 1. GCC's new feature to guarantee that all pre-merged files are saved with different names for different instances of the same process. 2. a merge tool to merge all the gcda files afterwards. from my understanding, the patch for the above 1 has been committed into GCC9. How about the patch for the above 2? has it been committed?
[Bug fortran/90237] Bogus warning from -Wdo-subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90237 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #1 from Thomas Koenig --- We should probably rename the option. It works as advertised: `-Wdo-subscript' Warn if an array subscript inside a DO loop could lead to an out-of-bounds access even if the compiler cannot prove that the statement is actually executed, in cases like real a(3) do i=1,4 if (condition(i)) then a(i) = 1.2 end if end do This option is implied by `-Wextra'. but people keep stumbling over it.
[Bug middle-end/90238] Bogus warning from -Warray-bounds, triggered by zero-length character literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90238 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 CC||kargl at gcc dot gnu.org Component|fortran |middle-end Severity|normal |enhancement --- Comment #2 from kargl at gcc dot gnu.org --- -Warray-bounds is a generic GCC option, and is used in the middle end for reporting warnings. When you use this option it does not recognize that a Fortran string is not an array. So, it gleefully reports an array bounds option. In other words, either ignore the warning or stop using -Warray-bounds.
[Bug fortran/90237] Bogus warning from -Wdo-subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90237 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 CC||kargl at gcc dot gnu.org Severity|normal |enhancement
[Bug fortran/90238] Bogus warning from -Warray-bounds, triggered by zero-length character literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90238 --- Comment #1 from Rich Townsend --- An even-simpler demo: -- program test_str_2 write(*,*) '' end program test_str_2 -- Compile with -O2 -Warray-bounds gives test_str_2.f90:3:0: write(*,*) '' Warning: array subscript 1 is above array bounds of 'character(kind=1)[1:0]' [-Warray-bounds] cheers, Rich
[Bug c++/90236] bogus error with auto non-type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90236 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Wed Apr 24 21:28:04 2019 New Revision: 270557 URL: https://gcc.gnu.org/viewcvs?rev=270557=gcc=rev Log: PR c++/90236 * g++.dg/cpp1z/nontype-auto16.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1z/nontype-auto16.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/90238] New: Bogus warning from -Warray-bounds, triggered by zero-length character literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90238
Bug ID: 90238
Summary: Bogus warning from -Warray-bounds, triggered by
zero-length character literal
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
The zero-length character literal following example program triggers a bogus
array-bounds warning:
--
program test_str
call foo('bar')
call foo('')
contains
subroutine foo (a)
character(*), intent(in) :: a
print *, a
end subroutine foo
end program test_str
--
Compiling with -O2 -Warray-bounds, the warning is:
test_str.f90:4:0:
call foo('')
Warning: array subscript 1 is above array bounds of 'character(kind=1)[1:0]'
[-Warray-bounds]
Compiling at -O1 or -O0 does not trigger the warning.
cheers,
Rich
[Bug fortran/90237] New: Bogus warning from -Wdo-subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90237 Bug ID: 90237 Summary: Bogus warning from -Wdo-subscript Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- I'm encountering a bogus subscript-in-loop warning triggered by -Wdo-subscript Example: -- program do_subscript_bug implicit none real:: a(10) integer :: i a = 0. do i = 1, 10 if (i > 1) then print *, a(i-1) endif end do end program do_subscript_bug -- Compiling with -Wdo-subscript gives this error: do_subscript_bug.f90:12:19: do_subscript_bug.f90:10:14: do i = 1, 10 2 do_subscript_bug.f90:12:19: print *, a(i-1) 1 Warning: Array reference at (1) out of bounds (0 < 1) in loop beginning at (2) [-Wdo-subscript] cheers, Rich
[Bug lto/90229] Interaction among -Wl,--as-needed and LTO results in an undefined symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90229
H.J. Lu changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from H.J. Lu ---
I can't reproduce it with binutils master branch and GCC 9:
[hjl@gnu-cfl-1 pr90229]$ cat x.ii
extern int FLAGS_verbose;
extern "C" void pthread_create(void);
void a(const char *b...) {
if (FLAGS_verbose) {
__builtin_va_list ap;
__builtin_va_start(ap, b);
}
}
void a() { pthread_create(); }
int main() { a(""); return 0; }
[hjl@gnu-cfl-1 pr90229]$ cat lib.ii
int FLAGS_verbose;
[hjl@gnu-cfl-1 pr90229]$ make
/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/ -B./ -g
-flto -c -o x.o x.ii
/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/ -B./ -g
-c -o lib.o lib.ii
/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/ -B./
-shared -g -o libx.so lib.o
/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/ -B./
-pthread -g -o x x.o libx.so -Wl,--as-needed
[hjl@gnu-cfl-1 pr90229]$
[Bug c++/90236] bogus error with auto non-type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90236
--- Comment #2 from Marek Polacek ---
Clearly it's this hunk:
@@ -6985,27 +7071,10 @@ convert_nontype_argument (tree type, tree expr,
tsubst_flags_t complain)
itself value-dependent, since what we want here is its address. */;
else
{
- if (!DECL_P (expr))
- {
- if (complain & tf_error)
- error ("%qE is not a valid template argument for type %qT "
- "because it is not an object with linkage",
- expr, type);
- return NULL_TREE;
- }
-
- /* DR 1155 allows internal linkage in C++11 and up. */
- linkage_kind linkage = decl_linkage (expr);
- if (linkage < (cxx_dialect >= cxx11 ? lk_internal : lk_external))
- {
- if (complain & tf_error)
- error ("%qE is not a valid template argument for type %qT "
- "because object %qD does not have linkage",
- expr, type, expr);
- return NULL_TREE;
- }
-
expr = build_address (expr);
+
+ if (invalid_tparm_referent_p (type, expr, complain))
+ return NULL_TREE;
}
if (!same_type_p (type, TREE_TYPE (expr)))
[Bug c++/90227] [9 Regression] trunk rejects polymake since r269965
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90227 --- Comment #3 from Jason Merrill --- Author: jason Date: Wed Apr 24 20:37:30 2019 New Revision: 270556 URL: https://gcc.gnu.org/viewcvs?rev=270556=gcc=rev Log: PR c++/90227 - error with template parameter packs. If require_all_args, we aren't waiting for more args to be deduced later. * pt.c (coerce_template_parms): Do add empty pack when require_all_args. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ62.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #89 from Zaak --- Anyone have a patch for 4.9? A user wants one, but I can't build 4.9 from source on Mojave.
[Bug d/89432] FAIL: libphobos.unittests/druntime/{static,shared}/core.time on CentOS 5.11, Linux 2.6.18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89432 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Iain Buclaw --- Upstream druntime has been patched to assume that only CLOCK_MONOTONIC and CLOCK_REALTIME exist on linux versions older than 2.6.39. Applied the fix, as well as what I posted to r270554.
[Bug c++/90186] optimizing options -O1 and -O2 produce different results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90186
--- Comment #2 from austin.card at torchtechnologies dot com ---
(In reply to Richard Biener from comment #1)
> Note that using #pragma pack(1) on struct Ipv4 makes u_short members not
> naturally aligned and thus code like
>
> void UpdateChecksum()
> {
> u_long sum(0);
>
> SetChecksum(0);
>
> u_short *buf = (u_short*)ip->Payload();
> u_long nwords = ip->PayloadSize() / 2;
>
> for (unsigned i = 0; i < nwords; ++i)
> {
>
> sum += ntohs(*buf++);
>
> dereferences pointers to u_short that might not be aligned to a 2 byte
> boundary.
>
> Confirmed though, even when using -fno-inline. -fno-strict-aliasing fixes
> it. Possibly the very same issue above - using u_short * to access memory
> with a different dynamic type. The same happens here:
>
> buf = (u_short*)
> nwords = 6;
>
> for (unsigned i = 0; i < nwords; ++i)
> {
>
> sum += ntohs(*buf++);
>
> ph is of type PseudoHeader. You cannot use lvalues of type u_short to
> refer to them.
So if this is an alignment issue, How does the #pragma pack(1) change the
alignment differently between option -O1 and -O2? Also in Udp.h if I uncomment
the dummy function at line 147, then the code produces the same output between
-O1 and -O2.
I have tried to produce the same result with other compilers:
clang++ -std=c+11 -O2 -o CheckSum main.cpp CheckSum.cpp
clang++ -std=c+11 -O1 -o CheckSum main.cpp CheckSum.cpp
does not have this problem.
And Microsoft VS2017 compiler does not have this problem between Debug and
Release.
Lastly, the code provided is computing the 16-bit checksum of a UDP packet
header contained in an IPv4 network packet. While the comment regarding
alignment of u_short members is in general correct, any misaligned members are
intended by the RFC standards.
[Bug c++/90236] bogus error with auto non-type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90236 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |7.5 --- Comment #1 from Marek Polacek --- g++7 also fails the same. (Thanks Hana for providing the testcase!)
[Bug c++/90236] New: bogus error with auto non-type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90236
Bug ID: 90236
Summary: bogus error with auto non-type template argument
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
Compiling this with g++8 and -std=c++17
struct foo { };
template void fnc() { }
void
test()
{
static constexpr foo a;
fnc();
}
results in
r.cc: In function ‘void test()’:
r.cc:9:10: error: no matching function for call to ‘fnc()’
fnc();
^
r.cc:3:30: note: candidate: ‘template > void fnc()’
template void fnc() { }
^~~
r.cc:3:30: note: template argument deduction/substitution failed:
r.cc:9:10: error: ‘a’ is not a valid template argument for type ‘const foo&’
because object ‘a’ does not have linkage
fnc();
^
This doesn't happen on trunk since r265789, so maybe we need to apply parts of
that commit to 8.
[Bug d/89432] FAIL: libphobos.unittests/druntime/{static,shared}/core.time on CentOS 5.11, Linux 2.6.18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89432 --- Comment #6 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Wed Apr 24 18:57:36 2019 New Revision: 270554 URL: https://gcc.gnu.org/viewcvs?rev=270554=gcc=rev Log: libphobos: Fix FAIL phobos.exp/core.time on CentOS 5.11, Linux 2.6.18 Merges upstream druntime e03164b5. Reviewed-on: https://github.com/dlang/druntime/pull/2581 libphobos/ChangeLog: 2019-04-24 Iain Buclaw PR d/89432 * testsuite/lib/libphobos.exp (check_effective_target_linux_pre_2639): New proc. * testsuite/libphobos.druntime/druntime.exp: Add compiler flag -fversion=Linux_Pre_2639 if target is linux_pre_2639. * testsuite/libphobos.druntime_shared/druntime_shared.exp: Likewise. Modified: trunk/libphobos/ChangeLog trunk/libphobos/libdruntime/MERGE trunk/libphobos/libdruntime/core/time.d trunk/libphobos/testsuite/lib/libphobos.exp trunk/libphobos/testsuite/libphobos.druntime/druntime.exp trunk/libphobos/testsuite/libphobos.druntime_shared/druntime_shared.exp
[Bug debug/90231] ivopts causes iterator in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231 --- Comment #4 from Jakub Jelinek --- I think the order doesn't matter in this case, as debug stmts can't have PHIs ATM and that is what you either immediately or soonish end up with. The only thing it changes is IMHO whether the D#1 appears in there or whether the second DEBUG i => is reset immediately, if you remove from end to start of the bb, then you first create D#1 that is the phi result + const and then reset that as it still refers to the PHI result, otherwise if you first remove the PHI result, you just reset whatever it refers to it. The point is that ivopts knows better and should before the removal of the IV remap it in debug stmt to something else.
[Bug c++/82171] Cant use std::declval in concept testing map operator[]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82171 Casey Carter changed: What|Removed |Added CC||Casey at Carter dot net --- Comment #4 from Casey Carter --- Likely a duplicate of 68781.
[Bug libffi/90146] Add support for NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90146 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- The second patch looks really weird, ld, ldblit () and LDBL_EPSILON already do (or the last one should, unless NetBSD float.h is buggy) have long double type, so there is no point in casting it to long double again.
[Bug libstdc++/90233] std::hash()(INFINITY) == std::hash()(0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90233 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #1) > Perhaps frexpl should be only used if isfinite and do something else > otherwise? Yes, I think that makes sense. The standard doesn't require different values for 0.0 and INFINITY but I think we should do it for QoI.
[Bug target/90235] New: Unnecessary save and restore frame pointer with AVX/AVX512 pseudo registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90235
Bug ID: 90235
Summary: Unnecessary save and restore frame pointer with
AVX/AVX512 pseudo registers
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, skpgkp1 at gmail dot com
Target Milestone: ---
From PR 90202:
[hjl@gnu-cfl-1 pr90202]$ cat x.ii
struct v {
int val[16];
};
struct v test(struct v a, struct v b) {
struct v res;
for (int i = 0; i < 16; i++)
res.val[i] = a.val[i] + b.val[i];
return res;
}
[hjl@gnu-cfl-1 pr90202]$ make CC=gcc
gcc -O3 -march=skylake -S x.ii
[hjl@gnu-cfl-1 pr90202]$ cat x.s
.file "x.ii"
.text
.p2align 4,,15
.globl _Z4test1vS_
.type _Z4test1vS_, @function
_Z4test1vS_:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rdi, %rax
movq%rsp, %rbp
.cfi_def_cfa_register 6
vmovdqu 16(%rbp), %ymm1
vmovdqu 48(%rbp), %ymm2
vpaddd 80(%rbp), %ymm1, %ymm0
vmovdqu %ymm0, (%rdi)
vpaddd 112(%rbp), %ymm2, %ymm0
vmovdqu %ymm0, 32(%rdi)
vzeroupper
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
Since there is
rtx
gen_reg_rtx (machine_mode mode)
{
rtx val;
unsigned int align = GET_MODE_ALIGNMENT (mode);
gcc_assert (can_create_pseudo_p ());
/* If a virtual register with bigger mode alignment is generated,
increase stack alignment estimation because it might be spilled
to stack later. */
if (SUPPORTS_STACK_ALIGNMENT
&& crtl->stack_alignment_estimated < align
&& !crtl->stack_realign_processed)
{
unsigned int min_align = MINIMUM_ALIGNMENT (NULL, mode, align);
if (crtl->stack_alignment_estimated < min_align)
crtl->stack_alignment_estimated = min_align;
}
and IRA has
frame_pointer_needed
= (! flag_omit_frame_pointer
|| (cfun->calls_alloca && EXIT_IGNORE_STACK)
/* We need the frame pointer to catch stack overflow exceptions if
the stack pointer is moving (as for the alloca case just above). */
|| (STACK_CHECK_MOVING_SP
&& flag_stack_check
&& flag_exceptions
&& cfun->can_throw_non_call_exceptions)
|| crtl->accesses_prior_frames
|| (SUPPORTS_STACK_ALIGNMENT && crtl->stack_realign_needed)
|| targetm.frame_pointer_required ());
generate AVX/AVX512 pseudo registers via gen_reg_rtx will mark frame
pointer as needed. Stack realignment is needed to
1. Align the outgoing stack.
2. Support aligned spill of AVX/AVX512 registers.
But we won't know if spill is needed before RA. As the result, we
save and restore frame pointer even if not needed. Since
(define_insn "mov_internal"
[(set (match_operand:VMOVE 0 "nonimmediate_operand"
"=v,v ,v ,m")
(match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand"
" C,BC,vm,v"))]
"TARGET_SSE
&& (register_operand (operands[0], mode)
|| register_operand (operands[1], mode))"
now supports both aligned and unaligned load/store of AVX/AVX512
registers, we can change gen_reg_rtx to
/* If a virtual register with bigger mode alignment is generated,
increase stack alignment estimation because it might be spilled
to stack later. */
if (SUPPORTS_STACK_ALIGNMENT
&& !SUPPORTS_MISALIGNED_SPILL
&& crtl->stack_alignment_estimated < align
&& !crtl->stack_realign_processed)
{
unsigned int min_align = MINIMUM_ALIGNMENT (NULL, mode, align);
if (crtl->stack_alignment_estimated < min_align)
crtl->stack_alignment_estimated = min_align;
}
[Bug libstdc++/90233] std::hash()(INFINITY) == std::hash()(0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90233 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- frexpl documentation says: If x is positive infinity (negative infinity), positive infinity (negative infinity) is returned, and the value of *exp is unspecified. Ditto for NaN (if std::hash::operator() needs to be meaningful for NaNs too). Perhaps frexpl should be only used if isfinite and do something else otherwise?
[Bug target/90234] New: 503.bwaves_r is 6% slower on Zen CPUs at -Ofast with native march/mtune than with generic ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90234 Bug ID: 90234 Summary: 503.bwaves_r is 6% slower on Zen CPUs at -Ofast with native march/mtune than with generic ones Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: x86_64-linux Target: x86_64-linux In my experiments on an EPYC CPU and GCC trunk r270364, 503.bwaves_r is over 6% slower at -Ofast when I supply -march=native =mtune=native than when I compile for generic x86_64. LNT sees 3.55% regression too: https://lnt.opensuse.org/db_default/v4/SPEC/spec_report/tuning perf stat and report of the generic (fast) binary run: Performance counter stats for 'numactl -C 0 -l specinvoke': 240411.714022 task-clock:u (msec) #0.999 CPUs utilized 0 context-switches:u#0.000 K/sec 0 cpu-migrations:u #0.000 K/sec 35189 page-faults:u #0.146 K/sec 757727387955 cycles:u #3.152 GHz (83.32%) 40175950077 stalled-cycles-frontend:u #5.30% frontend cycles idle (83.31%) 91872393105 stalled-cycles-backend:u # 12.12% backend cycles idle (83.37%) 2177387522561 instructions:u#2.87 insn per cycle #0.04 stalled cycles per insn (83.32%) 98299602685 branches:u# 408.880 M/sec (83.32%) 131591436 branch-misses:u #0.13% of all branches (83.36%) 240.668052943 seconds time elapsed # Samples: 960K of event 'cycles' # Event count (approx.): 755626377551 # # Overhead Samples Command Shared Object Symbol # . # 62.10%595840 bwaves_r bwaves_r_peak-gen mat_times_vec_ 13.91%133958 bwaves_r bwaves_r_peak-gen shell_ 12.40%119012 bwaves_r bwaves_r_peak-gen bi_cgstab_block_ 7.81% 75246 bwaves_r bwaves_r_peak-gen jacobian_ 2.11% 20290 bwaves_r bwaves_r_peak-gen flux_ 1.27% 12217 bwaves_r libc-2.29.so __memset_avx2_unaligned perf stat and report of the native (slow) binary run: Performance counter stats for 'numactl -C 0 -l specinvoke': 255695.249393 task-clock:u (msec) #0.999 CPUs utilized 0 context-switches:u#0.000 K/sec 0 cpu-migrations:u #0.000 K/sec 35604 page-faults:u #0.139 K/sec 800619530480 cycles:u #3.131 GHz (83.32%) 77320365388 stalled-cycles-frontend:u #9.66% frontend cycles idle (83.34%) 93389410778 stalled-cycles-backend:u # 11.66% backend cycles idle (83.33%) 1821704428841 instructions:u#2.28 insn per cycle #0.05 stalled cycles per insn (83.32%) 99885762475 branches:u# 390.644 M/sec (83.34%) 130710907 branch-misses:u #0.13% of all branches (83.34%) 255.958363704 seconds time elapsed # Samples: 1M of event 'cycles' # Event count (approx.): 804011318580 # # Overhead Samples Command Shared Object Symbol # . # 64.87%662574 bwaves_r bwaves_r_peak-nat mat_times_vec_ 12.75%130756 bwaves_r bwaves_r_peak-nat shell_ 11.48%117266 bwaves_r bwaves_r_peak-nat bi_cgstab_block_ 7.45% 76415 bwaves_r bwaves_r_peak-nat jacobian_ 1.92% 19701 bwaves_r bwaves_r_peak-nat flux_ 1.34% 13662 bwaves_r libc-2.29.so __memset_avx2_unaligned Examining the slow mat_times_vec_ further, perf claims that the following loop is the most sample-heavy: 0.01 |6c0:+->vmulpd (%r8,%rax,1),%xmm9,%xmm0 4.34 || vandnp (%r10,%rax,1),%xmm2,%xmm1 0.83 || vfmadd (%r15,%rax,1),%xmm11,%xmm1 1.35 || vfmadd (%r14,%rax,1),%xmm10,%xmm0 5.85 || vaddpd %xmm1,%xmm0,%xmm1 7.41 || vmulpd (%rsi,%rax,1),%xmm7,%xmm0 2.19 || vfmadd (%rdi,%rax,1),%xmm8,%xmm0 3.97 || vmovap %xmm0,%xmm12 0.07 || vmulpd (%r11,%rax,1),%xmm5,%xmm0 0.93 || vfmadd (%rcx,%rax,1),%xmm6,%xmm0 1.92 || vaddpd %xmm12,%xmm0,%xmm0 6.34 || vaddpd %xmm1,%xmm0,%xmm0 9.58 || vmovup %xmm0,(%r10,%rax,1) 0.49 || add
[Bug target/90193] [8 Regression] asm goto with TLS "m" input operand generates incorrect assembler in O1 and O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90193 Jakub Jelinek changed: What|Removed |Added Known to work||9.0 Summary|[8/9 Regression] asm goto |[8 Regression] asm goto |with TLS "m" input operand |with TLS "m" input operand |generates incorrect |generates incorrect |assembler in O1 and O2 |assembler in O1 and O2 Known to fail|9.0 | --- Comment #13 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/90193] [8/9 Regression] asm goto with TLS "m" input operand generates incorrect assembler in O1 and O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90193 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Wed Apr 24 15:49:36 2019 New Revision: 270550 URL: https://gcc.gnu.org/viewcvs?rev=270550=gcc=rev Log: PR target/90193 * rtl.c (classify_insn): Return JUMP_INSN for asm goto. * emit-rtl.c (try_split): Copy over REG_LABEL_TARGET. * gcc.target/i386/pr90193.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr90193.c Modified: trunk/gcc/ChangeLog trunk/gcc/emit-rtl.c trunk/gcc/rtl.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/90233] New: std::hash()(INFINITY) == std::hash()(0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90233
Bug ID: 90233
Summary: std::hash()(INFINITY) == std::hash()(0)
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
#include
#include
int main()
{
std::hash hd;
std::hash hl;
std::cout << hd(0) << ' ' << hd(INFINITY) << ' ' << hd(-INFINITY) << '\n';
std::cout << hl(0) << ' ' << hl(INFINITY) << ' ' << hl(-INFINITY) << '\n';
}
Output:
0 3377428025507081056 6848127736350075394
0 0 0
[Bug debug/90232] gcc drops top-level dies with -fdebug-types-section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90232 --- Comment #1 from Tom de Vries --- With this demonstrator patch: ... diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index b9a624e1ac7..1e818973fae 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -8400,10 +8400,11 @@ generate_skeleton (dw_die_ref die) /* If this type definition is nested inside another type, and is not an instantiation of a template, always leave at least a declaration in its place. */ - if (die->die_parent != NULL - && is_type_die (die->die_parent) - && !is_template_instantiation (die)) -node.new_die = clone_as_declaration (die); + if (true || (die->die_parent != NULL + && is_type_die (die->die_parent) + && !is_template_instantiation (die))) + node.new_die = clone_as_declaration (die); + node.new_die->die_perennial_p = 1; generate_skeleton_bottom_up (); return node.new_die; ... instead we get the desired: ... <0>: Abbrev Number: 5 (DW_TAG_compile_unit) DW_AT_name: (indirect string, offset: 0x1f8): 36.c <1>: Abbrev Number: 6 (DW_TAG_structure_type) DW_AT_name: s DW_AT_signature : signature: 0xfd1462823bb6f7b7 <1><106>: Abbrev Number: 7 (DW_TAG_subprogram) <107> DW_AT_name: (indirect string, offset: 0x2b8): main <2><124>: Abbrev Number: 8 (DW_TAG_variable) <125> DW_AT_name: a <12a> DW_AT_type: <0xf4> Contents of the .debug_types section: Signature: 0xfd1462823bb6f7b7 <1><1d>: Abbrev Number: 2 (DW_TAG_structure_type) <1e> DW_AT_name: s ... and: ... <0><13e>: Abbrev Number: 5 (DW_TAG_compile_unit) <144> DW_AT_name: (indirect string, offset: 0x2bd): 36b.c <1><160>: Abbrev Number: 6 (DW_TAG_structure_type) <161> DW_AT_name: s <163> DW_AT_signature : signature: 0x534310fbefba324d <1><172>: Abbrev Number: 7 (DW_TAG_subprogram) <173> DW_AT_name: f <2><18a>: Abbrev Number: 8 (DW_TAG_variable) <18b> DW_AT_name: b Contents of the .debug_types section: Signature: 0x534310fbefba324d <1><59>: Abbrev Number: 2 (DW_TAG_structure_type) <5a> DW_AT_name: s ...
[Bug debug/90231] ivopts causes iterator in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231 --- Comment #3 from rguenther at suse dot de --- On April 24, 2019 5:04:37 PM GMT+02:00, "jakub at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231 > >Jakub Jelinek changed: > > What|Removed |Added > > CC||amker at gcc dot gnu.org >Version|8.3.1 |9.0 > >--- Comment #1 from Jakub Jelinek --- >Alex or Bin, could you please have a look into this during GCC 10 >stage1? Might be also an issue of IVOs own DCE not working in optimal order for debug temp creation.
[Bug debug/90232] New: gcc drops top-level dies with -fdebug-types-section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90232
Bug ID: 90232
Summary: gcc drops top-level dies with -fdebug-types-section
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
[ Spinoff bug from gdb PR
https://sourceware.org/bugzilla/show_bug.cgi?id=14148#c3 ]
Consider two-file test-case 36:
...
$ cat 36.c
struct s { int i; };
extern void f (void);
int main (void) {
struct s a;
f ();
return 0;
}
$ cat 36b.c
struct s { int j; };
void f (void) {
struct s b;
}
...
Compiled like this:
...
$ gcc -fdebug-types-section -o 36 36.c 36b.c -Wall -g
...
Without -fdebug-types-section, for 36.c we have the struct type s as top-level
die, and as type of main variable a:
...
<0>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_name: (indirect string, offset: 0x1f8): 36.c
<1>: Abbrev Number: 2 (DW_TAG_structure_type)
DW_AT_name: s
<1><112>: Abbrev Number: 5 (DW_TAG_subprogram)
<113> DW_AT_name: (indirect string, offset: 0x1fd): main
<2><130>: Abbrev Number: 6 (DW_TAG_variable)
<131> DW_AT_name: a
<136> DW_AT_type: <0xf4>
...
with the same pattern for 36b.c:
...
<0><14a>: Abbrev Number: 1 (DW_TAG_compile_unit)
<150> DW_AT_name: (indirect string, offset: 0x261): 36b.c
<1><16c>: Abbrev Number: 2 (DW_TAG_structure_type)
<16d> DW_AT_name: s
<1><18a>: Abbrev Number: 5 (DW_TAG_subprogram)
<18b> DW_AT_name: f
<2><1a2>: Abbrev Number: 6 (DW_TAG_variable)
<1a3> DW_AT_name: b
<1a8> DW_AT_type: <0x16c>
...
With -fdebug-types-section, we have struct s in .debug_types with only a
reference from the variable for 36.c:
...
<1>: Abbrev Number: 6 (DW_TAG_subprogram)
DW_AT_name: (indirect string, offset: 0x272): main
<2><119>: Abbrev Number: 7 (DW_TAG_variable)
<11a> DW_AT_name: a
<11f> DW_AT_type: signature: 0xfd1462823bb6f7b7
Contents of the .debug_types section:
Signature: 0xfd1462823bb6f7b7
<1><1d>: Abbrev Number: 2 (DW_TAG_structure_type)
<1e> DW_AT_name: s
...
and the same for 36b.c:
...
<1><160>: Abbrev Number: 6 (DW_TAG_subprogram)
<161> DW_AT_name: f
<2><178>: Abbrev Number: 7 (DW_TAG_variable)
<179> DW_AT_name: b
<17e> DW_AT_type: signature: 0x534310fbefba324d
Contents of the .debug_types section:
Signature: 0x534310fbefba324d
<1><59>: Abbrev Number: 2 (DW_TAG_structure_type)
<5a> DW_AT_name: s
...
So, AFAICT gcc drops the top-level struct s dies.
[Bug debug/90231] ivopts causes iterator in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231 --- Comment #2 from Alexandre Oliva --- that's a known (to me) problem; it's mentioned in the gOlogy report, and IIRC I even highlighted it in the slides about it I spent some time looking for a low-hanging fix a while ago, but came out empty-handed a fix will likely take involvement by someone a lot more familiar with ivopts than I am (or putting in the time required to become one ;-)
[Bug libstdc++/90220] std::any_cast misbehaves for function and array types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |7.5 --- Comment #5 from Jonathan Wakely --- Both examples are fixed on trunk. I plan to backport the fixes.
[Bug libstdc++/90220] std::any_cast misbehaves for function and array types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Wed Apr 24 15:17:43 2019 New Revision: 270547 URL: https://gcc.gnu.org/viewcvs?rev=270547=gcc=rev Log: PR libstdc++/90220 Fix std::any_cast for array types Although the std::any constructors use decay_t to determine the type of the contained value, std::any_cast should use the un-decayed type (and so always fail for function and array types that decay to pointers). Using remove_cv_t is correct, because the condition for std::any_cast to return non-null is operand.type() == typeid(T) and typeid ignores top-level cv-qualifiers. PR libstdc++/90220 * include/std/any (__any_caster): Use remove_cv_t instead of decay_t. Avoid a runtime check for types that can never be stored in std::any. * testsuite/20_util/any/misc/any_cast.cc: Test std::any_cast with array types. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/any trunk/libstdc++-v3/testsuite/20_util/any/misc/any_cast.cc
[Bug c++/90227] [9 Regression] trunk rejects polymake since r269965
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90227 --- Comment #2 from Jakub Jelinek --- icc also accepts #c1 with -std=c++14.
[Bug d/89432] FAIL: libphobos.unittests/druntime/{static,shared}/core.time on CentOS 5.11, Linux 2.6.18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89432 --- Comment #5 from Iain Buclaw --- Created attachment 46240 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46240=edit patch for pr89432 (In reply to Uroš Bizjak from comment #4) > Created attachment 46182 [details] > Proposed patch > > Attached patch introduces DRUNTIME_OS_LINUX_PRE_2639 function that detects > linux version < 2.6.39 and sets LINUX_PRE_2639_FLAG. However, as shown in > the Comment #0, CentOS 5.11 (kernel 2.6.18) lacks several other clock types > besides CLOCK_BOOTTIME, so the patch does not fix the failure for these > older kernels. > > I doubt it is worth pushing this any further, so I'll just attach the patch > here for reference. Now that the unit-test runner has been hauled out properly into dejagnu, I was thinking of this being the better way.
[Bug debug/90231] ivopts causes iterator in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231 Jakub Jelinek changed: What|Removed |Added CC||amker at gcc dot gnu.org Version|8.3.1 |9.0 --- Comment #1 from Jakub Jelinek --- Alex or Bin, could you please have a look into this during GCC 10 stage1?
[Bug debug/90231] New: ivopts causes iterator in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
Bug ID: 90231
Summary: ivopts causes iterator in the loop
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org, jakub at gcc dot gnu.org,
rguenth at gcc dot gnu.org, rsandifo at gcc dot gnu.org,
unassigned at gcc dot gnu.org
Depends on: 90197
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #90197 +++
In the PR90197 testcase with -g -O2 ivopts results in bad debug info quality,
at least on x86_64-linux.
__attribute__((noipa))
void
test (unsigned int *dst, unsigned int base, int count)
{
for (int i = 0; i < count; ++i, base += 15)
dst[i] = base;
}
int
main (void)
{
unsigned int dst[100];
test (dst, 0x4000, 100);
}
Before ivopts pass, the IL is:
[local count: 105119324]:
[local count: 955630224]:
# base_17 = PHI
# i_18 = PHI <0(5), i_12(6)>
# DEBUG i => i_18
# DEBUG base => base_17
# DEBUG BEGIN_STMT
_1 = (long unsigned int) i_18;
_2 = _1 * 4;
_3 = dst_10(D) + _2;
*_3 = base_17;
# DEBUG BEGIN_STMT
i_12 = i_18 + 1;
# DEBUG i => i_12
base_13 = base_17 + 15;
# DEBUG base => base_13
# DEBUG i => i_12
# DEBUG base => base_13
# DEBUG BEGIN_STMT
if (count_9(D) > i_12)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 850510900]:
goto ; [100.00%]
The IVOPTS pass keeps the base IV and replaces the i IV with a different one:
[local count: 105119324]:
ivtmp.11_5 = (unsigned long) dst_10(D);
_16 = (unsigned int) count_9(D);
_15 = _16 * 15;
_14 = base_7(D) + _15;
[local count: 955630224]:
# base_17 = PHI
# ivtmp.11_20 = PHI
# DEBUG i => NULL
# DEBUG base => base_17
# DEBUG BEGIN_STMT
_4 = (void *) ivtmp.11_20;
MEM[base: _4, offset: 0B] = base_17;
# DEBUG BEGIN_STMT
# DEBUG D#1 => NULL
# DEBUG i => D#1
base_13 = base_17 + 15;
# DEBUG base => base_13
# DEBUG i => D#1
# DEBUG base => base_13
# DEBUG BEGIN_STMT
ivtmp.11_6 = ivtmp.11_20 + 4;
if (base_13 != _14)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 850510900]:
goto ; [100.00%]
The problem is that i => NULL and D#1 => NULL; while we don't have any register
holding the i value at runtime through iterations of the loop, I would hope
that ivopts pass has enough information on how to express one IV from another
IV and should be able to emit that information in a form of debug stmts into
the IL. In this case, I guess it can either say that the i at the beginning of
the loop is either (int) ((ivtmp.11_20 - (unsigned long) dst_10(D)) / 4), or
(int) ((base_17 - base_7(D)) / 15). Even if those dst_10(D) or base_7(D)
aren't really used later in the function (that is the case of both in this
function), those can be still live in some register (e.g. count argument is
live in a register) or memory and even if it doesn't, in some cases it could be
expressed through DW_OP_entry_value (the callers sets those up in this
testcase).
It could be as simple as replacing the debug uses of i_18 (the IV that is going
away) with a debug temp decl, either
# DEBUG D#2 = ivtmp.11_20 - ivtmp.11_5
# DEBUG D#3 = D#2 / 4
# DEBUG i => D#3
or similar and let the normal debug handling code do the rest when ivtmp.11_5
is no longer needed or optimized away etc.
I guess one needs to properly think if the to be removed IV is actually
properly expressible through some other IV, in the ivtmp case when that one is
64-bit and the IV is 32-bit and division just by 4 that is clearly the case, in
other cases we could use assumption that signed integer overflow is UB etc.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197
[Bug 90197] [8/9 Regression] Cannot step through simple loop at -O -g
[Bug target/88496] Unnecessary stack adjustment with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88496
--- Comment #1 from H.J. Lu ---
From PR 90202:
[hjl@gnu-cfl-1 pr90202]$ cat x.ii
struct v {
int val[16];
};
struct v test(struct v a, struct v b) {
struct v res;
for (int i = 0; i < 16; i++)
res.val[i] = a.val[i] + b.val[i];
return res;
}
[hjl@gnu-cfl-1 pr90202]$ make CC=gcc
gcc -O3 -march=skylake -S x.ii
[hjl@gnu-cfl-1 pr90202]$ cat x.s
.file "x.ii"
.text
.p2align 4,,15
.globl _Z4test1vS_
.type _Z4test1vS_, @function
_Z4test1vS_:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rdi, %rax
movq%rsp, %rbp
.cfi_def_cfa_register 6
vmovdqu 16(%rbp), %ymm1
vmovdqu 48(%rbp), %ymm2
vpaddd 80(%rbp), %ymm1, %ymm0
vmovdqu %ymm0, (%rdi)
vpaddd 112(%rbp), %ymm2, %ymm0
vmovdqu %ymm0, 32(%rdi)
vzeroupper
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
[Bug target/59888] Darwin linker error "illegal text-relocation" with -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888 Zaak changed: What|Removed |Added CC||zbeekman at gmail dot com --- Comment #15 from Zaak --- This is preventing gtk-fortran from compiling on macOS with GCC 8.3, AFAICT. cd /tmp/gtk-fortran-20190424-36870-ggjnvc/gtk-fortran-19.04.gtk3.24.8/build/src && /usr/local/Cellar/cmake/3.14.3/bin/cmake -E cmake_link_script CMakeFiles/gtk-fortran_shared.dir/link.txt --verbose=1 /usr/local/bin/gfortran -pthread -O2 -fPIC -dynamiclib -Wl,-headerpad_max_install_names -compatibility_version 0.1.0 -current_version 0.1.0 -o libgtk-3-fortran.0.1.dylib -install_name @rpath/libgtk-3-fortran.0.1.dylib CMakeFiles/gtk-fortran_object.dir/atk-auto.f90.o CMakeFiles/gtk-fortran_object.dir/cairo-auto.f90.o CMakeFiles/gtk-fortran_object.dir/gdk-auto.f90.o CMakeFiles/gtk-fortran_object.dir/gdk-pixbuf-auto.f90.o CMakeFiles/gtk-fortran_object.dir/glib-auto.f90.o CMakeFiles/gtk-fortran_object.dir/gtk.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-container.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-button.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-entry.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-tree.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-menu.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-combobox.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-spin-slider.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-chooser.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-dialog.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-progress.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-accelerator.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-infobar.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-assistant.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-misc.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-draw-hl.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-sup.f90.o CMakeFiles/gtk-fortran_object.dir/gdk-pixbuf-hl.f90.o CMakeFiles/gtk-fortran_object.dir/pango-auto.f90.o CMakeFiles/gtk-fortran_object.dir/gdkevents-auto3.f90.o CMakeFiles/gtk-fortran_object.dir/unixonly-auto.f90.o -L/usr/local/Cellar/plplot/5.14.0_1/lib -Wl,-rpath,/usr/local/Cellar/plplot/5.14.0_1/lib /usr/local/lib/libatk-1.0.dylib /usr/local/lib/libcairo.dylib /usr/local/lib/libgdk-3.0.dylib /usr/local/lib/libgdk_pixbuf-2.0.dylib /usr/local/lib/libglib-2.0.dylib /usr/local/lib/libgio-2.0.dylib /usr/local/lib/libgobject-2.0.dylib /usr/local/lib/libgtk-3.0.dylib /usr/local/lib/libpango-1.0.dylib ld: illegal text-relocation to '_hl_gtk_listn_edit_cb' in CMakeFiles/gtk-fortran_object.dir/gtk-hl-tree.f90.o from 'lC72' in CMakeFiles/gtk-fortran_object.dir/gtk-hl-tree.f90.o for architecture x86_64 collect2: error: ld returned 1 exit status make[2]: *** [src/libgtk-3-fortran.0.1.dylib] Error 1 make[1]: *** [src/CMakeFiles/gtk-fortran_shared.dir/all] Error 2 make: *** [all] Error 2
[Bug d/88654] Hangs in libphobos testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88654 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Iain Buclaw --- (In reply to Jakub Jelinek from comment #0) > 3) and, if libcurl isn't available, I think it would be better to skip the > test as UNSUPPORTED, i.e. add some effective-target that tests if libcurl is > available and if it fails, don't even try to run the test This has been done in r270545, nothing else left do here as far as I can see.
[Bug d/88654] Hangs in libphobos testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88654 --- Comment #8 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Wed Apr 24 14:17:34 2019 New Revision: 270545 URL: https://gcc.gnu.org/viewcvs?rev=270545=gcc=rev Log: libphobos: Skip curl tests if libcurl is not installed on the target. libphobos/ChangeLog: 2019-04-24 Iain Buclaw PR d/88654 * testsuite/lib/libphobos.exp (libphobos-dg-test): Check libphobos_skipped_test_p before running test. (libphobos-dg-prune): New proc. (libphobos_init): Set libphobos_skip_tests. (libphobos_skipped_test_p): New proc. (check_effective_target_libcurl_available): New proc. * testsuite/libphobos.phobos/phobos.exp: Skip curl tests if library not found. * testsuite/libphobos.phobos_shared/phobos_shared.exp: Likewise. Modified: trunk/libphobos/ChangeLog trunk/libphobos/testsuite/lib/libphobos.exp trunk/libphobos/testsuite/libphobos.phobos/phobos.exp trunk/libphobos/testsuite/libphobos.phobos_shared/phobos_shared.exp
[Bug fortran/90230] New: newunit in open function is not threadsafe with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90230 Bug ID: 90230 Summary: newunit in open function is not threadsafe with openmp Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mweiland at freenet dot de Target Milestone: --- Created attachment 46239 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46239=edit Source file to reproduce the error The issue can be reproduced with: gfortran -c -fopenmp minimal.f90 gfortran -fopenmp minimal.o ./a.out It yields: opened file with lun: -10 At line 7 of file minimal.f90 Fortran runtime error: File already opened in another unit It seems to me that the newunit feature of open() is not threadsafe. I get the output: opened file with lun: -11 At line 7 of file minimal.f90 Fortran runtime error: File already opened in another unit Error termination. Backtrace: ... With ifort/14.0 and NagCompiler, this example works, e.g.: ifort -c -fopenmp minimal.f90 ifort -fopenmp minimal.o ./a.out opened file with lun:-130 closed file with lun:-130 opened file with lun:-133 opened file with lun:-131 opened file with lun:-134 opened file with lun:-135 closed file with lun:-134 opened file with lun:-129 closed file with lun:-133 closed file with lun:-131 closed file with lun:-129 opened file with lun:-132 closed file with lun:-132 opened file with lun:-136 opened file with lun:-137 closed file with lun:-137 closed file with lun:-135 opened file with lun:-138 closed file with lun:-138 closed file with lun:-136 Not sure if this is really a bug, since I do not know if newunit is actually supposed to be treadsafe from the Fortran standard.
[Bug libstdc++/88888] Cannot construct filesystem::path from variable length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Jonathan Wakely --- Agreed.
[Bug libstdc++/88888] Cannot construct filesystem::path from variable length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #3 from Ville Voutilainen --- Work-around #3 looks splendidly sufficient to me, let's close this without further extension-work into this wonderful overload set.
[Bug target/89952] S/390: Inconsistent CFI info when restoring frame pointer from fpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89952 Andreas Krebbel changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andreas Krebbel --- Fixed upstream with the patch from comment #2
[Bug target/89952] S/390: Inconsistent CFI info when restoring frame pointer from fpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89952 --- Comment #2 from Andreas Krebbel --- Author: krebbel Date: Wed Apr 24 13:40:38 2019 New Revision: 270544 URL: https://gcc.gnu.org/viewcvs?rev=270544=gcc=rev Log: S/390: Fix PR89952 incorrect CFI This patch fixes a cases where inconsistent CFI is generated. After restoring the hard frame pointer (r11) from an FPR we have to set the CFA register. In order to be able to set it back to the stack pointer (r15) we have to make sure that r15 has been restored already. The patch also adds a scheduler dependency to prevent the instruction scheduler from swapping the r11 and r15 restore again. gcc/ChangeLog: 2019-04-24 Andreas Krebbel PR target/89952 * config/s390/s390.c (s390_restore_gprs_from_fprs): Restore GPRs from FPRs in reverse order. Generate REG_CFA_DEF_CFA note also for restored hard frame pointer. (s390_sched_dependencies_evaluation): Implement new target hook. (TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK): New macro definition. gcc/testsuite/ChangeLog: 2019-04-24 Andreas Krebbel PR target/89952 * gcc.target/s390/pr89952.c: New test. Added: trunk/gcc/testsuite/gcc.target/s390/pr89952.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.c trunk/gcc/testsuite/ChangeLog
[Bug c++/90227] [9 Regression] trunk rejects polymake since r269965
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90227
Jakub Jelinek changed:
What|Removed |Added
Keywords||rejects-valid
Priority|P3 |P1
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-04-24
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Ah, unfortunately the originally submitted preprocessed source has been
hand-edited and so clang++ rejected it while g++ 8 still accepted it, I bet in
the category of what can but doesn't have to be diagnosed in uninstantiated
templates. I've hand-edited that back from original polymake sources so that
it compiled with clang++ and creduced again, verifying that it compiles without
errors with g++ 8 as well as clang++ and is rejected by g++ trunk this way.
The result is -std=c++14:
template struct c { static constexpr int d = b; typedef c e; };
template using f = a;
template using h = c;
template using i = c;
template struct ab {};
template struct k { using e = ab; };
template struct ad;
template struct ad> { using e =
ab; };
template struct ae;
template struct ae> : i {};
template ::d> struct ag;
template struct ag, 0, 0> { using e = ab<>; };
template
struct ag, 0, ah> : k>::e, ah -
1>::e> {};
template
struct ag, ai, ah> : ag>::e, ai - 1> {};
template class> struct aj;
template class ak> struct aj, ak>
{
using e = ab::e...>;
};
template struct an;
struct ao { typedef an<0> ap; };
template struct aq {};
template struct as;
template struct as> { typedef
aq ap; };
template using au = typename as::ap;
template using av = aq;
template using aw = au;
struct ay { using e = h::d>; };
template class, typename...>
struct bb : ay::e {};
struct bd { using e = av<>; };
struct bg { using e = bd::e; };
namespace bi {
enum bj { bk };
struct bo { enum n { bp }; };
struct bq { bool br; static const bo::n bs = bo::bp; };
template struct bw { using e = bv; };
template class bx;
template
struct bx, av> : bo {
static const n bs = bv::bs;
static const long ca = sizeof bv::br;
using cb = int;
using cc = ab;
using cd = typename ag::e;
using ce = typename ag::e;
using cf = aw;
using cg = typename bw::e;
using ch = decltype(cg()(cb(), cd(), ce(), cf()));
};
class ck;
template struct cl : c {};
template
struct bx> : public bx,
cl>::e, bg::e> {};
}
using bi::bj;
using bi::ck;
template class co {
template co(p) { c(); }
static co o;
};
namespace bi {
template class cp;
template using cq = bb;
template void cs(cr, f::d, void *> = nullptr);
}
using bi::cs;
struct cu : bi::bq {
template
auto operator()(int q, ab, ab, av<>) {
cs(q);
}
};
template <>
co>>
co>>::o(0);
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #83 from Jakub Jelinek --- Fixed then.
[Bug debug/90197] [8/9 Regression] Cannot step through simple loop at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197 --- Comment #7 from Jakub Jelinek --- Created attachment 46238 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46238=edit gcc9-pr90197-wip.patch Untested WIP patch (for the C FE so far only, C++ needs something similar though).
[Bug c++/90186] optimizing options -O1 and -O2 produce different results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90186
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Richard Biener ---
Note that using #pragma pack(1) on struct Ipv4 makes u_short members not
naturally aligned and thus code like
void UpdateChecksum()
{
u_long sum(0);
SetChecksum(0);
u_short *buf = (u_short*)ip->Payload();
u_long nwords = ip->PayloadSize() / 2;
for (unsigned i = 0; i < nwords; ++i)
{
sum += ntohs(*buf++);
dereferences pointers to u_short that might not be aligned to a 2 byte
boundary.
Confirmed though, even when using -fno-inline. -fno-strict-aliasing fixes
it. Possibly the very same issue above - using u_short * to access memory
with a different dynamic type. The same happens here:
buf = (u_short*)
nwords = 6;
for (unsigned i = 0; i < nwords; ++i)
{
sum += ntohs(*buf++);
ph is of type PseudoHeader. You cannot use lvalues of type u_short to
refer to them.
[Bug c++/90228] [UBSAN]: get_addr_base_and_unit_offset_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90228 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-24 CC||marxin at gcc dot gnu.org Blocks||63426 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug lto/90229] Interaction among -Wl,--as-needed and LTO results in an undefined symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90229 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-24 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- This is probably a linker bug. 1 1.o 5 207 247afdd8dccf97e2 PREVAILING_DEF_IRONLY _Z1aPKcz 210 247afdd8dccf97e2 PREVAILING_DEF_IRONLY _Z1av 213 247afdd8dccf97e2 PREVAILING_DEF main 228 247afdd8dccf97e2 RESOLVED_DYN FLAGS_verbose 224 247afdd8dccf97e2 UNDEF pthread_create ld is invoked as /usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld -plugin /usr/lib64/gcc/x86_64-suse-linux/8/liblto_plugin.so -plugin-opt=/usr/lib64/gcc/x86_64-suse-linux/8/lto-wrapper -plugin-opt=-fresolution=1.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib64/gcc/x86_64-suse-linux/8/../../../../lib64/crt1.o /usr/lib64/gcc/x86_64-suse-linux/8/../../../../lib64/crti.o /usr/lib64/gcc/x86_64-suse-linux/8/crtbegin.o -L. -L/usr/lib64/gcc/x86_64-suse-linux/8 -L/usr/lib64/gcc/x86_64-suse-linux/8/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/8/../../.. 1.o mylib.so --as-needed -lstdc++ -lm -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc /usr/lib64/gcc/x86_64-suse-linux/8/crtend.o /usr/lib64/gcc/x86_64-suse-linux/8/../../../../lib64/crtn.o works fine with -fuse-ld=gold.
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 --- Comment #82 from ian at gcc dot gnu.org --- Author: ian Date: Wed Apr 24 12:45:45 2019 New Revision: 270542 URL: https://gcc.gnu.org/viewcvs?rev=270542=gcc=rev Log: PR target/89093 runtime: mark unwind functions general-regs-only on ARM For https://gcc.gnu.org/PR89093. Change-Id: Ic426b43d633c77104bda01d4e7835bc9ab4695ef Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/173657 Reviewed-by: Ian Lance Taylor Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/runtime/go-unwind.c
[Bug libstdc++/89728] ctype is underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89728 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/90215] [8/9 Regression] ICE with lambda in fold expression over comma and assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90215
--- Comment #4 from Vittorio Romeo ---
Simplified quite a lot, removed `` dependency:
https://gcc.godbolt.org/z/6uNcCN
struct X
{
template
void f(F f)
{
f(0);
}
};
template
void bug(Xs... xs)
{
int i;
[&](auto&... ys)
{
(xs.f([&](auto)
{
ys;
}), ...);
}(i);
}
int main()
{
bug(X{});
}
[Bug c++/90228] [UBSAN]: get_addr_base_and_unit_offset_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90228 --- Comment #1 from Richard Biener --- Hmm. We return signed offset because the maximum object size is half of the address space. So I think the code is OK and just invalid C input will produce undefined output here. Otherwise we'd need one bit more in precision and sacrifice speed of compilation quite a bit for this hot function.
[Bug libstdc++/89728] ctype is underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89728 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-24 Ever confirmed|0 |1
[Bug libstdc++/88888] Cannot construct filesystem::path from variable length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 --- Comment #2 from Jonathan Wakely --- (The versions passing i as the length will do the wrong thing here, because the array actually contains the empty string "", but I'm just showing examples of valid syntax that work with VLAs).
[Bug c++/90217] Greater optimization of C++ Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90217 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |WAITING Last reconfirmed||2019-04-24 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Please attach the testcases.
[Bug libstdc++/88888] Cannot construct filesystem::path from variable length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
--- Comment #1 from Jonathan Wakely ---
I'm not sure we should bother doing anything here. There are various
workarounds possible:
std::filesystem::path p(vla);
std::filesystem::path p({vla, (size_t)i});
std::filesystem::path p = (const char*)vla;
std::filesystem::path p = std::string(vla);
std::filesystem::path p = std::string(vla, i);
std::filesystem::path p = std::string_view(vla);
std::filesystem::path p = std::string_view(vla, i);
[Bug c++/90215] [8/9 Regression] ICE with lambda in fold expression over comma and assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90215 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/90204] [8/9 Regression] C code is optimized worse than C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204 --- Comment #6 from rguenther at suse dot de --- On Wed, 24 Apr 2019, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204 > > --- Comment #5 from Jakub Jelinek --- > That would be likely NRV optimization in the C++ FE, but then why doesn't the > generic NRV optimization handle it in the middle-end later on? Probably getting address-taken due to vectorization / IVOPTs. NRV runs pretty late.
[Bug tree-optimization/90213] UBSAN: signed integer overflow: -5621332293356458048 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90213 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-24 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- The code even says /* TODO: This code seems wrong, multiply then check to see if it fits. */ offset *= tree_to_uhwi (unit_size); offset *= BITS_PER_UNIT; it might be as simple as moving the multiplication above the to_shwi check.
[Bug tree-optimization/90213] UBSAN: signed integer overflow: -5621332293356458048 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90213 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Lemme fix it.
[Bug c++/90212] [8/9 Regression] by-ref capture of constexpr class object rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90212 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164 --- Comment #20 from rsandifo at gcc dot gnu.org --- > Most of these are array bounds. I'll find out stack backtraces for > each of these. Thanks for the testing. Could you open new PRs for the new backtraces? These are really independent bugs, and it'd be useful to keep this PR specific to the two problems fixed in r270442. > I got 26 runtime errors, of which 20 are poly-int.h FWIW, whether something occurs in poly-int.h or not isn't usually that relevant. A lot of arithmetic that used to be open-coded now goes through functions in poly-int.h, so it tends to show up a lot as the immediate point of failure. But whether the operation triggers UB is usually determined by the operation being done (i.e. by the caller) rather than the way poly-int.h implements it. On x86 targets, what poly-int.h does is usually the same as what the original pre-poly-int code did. This was the case in both of the bugs fixed in r270442 for example.
[Bug target/90204] [8/9 Regression] C code is optimized worse than C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204 --- Comment #5 from Jakub Jelinek --- That would be likely NRV optimization in the C++ FE, but then why doesn't the generic NRV optimization handle it in the middle-end later on?
[Bug tree-optimization/90211] [8 Regression] ICE: tree check: expected ssa_name, have real_cst in first_readonly_imm_use, at ssa-iterators.h:351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90211 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||9.0 Known to fail||8.3.0
[Bug fortran/90207] Debugging generated tree code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90207 --- Comment #1 from Richard Biener --- (In reply to Thomas Koenig from comment #0) > This could also be implemented by a transformation of > what -fdump-tree-original produces into a valid C program, > using data structures from libgfortran. Note this is probably not OK with the FSF (opens up the possibility of using the gfortran frontend with a proprietary backend).
[Bug tree-optimization/90208] [7/8 Regression] error: EH landing pad label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90208 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug lto/90229] Interaction among -Wl,--as-needed and LTO results in an undefined symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90229 Martin Liška changed: What|Removed |Added CC||matz at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #2 from Martin Liška --- CCing my favorite --as-needed experts ;)
[Bug lto/90229] Interaction among -Wl,--as-needed and LTO results in an undefined symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90229
--- Comment #1 from Martin Liška ---
$ cat 1.ii
extern int FLAGS_verbose;
extern "C" void pthread_create();
void a(const char *b...) {
if (FLAGS_verbose) {
__builtin_va_list ap;
__builtin_va_start(ap, b);
}
}
void a() { pthread_create(); }
int main() { a(""); return 0; }
[Bug target/90204] [8/9 Regression] C code is optimized worse than C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #4 from Richard Biener ---
The difference is that for C++ we directly use DECL_RESULT in the GIMPLE IL
while for C we end up with a copy to it. The C++ FE does
;; Function v test(v, v) (null)
;; enabled by -tree-original
{
struct v res [value-expr: ];
and at the end
<>>;
}
while the C FE uses plain res:
{
struct v res;
...
return res;
}
which in the end also results in try/finally processing for CLOBBERs. Not sure
where the C++ FE decides using for res is fine and whether the C
FE could do the same. Certainly eliding this extra copy is beneficial.
[Bug lto/90229] New: Interaction among -Wl,--as-needed and LTO results in an undefined symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90229 Bug ID: 90229 Summary: Interaction among -Wl,--as-needed and LTO results in an undefined symbol Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- As seen in few openSUSE packages with LTO enabled: https://bugzilla.opensuse.org/show_bug.cgi?id=1133232 https://bugzilla.opensuse.org/show_bug.cgi?id=1133131 There's some issue: $ cat lib.cc int FLAGS_verbose; $ g++ -shared -fPIC lib.cc -o mylib.so $ g++ -pthread 1.ii libpes.so -Wl,--as-needed -O [OK] But: $ g++ -pthread 1.ii libpes.so -Wl,--as-needed -O -flto /usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/gcc/x86_64-suse-linux/8/libstdc++.so: undefined reference to `pthread_create' collect2: error: ld returned 1 exit status
[Bug target/90202] AVX-512 instructions not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90202 Richard Biener changed: What|Removed |Added Keywords||ra Target||x86_64-*-* i?86-*-* Status|UNCONFIRMED |RESOLVED CC||hjl.tools at gmail dot com Resolution|--- |WORKSFORME --- Comment #3 from Richard Biener --- The same pushes/moves appear for the AVX2 code. I think we have a duplicate for this issue and it appears because we eventually have to align the local stack to be able to spill ymm/zmm registers and we can't fully elide the frame construction after RA. Original issue worksfrme (works as designed), frame issue has a duplicate somewhere.
[Bug c++/90228] New: [UBSAN]: get_addr_base_and_unit_offset_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90228 Bug ID: 90228 Summary: [UBSAN]: get_addr_base_and_unit_offset_1 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- From the C++ testsuite, for source code file ./g++.dg/warn/Wplacement-new-size-5.C with gcc trunk version 207500 and compiler flag -O2, I get this: ../../trunk/gcc/poly-int.h:715:21: runtime error: signed integer overflow: 92233 72036854775807 + 1 cannot be represented in type 'long int' #0 0x331775c in poly_int<1u, long>& poly_int<1u, long>::operator+=(pol y_int_pod<1u, long> const&) ../../trunk/gcc/poly-int.h:715 #1 0x331775c in get_addr_base_and_unit_offset_1(tree_node*, poly_int_pod<1u, long>*, tree_node* (*)(tree_node*)) ../../trunk/gcc/tree-dfa.c:796 #2 0x48d in gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_ node*), tree_node* (*)(tree_node*)) ../../trunk/gcc/gimple-fold.c:6350 #3 0x36ea4f4 in ccp_fold ../../trunk/gcc/tree-ssa-ccp.c:1257 #4 0x36ea4f4 in evaluate_stmt ../../trunk/gcc/tree-ssa-ccp.c:1785
[Bug c++/90201] -Werror=useless-cast in move constructir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90201 --- Comment #4 from Dima Pro --- (In reply to Jonathan Wakely from comment #3) > You get a warning with -Wuseless-cast Yes, sorry. Miss this. Anyway, no useless cast warning should be for this code.
[Bug libstdc++/90220] std::any_cast misbehaves for function and array types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220 --- Comment #3 from Jonathan Wakely --- Patch for the second bit posted: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00927.html
[Bug c++/90201] -Werror=useless-cast in move constructir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90201 --- Comment #3 from Jonathan Wakely --- You get a warning with -Wuseless-cast
[Bug debug/90194] ICE in expand_debug_expr, at cfgexpand.c:5244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90194 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine.
[Bug debug/90194] ICE in expand_debug_expr, at cfgexpand.c:5244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90194
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-04-24
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed. update-address-taken does, after CCP:
af (int xn)
{
void * D.2359;
- void * _2;
[local count: 1073741824]:
# DEBUG BEGIN_STMT
# DEBUG D.2357 => 4
# DEBUG nq =>
# DEBUG BEGIN_STMT
- _4 =
# DEBUG D.2357 => NULL
# DEBUG nq => NULL
- _2 = _4;
- MEM[(struct cb *)_2] = {};
+ xn_5 = VIEW_CONVERT_EXPR({});
+ # DEBUG xn => xn_5
return;
which failed to "fold" the V_C_E. It does reach
rhs = fold_build1 (VIEW_CONVERT_EXPR,
TREE_TYPE (lhs), rhs);
but this does nothing.
[Bug d/90065] Unaligned accesses on strict-alignment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90065
--- Comment #2 from Iain Buclaw ---
I have my suspicions that the following code will throw an unaligned access
error as well.
shared int var;
void main() {
synchronized { var = 1; }
}
As synchronized statements are lowered to the following equivalent C.
static char __critsec64[48];
_d_criticalenter(& __critsec64);
var = 0;
_d_criticalexit(& __critsec64);
Just going off memory, but I don't think the artificial __critsec variable
would be suitably aligned for use as a pthread_mutex_t.
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #17 from Paul Thomas --- > Created attachment 46216 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46216=edit > Patch for the remaining problems. > > I am registering this now as a measure of progress towards doing a proper job > of fixing this PR for good. I've just applied the patch to trunk, rebuilt f951 on sparc-sun-solaris2.11 and tested unlimited_polymorphic_30.f03: the test now PASSes for both 32 and 64-bit. I'll include the patch in tonight's bootstrap and let you know if there are any problems elsewhere.
[Bug tree-optimization/88239] ./gcc.dg/torture/pr84929.c with -O3 -march=native causes ubsan error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88239 --- Comment #3 from David Binderman --- Still going wrong at revision 270500. Here is a stack backtrace: ../../trunk/gcc/tree-ssa-loop-prefetch.c:468:14: runtime error: signed integer o verflow: 7818038963515661296 * 4 cannot be represented in type 'long int' #0 0x30177c3 in idx_analyze_ref ../../trunk/gcc/tree-ssa-loop-prefetch.c:468 #1 0x303b6d8 in for_each_index(tree_node**, bool (*)(tree_node*, tree_node** , void*), void*) ../../trunk/gcc/tree-ssa-loop.c:622 #2 0x30147d3 in analyze_ref ../../trunk/gcc/tree-ssa-loop-prefetch.c:530 #3 0x30147d3 in gather_memory_references_ref ../../trunk/gcc/tree-ssa-loop-p refetch.c:548 #4 0x3018fec in gather_memory_references ../../trunk/gcc/tree-ssa-loop-prefe tch.c:651
