[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822 --- Comment #4 from rguenther at suse dot de --- On Thu, 17 May 2018, tetra2005 at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822 > > --- Comment #3 from Yuri Gribov --- > It seems these lines in is_masked_range_test should be removed: > if (wi::neg_p (val, TYPE_SIGN (type))) > std::swap (*low, *high); > Sadly there were no tests which tested negative constants. I'll bootstrap and > send patch tomorrow (hope there's no urgency?). Well, iff then you should replace the above with if (wi::neg_p (val, TYPE_SIGN (type))) return false; (possibly earlier as soon as val is computed). At least w/o more exhaustive test coverage or explanation.
[Bug fortran/68950] [fortran] gfc_format_decoder cannot handle %qE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68950 --- Comment #11 from Tom de Vries --- (In reply to kargl from comment #10) > If you're looking for a Fortran maintainer's approval, then > one may want to submit the patch to fort...@gcc.gnu.org. Both the original submission and the ping where to both gcc-patches@ and fortran@.
[Bug fortran/68950] [fortran] gfc_format_decoder cannot handle %qE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68950 --- Comment #12 from Tom de Vries --- (In reply to Eric Gallager from comment #9) > (In reply to Tom de Vries from comment #8) > > (In reply to vries from comment #6) > > > posted RFC: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01749.html > > > > pinged: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00831.html > > Please keep pinging! ping^2: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00876.html
[Bug tree-optimization/85826] New: [9 Regression] ICE in builtin_memref in gcc/gimple-ssa-warn-restrict.c:281 starting with r260280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85826 Bug ID: 85826 Summary: [9 Regression] ICE in builtin_memref in gcc/gimple-ssa-warn-restrict.c:281 starting with r260280 Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- Following ICEs: $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr66817.c -Warray-bounds -O3 during GIMPLE pass: wrestrict /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr66817.c: In function ‘retframe_block’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr66817.c:16:3: internal compiler error: tree check: expected integer_cst, have var_decl in get_len, at tree.h:5571 retframe_block () ^~ 0x5d5f98 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/tree.c:9337 0x95e3fb tree_check(tree_node const*, char const*, int, char const*, tree_code) ../../gcc/tree.h:3391 0x95e3fb wi::extended_tree<128>::get_len() const ../../gcc/tree.h:5571 0x95e3fb wi::int_traits > >::decompose(long*, unsigned int, generic_wide_int > const&) ../../gcc/wide-int.h:934 0x95e3fb wide_int_ref_storage::wide_int_ref_storage > >(generic_wide_int > const&, unsigned int) ../../gcc/wide-int.h:983 0x95e3fb generic_wide_int >::generic_wide_int > >(generic_wide_int > const&, unsigned int) ../../gcc/wide-int.h:758 0x95e3fb fixed_wide_int_storage<128>::fixed_wide_int_storage > >(generic_wide_int > const&) ../../gcc/wide-int.h:1211 0x95e3fb generic_wide_int >& generic_wide_int >::operator= > >(generic_wide_int > const&) ../../gcc/wide-int.h:886 0x95e3fb builtin_memref ../../gcc/gimple-ssa-warn-restrict.c:281 0x95fac2 check_bounds_or_overlap(gcall*, tree_node*, tree_node*, tree_node*, tree_node*, bool) ../../gcc/gimple-ssa-warn-restrict.c:1855 0x96270b check_call ../../gcc/gimple-ssa-warn-restrict.c:1826 0x96270b before_dom_children ../../gcc/gimple-ssa-warn-restrict.c:106 0x146bd9f dom_walker::walk(basic_block_def*) ../../gcc/domwalk.c:353 0x957071 execute ../../gcc/gimple-ssa-warn-restrict.c:120
[Bug tree-optimization/85826] [9 Regression] ICE in builtin_memref in gcc/gimple-ssa-warn-restrict.c:281 starting with r260280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85826 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-18 Known to work||8.1.0 Version|unknown |9.0 Ever confirmed|0 |1 Known to fail||9.0
[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- Created attachment 44145 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44145&action=edit patch I am testing I am testing the attached. Please check how negative values can be handled correctly or why exactly the handling was wrong.
[Bug middle-end/85817] [9 Regression] ICE in expand_call at gcc/calls.c:4291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85817 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Priority|P3 |P1 Component|tree-optimization |middle-end Version|unknown |9.0 Target Milestone|--- |9.0
[Bug target/85819] conversion from __v[48]su to __v[48]sf should use FMA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85819 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-18 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug tree-optimization/85826] [9 Regression] ICE in builtin_memref in gcc/gimple-ssa-warn-restrict.c:281 starting with r260280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85826 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |9.0
[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822 --- Comment #6 from Yuri Gribov --- (In reply to Richard Biener from comment #5) > Created attachment 44145 [details] > patch I am testing > > I am testing the attached. Please check how negative values can be handled > correctly or why exactly the handling was wrong. I think just removing the hunk I mentioned should fix it (I'll test and post to gcc-patches today hopefully).
[Bug tree-optimization/63185] Improve DSE with branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185 --- Comment #10 from Richard Biener --- Created attachment 44146 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44146&action=edit testresults Related I checked Index: gcc/passes.def === --- gcc/passes.def (revision 260317) +++ gcc/passes.def (working copy) @@ -209,8 +209,6 @@ along with GCC; see the file COPYING3. NEXT_PASS (pass_return_slot); NEXT_PASS (pass_fre); NEXT_PASS (pass_merge_phi); - NEXT_PASS (pass_thread_jumps); - NEXT_PASS (pass_vrp, true /* warn_array_bounds_p */); NEXT_PASS (pass_chkp_opt); NEXT_PASS (pass_dce); NEXT_PASS (pass_stdarg); @@ -224,6 +222,7 @@ along with GCC; see the file COPYING3. NEXT_PASS (pass_ch); NEXT_PASS (pass_lower_complex); NEXT_PASS (pass_sra); + NEXT_PASS (pass_vrp, true /* warn_array_bounds_p */); /* The dom pass will also resolve all __builtin_constant_p calls that are still there to 0. This has to be done after some propagations have already run, but before some more dead code which as quite some regressions (attached). Ignore any auto-fdo fails. Will check w/o the removal of pass_thread_jumps.
[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822 --- Comment #7 from rguenther at suse dot de --- On Fri, 18 May 2018, tetra2005 at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822 > > --- Comment #6 from Yuri Gribov --- > (In reply to Richard Biener from comment #5) > > Created attachment 44145 [details] > > patch I am testing > > > > I am testing the attached. Please check how negative values can be handled > > correctly or why exactly the handling was wrong. > > I think just removing the hunk I mentioned should fix it (I'll test and post > to > gcc-patches today hopefully). Ok, please make sure to say why not doing anything special for negative numbers is ok.
[Bug c++/79092] template: type ignored if value already instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79092 Jonathan Wakely changed: What|Removed |Added CC||christosstratopoulos1@gmail ||.com --- Comment #7 from Jonathan Wakely --- *** Bug 85825 has been marked as a duplicate of this bug. ***
[Bug c++/85825] Incorrect selection of method in template class specialization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85825 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- This was fixed on trunk by r254843 which makes it a dup of PR 79092. C++17 bugs are unlikely to get backported to gcc-7-branch, use gcc-8 for better C++17 support. *** This bug has been marked as a duplicate of bug 79092 ***
[Bug tree-optimization/63185] Improve DSE with branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #11 from Richard Biener ---
(In reply to Marc Glisse from comment #5)
> Another example:
>
> #include
> void f(){
> const int n=1<<14;
> double a[n];
> double b[n];
> double c[n];
> __builtin_memset(a,0,n);
> __builtin_memset(b,0,n);
> __builtin_memset(c,0,n);
> for(int i=0;i c[i]=a[i]+b[i];
> time(0);
> }
I guess you meant (notice the bogus memset size above):
#include
void f(){
const int n=1<<14;
double a[n];
double b[n];
double c[n];
__builtin_memset(a,0,n*sizeof(double));
__builtin_memset(b,0,n*sizeof(double));
__builtin_memset(c,0,n*sizeof(double));
for(int i=0;i If I make n a constant (using #define), DCE knows that c is not
> ref_may_be_aliased (that test could probably be weakened) and removes almost
> everything. We don't replace alloca_with_align with an array because the
> size is larger than 256 (with a more limited scope the limit would even be
> 25...). DSE is likely confused by the loop. And PRE and others don't know
> that a[i] is always 0. (llvm removes everything but the final call)
[Bug fortran/66694] Failure in function returning an allocated CHARACTER array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66694 --- Comment #3 from Dominique d'Humieres --- > On darwin the executable hangs due to pr30617. Commenting the line 118 allows the executable to run and to give a sensible output.
[Bug tree-optimization/63185] Improve DSE with branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185 --- Comment #12 from Marc Glisse --- (In reply to Richard Biener from comment #11) > I guess you meant (notice the bogus memset size above): True. And while it shouldn't make a difference in checking if the stores to c are dead, it could (but doesn't, symbolic bounds are not so easy to handle) make a difference for the reads since we could notice that the reads from a and b are necessarily 0 (thus we write 0 to c[i], thus this loop is a memset, etc).
[Bug fortran/85537] [7/8/9 Regression] Invalid memory reference at runtime when calling subroutine through procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #4 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) > The test works for me with 4.8.5. The change occurred between revisions > r2370089 (2016-06-04, OK) and r237310 + one patch (2016-06-10, wrong code). I see runtime segfaults with every gfortran version that I tried, starting from 4.6. 4.4 does not compile the example due to the proc-ptr init.
[Bug fortran/85537] [7/8/9 Regression] Invalid memory reference at runtime when calling subroutine through procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537 --- Comment #5 from janus at gcc dot gnu.org --- However I don't see any failures with this variant: program main call foo() contains subroutine foo() integer :: a abstract interface subroutine ibar() end subroutine end interface procedure(ibar), pointer :: bar_ptr => bar_impl a = 0 call bar_impl() call bar_ptr() end subroutine subroutine bar_impl() write (*,*) "foo" a = a + 1 end subroutine end program
[Bug tree-optimization/85803] [6/7/8/9 Regression] DSE removes live global store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85803
--- Comment #3 from rguenther at suse dot de ---
On Thu, 17 May 2018, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85803
>
> Eric Botcazou changed:
>
>What|Removed |Added
>
> Status|UNCONFIRMED |NEW
>Last reconfirmed||2018-05-17
> Ever confirmed|0 |1
>
> --- Comment #2 from Eric Botcazou ---
> (> I think the only in-tree language eventually specifying behavior for stuff
> > like above is Ada - so, any comments / attempts for testcases where we do
> > not follow language specified behavior?
>
> I don't think that the language fully does it, it's quite borderline.
>
> But something changed in DSE yesterday, the following procedure compiled with
> -gnatp -O used to print "SEGV Handler" and now it runs quietly.
>
> with Ada.Text_IO;
>
> procedure p is
>
>procedure leaf is
> type Int_Ptr is access all Integer;
> function n return Int_Ptr is
> begin return null; end;
>
> Data : Int_Ptr := n;
>begin
> Data.all := 0;
>end;
>
> begin
>leaf;
> exception
>when others =>
> Ada.Text_IO.Put_Line ("SEGV Handler");
> end;
I think that's because we now annotate p.leaf.n with malloc() and
then DSE will remove the store as dead as the result of p.leaf.n
doesn't escape. Note this will change again once Pratamesh commits
a followup change (that malloc annotation isn't really useful).
[Bug gcov-profile/45582] gcda file names collision when profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45582 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Martin Liška --- This should help for the scenario: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00729.html
[Bug c++/38087] g++ accepts invalid destructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38087 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=12333 Summary|Pseudo destructor call |g++ accepts invalid ||destructor call --- Comment #5 from Eric Gallager --- (In reply to Eric Gallager from comment #4) > Redoing lost comments: > > https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01624.html > > Eric Gallager changed: > >What|Removed |Added > > Status|UNCONFIRMED |WAITING >Last reconfirmed||2017-08-14 > CC||egallager at gcc dot gnu.org > Ever confirmed|0 |1 > > --- Comment #4 from Eric Gallager --- > (In reply to Andrew Pinski from comment #1) > > I still think this is valid code ... There are defect reports against this > > area too. > > Which ones do you mean? > > https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01637.html > > Jonathan Wakely changed: > >What|Removed |Added > >Keywords||accepts-invalid > Status|WAITING |NEW > > --- Comment #5 from Jonathan Wakely --- > There's https://wg21.link/cwg555 but I don't think it changes anything here. > > [expr.pseudo] definitely doesn't apply, as that only applies to non-class > types. (The bug title is wrong for the same reason, this is a destructor > call, not a pseudo destructor call.) > > The current wording in [basic.lookup.classref] says "At least one of the > lookups shall find a name that refers to cv T." The object expression has > type C, but the lookup result for B does not find that type, so the code is > invalid. Retitling then.
[Bug c++/85827] New: false positive for -Wunused-but-set-variable because of constexpr-if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85827
Bug ID: 85827
Summary: false positive for -Wunused-but-set-variable because
of constexpr-if
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Testcase `-std=c++17 -Wall` (cf. https://godbolt.org/g/kfgN2V):
template int f()
{
constexpr bool _1 = N == 1;
constexpr bool _2 = N == 2;
constexpr bool _3 = N == 3;
if constexpr (_1) {
return 5;
} else if constexpr (_2) {
return 1;
} else if constexpr (_3) {
return 7;
}
}
int a() {
return f<1>();
}
int b() {
return f<2>();
}
int c() {
return f<3>();
}
Yes, I see how one can argue that _2 and _3 are unused in f<1>. However, this
makes use of constexpr-if cumbersome. E.g. when a variable is required in all
but one branch, then it'll warn for specializations that take this one branch.
So you'll have to reorder the code such that the variable is only defined
inside the else branch where all the other branches are handled. But what if
you have two variables and their uses are disjunct? This leads to code
duplication, just for silencing the warning.
I believe, -Wunused-but-set-variable needs to consider all constexpr branches
to be useful here.
[Bug c++/85827] false positive for -Wunused-but-set-variable because of constexpr-if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85827 --- Comment #1 from Matthias Kretz --- Same issue for -Wunused-variable
[Bug libstdc++/85824] regex constructor crashes under UTF-8 locale on Solaris SPARC when parsing a simple character class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85824
Jonathan Wakely changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #4 from Jonathan Wakely ---
(In reply to Wanying Luo from comment #0)
> When _M_transform() calls strxfrm() and gets -1 when converting 0x80 under
> the UTF-8 locale on Solaris SPARC, it simply assigns -1 to __res of type
> size_t which creates a very large number. This causes __ret.append(__c,
> __res) to crash. I think it would be nice if the code checks errno and
> issues a better error message than the one above.
N.B. it doesn't just crash, it throws an exception because it can't append
4294967295 bytes to a std::string. Any fix to check errno in
collate::do_transform is still going to involve throwing an exception,
just a slightly different one.
The real problem is that std::regex wants to build a cache of every value from
CHAR_MIN to CHAR_MAX, to decide if it matches the bracket expression "[0-9]".
If calling strxfrm on any 8-bit char value produces an error then we're going
to get an exception. I think something in the regex compiler (maybe in
transform_primary) needs to handle those exceptions (and either decide the
characters that produce errors do not match, or maybe disable the cache?)
Tim, I'll take care of checking errno in collate<>::_M_transform but could you
advise what to do about the regex compiler? Maybe:
--- a/libstdc++-v3/include/bits/regex.h
+++ b/libstdc++-v3/include/bits/regex.h
@@ -257,7 +257,11 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
const __ctype_type& __fctyp(use_facet<__ctype_type>(_M_locale));
std::vector __s(__first, __last);
__fctyp.tolower(__s.data(), __s.data() + __s.size());
- return this->transform(__s.data(), __s.data() + __s.size());
+ __try {
+ return this->transform(__s.data(), __s.data() + __s.size());
+ } catch(const std::runtime_error&) {
+ return string_type();
+ }
}
/**
[Bug c++/38087] g++ accepts invalid destructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38087
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2017-08-17 00:00:00 |2018-5-18
--- Comment #6 from Jonathan Wakely ---
Clang gives this error:
d.cc:4:11: error: destructor type 'B' in object destruction expression does not
match the type 'C' of the object being destroyed
this->~B();
^
d.cc:1:7: note: type 'B' is declared here
class B { };
^
1 error generated.
And EDG gives this error:
"d.cc", line 4: error: invalid destructor name for type "C"
this->~B();
^
1 error detected in the compilation of "d.cc".
[Bug c++/85827] false positive for -Wunused-but-set-variable because of constexpr-if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85827 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-18 Ever confirmed|0 |1
[Bug c++/85827] false positive for -Wunused-but-set-variable because of constexpr-if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85827 --- Comment #2 from Marc Glisse --- I think that's going to be hard. The same issue always existed with macros. The whole point of "if constexpr" is not to look at the other branches, as they may not even compile. Sure, some minimal "safe" attempt at looking at those branches would be possible, but I am not sure it is worth the trouble.
[Bug middle-end/85817] [9 Regression] ICE in expand_call at gcc/calls.c:4291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85817 --- Comment #4 from prathamesh3492 at gcc dot gnu.org --- Author: prathamesh3492 Date: Fri May 18 12:31:04 2018 New Revision: 260358 URL: https://gcc.gnu.org/viewcvs?rev=260358&root=gcc&view=rev Log: 2018-05-18 Prathamesh Kulkarni PR middle-end/85817 * ipa-pure-const.c (malloc_candidate_p): Remove the check integer_zerop for retval and return false if all args to phi are zero. testsuite/ * gcc.dg/tree-ssa/pr83648.c: Change scan-tree-dump to scan-tree-dump-not for h. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-pure-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr83648.c
[Bug libstdc++/85828] New: std::shuffle tries to swap element with itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85828 Bug ID: 85828 Summary: std::shuffle tries to swap element with itself Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: soap at gentoo dot org Target Milestone: --- This bug is related to a previous one in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603. For a full description, see https://stackoverflow.com/questions/22915325/avoiding-self-assignment-in-stdshuffle. The problem boils down to the fact that in std::shuffle, self-assignment in some std::swap(x, x) will happen eventually. This will cause an "Error: attempt to self move assign." failure to occur and kill the program when compiled in debug mode. A chat on IRC with Jonathan Wakely confirmed that this is an implementation bug, and that the likely correct fix for this is to avoid self-swap in std::shuffle.
[Bug gcov-profile/84846] GCOV intermediate format improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84846 --- Comment #2 from Martin Liška --- Author: marxin Date: Fri May 18 12:46:32 2018 New Revision: 260359 URL: https://gcc.gnu.org/viewcvs?rev=260359&root=gcc&view=rev Log: Print working directory to gcov files (PR gcov-profile/84846). 2018-05-18 Martin Liska PR gcov-profile/84846 * coverage.c (coverage_init): Write PWD to .gcno file. * doc/gcov.texi: Document how working directory is printed. * gcov-dump.c (dump_gcov_file): Print PWD. * gcov.c (output_intermediate_file): Likewise. (read_graph_file): Read PWD string. (output_lines): Print PWD. Modified: trunk/gcc/ChangeLog trunk/gcc/coverage.c trunk/gcc/doc/gcov.texi trunk/gcc/gcov-dump.c trunk/gcc/gcov.c
[Bug c++/85827] false positive for -Wunused-but-set-variable because of constexpr-if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85827
--- Comment #3 from Matthias Kretz ---
But macros are different. They remove the code before the C++ parser sees it
(at least as-if). One great improvement of constexpr-if over macros is that all
the other branches are parsed and their syntax checked. E.g. it requires the
mentioned names to exist. This doesn't compile (cf.
https://godbolt.org/g/iCRPDv):
#ifdef HAVE_FOO
constexpr bool have_foo = true;
void foo();
#else
constexpr bool have_foo = false;
#endif
void f() {
if constexpr (have_foo) {
foo();
}
}
So, the frontend parses all branches anyway. It should be able to see that _2
and _3 are referenced in f<1>().
[Bug libstdc++/85828] std::shuffle tries to swap element with itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85828
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2018-05-18
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
#include
#include
#include
struct Type {
std::vector ints;
};
int main() {
std::vector intVectors = {{{1}}, {{1, 2}}};
std::shuffle(intVectors.begin(), intVectors.end(), std::mt19937());
}
$ g++ self.cc -D_GLIBCXX_DEBUG
$ ./a.out
/usr/include/c++/7/debug/safe_container.h:83:
Error: attempt to self move assign.
Objects involved in the operation:
sequence "this" @ 0x0x12e7ee8 {
type = __gnu_debug::_Safe_container >, std::allocator, __gnu_debug::_Safe_sequence, true>;
}
Aborted (core dumped)
[Bug gcov-profile/84846] GCOV intermediate format improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84846 --- Comment #3 from Martin Liška --- Author: marxin Date: Fri May 18 13:06:31 2018 New Revision: 260361 URL: https://gcc.gnu.org/viewcvs?rev=260361&root=gcc&view=rev Log: gcov: add new option -t that prints output to stdout (PR gcov-profile/84846). 2018-05-18 Martin Liska PR gcov-profile/84846 * gcov.c (print_usage): Add new -t option. (process_args): Handle the option. (generate_results): Use stdout as output when requested by the option. 2018-05-18 Martin Liska PR gcov-profile/84846 * doc/gcov.texi: Document -t option of gcov tool. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/gcov.texi trunk/gcc/gcov.c
[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Martin Liška ---
[...]
> So can you please debug why we go into following branch:
> 1277if (!create_wrapper
> 1278&& !alias->call_for_symbol_and_aliases
> (cgraph_node::has_thunk_p,
> 1279NULL, true)
> 1280&& !alias->can_remove_if_no_direct_calls_p ())
> 1281 {
> 1282if (dump_file)
> 1283 fprintf (dump_file, "Not unifying; can not make wrapper
> and
> "
> 1284 "function has other uses than direct calls\n\n");
> 1285return false;
> 1286 }
>
> I'm curious why can_remove_if_no_direct_calls_p returns false.
It took me a bit figuring out which of the two lto1 invocations was the
interesting one, then rebuilding with -g3 -O0 to be able to see anything
useful in gdb.
Here's what I found:
ipa-icf.c:1280 (sem_function::merge)
&& !alias->can_remove_if_no_direct_calls_p ())
cgraph.c:2848 (cgraph_node::can_remove_if_no_direct_calls_p)
return !call_for_symbol_and_aliases (nonremovable_p, NULL, true);
cgraph.h:3213 (cgraph_node::call_for_symbol_and_aliases)
if (callback (this, data))
return true;
cgraph.c:2829 (nonremovable_p)
return !node->can_remove_if_no_direct_calls_and_refs_p ();
cgraph.h:2924 (cgraph_node::can_remove_if_no_direct_calls_and_refs_p)
/* Only COMDAT functions can be removed if externally visible. */
if (externally_visible
&& (!DECL_COMDAT (decl)
|| forced_by_abi
|| used_from_object_file_p ()))
return false;
externally_visible = 1 and If I'm not mistaken, decl is not comdat, thus
return false:
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
faefb3c0 precision:32 min max
pointer_to_this >
QI
size
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
arg-types >
pointer_to_this >
readonly addressable nothrow public static function-specific-target
function-specific-opt uninlinable QI
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/ipa/ipa-icf-38a.c:6:5 align:8
warn_if_not_align:0 context
attributes > initial
result
ignored SI
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/ipa/ipa-icf-38a.c:6:5 size
unit-size
align:32 warn_if_not_align:0 context >
struct-function fa52b1a0>
[Bug gcov-profile/84846] GCOV intermediate format improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84846 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Implemented on trunk.
[Bug target/85829] New: [8/9 Regression] PARTIAL_REG_DEPENDENCY and MOVX were disabled for Haswell and newer processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85829 Bug ID: 85829 Summary: [8/9 Regression] PARTIAL_REG_DEPENDENCY and MOVX were disabled for Haswell and newer processors Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: hubicka at ucw dot cz Target Milestone: --- Target: x86_64-*-*, i?86-*-* r254152 disabled PARTIAL_REG_DEPENDENCY and MOVX were disabled for Haswell and newer processors. r258972 restored them for skylake-avx512. We may need them back for all Haswell and newer processors.
[Bug fortran/85599] Prevent short-circuiting of logical expressions for non-pure functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599 --- Comment #31 from Steve Kargl --- On Thu, May 17, 2018 at 05:37:51AM +, janus at gcc dot gnu.org wrote: > > > The order of the evaluation of ping() and pong() is > > not specified by the Fortran standard. > > This PR is not about reordering, but about short-circuiting. > AFAICT this PR is about a function with side-effects, and re-ordering can have an potentially undesirable result.
[Bug fortran/80931] ICE on move_alloc in gimplify_expr, at gimplify.c:11335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80931 snowfed changed: What|Removed |Added CC||snowfed at mail dot ru --- Comment #3 from snowfed --- Just stumbled upon this bug as well. Here is my minimal example (slightly smaller than Tiziano's). module buggy implicit none type type_t character(:), dimension(:), allocatable :: characters contains procedure :: mover end type type_t contains subroutine mover (self) implicit none class(type_t), intent(in out) :: self character(:), dimension(:), allocatable :: new allocate(character(5) :: new(2018)) call move_alloc(new, self%characters) end subroutine mover end module buggy
[Bug middle-end/82089] emit_cstore sign-extends BImode result for STORE_FLAG_VALUE == 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82089 Andrew Stubbs changed: What|Removed |Added CC||ams at gcc dot gnu.org --- Comment #5 from Andrew Stubbs --- Any reason not to get this committed?
[Bug libstdc++/85828] std::shuffle tries to swap element with itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85828
--- Comment #2 from Jonathan Wakely ---
This is ugly but it works:
--- a/libstdc++-v3/include/bits/stl_algo.h
+++ b/libstdc++-v3/include/bits/stl_algo.h
@@ -3827,7 +3827,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
if ((__urange % 2) == 0)
{
__distr_type __d{0, 1};
- std::iter_swap(__i++, __first + __d(__g));
+ if (__d(__g) == 0)
+ std::iter_swap(__i, __first);
+ ++__i;
}
// Now we know that __last - __i is even, so we do the rest in pairs,
@@ -3841,8 +3843,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
const pair<__uc_type, __uc_type> __pospos =
__gen_two_uniform_ints(__swap_range, __swap_range + 1, __g);
- std::iter_swap(__i++, __first + __pospos.first);
- std::iter_swap(__i++, __first + __pospos.second);
+ _RandomAccessIterator __pos1 = __first + __pospos.first;
+ _RandomAccessIterator __pos2 = __first + __pospos.second;
+ if (__i != __pos1)
+ std::iter_swap(__i, __pos1);
+ ++__i;
+ if (__i != __pos2)
+ std::iter_swap(__i, __pos2);
+ ++__i;
}
return;
I think we also want to remove the __glibcxx_check_self_move_assign assertions
completely.
[Bug c++/85782] acc loops with continue statements ICE in c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85782 --- Comment #1 from cesar at gcc dot gnu.org --- Author: cesar Date: Fri May 18 15:43:09 2018 New Revision: 260369 URL: https://gcc.gnu.org/viewcvs?rev=260369&root=gcc&view=rev Log: PR c++/85782 gcc/cp/ * cp-gimplify.c (cp_genericize_r): Call genericize_omp_for_stmt for OACC_LOOPs. gcc/testsuite/ * c-c++-common/goacc/pr85782.c: New test. libgomp/ * testsuite/libgomp.oacc-c-c++-common/pr85782.c: New test. Added: trunk/gcc/testsuite/c-c++-common/goacc/pr85782.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85782.c Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/testsuite/ChangeLog trunk/libgomp/ChangeLog
[Bug c++/85782] acc loops with continue statements ICE in c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85782 --- Comment #2 from cesar at gcc dot gnu.org --- Author: cesar Date: Fri May 18 15:46:56 2018 New Revision: 260370 URL: https://gcc.gnu.org/viewcvs?rev=260370&root=gcc&view=rev Log: PR c++/85782 Backport from mainline 2018-05-18 Cesar Philippidis PR c++/85782 gcc/cp/ * cp-gimplify.c (cp_genericize_r): Call genericize_omp_for_stmt for OACC_LOOPs. gcc/testsuite/ * c-c++-common/goacc/pr85782.c: New test. libgomp/ * testsuite/libgomp.oacc-c-c++-common/pr85782.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/c-c++-common/goacc/pr85782.c branches/gcc-8-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85782.c Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/cp-gimplify.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/libgomp/ChangeLog
[Bug c/85830] New: vec_popcntd is improperly defined in altivec.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85830
Bug ID: 85830
Summary: vec_popcntd is improperly defined in altivec.h
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: munroesj at gcc dot gnu.org
Target Milestone: ---
Created attachment 44147
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44147&action=edit
compile test case for vec_popcntd.
Altivec.h should define either the generic vec_popcnt or the specific
vec_vpopcntd.
In GCC-8.1 altivec.h defines the expected vec_popcnt (as defined in the ABI)
and the PIM style specific vec_vpopcntd. these are OK.
However it also defines vec_popcntd which generates __builtin_vec_vpopcntud.
This gives compile errors.
vector unsigned long long
__test_popcntd_2 (vector unsigned long long a)
{
return (vec_popcntd (a));
}
vector unsigned int
__test_popcntw_2 (vector unsigned int a)
{
return (vec_popcntw (a));
}
vec_popcnt-2.c: In function ‘__test_popcntd_2’:
vec_popcnt-2.c:31:3: error: invalid parameter combination for AltiVec intrinsic
‘__builtin_vec_vpopcntud’
return (vec_popcntd (a));
^~
vec_popcnt-2.c: In function ‘__test_popcntw_2’:
vec_popcnt-2.c:37:3: error: invalid parameter combination for AltiVec intrinsic
‘__builtin_vec_vpopcntuw’
return (vec_popcntw (a));
^~
There are two problems here;
1) You would expect a __builtin_vec_vpopcntud to accept a unsigned input and it
does not. I am not sure what it does accept.
2) The vec_popcntd define fits neither the ABI generic specific (vec_popcnt())
or the old PIM specific style (vec_vpopcntd() which follows the PowerISA
mnemonic.
This 3rd style should be removed from altivec.h ( vec_popcntb, vec_popcnth,
vec_popcntw, vec_popcntd)
While retaining the ABI generic and PIM specific definitions.
[Bug libstdc++/85098] undefined reference to std::regex::extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85098 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Fri May 18 16:14:04 2018 New Revision: 260371 URL: https://gcc.gnu.org/viewcvs?rev=260371&root=gcc&view=rev Log: PR libstdc++/85098 add missing definitions for static constants In C++11 and C++14 any odr-use of these constants requires a definition at namespace-scope. In C++17 they are implicitly inline and so the namespace-scope redeclarations are redundant (and allowing them is deprecated). PR libstdc++/85098 * include/bits/regex.h [__cplusplus < 201703L] (basic_regex::icase) (basic_regex::nosubs, basic_regex::optimize, basic_regex::collate) (basic_regex::ECMAScript, basic_regex::basic, basic_regex::extended) (basic_regex::awk, basic_regex::grep, basic_regex::egrep): Add definitions. * include/bits/regex_automaton.h (_NFA::_M_insert_state): Adjust whitespace. * include/bits/regex_compiler.tcc (__INSERT_REGEX_MATCHER): Add braces around body of do-while. * testsuite/28_regex/basic_regex/85098.cc: New Added: trunk/libstdc++-v3/testsuite/28_regex/basic_regex/85098.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/regex.h trunk/libstdc++-v3/include/bits/regex_automaton.h trunk/libstdc++-v3/include/bits/regex_compiler.tcc
[Bug libstdc++/85098] undefined reference to std::regex::extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85098 --- Comment #6 from Jonathan Wakely --- Fixed on trunk but I'll keep this open as I plan to backport it.
[Bug libstdc++/85831] New: types should have move constructors and move assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85831
Bug ID: 85831
Summary: types should have move constructors and
move assignment operators
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
The standard says:
namespace std {
class logic_error : public exception {
public:
explicit logic_error(const string& what_arg);
explicit logic_error(const char* what_arg);
};
}
The lack of user-declared special members means that a move constructor and
move assignment operator should be implicitly declared.
But we define:
class logic_error : public exception
{
[...]
virtual ~logic_error() _GLIBCXX_TXN_SAFE_DYN _GLIBCXX_USE_NOEXCEPT;
[...]
};
The user-declared destructor means there is no move constructor or move
assignment operator.
(The user-defined destructor is the key function and ensures the vtable and
RTTI are only emitted in the library, not in every TU).
[Bug target/85298] relocation errors on windows when linking C code to libstdc++ built with weakrefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85298 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-18 CC||redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/85832] New: [AVX512] possible shorter code when comparing with vector of zeros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85832
Bug ID: 85832
Summary: [AVX512] possible shorter code when comparing with
vector of zeros
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wojciech_mula at poczta dot onet.pl
Target Milestone: ---
Consider this simple function, which yields mask fors non-zero elements:
---cat cmp.c---
#include
int fun(__m512i x) {
return _mm512_cmpeq_epi32_mask(x, _mm512_setzero_si512());
}
---eof
$ gcc --version
gcc (Debian 7.3.0-16) 7.3.0
$ gcc -O2 -S -mavx512f cmp.c && cat cmp.s
fun:
vpxord %zmm1, %zmm1, %zmm1 # <<< HERE
vpcmpeqd%zmm1, %zmm0, %k1 # <<<
kmovw %k1, %eax
vzeroupper
ret
Also 8.1.0 generates the same code (as checked on godbolt.org).
The pair of instructions VPXORD/VPCMPEQD can be replaced with single
VPTESTMD %zmm0, %zmm0. VPTESTMD performs k1 := zmm0 AND zmm0, so to
compare zmm0 with zeros it's sufficient.
[Bug target/85833] New: [AVX512] use mask registers instructions instead of scalar code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85833
Bug ID: 85833
Summary: [AVX512] use mask registers instructions instead of
scalar code
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wojciech_mula at poczta dot onet.pl
Target Milestone: ---
There is a simple function, which checks if there is any non-zero element
in a vector:
---ktest.c---
#include
int anynonzero_epi32(__m512i x) {
const __m512i zero = _mm512_setzero_si512();
const __mmask16 mask = _mm512_cmpneq_epi32_mask(x, zero);
return mask != 0;
}
---eof---
$ gcc --version
gcc (Debian 7.3.0-16) 7.3.0
$ gcc -O2 -S -mavx512f ktest.c && cat ktest.s
anynonzero_epi32:
vpxord %zmm1, %zmm1, %zmm1
vpcmpd $4, %zmm1, %zmm0, %k1
kmovw %k1, %eax # <<< HERE
testw %ax, %ax#
setne %al
movzbl %al, %eax
vzeroupper
ret
The problem is that GCC copies content of the mask register k1 into
GPR (using KMOV instruction), and then perform test. AVX512F has got
instruction KTEST kx, ky which sets ZF and CF:
ZF = (kx AND ky) == 0
CF = (kx AND NOT ky) == 0
In this case we might use KTEST k1, k1 to set ZF when k1 == 0.
The procedure might be then compiled as:
anynonzero_epi32:
vpxord %zmm1, %zmm1, %zmm1
vpcmpd $4, %zmm1, %zmm0, %k1
xor %eax, %eax #
ktestw %k1, %k1#
setne %al #
vzeroupper
ret
[Bug target/85829] [8/9 Regression] PARTIAL_REG_DEPENDENCY and MOVX were disabled for Haswell and newer processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85829 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-18 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jan Hubicka --- It would be nice to have an examples where they are needed. The motivation to disable them was optimization manuals claiming that Haswell+ handles partial reg stalls better than old cores. Also PARTIAL_REG_DEPENDENCY does not really fit the hardware design of cores which are partial reg stall architecture. So in theory if we enable something it should be the PARTIAL_REG_STALL flag.
[Bug target/85829] [8/9 Regression] PARTIAL_REG_DEPENDENCY and MOVX were disabled for Haswell and newer processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85829 --- Comment #2 from H.J. Lu --- Haswell tuning was done many years ago. We really shouldn't change it. For newer processors, we need to investigate PARTIAL_REG_DEPENDENCY vs PARTIAL_REG_STALL.
[Bug target/85829] [8/9 Regression] PARTIAL_REG_DEPENDENCY and MOVX were disabled for Haswell and newer processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85829 --- Comment #3 from Jan Hubicka --- > Haswell tuning was done many years ago. We really shouldn't change it. > For newer processors, we need to investigate PARTIAL_REG_DEPENDENCY vs > PARTIAL_REG_STALL. I have revisited the tunning options primarily to define more reasonable generic. For that I have revisited some flags which seems to have been set incorrectly. We run regular benchmarks on Haswell at https://gcc.opensuse.org/gcc-old/index.html (Czerny) and especially specfp2000 has improved noticeably past release cycle. https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64/mean-fp_big.png There are quite few haswell chips around so I do not see why we should stop trying to improve code generated there plus it would be good to have fewer combinations enabled for differnt generations. So I would suggest to revisit PARTIAL_REG_DEPENDENCY wrt PARTIAL_REG_STALL for Haswell+ Honza
[Bug tree-optimization/85826] [9 Regression] ICE in builtin_memref in gcc/gimple-ssa-warn-restrict.c:281 starting with r260280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85826 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug c/85834] New: ice in set_ssa_val_to, at tree-ssa-sccvn.c:3396
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85834 Bug ID: 85834 Summary: ice in set_ssa_val_to, at tree-ssa-sccvn.c:3396 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: --- ../../trunk/gcc/asan.c: In function ‘rtx_insn* asan_emit_stack_protection(rtx, rtx, unsigned int, long int*, tree_node**, int)’: ../../trunk/gcc/asan.c:1252:1: internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:3396 asan_emit_stack_protection (rtx base, rtx pbase, unsigned int alignb, ^~ 0x10391dd set_ssa_val_to(tree_node*, tree_node*) ../../trunk/gcc/tree-ssa-sccvn.c:3393 0x103a3c5 visit_use(tree_node*) ../../trunk/gcc/tree-ssa-sccvn.c:0 0x102fdcb process_scc(vec) ../../trunk/gcc/tree-ssa-sccvn.c:4416 0x102fdcb extract_and_process_scc_for_name(tree_node*) ../../trunk/gcc/tree-ssa-sccvn.c:4487 This fault can be demonstrated by bootstrapping gcc with the following commands: ../trunk/configure --prefix=/home/dcb/gcc/results.260370 \ --disable-multilib \ --disable-werror \ --enable-checking=df,extra,fold,rtl,yes \ --enable-languages=c,c++,fortran sed 's/-O2/-O3/' < Makefile > Makefile.tmp mv Makefile.tmp Makefile This command used to work at revision 260281, but now at revision 260370, it doesn't work.
[Bug c/85834] ice in set_ssa_val_to, at tree-ssa-sccvn.c:3396
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85834 --- Comment #1 from David Binderman --- Removing the last two lines of commands which replace -O2 with -O3 also make it work, so it looks like someone's broken some part of -O3 since Wed 16 May.
[Bug sanitizer/85835] New: libsanitizer includes unconditionally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85835
Bug ID: 85835
Summary: libsanitizer includes unconditionally
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: adhemerval.zanella at linaro dot org, dodji at gcc dot
gnu.org,
dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org,
kcc at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc has
#include
...
#if SANITIZER_LINUX && !SANITIZER_ANDROID
unsigned struct_ustat_sz = sizeof(struct ustat);
unsigned struct_rlimit64_sz = sizeof(struct rlimit64);
unsigned struct_statvfs64_sz = sizeof(struct statvfs64);
#endif // SANITIZER_LINUX && !SANITIZER_ANDROID
But has been removed from glibc 2.28 by
commit cf2478d53ad7071e84c724a986b56fe17f4f4ca7
Author: Adhemerval Zanella
Date: Sun Mar 18 11:28:59 2018 +0800
Deprecate ustat syscall interface
As for sysctl, ustat has been deprecated in favor of {f}statfs. Also
some newer ports which uses generic interface builds a stub version that
returns ENOSYS.
This patch deprecates ustat interface by removing ustat.h related headers,
adding a compatibility symbol, and avoiding new ports to build and provide
the symbol.
Checked on x86_64-linux-gnu and i686-linux-gnu. Also checked with a
check-abi on all affected ABIs.
[Bug tree-optimization/85826] [9 Regression] ICE in builtin_memref in gcc/gimple-ssa-warn-restrict.c:281 starting with r260280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85826 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #1 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00939.html
[Bug fortran/85599] Prevent short-circuiting of logical expressions for non-pure functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599 --- Comment #32 from janus at gcc dot gnu.org --- (In reply to Steve Kargl from comment #31) > > This PR is not about reordering, but about short-circuiting. > > AFAICT this PR is about a function with side-effects, > and re-ordering can have an potentially undesirable > result. Yah, I guess you can dream up all kinds of possible issues with non-pure functions, but that is really beyond the scope of this PR. I feel like I have already opened up a barrel large enough, and have gotten sufficient flak for that. I'm really not interested in taking this discussion any further. If you are, please open a new PR for that.
[Bug libstdc++/85824] regex constructor crashes under UTF-8 locale on Solaris SPARC when parsing a simple character class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85824
--- Comment #5 from Tim Shen ---
(In reply to Jonathan Wakely from comment #4)
> Tim, I'll take care of checking errno in collate<>::_M_transform but could
> you advise what to do about the regex compiler? Maybe:
>
> --- a/libstdc++-v3/include/bits/regex.h
> +++ b/libstdc++-v3/include/bits/regex.h
> @@ -257,7 +257,11 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
> const __ctype_type& __fctyp(use_facet<__ctype_type>(_M_locale));
> std::vector __s(__first, __last);
> __fctyp.tolower(__s.data(), __s.data() + __s.size());
> - return this->transform(__s.data(), __s.data() + __s.size());
> + __try {
> + return this->transform(__s.data(), __s.data() + __s.size());
> + } catch(const std::runtime_error&) {
> + return string_type();
> + }
> }
>
>/**
First of all, std::regex("[0-9]") shouldn't be locale sensitive, as
regex_constants::collate is set. If somehow a locale-related exception was
thrown without collate being set, it's a bug in the regex implementation and we
should fix it. We probably have a bug in _BracketMatcher::_M_apply().
When collate is set, we still don't want to eagerly forward exceptions in regex
ctor. I think regex_traits<>::transform_primary should be exception neutral
(unless it's specified otherwise). Instead, we some how fix regex's constructor
not to generate exceptions from _BracketMatcher::_M_make_cache().
Regarding the compile-time variable __collate in _BracketMatcher, I suggest to
fix _BracketMatcher to the following definition:
* If !__collate or -fno-exceptions, nothing needs to be changed; otherwise
* change the element of cache from bool to a 3-state enum, e.g. enum { MATCHED,
NOT_MATCHED, NOT_CACHED }. When an exception happens in _M_make_cache, catch it
and set the cache result to NOT_CACHED. During regex matching, non-cached
result requires a full run of _M_apply() and it likely throws.
[Bug libstdc++/85824] regex constructor crashes under UTF-8 locale on Solaris SPARC when parsing a simple character class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85824
--- Comment #6 from Tim Shen ---
(In reply to Tim Shen from comment #5)
> First of all, std::regex("[0-9]") shouldn't be locale sensitive, as
> regex_constants::collate is set.
Correction: as regex_constants::collate is *not* set.
[Bug fortran/85836] New: [meta-bug] Fortran 2018 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836 Bug ID: 85836 Summary: [meta-bug] Fortran 2018 support 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: --- meta bug to track all PRs related to the Fortran 2018 standard
[Bug tree-optimization/85834] ice in set_ssa_val_to, at tree-ssa-sccvn.c:3396
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85834 David Binderman changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from David Binderman --- Revision 260318, dated 17 May, is the most recent change to file tree-ssa-sccvn.c Adding Richard Biener.
[Bug web/85837] New: Listing of all error and warning messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85837 Bug ID: 85837 Summary: Listing of all error and warning messages Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: eyalroz at technion dot ac.il Target Milestone: --- Compiler error and warning messages are sometimes difficult to understand - especially (but not exclusively) for novice developers. They are also typically concise, and assume some knowledge of relevant terms, which the program author may not know, despite being able to write a program. I also note that many users repeatedly ask questions on web forums and Q&A sites (e.g. StackOverflow) regarding specific error messages they get - not just asking "what's wrong with my code which causes the error?", but rather "What does this message mean? I don't understand what it says." Now, the GCC manual does not seem include such a listing, and I could not find it on the Wiki either. Assuming it indeed doesn't exist - I believe that it should. If it does exist, then the bug is that it's difficult to notice/locate. Note that to realize such a listing it should be possible to harness more than just the GCC developers, if it's done through the Wiki. (Of course people would need to be attracted to the Wiki to assist in doing this.)
[Bug web/85837] Listing of all error and warning messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85837 Andrew Pinski changed: What|Removed |Added Keywords||documentation --- Comment #1 from Andrew Pinski --- We try to improve error messages rather than list all of the error messages out. For an example the following URL links of the improvements to all of the diagnostic in GCC 8 (that was recorded as a bugzilla entry): https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&component=c%2B%2B&keywords=diagnostic%2C%20&keywords_type=allwords&list_id=210084&product=gcc&query_format=advanced&resolution=FIXED&short_desc=Regression&short_desc_type=notregexp&target_milestone=8.0
[Bug bootstrap/85838] New: -Wmaybe-uninitialized warning in sparc.c (sparc_expand_builtin) breaks SPARC bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85838
Bug ID: 85838
Summary: -Wmaybe-uninitialized warning in sparc.c
(sparc_expand_builtin) breaks SPARC bootstrap
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
Host: sparc-sun-solaris2.*
Target: sparc-sun-solaris2.*
Build: sparc-sun-solaris2.*
Between 20180517 (r260326) and 20180518 (r260354), Solaris/SPARC bootstrap got
broken. Compiling sparc.c in stage2 gives
In file included from /vol/gcc/src/hg/trunk/local/gcc/config/sparc/sparc.c:42:
/vol/gcc/src/hg/trunk/local/gcc/recog.h: In function 'rtx_def*
sparc_expand_builtin(tree, rtx, rtx, machine_mode, int)':
/vol/gcc/src/hg/trunk/local/gcc/recog.h:303:85: error: 'op[0]' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
rtx_insn * operator () (rtx a0, rtx a1, rtx a2, rtx a3) const { return
((f4)func) (a0, a1, a2, a3); }
~~~^~~~
/vol/gcc/src/hg/trunk/local/gcc/config/sparc/sparc.c:11595:12: note: 'op[0]'
was declared here
rtx pat, op[4];
^~
A reghunt identified this patch
2018-05-18 Richard Biener
* tree-dfa.c (get_ref_base_and_extent): Use range-info to refine
results when processing array refs with variable index.
as the culprit.
[Bug bootstrap/85838] -Wmaybe-uninitialized warning in sparc.c (sparc_expand_builtin) breaks SPARC bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85838 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug bootstrap/85838] -Wmaybe-uninitialized warning in sparc.c (sparc_expand_builtin) breaks SPARC bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85838 --- Comment #1 from Eric Botcazou --- Author: ebotcazou Date: Fri May 18 18:49:20 2018 New Revision: 260374 URL: https://gcc.gnu.org/viewcvs?rev=260374&root=gcc&view=rev Log: PR bootstrap/85838 * config/sparc/sparc.c (sparc_expand_builtin): Always initialize op[0]. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c
[Bug bootstrap/85838] -Wmaybe-uninitialized warning in sparc.c (sparc_expand_builtin) breaks SPARC bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85838 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|8.0 |9.0 Resolution|--- |FIXED --- Comment #2 from Eric Botcazou --- This should work again.
[Bug target/85833] [AVX512] use mask registers instructions instead of scalar code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85833
--- Comment #1 from Uroš Bizjak ---
(In reply to Wojciech Mula from comment #0)
> There is a simple function, which checks if there is any non-zero element
> in a vector:
>
> ---ktest.c---
> #include
>
> int anynonzero_epi32(__m512i x) {
> const __m512i zero = _mm512_setzero_si512();
> const __mmask16 mask = _mm512_cmpneq_epi32_mask(x, zero);
> return mask != 0;
> }
> ---eof---
>
> $ gcc --version
> gcc (Debian 7.3.0-16) 7.3.0
>
> $ gcc -O2 -S -mavx512f ktest.c && cat ktest.s
ktestw is AVX512DQ instruction.
[Bug web/85837] Listing of all error and warning messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85837 --- Comment #2 from Eyal Rozenberg --- (In reply to Andrew Pinski from comment #1) > We try to improve error messages rather than list all of the error messages > out. But the listed error messages must balance readability/accessibility with conciseness. Specifically, an error message will never have a short example of a typical error and a correction. Or an explanation, in a few sentences, of a some concept referred to by the message, or a quotation of a paragraph from the language standard and so on.
[Bug fortran/85599] Prevent short-circuiting of logical expressions for non-pure functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
--- Comment #33 from Steve Kargl ---
On Fri, May 18, 2018 at 06:23:41PM +, janus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
>
> --- Comment #32 from janus at gcc dot gnu.org ---
> (In reply to Steve Kargl from comment #31)
> > > This PR is not about reordering, but about short-circuiting.
> >
> > AFAICT this PR is about a function with side-effects,
> > and re-ordering can have an potentially undesirable
> > result.
>
> Yah, I guess you can dream up all kinds of possible issues with non-pure
> functions, but that is really beyond the scope of this PR. I feel like I have
> already opened up a barrel large enough, and have gotten sufficient flak for
> that. I'm really not interested in taking this discussion any further. If you
> are, please open a new PR for that.
>
I don't think you're getting flak. I think you're
getting discussion, where both Thomas and I disagree
with you on whether this is a bug or not. This has
nothing to do with a pure or impure function. This
has to do with special casing a binop to explicitly
require that both arguments must be evaluated, because
one of the operands may have a side-effect. The Fortran
standard explicitly allows the current behavior.
Thomas is willing to compromise to at least issue a
warning that in '.false. .and. check()' check()
may not be evaluated. I've suggested a new option
-fno-short-circuit and a review of all binops to
force evaluation of both operands.
If I were to give you flak, I would have suggested
that you contact the other Fortran vendors with
bug reports for a missed optimization. It could
take a very long time to evaluate check(). Why
bother with the evaluation when the result for
'.false. .and. check()' is known regardless of the
result for check()? Yes, it is a rhetorical
question as I know your answer that check() may
have side-effects.
And, if I were really to give you flak, I would
suggest that a patch is louder than words.
svn diff gcc/fortran/trans-expr.c
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 260235)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -3446,6 +3446,12 @@ gfc_conv_expr_op (gfc_se * se, gfc_expr * expr)
if (lop)
{
+ if (expr->value.op.op == INTRINSIC_AND
+ || expr->value.op.op == INTRINSIC_OR)
+ {
+ lse.expr = gfc_evaluate_now (lse.expr, &se->pre);
+ rse.expr = gfc_evaluate_now (rse.expr, &se->pre);
+ }
/* The result of logical ops is always logical_type_node. */
tmp = fold_build2_loc (input_location, code, logical_type_node,
lse.expr, rse.expr);
% gfcx -o z a.f90 && ./z
check 1
check 2
I completely disagree with this patch without -fno-short-circuit.
You're welcomed.
[Bug fortran/82275] gfortran rejects valid & accepts invalid reference to dimension-remapped type SELECT TYPE selector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82275 --- Comment #4 from Paul Thomas --- (In reply to Damian Rouson from comment #3) > Thanks for looking at this. Once there's a fix, it would be great if it > could be back-ported to GCC 7 as well. Hi Damian, Now I have found a bit of time, I am working through the bugs that I have taken. I have just arrived at this one. Sorry to have taken so long. Let's see how it goes :-) Paul
[Bug web/85837] Listing of all error and warning messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85837 --- Comment #3 from Jonathan Wakely --- (In reply to Eyal Rozenberg from comment #0) > Now, the GCC manual does not seem include such a listing, and I could not > find it on the Wiki either. Assuming it indeed doesn't exist - I believe > that it should. If it does exist, then the bug is that it's difficult to > notice/locate. There's https://gcc.gnu.org/wiki/VerboseDiagnostics for a few such errors. > Note that to realize such a listing it should be possible to harness more > than just the GCC developers, if it's done through the Wiki. (Of course > people would need to be attracted to the Wiki to assist in doing this.) This absolutely should be done by users, not the GCC developers. We're all busy working on GCC already, and if we knew how to make the diagnostics easier to understand then we'd already have done it.
[Bug c++/85792] #include triggers Wctor-dtor-privcay
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85792
Jonathan Wakely changed:
What|Removed |Added
Keywords|diagnostic |
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-05-18
Component|libstdc++ |c++
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
The warning is bogus, because that type inherits a default constructor from its
base class (also it probably shouldn't give a warning for code in system
headers).
Minimal testcase:
template struct A { };
template struct B : A {
using A::A;
B(const B&) { }
};
It's probably related to constructors in dependent base classes not being seen
at the point the warning is given.
[Bug c++/85792] [8/9 Regression] #include triggers Wctor-dtor-privcay
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85792 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic CC||nathan at gcc dot gnu.org Known to work||7.3.0 Summary|#include triggers |[8/9 Regression] #include |Wctor-dtor-privcay | triggers ||Wctor-dtor-privcay Known to fail||8.1.0, 9.0 --- Comment #2 from Jonathan Wakely --- Regression starting with r250281: * class.c (maybe_warn_about_overly_private_class): Ignore public copy ctors. * g++.dg/warn/ctor-dtor-privacy-3.C: New.
[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407 --- Comment #15 from Jason Merrill --- Author: jason Date: Fri May 18 20:02:48 2018 New Revision: 260381 URL: https://gcc.gnu.org/viewcvs?rev=260381&root=gcc&view=rev Log: PR c++/58407 - deprecated implicit copy ops. gcc/c-family/ * c.opt (Wdeprecated-copy): New flag. gcc/cp/ * call.c (build_over_call): Warn about deprecated trivial fns. * class.c (classtype_has_user_copy_or_dtor): New. (type_build_ctor_call): Check TREE_DEPRECATED. (type_build_dtor_call): Likewise. * decl2.c (cp_warn_deprecated_use): Move from tree.c. Add checks. Return bool. Handle -Wdeprecated-copy. (mark_used): Use it. * decl.c (grokdeclarator): Remove redundant checks. * typeck2.c (build_functional_cast): Likewise. * method.c (lazily_declare_fn): Mark deprecated copy ops. * init.c (build_aggr_init): Only set TREE_USED if there are side-effects. libitm/ * beginend.cc (save): Disable -Werror=deprecated-copy. Added: trunk/gcc/testsuite/g++.dg/cpp0x/depr-copy1.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/init.c trunk/gcc/cp/method.c trunk/gcc/cp/tree.c trunk/gcc/cp/typeck2.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/g++.old-deja/g++.other/warn6.C trunk/libitm/ChangeLog trunk/libitm/beginend.cc
[Bug fortran/85839] New: [F2018] warn for obsolescent features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85839 Bug ID: 85839 Summary: [F2018] warn for obsolescent features 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: --- Fortran 2018 introduces several new obsolescences: * COMMON * EQUIVALENCE * BLOCK DATA * labelled DO statements * specific names for standard intrinsic functions * FORALL (see also PR 40881, where the same has been done for the F03 obsolenscences)
[Bug fortran/85840] New: Memory leak in write.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 Bug ID: 85840 Summary: Memory leak in write.c Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jjcogliati-r1 at yahoo dot com Target Milestone: --- This bug comes from trying to find a memory leak in my own program. gfortran --version GNU Fortran (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5) Copyright (C) 2017 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. The line in my code was: print '(A16,I7,6E25.16E3)',"start line print",i,a,b,c,d,e,f where a,b,c,d,e,f are complicated real kinds. The valgrind trace was: ==23064== 142,120 bytes in 440 blocks are definitely lost in loss record 39 of 49 ==23064==at 0x4C2CB6B: malloc (vg_replace_malloc.c:299) ==23064==by 0x4E53454: _gfortrani_xmalloc (memory.c:42) ==23064==by 0x4FD637A: write_float_0 (write.c:1593) ==23064==by 0x4FCD98C: formatted_transfer_scalar_write (transfer.c:2041) ==23064==by 0x4FCDF9C: formatted_transfer (transfer.c:2279) Looking at write.c, we have: /* String buffer to hold final result. */ result = select_string (dtp, f, str_buf, &res_len, kind); //line 1593 buffer = select_buffer (dtp, f, precision, buf_stack, &buf_size, kind); get_float_string (dtp, f, source , kind, 0, buffer, precision, buf_size, result, &res_len); write_float_string (dtp, result, res_len); if (buf_size > BUF_STACK_SZ) free (buffer); if (res_len > BUF_STACK_SZ) free (result); Notice that we assign to the value of res_len from select_string AND from get_float_string, and get_float_string can assign to the length in functions called from it such as in build_float_string So I think what is happening is res_len is getting assigned a number that is smaller than BUF_STACK_SZ, and then result is not getting freed. I haven't come up with a small test case yet, but I certainly can if needed.
[Bug fortran/85841] New: [F018] reject deleted features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85841 Bug ID: 85841 Summary: [F018] reject deleted features 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: --- Fortran 2018 removes the following features: * arithmetic IF statement * nonblock DO construct They have been obsolescent since F90, and should now be rejected with -std=f2018.
[Bug web/85837] Listing of all error and warning messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85837 --- Comment #4 from Eyal Rozenberg --- (In reply to Jonathan Wakely from comment #3) > There's https://gcc.gnu.org/wiki/VerboseDiagnostics for a few such errors. Well, that's a (tiny) start... however: * I wouldn't have found it if you wouldn't have provided the link - and I did search the Wiki (albeit not very thoroughly) * I think that has low search engine visibility * I believe there should be some auto-generated skeleton of that (either a single page or multiple pages) which collects all error messages. * I would definitely separate the language-specific errors for different languages (perhaps an even finer separation into pages is called for, but certainly at least that) > This absolutely should be done by users, not the GCC developers. We're all > busy working on GCC already, and if we knew how to make the diagnostics > easier to understand then we'd already have done it. Fair enough, but, honestly - if the page says "Please, feel free to suggest new content in gcc-help mailing list" - practically nobody will contribute. Also, I'm sure that some of this could be adapted from from other sources online.
[Bug web/85837] Listing of all error and warning messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85837 --- Comment #5 from Jonathan Wakely --- (In reply to Eyal Rozenberg from comment #4) > Fair enough, but, honestly - if the page says "Please, feel free to suggest > new content in gcc-help mailing list" - practically nobody will contribute. Why not? > Also, I'm sure that some of this could be adapted from from other sources > online. Be the change that you want to see in the world. If you want this, make it happen.
[Bug web/85837] Listing of all error and warning messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85837 Eric Gallager changed: What|Removed |Added Keywords||diagnostic CC||dmalcolm at gcc dot gnu.org, ||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Jonathan Wakely from comment #3) > (In reply to Eyal Rozenberg from comment #0) > > Now, the GCC manual does not seem include such a listing, and I could not > > find it on the Wiki either. Assuming it indeed doesn't exist - I believe > > that it should. If it does exist, then the bug is that it's difficult to > > notice/locate. > > There's https://gcc.gnu.org/wiki/VerboseDiagnostics for a few such errors. > > > Note that to realize such a listing it should be possible to harness more > > than just the GCC developers, if it's done through the Wiki. (Of course > > people would need to be attracted to the Wiki to assist in doing this.) > > This absolutely should be done by users, not the GCC developers. We're all > busy working on GCC already, and if we knew how to make the diagnostics > easier to understand then we'd already have done it. This is something David Malcolm sometimes focuses on; cc-ing him.
[Bug web/85837] Listing of all error and warning messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85837 --- Comment #7 from Eyal Rozenberg --- (In reply to Jonathan Wakely from comment #5) > Be the change that you want to see in the world. > > If you want this, make it happen. Well, I already started by filing this bug, but point taken. > (In reply to Eyal Rozenberg from comment #4) > > Fair enough, but, honestly - if the page says "Please, feel free to suggest > > new content in gcc-help mailing list" - practically nobody will contribute. > > Why not? Really? Ok, I'll explain: Many/most people familiar with collaboratively-edited resources such as Wikis or Q&A sites expect either immediate ability to edit content, or a requirement of at most website registration. What this line is telling visitors is (with slight over-dramatization): "Don't expect to be able to edit existing content on this page, ever. Don't expect to easily add content to this page, ever. If you want to even add anything to this page, you have to increase your level of commitment to that of being a mailing list member. You'll have to talk to people on that mailing list. You'll have to convince them your addition is important. Then maybe it'll be added." - this amounts to telling most people to go away.
[Bug libstdc++/83891] std::filesystem::path::is_absolute for Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83891 --- Comment #4 from Jonathan Wakely --- This is still wrong, for Windows it should be: return has_root_name() && has_root_directory(); But I'll fix it as part of PR 78870
[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899 --- Comment #24 from Marc Glisse --- Author: glisse Date: Fri May 18 22:21:20 2018 New Revision: 260383 URL: https://gcc.gnu.org/viewcvs?rev=260383&root=gcc&view=rev Log: Aliasing 'this' in a C++ constructor 2018-05-18 Marc Glisse PR c++/82899 gcc/ * tree-ssa-structalias.c (create_variable_info_for_1): Extra argument. (intra_create_variable_infos): Handle C++ constructors. gcc/testsuite/ * g++.dg/pr82899.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/pr82899.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899 Marc Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #25 from Marc Glisse --- .
[Bug web/85837] Listing of all error and warning messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85837 --- Comment #8 from Jonathan Wakely --- (In reply to Eyal Rozenberg from comment #7) > (In reply to Jonathan Wakely from comment #5) > > Be the change that you want to see in the world. > > > > If you want this, make it happen. > > Well, I already started by filing this bug, but point taken. So far you're just asking for other people to do the work. Speaking for myself, I already know what GCC's diagnostics mean, and so what you're suggesting wouldn't be useful to me* and that's probably true for most GCC developers. You're asking busy people to do a ton of work. * before you say I should do it anyway to help users, note that I did already add most of the content to the wiki page. > > (In reply to Eyal Rozenberg from comment #4) > > > Fair enough, but, honestly - if the page says "Please, feel free to > > > suggest > > > new content in gcc-help mailing list" - practically nobody will > > > contribute. > > > > Why not? > > Really? Ok, I'll explain: Many/most people familiar with > collaboratively-edited resources such as Wikis or Q&A sites expect either > immediate ability to edit content, or a requirement of at most website > registration. What this line is telling visitors is (with slight > over-dramatization): "Don't expect to be able to edit existing content on > this page, ever. Don't expect to easily add content to this page, ever. If This isn't a slight over-dramatization, this is nonsense. "Please feel free to suggest new content" does not mean "you can not add new content, ever". > you want to even add anything to this page, you have to increase your level > of commitment to that of being a mailing list member. Nobody has to be a member of anything to send an email to the list. You don't have to subscribe, you just have to send an email. > You'll have to talk to > people on that mailing list. The horror! > You'll have to convince them your addition is > important. Then maybe it'll be added." I don't think that's unreasonable, otherwise the page would descend into total garbage very rapidly. Sites like Wikipedia and StackOverflow depend on thousands of active contributors to keep the signal to noise ratio high and we don't have the resources. > - this amounts to telling most people > to go away. I've tried to improve the info at the top of the page. If you think it can still be improved please make suggestions.
[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Jason Merrill --- (In reply to Jason Merrill from comment #14) > An interesting subcategory I noticed when I had the warning on by default is > classes with a virtual destructor, such as the exception hierarchy. The > warning calls attention to potential slicing problems, and so I think we > don't want to add defaulted copy ops; it's good for users to be encouraged > to e.g. catch by reference. For the record, I changed my mind about this; a slicing warning should only apply to copies from an object of unknown dynamic type. -Wdeprecated-copy added for GCC 9.
[Bug c++/81930] [meta-bug] Issues with -Weffc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81930 Bug 81930 depends on bug 58407, which changed state. Bug 58407 Summary: [C++11] Should warn about deprecated implicit generation of copy constructor/assignment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/82063] issues with arguments enabled by -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82063 Martin Sebor changed: What|Removed |Added Component|c |middle-end --- Comment #7 from Martin Sebor --- Patch for -Walloc-alloc-size-larger-than problems: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00950.html
[Bug tree-optimization/85834] ice in set_ssa_val_to, at tree-ssa-sccvn.c:3396
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85834 --- Comment #3 from rguenther at suse dot de --- On May 18, 2018 8:33:35 PM GMT+02:00, dcb314 at hotmail dot com wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85834 > >David Binderman changed: > > What|Removed |Added > > CC||rguenth at gcc dot gnu.org > >--- Comment #2 from David Binderman --- >Revision 260318, dated 17 May, is the most recent change to file >tree-ssa-sccvn.c > >Adding Richard Biener. If you have preprocessed source available that would help.
