[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282 --- Comment #1 from songyuanyao --- The error message for the code (from gcc8.0.1): error: explicit specialization in non-namespace scope
[Bug c++/85282] New: CWG 727 (full specialization in non-namespace scope)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282
Bug ID: 85282
Summary: CWG 727 (full specialization in non-namespace scope)
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: songyuanyao at qq dot com
Target Milestone: ---
According to CWG 727, the following code should be accepted; i.e. full
specialization may be declared inside class definition.
struct A {
template struct B;
template <> struct B { };
};
And per [temp.expl.spec] paragraph 2,
An explicit specialization may be declared in any scope in which the
corresponding primary template may be defined ([namespace.memdef], [class.mem],
[temp.mem]).
[Bug middle-end/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976 --- Comment #14 from Thomas Koenig --- Author: tkoenig Date: Sat Apr 7 23:52:03 2018 New Revision: 259212 URL: https://gcc.gnu.org/viewcvs?rev=259212&root=gcc&view=rev Log: 2018-04-07 Thomas Koenig Andrew Pinski PR middle-end/82976 * match.pd: Use constant_boolean_node of correct type instead of boolean_true_node or boolean_false_node for simplifying pointer comparisons to zero. 2018-04-07 Thomas Koenig PR middle-end/82976 * gfortran.dg/realloc_on_assign_16a.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_16a.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug c++/85269] warn for referenced standard symbols that aren't guaranteed to be declared in a header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85269
--- Comment #4 from Martin Sebor ---
Your example in comment #2 should not warn. Projects often have their own
"base" header that includes a a bunch of standard headers and that by
convention is included in each of the project's source files so they don't have
to worry about this kind of portability problem.
I envision an algorithm that would look up the standard header where each
standard symbol used in a translation unit is declared or defined and see if
the standard header has been directly included at that point by some
non-standard file; if not, the warning would trigger.
I imagine there would need to be exceptions for the common cases you describe
where this warning would be unhelpful, and the algorithm would need to be
parameterized on the version of the standard to account for changes to the
synopses of the headers.
The problem is interesting. A solution to it might involve a separate
enhancement to the existing machinery. For example, in the following, GCC
suggests to include (as expected) but doesn't provide a similar
suggestion for the incomplete char_traits (which is required to be
forward-declared in ). GCC also doesn't provide such a suggestion for
std::string which isn't required to be declared in . The warning
should be able to differentiate these cases and trigger for any mention of
std::string but avoid triggering for uses of std::char_traits that don't
require it to be a complete type. This also suggests that for uses of types
declared in without the appropriate header included GCC might want to
suggest to include when the use doesn't require the type to be
complete, rather than suggesting to include the header that defines the type.
#include
enum {
e0 = sizeof (std::char_traits*),// okay, no warning
e1 = sizeof (std::char_traits), // warn if not error
e2 = sizeof (std::basic_string*), // warn
e3 = sizeof (std::basic_string),// warn if not error
e4 = sizeof (std::vector*), // warn if not error
e5 = sizeof (std::vector)// warn if not error
};
pr85269.C:5:38: error: invalid application of ‘sizeof’ to incomplete type
‘std::char_traits’
e1 = sizeof (std::char_traits), // warn if not error
^
pr85269.C:8:39: error: invalid application of ‘sizeof’ to incomplete type
‘std::__cxx11::basic_string’
e3 = sizeof (std::basic_string),// warn if not error
^
pr85269.C:10:21: error: ‘vector’ is not a member of ‘std’
e4 = sizeof (std::vector*), // warn if not error
^~
pr85269.C:10:21: note: ‘std::vector’ is defined in header ‘’; did you
forget to ‘#include ’?
pr85269.C:2:1:
+#include
pr85269.C:10:21:
e4 = sizeof (std::vector*), // warn if not error
^~
pr85269.C:10:28: error: expected primary-expression before ‘int’
e4 = sizeof (std::vector*), // warn if not error
^~~
pr85269.C:10:28: error: expected ‘)’ before ‘int’
e4 = sizeof (std::vector*), // warn if not error
~^~~
)
[Bug c++/85269] warn for referenced standard symbols that aren't guaranteed to be declared in a header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85269 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > Also, we'd need to be careful so that we don't warn about referring to > std::ostream without , because exists specifically to make > that possible. Also, is now guaranteed to include , but wasn't in previous versions of the standard. According to the standard, std::char_traits is defined by , but in practice it has to be defined by and as well, so it would be unhelpful to warn about using it without . Similarly, std::allocator is defined in , but has to be defined by most containers (and other headers) so it would be unhelpful to warn about using std::allocator without . Making this warning actually useful might be a lot of work.
[Bug c++/85269] warn for referenced standard symbols that aren't guaranteed to be declared in a header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85269 --- Comment #2 from Jonathan Wakely --- Could you clarify the suggestion? Should your first example warn because std::locale is only declared not defined? What if we later modify so it does include the whole of , would that stop the warning? The user code is just as non-portable so the warning would be just as useful. But to warn even if the right header has been included would mean tracking whether it was included directly or transitively, and if transitively then deciding whether that was included by "the user" or not. Should this warn? #include #include "foolib.h" // includes void f (std::locale); Would it depend on whether foolib.h was a system header? Also, we'd need to be careful so that we don't warn about referring to std::ostream without , because exists specifically to make that possible.
[Bug target/85281] New: [8 Regression] Assembler messages: Error: operand size mismatch for `vpbroadcastb' with -mavx512bw -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85281
Bug ID: 85281
Summary: [8 Regression] Assembler messages: Error: operand size
mismatch for `vpbroadcastb' with -mavx512bw
-masm=intel
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Created attachment 43875
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43875&action=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -mavx512bw -masm=intel -w testcase.c -save-temps
testcase.s: Assembler messages:
testcase.s:32: Error: operand size mismatch for `vpbroadcastb'
The failing instruction is:
...
vpbroadcastbzmm0{k2}, XMMWORD PTR [rsp+48]
...
which is mixing zmm0 and XMMWORD.
This compiles fine with att syntax:
...
vpbroadcastb48(%rsp), %zmm0{%k2}
...
The gcc I am using is patched with the fix for PR85177#c1
7-branch is fine on this testcase, but it generates very different (inferior in
my eyes) code.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-259207-checking-yes-rtl-df-extra-nobootstrap-pr85177-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-259207-checking-yes-rtl-df-extra-nobootstrap-pr85177-amd64
Thread model: posix
gcc version 8.0.1 20180407 (experimental) (GCC)
[Bug target/85280] [8 Regression] Bootstrap comparison failure on powerpc64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85280 Thomas Koenig changed: What|Removed |Added Target||powerpc64-unknown-linux-gnu Target Milestone|--- |8.0
[Bug target/85280] New: [8 Regression] Bootstrap comparison failure on powerpc64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85280 Bug ID: 85280 Summary: [8 Regression] Bootstrap comparison failure on powerpc64-unknown-linux-gnu Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- With r259211, clean trunk: make[3]: Leaving directory `/home/tkoenig/trunk-bin' Comparing stages 2 and 3 warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1obj-checksum.o differs Bootstrap comparison failure! gcc/gcc.o differs gcc/plugin.o differs make[2]: *** [compare] Fehler 1 make[2]: Leaving directory `/home/tkoenig/trunk-bin' make[1]: *** [stage3-bubble] Fehler 2 make[1]: Leaving directory `/home/tkoenig/trunk-bin' make: *** [all] Fehler 2 Configure was ../trunk/connfigure --prefix=$HOME/GCC --enable-languages=all && make -j32 && make install The machine was gcc110.fsffrance.org. Bootstrapping compiler was gcc-Version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC)
[Bug c++/85279] New: [6/7/8 Regression] Broken diagnostic for decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85279
Bug ID: 85279
Summary: [6/7/8 Regression] Broken diagnostic for decltype
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following invalid testcase produces a broken diagnostic since GCC 4.7.0:
template struct A
{
void foo(decltype(T())::Y);
};
bug.cc:3:27: error: '#'decltype_type' not supported by dump_expr#::Y' is not a type
void foo(decltype(T())::Y);
^
[Bug c++/85278] New: [concepts] Garbled diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85278
Bug ID: 85278
Summary: [concepts] Garbled diagnostic
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Blocks: 67491
Target Milestone: ---
The testcase gcc/testsuite/g++.dg/concepts/req2.C produces a broken diagnostic
since GCC 6.1.0:
req2.C:18:14: error: cannot call function 'void f2(auto:2) requires (> [with auto:2
= void*]'
The offending testcase can be reduced to:
==
void f2(auto a)
requires requires (decltype(a) x) { -x; }
{ }
int main() {
f2((void*)0);
}
==
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues
[Bug c++/85277] New: [8 Regression] Broken diagnostic for offsetof with static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85277
Bug ID: 85277
Summary: [8 Regression] Broken diagnostic for offsetof with
static member function
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The testcase gcc/testsuite/g++.dg/ext/offsetof1.C produces a broken diagnostic
on trunk:
offsetof1.C:15:50: error: cannot apply 'offsetof' to member function
'#'indirect_ref' not supported by dump_decl#'
The offending problem can be reduced to:
==
struct bar {
static int baz();
};
int bv0 = __builtin_offsetof(volatile bar, baz[0]);
==
The regression was introduced between 2017-11-09 and 2017-11-17.
[Bug fortran/70870] Segmentation violation in gfc_assign_data_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70870 --- Comment #7 from kargl at gcc dot gnu.org --- (In reply to Gerhard Steinmetz from comment #2) > A variant that aborts with this message directly : > > $ gfortran-6 z1.f90 > f951: internal compiler error: in gfc_assign_data_value, at > fortran/data.c:449 > > $ cat z1.f90 > program p >type t > integer :: n >end type >type(t), pointer :: z => null() >data z%n / 3 / >print *, z%n > end > > --- > > A minimal change of z1.f90 immediately points to pr50410 : > > $ cat z2.f90 > program p >type t > integer :: n >end type >type(t), pointer :: z >data z%n / 3 / >print *, z%n > end > > $ gfortran-6 z2.f90 > f951: internal compiler error: in record_reference, at cgraphbuild.c:64 These "variant" are different problems than the one in the intial post. The original problem is considered with an entity that has a default initializer appearing in a DATA statement. The above examples are issues with a unassociated pointer appearing a DATA statement. These should have a new PR opened for them.
[Bug gcov-profile/85276] [GCOV] A comparative statement with '=', '&&' , '||', and '==' operators is wrongly marked as executed twice in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85276 --- Comment #1 from Yibiao Yang --- This bug is similar to bug 85163. As it is not a call statement apart from bug 85163, I report it as a new one.
[Bug gcov-profile/85276] New: [GCOV] A comparative statement with '=', '&&' , '||', and '==' operators is wrongly marked as executed twice in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85276
Bug ID: 85276
Summary: [GCOV] A comparative statement with '=', '&&' , '||',
and '==' operators is wrongly marked as executed twice
in gcov
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)
$ cat small.c
int a, b, c, d, e;
void main() {
((e=a) && c || 5 || 0) == b || d;
}
$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 3
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:int a, b, c, d, e;
1:2:void main() {
2:3: ((e=a) && c || 5 || 0) == b || d;
1:4:}
**
Line #3 is wrongly marked as executed twice.
[Bug c/84183] internal compiler error: in initialize, at alloc-pool.h:257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84183 --- Comment #5 from Thomas Plank --- (In reply to Thomas Plank from comment #4) > I'm pretty sure I already had binutils updated to 2.30. > > I will give it a try with a downgrade to 2.29.1 and check if gcc 7.3.0 > builds then. I didn't do the downgrade but used the patched binutils version. GCC now builds under cygwin, see below: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-cygwin/7.3.0/lto-wrapper.exe Target: x86_64-unknown-cygwin Configured with: ../gcc-7.3.0/configure --enable-threads --enable-languages=c,c++,fortran,lto,objc,obj-c++ --disable-sjlj-exceptions --with-mpc=/usr/local --with-isl=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local Thread model: posix gcc version 7.3.0 (GCC)
[Bug tree-optimization/80021] untranslateable diagnostic "type variant differs by " #flag "."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80021 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/80021] untranslateable diagnostic "type variant differs by " #flag "."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80021 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Sat Apr 7 10:57:53 2018 New Revision: 259211 URL: https://gcc.gnu.org/viewcvs?rev=259211&root=gcc&view=rev Log: PR tree-optimization/80021 * tree.c (verify_type_variant): Make error call in verify_variant_match translatable and remove final full stop. Modified: trunk/gcc/ChangeLog trunk/gcc/tree.c
[Bug middle-end/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976
--- Comment #13 from Thomas Koenig ---
(In reply to Andrew Pinski from comment #12)
> match.pd looks like it has a type bug:
> /* Simplify pointer equality compares using PTA. */
> (for neeq (ne eq)
> (simplify
> (neeq @0 @1)
> (if (POINTER_TYPE_P (TREE_TYPE (@0))
>&& ptrs_compare_unequal (@0, @1))
>{ neeq == EQ_EXPR ? boolean_false_node : boolean_true_node; })))
>
>
> It assumes all types of EQ_EXPR/NE_EXPR will be boolean_type_node which is
> not true.
> It should be using constant_boolean_node (neeq != EQ_EXPR, type); .
I'll run a regression-test on
Index: match.pd
===
--- match.pd(Revision 259152)
+++ match.pd(Arbeitskopie)
@@ -3700,7 +3700,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(neeq @0 @1)
(if (POINTER_TYPE_P (TREE_TYPE (@0))
&& ptrs_compare_unequal (@0, @1))
- { neeq == EQ_EXPR ? boolean_false_node : boolean_true_node; })))
+ { constant_boolean_node (neeq != EQ_EXPR, type); })))
/* PR70920: Transform (intptr_t)x eq/ne CST to x eq/ne (typeof x) CST.
and (typeof ptr_cst) x eq/ne ptr_cst to x eq/ne (typeof x) CST.
and submit if it passes.
[Bug tree-optimization/85275] New: copyheader peels off almost the entire iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85275
Bug ID: 85275
Summary: copyheader peels off almost the entire iteration
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
I expected predcom to eliminate one of the loads in this loop at -O3:
int is_sorted(int *a, int n)
{
for (int i = 0; i < n - 1; i++)
if (a[i] > a[i + 1])
return 0;
return 1;
}
Unfortunately, predcom bails out since the loads it sees are not
always-executed. Ideally loop header copying would make this a suitable
do-while loop, but in this case it duplicates too much:
;; Loop 1
;; header 5, latch 4
;; depth 1, outer 0
;; nodes: 5 4 3
;; 2 succs { 5 }
;; 3 succs { 6 4 }
;; 4 succs { 5 }
;; 5 succs { 3 6 }
;; 6 succs { 1 }
Analyzing loop 1
Loop 1 is not do-while loop: latch is not empty.
Will duplicate bb 5
Will duplicate bb 3
Not duplicating bb 4: it is single succ.
Duplicating header of the loop 1 up to edge 3->4, 12 insns.
[...]
[local count: 114863532]:
_17 = n_12(D) + -1;
if (_17 > 0)
goto ; [94.50%]
else
goto ; [5.50%]
[local count: 108546038]:
_18 = 0;
_19 = _18 * 4;
_20 = a_13(D) + _19;
_21 = *_20;
_22 = _18 + 1;
_23 = _22 * 4;
_24 = a_13(D) + _23;
_25 = *_24;
if (_21 > _25)
goto ; [5.50%]
else
goto ; [94.50%]
[local count: 906139986]:
_1 = (long unsigned int) i_15;
_2 = _1 * 4;
_3 = a_13(D) + _2;
_4 = *_3;
_5 = _1 + 1;
_6 = _5 * 4;
_7 = a_13(D) + _6;
_8 = *_7;
if (_4 > _8)
goto ; [5.50%]
else
goto ; [94.50%]
[local count: 958878293]:
# i_26 = PHI <0(3), i_15(4)>
i_15 = i_26 + 1;
_9 = n_12(D) + -1;
if (_9 > i_15)
goto ; [94.50%]
else
goto ; [5.50%]
(throttling it down with --param max-loop-header-insns=5 gives the expected
optimization)
[Bug target/80022] arc: diagnostic ending in two periods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80022
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
There should be no periods at all, and it shouldn't use DK_WARNING either.
So like:
if (warning (0, "PIC is not supported for %s", arc_cpu_string))
inform ("generating non-PIC code only");
or so.
[Bug tree-optimization/85257] [6/7 Regression] wrong code with -O -fno-tree-ccp and reading zeroed vector member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85257 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Summary|[6/7/8 Regression] wrong|[6/7 Regression] wrong code |code with -O -fno-tree-ccp |with -O -fno-tree-ccp and |and reading zeroed vector |reading zeroed vector |member |member --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug gcov-profile/85274] New: [GCOV] A return statement in if(0) block is wrongly marked as executed when they are nested in for(;1;) statement and prefixed with an struct declaration and followed by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85274
Bug ID: 85274
Summary: [GCOV] A return statement in if(0) block is wrongly
marked as executed when they are nested in for(;1;)
statement and prefixed with an struct declaration and
followed by a assignment statement in gcov
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ cat small.c
struct s {int s1;};
int a = 0;
int main() {
for (; 1;) {
struct s g;
if (0)
return 2;
return 0;
a = 0;
}
return 0;
}
$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat smal.c.gcov
File 'small.c'
Lines executed:80.00% of 5
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:struct s {int s1;};
-:2:int a = 0;
1:3:int main() {
1:4: for (; 1;) {
-:5:struct s g;
-:6:if (0)
1:7: return 2;
1:8:return 0;
-:9:a = 0;
-: 10: }
#: 11: return 0;
-: 12:}
**
Line #7 is wrongly marked as executed.
while removing any of Line #5 or Line #9, the result is correct.
[Bug tree-optimization/85257] [6/7/8 Regression] wrong code with -O -fno-tree-ccp and reading zeroed vector member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85257 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Sat Apr 7 07:20:42 2018 New Revision: 259206 URL: https://gcc.gnu.org/viewcvs?rev=259206&root=gcc&view=rev Log: PR tree-optimization/85257 * fold-const.c (native_encode_vector): If not all elts could fit and off is -1, return 0 rather than offset. * tree-ssa-sccvn.c (vn_reference_lookup_3): Pass (offseti - offset2) / BITS_PER_UNIT as 4th argument to native_encode_expr. Verify len * BITS_PER_UNIT >= maxsizei. Don't adjust buffer in native_interpret_expr call. * gcc.dg/pr85257.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr85257.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
