[Bug bootstrap/90544] Build failure on MINGW for gcc-9.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90544 Kuang changed: What|Removed |Added CC||master at a1983 dot com.cn --- Comment #2 from Kuang --- Same problem when cross compiling for windows on Ubuntu with x86_64-w64-mingw32-gcc (9.1.0)
[Bug target/90721] [Bug] ./gcc.dg/torture/stackalign/builtin-apply-4.c test case getting fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90721 --- Comment #1 from Akhilesh Kumar --- One more observation same test case getting PASS on x86 root@akhilesh-ubuntu:/home/akhilesh.k/gcc-arm-src-snapshot-8.3-2019.03/gcc/testsuite# gcc ./gcc.dg/torture/stackalign/builtin-apply-4.c -flto -fgnu89-inline -lm -o builtin-apply-4.exe root@akhilesh-ubuntu:/home/akhilesh.k/gcc-arm-src-snapshot-8.3-2019.03/gcc/testsuite# ./builtin-apply-4.exe root@akhilesh-ubuntu:/home/akhilesh.k/gcc-arm-src-snapshot-8.3-2019.03/gcc/testsuite#
[Bug target/90689] [10 Regression] ICE in extract_insn, at recog.c:2310 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90689 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED CC|amodra at gcc dot gnu.org, | |amodra at gmail dot com| Resolution|--- |FIXED --- Comment #7 from Alan Modra --- Fixed
[Bug target/90689] [10 Regression] ICE in extract_insn, at recog.c:2310 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90689 --- Comment #6 from Alan Modra --- Author: amodra Date: Tue Jun 4 00:13:07 2019 New Revision: 271895 URL: https://gcc.gnu.org/viewcvs?rev=271895=gcc=rev Log: PR90689, ICE in extract_insn on ppc64le PR target/90689 * config/rs6000/rs6000.c (rs6000_call_aix): Correct r271753 merge error. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug target/90689] [10 Regression] ICE in extract_insn, at recog.c:2310 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90689 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com --- Comment #5 from Alan Modra --- It's a merge error. The correct condition for the block shown in comment #4 is if (is_pltseq_longcall) I'll give that a quick test and commit as obvious.
[Bug tree-optimization/90739] [10 regression] Fortran pointer array tests fails after r271860
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90739 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from kargl at gcc dot gnu.org --- dup. *** This bug has been marked as a duplicate of bug 90738 ***
[Bug fortran/90738] [10 regression] gfortran.dg/pointer_array_10.f90 etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90738 kargl at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- *** Bug 90739 has been marked as a duplicate of this bug. ***
[Bug libstdc++/90700] Wrong constraints for tuple(allocator_arg_t, const A&, const tuple&)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90700 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Mon Jun 3 22:31:45 2019 New Revision: 271887 URL: https://gcc.gnu.org/viewcvs?rev=271887=gcc=rev Log: PR libstdc++/90700 Fix constructor constraint for std::tuple * include/std/tuple (tuple(allocator_arg_t, const A&, const tuple&)): Fix value category of template argument to _TC::_NonNestedTuple. * testsuite/20_util/tuple/cons/90700.cc: New test. Added: branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/tuple/cons/90700.cc Modified: branches/gcc-9-branch/libstdc++-v3/ChangeLog branches/gcc-9-branch/libstdc++-v3/include/std/tuple
[Bug tree-optimization/90739] New: [10 regression] Fortran pointer array tests fails after r271860
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90739 Bug ID: 90739 Summary: [10 regression] Fortran pointer array tests fails after r271860 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- > FAIL: gfortran.dg/pointer_array_10.f90 -Os execution test > FAIL: gfortran.dg/subref_array_pointer_2.f90 -Os execution test Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/pointer_array_10.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never-Os -pedantic-errors -B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs -B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs -lm -o ./pointer_array_10.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/pointer_array_10.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -Os -pedantic-errors -B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs -B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs -lm -o ./pointer_array_10.exe PASS: gfortran.dg/pointer_array_10.f90 -Os (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/gcc:.:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64 Execution timeout is: 300 spawn [open ...] STOP 1 FAIL: gfortran.dg/pointer_array_10.f90 -Os execution test testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/dg.exp completed in 0 seconds === gfortran Summary === # of expected passes11 # of unexpected failures1
[Bug fortran/90738] [10 regression] gfortran.dg/pointer_array_10.f90 etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90738 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug fortran/90738] New: [10 regression] gfortran.dg/pointer_array_10.f90 etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90738 Bug ID: 90738 Summary: [10 regression] gfortran.dg/pointer_array_10.f90 etc. FAIL Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: tkoenig at gcc dot gnu.org Target Milestone: --- Between 20190601 (r271838) and 20190603 (r271873), two fortran tests regressed: +FAIL: gfortran.dg/pointer_array_10.f90 -Os execution test +FAIL: gfortran.dg/subref_array_pointer_2.f90 -Os execution test I'm seeing it on Solaris/SPARC and x86 (both 32 and 64-bit), but there are several gcc-testresults reports on a bunch of other targets including Linux/x86_64. The first test exists with STOP 1 Perhaps this is due to 2019-06-02 Thomas Koenig PR fortran/90539 * trans-expr.c (gfc_conv_subref_array_arg): If the size of the expression can be determined to be one, treat it as contiguous. Set likelyhood of presence of an actual argument according to PRED_FORTRAN_ABSENT_DUMMY and likelyhood of being contiguous according to PRED_FORTRAN_CONTIGUOUS. 2019-06-02 Thomas Koenig PR fortran/90539 * predict.def (PRED_FORTRAN_CONTIGUOUS): New predictor. the only fortran patch in the above range?
[Bug c/90737] [8/9/10 Regression] inconsistent address of a local converted to intptr_t between callee and caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90737 Martin Sebor changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-06-03 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00114.html
[Bug middle-end/90694] incorrect representation of ADDR_EXPR involving a pointer to array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90694 --- Comment #7 from Martin Sebor --- Thanks for the heads up. I scanned the testsuite for the pattern but couldn't find any matching tests: $ find gcc/testsuite/ -type f | xargs grep "&\*[a-zA-Z_][a-zA-Z_0-9]*\[" | grep scan | wc -l 0 Please let me know if you think I may have missed some.
[Bug c++/90736] [9/10 Regression] Bogus error with alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90736 --- Comment #3 from Marek Polacek --- This compiles when the parm 'b' is not const.
[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #100 from Iain Sandoe --- fixed on open branches, I will probably make local patches for 6.5 and 5.5 since there are folks who still care about them, however this is closed as fixed.
[Bug rtl-optimization/90706] [9 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 --- Comment #2 from Berni --- (In reply to Georg-Johann Lay from comment #1) > (In reply to Berni from comment #0) > > pushing r0 does not make sense at all since it is by definition a temporary > > register that can freely be modified. Maybe it's just pushed to make room > > for the stack operations? > > Yes. > > The code from v8 is already suboptimal: It's nonsense to load R28 with 0x1 > just to survive a function call. Better use a call-used register and load it > after the function call to where the return value is computed. Then there > would be no need to push/pop R28. > > Does -fno-caller-saves improve v9 code? > > This is definitely not a target issue. It's likely a register-allocation > problem. And the v8 problem is because some (tree) passes move setters away > from their consumers. With option -fno-caller-saves there is no change in v9 code!
[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #99 from Iain Sandoe --- Author: iains Date: Mon Jun 3 19:13:46 2019 New Revision: 271881 URL: https://gcc.gnu.org/viewcvs?rev=271881=gcc=rev Log: Darwin, backport fixes for PR 89864 (with 90379 included) 2019-06-03 Iain Sandoe Backport from mainline. 2019-05-11 Iain Sandoe PR bootstrap/89864 * inclhack.def (darwin_ucred__Atomic): Do not supply test_text for wrap fixes. * fixincl.x: Regenerated. Backport from mainline. 2019-04-18 Erik Schnetter Jakub Jelinek Iain Sandoe PR bootstrap/89864 * inclhack.def (darwin_ucred__Atomic): New, work around _Atomic keyword use in headers included by C++. * fixincl.x: Regenerated. Modified: branches/gcc-7-branch/fixincludes/ChangeLog branches/gcc-7-branch/fixincludes/fixincl.x branches/gcc-7-branch/fixincludes/inclhack.def
[Bug c/90737] [8/9/10 Regression] inconsistent address of a local converted to intptr_t between callee and caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90737 Martin Sebor changed: What|Removed |Added Keywords||diagnostic, wrong-code Known to work||4.9.4 Blocks||90556 Summary|wrong code returning|[8/9/10 Regression] |address of a local |inconsistent address of a |converted to intptr_t |local converted to intptr_t ||between callee and caller Known to fail||10.0, 5.1.0, 6.4.0, 7.3.0, ||8.2.0, 9.1.0 --- Comment #1 from Martin Sebor --- The warning for this code goes at least as far back as GCC 4.1. The inconsistency between the callee and the caller started in GCC 4.9. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90556 [Bug 90556] [meta-bug] bogus/missing -Wreturn-local-addr
[Bug c/90737] New: wrong code returning address of a local converted to intptr_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90737
Bug ID: 90737
Summary: wrong code returning address of a local converted to
intptr_t
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC issues -Wreturn-local-addr even for returning the address of a local
variable converted to an integer. In addition, it also replaces the value of
the integer with a zero. Since returning the integer representation of pointer
is well-defined, as is using such an integer, this leads to
inconsistencies/undefined behavior when the integer is first determined to be
non-zero within the body of the returning function and then zero in its caller.
The warning should only be issued for functions that return a pointer.
Likewise, the replacement of the address with a zero should only be done for
such functions and not for those returning other types.
$ cat a.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout a.c
typedef __INTPTR_TYPE__ intptr_t;
intptr_t f (void)
{
int i;
if ((intptr_t) == 0)
__builtin_abort ();
return (intptr_t)
}
void g (void)
{
intptr_t i = f ();
if (i == 0)
__builtin_trap ();
}
a.c: In function ‘f’:
a.c:9:10: warning: function returns address of local variable
[-Wreturn-local-addr]
9 | return (intptr_t)
| ^~~~
;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=0)
f ()
{
[local count: 1073741824]:
return 0;
}
;; Function g (g, funcdef_no=1, decl_uid=1911, cgraph_uid=2, symbol_order=1)
(unlikely executed)
g ()
{
[count: 0]:
__builtin_trap ();
}
[Bug middle-end/90735] missing location in -Wreturn-local-addr on a function with two return statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90735
--- Comment #2 from Martin Sebor ---
The problem is in this function in gimple-low.c:
/* Lower a GIMPLE_RETURN GSI. DATA is passed through the recursion. */
static void
lower_gimple_return (gimple_stmt_iterator *gsi, struct lower_data *data)
{
...
if (gimple_return_retval (stmt) == gimple_return_retval (tmp_rs.stmt))
{
/* Remove the line number from the representative return statement.
It now fills in for many such returns. Failure to remove this
will result in incorrect results for coverage analysis. */
gimple_set_location (tmp_rs.stmt, UNKNOWN_LOCATION);
goto found;
}
...
I wonder if setting the location to the closing curly brace of the function
definition would not cause these failures. At least the warning would point
into the right function if not the right statement.
[Bug libfortran/77278] Use LTO for libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278 --- Comment #10 from rguenther at suse dot de --- On June 3, 2019 6:54:10 PM GMT+02:00, "tkoenig at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278 > >--- Comment #9 from Thomas Koenig --- >Created attachment 46446 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46446=edit >LTO tree dump from simple test case > >So, I tried out a simple program: > >$ cat minloc.f90 >program main > real, dimension(10,10) :: a > integer, dimension(2) :: m1 > call random_number(a) > m1 = minloc(a) > print *,m1 >end program main > >Compiling this with the fat-object libgfortran results in the somewhat >humorous > >$ gfortran -fdump-tree-optimized -O3 -flto -static-libgfortran >minloc.f90 >minloc.f90:5: warning: type of '_gfortran_minloc0_4_r4' does not match >original >declaration [-Wlto-type-mismatch] >5 | m1 = minloc(a) > | >../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: type >mismatch >in parameter 3 >../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: >'minloc0_4_r4' >was previously declared here >../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: code >may be >misoptimized unless '-fno-strict-aliasing' is used > >which looks like an LTO bug. It tells you the actual argument of the Fortran frontend generated call is not compatible with the C prototype. It Doesn't say which types are involved here and the leading sentence is confusing. >There is a lot of code pulled in for writing to standard output >which could be optimized away. > >The good news: Inlining _gfortran_minloc0_4_r4 appears to work :-)
[Bug c++/90736] [9/10 Regression] Bogus error with alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90736 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-03 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |8.4 Summary|Bogus error with alignas|[9/10 Regression] Bogus ||error with alignas Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed.
[Bug c++/90736] Bogus error with alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90736 --- Comment #1 from Matthew Beliveau --- Started with commit r261971
[Bug c++/90736] New: Bogus error with alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90736
Bug ID: 90736
Summary: Bogus error with alignas
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mbelivea at redhat dot com
Target Milestone: ---
constexpr unsigned long a(const unsigned long b) { return b; }
const unsigned long c = a(alignof(int));
alignas(c) char d;
./cc1plus -quiet u.ii
u.ii:3:17: error: requested alignment is not an integer constant
3 | alignas(c) char d;
[Bug middle-end/90735] missing location in -Wreturn-local-addr on a function with two return statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90735
--- Comment #1 from Martin Sebor ---
The output of the -fdump-tree-all-lineno option shows the correct location
information in the a.c.007t.omplower dump:
;; Function f (f, funcdef_no=0, decl_uid=1909, cgraph_uid=1, symbol_order=0)
f (int i, int j)
[../a.c:4:1] {
int * iftmp.0;
int * D.1920;
int c;
int * p;
try
{
[../a.c:6:22] if (i < 0) goto ; else goto ;
:
[../a.c:6:22] iftmp.0 = [../a.c:6:20]
goto ;
:
[../a.c:6:22] iftmp.0 = [../a.c:6:24]
:
[../a.c:6:8] p = iftmp.0;
[../a.c:7:7] _1 = [../a.c:7:7] *p;
[../a.c:7:6] if (_1 != 0) goto ; else goto ;
:
[../a.c:8:12] D.1920 = p;
[../a.c:8:12] // predicted unlikely by early return (on trees) predictor.
[../a.c:8:12] return D.1920;
:
[../a.c:9:6] if (j < 0) goto ; else goto ;
:
[../a.c:10:7] p = [../a.c:10:9]
:
[../a.c:12:10] D.1920 = p;
[../a.c:12:10] return D.1920;
}
finally
{
c = {CLOBBER};
}
}
but the a.c.008t.lower dump below does not. The two return statements (one on
line 8 and the other on line 12) are merged into one at the end of the
function. I'm not sure what would be a good solution here. Keeping the
location of either one of the statement would still lead to inaccurate results
in some cases. But maybe that's better than no location at all.
;; Function f (f, funcdef_no=0, decl_uid=1909, cgraph_uid=1, symbol_order=0)
f (int i, int j)
{
int * p;
int c;
int * D.1920;
int * iftmp.0;
try
{
[../a.c:6:22] if (i < 0) goto ; else goto ;
:
[../a.c:6:22] iftmp.0 = [../a.c:6:20]
goto ;
:
[../a.c:6:22] iftmp.0 = [../a.c:6:24]
:
[../a.c:6:8] p = iftmp.0;
[../a.c:7:7] _1 = [../a.c:7:7] *p;
[../a.c:7:6] if (_1 != 0) goto ; else goto ;
:
[../a.c:8:12] D.1920 = p;
[../a.c:8:12] // predicted unlikely by early return (on trees) predictor.
[../a.c:8:12] goto ;
:
[../a.c:9:6] if (j < 0) goto ; else goto ;
:
[../a.c:10:7] p = [../a.c:10:9]
:
[../a.c:12:10] D.1920 = p;
[../a.c:12:10] goto ;
}
finally
{
c = {CLOBBER};
}
:
return D.1920;
}
[Bug c++/90734] [concepts] Pre-normalization substitution into constraints of templated function breaks subsumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90734 Casey Carter changed: What|Removed |Added CC||Casey at Carter dot net --- Comment #1 from Casey Carter --- Note that this may be a duplicate of #82507, or more precisely a different expression of the same mechanism that causes #82507. Handy Compiler Explorer link with repro: https://godbolt.org/z/-vPUJx.
[Bug middle-end/90735] New: missing location in -Wreturn-local-addr on a function with two return statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90735
Bug ID: 90735
Summary: missing location in -Wreturn-local-addr on a function
with two return statements
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The -Wreturn-local-addr warning is often missing location information when
issued for one of two (or more) return statements in a function involving
conditionals. For example:
$ cat a.c && gcc -O2 -S -Wall -Wextra a.c
extern int a[], b[];
int* f (int i, int j)
{
int c;
int *p = i < 0 ? a : b;
if (*p)
return p;
if (j < 0)
p =
return p;
}
a.c: In function ‘f’:
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
a.c:5:7: note: declared here
5 | int c;
| ^
[Bug c++/90734] New: [concepts] Pre-normalization substitution into constraints of templated function breaks subsumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90734
Bug ID: 90734
Summary: [concepts] Pre-normalization substitution into
constraints of templated function breaks subsumption
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 46447
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46447=edit
Repro
Compiling this program:
template
inline constexpr bool bool_ = B;
#if defined(WORKAROUND)
template
concept bool Same_impl = __is_same_as(T, U);
#else
template
concept bool Same_impl = bool_<__is_same_as(T, U)>;
#endif
template
concept bool Same = Same_impl && Same_impl;
template
concept bool Foo = Same;
template
concept bool Bar = Foo && Same;
template
struct S1 {
// overload set incorrectly is ambiguous (should resolve to second
overload)
static constexpr bool f() requires Foo { return false; }
static constexpr bool f() requires Bar { return true; }
};
template
struct S2 {
// overload set incorrectly is not ambiguous (resolves to third
overload)
static constexpr bool f() requires Foo { return false; }
static constexpr bool f() requires Bar { return false; }
static constexpr bool f() requires bool_ && true { return true; }
};
template
concept bool can_f = requires { T::f(); };
int main() {
static_assert(Foo);
static_assert(Bar);
static_assert(can_f>); // Fails
static_assert(S1::f());// Bogus error
static_assert(!can_f>); // Fails
#ifndef WORKAROUND
static_assert(S2::f());// Bogus non-error
#endif
}
with "-std=c++2a -fconcepts" produces diagnostics:
/home/casey/casey/Desktop/repro.cpp: In function ‘int main()’:
/home/casey/casey/Desktop/repro.cpp:43:19: error: static assertion failed
43 | static_assert(can_f>); // Fails
| ^~
/home/casey/casey/Desktop/repro.cpp:44:30: error: call of overloaded ‘f()’
is ambiguous
44 | static_assert(S1::f());// Bogus error
| ^
/home/casey/casey/Desktop/repro.cpp:24:27: note: candidate: ‘static
constexpr bool S1::f() requires Foo [with T = int]’
24 | static constexpr bool f() requires Foo { return false; }
| ^
/home/casey/casey/Desktop/repro.cpp:25:27: note: candidate: ‘static
constexpr bool S1::f() requires Bar [with T = int]’
25 | static constexpr bool f() requires Bar { return true; }
| ^
/home/casey/casey/Desktop/repro.cpp:46:19: error: static assertion failed
46 | static_assert(!can_f>); // Fails
| ^~~
when it should diagnose only the static_assert on line 48. Bar subsumes
Foo, so S1::f should be unambiguous. Conversely, Neither Bar nor
bool_ && true subsumes the other, so S2::f should be ambiguous. The
compiler's disagreement with both of these facts suggests premature
substitution replacing bool_<__is_same_as(T, T)> and bool_<__is_same_as(const
T&, const T&)> with bool_ *before* determination of subsumption in
overload resolution. That replacement would result in Foo being replaced
with bool_ && bool_, and Bar being replaced with bool_ &&
bool_ && bool_ && bool_ which *would* produce the observed
behavior during overload resolution.
[Bug libfortran/77278] Use LTO for libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278 --- Comment #9 from Thomas Koenig --- Created attachment 46446 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46446=edit LTO tree dump from simple test case So, I tried out a simple program: $ cat minloc.f90 program main real, dimension(10,10) :: a integer, dimension(2) :: m1 call random_number(a) m1 = minloc(a) print *,m1 end program main Compiling this with the fat-object libgfortran results in the somewhat humorous $ gfortran -fdump-tree-optimized -O3 -flto -static-libgfortran minloc.f90 minloc.f90:5: warning: type of '_gfortran_minloc0_4_r4' does not match original declaration [-Wlto-type-mismatch] 5 | m1 = minloc(a) | ../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: type mismatch in parameter 3 ../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: 'minloc0_4_r4' was previously declared here ../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: code may be misoptimized unless '-fno-strict-aliasing' is used which looks like an LTO bug. There is a lot of code pulled in for writing to standard output which could be optimized away. The good news: Inlining _gfortran_minloc0_4_r4 appears to work :-)
[Bug c/90733] New: [8/9/10 Regression] ICE in simplify_subreg, at simplify-rtx.c:6440
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90733
Bug ID: 90733
Summary: [8/9/10 Regression] ICE in simplify_subreg, at
simplify-rtx.c:6440
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with early gcc-8 and options -g -O2+ :
$ cat z1.c
typedef struct
{
unsigned a : 1;
} s;
typedef union
{
s b;
_Complex unsigned c;
} t;
t f (t d)
{
t e = d;
return e;
}
int g ()
{
t x;
t y;
x.c = x.b.a;
y = f(x);
return (x.c != y.c);
}
$ gcc-10-20190602 -c z1.c -O2
$
$ gcc-10-20190602 -c z1.c -O2 -g
z1.c: In function 'g':
z1.c:22:12: warning: 'x.b.a' is used uninitialized in this function
[-Wuninitialized]
22 | x.c = x.b.a;
| ~~~^~
during RTL pass: vartrack
z1.c:25:1: internal compiler error: in simplify_subreg, at simplify-rtx.c:6440
25 | }
| ^
0xa67144 simplify_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
../../gcc/simplify-rtx.c:6440
0xa66b24 simplify_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
../../gcc/simplify-rtx.c:6544
0xa6ac78 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
../../gcc/simplify-rtx.c:6711
0xce16a5 vt_expand_loc_callback
../../gcc/var-tracking.c:8488
0x710f31 cselib_expand_value_rtx_1
../../gcc/cselib.c:1681
0x7124ae cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc/cselib.c:1562
0xce19e9 vt_expand_var_loc_chain
../../gcc/var-tracking.c:8384
0xce19e9 vt_expand_loc_callback
../../gcc/var-tracking.c:8547
0x710df2 cselib_expand_value_rtx_1
../../gcc/cselib.c:1716
0x7124ae cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc/cselib.c:1562
0xce19e9 vt_expand_var_loc_chain
../../gcc/var-tracking.c:8384
0xce19e9 vt_expand_loc_callback
../../gcc/var-tracking.c:8547
0x710ced cselib_expand_value_rtx_1
../../gcc/cselib.c:1755
0x7124ae cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc/cselib.c:1562
0xce19e9 vt_expand_var_loc_chain
../../gcc/var-tracking.c:8384
0xce19e9 vt_expand_loc_callback
../../gcc/var-tracking.c:8547
0x710df2 cselib_expand_value_rtx_1
../../gcc/cselib.c:1716
0x7124ae cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc/cselib.c:1562
0xce0a65 vt_expand_var_loc_chain
../../gcc/var-tracking.c:8384
0xce0a65 vt_expand_1pvar
../../gcc/var-tracking.c:8660
[Bug c++/90732] New: regression - ICE with std::apply after variable length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90732
Bug ID: 90732
Summary: regression - ICE with std::apply after variable length
array
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: v at vsamko dot com
Target Milestone: ---
With -O0 -std=c++17 this results in ICE
#include
#include
volatile size_t SIZE = 100;
template
void foo(Ts&... out) {
std::tuple dummy;
char buf[SIZE];
std::apply([, ](auto&... x) { (x, ...); }, dummy);
}
int main() {
int x1;
foo(x1);
}
during RTL pass: expand
test.cpp: In lambda function:
test.cpp:10:16: internal compiler error: in expand_expr_real_1, at expr.c:10012
10 | std::apply([, ](auto&... x) { (x, ...); }, dummy);
|^
0x79d4d9 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-9.1.0/gcc/expr.c:10012
0x1236818 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc-9.1.0/gcc/expr.c:8275
0x1236818 expand_expr
../../gcc-9.1.0/gcc/expr.h:279
0x1236818 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
../../gcc-9.1.0/gcc/expr.c:7873
0x123082a expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc-9.1.0/gcc/expr.c:8733
0x115d279 expand_gimple_stmt_1
../../gcc-9.1.0/gcc/cfgexpand.c:3789
0x115d279 expand_gimple_stmt
../../gcc-9.1.0/gcc/cfgexpand.c:3850
0x11579de expand_gimple_basic_block
../../gcc-9.1.0/gcc/cfgexpand.c:5886
0x11579de execute
../../gcc-9.1.0/gcc/cfgexpand.c:6509
Please submit a full bug report,
[Bug c++/90731] regression - noexcept broken for forward declarations with decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90731 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-03 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- r260238
[Bug c++/90728] False positive Wmemset-elt-size with zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90728 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-03 CC||msebor at gcc dot gnu.org Component|c |c++ Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed in C++. The code that issues the warning is the same between C and C++: if (COMPLETE_TYPE_P (elt_type) && !integer_onep (TYPE_SIZE_UNIT (elt_type)) && domain != NULL_TREE && TYPE_MAX_VALUE (domain) && TYPE_MIN_VALUE (domain) && integer_zerop (TYPE_MIN_VALUE (domain)) && integer_onep (fold_build2 (MINUS_EXPR, domain, arg2, TYPE_MAX_VALUE (domain warning_at (loc, OPT_Wmemset_elt_size, "% used with length equal to " "number of elements without multiplication " "by element size"); but the difference is that in C the domain of the zero-length array is [0, null] while in C++ it's [0, SIZE_MAX]. I.e., TYPE_MAX_VALUE (domain) is null in C which makes the if condition evaluate to false.
[Bug c++/83534] C++17: typeinfo for noexcept function lacks noexcept information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83534 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-03 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- Indeed it is. I thought I'd confirmed this when it was first reported.
[Bug driver/90730] -fdump-tree-gimple-optimized-... accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90730 Martin Sebor changed: What|Removed |Added Keywords||accepts-invalid --- Comment #1 from Martin Sebor --- Another invalid example that's accepted: -fdump-tree-gimple-all-all-details-details Based on a warning when one is issued, it looks like GCC simply ignores all syntactically valid "keywords" after -fdump-tree-- like all and details but gives warnings for invalid ones. $ gcc -Wall -Wextra -S -fdump-tree-gimple-all-details-detail -xc - < /dev/null cc1: warning: ignoring unknown option ‘detail’ in ‘-fdump-tree-gimple’
[Bug c++/90731] New: regression - noexcept broken for forward declarations with decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90731
Bug ID: 90731
Summary: regression - noexcept broken for forward declarations
with decltype
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: v at vsamko dot com
Target Milestone: ---
void foo1() noexcept(true) {}
decltype(foo1) stub_foo1;
void stub_foo1() noexcept(true) {}
This compiles fine with clang 8 and gcc 8.3, but not with gcc 9.1 (all in c++17
mode).
g++ 9.1 produces error
:9:6: error: declaration of 'void stub_foo1() noexcept' has a different
exception specifier
9 | void stub_foo1() noexcept(true) {}
| ^
:7:16: note: from previous declaration 'void stub_foo1()'
7 | decltype(foo1) stub_foo1;
|^
Compiler returned: 1
According to the standard
(https://en.cppreference.com/w/cpp/language/noexcept_spec) - Functions
differing only in their exception specification cannot be overloaded (just like
the return type, exception specification is part of function type, but not part
of the function signature) (since C++17).
And indeed,
void foo1() noexcept(true) {}
void foo2() noexcept(false) {}
std::is_same_v // evaluates to false
[Bug driver/90730] New: -fdump-tree-gimple-optimized-... accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90730 Bug ID: 90730 Summary: -fdump-tree-gimple-optimized-... accepted Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Some non-sensical -fdump-tree-xxx options are silently accepted, such as: $ gcc -Wall -Wextra -S -fdump-tree-gimple-optimized -xc - < /dev/null The result is a .gimple dump file but no .optimized dump. This is also accepted: -fdump-tree-gimple-all with the same effect.
[Bug target/90689] [10 Regression] ICE in extract_insn, at recog.c:2310 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90689
--- Comment #4 from Segher Boessenkool ---
rs6000.c does
if (HAVE_AS_PLTSEQ
&& DEFAULT_ABI == ABI_ELFv2
&& GET_CODE (func_desc) == SYMBOL_REF)
{
rtvec v = gen_rtvec (3, toc_reg, func_desc, tlsarg);
rtx mark_toc_reg = gen_rtx_UNSPEC (Pmode, v, UNSPEC_PLTSEQ);
emit_insn (gen_rtx_SET (stack_toc_mem, mark_toc_reg));
}
else
emit_move_insn (stack_toc_mem, toc_reg);
but the insn condition for *pltseq_tocsave_ is
"TARGET_PLTSEQ
&& DEFAULT_ABI == ABI_ELFv2"
I think that HAVE_AS_PLTSEQ there should be TARGET_PLTSEQ?
[Bug c++/83534] C++17: typeinfo for noexcept function lacks noexcept information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83534 Valentine changed: What|Removed |Added CC||v at vsamko dot com --- Comment #1 from Valentine --- I'm having the same problem. Looks like a bug. Clang handles this fine.
[Bug target/90689] [10 Regression] ICE in extract_insn, at recog.c:2310 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90689 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2019-05-31 00:00:00 |2019-06-03 Ever confirmed|0 |1 --- Comment #3 from Segher Boessenkool --- I have reproduced it now (on a native build). It needs all of -mno-pltseq -fno-inline -fno-plt -Os -mabi=elfv2 to fail.
[Bug d/90729] libphobos.phobos_shared/std/math.d FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90729 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.2
[Bug d/90729] New: libphobos.phobos_shared/std/math.d FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90729 Bug ID: 90729 Summary: libphobos.phobos_shared/std/math.d FAILs on Solaris Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.11 The libphobos.phobos_shared/std/math.d test FAILs on Solaris/SPARC and x86, though in different ways: * x86: Arithmetic Exception Thread 2 received signal SIGFPE, Arithmetic exception. [Switching to Thread 1 (LWP 1)] 0x0807d4f2 in std.math.__unittestL2454_30() () at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:2533 2533if (x == real.infinity) (gdb) p x $1 = 2.6711020675522791803e-4932 * sparc: core.exception.AssertError@/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d(1516): unittest failure assert(equalsDigit(acosh(cosh(3.0)), 3, useDigits));
[Bug c/90728] New: False positive Wmemset-elt-size with zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90728
Bug ID: 90728
Summary: False positive Wmemset-elt-size with zero size array
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
The code below comes from a template expansion (when certain cache feature is
disabled) and all the operation on the `buff` member are no-op.
```
#include
struct A {
A()
{
memset(, 0xff, sizeof(buff));
}
int buff[0];
};
```
However, this start to raise a warning on GCC 9
```
a.cpp: In constructor 'A::A()':
a.cpp:8:41: warning: 'memset' used with length equal to number of elements
without multiplication by element size [-Wmemset-elt-size]
8 | memset(, 0xff, sizeof(buff));
| ^
```
It seems that the warning logic simply compare the size (as well as checking
element size != 1) without taking into account the 0 size case.
[Bug d/90727] libphobos.phobos_shared/std/datetime/systime.d etc. FAIL on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90727 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.2
[Bug d/90727] New: libphobos.phobos_shared/std/datetime/systime.d etc. FAIL on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90727 Bug ID: 90727 Summary: libphobos.phobos_shared/std/datetime/systime.d etc. FAIL on Solaris Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.11 libphobos.phobos_shared/std/datetime/systime.d and libphobos.phobos_shared/std/datetime/timezone.d FAIL on Solaris/SPARC and x86, 32 and 64-bit: core.exception.AssertError@/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/datetime/systime.d(748): Value given: -1998-Jan-01 01:59:59 Failed time zone: America/Los_Angeles core.exception.AssertError@/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/datetime/timezone.d(236): Assertion failure I've not yet wrapped my head around that code, but suspect the failures are related to Solaris' lack of tm_gmtoff and tm_zone members in struct tm.
[Bug libstdc++/90686] Libstdc++ C++20 status table is missing entry for P1357R1 "Traits for [Un]bounded Arrays"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90686 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Mon Jun 3 14:05:50 2019 New Revision: 271872 URL: https://gcc.gnu.org/viewcvs?rev=271872=gcc=rev Log: PR libstdc++/90686 update C++2a library status docs PR libstdc++/90686 * doc/xml/manual/status_cxx2014.xml: Document what's missing from . * doc/xml/manual/status_cxx2020.xml: Document status of P0777R1, P0339R6, P0340R3, P1164R1 and P1357R1. * doc/html/*: Regenerate. Modified: branches/gcc-9-branch/libstdc++-v3/ChangeLog branches/gcc-9-branch/libstdc++-v3/doc/html/manual/status.html branches/gcc-9-branch/libstdc++-v3/doc/xml/manual/status_cxx2014.xml branches/gcc-9-branch/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
[Bug libstdc++/90686] Libstdc++ C++20 status table is missing entry for P1357R1 "Traits for [Un]bounded Arrays"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90686 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- Fixed
[Bug middle-end/64242] Longjmp expansion incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242 --- Comment #24 from Wilco --- Author: wilco Date: Mon Jun 3 13:55:15 2019 New Revision: 271870 URL: https://gcc.gnu.org/viewcvs?rev=271870=gcc=rev Log: Fix PR64242 - Longjmp expansion incorrect Improve the fix for PR64242. Various optimizations can change a memory reference into a frame access. Given there are multiple virtual frame pointers which may be replaced by multiple hard frame pointers, there are no checks for writes to the various frame pointers. So updates to a frame pointer tends to generate incorrect code. Improve the previous fix to also add clobbers of several frame pointers and add a scheduling barrier. This should work in most cases until GCC supports a generic "don't optimize across this instruction" feature. Bootstrap OK. Testcase passes on AArch64 and x86-64. Inspected x86, Arm, Thumb-1 and Thumb-2 assembler which looks correct. gcc/ PR middle-end/64242 * builtins.c (expand_builtin_longjmp): Add frame clobbers and schedule block. (expand_builtin_nonlocal_goto): Likewise. testsuite/ PR middle-end/64242 * gcc.c-torture/execute/pr64242.c: Update test. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/pr64242.c
[Bug middle-end/90726] exponential behavior on SCEV results everywhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90726 Richard Biener changed: What|Removed |Added Keywords||compile-time-hog Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-06-03 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/90726] New: exponential behavior on SCEV results everywhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90726
Bug ID: 90726
Summary: exponential behavior on SCEV results everywhere
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
A GIMPLE testcase derived from gcc.dg/torture/pr88597.c exposes quadraticnesses
in chrec and ivopts predicates (I have patches for this) as well as
expand_simple_operations. It also shows expression_expensive_p happily
accepts the GENERIC tree resulting in exponential amount of generated GIMPLE
due to unsharing/gimplification. I also have a patch for
expression_expensive_p.
int __GIMPLE (ssa,guessed_local(12348030),startwith("fix_loops"))
un (int dd)
{
int s2;
int q8;
int nz;
__BB(2,guessed_local(12348030)):
goto __BB3(guessed(134217728));
__BB(3,loop_header(1),guessed_local(37044096)):
nz_7 = __PHI (__BB2: 0, __BB5: nz_10);
q8_13 = dd_9(D) * dd_9(D);
q8_17 = q8_13 * q8_13;
q8_21 = q8_17 * q8_17;
q8_25 = q8_21 * q8_21;
q8_29 = q8_25 * q8_25;
q8_33 = q8_29 * q8_29;
q8_37 = q8_33 * q8_33;
q8_41 = q8_37 * q8_37;
q8_45 = q8_41 * q8_41;
q8_49 = q8_45 * q8_45;
q8_53 = q8_49 * q8_49;
q8_57 = q8_53 * q8_53;
q8_61 = q8_57 * q8_57;
q8_65 = q8_61 * q8_61;
q8_69 = q8_65 * q8_65;
q8_73 = q8_69 * q8_69;
q8_77 = q8_73 * q8_73;
q8_81 = q8_77 * q8_77;
q8_85 = q8_81 * q8_81;
q8_89 = q8_85 * q8_85;
q8_93 = q8_89 * q8_89;
q8_97 = q8_93 * q8_93;
q8_101 = q8_97 * q8_97;
q8_105 = q8_101 * q8_101;
q8_109 = q8_105 * q8_105;
q8_113 = q8_109 * q8_109;
q8_117 = q8_113 * q8_113;
q8_121 = q8_117 * q8_117;
nz_10 = nz_7 + 1;
if (nz_10 != 3)
goto __BB5(guessed(89478485));
else
goto __BB4(guessed(44739243));
__BB(5,guessed_local(24696064)):
goto __BB3(precise(134217728));
__BB(4,guessed_local(12348031)):
return q8_121;
}
[Bug libstdc++/90686] Libstdc++ C++20 status table is missing entry for P1357R1 "Traits for [Un]bounded Arrays"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90686 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Mon Jun 3 13:23:03 2019 New Revision: 271867 URL: https://gcc.gnu.org/viewcvs?rev=271867=gcc=rev Log: PR libstdc++/90686 update C++2a library status docs PR libstdc++/90686 * doc/xml/manual/status_cxx2014.xml: Document what's missing from . * doc/xml/manual/status_cxx2020.xml: Document status of P1285R0, P0339R6, P0340R3, P1164R1 and P1357R1. * doc/html/*: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/html/manual/memory.html trunk/libstdc++-v3/doc/html/manual/status.html trunk/libstdc++-v3/doc/xml/manual/status_cxx2014.xml trunk/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
[Bug c++/90725] New: implicitly used 'this' not diagnosed in static member fn declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90725
Bug ID: 90725
Summary: implicitly used 'this' not diagnosed in static member
fn declaration
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
struct S {
int a;
static int foo() noexcept(noexcept(a));
};
is compiled fine, but 'this' cannot be used in a static member function
declaration. This one we handle ok:
struct S2 {
int a;
static int foo() noexcept(noexcept(this->a));
};
[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 Iain Sandoe changed: What|Removed |Added Target|x86_64-apple-darwin1(3|4) |x86_64-apple-darwin1(345678 ||) Last reconfirmed|2014-11-11 00:00:00 |2019-6-3 Host|x86_64-apple-darwin1(3|4) |x86_64-apple-darwin1(345678 ||) Build|x86_64-apple-darwin1(3|4) |x86_64-apple-darwin1(345678 ||) --- Comment #23 from Iain Sandoe --- I do not see these fails on m32 darwin9 or on x86_64 darwin10-12, so there is some OS interaction, apparently (even if that is only exposing a latent issue).
[Bug target/90724] New: ICE with __sync_bool_compare_and_swap with -march=armv8.2-a+sve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90724
Bug ID: 90724
Summary: ICE with __sync_bool_compare_and_swap with
-march=armv8.2-a+sve
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: prathamesh3492 at gcc dot gnu.org
Target Milestone: ---
Following test (pr82096.c) and few others fail with following ICE with
-march=armv8.2-a+sve that contain call to __sync_bool_compare_and_swap:
static long long AL[24];
int
check_ok (void)
{
return (__sync_bool_compare_and_swap (AL+1, 0x20003ll, 0x1234567890ll));
}
pr82096.c: In function 'check_ok':
pr82096.c:11:1: error: unrecognizable insn:
11 | }
| ^
(insn 11 10 12 2 (set (reg:CC 66 cc)
(compare:CC (reg:DI 95)
(const_int 8589934595 [0x20003]))) "pr82096.c":10:11 -1
(nil))
during RTL pass: vregs
pr82096.c:11:1: internal compiler error: in extract_insn, at recog.c:2310
0x64bb6e _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x64bb8a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:116
0x64a58b extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2310
0xa28a45 instantiate_virtual_regs_in_insn
../../gcc/gcc/function.c:1605
0xa28a45 instantiate_virtual_regs
../../gcc/gcc/function.c:1975
0xa28a45 execute
../../gcc/gcc/function.c:2024
Thanks,
Prathamesh
[Bug target/90723] New: pr88598-2.c segfaults with -msve-vector-bits=256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90723
Bug ID: 90723
Summary: pr88598-2.c segfaults with -msve-vector-bits=256
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: prathamesh3492 at gcc dot gnu.org
Target Milestone: ---
cc1 segfaults with the following test-case, with -O2 -march=armv8.2-a+sve
-msve-vector-bits=256:
typedef double v4df __attribute__ ((vector_size (32)));
void foo(v4df);
int
main ()
{
volatile v4df x1;
x1 = (v4df) { 0, 1, 1, 2 };
foo (x1);
return 0;
}
gdb backtrace (clipped to last 14):
Program received signal SIGSEGV, Segmentation fault.
0x00bfdad1 in expand_binop_directly (icode=CODE_FOR_adddi3,
mode=mode@entry=E_DImode, binoptab=binoptab@entry=add_optab,
op0=op0@entry=0x77a233a8, op1=op1@entry=0x77a2b290,
target=target@entry=0x75095468, unsignedp=1, methods=OPTAB_LIB_WIDEN,
last=0x75094bc0) at ../../gcc/gcc/optabs.c:1038
1038{
(gdb) bt
#0 0x00bfdad1 in expand_binop_directly (icode=CODE_FOR_adddi3,
mode=mode@entry=E_DImode, binoptab=binoptab@entry=add_optab,
op0=op0@entry=0x77a233a8, op1=op1@entry=0x77a2b290,
target=target@entry=0x75095468, unsignedp=1, methods=OPTAB_LIB_WIDEN,
last=0x75094bc0) at ../../gcc/gcc/optabs.c:1038
#1 0x00bfc0dd in expand_binop (mode=E_DImode, binoptab=, op0=0x77a233a8, op1=0x77a2b290, target=0x75095468,
unsignedp=1, methods=OPTAB_LIB_WIDEN) at ../../gcc/gcc/optabs.c:1209
#2 0x009cc7e4 in force_operand (value=0x77859f90,
target=0x75095468) at ../../gcc/gcc/expr.c:7527
#3 0x009a80a3 in copy_to_mode_reg (mode=E_DImode,
x=x@entry=0x77859f90) at ../../gcc/gcc/explow.c:627
#4 0x00bf2dce in maybe_legitimize_operand_same_code
(icode=icode@entry=CODE_FOR_aarch64_pred_movvnx2df, opno=opno@entry=2,
op=)
at ../../gcc/gcc/optabs.c:7146
#5 0x00bf56ee in maybe_legitimize_operand (op=0x7bfff400, opno=2,
icode=CODE_FOR_aarch64_pred_movvnx2df) at ../../gcc/gcc/optabs.c:7196
#6 maybe_legitimize_operands (icode=CODE_FOR_aarch64_pred_movvnx2df, opno=0,
nops=, ops=0x7bfff3c0) at ../../gcc/gcc/optabs.c:7323
#7 0x00bf5c0a in maybe_gen_insn
(icode=CODE_FOR_aarch64_pred_movvnx2df, nops=,
ops=0x7bfff3c0)
at ../../gcc/gcc/optabs.c:7342
#8 0x00bf8c39 in maybe_expand_insn (ops=ops@entry=0x7bfff3b0,
nops=nops@entry=3, icode=) at ../../gcc/gcc/optabs.c:7416
#9 expand_insn (icode=, nops=nops@entry=3,
ops=ops@entry=0x7bfff3c0) at ../../gcc/gcc/optabs.c:7416
#10 0x010378a4 in aarch64_emit_sve_pred_move (dest=,
pred=, src=) at ./insn-opinit.h:735
#11 0x012cb710 in gen_movvnx2df (operand0=0x75095408,
operand1=0x77859f78) at ../../gcc/gcc/config/aarch64/aarch64-sve.md:77
#12 0x009c7505 in insn_gen_fn::operator() (this=,
a1=0x77859f78, a0=0x75095408) at ../../gcc/gcc/recog.h:301
#13 emit_move_insn_1 (x=0x75095408, y=0x77859f78) at
../../gcc/gcc/expr.c:3701
#14 0x009c7950 in emit_move_insn (x=x@entry=0x75095408,
y=y@entry=0x77859f78) at ../../gcc/gcc/expr.c:3797
Thanks,
Prathamesh
[Bug target/90722] New: ICE with __builtin_convertvector with -msve-vector-bits=256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90722
Bug ID: 90722
Summary: ICE with __builtin_convertvector with
-msve-vector-bits=256
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: prathamesh3492 at gcc dot gnu.org
Target Milestone: ---
The following test-case:
typedef int v4si __attribute__((vector_size (4 * sizeof (int;
typedef double v4df __attribute__((vector_size (4 * sizeof (double;
void
f4 (v4df *x, v4si *y)
{
*y = __builtin_convertvector (*x, v4si);
}
results in ICE with -O2 -march=armv8.2-a+sve -msve-vector-bits=256:
0xcddacd simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc/gcc/simplify-rtx.c:1763
0xcd9c2a simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc/gcc/simplify-rtx.c:873
0x13bca5a combine_simplify_rtx
../../gcc/gcc/combine.c:5787
0x13bf1a6 subst
../../gcc/gcc/combine.c:5727
0x13bf2bb subst
../../gcc/gcc/combine.c:5590
0x13bf102 subst
../../gcc/gcc/combine.c:5661
0x13c0568 try_combine
../../gcc/gcc/combine.c:3420
0x13c66c6 combine_instructions
../../gcc/gcc/combine.c:1306
0x13c66c6 rest_of_handle_combine
../../gcc/gcc/combine.c:15068
0x13c66c6 execute
../../gcc/gcc/combine.c:15113
because it hits following assert in simplify_const_unary_operation:
gcc_assert (known_eq (GET_MODE_NUNITS (mode), n_elts));
GET_MODE_NUNITS (mode) == 8 and n_elts == 4 for the test-case.
Thanks,
Prathamesh
[Bug target/90689] [10 Regression] ICE in extract_insn, at recog.c:2310 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90689 Martin Liška changed: What|Removed |Added CC||amodra at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r271753. I use normal cross compiler: Configured with: ../configure --enable-languages=c,c++,fortran --disable-multilib --prefix=/home/marxin/bin/gcc2 --disable-bootstrap --disable-libsanitizer --target=ppc64le-linux-gnu --with-as=/usr/bin/powerpc64le-suse-linux-as : (reconfigured)
[Bug driver/90684] New alignment options incorrectly report error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90684 --- Comment #3 from Wilco --- Author: wilco Date: Mon Jun 3 11:27:50 2019 New Revision: 271864 URL: https://gcc.gnu.org/viewcvs?rev=271864=gcc=rev Log: Fix alignment option parser (PR90684) Fix the alignment option parser to always allow up to 4 alignments. Now -falign-functions=16:8:8:8 no longer reports an error. gcc/ PR driver/90684 * opts.c (parse_and_check_align_values): Allow 4 alignment values. Mgcc/ChangeLog Mgcc/opts.c Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c
[Bug rtl-optimization/90706] [9 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 Georg-Johann Lay changed: What|Removed |Added Component|target |rtl-optimization Summary|Useless code generated for |[9 Regression] Useless code |stack / register operations |generated for stack / |on AVR |register operations on AVR --- Comment #1 from Georg-Johann Lay --- (In reply to Berni from comment #0) > pushing r0 does not make sense at all since it is by definition a temporary > register that can freely be modified. Maybe it's just pushed to make room > for the stack operations? Yes. The code from v8 is already suboptimal: It's nonsense to load R28 with 0x1 just to survive a function call. Better use a call-used register and load it after the function call to where the return value is computed. Then there would be no need to push/pop R28. Does -fno-caller-saves improve v9 code? This is definitely not a target issue. It's likely a register-allocation problem. And the v8 problem is because some (tree) passes move setters away from their consumers.
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853
--- Comment #36 from Wilco ---
(In reply to Orr Shalom Dvory from comment #35)
> Hi, thanks for your respond. can someone mark this bug as need to be
> improved?
> Does anyone agree/disagree with my new proposed method?
It's best to create a new bug if there are still easy cases that could be
optimized. Also it seems the constants it uses are quite complex - it may be
feasible to simplify them. Eg. long f(long x) { return x % 35 == 0; }
[Bug c/90721] New: [Bug] ./gcc.dg/torture/stackalign/builtin-apply-4.c test case getting fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90721
Bug ID: 90721
Summary: [Bug] ./gcc.dg/torture/stackalign/builtin-apply-4.c
test case getting fail
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: akhilesh.k at samsung dot com
Target Milestone: ---
Hello
I am working On ARM target: in that
./gcc.dg/torture/stackalign/builtin-apply-4.c test case getting fail when we
use -flto flag with gcc 8.3 but same test cases getting pass when we run on gcc
6.3
=
bash-3.2# cat ./gcc.dg/torture/stackalign/builtin-apply-4.c
/* PR tree-optimization/20076 */
/* { dg-do run } */
/* { dg-additional-options "-fgnu89-inline" } */
/* { dg-require-effective-target untyped_assembly } */
#include
extern void abort (void);
double
foo (int arg)
{
if (arg != 116)
abort();
return arg + 1;
}
inline double
bar (int arg)
{
foo (arg);
__builtin_return (__builtin_apply ((void (*) ()) foo,
__builtin_apply_args (), 16));
}
int
main (int argc, char **argv)
{
if (bar (116) != 117.0)
printf("hello\n");
return 0;
}
bash-3.2#
=
gcc 8.x Results
bash-3.2# gcc ./gcc.dg/torture/stackalign/builtin-apply-4.c -flto
-fgnu89-inline -lm -o ./builtin-apply-4.exe
bash-3.2# ./builtin-apply-4.exe
hello
bash-3.2#
gcc 6.3 test results
bash-3.2# /bin/gcc ./gcc.dg/torture/stackalign/builtin-apply-4.c -flto
-fgnu89-inline -lm -o ./builtin-apply-4.exe
bash-3.2# ./builtin-apply-4.exe
bash-3.2#
it seems that __builtin_apply returning wrong value
[Bug driver/90692] The "%{!shared:%:if-exists(default-manifest.o%s)}" spec option fails if gcc is installed in a path with spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90692 --- Comment #1 from Olivier Michel --- The principle of this patch is that it breaks the recursion of the specs function evaluation as soon as a library file is expanded. This is needed because otherwise, the file path containing a space is broken down into two tokens that are evaluated separately and this ends up in two wrong file names (resulting from the split at the location of the space in the original path). Indeed, once a library file is expanded, there is no need to further recurse in the evaluation. So, the recursion is stopped and the result is added to the argbuf list. That makes the code slightly more efficient and fixes the handling of paths with spaces. Please let me know if you believe this a good approach to fix this bug or if you have a different idea to achieve a better patch.
[Bug target/89803] Missing AVX512 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89803
--- Comment #6 from Hongtao.liu ---
Using "vector_operand" "vm" instead
Index: gcc/config/i386/sse.md
===
--- gcc/config/i386/sse.md (revision 271853)
+++ gcc/config/i386/sse.md (working copy)
@@ -600,6 +600,10 @@
(V8HI "v8si") (V16HI "v16si") (V32HI "v32si")
(V4SI "v4di") (V8SI "v8di") (V16SI "v16di")])
+(define_mode_attr mem_suffix
+ [(V16SF "{z}") (V8SF "{y}") (V4SF "{x}")
+ (V8DF "{z}") (V4DF "{y}") (V2DF "{x}")])
+
(define_mode_attr ssedoublemode
[(V4SF "V8SF") (V8SF "V16SF") (V16SF "V32SF")
(V2DF "V4DF") (V4DF "V8DF") (V8DF "V16DF")
@@ -21317,26 +21321,26 @@
(define_insn "avx512dq_fpclass"
[(set (match_operand: 0 "register_operand" "=k")
(unspec:
-[(match_operand:VF_AVX512VL 1 "register_operand" "v")
+[(match_operand:VF_AVX512VL 1 "vector_operand" "vm")
(match_operand:QI 2 "const_0_to_255_operand" "n")]
UNSPEC_FPCLASS))]
"TARGET_AVX512DQ"
- "vfpclass\t{%2, %1,
%0|%0, %1, %2}";
+ "vfpclass\t{%2, %1,
%0|%0, %1, %2}";
[(set_attr "type" "sse")
(set_attr "length_immediate" "1")
(set_attr "prefix" "evex")
(set_attr "mode" "")])
also need to modify scan assembler tests.
[Bug debug/90716] [10 Regression] gcc generates wrong debug information at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90716 --- Comment #3 from Richard Biener --- Author: rguenth Date: Mon Jun 3 10:17:16 2019 New Revision: 271858 URL: https://gcc.gnu.org/viewcvs?rev=271858=gcc=rev Log: 2019-06-03 Richard Biener PR tree-optimization/90716 * tree-loop-distribution.c (destroy_loop): Process blocks in correct order. * gcc.dg/guality/pr90716.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/guality/pr90716.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-loop-distribution.c
[Bug debug/90716] [10 Regression] gcc generates wrong debug information at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90716 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed.
[Bug target/88837] [SVE] Poor vector construction code in VL-specific mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88837 --- Comment #1 from prathamesh3492 at gcc dot gnu.org --- Author: prathamesh3492 Date: Mon Jun 3 09:35:37 2019 New Revision: 271857 URL: https://gcc.gnu.org/viewcvs?rev=271857=gcc=rev Log: 2019-06-03 Prathamesh Kulkarni PR target/88837 * vector-builder.h (vector_builder::count_dups): New method. * config/aarch64/aarch64-protos.h (aarch64_expand_sve_vector_init): Declare prototype. * config/aarch64/aarch64/sve.md (aarch64_sve_rev64): Use @. (vec_init): New pattern. * config/aarch64/aarch64.c (emit_insr): New function. (aarch64_sve_expand_vector_init_handle_trailing_constants): Likewise. (aarch64_sve_expand_vector_init_insert_elems): Likewise. (aarch64_sve_expand_vector_init_handle_trailing_same_elem): Likewise. (aarch64_sve_expand_vector_init): Define two overloaded functions. testsuite/ * gcc.target/aarch64/sve/init_1.c: New test. * gcc.target/aarch64/sve/init_1_run.c: Likewise. * gcc.target/aarch64/sve/init_2.c: Likewise. * gcc.target/aarch64/sve/init_2_run.c: Likewise. * gcc.target/aarch64/sve/init_3.c: Likewise. * gcc.target/aarch64/sve/init_3_run.c: Likewise. * gcc.target/aarch64/sve/init_4.c: Likewise. * gcc.target/aarch64/sve/init_4_run.c: Likewise. * gcc.target/aarch64/sve/init_5.c: Likewise. * gcc.target/aarch64/sve/init_5_run.c: Likewise. * gcc.target/aarch64/sve/init_6.c: Likewise. * gcc.target/aarch64/sve/init_6_run.c: Likewise. * gcc.target/aarch64/sve/init_7.c: Likewise. * gcc.target/aarch64/sve/init_7_run.c: Likewise. * gcc.target/aarch64/sve/init_8.c: Likewise. * gcc.target/aarch64/sve/init_8_run.c: Likewise. * gcc.target/aarch64/sve/init_9.c: Likewise. * gcc.target/aarch64/sve/init_9_run.c: Likewise. * gcc.target/aarch64/sve/init_10.c: Likewise. * gcc.target/aarch64/sve/init_10_run.c: Likewise. * gcc.target/aarch64/sve/init_11.c: Likewise. * gcc.target/aarch64/sve/init_11_run.c: Likewise. * gcc.target/aarch64/sve/init_12.c: Likewise. * gcc.target/aarch64/sve/init_12_run.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/aarch64/sve/init_1.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_10.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_10_run.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_11.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_11_run.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_12.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_12_run.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_1_run.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_2.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_2_run.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_3.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_3_run.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_4.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_4_run.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_5.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_5_run.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_6.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_6_run.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_7.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_7_run.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_8.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_8_run.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_9.c trunk/gcc/testsuite/gcc.target/aarch64/sve/init_9_run.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-protos.h trunk/gcc/config/aarch64/aarch64-sve.md trunk/gcc/config/aarch64/aarch64.c trunk/gcc/testsuite/ChangeLog trunk/gcc/vector-builder.h
[Bug ipa/90720] New: g++.dg/lto/alias-1 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90720 Bug ID: 90720 Summary: g++.dg/lto/alias-1 FAILs Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.11 The new g++.dg/lto/alias-1 test FAILs on Solaris, 32 and 64-bit, sparc and x86: +FAIL: g++.dg/lto/alias-1 cp_lto_alias-1_0.o-cp_lto_alias-1_1.o execute -O2 -flto Thread 2 received signal SIGABRT, Aborted. [Switching to Thread 1 (LWP 1)] 0xfe29f7d5 in __lwp_sigqueue () from /lib/libc.so.1 (gdb) where #0 0xfe29f7d5 in __lwp_sigqueue () from /lib/libc.so.1 #1 0xfe2980af in thr_kill () from /lib/libc.so.1 #2 0xfe1d986a in raise () from /lib/libc.so.1 #3 0xfe1ab84e in abort () from /lib/libc.so.1 #4 0x08050ddf in main (argc=1, argv=0xfeffd95c) at /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/lto/alias-1_0.C:29 if (!__builtin_constant_p (aptr == 0)) __builtin_abort ();
[Bug ipa/90720] g++.dg/lto/alias-1 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90720 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug tree-optimization/90681] [10 Regression] ICE in vect_slp_analyze_node_operations_1, at tree-vect-slp.c:2513 since r271704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90681 --- Comment #4 from alejandro at gcc dot gnu.org --- Author: alejandro Date: Mon Jun 3 09:13:32 2019 New Revision: 271856 URL: https://gcc.gnu.org/viewcvs?rev=271856=gcc=rev Log: Fix ICE in vect_slp_analyze_node_operations_1 This patch fixes bug 90681. It was caused by trying to SLP vectorize a non groupped load. We've fixed it by tweaking a bit the implementation: mark masked loads as not vectorizable, but support them as an special case. Then the detect them in the test for normal non-groupped loads that was already there. Added: trunk/gcc/testsuite/gfortran.dg/vect/pr90681.f Modified: trunk/gcc/ChangeLog trunk/gcc/internal-fn.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug testsuite/90713] [10 regression] FAIL: gcc.dg/gimplefe-40.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90713 --- Comment #4 from Richard Biener --- Author: rguenth Date: Mon Jun 3 09:03:48 2019 New Revision: 271855 URL: https://gcc.gnu.org/viewcvs?rev=271855=gcc=rev Log: 2019-06-03 Richard Biener PR testsuite/90713 * gcc.dg/gimplefe-40.c: Add -maltivec for powerpc. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/gimplefe-40.c
[Bug testsuite/90713] [10 regression] FAIL: gcc.dg/gimplefe-40.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90713 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug testsuite/90713] [10 regression] FAIL: gcc.dg/gimplefe-40.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90713
--- Comment #3 from rguenther at suse dot de ---
On Mon, 3 Jun 2019, segher at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90713
>
> Segher Boessenkool changed:
>
>What|Removed |Added
>
> Status|UNCONFIRMED |NEW
>Last reconfirmed||2019-06-03
> Ever confirmed|0 |1
>
> --- Comment #2 from Segher Boessenkool ---
> Confirmed. And confirmed that the testcase works fine with -maltivec.
>
> vect_float is the wrong selector to see if vectors of float are enabled by
> current compiler options:
>
> # Return 1 if the target supports hardware vectors of float when
> # -funsafe-math-optimizations is enabled, 0 otherwise.
> #
> # This won't change for different subtargets so cache the result.
>
> This testcase will need a test to see if there are 16 byte vector floats.
> Something that just tries to create a
> typedef float v4sf __attribute__((vector_size(16)));
> variable should do fine.
>
> Oh, and the gimple front end shouldn't ICE the compiler, of course :-/
The GIMPLE FE expects valid GIMPLE - but yes, the GIMPLE verifier
lacks verification of certain vector target constraints so we end
up ICEing in the expander or lowering things unexpectedly.
The GIMPLE FE is a unit-testing / debugging tool, not a "proper"
frontend ;)
I guess I'll add { dg-additional-options "-maltivec" { target powerpc*-*-*
} }
[Bug tree-optimization/90697] ia64: segmentation fault during GIMPLE pass: dom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90697 --- Comment #5 from rguenther at suse dot de --- On Mon, 3 Jun 2019, glaubitz at physik dot fu-berlin.de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90697 > > --- Comment #4 from John Paul Adrian Glaubitz fu-berlin.de> --- > (In reply to Richard Biener from comment #3) > > I can't reproduce this. Matthias, IIRC the debian version is not 8.3.0 but > > patched - to which rev? > > That's currently SVN 20190428 (r270630), see [1]. > > > [1] > > http://metadata.ftp-master.debian.org/changelogs/main/g/gcc-8/gcc-8_8.3.0-7_changelog OK, with that rev. and a simple cross cc1 to ia64-linux the issue doesn't reproduce on a x86_64 host: > ./cc1 -quiet /tmp/t.i -O3 -I include -g -fPIC -fno-strict-overflow -fstack-protector-all -std=c11 -fomit-frame-pointer -fno-math-errno -fno-signed-zeros -fno-tree-vectorize >
[Bug libfortran/77278] Use LTO for libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278 --- Comment #8 from rguenther at suse dot de --- On Sun, 2 Jun 2019, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278 > > --- Comment #6 from Thomas Koenig --- ... > So, dt_parm_1 is still filled with information in the tight loop > (which the library does not change), and the call to > transfer_real_write.constprop does not do a lot of the things > that could be done in theory, for example keeping the unit > number cached, take a note that this is not asynchronous, > that we always use "NO" on advance in the loop, etc. > > So, is it realistic to expect that LTO could do this kind > of thing with the very complex structure that libgfortran? Sure, why not. Of course the original motivation wasn't so much I/O but inlining/optimizing intrinsics. The frontend does a lot more inlining itself here today so the effect might not be as big.
[Bug c++/26989] C++ front-end (and others parts of GCC) use the wrong check to see if hidden visibility is there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26989
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #10 from Iain Sandoe ---
(In reply to Jonathan Wakely from comment #9)
> The G++ code now uses:
>
> if (is_attribute_p ("visibility", name))
>
> and the test that was failing uses:
>
> // { dg-require-visibility "" }
>
> which also depends on whether the attribute is supported:
>
> ###
> # proc check_visibility_available { what_kind }
> ###
>
> # The visibility attribute is only support in some object formats
> # This proc returns 1 if it is supported, 0 if not.
> # The argument is the kind of visibility, default/protected/hidden/internal.
>
> proc check_visibility_available { what_kind } {
> if [string match "" $what_kind] { set what_kind "hidden" }
>
> return [check_no_compiler_messages visibility_available_$what_kind
> object "
> void f() __attribute__((visibility(\"$what_kind\")));
> void f() {}
> "]
> }
>
> So I think this is probably doing the right thing for all targets now.
Yeah, the attribute is supported on Darwin at least back to Darwin8, and as
noted, earlier systems won't bootstrap without a tools update (which would
include such support). So I think we can close this as 'fixed by the passage of
time'.
[Bug d/90719] libphobos.phobos_shared/std/file.d FAILs on 32-bit Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90719 --- Comment #1 from Rainer Orth --- Created attachment 46445 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46445=edit Proposed patch
[Bug d/90719] libphobos.phobos_shared/std/file.d FAILs on 32-bit Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90719 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.2
[Bug middle-end/32503] __builtin_pow[i] - vectorize for other exponents besides 2 and 0.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32503 Richard Biener changed: What|Removed |Added Last reconfirmed|2007-06-26 10:47:05 |2019-6-3 Blocks||53947 Summary|__builtin_powi - optimize |__builtin_pow[i] - |for other exponents besides |vectorize for other |2 and 0.5 |exponents besides 2 and 0.5 --- Comment #5 from Richard Biener --- (In reply to Eric Gallager from comment #4) > (In reply to Richard Biener from comment #2) > > Confirmed. I had done tree-level expansion of powi into add/mul sequences > > at > > one time. But this had been rejected for some reason I cannot remember > > right now. > > Do you at least remember when that time was, so we can know where to go > looking in the archives? See the followup comment. We now do this expansion but it is too late for vectorization. The vectorizer knows how to handle pow of a constant via exp[2] which have vectorized variants. It also knows square-root and square but doesn't try anything more fancy. See vect_recog_pow_pattern. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug d/90719] New: libphobos.phobos_shared/std/file.d FAILs on 32-bit Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90719
Bug ID: 90719
Summary: libphobos.phobos_shared/std/file.d FAILs on 32-bit
Solaris
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Target: *-*-solaris2.11
libphobos.phobos_shared/std/file.d currently FAILs on 32-bit Solaris:
FAIL: libphobos.phobos_shared/std/file.d execution test
core.exception.AssertError@/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/file.d(1040):
unittest failure
[2000-Feb-03 23:12:09.5593787] [2000-Feb-04 01:09:39.5593787] [2019-Jun-01
10:45:13.9496087] [-1008 weeks, -1 days, -10 hours, -33 minutes, -4 secs, -390
ms, and -230 μs] [-1008 weeks, -1 days, -8 hours, -35 minutes, -34 secs, -390
ms, and -230 μs]
It turns out there's another mismatch between the system and druntime
declarations, this time affecting struct stat:
Solaris 11 has
struct stat {
dev_t st_dev;
longst_pad1[3]; /* reserved for network id */
ino_t st_ino;
mode_t st_mode;
nlink_t st_nlink;
uid_t st_uid;
gid_t st_gid;
dev_t st_rdev;
longst_pad2[2];
off_t st_size;
#if _FILE_OFFSET_BITS != 64
longst_pad3;/* future off_t expansion */
#endif
timespec_t st_atim;
timespec_t st_mtim;
timespec_t st_ctim;
blksize_t st_blksize;
blkcnt_tst_blocks;
charst_fstype[_ST_FSTYPSZ];
longst_pad4[8]; /* expansion area */
};
while libdruntime/core/sys/posix/sys/stat.d has
struct stat32_t
{
dev_t st_dev;
c_long[3] st_pad1;
ino_t st_ino;
mode_t st_mode;
nlink_t st_nlink;
uid_t st_uid;
gid_t st_gid;
dev_t st_rdev;
c_long[2] st_pad2;
off_t st_size;
c_long st_pad3;
union
{
timestruc_t st_atim;
time_t st_atime;
}
union
{
timestruc_t st_mtim;
time_t st_mtime;
}
union
{
timestruc_t st_ctim;
time_t st_ctime;
}
blksize_t st_blksize;
blkcnt_t st_blocks;
char[_ST_FSTYPSZ] st_fstype = 0;
c_long[8] st_pad4;
}
static if (__USE_FILE_OFFSET64)
alias stat64_t stat_t;
else
alias stat32_t stat_t;
i.e. st_pad3 is included in the non-largefile version of struct stat when it
shouldn't be.
Fixed by the attached patch which lets the test PASS.
[Bug libfortran/77278] Use LTO for libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #7 from Richard Biener ---
(In reply to Thomas Koenig from comment #5)
> One thing we would also have to tackle is GFC_LOGICAL arguments.
> C only has one bool type, which is (for gcc) equivalent to
> logical(kind=1). We might just get by with
>
> typedef enum { _zero=1, _one=1 } GFC_LOGICAL_4;
>
> but what about arguments with other logical types?
> We might actually need a C extension there, or disable
> aliasing-based optimization.
aliasing shouldn't be an issue here. The other logical kinds need to
be mapped to short/int/long anyways for ABI reasons, no?
[Bug c++/26989] C++ front-end (and others parts of GCC) use the wrong check to see if hidden visibility is there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26989
--- Comment #9 from Jonathan Wakely ---
The G++ code now uses:
if (is_attribute_p ("visibility", name))
and the test that was failing uses:
// { dg-require-visibility "" }
which also depends on whether the attribute is supported:
###
# proc check_visibility_available { what_kind }
###
# The visibility attribute is only support in some object formats
# This proc returns 1 if it is supported, 0 if not.
# The argument is the kind of visibility, default/protected/hidden/internal.
proc check_visibility_available { what_kind } {
if [string match "" $what_kind] { set what_kind "hidden" }
return [check_no_compiler_messages visibility_available_$what_kind object "
void f() __attribute__((visibility(\"$what_kind\")));
void f() {}
"]
}
So I think this is probably doing the right thing for all targets now.
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 --- Comment #3 from ktkachov at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #1) > Another, not mutually exclusive approach would be to make libgfortran LTO > clean so the more complex minloc etc calls could be pulled in. Interesting. What would it take to build libgfortran with LTO? Is it just a matter of adding -flto to then right build flags?
[Bug testsuite/90713] [10 regression] FAIL: gcc.dg/gimplefe-40.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90713 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-03 Ever confirmed|0 |1 --- Comment #2 from Segher Boessenkool --- Confirmed. And confirmed that the testcase works fine with -maltivec. vect_float is the wrong selector to see if vectors of float are enabled by current compiler options: # Return 1 if the target supports hardware vectors of float when # -funsafe-math-optimizations is enabled, 0 otherwise. # # This won't change for different subtargets so cache the result. This testcase will need a test to see if there are 16 byte vector floats. Something that just tries to create a typedef float v4sf __attribute__((vector_size(16))); variable should do fine. Oh, and the gimple front end shouldn't ICE the compiler, of course :-/
[Bug d/90718] libphobos.phobos_shared/std/socket.d FAILs on 32-bit Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90718 --- Comment #1 from Rainer Orth --- Created attachment 46444 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46444=edit Proposed patch
[Bug d/90718] libphobos.phobos_shared/std/socket.d FAILs on 32-bit Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90718 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.2
[Bug tree-optimization/90697] ia64: segmentation fault during GIMPLE pass: dom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90697 --- Comment #4 from John Paul Adrian Glaubitz --- (In reply to Richard Biener from comment #3) > I can't reproduce this. Matthias, IIRC the debian version is not 8.3.0 but > patched - to which rev? That's currently SVN 20190428 (r270630), see [1]. > [1] > http://metadata.ftp-master.debian.org/changelogs/main/g/gcc-8/gcc-8_8.3.0-7_changelog
[Bug d/90718] New: libphobos.phobos_shared/std/socket.d FAILs on 32-bit Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90718
Bug ID: 90718
Summary: libphobos.phobos_shared/std/socket.d FAILs on 32-bit
Solaris/SPARC
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Target: sparc*-*-solaris2.11
The libphobos.phobos_shared/std/socket.d test FAILs on 32-bit Solaris/SPARC:
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00043eb4 in std.socket.getAddressInfoImpl(const(char[]), const(char[]),
core.sys.posix.netdb.addrinfo*) (node=..., service=..., hints=0xffbfddd4)
at
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/socket.d:1006
1006cast(AddressFamily) ai.ai_family,
1: x/i $pc
=> 0x43eb4
<_D3std6socket18getAddressInfoImplFxAaxAaPS4core3sys5posix5netdb8addrinfoZAS3std6socket11AddressInfo+504>:
ld [ %g1 + 4 ], %g1
(gdb) p/x $g1
$1 = 0x21
The first time through, ai is
$9 = {ai_flags = 0, ai_family = 2, ai_socktype = 0, ai_protocol = 0,
_ai_pad = 16, ai_addrlen = 0, ai_canonname = 0xac710 "", ai_addr = 0xac4c0,
ai_next = 0x21}
i.e. ai_next is bogus.
Comparing the struct addrinfo declarations in
struct addrinfo {
int ai_flags; /* AI_PASSIVE, AI_CANONNAME, ... */
int ai_family; /* PF_xxx */
int ai_socktype;/* SOCK_xxx */
int ai_protocol;/* 0 or IPPROTO_xxx for IPv4 and IPv6 */
#ifdef __sparcv9
int _ai_pad;/* for backwards compat with old size_t */
#endif /* __sparcv9 */
socklen_t ai_addrlen;
char *ai_canonname; /* canonical name for hostname */
struct sockaddr *ai_addr; /* binary address */
struct addrinfo *ai_next; /* next structure in linked list */
};
and libdruntime/core/sys/posix/netdb.d
struct addrinfo
{
int ai_flags;
int ai_family;
int ai_socktype;
int ai_protocol;
version (SPARC)
int _ai_pad;
else version (SPARC64)
int _ai_pad;
socklen_t ai_addrlen;
char* ai_canonname;
sockaddr* ai_addr;
addrinfo* ai_next;
}
There's a mismatch here: the system version has no _ai_pad member on 32-bit
SPARC; no idea how this crept into the druntime version.
Fixing as in the attached patch lets the test get further along. It still
FAILs
however:
Aborting from
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/gcc/sections/elf_shared.d(724)
DSO already registered.
but this is a different issue affecting a couple of other tests as well.
[Bug debug/90717] wrong stmt location for breakpoint, XFAIL gcc.dg/guality/pr90716.c -flto -fuse-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90717
Richard Biener changed:
What|Removed |Added
Keywords||wrong-debug
CC||aoliva at gcc dot gnu.org
Blocks||90716
--- Comment #1 from Richard Biener ---
Alex? Even in .final t.c:23 is only mentioned after all locations for b/j,
while we want to preserve them we only want the "last" value, not all views
on a instruction for line 23. At least until gdb has better support for
location views?
(note 476 553 477 2 t.c:16 NOTE_INSN_BEGIN_STMT)
(note 477 476 478 2 t.c:17 NOTE_INSN_BEGIN_STMT)
(note 478 477 554 2 t.c:16 NOTE_INSN_BEGIN_STMT)
(note 554 478 479 2 (var_location j (const_int 8 [0x8]))
NOTE_INSN_VAR_LOCATION)
(note 479 554 480 2 t.c:16 NOTE_INSN_BEGIN_STMT)
(note 480 479 555 2 t.c:14 NOTE_INSN_BEGIN_STMT)
(note 555 480 481 2 (var_location b (const_int 7 [0x7]))
NOTE_INSN_VAR_LOCATION)
(note 481 555 482 2 t.c:14 NOTE_INSN_BEGIN_STMT)
(note 482 481 286 2 t.c:23 NOTE_INSN_BEGIN_STMT)
(insn:TI 286 482 272 2 (parallel [
(set (reg:DI 0 ax)
(const_int 0 [0]))
(clobber (reg:CC 17 flags))
]) "t.c":23:3 60 {*movdi_xor}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(call_insn:TI 272 286 483 2 (call (mem:QI (symbol_ref:DI ("optimize_me_not")
[flags 0x3] ) [0 optimize_me_not
S1 A8])
(const_int 0 [0])) "t.c":23:3 666 {*call}
(expr_list:REG_CALL_ARG_LOCATION (nil)
(expr_list:REG_DEAD (reg:QI 0 ax)
(expr_list:REG_CALL_DECL (symbol_ref:DI ("optimize_me_not") [flags
0x3] )
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)
(expr_list (use (reg:QI 0 ax))
(nil)))
(note 483 272 287 2 t.c:24 NOTE_INSN_BEGIN_STMT)
(insn 287 483 279 2 (parallel [
(set (reg:DI 0 ax)
(const_int 0 [0]))
(clobber (reg:CC 17 flags))
]) "t.c":25:1 60 {*movdi_xor}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 279 287 288 2 (use (reg/i:SI 0 ax)) "t.c":25:1 -1
(nil))
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90716
[Bug 90716] [10 Regression] gcc generates wrong debug information at -O2
[Bug debug/90717] New: wrong stmt location for breakpoint, XFAIL gcc.dg/guality/pr90716.c -flto -fuse-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90717
Bug ID: 90717
Summary: wrong stmt location for breakpoint, XFAIL
gcc.dg/guality/pr90716.c -flto -fuse-linker-plugin
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
The gcc.dg/guality/pr90716.c testcase fails with -O2 -fwhole-program,
expanding from
main ()
{
[local count: 17041817]:
[t.c:12:3] # DEBUG BEGIN_STMT
[t.c:13:3] # DEBUG BEGIN_STMT
[t.c:13:5] # DEBUG b => 0
[t.c:14:3] # DEBUG BEGIN_STMT
# DEBUG b => 0
[t.c:14:10] # DEBUG BEGIN_STMT
# DEBUG j => 0
[t.c:16:14] # DEBUG BEGIN_STMT
... unrolled loop ...
[t.c:16:14] # DEBUG BEGIN_STMT
[t.c:17:2] # DEBUG BEGIN_STMT
[t.c:16:21] # DEBUG BEGIN_STMT
# DEBUG j => 8
[t.c:16:14] # DEBUG BEGIN_STMT
[t.c:14:17] # DEBUG BEGIN_STMT
# DEBUG b => 7
[t.c:14:10] # DEBUG BEGIN_STMT
[t.c:23:3] # DEBUG BEGIN_STMT
[t.c:23:3] optimize_me_not ();
[t.c:24:3] # DEBUG BEGIN_STMT
return 0;
gdb puts the breakpoint at
Breakpoint 1, main ()
at
/space/rguenther/src/svn/trunk2/gcc/testsuite/gcc.dg/guality/pr90716.c:23
23optimize_me_not(); /* { dg-final { gdb-test . "j + 1" "9" } } */
(gdb) disassemble
Dump of assembler code for function main:
=> 0x004003e0 <+0>: xor%eax,%eax
0x004003e2 <+2>: callq 0x4004d0
0x004003e7 <+7>: xor%eax,%eax
0x004003e9 <+9>: retq
where
(gdb) p j
$1 = 0
but at the "correct" location the correct value is displayed.
(gdb) si
0x004003e2 23optimize_me_not(); /* { dg-final { gdb-test .
"j + 1" "9" } } */
(gdb) p j
$2 = 8
Somehow things must go wrong on the RTL / debuginfo creation level putting
the location views for 'j' on a assembler stmt associated with line 23.
[Bug debug/90716] [10 Regression] gcc generates wrong debug information at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90716 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Version|unknown |10.0 Keywords||wrong-debug Last reconfirmed||2019-06-03 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|gcc generates wrong debug |[10 Regression] gcc |information at -O2 |generates wrong debug ||information at -O2 Target Milestone|--- |10.0 --- Comment #1 from Richard Biener --- Confirmed. loop-distribution performs manual removal of the old loop body in destroy_loop () but it moves debug stmts in bogus order. I have a patch.
[Bug c++/26989] C++ front-end (and others parts of GCC) use the wrong check to see if hidden visibility is there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26989 --- Comment #8 from Iain Sandoe --- (In reply to Jonathan Wakely from comment #7) > Cc Iain who probably knows more about the Darwin linker. I'm pretty sure it > supports visibility now because LLVM's libc++ makes extensive use of > visibility attributes. hmm... Darwin7 ... Well... as things stand Darwin7 will not bootstrap even gcc-4.6 with its system toolchain [xcode 1.5] (it fails very early with "make is too old") I haven't figured a recipe for the minimum number of tools that need to be upgraded yet (and it's frankly very low priority). However, that being said - we should verify that the test is appropriate to newer systems too (or even still exists?)
[Bug c++/26989] C++ front-end (and others parts of GCC) use the wrong check to see if hidden visibility is there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26989 Jonathan Wakely changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #7 from Jonathan Wakely --- Cc Iain who probably knows more about the Darwin linker. I'm pretty sure it supports visibility now because LLVM's libc++ makes extensive use of visibility attributes.
[Bug testsuite/90713] [10 regression] FAIL: gcc.dg/gimplefe-40.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90713
Richard Biener changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Component|middle-end |testsuite
--- Comment #1 from Richard Biener ---
This means that V4SF is not a supported vector type despite { target {
vect_float } }. I suppose -maltivec is needed here, but why does vect_float
not verify that is provided?
[Bug testsuite/90713] [10 regression] FAIL: gcc.dg/gimplefe-40.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90713 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug target/90712] [10 regression] gcc.dg/rtl/aarch64/subs_adds_sp.c fails with ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90712 Richard Biener changed: What|Removed |Added Version|unknown |10.0 Target Milestone|--- |10.0
[Bug tree-optimization/90697] ia64: segmentation fault during GIMPLE pass: dom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90697 Richard Biener changed: What|Removed |Added CC||doko at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- I can't reproduce this. Matthias, IIRC the debian version is not 8.3.0 but patched - to which rev?
[Bug middle-end/90694] incorrect representation of ADDR_EXPR involving a pointer to array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90694 --- Comment #6 from Richard Biener --- (In reply to Richard Biener from comment #5) > Just as a note - the tree/GIMPLE dumps are not C source code so > this kind of "issues" are expected. Watch out for testsuite fallout. For the latter esp. tests with scan-tree-dump-not might no longer be testing what they were supposed to ...
[Bug middle-end/90694] incorrect representation of ADDR_EXPR involving a pointer to array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90694 --- Comment #5 from Richard Biener --- Just as a note - the tree/GIMPLE dumps are not C source code so this kind of "issues" are expected. Watch out for testsuite fallout.
