[Bug ipa/86323] [9 regression] internal compiler error: in estimate_edge_growth, at ipa-inline.h:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86323 --- Comment #3 from Martin Liška --- Author: marxin Date: Mon Jul 2 07:04:01 2018 New Revision: 262297 URL: https://gcc.gnu.org/viewcvs?rev=262297&root=gcc&view=rev Log: Revert one ipa_call_summaries::get to get_create (PR ipa/86323). 2018-07-02 Martin Liska PR ipa/86323 * ipa-inline.c (early_inliner): Revert wrongly added ::get call. 2018-07-02 Martin Liska PR ipa/86323 * g++.dg/ipa/pr86323.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr86323.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/86279] [9 Regression] ICE in malloc_candidate_p, at ipa-pure-const.c:927
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86279 --- Comment #2 from Martin Liška --- Author: marxin Date: Mon Jul 2 07:04:20 2018 New Revision: 262298 URL: https://gcc.gnu.org/viewcvs?rev=262298&root=gcc&view=rev Log: Revert 2 ::get to ::get_create for IPA summaries (PR ipa/86279). 2018-07-02 Martin Liska PR ipa/86279 * ipa-pure-const.c (malloc_candidate_p): Revert usage of ::get. (propagate_nothrow): Likewise. 2018-07-02 Martin Liska PR ipa/86279 * gcc.dg/ipa/pr86279.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ipa/pr86279.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-pure-const.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/45305] Array-valued calles to elementals are not simplified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45305 --- Comment #5 from Paul Thomas --- Author: pault Date: Mon Jul 2 07:20:27 2018 New Revision: 262299 URL: https://gcc.gnu.org/viewcvs?rev=262299&root=gcc&view=rev Log: 2018-07-02 Paul Thomas PR fortran/45305 * expr.c : Add a prototype for scalarize_intrinsic_call. (gfc_simplify_expr): Use scalarize_intrinsic_call for elemental intrinsic function calls. (scalarize_intrinsic_call): Add 'init_flag' argument. Check if the expression or any of the actual argument expressions are NULL. Before calling gfc_check_init_expr, check 'init_flag'. Only simplify the scalarized expressions if there are no errors on the stack. (gfc_check_init_expr): Set 'init_flag' true in the call to scalarize_intrinsic_call. 2018-07-02 Paul Thomas PR fortran/45305 * gfortran.dg/scalarize_parameter_array_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/scalarize_parameter_array_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/45305] Array-valued calles to elementals are not simplified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45305 Paul Thomas changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Paul Thomas --- Fixed on trunk Thanks for the report. Paul
[Bug fortran/45305] Array-valued calles to elementals are not simplified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45305 --- Comment #7 from Paul Thomas --- Author: pault Date: Mon Jul 2 07:24:43 2018 New Revision: 262300 URL: https://gcc.gnu.org/viewcvs?rev=262300&root=gcc&view=rev Log: 2018-07-02 Paul Thomas PR fortran/45305 * expr.c : Add a prototype for scalarize_intrinsic_call. (gfc_simplify_expr): Use scalarize_intrinsic_call for elemental intrinsic function calls. (scalarize_intrinsic_call): Add 'init_flag' argument. Check if the expression or any of the actual argument expressions are NULL. Before calling gfc_check_init_expr, check 'init_flag'. Only simplify the scalarized expressions if there are no errors on the stack. (gfc_check_init_expr): Set 'init_flag' true in the call to scalarize_intrinsic_call. 2018-07-02 Paul Thomas PR fortran/45305 * gfortran.dg/scalarize_parameter_array_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_50.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/86323] [9 regression] internal compiler error: in estimate_edge_growth, at ipa-inline.h:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86323 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed.
[Bug ipa/86279] [9 Regression] ICE in malloc_candidate_p, at ipa-pure-const.c:927
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86279 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed.
[Bug lto/86321] [9 Regression] ICE: in splice_child_die, at dwarf2out.c:5693 for several Fortran tests with -g -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86321 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug lto/86321] [9 Regression] ICE: in splice_child_die, at dwarf2out.c:5693 for several Fortran tests with -g -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86321 --- Comment #7 from Richard Biener --- Author: rguenth Date: Mon Jul 2 08:00:47 2018 New Revision: 262301 URL: https://gcc.gnu.org/viewcvs?rev=262301&root=gcc&view=rev Log: 2018-07-02 Richard Biener PR lto/86321 * trans-types.c (gfc_get_array_type_bounds): Unshare TYPE_FIELDs for the distinct type copy. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c
[Bug fortran/56670] Allocatable-length character var causes bogus warning with -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56670 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #5 from janus at gcc dot gnu.org --- Related test case: subroutine sub(strIn, strOut) character(len=10) :: strOut character(len=100) :: strIn associate (substr => strIn(1:10)) strout = substr end associate end Compiling this with "gfortran-8 -Wall" yields: strout = substr Warning: ‘.substr’ is used uninitialized in this function [-Wuninitialized] gfortran-7 and earlier doesn't show this warning.
[Bug c++/86369] constexpr const char* comparison fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369 Nicolas Lesser changed: What|Removed |Added CC||blitzrakete at gmail dot com --- Comment #1 from Nicolas Lesser --- For clarity, b1 shouldn't compile. [lex.string]p16 says: "whether successive evaluations of a string-literal yield the same or a different object is unspecified." [expr.const]p2 says: "An expression e is a core constant expression unless the evaluation of e, [...], would evaluate one of the following expressions: [...]; a relational or equality operator where the result is unspecified;"
[Bug fortran/86372] New: [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372 Bug ID: 86372 Summary: [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Target Milestone: ---
[Bug fortran/86372] [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #1 from janus at gcc dot gnu.org ---
Test case:
program xxx
character(len=50) :: s
s = repeat('*', len(s))
call sub(s)
print *, s
contains
subroutine sub(str)
character(len=*), intent(inout) :: str
associate (substr => str(3:5))
substr = '123'
end associate
end subroutine
end
With gfortran version 5 to 7 it compiles ok and prints at runtime:
**
This is already wrong, since the string should be modified is the subroutine.
With gfortran 8 and trunk there is even a segfault at runtime (on the line
"substr = '123'"), and the warning mentioned in PR 56670 comment 5:
substr = '123'
Warning: ‘.substr’ is used uninitialized in this function [-Wuninitialized]
[Bug fortran/56670] Allocatable-length character var causes bogus warning with -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56670 janus at gcc dot gnu.org changed: What|Removed |Added Summary|Allocatable-length |Allocatable-length |character var causes bogus |character var causes bogus |warning with -Wall |warning with ||-Wuninitialized --- Comment #6 from janus at gcc dot gnu.org --- (In reply to janus from comment #5) > Related test case: This is probably a separate problem, since it is also connected to a wrong-code bug, see PR 86372.
[Bug c++/86369] constexpr const char* comparison fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369 --- Comment #2 from Jonathan Wakely --- Clang trunk also rejects it for the same reason, icc accepts it.
[Bug tree-optimization/86363] [9 Regression] wrong code with __builtin_memset() at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86363
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Comment #1 from Bernd Edlinger ---
looks correct until pr86363.c.032t.ealias:
_1 = BIT_FIELD_REF ;
# PT = null { D.1901 }
_2 = &VIEW_CONVERT_EXPR(uD.1901)[_1];
# .MEM_11 = VDEF <.MEM_10(D)>
# USE = nonlocal null
# CLB = nonlocal null
memsetD.870 (_2, 0, 1);
# VUSE <.MEM_11>
_12 = BIT_FIELD_REF ;
_4 = (unsigned intD.9) _12;
_5 = (unsigned intD.9) _12;
_6 = (unsigned intD.9) _12;
_7 = (unsigned intD.9) _12;
_3 = {_4, _5, _6, _7};
# VUSE <.MEM_11>
g.0_8 = gD.1899;
_9 = _3 ^ g.0_8;
# .MEM_13 = VDEF <.MEM_11>
gD.1899 = _9;
problem starts in pr86363.c.033t.fre1:
Replaced BIT_FIELD_REF with 0 in all uses of _12 = BIT_FIELD_REF ;
...
_1 = BIT_FIELD_REF ;
# PT = null { D.1901 }
_2 = &VIEW_CONVERT_EXPR(uD.1901)[_1];
# .MEM_11 = VDEF <.MEM_10(D)>
# USE = nonlocal null
# CLB = nonlocal null
memsetD.870 (_2, 0, 1);
# VUSE <.MEM_11>
g.0_8 = gD.1899;
# VUSE <.MEM_11>
return g.0_8;
[Bug fortran/86372] [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-07-02 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- I get the warning with gcc8 and trunk (9.0), but the output is the expected one: **123*
[Bug fortran/86372] [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) > I get the warning with gcc8 and trunk (9.0), but the output is the expected > one: > > **123* Oh, really? That's interesting. Do you also get the correct output with earlier gfortran versions? Strangely, if I use a shorter string, e.g. "character(len=40) :: s", the segfault disappears, but the output is still only stars. Puzzling.
[Bug middle-end/85504] Bogus -Wrestrict warning with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85504 Bernd Edlinger changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Bernd Edlinger --- .
[Bug fortran/82173] [meta-bug] Parameterized derived type errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 Bug 82173 depends on bug 82865, which changed state. Bug 82865 Summary: Option -fdec collides with PDT https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug fortran/82865] Option -fdec collides with PDT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865
Rainer Orth changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||ro at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #13 from Rainer Orth ---
(In reply to Fritz Reese from comment #12)
> Author: foreese
> Date: Fri Jun 29 20:29:34 2018
> New Revision: 262260
>
> URL: https://gcc.gnu.org/viewcvs?rev=262260&root=gcc&view=rev
> Log:
> Revert r262224 (backport of r262221) as PDTs are not supported in 7-branch.
>
> gcc/fortran/ChangeLog:
> -2018-06-28 Fritz Reese
> -
> - PR fortran/82865
> - Backport from trunk.
> - * decl.c (gfc_match_type): Refactor and check for PDT declarations.
> -
>
> gcc/testsuite/ChangeLog:
> -2018-06-28 Fritz Reese
> -
> - PR fortran/82865
> - Backport from trunk.
> - * gfortran.dg/dec_type_print_2.f03: New testcase.
> -
>
> Removed:
> branches/gcc-7-branch/gcc/testsuite/gfortran.dg/dec_type_print_2.f03
> Modified:
> branches/gcc-7-branch/ (props changed)
> branches/gcc-7-branch/gcc/ada/s-interr-hwint.adb (props changed)
> branches/gcc-7-branch/gcc/fortran/ChangeLog
> branches/gcc-7-branch/gcc/fortran/decl.c
> branches/gcc-7-branch/gcc/testsuite/ChangeLog
> branches/gcc-7-branch/gcc/testsuite/gnat.dg/opt65.adb (props changed)
>
> Propchange: branches/gcc-7-branch/
> ('svn:mergeinfo' modified)
>
> Propchange: branches/gcc-7-branch/gcc/ada/s-interr-hwint.adb
> ('svn:mergeinfo' modified)
>
> Propchange: branches/gcc-7-branch/gcc/testsuite/gnat.dg/opt65.adb
> ('svn:mergeinfo' modified)
It seems the backport caused a caused quite a number on testsuite failures
on the gcc-7 branch:
+FAIL: gfortran.dg/dec_type_print_2.f03 -O0 (test for excess errors)
+UNRESOLVED: gfortran.dg/dec_type_print_2.f03 -O0 compilation failed to
produce executable
+FAIL: gfortran.dg/dec_type_print_2.f03 -O1 (test for excess errors)
+UNRESOLVED: gfortran.dg/dec_type_print_2.f03 -O1 compilation failed to
produce executable
+FAIL: gfortran.dg/dec_type_print_2.f03 -O2 (test for excess errors)
+UNRESOLVED: gfortran.dg/dec_type_print_2.f03 -O2 compilation failed to
produce executable
+FAIL: gfortran.dg/dec_type_print_2.f03 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess
errors)
+UNRESOLVED: gfortran.dg/dec_type_print_2.f03 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions compilation failed to
produce executable
+FAIL: gfortran.dg/dec_type_print_2.f03 -O3 -g (test for excess errors)
+UNRESOLVED: gfortran.dg/dec_type_print_2.f03 -O3 -g compilation failed to
produce executable
+FAIL: gfortran.dg/dec_type_print_2.f03 -Os (test for excess errors)
+UNRESOLVED: gfortran.dg/dec_type_print_2.f03 -Os compilation failed to
produce executable
Excess errors:
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:12:2:
Error: Unclassifiable statement at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:13:12:
Error: Invalid character in name at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:14:12:
Error: Invalid character in name at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:15:16:
Error: Symbol 'i' at (1) already has basic type of INTEGER
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:16:17:
Error: Symbol 'a' at (1) has no IMPLICIT type
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:18:5:
Error: Expecting END PROGRAM statement at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:20:13:
Error: Derived type 'mytype' at (1) is being used before it is defined
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:21:13:
Error: Derived type 'mytype' at (1) is being used before it is defined
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:23:2:
Error: Unclassifiable statement at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:24:2:
Error: Unclassifiable statement at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:25:2:
Error: Unclassifiable statement at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:26:2:
Error: Unclassifiable statement at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:27:2:
Error: Unclassifiable statement at (1)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:28:2:
Error: Unclassifiable statement at (1)
/vol/gcc/src/hg/gcc-7-bran
[Bug tree-optimization/86363] [9 Regression] wrong code with __builtin_memset() at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86363 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-07-02 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- I will have a look.
[Bug lto/86366] [9 regression] gcc.dg/profile-dir-3.c fails starting with r262251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86366 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug bootstrap/86371] building compiler tries to look in $HOME/local/include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86371
Richard Biener changed:
What|Removed |Added
Keywords||build
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-07-02
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed. gcc/brig/Make-lang.in contains
BRIGINCLUDES = -I $(srcdir)/brig -I ${HOME}/local/include \
-I $(srcdir)/brig/brigfrontend
[Bug fortran/86372] [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |8.2
[Bug lto/86366] [9 regression] gcc.dg/profile-dir-3.c fails starting with r262251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86366 avieira at gcc dot gnu.org changed: What|Removed |Added CC||avieira at gcc dot gnu.org --- Comment #2 from avieira at gcc dot gnu.org --- Hi Martin, We have also seen profile-dir-1.gcda fail on aarch64-none-linux-gnu and arm-none-linux-gnueabihf, as well as profile-dir-3.gcda, recently. I am assuming this is all related. Cheers, Andre
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #10 from Richard Biener --- FRE uses native_encode_real / native_interpret_int to read the NAN as integer. I suspect that something goes wrong with native_encode_real here or in real_to_target which is used by that function.
[Bug debug/78685] -Og generates too many ""s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685
Tom de Vries changed:
What|Removed |Added
Attachment #44333|0 |1
is obsolete||
--- Comment #12 from Tom de Vries ---
Created attachment 44343
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44343&action=edit
[debug] Add -fkeep-vars-live
(In reply to Richard Biener from comment #10)
> (In reply to Tom de Vries from comment #8)
> > Created attachment 44333 [details]
> > proof of concept patch
> >
> > I ran into the same problem with guality test-case pr54200.c, which fails
> > for Og.
> >
> > The relevant part of the test-case is:
> > ...
> > int __attribute__((noinline,noclone))
> > foo (int z, int x, int b)
> > {
> > if (x == 1)
> > {
> > bar ();
> > return z;
> > }
> > else
> > {
> > int a = (x + z) + b;
> > return a; /* { dg-final { gdb-test 20 "z" "3" } } */
> > }
> > }
> > ...
> >
> > The problem is that the '(x + z) + b' calculation has a temporary register
> > which gets allocated the register that holds 'z', so when we get to the
> > gdb-test line, z is no longer available.
> >
> > Using this patch I managed to print the correct value of z at the gdb-test
> > line.
> >
> > The patch uses clobbers in gimple to mark the out-of-scope point, purely
> > because that's similar to what was already done for local array variables,
> > and I thought that was the fastest path to getting a proof of concept
> > working. It's more accurate to model this as some sort of use in gimple, and
> > doing so may prevent gimple optimizations which wreck debug info, but
> > perhaps that's not necessary, I suppose that depends on which optimizations
> > are enabled in Og.
> >
> > Anyway, at expand we emit a use for the clobber which seems to do the trick.
>
> An interesting idea but I think this will cause excessive spilling and
> come at a compile-time cost. The idea of -Og was to have performance
> closer to -O1 here and with this we approach -O0 in assigning stack slots
> to all user variables?
>
Agreed, there will be a compile time cost. I've moved the functionality to an
orthogonal option -fkeep-vars-live (as suggested in comment 3), to keep Og as
is. Also, I agree there will be more spilling, but I'd hope that memory usage
still would be less than for O0.
> This is a general conflict of interest of course.
>
> Your patch shouldn't prevent any optimization at the GIMPLE level
> (like completely eliding local variables)
I've fixed that now, in the sense that it generates uses rather than clobbers
at gimple level.
> but definitely they'll keep
> things live at RTL level. Given for the testcase at hand the issue
> is "suboptimal" choice of register allocation I wonder if we can
> adjust the RA / DF to consider liveness to extend always up to the
> next sequence point.
>
> That is, it is reasonable to lose track of z in
>
> int a = (x + z) + b;
>
> but only after x + z is computed.
Right, that could maybe be a way to improve on Og.
But the trade-off I'm going for currently with "Og -fkeep-vars-live" is:
O0-like debug experience, slower compilation than Og, faster execution than
-O0.
> So a different approach would be
> to see this as an issue with the way debug consumers "step" now that
> we emit column debug information?
>
> That said, starting with GCC 8 we now have # DEBUG BEGIN_STMT
> markers:
>
>[local count: 856416479]:
> # DEBUG BEGIN_STMT
> _1 = x_4(D) + z_7(D);
> a_9 = _1 + b_8(D);
> # DEBUG a => a_9
> # DEBUG BEGIN_STMT
>
> they are also present on RTL as
>
> (debug_insn 21 20 0 (debug_marker) "t.c":11 -1
> (nil))
>
> which means we _could_ somehow use those for code-generation (in DF analysis
> to extend lifetimes somehow). Of course if we do we have to emit those
> always to not get code-gen differences -g vs. -g0.
>
> Maybe the RA could also be generally changed to use a not-LRU style
> preferencing of available registers to choose from.
>
> In the end nothing saves us from "spilling" things if we really want to
> be able to access all final values of registers up to the point they
> go out of scope...
>
> So another idea would be instead of like -O0 assigning the main location
> to the stack we spill no longer used vars during LRA? We'd still have to
> somehow know until when that spill slot needs to live (and afterwards can
> be re-used).
To stay in terms of the current patch, that could mean we mark artificial uses
as such, and then make the compiler handle them smarter than regular uses.
[ Also, this version of the patch adds insertion of nops to prevent empty debug
ranges, which allows me to get the value of 'a' at the 'return a' mentioned
above. ]
[Bug fortran/82865] Option -fdec collides with PDT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865 --- Comment #14 from Fritz Reese --- (In reply to Rainer Orth from comment #13) > > It seems the backport caused a caused quite a number on testsuite failures > on the gcc-7 branch: > ... I reverted the backport in r262260. Are you certain that you still see those errors after the reversion? That testcase file should no longer exist in the tree. > > Besides, all those svn property changes are at least unrelated. > > Rainer That is what I suspected. ‘svn merge’ added them for some reason (even from a clean tree). I’ll make sure to keep those out of future merges.
[Bug c++/86373] New: Destructor shall not be instantiated in C++17 mode for prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86373
Bug ID: 86373
Summary: Destructor shall not be instantiated in C++17 mode for
prvalue
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Following program fails to compile in -std=c++17 mode
struct some {
some() = default;
~some() = delete;
};
some foo() {
return {};
}
More realistic example:
#include
struct some;
std::unique_ptr f() {
return {};
}
Output:
/opt/compiler-explorer/gcc-8.1.0/include/c++/8.1.0/bits/unique_ptr.h:79:16:
error: invalid application of 'sizeof' to incomplete type 'some'
static_assert(sizeof(_Tp)>0,
However [basic.lval] say "The result object of a prvalue is the object
initialized by the prvalue; a prvalue that is used to compute the value of an
operand of an operator or that has type (possibly cv-qualified) void has no
result object."
So looks like std::unique_ptr has no object here, so the destructor shall
not be instantiated.
Clang compiles both of the above examples.
[Bug fortran/86372] [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372 janus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #1) > With gfortran 8 and trunk there is even a segfault at runtime (on the line > "substr = '123'"), and the warning mentioned in PR 56670 comment 5: > > substr = '123' > > Warning: ‘.substr’ is used uninitialized in this function [-Wuninitialized] I guess the varying runtime behavior is caused by the uninitialized string length. Setting it to the proper value should fix this bug.
[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 Rainer Orth changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ro at gcc dot gnu.org Resolution|FIXED |--- --- Comment #12 from Rainer Orth --- The new testcase FAILs on Solaris/SPARC on trunk, gcc-7 and gcc-8 branches: 32-bit sparc: +FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O0 execution test +FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O1 execution test 64-bit sparc also: +FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O2 execution test +FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test +FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O3 -g execution test +FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -Os execution test On gcc-testresults, there are also reports on hppa2.0w-hp-hpux11.11, spu-unknown-elf. The tests FAIL like this: Program received signal SIGBUS: Access to an undefined portion of a memory object. Backtrace for this error: gdb shows Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x00011244 in MAIN__ () at /vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/unlimited_polymorphic_30.f03:13 13x%v = ['foo','bar'] (gdb) where #0 0x00011244 in MAIN__ () at /vol/gcc/src/hg/gcc-7-branch/local/gcc/testsuite/gfortran.dg/unlimited_polymorphic_30.f03:13 1: x/i $pc => 0x11244 :ld [ %g1 ], %g1 (gdb) p/x $g1 $1 = 0x22a4b i.e. an unaligned access.
[Bug driver/86030] specs file processing does not create response files for input directories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030 Tamar Christina changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2018-07-02 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #2 from Tamar Christina --- It seems that this is not fully fixed yet. There are a number of other issues here. Given a simple response file /d/t/temp cat foo test.c -L/tmp/temp -L/bar/temp/rr -ldata_boo and calling gcc @foo -save-temps -### shows a few problems. At first glance it looks like the correct thing was done, the options are split into two new response files and passed along to collect2 and the commandline for collect2 no longer has the paths expanded in them. /d/t/temp cat /tmp/ccIP9us9 test.o -ldata_boo /d/t/temp cat /tmp/ccSls8Kg -L/tmp/temp -L/bar/temp/rr However, annoyingly, they have been expanded and placed into the `COLLECT_GCC_OPTIONS` environment variable COLLECT_GCC_OPTIONS='-L/tmp/temp' '-L/bar/temp/rr' '-save-temps' '-mlittle-endian' '-mabi=lp64' Which means they're getting passed twice.. And finally it seems that when collect2 makes the call to ld, it places everything on one giant commandline, undoing all the work of creating the response files and exploding the path. collect2 should honor the response files in it's output!
[Bug driver/86030] specs file processing does not create response files for input directories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030 --- Comment #3 from Tamar Christina --- Hmm according to 45749 with `HAVE_GNU_LD` on it should work for the ld call. I will give that a try. But the environment variable one is still an issue as far as I can tell.
[Bug ipa/86274] [7/8/9 Regression] SEGFAULT when logging std::to_string(NAN)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86274
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |7.4
--- Comment #12 from Richard Biener ---
So after gimplification I see
__s = __builtin_alloca (__n);
__builtin_va_start (&__args, 0);
__len = __convf (__s, __n, __fmt, &__args);
__builtin_va_end (&__args);
std::allocator::allocator (&D.109301);
try
{
try
{
_1 = (sizetype) __len;
_2 = __s + _1;
std::__cxx11::basic_string::basic_string (,
__s, _2, &D.109301);
return ;
}
finally
{
std::allocator::~allocator (&D.109301);
}
which after SSA rewrite looks like
std::__cxx11::basic_string::basic_string (_16(D), __s_7, _2,
&D.109301);
So we're rewriting into SSA which is expected,
is DECL_BY_REFERENCE. So that is a red herring.
I suppose the new printf code simply doesn't handle default-defs that
come in as DECL_BY_REFERENCE RESULT_DECL.
Note what the pass causes is simply treating
_3 = vsnprintf (__s_2, 328, "%f", &__args);
as not returning zero and thus eliding a == 0 check. For some reason
it says _3 is [8, 322] though but obviously 'NaN' prints as 3 characters
only...
So, martin? Reduced testcase:
volatile double x;
int main()
{
char *s = __builtin_alloca (220);
x = __builtin_nan("nan");
if (__builtin_snprintf (s, 220, "%f", x) != 3)
__builtin_abort ();
return 0;
}
[Bug c++/86374] New: [8 regression] template member name lookup problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86374
Bug ID: 86374
Summary: [8 regression] template member name lookup problem
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s...@li-snyder.org
Target Milestone: ---
hi -
With gcc checked out on 2018-07-01 from gcc-8-branch (rev 262277,
tested on x86_64-pc-linux-gnu [fedora 28]), this input:
-- y.cc
template
struct list {
static const int index = 1;
template struct addWithChecking {};
};
template
struct find{
static const int result = 0;
};
template
template
struct list::addWithChecking
{
static const int xres = find >::result;
};
gives an error:
$ cc1plus -quiet -v -D_GNU_SOURCE y.cc -quiet -std=c++17
...
y.cc:16:43: error: ‘index’ is not a member of ‘list’
static const int xres = find >::result;
^
y.cc:16:43: error: template argument 2 is invalid
This was accepted by gcc on this branch as of early June, as well as
8.1.1 20180502 and clang 6.0.0.
The error started occurring with this change:
r261460 | jason | 2018-06-11 18:01:55 -0400 (Mon, 11 Jun 2018) | 5 lines
PR c++/85815 - reference to member of enclosing template.
* search.c (lookup_base): Use currently_open_class.
(lookup_member): Use it regardless of -fconcepts.
* parser.c (cp_parser_postfix_dot_deref_expression): Check it.
thanks,
sss
[Bug c++/86375] New: Lambda call in template parameter causes compile time error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86375
Bug ID: 86375
Summary: Lambda call in template parameter causes compile time
error
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Following example fail to compile:
template struct stuff {};
stuff< [](){ return 42; }() > a; // Calling a constexpr lambda
Error message:
lambda-expression in template-argument
stuff< [](){ return 42; }() > a;
Replacing the lambda with variable that holds lambda works well:
template struct stuff {};
auto f = [](){ return 42; };
stuff< f() > b; // OK
Clang compiles the first example well.
[Bug tree-optimization/86363] [9 Regression] wrong code with __builtin_memset() at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86363 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/86363] [9 Regression] wrong code with __builtin_memset() at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86363 --- Comment #4 from Richard Biener --- Author: rguenth Date: Mon Jul 2 13:32:26 2018 New Revision: 262307 URL: https://gcc.gnu.org/viewcvs?rev=262307&root=gcc&view=rev Log: 2018-07-02 Richard Biener PR tree-optimization/86363 * tree-ssa-sccvn.c (vn_reference_lookup_3): Check the memset argument refers to a non-variable address. * gcc.dg/torture/pr86363.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr86363.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug c/86376] New: recent breakage in ubsan build ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86376 Bug ID: 86376 Summary: recent breakage in ubsan build ? Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Doing a ubsan build with revision 261981 worked. Doing same with revision 262304 doesn't. It breaks at the compare of stage 2 and stage 3. Configure line is ../trunk/configure --prefix=/home/dcb/gcc/results.262304.ubsan \ --with-build-config=bootstrap-ubsan \ --disable-multilib \ --disable-werror \ --enable-checking=df,extra,fold,rtl,yes \ --enable-languages=c,c++,fortran
[Bug testsuite/86366] [9 regression] gcc.dg/profile-dir-3.c fails starting with r262251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86366 --- Comment #3 from Martin Liška --- Author: marxin Date: Mon Jul 2 14:54:07 2018 New Revision: 262311 URL: https://gcc.gnu.org/viewcvs?rev=262311&root=gcc&view=rev Log: Fix GCOV scan pattern (PR testsuite/86366). 2018-07-02 Martin Liska PR testsuite/86366 * gcc.dg/profile-dir-1.c: Fix scanned pattern. * gcc.dg/profile-dir-2.c: Likewise. * gcc.dg/profile-dir-3.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/profile-dir-1.c trunk/gcc/testsuite/gcc.dg/profile-dir-2.c trunk/gcc/testsuite/gcc.dg/profile-dir-3.c
[Bug bootstrap/86376] recent breakage in ubsan build ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86376 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-07-02 CC||marxin at gcc dot gnu.org Component|c |bootstrap Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I'll take a look.
[Bug testsuite/86366] [9 regression] gcc.dg/profile-dir-3.c fails starting with r262251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86366 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed.
[Bug c++/86243] unknown attribute before throw causes hard error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86243
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-07-02
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Martin Sebor ---
Confirmed. GCC recognizes an attribute when it applies to other statements but
gets confused when it's applied to a throw expression statement as in comment
#0.
$ cat t.C && gcc -S t.C
int f ()
{
[[unlikely]] return 0;
[[unlikely]] { }
[[unlikely]] throw 0;
}
t.C: In function ‘int f()’:
t.C:3:3: warning: attributes at the beginning of statement are ignored
[-Wattributes]
[[unlikely]] return 0;
^
t.C:4:3: warning: attributes at the beginning of statement are ignored
[-Wattributes]
[[unlikely]] { }
^
t.C:6:4: error: expected identifier before ‘[’ token
[[unlikely]] throw 0;
^
t.C: In lambda function:
t.C:6:16: error: expected ‘{’ before ‘throw’
[[unlikely]] throw 0;
^
t.C: In function ‘int f()’:
t.C:6:15: error: expected ‘;’ before ‘throw’
[[unlikely]] throw 0;
^~
;
[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-07-02
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
There is value in diagnosing the use of attributes that GCC doesn't know about.
According to the manual -Wattributes also sounds like the right option to
control warnings about unknown attributes. Unfortunately, the option is also
used by GCC to control warnings about known attributes using in a way GCC
either doesn't consider valid or cannot honor and where -Wignored-attributes
might be more appropriate. For example:
warning: ‘packed’ attribute ignored for field of type ‘char’ [-Wattributes]
struct S { __attribute__ ((packed)) char c; };
Here, packed is used correctly but is "ignored" because it is implied on
members whose alignment is 8. (It's ignored internally within GCC but that's
an implementation detail that's opaque to the user. In this instance, I'd say
the warning should not be issued.)
Similarly for:
__attribute__ ((always_inline)) inline void f (void);
__attribute ((noinline)) void f (void);
warning: ignoring attribute ‘noinline’ because it conflicts with attribute
‘always_inline’ [-Wattributes]
__attribute ((noinline)) void f (void);
where there's nothing wrong with either attribute but GCC can only honor one
and has to ignore the other. Here, the warning is useful but distinct in
nature from an unknown attribute (like the one on bug 86243).
IMO, it should be possible to control warnings about attributes unknown to GCC
independently of other warnings about uses of known attributes. Thus
confirmed.
[Bug tree-optimization/86274] [7/8/9 Regression] SEGFAULT when logging std::to_string(NAN)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86274 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug tree-optimization/86274] [7/8/9 Regression] SEGFAULT when logging std::to_string(NAN)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86274 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #13 from Martin Sebor --- The sprintf pass doesn't consider NaNs and infinities. The output for the -fdump-tree-printf-return-value option shows: ;; Function main (main, funcdef_no=0, decl_uid=1898, cgraph_uid=1, symbol_order=1) (executed once) __builtin_snprintf: objsize = 220, fmtstr = "%f" Directive 1 at offset 0: "%f" Result: 8, 8, 317, 322 (8, 8, 317, 322) Directive 2 at offset 2: "", length = 1 Setting potentially out-of-bounds return value range [8, 322]. The range should be [3, 322]. Let me handle it.
[Bug c/81577] -ftrack-macro-expansion=0 causes spurious “this ‘else’ clause does not guard” with -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81577 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #2 from Romain Geissler --- Hi, This is still happening on released gcc 8. Cheers, Romain
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #11 from ian at gcc dot gnu.org --- Author: ian Date: Mon Jul 2 16:28:43 2018 New Revision: 262313 URL: https://gcc.gnu.org/viewcvs?rev=262313&root=gcc&view=rev Log: PR go/86331 os: check return value as well as error from waitid https://gcc.gnu.org/PR86331 indicates that if a signal handler runs it is possible for syscall.Syscall6 to return a non-zero errno value even if no error occurs. That is a problem in general, but this fix will let us work around the general problem for the specific case of calling waitid. Reviewed-on: https://go-review.googlesource.com/121595 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/os/wait_waitid.go
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #12 from ian at gcc dot gnu.org --- Author: ian Date: Mon Jul 2 16:28:58 2018 New Revision: 262314 URL: https://gcc.gnu.org/viewcvs?rev=262314&root=gcc&view=rev Log: PR go/86331 os: check return value as well as error from waitid https://gcc.gnu.org/PR86331 indicates that if a signal handler runs it is possible for syscall.Syscall6 to return a non-zero errno value even if no error occurs. That is a problem in general, but this fix will let us work around the general problem for the specific case of calling waitid. Reviewed-on: https://go-review.googlesource.com/121595 Modified: branches/gcc-8-branch/libgo/go/os/wait_waitid.go
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #13 from ian at gcc dot gnu.org --- Author: ian Date: Mon Jul 2 16:29:24 2018 New Revision: 262315 URL: https://gcc.gnu.org/viewcvs?rev=262315&root=gcc&view=rev Log: PR go/86331 os: check return value as well as error from waitid https://gcc.gnu.org/PR86331 indicates that if a signal handler runs it is possible for syscall.Syscall6 to return a non-zero errno value even if no error occurs. That is a problem in general, but this fix will let us work around the general problem for the specific case of calling waitid. Reviewed-on: https://go-review.googlesource.com/121595 Modified: branches/gcc-7-branch/libgo/go/os/wait_waitid.go
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 Ian Lance Taylor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Ian Lance Taylor --- This should now be fixed. I filed the general issue of syscall.Syscall as https://golang.org/issue/26183.
[Bug c/86377] New: extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377
Bug ID: 86377
Summary: extern int errno; is treated as buggy function
declaration [-Werror=strict-prototypes]
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: um at mutluit dot com
Target Milestone: ---
Created attachment 44344
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44344&action=edit
The output file of -save-temps (ie. the "file.i" file)
test file extern_var_bug.c:
-
#include
extern int errno;
int main(int argc, char* argv[])
{
return errno;
}
Output:
---
extern_var_bug.c:2:16: error: function declaration isn't a prototype
[-Werror=strict-prototypes]
extern int errno;
^
extern_var_bug.c: In function 'main':
extern_var_bug.c:4:14: warning: unused parameter 'argc' [-Wunused-parameter]
int main(int argc, char* argv[])
^~~~
extern_var_bug.c:4:26: warning: unused parameter 'argv' [-Wunused-parameter]
int main(int argc, char* argv[])
~~^~
cc1: all warnings being treated as errors
Compiler and compile command:
-
# gcc-latest is v9 from svn trunk on x86_64
$ gcc-latest --version
gcc-latest (GCC) 9.0.0 20180701 (experimental) [trunk revision 262287]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
gcc-latest -c -DHAVE_CONFIG_H -fopt-info -Wall -Wextra -Werror -Wpedantic
-pedantic -g0 -DNDEBUG -Ofast \
-I. -I../../gcc_trunk/libiberty/../include -W -Wall -Wwrite-strings \
-Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic -D_GNU_SOURCE
-fpic \
\
-Wno-error=stringop-truncation -Wno-error=unused-parameter \
\
-x c \
-fno-strict-aliasing -fwrapv \
-save-temps \
\
extern_var_bug.c \
Remarks:
- The compile error happens only if was included, and only if
compiled as C.
- The same error originally happened in
../../gcc_trunk/libiberty/pex-common.c:28:1: error: function declaration isn't
a prototype [-Werror=strict-prototypes]
extern int errno;
^~
when building with nearly almost all warnings enabled and -g0 -DNDEBUG.
[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- errno is a macro and is allowed to be by the C (and C++) standard.
[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377 --- Comment #2 from Jonathan Wakely --- In fact is required to define it as a macro in C, and a footnote says: "The macro errno need not be the identifier of an object. It might expand to a modifiable lvalue resulting from a function call (for example, *errno())." Also since 'errno' is reserved as an identifier with external linkage, the declaration in your program has undefined behaviour even if you don't include
[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377 --- Comment #3 from U.Mutlu --- As said in the Remarks, the bug originally was triggered in this file in the trunk: ../gcc_trunk/libiberty/pex-common.c:28 #include #ifdef NEED_DECLARATION_ERRNO extern int errno; #endif
[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377 --- Comment #4 from Andrew Pinski --- NEED_DECLARATION_ERRNO should not be defined for most targets/hosts. You need to figure out why it is being defined here. Look at config.log to figure that out.
[Bug bootstrap/86376] recent breakage in ubsan build ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86376 --- Comment #2 from David Binderman --- (In reply to Martin Liška from comment #1) > I'll take a look. Thanks. This configure line seems to work ok: ../trunk/configure --prefix=/home/dcb/gcc/results.262304.ubsan \ --with-build-config=bootstrap-ubsan \ --disable-multilib \ --disable-werror \ --enable-checking=release \ --enable-languages=c,c++ So the problem seems to be either in the fortran area (possible, but unlikely) or the checking flags. I'll have a deeper look.
[Bug c++/86354] Address comparison not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86354 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- The static_assert can be just static_assert( (X*) &y != (X*) &z); It ultimately comes down to symtab_node::equal_address_to, but due to the extern y and z are interposable so it returns -1.
[Bug c++/86378] New: [7/8/9 regression] typedef breaks functional cast in noexcept-qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86378
Bug ID: 86378
Summary: [7/8/9 regression] typedef breaks functional cast in
noexcept-qualifier
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: jason at gcc dot gnu.org
Reporter: jason at gcc dot gnu.org
Target Milestone: ---
From https://bugzilla.redhat.com/show_bug.cgi?id=1597104
struct Pepper {};
struct Apple { Apple(int) {} };
struct Combination : Apple, Pepper
{
Combination(Pepper p, Apple a)
: Apple(a), Pepper(p)
{}
};
struct MyCombination
{
using Spice = Pepper;
using Fruit = Apple;
Combination combination;
template
constexpr MyCombination(T&& t)
noexcept(noexcept(Combination(Spice(), Fruit(t
: combination(Spice(), Fruit(t))
{}
};
MyCombination obj(Apple(4));
[Bug c++/86378] [7/8/9 regression] typedef breaks functional cast in noexcept-qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86378 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-07-02 Ever confirmed|0 |1
[Bug c++/86378] [7/8/9 regression] typedef breaks functional cast in noexcept-qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86378 Jason Merrill changed: What|Removed |Added Target Milestone|--- |7.4
[Bug c++/86378] [7/8/9 regression] typedef breaks functional cast in noexcept-qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86378 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Started with r257713.
[Bug fortran/45305] Array-valued calles to elementals are not simplified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45305 --- Comment #8 from Paul Thomas --- Author: pault Date: Mon Jul 2 19:28:11 2018 New Revision: 262316 URL: https://gcc.gnu.org/viewcvs?rev=262316&root=gcc&view=rev Log: 2018-07-02 Paul Thomas PR fortran/45305 * expr.c : Add a prototype for scalarize_intrinsic_call. (gfc_simplify_expr): Use scalarize_intrinsic_call for elemental intrinsic function calls. (scalarize_intrinsic_call): Add 'init_flag' argument. Check if the expression or any of the actual argument expressions are NULL. Before calling gfc_check_init_expr, check 'init_flag'. Only simplify the scalarized expressions if there are no errors on the stack. (gfc_check_init_expr): Set 'init_flag' true in the call to scalarize_intrinsic_call. 2018-07-02 Paul Thomas PR fortran/45305 * gfortran.dg/scalarize_parameter_array_2.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/proc_ptr_50.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/trans-array.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 --- Comment #2 from Jonathan Wakely --- It might be reasonable for GCC to silently ignore attributes that use an unrecognized attribute-namespace. If somebody uses [[clang::foobar]] or [[acme::rocketboots]] they probably aren't expecting GCC to handle it. This could mean silently ignoring typos like [[ngu::unused]] but it's arguably easier to spot a typo like "ngu" than to spot "warn_unsued_result" or "alwasy_inlne".
[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377
--- Comment #5 from U.Mutlu ---
The configure scripts in the subdirs/libs (like libiberty) do compile some test
codes to populate the config.h of the subdir.
And there the difference happens if -Wuninitialized is treated as error,
ie. if user sets -Werror=uninitialized either explicitly or implicitly thru
-Werror or a similar option:
Example for the libiberty subdir: once w/o -Werror and once with -Werror:
< conftest.c:53:7: warning: 't' is used uninitialized in this function
[-Wuninitialized]
---
> conftest.c:53:7: error: 't' is used uninitialized in this function
> [-Werror=uninitialized]
361c361
< conftest.c:75:13: warning: 'cs[0]' is used uninitialized in this function
[-Wuninitialized]
---
> conftest.c:75:13: error: 'cs[0]' is used uninitialized in this function
> [-Werror=uninitialized]
364,365c364,447
< configure:4686: $? = 0
< configure:4693: result: yes
...
> configure:4693: result: no
And in the 2nd case (>) from there on this causes many things in the config.h's
to be set differently, incl. the said NEED_DECLARATION_ERRNO ...
So, I think if the warnings in the stanza-codes could be eliminated then the
compilation would go further. It is the following code that generates the above
warnings: the variables t and cs should be initialized:
> | /* end confdefs.h. */
> |
> | int
> | main ()
> | {
> | /* FIXME: Include the comments suggested by Paul. */
> | #ifndef __cplusplus
> | /* Ultrix mips cc rejects this. */
> | typedef int charset[2];
> | const charset cs;
> | /* SunOS 4.1.1 cc rejects this. */
> | char const *const *pcpcc;
> | char **ppc;
> | /* NEC SVR4.0.2 mips cc rejects this. */
> | struct point {int x, y;};
> | static struct point const zero = {0,0};
> | /* AIX XL C 1.02.0.0 rejects this.
> | It does not let you subtract one const X* pointer from another in
> | an arm of an if-expression whose if-part is not a constant
> | expression */
> | const char *g = "string";
> | pcpcc = &g + (g ? g-g : 0);
> | /* HPUX 7.0 cc rejects these. */
> | ++pcpcc;
> | ppc = (char**) pcpcc;
> | pcpcc = (char const *const *) ppc;
> | { /* SCO 3.2v4 cc rejects this. */
> | char *t;
> | char const *s = 0 ? (char *) 0 : (char const *) 0;
> |
> | *t++ = 0;
> | if (s) return 0;
> | }
> | { /* Someone thinks the Sun supposedly-ANSI compiler will reject this. */
> | int x[] = {25, 17};
> | const int *foo = &x[0];
> | ++foo;
> | }
> | { /* Sun SC1.0 ANSI compiler rejects this -- but not the above. */
> | typedef const int *iptr;
> | iptr p = 0;
> | ++p;
> | }
> | { /* AIX XL C 1.02.0.0 rejects this saying
> |"k.c", line 2.27: 1506-025 (S) Operand must be a modifiable lvalue.
> */
> | struct s { int j; const int *ap[3]; };
> | struct s *b; b->j = 5;
> | }
> | { /* ULTRIX-32 V3.1 (Rev 9) vcc rejects this */
> | const int foo = 10;
> | if (!foo) return 0;
> | }
> | return !cs[0] && !zero.x;
> | #endif
> |
> | ;
> | return 0;
> | }
As this code is just for test-compilation by the configure script, then it
makes sense to fix the warnings.
I will try this for all occurrences of that code and similar ones, and if the
result is satisfactory, then post a patch to the mailing list for review.
[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377
--- Comment #6 from U.Mutlu ---
The configure scripts in the subdirs/libs (like libiberty) do compile some test
codes to populate the config.h of the subdir.
And there the difference happens if -Wuninitialized is treated as error,
ie. if user sets -Werror=uninitialized either explicitly or implicitly thru
-Werror or a similar option:
Example for the libiberty subdir: once w/o -Werror and once with -Werror:
< conftest.c:53:7: warning: 't' is used uninitialized in this function
[-Wuninitialized]
---
> conftest.c:53:7: error: 't' is used uninitialized in this function
> [-Werror=uninitialized]
361c361
< conftest.c:75:13: warning: 'cs[0]' is used uninitialized in this function
[-Wuninitialized]
---
> conftest.c:75:13: error: 'cs[0]' is used uninitialized in this function
> [-Werror=uninitialized]
364,365c364,447
< configure:4686: $? = 0
< configure:4693: result: yes
...
> configure:4693: result: no
And in the 2nd case (>) from there on this causes many things in the config.h's
to be set differently, incl. the said NEED_DECLARATION_ERRNO ...
So, I think if the warnings in the stanza-codes could be eliminated then the
compilation would go further. It is the following code that generates the above
warnings: the variables t and cs should be initialized:
> | /* end confdefs.h. */
> |
> | int
> | main ()
> | {
> | /* FIXME: Include the comments suggested by Paul. */
> | #ifndef __cplusplus
> | /* Ultrix mips cc rejects this. */
> | typedef int charset[2];
> | const charset cs;
> | /* SunOS 4.1.1 cc rejects this. */
> | char const *const *pcpcc;
> | char **ppc;
> | /* NEC SVR4.0.2 mips cc rejects this. */
> | struct point {int x, y;};
> | static struct point const zero = {0,0};
> | /* AIX XL C 1.02.0.0 rejects this.
> | It does not let you subtract one const X* pointer from another in
> | an arm of an if-expression whose if-part is not a constant
> | expression */
> | const char *g = "string";
> | pcpcc = &g + (g ? g-g : 0);
> | /* HPUX 7.0 cc rejects these. */
> | ++pcpcc;
> | ppc = (char**) pcpcc;
> | pcpcc = (char const *const *) ppc;
> | { /* SCO 3.2v4 cc rejects this. */
> | char *t;
> | char const *s = 0 ? (char *) 0 : (char const *) 0;
> |
> | *t++ = 0;
> | if (s) return 0;
> | }
> | { /* Someone thinks the Sun supposedly-ANSI compiler will reject this. */
> | int x[] = {25, 17};
> | const int *foo = &x[0];
> | ++foo;
> | }
> | { /* Sun SC1.0 ANSI compiler rejects this -- but not the above. */
> | typedef const int *iptr;
> | iptr p = 0;
> | ++p;
> | }
> | { /* AIX XL C 1.02.0.0 rejects this saying
> |"k.c", line 2.27: 1506-025 (S) Operand must be a modifiable lvalue.
> */
> | struct s { int j; const int *ap[3]; };
> | struct s *b; b->j = 5;
> | }
> | { /* ULTRIX-32 V3.1 (Rev 9) vcc rejects this */
> | const int foo = 10;
> | if (!foo) return 0;
> | }
> | return !cs[0] && !zero.x;
> | #endif
> |
> | ;
> | return 0;
> | }
As this code is just for test-compilation by the configure script, then it
makes sense to fix the warnings.
I will try this for all occurrences of that code and similar ones, and if the
result is satisfactory, then post a patch to the mailing list for review.
[Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716 --- Comment #6 from Eric Gallager --- (In reply to Eric Gallager from comment #5) > I think I remember someone suggesting a progress bar at one point; it > involved hacking the pass manager... > > (confirmed) Right, I found the thread (I think) I was thinking of: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00957.html
[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #7 from Eric Gallager --- Generally you're not supposed to use -Werror with configure scripts like that; configure scripts are supposed to set -Werror themselves only once it's safe to do so
[Bug target/85894] PPC64LE alloca stack slot allocation allows memset to destroy the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85894 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Bill Schmidt --- So, not a gcc bug. Closing.
[Bug target/86285] We don't mangle __ieee128 correctly using -mlong-double-64 -mabi=ieeelongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86285 --- Comment #5 from Segher Boessenkool --- Author: segher Date: Mon Jul 2 21:25:10 2018 New Revision: 262320 URL: https://gcc.gnu.org/viewcvs?rev=262320&root=gcc&view=rev Log: rs6000: Set up ieee128_float_type_node correctly (PR86285) We shouldn't init __ieee128 to be the same as long double if the latter is not even a 128-bit type. This also reorders the nearby __ibm128 code so both types use similar logic. Backport from trunk 2018-06-26 Segher Boessenkool PR target/86285 * config/rs6000/rs6000.c (rs6000_init_builtins): Do not set ieee128_float_type_node to long_double_type_node unless TARGET_LONG_DOUBLE_128 is set. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/rs6000/rs6000.c
[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377 --- Comment #8 from U.Mutlu --- If one activates -Werror then it won't build as it then treats the warnings as error. And there are many warnings currently suppressed. That means -Werror is deactivated by default, and IMO never activated by any of the configure scripts. It is possible to fix all the warnings and then use -Werror. That means then that if there were a warning, then it wouldn't build. But if the warnings are fixed, then it will build even with -Werror. I just have managed to fix all warnings in libiberty (a tedious work as one has to start a clean-build after each fix done; but is manageable). For C & C++ there are in total 7 such configure scripts (like libiberty) needing such fixes: ../gcc_trunk/libiberty/configure ../gcc_trunk/fixincludes/configure ../gcc_trunk/libcpp/configure ../gcc_trunk/libdecnumber/configure ../gcc_trunk/mpfr-3.1.4/configure ../gcc_trunk/mpc-1.0.3/configure ../gcc_trunk/intl/configure If one can use the following, then the fixes can be done easily: #pragma GCC diagnostic push #pragma GCC diagnostic warning "-Wunused-value" ... #pragma GCC diagnostic pop But I'm not sure if that can be used if the building compiler is not gcc... So, currently just playing with it to broaden by experience...
[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377 --- Comment #9 from Jonathan Wakely --- (In reply to U.Mutlu from comment #8) > It is possible to fix all the warnings and then use -Werror. But only today. Tomorrow's compilers will have different warnings. And yesterday's compilers too. I think what you're trying to do is not something anybody really cares about supporting.
[Bug c++/86379] New: Class member access of |using|'d field goes horribly awry in presence of templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86379 Bug ID: 86379 Summary: Class member access of |using|'d field goes horribly awry in presence of templates Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jwalden+ggo at mit dot edu Target Milestone: --- Created attachment 44345 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44345&action=edit Mostly-reduced testcase SpiderMonkey is hitting compile errors with gcc 8/8.1/trunk (per godbolt) when, inside a member function in a template class, accessing member functions on a field inherited from a base class. The error messages indicate that the member isn't being found in a type that is *entirely different* from the type of the member being 'using'd, so it looks like a member lookup is happening on an entirely wrongly-computed type -- no other plausible explanation. This is a regression in gcc 8; godbolt says 7.3 compiles it just fine. clang also has no problems with it. I've attached a standalone testcase just over 200 lines long; compiler output is tacked on the end of the file in a comment. I could reduce further, but 1) I'm guessing it's obvious which thing is miscomputed where, and 2) I'm unsure exactly which interlocking parts of this, if removed, won't by pure happenstance jar it back into alignment. This is probably a duplicate, but I don't know the search terms to find the original. :-( I can work around these issues by not |using| the various fields and instead |this->|-qualifying them, but this gets pretty wordy. If there's a better workaround, I'd love to know it!
[Bug c++/86379] [8/9 Regression] Class member access of |using|'d field goes horribly awry in presence of templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86379 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||7.3.0 Keywords||rejects-valid Last reconfirmed||2018-07-02 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 Summary|Class member access of |[8/9 Regression] Class ||using|'d field goes|member access of |using|'d |horribly awry in presence |field goes horribly awry in |of templates|presence of templates Known to fail||8.1.0, 9.0 --- Comment #1 from Jonathan Wakely --- Started to be rejected with r251438: PR c++/81236 - ICE with template-id in generic lambda
[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #20 from Eric Gallager --- (In reply to Eric Gallager from comment #19) > (In reply to Manuel López-Ibáñez from comment #11) > > (In reply to comment #10) > > > However, with so many lines of legacy code out there using bit-filed that > > > have > > > been proven to work, it doesn't make sense to revisit/modify them. Would > > > it > > > be possible for gcc to provide a -Wbitfield-conversion flag in new > > > releases > > > and make 39170 an enhancement (preferably high priority)? > > > > Seriously, I am not the "maintainer" of GCC diagnostics > > That's David Malcolm; adding him on cc ...and since he's now made himself the assignee, changing status to ASSIGNED
[Bug c++/86190] [6/7/8/9 Regression] -Wsign-conversion ignores explicit conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86190 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug middle-end/77357] strlen of constant strings not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77357 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- Working on a patch.
[Bug rtl-optimization/84842] [7/8/9 Regression] ICE in verify_target_availability, at sel-sched.c:1569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842
--- Comment #15 from Arseny Solokha ---
(In reply to Alexander Monakov from comment #14)
> Arseny, in the meantime if by chance you have another x86_64 variant of this
> failure that doesn't require -funroll-all-loops, please post it as well.
Finally.
float
z6 (float gg, int rv)
{
long int v9;
while (-v9 / (!rv + 10) < (long unsigned int) ((gg + 1) / gg))
gg = (int) ((long unsigned int) (rv * 1.1f));
return gg;
}
% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20180701 -O2 -ffast-math -fschedule-insns
-fsel-sched-pipelining -fselective-scheduling -fsplit-paths -fno-tree-loop-im
-c scfabdxr.c
(as of 262290).
[Bug target/15896] Strange behaviour for inline assembler input constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15896
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org,
||pinskia at gcc dot gnu.org
--- Comment #2 from Eric Gallager ---
(In reply to Andrew Pinski from comment #1)
> I don't know Ada that well (in terms of promotions and types) but the
> following C code produces the
> same ICE so I might assume the issue is that My_Type+constant is being
> promoted to unsigned long
> long or something along that line:
> int f()
> {
> unsigned long long cu32 = 1;
> asm("%0"::"a"(cu32));
> }
Does this still happen with newer versions of GCC? I can't reproduce with gcc
7, but I'm assuming that's due to target differences; I get different messages
depending on 32-bit or 64-bit, but neither of them are an ICE:
$ gcc -c -m32 15896.c
15896.c: In function 'f':
15896.c:4:3: error: inconsistent operand constraints in an 'asm'
asm("%0"::"a"(cu32));
^~~
$ gcc -c -m64 15896.c
15896.c:4:Junk character 37 (%).
15896.c:4:Rest of line ignored. 1st junk character valued 114 (r).
$
[Bug target/57054] Compilation with -O3 passes, with -O2 fails (ARM/NEON)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57054 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||pinskia at gcc dot gnu.org, ||rearnsha at gcc dot gnu.org Severity|normal |minor --- Comment #5 from Eric Gallager --- Changing severity to "minor" per https://gcc.gnu.org/bugs/management.html
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #13 from Eric Gallager ---
(In reply to Oleg Endo from comment #12)
> (In reply to Oleg Endo from comment #11)
> >
> > seems to fix the test case of PR 34807. However, I've not tested it any
> > further and probably the fix is incomplete and works only for mem loads and
> > not stores.
> > In fact it can be broken again quite easily by inserting another insn that
> > requires R0 (tst #imm,r0 in this case):
> >
> > int glob, glob1;
> >
> > static int _dl_mmap (int xx)
> > {
> >register int __sc0 __asm__ ("r0") = glob1;
> >register int __sc1 __asm__ ("r1") = glob;
> >
> >if (xx & 3)
> > __asm__ ("trapa %1 " : "=z" (__sc0) : "i" (0x10), "0" (__sc0), "r"
> > (__sc1));
> >
> >return (__sc0);
> > }
> >
> > void _start(int xx)
> > {
> >static int buf;
> >buf = _dl_mmap(xx);
> > }
>
> I've tried that test case with the sh-lra branch and the problems seem to be
> gone.
So is this FIXED yet then?
[Bug target/50928] m32c ICE building RTEMS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #16 from Eric Gallager --- (In reply to DJ Delorie from comment #15) > The binutils team has been working a lot on patching vulnerabilities in the > binutils tools. The m32c, however, has a 3-byte reloc that might occur at > the end of a section, and was implemented as three bytes of a four-byte > "word", which would then be outside the bounds of the section. Recent > patches check for such bounds crossings, hence the breakage. I've checked > in a patch to binutils head to manually process the R_M32C_24 relocations so > that the range checking is more appropriate to the three-byte relocation. Which version of binutils was the patch released in?
[Bug target/63683] m32c-rtems ICE unable to find spill register compiling libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63683 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Eric Gallager --- (In reply to Bernd Edlinger from comment #2) > Hi, > > this looks like a duplicate of pr50928 OK, closing as such *** This bug has been marked as a duplicate of bug 50928 ***
[Bug target/50928] m32c ICE building RTEMS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928 --- Comment #17 from Eric Gallager --- *** Bug 63683 has been marked as a duplicate of this bug. ***
[Bug c/86380] New: Incorrect inequality in function chose_multiplier in file expmed.c in GCC.8.1.0 and earlier versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86380
Bug ID: 86380
Summary: Incorrect inequality in function chose_multiplier in
file expmed.c in GCC.8.1.0 and earlier versions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: colinwb at yahoo dot co.uk
Target Milestone: ---
In this line near the end of function choose_multiplier in file expmed.c
return mhigh.to_uhwi () >= mask;
the ">=" should really be ">".
As it is when precision = n < HOST_BITS_PER_WIDE_INT and d = 2**(n-1) + 1,
so post_shift = 2*n - 1 - n = n - 1 and mhigh = 2**n - 1,
choose_multiplier wrongly returns that the upper bit should be set.
unsigned HOST_WIDE_INT
choose_multiplier (unsigned HOST_WIDE_INT d, int n, int precision,
unsigned HOST_WIDE_INT *multiplier_ptr,
int *post_shift_ptr, int *lgup_ptr)
...
*post_shift_ptr = post_shift;
*lgup_ptr = lgup;
if (n < HOST_BITS_PER_WIDE_INT)
{
unsigned HOST_WIDE_INT mask = (HOST_WIDE_INT_1U << n) - 1;
*multiplier_ptr = mhigh.to_uhwi () & mask;
return mhigh.to_uhwi () >= mask;
}
else
{
*multiplier_ptr = mhigh.to_uhwi ();
return wi::extract_uhwi (mhigh, HOST_BITS_PER_WIDE_INT, 1);
}
}
[Bug bootstrap/86376] recent breakage in ubsan build ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86376 --- Comment #3 from David Binderman --- This configure line seems to work: ../trunk/configure --prefix=/home/dcb/gcc/results.262304.ubsan \ --with-build-config=bootstrap-ubsan \ --disable-multilib \ --disable-werror \ --enable-checking=df,extra,fold \ --enable-languages=fortran So it's looking like the rtl or yes flags are the problem.
[Bug fortran/54613] [F08] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #11 from janus at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #4) > Still to do: FINDLOC and BACK. It seems that BACK is done by now, while FINDLOC is still to do.
