[Bug c++/66924] Bad diagnostic for parameter name used as non-type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66924 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||dodji at gcc dot gnu.org --- Comment #2 from Eric Gallager --- cc-ing diagnostics maintainers
[Bug c/87298] New: [9 Regression] FAIL: gcc.c-torture/execute/pr87053.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87298 Bug ID: 87298 Summary: [9 Regression] FAIL: gcc.c-torture/execute/pr87053.c Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- On x86, r264291 gave FAIL: gcc.c-torture/execute/pr87053.c -O0 execution test FAIL: gcc.c-torture/execute/pr87053.c -O1 execution test FAIL: gcc.c-torture/execute/pr87053.c -O2 execution test FAIL: gcc.c-torture/execute/pr87053.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.c-torture/execute/pr87053.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: gcc.c-torture/execute/pr87053.c -O3 -g execution test FAIL: gcc.c-torture/execute/pr87053.c -Os execution test
[Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #17 from Manuel López-Ibáñez --- I don't think this is a bug. GCC warns at higher levels because it can inline. Doing more optimization at -O2 is a separate issue.
[Bug c++/87293] An object with invalid type is treated as if it were of type int when reporting errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87293 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez --- Probably Bug 57678 Probably we should use some kind of error_mark_node, but that is likely to break other things.
[Bug middle-end/54544] Option -Wuninitialized does not work as documented with volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54544
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||manu at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #5 from Manuel López-Ibáñez ---
This has nothing to do with volatile, as this reduced testcase shows:
int fct2(void);
int fct(int *p);
static int foo(int * p )
{
do {
if ( *p )
{
return fct( p );
}
}
while ( fct2() );
return 0;
}
int bar()
{
int i;
return foo( );
}
The issue here is that the testcase creates virtual phis
# .MEM_9 = PHI <.MEM_1(D)(2), .MEM_12(7)>
and this is not handled by the uninit pass yet.
*** This bug has been marked as a duplicate of bug 19430 ***
[Bug middle-end/19430] taking address of a var causes missing uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 Manuel López-Ibáñez changed: What|Removed |Added CC||jimfr06 at gmail dot com --- Comment #34 from Manuel López-Ibáñez --- *** Bug 54544 has been marked as a duplicate of this bug. ***
[Bug middle-end/60488] missing uninitialized warning (address taken, VOP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
--- Comment #5 from Manuel López-Ibáñez ---
Even simpler:
int f (int*);
int g(void);
int foo (void)
{
int b;
if (g() && f ())
return 0;
return b;
}
we have:
# .MEM_7 = VDEF <.MEM_6(D)>
# USE = nonlocal null { D.1912 } (escaped)
# CLB = nonlocal null { D.1912 } (escaped)
_1 = gD.1908 ();
if (_1 != 0)
goto ; [33.00%]
else
goto ; [67.00%]
;; basic block 6, loop depth 0, count 719407024 (estimated locally), maybe
hot
# .MEM_11 = PHI <.MEM_7(6), .MEM_8(8)>
# DEBUG BEGIN_STMT
# VUSE <.MEM_11>
_9 = bD.1912;
but uninit pass does not follow the PHI chain for memory ops.
[Bug c/87297] [9 Regression] ICE on strncpy with an undeclared argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87297 Martin Sebor changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-13 Known to work||8.2.0 Ever confirmed|0 |1 Known to fail||9.0 --- Comment #1 from Martin Sebor --- The ICE was introduced in r261515 (gcc 9.0.0): r261515 | msebor | 2018-06-12 13:14:31 -0400 (Tue, 12 Jun 2018) | 19 lines PR c/85931 - -Wsizeof-pointer-memaccess for strncpy with size of source gcc/c-family/ChangeLog: PR c/85931 * c-warn.c (sizeof_pointer_memaccess_warning): Avoid warning when sizeof source and destination yields the same value. gcc/ChangeLog: PR c/85931 * fold-const.c (operand_equal_p): Handle SAVE_EXPR.
[Bug c/87297] New: [9 Regression] ICE on strncpy with an undeclared argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87297
Bug ID: 87297
Summary: [9 Regression] ICE on strncpy with an undeclared
argument
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The following ill-formed test case triggers an ICE:
$ cat t.c && gcc -S -Wall t.c
struct S { char a[4]; };
void g (struct S *p, const char *s)
{
__builtin_strncpy (c->a, s, sizeof p->a);
}
t.c: In function ‘g’:
t.c:5:22: error: ‘c’ undeclared (first use in this function)
5 | __builtin_strncpy (c->a, s, sizeof p->a);
| ^
t.c:5:22: note: each undeclared identifier is reported only once for each
function it appears in
t.c:5:3: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in sizeof_pointer_memaccess_warning, at
c-family/c-warn.c:816
5 | __builtin_strncpy (c->a, s, sizeof p->a);
| ^
0x141f756 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/ssd/src/gcc/svn/gcc/tree.c:9417
0x7ea3ff tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/ssd/src/gcc/svn/gcc/tree.h:3239
0x9494fc sizeof_pointer_memaccess_warning(unsigned int*, tree_node*,
vec*, tree_node**, bool (*)(tree_node*,
tree_node*))
/ssd/src/gcc/svn/gcc/c-family/c-warn.c:816
0x880aec c_parser_postfix_expression_after_primary
/ssd/src/gcc/svn/gcc/c/c-parser.c:9176
0x88030f c_parser_postfix_expression
/ssd/src/gcc/svn/gcc/c/c-parser.c:9015
0x879f4a c_parser_unary_expression
/ssd/src/gcc/svn/gcc/c/c-parser.c:7278
0x879418 c_parser_cast_expression
/ssd/src/gcc/svn/gcc/c/c-parser.c:7119
0x877a36 c_parser_binary_expression
/ssd/src/gcc/svn/gcc/c/c-parser.c:6922
0x8771bb c_parser_conditional_expression
/ssd/src/gcc/svn/gcc/c/c-parser.c:6656
0x876ea9 c_parser_expr_no_commas
/ssd/src/gcc/svn/gcc/c/c-parser.c:6573
0x88127f c_parser_expression
/ssd/src/gcc/svn/gcc/c/c-parser.c:9325
0x8814db c_parser_expression_conv
/ssd/src/gcc/svn/gcc/c/c-parser.c:9358
0x874481 c_parser_statement_after_labels
/ssd/src/gcc/svn/gcc/c/c-parser.c:5551
0x8734dc c_parser_compound_statement_nostart
/ssd/src/gcc/svn/gcc/c/c-parser.c:5089
0x872eaa c_parser_compound_statement
/ssd/src/gcc/svn/gcc/c/c-parser.c:4923
0x86d6fe c_parser_declaration_or_fndef
/ssd/src/gcc/svn/gcc/c/c-parser.c:2351
0x86bb9d c_parser_external_declaration
/ssd/src/gcc/svn/gcc/c/c-parser.c:1644
0x86b6a1 c_parser_translation_unit
/ssd/src/gcc/svn/gcc/c/c-parser.c:1524
0x8a1458 c_parse_file()
/ssd/src/gcc/svn/gcc/c/c-parser.c:18403
0x91d06a c_common_parse_file()
/ssd/src/gcc/svn/gcc/c-family/c-opts.c:1139
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug middle-end/87296] -Wstringop-overflow false positive due to bogus MEM_REF type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87296
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||7.3.0
Keywords||diagnostic
Last reconfirmed||2018-09-13
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Summary|-Wstringop-overflow false |-Wstringop-overflow false
|positive|positive due to bogus
||MEM_REF type
Known to fail||8.2.0, 9.0
--- Comment #1 from Martin Sebor ---
Confirmed with the simplified C test case below. The warning sees a MEM_REF
(char[4], ...) as the destination of the strncpy call. Why the type is char[4]
is a mystery to me. I guess the type in MEM_REF really can't be trusted.
gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout pr87296.c
;; Function g (g, funcdef_no=0, decl_uid=1913, cgraph_uid=1, symbol_order=0)
g (struct S * p, const char * s)
{
void * _1;
char[4] * _2;
[local count: 1073741824]:
_1 = [(void *)p_3(D) + 4B];
_2 = _3(D)->a;
f (_2, _1);
__builtin_strncpy (_1, s_6(D), 6); [tail call]
return;
}
pr87296.c: In function ‘g’:
pr87296.c:11:3: warning: ‘__builtin_strncpy’ writing 6 bytes into a region of
size 4 overflows the destination [-Wstringop-overflow=]
11 | __builtin_strncpy (p->b, s, sizeof p->b);
| ^~~~
[Bug c++/39970] gcc accepts the . dot operator in template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39970
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||accepts-invalid
Last reconfirmed|2012-01-06 00:00:00 |2018-9-13
--- Comment #8 from Manuel López-Ibáñez ---
class blah { public:
int member; };
blah global; // global
template
class template_blah { /* blah */ };
[Bug c++/16582] Wrong diagnostic when using "[1]" as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16582
Manuel López-Ibáñez changed:
What|Removed |Added
Last reconfirmed|2005-05-09 00:48:28 |2018-9-13
Known to fail||
--- Comment #3 from Manuel López-Ibáñez ---
Clang:
:8:9: error: non-type template argument does not refer to any
declaration
X x3; // ERROR
^~~~
:1:25: note: template parameter is declared here
template struct X {
^
[Bug fortran/87284] [7/8/9 Regression] Allocation of class arrays with mold results in "conditional jump or move depends on uninitialised value"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87284 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Paul Thomas --- Fixed on 7-branch thru' trunk. Paul
[Bug fortran/87284] [7/8/9 Regression] Allocation of class arrays with mold results in "conditional jump or move depends on uninitialised value"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87284 --- Comment #3 from Paul Thomas --- Author: pault Date: Thu Sep 13 19:46:05 2018 New Revision: 264288 URL: https://gcc.gnu.org/viewcvs?rev=264288=gcc=rev Log: 2018-09-13 Paul Thomas PR fortran/87284 * trans-expr.c (gfc_trans_class_init_assign): Access to to array elements of the dynamic type requires that the array reference be added to the class expression and not the _data component, unlike scalar expressions. 2018-09-13 Paul Thomas PR fortran/87284 * gfortran.dg/allocate_with_mold_2.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/allocate_with_mold_2.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/trans-expr.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/46244] gfc_compare_derived_types is buggy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244 --- Comment #19 from janus at gcc dot gnu.org --- I'll note that the ICE on comment 1 is gone since version 6, while comment 5 still ICEs with 9-trunk.
[Bug fortran/81748] [OOP] extensible types non-conforming behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81748
--- Comment #2 from janus at gcc dot gnu.org ---
Slightly reduced test case:
program z
implicit none
type t1
integer :: age
end type
type, extends( t1 ) :: t2
real :: height_cm
end type
type( t2 ) :: p( 4 )
p % age = (/ 1,2,3,4 /)
call s( p )
call s( p % t1 )
contains
subroutine s( man )
class( t1 ) :: man(:)
write (*,*) man % age
end subroutine
end
This prints something like:
1 2 3 4
1 0 2 1659587003
where the second line is obviously wrong.
-fdump-tree-original shows that the class containers that are build for the two
calls to 's' have exactly the same data, but different vptr, which is certainly
wrong:
{
struct __class_z_T1_1_0t class.8;
struct array01_t2 parm.9;
class.8._vptr = (struct __vtype_z_T1 * {ref-all}) &__vtab_z_T2;
parm.9.dtype = {.elem_len=8, .rank=1, .type=5};
parm.9.dim[0].lbound = 1;
parm.9.dim[0].ubound = 4;
parm.9.dim[0].stride = 1;
parm.9.data = (void *) [0];
parm.9.offset = -1;
class.8._data = parm.9;
s ();
}
{
struct __class_z_T1_1_0t class.10;
struct array01_t2 parm.11;
class.10._vptr = (struct __vtype_z_T1 * {ref-all}) &__vtab_z_T1;
parm.11.dtype = {.elem_len=8, .rank=1, .type=5};
parm.11.dim[0].lbound = 1;
parm.11.dim[0].ubound = 4;
parm.11.dim[0].stride = 1;
parm.11.data = (void *) [0];
parm.11.offset = -1;
class.10._data = parm.11;
s ();
}
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #24 from Gerald Pfeifer --- Confirmed for i386-unknown-freebsd10.3 (using clang as bootstrap compiler) as well. Thank you, Richard!
[Bug middle-end/77696] Confusing wording for -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77696
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #16 from Manuel López-Ibáñez ---
To be honest, I find the fancy UI too overwhelming and a bit redundant in
simple cases.
It is true that the diagnostics could be improved by some tweaks. I took some
of the ideas here and I came up with the following flexible template.
1. First the main warning has only four variants, depending on whether we are
writing a fixed number or a range and whether we are sure or not:
warning: formatting %d bytes will/may overflow buffer '%BUFF' of size %BUFFSIZE
warning: formatting between %d and %d bytes will/may overflow buffer '%BUFF' of
size %BUFFSIZE
Example:
demo.c:6:3: warning: formatting 43 bytes will overflow 'buff' of size 16
[-Wformat-overflow=]
6 | sprintf (buf, "msg: %s\n", msg);
|~~~ ^
2. The next note explains the details (for all cases in comment #1):
// bounded, definite truncation copying format string
zzz.c:15:30: note: the format string will be truncated at character 'B' after
%d bytes
snprintf (d, sizeof d, "%iAB", 123);
~~~^
// unbounded, definite overflow in a directve
zzz.c:18:15: note: the terminating nul will be written after the end of 'd'
sprintf (d, "%i", 1235);
^
// unbounded, definite overflow copying format string
zzz.c:21:19: note: character ‘B’ of the format string will be written after the
end of 'd'
sprintf (d, "%iAB", 123);
~~~^
(I don't think we need to specify the offset, the column number and the caret
line should already point to the correct 'B', otherwise, it is more important
to get that fixed)
// bounded, possible truncation a directive
zzz.c:24:27: note: argument 4 corresponding to ‘%i’ has range [‘1’,
‘-2147483648’] and may be truncated after 4 bytes
snprintf (d, sizeof d, "%i", i);
~^ ~
// bounded, possible truncation copying format string
zzz.c:27:27: note: argument 4 corresponding to '%i' has range [‘1’,
‘-2147483648’] and may be truncated after 4 bytes
snprintf (d, sizeof d, "%iAB", i);
~^ ~
(these may look different, but they are exactly the same case)
// unbounded, possible overflow in a directive
zzz.c:30:16: note: argument 4 corresponding to '%i' has range [‘1’,
‘-2147483648’] and may write between 1 and 11 bytes after the end of 'd'
sprintf (d, "%i", i);
~^ ~
// unbounded, possible overflow copying format string
zzz.c:37:19: note: character 'B' of the format string may be written after the
end of 'd'
sprintf (d, "%sAB", s);
~~~^
3. And additional note may explain where the argument comes from for those
cases in (2) where we mention an argument:
demo.c:12:11: the value of 'msg' comes from here
12 | test_1 ("this is long enough to cause trouble")
I think it is not very useful to complicate it further because we would need to
consider cases where:
1. There are multiple directives of variable size.
2. The format string may be very long (too long to print).
3. The expanded arguments may be very long (too long to print).
I agree that in those cases, something like this:
note: layout [-fsome-option-enabling-this]
++---++---+
|format string |starting at|size|cumulative size|
++---++---+
|"/" | 0 | 1 | 1 |
|"%s" on 'tmpdir'| 1 | 0 - 79 |1 - 80 |
|"/" |1 - 80 | 1 |2 - 81 |
|"%s" on 'fname' |2 - 81 | 0 - 7 |2 - 88 |
|"-" |2 - 88 | 1 |3 - 89 |
|"%i" on 'num' |3 - 89 | 1- 16 | 4 - 105 |
|".tmp" | 4 - 105 | 4 | 8 - 109 |
|NUL terminator | 8 - 109 | 1 | 9 - 110 |
++---++---+
could be useful (but I would argue that the column 'starting at' is redundant
and that there should be a column 'argument' that gives the numerical number of
the argument for directives, because the argument may be something much much
longer than 'num' or even something that we cannot pretty-print).
In any case, I would not over-complicate the default diagnostics with many
details. Just have the option to generate the table under some -f option.
[Bug middle-end/87296] New: -Wstringop-overflow false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87296
Bug ID: 87296
Summary: -Wstringop-overflow false positive
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: curlypaul924 at gmail dot com
Target Milestone: ---
Tested on gcc 8.1 and 8.2 on Ubuntu 16.04, and also on gcc (trunk) on
gcc.godbolt.org.
The following code:
extern "C" char *strncpy(char *, const char *, unsigned long);
void fill(char const * begin, char const * end, char c);
struct q {
char ids[4];
char username[6];
};
q & get();
int main() {
auto & c = get();
fill(c.ids, c.ids + sizeof(c.ids), '\0');
strncpy(c.username, "root", sizeof(c.username));
}
when compiled with g++ -O1 on x86-64, produces:
v.cpp: In function ‘int main()’:
v.cpp:16:10: warning: ‘char* strncpy(char*, const char*, long unsigned int)’
writing 6 bytes into a region of size 4 overflows the destination
[-Wstringop-overflow=]
strncpy(c.username, "root", sizeof(c.username));
~~~^~~~
It seems that the compiler is confusing ids and username, somehow related to
passing c.ids + 4 to fill().
If I reduce the size of username to 5 bytes, the compiler generates MOV BYTE
instead of MOV DWORD for the null-padding, and there is no warning.
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86812, which changed state. Bug 86812 Summary: visium port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86812 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/86812] visium port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86812 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #4 from Eric Botcazou --- .
[Bug target/86812] visium port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86812 --- Comment #3 from Eric Botcazou --- Author: ebotcazou Date: Thu Sep 13 17:27:00 2018 New Revision: 264281 URL: https://gcc.gnu.org/viewcvs?rev=264281=gcc=rev Log: PR target/86812 * config/visium/visium.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/visium/visium.c
[Bug target/86812] visium port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86812 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- .
[Bug target/86812] visium port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86812 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-13 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Confirmed.
[Bug target/86806] sparc port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86806 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-13 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Confirmed.
[Bug ada/81103] gcc/ada/terminals.c: please remove unused termio.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81103 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #4 from Eric Botcazou --- Done for GCC 9.
[Bug ada/81103] gcc/ada/terminals.c: please remove unused termio.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81103 --- Comment #3 from Eric Botcazou --- Author: ebotcazou Date: Thu Sep 13 17:05:40 2018 New Revision: 264277 URL: https://gcc.gnu.org/viewcvs?rev=264277=gcc=rev Log: PR ada/81103 * terminals.c: Do not include termio.h. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/terminals.c
[Bug c++/66670] "template argument deduction/substitution failed" with function pointers and multiple parameter packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66670
Marc "Foddex" Oude Kotte changed:
What|Removed |Added
CC||foddex at foddex dot net
--- Comment #2 from Marc "Foddex" Oude Kotte ---
I have a similar problem with only one parameter pack, that I think is closely
related to this bug.
The following code does not work with gcc 8.1.1, gcc 8.2 and Apple LLVM version
9.1.0, but does work with MSVC 2017 15.8.4 and icc 18.0.0 (as checked with
https://godbolt.org)
template
static void whatever(_Object*, void(_Object::*method)(_Parameters..., float))
{}
struct Foobar {
void myMethod(bool, float);
};
int main(int argc, char** argv) {
Foobar f;
whatever(, ::myMethod);
}
When compiled with -std=c+=14, gcc's output is:
: In function 'int main(int, char**)':
:10:49: error: no matching function for call to 'whatever(Foobar*, void (Foobar::*)(bool, float))'
whatever(, ::myMethod);
^
:2:13: note: candidate: 'template
void whatever(_Object*, void (_Object::*)(_Parameters ..., float))'
static void whatever(_Object*, void(_Object::*method)(_Parameters..., float))
{}
^~~~
:2:13: note: template argument deduction/substitution failed:
:10:49: note: mismatched types 'float' and 'bool'
whatever(, ::myMethod);
^
Note that the following version of the above code DOES work perfectly, on all
aforementioned mentioned compiler versions.
template
static void whatever(_Object*, void(_Object::*method)(float, _Parameters...))
{}
struct Foobar {
void myMethod(float, bool);
};
int main(int argc, char** argv) {
Foobar f;
whatever(, ::myMethod);
}
The difference is that in the first version, the parameter pack comes first,
and then the fixed float parameter, while in the second version, the float
comes first, and then the parameter pack.
Hope this helps
[Bug debug/87295] ICE with -ffat-lto-objects -fdebug-types-section -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87295 --- Comment #1 from Nathan Sidwell --- Oh, forgot to mention, trunk and gcc-8 (at least)
[Bug debug/87295] ICE with -ffat-lto-objects -fdebug-types-section -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87295 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-13 Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Ever confirmed|0 |1
[Bug debug/87295] New: ICE with -ffat-lto-objects -fdebug-types-section -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87295
Bug ID: 87295
Summary: ICE with -ffat-lto-objects -fdebug-types-section -g
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
Created attachment 44691
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44691=edit
testcase
./cc1plus -fpreprocessed bug.ii -flto -ffat-lto-objects -fdebug-types-section
-g -std=gnu++17
bug.ii: At top level:
bug.ii:17:4: internal compiler error: Segmentation fault
17 | { };
|^
0x135b276 crash_signal
/home/nathans/egcs/trunk/obj/x86_64/../../src/gcc/toplev.c:325
0x7fd5e7842f2f ???
/usr/src/debug/glibc-2.27-78-g2b47bb9cba/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x2245c90 htab_hash_string
/home/nathans/egcs/trunk/obj/x86_64/../../src/libiberty/hashtab.c:838
0xdc4487 hash_table::find_slot(external_ref*
const&, insert_option)
/home/nathans/egcs/trunk/obj/x86_64/../../src/gcc/hash-table.h:414
0xd7be32 lookup_external_ref
/home/nathans/egcs/trunk/obj/x86_64/../../src/gcc/dwarf2out.c:8954
0xd7bed9 optimize_external_refs_1
/home/nathans/egcs/trunk/obj/x86_64/../../src/gcc/dwarf2out.c:8981
0xd7bfc5 optimize_external_refs_1
/home/nathans/egcs/trunk/obj/x86_64/../../src/gcc/dwarf2out.c:8996
0xd7c122 optimize_external_refs
/home/nathans/egcs/trunk/obj/x86_64/../../src/gcc/dwarf2out.c:9045
0xd80c1a output_comp_unit
/home/nathans/egcs/trunk/obj/x86_64/../../src/gcc/dwarf2out.c:11053
0xdb9849 dwarf2out_finish
/home/nathans/egcs/trunk/obj/x86_64/../../src/gcc/dwarf2out.c:31544
[Bug debug/87294] [8/9 Regression] dwarf-3 generation fails with ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87294 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.3
[Bug tree-optimization/87263] [9 Regression] ICE on valid code at -O1: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87263 --- Comment #5 from Richard Biener --- Author: rguenth Date: Thu Sep 13 14:15:41 2018 New Revision: 264273 URL: https://gcc.gnu.org/viewcvs?rev=264273=gcc=rev Log: 2018-09-13 Richard Biener PR tree-optimization/87263 * tree-ssa-sccvn.c (visit_phi): Revert some earlier changes. (struct unwind_state): Add max_rpo field. (do_rpo_vn): Allow up-to-date loop state to be used when not iterating. Compute max_rpo, the max RPO number a block can be backwards reached from. Re-write non-iterating mode to a RPO ordered worklist approach, separating it from the iterating mode. * gcc.dg/torture/pr87263.c: New testcase. * gcc.dg/torture/ssa-fre-2.c: Likewise. * gcc.dg/torture/ssa-fre-3.c: Likewise. * gcc.dg/torture/ssa-fre-4.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr87263.c trunk/gcc/testsuite/gcc.dg/torture/ssa-fre-2.c trunk/gcc/testsuite/gcc.dg/torture/ssa-fre-3.c trunk/gcc/testsuite/gcc.dg/torture/ssa-fre-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/87263] [9 Regression] ICE on valid code at -O1: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87263 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug c++/71007] Divergence between treatment of char[0] between OR (=> SFINAE failure) and diagnostic printing (no failure)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71007 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||dodji at gcc dot gnu.org --- Comment #3 from Eric Gallager --- cc-ing diagnostics maintainers
[Bug middle-end/63155] [6/7/8/9 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
--- Comment #19 from Richard Biener ---
Oddly enough
Index: gcc/tree-ssa-coalesce.c
===
--- gcc/tree-ssa-coalesce.c (revision 264259)
+++ gcc/tree-ssa-coalesce.c (working copy)
@@ -620,7 +620,11 @@ ssa_conflicts_merge (ssa_conflicts *ptr,
{
bitmap bz = ptr->conflicts[z];
if (bz)
- bitmap_set_bit (bz, x);
+ {
+ bool was_there = bitmap_clear_bit (bz, y);
+ gcc_checking_assert (was_there);
+ bitmap_set_bit (bz, x);
+ }
}
if (bx)
changes at least the 2nd testcase to run faster (albeit memory use stays around
the same).
w/o patch
> /usr/bin/time ./cc1 -quiet t2.c
108.14user 1.62system 1:49.78elapsed 99%CPU (0avgtext+0avgdata
5610876maxresident)k
0inputs+440outputs (0major+1442106minor)pagefaults 0swaps
w/ patch
> /usr/bin/time ./cc1 -quiet t2.c
86.53user 1.46system 1:27.99elapsed 99%CPU (0avgtext+0avgdata
5610888maxresident)k
0inputs+440outputs (0major+1440069minor)pagefaults 0swaps
note this is a -O0 "optimized" cc1 binary with checking enabled so ...
It's even so slightly faster with doing
if (y < x)
{
bool was_there = bitmap_clear_bit (bz, y);
gcc_checking_assert (was_there);
bitmap_set_bit (bz, x);
}
else
{
bitmap_set_bit (bz, x);
bool was_there = bitmap_clear_bit (bz, y);
gcc_checking_assert (was_there);
}
but that's probably luck (bitmap caching and path length from start vs.
x / y). Eventually doing a forward walk also makes prefetchers
happy.
Probably with a lot of coalesces this keeps the conflict bitmaps small
(and thus the bitmap element walks fast).
Timings with release checking and optimized build:
patched:
> /usr/bin/time ../../obj/gcc/cc1 -quiet t2.c
22.91user 1.45system 0:24.38elapsed 99%CPU (0avgtext+0avgdata
5515460maxresident)k
0inputs+440outputs (0major+1378102minor)pagefaults 0swaps
patched, fancy forward walk:
> /usr/bin/time ../../obj/gcc/cc1 -quiet t2.c
22.47user 1.39system 0:23.88elapsed 99%CPU (0avgtext+0avgdata
5515420maxresident)k
0inputs+440outputs (0major+1377586minor)pagefaults 0swaps
unpatched:
> /usr/bin/time ../../obj/gcc/cc1 -quiet t2.c
46.60user 1.43system 0:48.03elapsed 99%CPU (0avgtext+0avgdata
5515380maxresident)k
0inputs+440outputs (0major+1378102minor)pagefaults 0swaps
I'm testing the simple patch now.
[Bug ada/81103] gcc/ada/terminals.c: please remove unused termio.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81103 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- .
[Bug ada/81103] gcc/ada/terminals.c: please remove unused termio.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81103 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-13 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Probably time to do it indeed.
[Bug middle-end/77696] Confusing wording for -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77696
--- Comment #15 from David Malcolm ---
(In reply to David Malcolm from comment #14)
Some random UI ideas (brainstorming in Emacs, so no idea if these are
*good* ideas):
warning: buffer overflow: writing 9-110 bytes into a buffer with capacity 80
[-Wformat-overflow=]
7 | __builtin_sprintf (buf, "/%s/%s-%i.tmp", tmpdir, fname, num);
| ~~~ ~~~^~
| ||
| |writing 9...110 bytes
| capacity: 80 bytes
note: details
7 | __builtin_sprintf (buf, "/%s/%s-%i.tmp", tmpdir, fname, num);
| ~~~ ab~cd~ef~g~~~h
| | || || || | |
| | || || || | 1 byte (NUL terminator)
| | || || || 4 bytes (".tmp")
| | || || |1...16 bytes ("%i" on 'num')
| | || || 1 byte ("-")
| | || |0-8 bytes ("%s" on 'fname')
| | || 1 byte ("/")
| | |0-79 bytes ("%s" on 'tmpdir')
| | 1 byte ("/")
| capacity: 80 bytes
note: layout [-fsome-option-enabling-this]
(with alternating colorization to better distinguish all those ranges and
labels)
|+---+--++-+-+---+--+--+
start @||0 |1 |1-80|2-81 |10-89|11-90 |12-106|16-110|
size:|| 1| 0 - 79 | 1|8|1|1-16???| 4| 1|
||"/"|%s on 'tmpdir'| "/"|%s on 'fname'| "-" |%i on 'num'|".tmp"| NUL |
|+---+--++-+-+---+--+--+
or with a vertical orientation:
note: layout [-fsome-option-enabling-this]
++---++---+
|element |starting at|size|cumulative size|
++---++---+
|"/" | 0 | 1 | 1 |
|"%s" on 'tmpdir'| 1 | 0 - 79 |1 - 80 |
|"/" |1 - 80 | 1 |2 - 81 |
|"%s" on 'fname' |2 - 81 | 0 - 7 |2 - 88 |
|"-" |2 - 88 | 1 |3 - 89 |
|"%i" on 'num' |3 - 89 | 1- 16 | 4 - 105 |
|".tmp" | 4 - 105 | 4 | 8 - 109 |
|NUL terminator | 8 - 109 | 1 | 9 - 110 |
++---++---+
(I've probably got some of the numbers wrong above, but hopefully you
get the idea of where I'm going with this).
Maybe some kind of highlight to show where we can exceed the buffer
capacity.
I like calling out the NUL terminator explicitly (as it's so easy to
get wrong), and putting "buffer overflow" upfront in the text of the
warning, as I did above.
[Bug middle-end/77696] Confusing wording for -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77696
--- Comment #14 from David Malcolm ---
Another example from Martin:
extern char buf[80];
extern char tmpdir[80];
extern char fname[8];
void f (int num)
{
sprintf (buf, "/%s/%s-%i.tmp", tmpdir, fname, num);
}
In the most basic case (nothing beyond what's in the above is
known) GCC currently prints the rather mystifying:
warning: ‘/’ directive writing 1 byte into a region of size between 0
and 79 [-Wformat-overflow=]
7 | __builtin_sprintf (buf, "/%s/%s-%i.tmp", tmpdir, fname, num);
| ^
We need to make this more "actionable" for the end-user.
[Bug middle-end/77696] Confusing wording for -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77696
--- Comment #13 from David Malcolm ---
Some more examples to consider (thanks Martin):
struct MyStrings {
char a[8], b[20];
};
const struct MyStrings ms[] = {
{ "foo", "bar" }, { "abcd", "klmno" }, ...
};
Consider:
sprintf (smallbuf, "msg: %s\n", ms[1].b);
vs this case where we don't know which one we're using:
sprintf (smallbuf, "msg: %s\n", ms[idx].b);
[Bug middle-end/63155] [6/7/8/9 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #18 from Richard Biener --- -ftree-coalesce-vars is a workaround for some testcases (enabled by default with optimization).
[Bug c++/87293] An object with invalid type is treated as if it were of type int when reporting errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87293 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-13 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > I think there's an existing bug report about this. I can't find it though, so confirmed.
[Bug middle-end/77696] Confusing wording for -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77696 --- Comment #12 from David Malcolm --- (In reply to David Malcolm from comment #5) > I brainstormed some ideas on making these kinds of warning easier for > the user to understand. Copying a string to a buffer allocated with strlen(), rather than strlen() + 1: | | | |++|++| ||0...strlen() - 1|| NUL || |++|++| vvv |<--- ok -->|| | | | to 'buf': | | |++| ||0...strlen() - 1|| |++| (drawing the user's attention to the NUL terminator, because it's such a common source of mistakes) FWIW, I have some classes for laying out ASCII art drawings which could be reused for this, as part of this vectorization RFC: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01576.html
[Bug middle-end/77696] Confusing wording for -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77696 --- Comment #11 from David Malcolm --- (In reply to David Malcolm from comment #5) > I brainstormed some ideas on making these kinds of warning easier for > the user to understand. A simple example where the overflowing write is to the start of the buffer: sprintf of an unbounded string to a fixed-size buf[100]: demo.c:6:3: note: buffer overflow... snprintf of "%s" from: |+--+|+--++---+| ||0...99|||100...strlen-1|| strlen|| || ||| || NUL || |+--+|+--++---+| |<--ok-->|<-- overflow-->| || | to 'buf': || |+--+| ||0...99|| |+--+|
[Bug middle-end/77696] Confusing wording for -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77696
--- Comment #10 from David Malcolm ---
(In reply to David Malcolm from comment #5)
> I brainstormed some ideas on making these kinds of warning easier for
> the user to understand.
Here's another possible visualization, of a different overflow:
snprintf of "%s" from:
|+---+ ... +---+|+---+ ... +---|
|| 0 | | n |||n+1| | 31|
|+---+ ... +---+|+---+ ... +---|
|<--- ok --->|<--overflow-->|
| | |
to 'buf':
| | |
++---+ ... +---+|+---+ ... +---+|
|| 0 | | x |||x+1| | 15||
++---+ ... +---+|+---+ ... +---+|
In this one, 32 bytes are being written into an unknown point ("x+1")
within a buffer of size 16.
[Bug middle-end/77696] Confusing wording for -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77696 --- Comment #9 from David Malcolm --- (In reply to David Malcolm from comment #8) > (In reply to David Malcolm from comment #5) > > I brainstormed some ideas on making these kinds of warning easier for > > the user to understand. > > Getting really fancy, we could emit an ASCII art visualization to Here's another version of the same UI idea, for the same diagnostic, which tries to show the string data (in the name of readability; I think this one is better than the above): demo.c:6:3: note: buffer overflow... snprintf of "%s" from: |+-+|+---++---+| ||0 - 10 ||| 11 - 41 || 42|| ||"this is lon"|||"g enough to cause trouble"||NUL|| |+-+|+---++---+| |<--- ok --->|<-- overflow -->| | | | to 'buf': | | | ++---+|+-+| || 0 - 4 ||| 5 - 15|| ||"msg: "|||"this is lon"|| ++---+|+-+|
[Bug middle-end/77696] Confusing wording for -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77696
--- Comment #8 from David Malcolm ---
(In reply to David Malcolm from comment #5)
> I brainstormed some ideas on making these kinds of warning easier for
> the user to understand.
Getting really fancy, we could emit an ASCII art visualization to
(hopefully) make the buffer overflow crystal-clear (with an option to
disable it):
demo.c:6:3: note: buffer overflow [-fdiagnostics-show-buffer-overflow]
snprintf of "%s" from:
|+---+---+ ... +---+---+|+---+---+ ... +---+---+|
|| 0| 1| | 9| 10||| 11| 12| | 41| 42||
||'t'|'h'| |'o'|'n'|||'g'|' '| |'e'|NUL||
|+---+---+ ... +---+---+|+---+---+ ... +---+---+|
v
|<--- ok --->|<-- overflow-->|
| | |
to 'buf':
| | |
++---+---+---+---+---+|+---+---+ ... +---+---+|
|| 0| 1| 2| 3| 4||5 | 6| | 14| 15||
||'m'|'s'|'g'|':'|' '|||'t'|'h'| |'o'|'n'||
++---+---+---+---+---+|+---+---+ ... +---+---+|
| |
(thus showing the buffer content where it's known, eliding the middle
when it goes above 5 elements)
The parts on the right-hand side ("overflow" etc) could be colorized in
red.
[Bug middle-end/77696] Confusing wording for -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77696
--- Comment #7 from David Malcolm ---
(In reply to David Malcolm from comment #6)
A tweak to this would be to show the point where the overflow occurs
(if the substring location code is up to it...):
demo.c: In function ‘test_2’:
demo.c:6:23: warning: ‘%s’ directive writing 36 bytes into a region of size 11
[-Wformat-overflow=]
6 | sprintf (buf, "msg: %s\n", msg);
|~~~^~
|| |
|| required space: 36 bytes
|remaining capacity: 11 bytes
demo.c:12:11:
12 | test_1 ("this is long enough to cause trouble");
| ^
| |
| overflow occurs here
demo.c:6:3: note: ‘sprintf’ output 43 bytes into a destination of size 16
6 | sprintf (buf, "msg: %s\n", msg);
|~~~ ^
|| |
|| required space: 43 bytes
|size: 16 bytes
[Bug middle-end/77696] Confusing wording for -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77696
--- Comment #6 from David Malcolm ---
(In reply to David Malcolm from comment #5)
> I brainstormed some ideas on making these kinds of warning easier for
> the user to understand.
We could use the new labeling-of-source-ranges idea from:
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00901.html
to print something like:
demo.c: In function ‘test_2’:
demo.c:6:23: warning: ‘%s’ directive writing 36 bytes into a region of size 11
[-Wformat-overflow=]
6 | sprintf (buf, "msg: %s\n", msg);
|~~~^~
|| |
|| required space: 36 bytes
|remaining capacity: 11 bytes
demo.c:12:11:
12 | test_1 ("this is long enough to cause trouble");
| ~~
| |
| required space: 36 bytes
demo.c:6:3: note: ‘sprintf’ output 43 bytes into a destination of size 16
6 | sprintf (buf, "msg: %s\n", msg);
|~~~ ^
|| |
|| required space: 43 bytes
|size: 16 bytes
(making a distinction between "size" and "remaining capacity",
depending on whether the code is writing to the start of the buffer or
not)
Underlining "buf" requires access to its source location, which might
not be available yet in the C frontend (if so, I can look at fixing
that).
[Bug middle-end/77696] Confusing wording for -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77696
--- Comment #5 from David Malcolm ---
(In reply to David Malcolm from comment #4)
> In the meantime, I'm going to post some of the other UI ideas for this that
> we've being chatting about, so that they're captured publicly.
Consider this problematic call to sprintf:
$ cat demo.c
#include
const char *test_1 (const char *msg)
{
static char buf[16];
sprintf (buf, "msg: %s\n", msg);
return buf;
}
void test_2 ()
{
test_1 ("this is long enough to cause trouble");
}
Right now, we emit this (this is trunk, plus some fixes for line-
numbering bugs):
$ ./xgcc -B. -c demo.c -Wall -O2
demo.c: In function ‘test_2’:
demo.c:6:23: warning: ‘%s’ directive writing 36 bytes into a region of size 11
[-Wformat-overflow=]
6 | sprintf (buf, "msg: %s\n", msg);
| ^~
demo.c:12:11:
12 | test_1 ("this is long enough to cause trouble");
| ~~
demo.c:6:3: note: ‘sprintf’ output 43 bytes into a destination of size 16
6 | sprintf (buf, "msg: %s\n", msg);
| ^~~
I brainstormed some ideas on making these kinds of warning easier for
the user to understand.
[Bug c++/87293] An object with invalid type is treated as if it were of type int when reporting errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87293 --- Comment #1 from Jonathan Wakely --- I think there's an existing bug report about this.
[Bug middle-end/77696] Confusing wording for -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77696 David Malcolm changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|msebor at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #4 from David Malcolm --- Martin: I had a go at revamping this warning on the trip back from Cauldron, and I have a mostly working prototype of something I like a lot. I'm tidying it up, and hope to post it to the mailing list sometime in the next day or so (once the FIXME count in my code is at a more reasonable level!). I'll CC you when I do. I'm assigning this one to me, hoping to get it into gcc 9. In the meantime, I'm going to post some of the other UI ideas for this that we've being chatting about, so that they're captured publicly.
[Bug c++/87289] jdk11 plinux compiled with gcc 7.3 doesn't work with NativeImageBuffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87289 --- Comment #9 from pdbain at ca dot ibm.com --- Thank you. Code updated and working.
[Bug debug/87294] New: [8/9 Regression] dwarf-3 generation fails with ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87294 Bug ID: 87294 Summary: [8/9 Regression] dwarf-3 generation fails with ICE Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: daniel.f.starke at freenet dot de Target Milestone: --- Created attachment 44690 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44690=edit test case Using GCC version 8.2.0 in mingw-w64 compiled with the following configuration fails on the attached test case. Configured with: ../../src/gcc-8.2.0/configure --host=x86_64-w64-mingw32 --enable-languages=c,c++ --enable-seh-exceptions --enable-threads=posix --disable-nls --disable-shared --enable-static --enable-fully-dynamic-string --enable-lto --enable-plugins --enable-libgomp --with-dwarf2 --enable-mingw-wildcard=platform --disable-win32-registry --enable-version-specific-runtime-libs --prefix=/mingw64-64 --with-sysroot=/mingw64-64 --target=x86_64-w64-mingw32 --enable-targets=all --enable-checking=release --with-gmp=/usr/new-gcc/lib/gmp-5.0.5 --with-mpfr=/usr/new-gcc/lib/mpfr-2.4.2 --with-mpc=/usr/new-gcc/lib/mpc-0.9 --with-isl=/usr/new-gcc/lib/isl-0.18 --with-cloog=/usr/new-gcc/lib/cloog-0.18.4 --with-host-libstdcxx='-lstdc++ -lsupc++' --disable-cloog-version-check --enable-cloog-backend=isl Thread model: posix The command-line g++ -Og -gdwarf-3 -fno-omit-frame-pointer -c a.cpp -o a.o returns during RTL pass: final a.cpp: In function 'boost::_bi::bind_t::type> boost::bind(R (*)(B1, B2, B3), A1, A2, A3) [with R = int; B1 = void*; B2 = const unsigned char*; B3 = unsigned int; A1 = boost::arg<1>; A2 = boost::arg<2>; A3 = boost::arg<3>]': a.cpp:99:3: internal compiler error: in based_loc_descr, at dwarf2out.c:14272 } ^ libbacktrace could not find executable to open Removing -gdwarf-3 or -fno-omit-frame-pointer does not result in the shown error. This issue does not occur with GCC 7.3.0. The bug report took a while as multidelta needed 25 days to reduce the pre-processed test file (14.6 MiB).
[Bug tree-optimization/87259] [9 Regression] ICE: error: definition in block 3 does not dominate use in block 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87259 --- Comment #2 from ktkachov at gcc dot gnu.org --- Patch posted at https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00640.html
[Bug c++/87293] New: An object with invalid type is treated as if it were of type int when reporting errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87293
Bug ID: 87293
Summary: An object with invalid type is treated as if it were
of type int when reporting errors
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b7.10110111 at gmail dot com
Target Milestone: ---
Consider the following C++ code:
//
#include
int main()
{
std::shared_ptr p(new double{5.3});
}
//
Here, g++ emits the following messages:
--BEGIN-
test.cpp: In function ‘int main()’:
test.cpp:4:21: error: ‘dbl’ was not declared in this scope
std::shared_ptr p(new double{5.3});
^~~
test.cpp:4:24: error: template argument 1 is invalid
std::shared_ptr p(new double{5.3});
^
test.cpp:4:43: error: invalid conversion from ‘double*’ to ‘int’ [-fpermissive]
std::shared_ptr p(new double{5.3});
^
-END---
The first error is correct: there's no dbl type. But the last error makes no
sense at all. There's nothing in the code which could imply that the type of
`p` could be `int`: even if there were no type present, C++ is not C89 to imply
`int` by default.
Moreover, if we add a line which uses `p` in another erroneous way, e.g.
"struct S{}s=p;", g++ again thinks that `p` is of type `int` ("error:
conversion from ‘int’ to non-scalar type ‘main()::S’ requested").
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #22 from Richard Biener --- > Fixed. Indeed: I've just successfully completed a i386-pc-solaris2.11 bootstrap without the workaround (preloaded libumem.so), and a sparc-sun-solaris2.11 bootstrap is well into make check. Thanks a lot. Rainer
[Bug bootstrap/12024] i386-elf build references nonexistent crt0.o, libsim.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12024 Sreekar changed: What|Removed |Added CC||cs14btech11033 at iith dot ac.in --- Comment #6 from Sreekar --- Were you able to resolve the issue??
[Bug tree-optimization/87271] [9 Regression] ICE in rpo_elim::~rpo_elim (this=0xbfbfe15c, __in_chrg=) at ../../gcc/tree-ssa-sccvn.c:5709 on FreeBSD 10.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87271 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Richard Biener --- dup anyway *** This bug has been marked as a duplicate of bug 87134 ***
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #21 from Richard Biener --- *** Bug 87271 has been marked as a duplicate of this bug. ***
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #22 from Richard Biener --- Fixed.
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #20 from Richard Biener --- Author: rguenth Date: Thu Sep 13 11:31:58 2018 New Revision: 264268 URL: https://gcc.gnu.org/viewcvs?rev=264268=gcc=rev Log: 2018-09-13 Richard Biener PR bootstrap/87134 * tree-ssa-sccvn.c (vn_nary_op_insert_into): Fix assert. (vn_nary_op_insert_pieces_predicated): Do not write useless valid_dominated_by_p entry outside of the allocated storage. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug debug/86985] Generated DWARF does not distinguish between zero-length and flexible array types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86985 Tom de Vries changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #7 from Tom de Vries --- Patch with test-case committed, marking resolved-fixed.
[Bug debug/86985] Generated DWARF does not distinguish between zero-length and flexible array types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86985 --- Comment #6 from Tom de Vries --- Author: vries Date: Thu Sep 13 10:27:12 2018 New Revision: 264267 URL: https://gcc.gnu.org/viewcvs?rev=264267=gcc=rev Log: [debug] DWARF: add DW_AT_count to zero-length arrays 2018-09-13 Omar Sandoval Tom de Vries PR debug/86985 * dwarf2out.c (is_c): New function. (add_subscript_info): Add DW_AT_count of 0 for C zero-length arrays. * gcc.dg/guality/zero-length-array.c: New test. Added: trunk/gcc/testsuite/gcc.dg/guality/zero-length-array.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug c++/87292] Warnings with Bit Fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87292
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-09-13
Ever confirmed|0 |1
--- Comment #6 from Jonathan Wakely ---
(In reply to Nuno Gonçalves from comment #4)
> I found that the issue with enum have been extensively debated at #61414.
> Sorry.
Yes, we already have Bug 61414 for that.
> So actually this bug report is only regarding the warning with initializer
> list:
>
> struct{
> uint8_t c1:6;
> uint8_t c2:6;
> } a;
> auto c = {a.c1, a.c2}; //warning: narrowing conversion of '(unsigned
> char)c1' from 'unsigned char' to 'unsigned char:6' [-Wnarrowing]
Confirmed. The initializers should be promoted before deciding the type of the
std::initializer_list.
This should compile:
#include
struct {
int c1 : 6;
int c2 : 6;
} a;
auto c = { a.c1, a.c2 };
std::initializer_list& r = c;
n.cc:7:14: warning: narrowing conversion of '(int)a.::c1' from
'int' to 'signed char:6' [-Wnarrowing]
7 | auto c = { a.c1, a.c2 };
|~~^~
n.cc:7:14: warning: narrowing conversion of 'a.::c1' from 'int'
to 'signed char:6' [-Wnarrowing]
n.cc:7:20: warning: narrowing conversion of '(int)a.::c2' from
'int' to 'signed char:6' [-Wnarrowing]
7 | auto c = { a.c1, a.c2 };
| ~~^~
n.cc:7:20: warning: narrowing conversion of 'a.::c2' from 'int'
to 'signed char:6' [-Wnarrowing]
n.cc:8:33: error: invalid initialization of reference of type
'std::initializer_list&' from expression of type
'std::initializer_list'
8 | std::initializer_list& r = c;
|
[Bug c++/87292] Warnings with Bit Fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87292 --- Comment #5 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #1) > I think the second is correct but I dont know the exact rules about enum > classes; are they unsigned by default? No, the default underlying type is 'int'
[Bug target/85628] Make better use of BFI (BFXIL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85628 --- Comment #2 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Thu Sep 13 09:46:55 2018 New Revision: 264264 URL: https://gcc.gnu.org/viewcvs?rev=264264=gcc=rev Log: [Aarch64] Exploiting BFXIL when OR-ing two AND-operations with appropriate bitmasks 2018-09-13 Sam Tebbs PR target/85628 * config/aarch64/aarch64.md (*aarch64_bfxil): Define. * config/aarch64/constraints.md (Ulc): Define. * config/aarch64/aarch64-protos.h (aarch64_high_bits_all_ones_p): Define. * config/aarch64/aarch64.c (aarch64_high_bits_all_ones_p): New function. * gcc.target/aarch64/combine_bfxil.c: New file. * gcc.target/aarch64/combine_bfxil_2.c: New file. Added: trunk/gcc/testsuite/gcc.target/aarch64/combine_bfxil.c trunk/gcc/testsuite/gcc.target/aarch64/combine_bfxil_2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-protos.h trunk/gcc/config/aarch64/aarch64.c trunk/gcc/config/aarch64/aarch64.md trunk/gcc/config/aarch64/constraints.md trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #19 from Richard Biener --- So I have now, with FreeBSD 10.4, bootstrap with host GCC 6.4.0, a libc built with -g -O0 (eh...): Starting program: /root/obj/gcc/cc1 -quiet -fpreprocessed cp-demangle.i -quiet -dumpbase cp-demangle.c -mtune=pentium -march=pentium -auxbase-strip cp-demangle.o -g -O2 -Wno-error -version -fPIC -o cp-demangle.s GNU C17 (GCC) version 9.0.0 20180913 (experimental) (i586-unknown-freebsd10.4) compiled by GNU C version 6.4.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version none GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C17 (GCC) version 9.0.0 20180913 (experimental) (i586-unknown-freebsd10.4) compiled by GNU C version 6.4.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version none GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 7de01f066f6d84094dfef092696e3ed8 Program received signal SIGSEGV, Segmentation fault. 0x2a5bbb3f in __jemalloc_arena_dalloc_bin_locked (arena=0x2a8000c0, chunk=0x2ac0, ptr=0x2aed9000, mapelm=0x2ac02220) at jemalloc_arena.c:1717 1717bin->stats.allocated -= size; (gdb) bt #0 0x2a5bbb3f in __jemalloc_arena_dalloc_bin_locked (arena=0x2a8000c0, chunk=0x2ac0, ptr=0x2aed9000, mapelm=0x2ac02220) at jemalloc_arena.c:1717 #1 0x2a5bc2d6 in __jemalloc_arena_dalloc_bin (arena=0x2a8000c0, chunk=0x2ac0, ptr=0x2aed9000, pageind=729, mapelm=0x2ac02220) at jemalloc_arena.c:1733 #2 0x2a5bc371 in __jemalloc_arena_dalloc_small (arena=0x2a8000c0, chunk=0x2ac0, ptr=0x2aed9000, pageind=729) at jemalloc_arena.c:1749 #3 0x2a5d3913 in __jemalloc_arena_dalloc (arena=0x2a8000c0, chunk=0x2ac0, ptr=0x2aed9000, try_tcache=true) at /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:1005 #4 __jemalloc_idallocx (ptr=, try_tcache=, ptr=, try_tcache=) at /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemalloc_internal.h:913 #5 __jemalloc_iqallocx (ptr=0x2aed9000, try_tcache=true) at /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemalloc_internal.h:932 #6 __jemalloc_iqalloc (ptr=0x2aed9000) at /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemalloc_internal.h:939 #7 __free (ptr=0x2aed9000) at jemalloc_jemalloc.c:1277 #8 0x097d59d5 in dom_walker::dom_walker (this=0xbfbfe6b4, direction=CDI_DOMINATORS, reachability=dom_walker::ALL_BLOCKS) at ../../trunk/gcc/domwalk.c:236 #9 0x08e7cf6b in eliminate_dom_walker::eliminate_dom_walker (this=0xbfbfe6b4, direction=CDI_DOMINATORS, inserted_exprs_=0x0) at ../../trunk/gcc/tree-ssa-sccvn.c:4693 #10 0x08e80199 in eliminate_with_rpo_vn (inserted_exprs=0x0) at ../../trunk/gcc/tree-ssa-sccvn.c:5546 #11 0x08e839b4 in do_rpo_vn (fn=0x2b197680, entry= 2)>, exit_bbs=0x0, iterate=true, eliminate=true) at ../../trunk/gcc/tree-ssa-sccvn.c:6613 #12 0x08e83b1f in (anonymous namespace)::pass_fre::execute (this=0x2ac5b8c0, fun=0x2b197680) at ../../trunk/gcc/tree-ssa-sccvn.c:6681 #13 0x08ab9021 in execute_one_pass (pass=) at ../../trunk/gcc/passes.c:2446 This is just int *postorder = XNEWVEC (int, n_basic_blocks_for_fn (cfun)); int postorder_num = pre_and_rev_post_order_compute (NULL, postorder, true); m_bb_to_rpo = XNEWVEC (int, last_basic_block_for_fn (cfun)); for (int i = 0; i < postorder_num; ++i) m_bb_to_rpo[postorder[i]] = i; free (postorder); ^^^ #0 0x2a5bbb3f in __jemalloc_arena_dalloc_bin_locked (arena=0x2a8000c0, chunk=0x2ac0, ptr=0x2aed9000, mapelm=0x2ac02220) at jemalloc_arena.c:1717 1717bin->stats.allocated -= size; (gdb) p bin $1 = (arena_bin_t *) 0x1 where bin is computed as 1697pageind = ((uintptr_t)ptr - (uintptr_t)chunk) >> LG_PAGE; 1698run = (arena_run_t *)((uintptr_t)chunk + (uintptr_t)((pageind - 1699arena_mapbits_small_runind_get(chunk, pageind)) << LG_PAGE)); 1700bin = run->bin; just watching run->bin luckily(?) shows up Hardware watchpoint 5: *$6 Old value = (arena_bin_t *) 0x2a800abc New value = (arena_bin_t *) 0x1 vn_nary_op_insert_pieces_predicated (length=2, code=GT_EXPR, type= , ops=0xbfbfe628, result=, value_id=0, pred_e= 443)>) at ../../trunk/gcc/tree-ssa-sccvn.c:3220 3220 return vn_nary_op_insert_into (vno1, valid_info->nary, true); (gdb) l 3215 vno1->u.values
[Bug gcov-profile/85871] g++.dg/gcov/gcov-8.C random failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85871 Christophe Lyon changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #9 from Christophe Lyon --- Problem still present: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00675.html
[Bug middle-end/12849] testing divisibility by constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12849 Bug 12849 depends on bug 82853, which changed state. Bug 82853 Summary: Optimize x % 3 == 0 without modulo https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #31 from Jakub Jelinek --- Fixed on the trunk. We might still try to improve some == non-zero cases with conditional code, and certainly should repeat this in the vectorizer's pattern recognizer.
[Bug tree-optimization/87287] Move signed (x % pow2) == 0 optimization to gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87287 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Done for trunk.
[Bug middle-end/87290] Optimize signed x % pow2p == cst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87290 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed on the trunk. We probably want to repeat this optimization in vectorizer pattern recognition though.
[Bug c++/87292] Warnings with Bit Fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87292
--- Comment #4 from Nuno Gonçalves ---
I found that the issue with enum have been extensively debated at #61414.
Sorry.
So actually this bug report is only regarding the warning with initializer
list:
struct{
uint8_t c1:6;
uint8_t c2:6;
} a;
auto c = {a.c1, a.c2}; //warning: narrowing conversion of '(unsigned
char)c1' from 'unsigned char' to 'unsigned char:6' [-Wnarrowing]
[Bug middle-end/87290] Optimize signed x % pow2p == cst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87290 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Thu Sep 13 07:42:55 2018 New Revision: 264261 URL: https://gcc.gnu.org/viewcvs?rev=264261=gcc=rev Log: PR middle-end/87290 * expr.c (maybe_optimize_pow2p_mod_cmp): New function. (maybe_optimize_mod_cmp): Use it if integer_pow2p treeop1. * gcc.target/i386/pr87290.c: New test. * gcc.c-torture/execute/pr87290.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr87290.c trunk/gcc/testsuite/gcc.target/i386/pr87290.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/87051] is_trivially_move_constructible wrongly gives `false` for class with user-provided non-const copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87051 --- Comment #2 from Ville Voutilainen --- Patch available: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00670.html
[Bug tree-optimization/87287] Move signed (x % pow2) == 0 optimization to gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87287 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Thu Sep 13 07:36:50 2018 New Revision: 264260 URL: https://gcc.gnu.org/viewcvs?rev=264260=gcc=rev Log: PR tree-optimization/87287 * fold-const.c (fold_binary_loc) : Move signed modulo X % C == 0 to X % (unsigned) C == 0 optimization to ... * match.pd (X % C == 0): ... here. New optimization. * gcc.dg/tree-ssa/pr87287.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr87287.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/87188] Function pointer canonicalization optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87188 --- Comment #24 from rguenther at suse dot de --- On Wed, 12 Sep 2018, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87188 > > --- Comment #23 from dave.anglin at bell dot net --- > On 2018-09-12 4:03 AM, rguenth at gcc dot gnu.org wrote: > > --- Comment #22 from Richard Biener --- > > (In reply to dave.anglin from comment #21) > >> On 2018-09-09 2:46 PM, rguenther at suse dot de wrote: > >>> In the last patch you replace arg0 || arg1 with arg0 & & arg1, that looks > >>> wrong. Otherwise the patch looks OK. > >> It was intentional. See the comment in dojump.c: > >> > >> /* If function pointers need to be "canonicalized" before they can > >> be reliably compared, then canonicalize them. > >> Only do this if*both* sides of the comparison are function > >> pointers. > >> If one side isn't, we want a noncanonicalized comparison. See PR > >> middle-end/17564. */ > >> if (targetm.have_canonicalize_funcptr_for_compare () > >> && POINTER_TYPE_P (TREE_TYPE (treeop0)) > >> && POINTER_TYPE_P (TREE_TYPE (treeop1)) > >> && FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (treeop0))) > >> && FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (treeop1 > >> > >> Based on this, I thought that we could allow do_store_flag to output a > >> "scc" instruction > >> when both sides weren't function or method pointers. > > Ah, I see. > Based on my testing, when we have a function or method pointer for one > of the operands, the other > operand is either a function, method or void pointer. An implicit cast > occurs if one compares a function > pointer to say an int or int*. Of course, a warning is generated in > that case. So, we want to canonicalize > when one of the operands is a function or method pointer. This > canonicalizes comparisons of a function > pointer and a void pointer. > > Attached is latest patch. LGTM.
[Bug c++/87292] Warnings with Bit Fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87292
--- Comment #3 from Nuno Gonçalves ---
Also to add, this could be suppressed if
enum class Bool : bool{False=0, True=1};
So a better example is for a 2 bit BitField:
enum class Nr : uint8_t{Zero=0, One=1, Two=2, Three=3};
struct{
Nr v:2;
} b;
[Bug c++/87292] Warnings with Bit Fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87292
--- Comment #2 from Nuno Gonçalves ---
Not the case since, same warning if:
enum class Bool : uint8_t {False=0, True=1}
[Bug c++/87292] Warnings with Bit Fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87292 --- Comment #1 from Andrew Pinski --- I think the second is correct but I dont know the exact rules about enum classes; are they unsigned by default? I know normal emuns are signed by default.
[Bug c++/87292] New: Warnings with Bit Fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87292
Bug ID: 87292
Summary: Warnings with Bit Fields
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nunojpg at gmail dot com
Target Milestone: ---
#include
#include
int main()
{
struct{
uint8_t c1:6;
uint8_t c2:6;
} a;
auto c = {a.c1, a.c2}; //warning: narrowing conversion of '(unsigned
char)c1' from 'unsigned char' to 'unsigned char:6' [-Wnarrowing]
enum class Bool{False=0, True=1};
struct{
Bool v:1; //warning: 'v' is too small to hold all values of 'enum class
main()::Bool'
} b;
return 0;
}
I get this 2 warnings with g++, including trunk, but not with clang++.
I believe the first case is a bug, c1 is promoted to uint8_t and then is
truncated back to uint8_t:6.
The second case I am not sure if the warning is reasonable. For example clang++
will also not warn if the enum class have values defined that do not fit, and
instead will only warn if it detects a assignment that causes truncation.
