[Bug ipa/87024] New: ICE in fold_stmt_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87024
Bug ID: 87024
Summary: ICE in fold_stmt_1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
gcc-9.0.0-alpha20180819 snapshot (r263652), as well as gcc 8.2, 7.3, 6.3, 5.4,
4.9.4, 4.8.5 all ICE when compiling the following snippet w/ -O1 (-O2, -O3,
-Ofast, -Os) -fno-tree-dce:
void
mp (void)
{
(void) __builtin_va_arg_pack_len ();
}
void
ui (void)
{
mp ();
}
% gcc-9.0.0-alpha20180819 -O1 -fno-tree-dce -c zypn5ily.c
during IPA pass: inline
zypn5ily.c: In function 'ui':
zypn5ily.c:8:1: internal compiler error: Segmentation fault
8 | ui (void)
| ^~
0xcb39cf crash_signal
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/toplev.c:325
0xa2b33b fold_stmt_1
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/gimple-fold.c:4634
0xd2a293 fold_marked_statements
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/tree-inline.c:4949
0xd376f2 optimize_inline_calls(tree_node*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/tree-inline.c:5030
0x15029fc inline_transform(cgraph_node*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/ipa-inline-transform.c:682
0xbd726f execute_one_ipa_transform_pass
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/passes.c:2188
0xbd726f execute_all_ipa_transforms()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/passes.c:2230
0x8cacba cgraph_node::expand()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/cgraphunit.c:2109
0x8cbd22 expand_all_functions
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/cgraphunit.c:2254
0x8cbd22 symbol_table::compile()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/cgraphunit.c:2605
0x8ce189 symbol_table::compile()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/cgraphunit.c:2517
0x8ce189 symbol_table::finalize_compilation_unit()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/cgraphunit.c:2698
% gcc-9.0.0-alpha20180819 -O2 -fno-tree-dce -c zypn5ily.c
during GIMPLE pass: einline
zypn5ily.c: In function 'ui':
zypn5ily.c:11:1: internal compiler error: Segmentation fault
11 | }
| ^
0xcb39cf crash_signal
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/toplev.c:325
0xa2b33b fold_stmt_1
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/gimple-fold.c:4634
0xd2a293 fold_marked_statements
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/tree-inline.c:4949
0xd376f2 optimize_inline_calls(tree_node*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/tree-inline.c:5030
0x14f8579 early_inliner(function*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/ipa-inline.c:2796
[Bug middle-end/86505] [6/7/8 Regression] __builtin_va_arg_pack_len() computes the number of arguments wrongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86505 --- Comment #7 from Arseny Solokha --- (In reply to Richard Biener from comment #6) > I wonder if the auto-regression police can help here increasing coverage? Here you are: PR87024.
[Bug tree-optimization/87025] New: [9 Regression] ICE in add_record, at optinfo-emit-json.cc:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87025
Bug ID: 87025
Summary: [9 Regression] ICE in add_record, at
optinfo-emit-json.cc:175
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: asolokha at gmx dot com
Target Milestone: ---
gcc-9.0.0-alpha20180819 snapshot (r263652) ICEs when compiling the following
snippet w/ -O1 -fsave-optimization-record -ftree-vectorize -fno-tree-scev-cprop
-fno-tree-sink:
void
fk (unsigned int sf)
{
for (;;)
{
if (sf != 0)
{
while (sf != 0)
++sf;
while (sf < 8)
++sf;
}
++sf;
}
}
% gcc-9.0.0-alpha20180819 -O1 -fsave-optimization-record -ftree-vectorize
-fno-tree-scev-cprop -fno-tree-sink -c hdtzb5rs.c
during GIMPLE pass: vect
hdtzb5rs.c: In function 'fk':
hdtzb5rs.c:2:1: internal compiler error: in add_record, at
optinfo-emit-json.cc:175
2 | fk (unsigned int sf)
| ^~
0x64094b optrecord_json_writer::add_record(json::object*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/optinfo-emit-json.cc:175
0xbc42e6 optrecord_json_writer::add_record(optinfo const*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/optinfo-emit-json.cc:156
0x90ba46 dump_context::end_any_optinfo()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/dumpfile.c:1120
0x90bae0 dump_context::begin_next_optinfo(dump_location_t const&)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/dumpfile.c:1107
0x90dd2e dump_context::begin_scope(char const*, dump_location_t const&)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/dumpfile.c:1070
0xf01591 auto_dump_scope::auto_dump_scope(char const*, dump_location_t)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/dumpfile.h:537
0xf01591 vect_analyze_loop(loop*, _loop_vec_info*, vec_info_shared*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/tree-vect-loop.c:2274
0xf1d763 try_vectorize_loop_1
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/tree-vectorizer.c:867
0xf1e591 vectorize_loops()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/tree-vectorizer.c:1075
[Bug target/87014] [x32] __builtin_eh_return should use 64-bit mov to set return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87014
--- Comment #5 from camper ---
test case (-O0):
using ll = long long;
void fillstack() {
ll foo[] = {
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
};
}
void f(ll=-1,ll=-1,ll=-1,ll=-1,ll=-1,ll=-1,ll arg7_on_stack=-1) {
throw 0;
}
void g() {
try {
f();
} catch(int) {
}
}
int main() {
fillstack();
g();
}
[Bug sanitizer/78651] Incorrect exception handling when catch clause uses local class and PIC and sanitizer are active
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78651 --- Comment #10 from chefmax at gcc dot gnu.org --- Seems to be closed on GCC 8 and 7, OK to close?
[Bug sanitizer/78651] Incorrect exception handling when catch clause uses local class and PIC and sanitizer are active
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78651 --- Comment #11 from chefmax at gcc dot gnu.org --- (In reply to chefmax from comment #10) > Seems to be closed on GCC 8 and 7, OK to close? s/closed/fixed/
[Bug target/87014] [x32] __builtin_eh_return should use 64-bit mov to set return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87014 Uroš Bizjak changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #6 from Uroš Bizjak --- Adding CC.
[Bug rtl-optimization/86107] [9 Regression] ICE: in ix86_mitigate_rop, at config/i386/i386.c:42301 with -O -funroll-loops -mavx5124fmaps -mmitigate-rop --param=hot-bb-frequency-fraction=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86107 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Uroš Bizjak --- -mmitigate-rop was deprecated in gcc-9.
[Bug target/87026] New: [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87026
Bug ID: 87026
Summary: [9 Regression] ICE in extract_constrain_insn_cached,
at recog.c:2218
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
gcc-9.0.0-alpha20180819 snapshot (r263652) ICEs when compiling the following
snippet w/ -O2 (-O3, -Ofast, -Os) -fno-if-conversion:
int jd;
int
uq (int u0)
{
goto al;
while (jd < 1)
{
jd = 0;
if (jd != 0)
{
al:
while (u0 != 0)
{
}
}
}
return 1 / u0;
}
% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20180819 -O2 -fno-if-conversion -c
sakw6h4j.c
sakw6h4j.c: In function 'uq':
sakw6h4j.c:22:1: error: insn does not satisfy its constraints:
22 | }
| ^
(insn 56 0 0 (set (reg:SI 121)
(const_int 0 [0])) 502 {*movsi_internal1}
(nil))
during RTL pass: ce3
sakw6h4j.c:22:1: internal compiler error: in extract_constrain_insn_cached, at
recog.c:2218
0x61a5f9 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/rtl-error.c:108
0x61a623 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/rtl-error.c:118
0x618be5 extract_constrain_insn_cached(rtx_insn*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/recog.c:2218
0x1209abf insn_default_length(rtx_insn*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/config/rs6000/rs6000.md:7058
0xffe417 rs6000_insn_cost
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/config/rs6000/rs6000.c:34085
0x98a774 canonicalize_comparison(machine_mode, rtx_code*, rtx_def**)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/expmed.c:6249
0xbc36f1 prepare_cmp_insn
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/optabs.c:3816
0xbc402e gen_cond_trap(rtx_code, rtx_def*, rtx_def*, rtx_def*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/optabs.c:5288
0x13febff find_cond_trap
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/ifcvt.c:4657
0x13febff find_if_header
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/ifcvt.c:4282
0x13febff if_convert
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/ifcvt.c:5405
0x140015d execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180819/work/gcc-9-20180819/gcc/ifcvt.c:5553
[Bug bootstrap/87013] Error: junk at end of line, first unrecognized character is `i'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87013
Jonathan Wakely changed:
What|Removed |Added
Target||sparc-linux
Status|UNCONFIRMED |WAITING
Last reconfirmed||2018-08-20
Summary|xgcc: fatal error: no input |Error: junk at end of line,
|files |first unrecognized
||character is `i'
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
> xgcc: error: unrecognized command line option '-qversion'; did you mean
> '--version'?
> xgcc: fatal error: no input files
That's not the problem, this error is supposed to happen, because your compiler
doesn't recognise the -qversion option.
> compilation terminated.
> configure:3458: $? = 1
> configure:3474: /media/gcc-8.2.0-compiled/./gcc/xgcc
> -B/media/gcc-8.2.0-compiled/./gcc/ -B/opt/gcc-8.2/sparc-linux/bin/
> -B/opt/gcc-8.2/sparc-linux/lib/ -isystem /opt/gcc-8.2/sparc-linux/include
> -isystem /opt/gcc-8.2/sparc-linux/sys-include-o conftest -g -O2
> conftest.c >&5
> /tmp/ccvuOEZf.s: Assembler messages:
> /tmp/ccvuOEZf.s:15: Error: junk at end of line, first unrecognized character
> is `i'
> configure:3477: $? = 1
> configure:3665: checking for suffix of object files
> configure:3687: /media/gcc-8.2.0-compiled/./gcc/xgcc
> -B/media/gcc-8.2.0-compiled/./gcc/ -B/opt/gcc-8.2/sparc-linux/bin/
> -B/opt/gcc-8.2/sparc-linux/lib/ -isystem /opt/gcc-8.2/sparc-linux/include
> -isystem /opt/gcc-8.2/sparc-linux/sys-include-c -g -O2 conftest.c >&5
> /tmp/ccookNLX.s: Assembler messages:
> /tmp/ccookNLX.s:15: Error: junk at end of line, first unrecognized character
> is `i'
This is the problem.
Try compiling the source below using the command above, adding -save-temps, and
then look at the resulting .s file. See why your assembler can't process it (do
you even have an assembler for your target?)
> configure:3691: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "GNU C Runtime Library"
> | #define PACKAGE_TARNAME "libgcc"
> | #define PACKAGE_VERSION "1.0"
> | #define PACKAGE_STRING "GNU C Runtime Library 1.0"
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
> | /* end confdefs.h. */
> |
> | int
> | main ()
> | {
> |
> | ;
> | return 0;
> | }
> configure:3705: error: in `/media/gcc-8.2.0-compiled/sparc-linux/libgcc':
> configure:3708: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.
[Bug c++/87015] [8 Regression] miscompilation of template heavy Boost Spirit code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-08-20 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to Daniel Starke from comment #0) > It is available here: https://sourceforge.net/projects/gcc-win64/files/8.2.0/ > > Due to the nature of the bug I am unable to provide a reduced test case > without an better idea of what the cause of the issue is. Compiling with -Og > or -O1 instead of -O2 did not change the behavior. As explained at https://gcc.gnu.org/bugs/ you still need to provide a preprocessed testcase, not a URL. It doesn't have to be reduced.
[Bug libstdc++/87027] New: lower_bound returns erroneous result, 32 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87027
Bug ID: 87027
Summary: lower_bound returns erroneous result, 32 bit
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lists at sagnix dot eu
Target Milestone: ---
The program below outputs 2:
/usr/bin/g++ -m32 -std=c++14 ex.cpp && ./a.out
Vector maximal size: 4294967295 and actual size: 2415919104
Found value 2
It should output 3 or throw std::length_error.
See also
https://stackoverflow.com/questions/51907247/lower-bound-algorithm-stl-usage-preconditions/51910011#51910011
// compile with -m32 switch
#include
#include
#include
#include
using namespace std;
int main() {
try {
vector v((1ULL << 28) * 9, 2); // 2.25 G entries
v.back() = 3; // the last of which is greater
cout<< "Vector maximal size: "<
[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413 --- Comment #27 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #26) > Paolo, do you remember if this testcase was specifically testing the zh_TW > locale, or just sing that as an example of a locale using wide characters? s/just sing/just using/
[Bug ipa/87024] ICE in fold_stmt_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87024
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-08-20
Ever confirmed|0 |1
--- Comment #1 from Martin Liška ---
Confirmed. We end up with:
EMERGENCY DUMP:
ui ()
{
:
= 0;
return;
}
[Bug c++/81830] missing Wunused-local-typedef on a typedef of an unnamed enum or struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81830
--- Comment #4 from Jonathan Wakely ---
For unnamed class and enumeration types the typedef is the name of the type for
linkage purposes, so it can be used even if it's never referred to e.g.
template void use(T) { }
void g (void)
{
typedef enum { e } F; // missing -Wunused-local-typedefs in C++
use(e);
}
The name 'F' is needed for the mangled name of use even though it's not used
directly in the source. So that's probably why G++ treats the typedef names as
used. Maybe it could be made smarter, so that if no name is needed for linkage
purposes, then it still warns.
[Bug c++/87017] vector must have the same value as its allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87017 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- (In reply to Peter VARGA from comment #0) > using smatch = std::match_results Allocator>; The value type of match_result is sub_match, so you need to use Allocator> not Allocator. > Changing it to std::smatch then it compiles. Because that uses the correct allocator type. > Compiler options: > -O3 -std=c++17 -Werror -Wextra -Wold-style-cast -Wall If you use -std=gnu++17 then your code will be accepted, but is not portable and is not valid C++.
[Bug c++/87017] vector must have the same value as its allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87017
--- Comment #2 from Jonathan Wakely ---
N.B. it only works with clang and ICC because you're using them with an older
version of libstdc++, which didn't enforce this requirement. Saying "it
compiles with three compilers all using the same standard library" is only one
data point.
If you use clang's own libc++ you get a similar error:
In file included from /opt/wandbox/clang-head/include/c++/v1/regex:770:
/opt/wandbox/clang-head/include/c++/v1/vector:486:5: error: static_assert
failed due to requirement 'is_same::value' "Allocator::value_type must be same type as value_type"
static_assert((is_same::value),
^
~~~
/opt/wandbox/clang-head/include/c++/v1/regex:5228:23: note: in instantiation of
template class
'std::__1::vector >,
FaF::Allocator > >' requested here
__container_type __matches_;
^
prog.cc:33:15: note: in instantiation of template class
'std::__1::match_results,
FaF::Allocator > >' requested here
FaF::smatch results {};
^
That's because the code is not valid according to the standard.
[Bug libstdc++/87020] comparison operator isn't called for stateless allocator without is_always_equal for C++11/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87020 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Jonathan Wakely --- The is_always_equal trait was invented in libstdc++ before it got into the standard, and if we didn't give the same behaviour for C++11 and C++14 there would be ODR violations. So this is not going to change. The trait was added to resolve a defect report about missing 'noexcept' on container member functions, so arguably it's needed to fix defects in C++11 and C++14 anyway.
[Bug libstdc++/87020] comparison operator isn't called for stateless allocator without is_always_equal for C++11/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87020 --- Comment #2 from Jonathan Wakely --- This property of the library is documented: https://gcc.gnu.org/onlinedocs/libstdc++/manual/bugs.html#manual.bugs.dr2108
[Bug c/87028] New: false positive -Wstringop-truncation strncpy with global variable source string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87028
Bug ID: 87028
Summary: false positive -Wstringop-truncation strncpy with
global variable source string
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anon63 at protonmail dot com
Target Milestone: ---
Hi,
Just builded latest gcc (GCC) 9.0.0 20180820 (experimental) commit 316828699
on Debian Linux 4.17.0-1-amd64 with gcc (Debian 8.2.0-3) 8.2.0 and ldd (Debian
GLIBC 2.27-5) 2.27
I know there are already several -Wstringop-truncation false positive related
threads but I'm not sure if this particular behaviour : emit warning when
source string is global variable and does not emit warning when source string
is local variable, has already been addressed.
GLOBAL VARIABLE SOURCE STRING => WARNING
$ cat a.c && gcc -O2 -Wall -Wextra -S a.c
char *strncpy (char *, const char *, __SIZE_TYPE__);
struct S {
char dest[5];
};
const char src[] = "1234567890";
void function(struct S *s)
{
strncpy(s->dest,src,sizeof(s->dest)-1);
s->dest[sizeof(s->dest)-1]='\0';
}
a.c: In function ‘function’:
a.c:12:5: warning: ‘strncpy’ output truncated copying 4 bytes from a string of
length 10 [-Wstringop-truncation]
strncpy(s->dest,src,sizeof(s->dest)-1);
^~
LOCAL VARIABLE SOURCE STRING => NO WARNING
$ cat a.c && gcc -O2 -Wall -Wextra -S a.c
char *strncpy (char *, const char *, __SIZE_TYPE__);
struct S {
char dest[5];
};
void function(struct S *s)
{
const char src[] = "1234567890";
strncpy(s->dest,src,sizeof(s->dest)-1);
s->dest[sizeof(s->dest)-1]='\0';
}
CONSTANT SOURCE STRING => WARNING
$ cat a.c && gcc -O2 -Wall -Wextra -S a.c
char *strncpy (char *, const char *, __SIZE_TYPE__);
struct S {
char dest[5];
};
void function(struct S *s)
{
strncpy(s->dest,"1234567890",sizeof(s->dest)-1);
s->dest[sizeof(s->dest)-1]='\0';
}
a.c: In function ‘function’:
a.c:11:5: warning: ‘strncpy’ output truncated copying 4 bytes from a string of
length 10 [-Wstringop-truncation]
11 | strncpy(s->dest,"1234567890",sizeof(s->dest)-1);
This last case, constant source string, seems to be duplicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84474 but I would like to know if
there are any news/recommendations about this problem.
Lots of codebases can't be compiled with -Werror flag now.
I see lots of people, mechanically changing strncpy for memcpy. Other people do
the transformation strncpy of size n => strncpy of size n-1 + '\0' at index
n-1. Without success for me in the "global variable" case.
What would be the recommended way with the examples above ?
Cheers,
A.
[Bug c++/52801] improve selective typedef unwrapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52801
Jonathan Wakely changed:
What|Removed |Added
Keywords|error-recovery |
CC|redi at gcc dot gnu.org|
--- Comment #4 from Jonathan Wakely ---
The only real difference between Clang and G++ here is that Clang preserves the
vector type in the output, but G++ shows vector.
GCC's first line shows the
52801.cc:9:8: error: no match for ‘operator=’ (operand types are
‘std::__cxx11::string {aka std::__cxx11::basic_string}’ and
‘std::vector’)
This uses "aka" to relate the type shown in the source (which might be a
typedef) with the canonical types shown in the later errors. If that first line
said "'vector' {aka 'std::vector'}" I think it would be fine.
The fact the typedef is preserved for the string but not the vector may be
because the string is declared using a typedef ("string") but the vector is not
("Real" is a typedef, but "vector" is not).
Some of the other differences are due to comparing apples with oranges:
- Several more lines in GCC output, because the clang test was done with
-std=gnu++98 and the GCC one with -std=gnu++14, so there are extra overloads in
the GCC version. Clang also prints more lines for recent standards.
- Clang shows std::basic_string and gcc shows
std::__cxx11::basic_string, but only because the clang test was using GCC
4.3 headers. Using libc++ headers shows std::__1::basic_string which is
no better. N.B. GCC would be improved by PR 81239, so that the first line would
show "std::string {aka 'std::__cxx11::basic_string'}". I might even be able to
make that happen with a libstdc++ change.
[Bug libstdc++/78448] Container max_size() functions don't consider the range of their difference_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78448 Jonathan Wakely changed: What|Removed |Added CC||lists at sagnix dot eu --- Comment #1 from Jonathan Wakely --- *** Bug 87027 has been marked as a duplicate of this bug. ***
[Bug libstdc++/87027] lower_bound returns erroneous result, 32 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87027 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- This is the problem I reported as PR 78448 *** This bug has been marked as a duplicate of bug 78448 ***
[Bug libstdc++/78448] Container max_size() functions don't consider the range of their difference_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78448
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-08-20
Ever confirmed|0 |1
--- Comment #2 from Jonathan Wakely ---
Testcase from PR 87027:
The program below outputs 2:
/usr/bin/g++ -m32 -std=c++14 ex.cpp && ./a.out
Vector maximal size: 4294967295 and actual size: 2415919104
Found value 2
It should output 3 or throw std::length_error.
See also
https://stackoverflow.com/questions/51907247/lower-bound-algorithm-stl-usage-preconditions/51910011#51910011
// compile with -m32 switch
#include
#include
#include
#include
using namespace std;
int main() {
try {
vector v((1ULL << 28) * 9, 2); // 2.25 G entries
v.back() = 3; // the last of which is greater
cout<< "Vector maximal size: "<
[Bug libstdc++/78448] Container max_size() functions don't consider the range of their difference_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78448 --- Comment #3 from Jonathan Wakely --- UBsan shows where the overflows happen: /home/jwakely/gcc/9/include/c++/9.0.0/bits/stl_vector.h:359:59: runtime error: pointer index expression with base 0x6760f010 overflowed to 0xf760f010 /home/jwakely/gcc/9/include/c++/9.0.0/bits/stl_algobase.h:777:20: runtime error: pointer index expression with base 0x6760f010 overflowed to 0xf760f010 /home/jwakely/gcc/9/include/c++/9.0.0/bits/stl_algobase.h:778:24: runtime error: pointer index expression with base 0x6760f010 overflowed to 0xf760f010 Vector maximal size: 4294967295 and actual size: 2415919104 Found value 2 We just need to fix our max_size() as per comment 0.
[Bug c++/87017] vector must have the same value as its allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87017 Peter VARGA changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #3 from Peter VARGA --- Jonathan, I thank you very much for your clear and simple explanation. I have fixed it now as you suggested according to the standard!
[Bug c++/87016] std::optional::operator= in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87016 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- The code is valid. The optional::operator=(U&&) assignment operator is not used when is_scalar and is_same> (which is true here, where T=int and U=int). That means the assignment creates a temporary optional using the constexpr constructor, i.e. bar = std::optional(10); This is valid in a constexpr function.
[Bug c++/87017] vector must have the same value as its allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87017 Jonathan Wakely changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #4 from Jonathan Wakely --- Changing status back. FIXED means GCC was fixed, but GCC doesn't need fixing. https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#bug_status
[Bug target/87026] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87026 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-20 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Confirmed (also on 64-bit, etc.)
[Bug fortran/87019] ICE: Static member of derived type, organized in coarray accessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87019 --- Comment #1 from Alexander Lehmann --- I found out that this bug was encounter in the following forum as well: https://github.com/szaghi/HASTY/issues/6 and then opened in this case: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78682 But unfortunately the ICE still persists in the current version of gfortran.
[Bug c++/87016] std::optional::operator= in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87016 --- Comment #2 from bobogu at atlas dot cz --- Do I understand it correctly that this will get optimized into one statement saying bar = std::optional(10); If so, is there something that could prevent such optimizations in order to check if the code is portable? Also, just to clarify, this has nothing to do with this proposal http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0602r3.html to which someone has pointed me to?
[Bug c++/87016] std::optional::operator= in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87016 --- Comment #3 from Jonathan Wakely --- (In reply to bobogu from comment #2) > Do I understand it correctly that this will get optimized into one statement > saying > > bar = std::optional(10); No, it's not an optimization. When you assign an int to optional it is equivalent to constructing a temporary optional and then assigning that to the left-hand operand. > If so, is there something that could prevent such optimizations in order to > check if the code is portable? It's not an optimization, it's the required behaviour according the the specification of std::optional in the standard. > Also, just to clarify, this has nothing to do with this proposal > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0602r3.html to > which someone has pointed me to? It's nothing to do with that.
[Bug c++/87016] std::optional::operator= in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87016 --- Comment #4 from bobogu at atlas dot cz --- (In reply to Jonathan Wakely from comment #3) > (In reply to bobogu from comment #2) > When you assign an int to optional it is equivalent to constructing a > temporary optional and then assigning that to the left-hand operand. I feel stupid, but I still don't understand how that can work in a constexpr context when the current c++17 standard doesn't specify any constexpr assignment operator. The second line of this snippet std::optional bar = 3; bar = std::optional(10); would call the 3rd assignment operator (https://en.cppreference.com/w/cpp/utility/optional/operator%3D), right? And the operator isn't constexpr, but works in a constexpr function.
[Bug bootstrap/87018] [9 Regression] Boostrap failure on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87018 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool --- I always use --disable-nls on AIX (and on other systems where NLS causes problems). I don't know if there is a bug here (and where), or if this is user error; but that will avoid all such problems.
[Bug fortran/80931] ICE on move_alloc in gimplify_expr, at gimplify.c:11335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80931 --- Comment #8 from Arjen Markus --- Thank you! I do appreciate such comments - apart from the fun it was to write the book and experiment with all the features of Fortran, it is great to hear that other people enjoy it too. Regards, Arjen 2018-08-17 23:06 GMT+02:00 snowfed at mail dot ru : > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80931 > > --- Comment #7 from snowfed --- > Wow! Read your book with great pleasure! (the Russian translation of it) > > (In reply to Arjen Markus from comment #6) >> Yes, I am :). >> >> Regards, >> >> Arjen >> > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/87016] std::optional::operator= in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87016 --- Comment #5 from Jonathan Wakely --- (In reply to bobogu from comment #4) > I feel stupid, but I still don't understand how that can work in a constexpr > context when the current c++17 standard doesn't specify any constexpr > assignment operator. That's true, but the standard is broken. All implementations define the assignment operator as defaulted, and so the compiler makes it constexpr. In fact the p0602R3 proposal you linked to is relevant, because it would *require* implementations to define the operator as defaulted (in order to be trivial) and so the compiler is always going to make it constexpr for std::optional. Anyway, I don't consider "I can use more things in constant expressions than the standard says" to be a bug.
[Bug libstdc++/86963] std::tuple incorrectly assigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86963 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Mon Aug 20 13:53:56 2018 New Revision: 263661 URL: https://gcc.gnu.org/viewcvs?rev=263661&root=gcc&view=rev Log: PR libstdc++/86963 Remove use of __tuple_base in std::tuple The _Tuple_impl base class can be used to disable copy/move assignment, without requiring an extra base class. Exception specifications on std::tuple assignment and swap functions can be defined directly using is_nothrow_swappable, instead of querying the base classes. PR libstdc++/86963 * include/std/tuple (_Tuple_impl::operator=): Define as deleted. (_Tuple_impl::_M_assign): New functions to perform assignment instead of assignment operators. (_Tuple_impl::_M_swap): Remove exception specification. (_Tuple_impl<_Idx, _Head>): Likewise. (_TC::_NonNestedTuple, _TC::_NotSameTuple): Use __remove_cvref_t. (__tuple_base): Remove. (tuple, tuple<_T1, _T2>): Remove inheritance from __tuple_base. (tuple::operator=, tuple<_T1, _T2>::operator=): Call _M_assign. (tuple::swap, tuple<_T1, _T2>::swap): Define exception specification using __is_nothrow_swappable. (tuple<_T1, _T2>::tuple(_U1&&, _U2&&)): Use __remove_cvref_t. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/tuple
[Bug fortran/87019] ICE: Static member of derived type, organized in coarray accessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87019 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-20 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Duplicate of pr77871?
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 nsz at gcc dot gnu.org changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #10 from nsz at gcc dot gnu.org --- Created attachment 44561 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44561&action=edit good rtl dump of combine pass
[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655 --- Comment #6 from Richard Biener --- Author: rguenth Date: Mon Aug 20 14:01:05 2018 New Revision: 263662 URL: https://gcc.gnu.org/viewcvs?rev=263662&root=gcc&view=rev Log: 2018-08-20 Richard Biener PR tree-optimization/78655 * tree-vrp.c (extract_range_from_binary_expr_1): Make pointer + offset nonnull if either operand is nonnull work. * gcc.dg/tree-ssa/evrp11.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/evrp11.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655 --- Comment #7 from Richard Biener --- Note the original testcase is already optimized with GCC 8 due to the fix for PR35878 and enabling it for all standard modes.
[Bug c++/87016] std::optional::operator= in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87016 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > In fact the p0602R3 proposal you linked to is relevant, because it would > *require* implementations to define the operator as defaulted (in order to > be trivial) and so the compiler is always going to make it constexpr for > std::optional. I've raised this with the standards committee.
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 --- Comment #11 from nsz at gcc dot gnu.org --- Created attachment 44562 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44562&action=edit bad rtl dump of combine pass attached good and bad dump of combine, i also tried to look at the array contents, it seems to go from (good): hello hola! goddag to (bad): goddo hola! goddag in the last option_stopwatch_a call in main (even though the array 'a' seems to be 'hello' before the call).
[Bug c++/87029] New: Add -Wredundant-move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87029
Bug ID: 87029
Summary: Add -Wredundant-move
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
Similarly to 86981, we could also warn here about the redundant (but not
pessimizing) move here:
#include
struct S { };
S
foo (S s)
{
return std::move (s);
}
the compiler will try a move operation regardless the std::move (if the move
ctor is present and accessible).
Unless the parameter is const, of course.
[Bug c++/87029] Add -Wredundant-move warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87029 Marek Polacek changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-08-20 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Summary|Add -Wredundant-move|Add -Wredundant-move ||warning Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- This should be a fairly easy extension of -Wpessimizing-move.
[Bug target/86984] invalid relocation accessing a const char arrray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86984 --- Comment #3 from Jeffrey A. Law --- Author: law Date: Mon Aug 20 14:20:59 2018 New Revision: 263664 URL: https://gcc.gnu.org/viewcvs?rev=263664&root=gcc&view=rev Log: PR target/86984 * expr.c (expand_assignment): Assert that bitpos is positive. (store_field): Likewise (expand_expr_real_1): Make sure that bitpos is positive. * config/alpha/alpha.h (CONSTANT_ADDRESS_P): Avoid signed integer overflow. PR target/86984 * gcc.target/alpha/pr86984.c: New test. Added: trunk/gcc/testsuite/gcc.target/alpha/pr86984.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/alpha.h trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/87030] New: GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 Bug ID: 87030 Summary: GCC fails to build with Xcode 10, attempting an impossible multilib build Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org Target Milestone: --- Building with Xcode 10 (beta) on macOS 10.13 or 10.14 (beta), leads to a build failure because by default, configure sets GCC up for a multilib build. However, starting with Xcode 10, Apple has removed support for 32-bit: thus, the builds fails when trying to link libgcc, because it does not find the 32-bit system libc. Passing --disable-multilib fixes bootstrap. However, the default configure should detect that 32-bit is not supported and automatically build without 32-bit multilib.
[Bug target/87026] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87026 Segher Boessenkool changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #2 from Segher Boessenkool --- This is caused by r263591 (of a few days ago).
[Bug c++/87016] std::optional::operator= in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87016 --- Comment #7 from bobogu at atlas dot cz --- (In reply to Jonathan Wakely from comment #5) > (In reply to bobogu from comment #4) > All implementations define the assignment operator as defaulted, and so the > compiler makes it constexpr. > > In fact the p0602R3 proposal you linked to is relevant, because it would > *require* implementations to define the operator as defaulted (in order to > be trivial) and so the compiler is always going to make it constexpr for > std::optional. Ah, finally it makes sense to me! > Anyway, I don't consider "I can use more things in constant expressions than > the standard says" to be a bug. All right, I'm sorry then... I just thought that as this is undocumented, it could lead to producing an unportable code. Anyway, thank you for clearing it out. > I've raised this with the standards committee. Thanks!
[Bug target/87026] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87026 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #3 from Segher Boessenkool --- I have a patch.
[Bug c++/87015] [8 Regression] miscompilation of template heavy Boost Spirit code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015 --- Comment #2 from Daniel Starke --- I am not quite sure how to do this in this case. GCC terminates without an error but the resulting application misbehaves since GCC 8.1.0. That means the assembly output is wrong. Any idea on how to make a reproducable test case that matches the bug reporting guidelines and works for my issue is welcome.
[Bug target/86984] invalid relocation accessing a const char arrray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86984 Eric Botcazou changed: What|Removed |Added CC||slyfox at inbox dot ru --- Comment #4 from Eric Botcazou --- *** Bug 84184 has been marked as a duplicate of this bug. ***
[Bug middle-end/84184] gcc generates wrong relocations with negative offsets in struct arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #13 from Eric Botcazou --- . *** This bug has been marked as a duplicate of bug 86984 ***
[Bug c++/87016] std::optional::operator= in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87016 --- Comment #8 from Jonathan Wakely --- (In reply to bobogu from comment #7) > All right, I'm sorry then... I just thought that as this is undocumented, it > could lead to producing an unportable code. It could, except that you should get the same behaviour for every correct implementation. Your example doesn't compile with libc++, but that's a bug: https://bugs.llvm.org/show_bug.cgi?id=38638
[Bug fortran/87019] ICE: Static member of derived type, organized in coarray accessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87019 Alexander Lehmann changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Alexander Lehmann --- True, that looks very similar though it is already two years old an still marked as "NEW". I marked mine as duplicate, now, but hope that this issue will be resolved in near future. Unfortunately, this issue hinders the use of the combination of derived types and co-arrays which would help making code look clean. *** This bug has been marked as a duplicate of bug 77871 ***
[Bug fortran/77871] [6/7/8/9 Regression] [Coarray] [OOP] ICE in gfc_get_caf_token_offset, at fortran/trans-expr.c:1981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77871 Alexander Lehmann changed: What|Removed |Added CC||welttensor at web dot de --- Comment #4 from Alexander Lehmann --- *** Bug 87019 has been marked as a duplicate of this bug. ***
[Bug c++/87016] std::optional::operator= in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87016 --- Comment #9 from bobogu at atlas dot cz --- (In reply to Jonathan Wakely from comment #8) > (In reply to bobogu from comment #7) > > All right, I'm sorry then... I just thought that as this is undocumented, it > > could lead to producing an unportable code. > > It could, except that you should get the same behaviour for every correct > implementation. Your example doesn't compile with libc++, but that's a bug: > https://bugs.llvm.org/show_bug.cgi?id=38638 Yes, that was just my misconception before you got me on the right track - I thought clang's behaviour was correct because of what I saw in the standard :-)
[Bug jit/87003] use nonnull attribute in libgccjit.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87003 --- Comment #1 from David Malcolm --- It would be good to make the header file be more self-documenting. In general, every pointer argument ought to be non-NULL, but a NULL will be checked for and gracefully rejected. The exception is gcc_jit_location *, which can always be NULL. libgccjit performs error-checking at the API boundary: there are many places where a NULL pointer argument will lead to a failure that puts the context into an "invalid" state, but such a failure will be handled gracefully without segfaulting: https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#error-handling This means that e.g. C code calling into the API doesn't need to check everywhere for NULL results before passing them back in as arguments to followup calls; it can just check once at the end of populating a context. (FWIW, I notice that the Rust bindings don't do error-handling yet: https://github.com/swgillespie/gccjit.rs#error-handling ) The docs for attribute "nonnull": https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Common-Function-Attributes.html#Common-Function-Attributes say it: > "...causes the compiler to check that [...] arguments [...] are > non-null. If the compiler determines that a null pointer is passed > in an argument slot marked as non-null, and the -Wnonnull option is > enabled, a warning is issued. The compiler may also choose to make > optimizations based on the knowledge that certain function arguments > will never be null" That last sentence about optimizations makes me a little wary: it *is* possible for such arguments to be NULL (and my test cases make use of this to verify that the API does indeed gracefully handle these errors). But it does seem useful to mark all those arguments, and potentially warn for obvious "NULL in the wrong places" typos. Thoughts?
[Bug target/87031] New: nios2 optimization for size - two cases of regression relatively to 5.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87031
Bug ID: 87031
Summary: nios2 optimization for size - two cases of regression
relatively to 5.3.0
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: already5chosen at yahoo dot com
Target Milestone: ---
Created attachment 44563
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44563&action=edit
first case - shifts instead of mulx
Here are two cases of significant regression in optimization for size between
5.3.0 (a version supplied in Altera Nios2 SDK) and 8.2.0.
Both cases compiled with -Wall -Os -ffreestanding -fbuiltin -mhw-div -mhw-mul
-mhw-mulx
It looks like in the first case -Os flag caused to compiler to forget that
hw-mulx is present.
The the second case, in addition to the same problem as in the first case,
compiler decided to unroll the loop. An exact opposite of what one expects from
'-s'.
I checked if the problems appear with similar back ends ('riscv -mabi=ilp32
-march=rv32im' and 'mips -mabi=32 -mips32r6 -mcompact-branches=always').
The first problem (shifts instead of mulx) appear unique to nios2. The second
problem (unrolling) shows up on all three architectures.
[Bug target/87031] nios2 optimization for size - two cases of regression relatively to 5.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87031 --- Comment #1 from Michael_S --- Created attachment 44564 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44564&action=edit second case - loop unrolled
[Bug c/87028] false positive -Wstringop-truncation strncpy with global variable source string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87028 Martin Sebor changed: What|Removed |Added Keywords||diagnostic CC||msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor --- This is the same issue as pr84474. The warning in all these cases is by design. There is an (undocumented) suppression mechanism in GCC to avoid warning for instances of calls that are followed by the nul assignment. The suppression works in the second example when GCC sees the nul assignment but not in the first or last one where the warning triggers before access to the subsequent statement is available. In both of these, the strncpy call is transformed early on to memcpy (the warning is issued just before this transformation) so avoiding the diagnostic in these cases would prevent diagnosing instances where the nul isn't stored next. In effect, it's a tradeoff between false positives and false negatives, forced by the early transformation. IMO, the early folding of strncpy to memcpy is unhelpful (it causes false negatives in buffer overflow detection) and should be done later, but so far I haven't been successful at convincing others to defer it.
[Bug c/87028] false positive -Wstringop-truncation strncpy with global variable source string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87028 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-20 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84474 Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- The test case here is more compelling than the one in bug 84474 and I agree that it would be helpful to avoid the warning, although not at the expense of true positives. Short of deferring the strncpy -> memcpy folding I don't see a way to do it. Let me confirm this report with the hope that GCC can change to do the folding later.
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #12 from nsz at gcc dot gnu.org ---
the wrong string seems to be caused by a missing ldm
good main:
...
mov r4, #0
str r4, [sp, #32]
mov r2, #2
str r2, [sp, #36]
add r2, sp, #40
str r2, [sp, #4]
str r4, [sp, #8]
ldm ip, {r0, r1}/// load r0 (content is 'hell')
str r0, [sp, #40] /// store the right r0
strhr1, [sp, #44] @ movhi
ldr r2, [sp, #66] @ unaligned
str r2, [sp, #46] @ unaligned
ldrhr2, [sp, #70] @ unaligned
strhr2, [sp, #50] @ unaligned
add r2, sp, #72
ldm r2, {r0, r1}
str r0, [sp, #52]
strhr1, [sp, #56] @ movhi
mov r1, r3
add r0, sp, #4
bl option_stopwatch_a.5061
bad main:
...
mov r4, #0
str r4, [sp, #32]
mov r2, #2
str r2, [sp, #36]
add r2, sp, #40
str r2, [sp, #4]
str r4, [sp, #8]
ldr r1, [sp, #64]
str r0, [sp, #40] /// store a bad r0 (content is 'godd')
strhr1, [sp, #44] @ movhi
ldr r2, [sp, #66] @ unaligned
str r2, [sp, #46] @ unaligned
ldrhr2, [sp, #70] @ unaligned
strhr2, [sp, #50] @ unaligned
ldr r1, [sp, #76]
str r0, [sp, #52]
strhr1, [sp, #56] @ movhi
mov r1, r3
add r0, sp, #4
bl option_stopwatch_a.5061
[Bug c++/87032] New: incorrect nested structure with union initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87032
Bug ID: 87032
Summary: incorrect nested structure with union initialization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vadim at sukhomlinov dot co
Target Milestone: ---
For the code:
/**/
struct f1 {int x,y;};
struct f2 {int x,y,z,t;};
struct T {
const char * name;
union {
struct f1 fn1;
struct f2 fn2;
} d;
};
extern "C" void p(struct T);
int main(){
p({"%x",{.fn2={1,2,3,4}}});
}
/**/
gcc 7.3 generates:
: In function 'int main()':
:15:26: internal compiler error: in reshape_init_class, at
cp/decl.c:5802
p({"%x",{.fn2={1,2,3,4}}});
^
mmap: Invalid argument
gcc 8.1/8.2:
: In function 'int main()':
:15:26: error: could not convert '{"%x", {{1, 2, 3, 4}}}' from
'' to 'T'
p({"%x",{.fn2={1,2,3,4}}});
^
Compiler returned: 1
At the same time Clang starting 3.1 and higher generates valid code.
Testing done using https://godbolt.org/
[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
--- Comment #8 from Marc Glisse ---
(just to put this somewhere)
We have multiple ways of doing pointer arithmetic in gcc. After the recent
patch, we know that g returns nonnull, but we don't know it for f.
struct A{int a,b;};
int*f(A*p){return&p->b;}
int*g(A*p){return(int*)p+1;}
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-08-20
CC||wilco at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #13 from Wilco ---
(In reply to nsz from comment #12)
> the wrong string seems to be caused by a missing ldm
Yes what happens is that it decides to combine instruction 150 and 190 and
split an ldm2:
insn_cost 4 for 150: r197:SI=sfp:SI-0x24
...
insn_cost 0 for 190: {r0:SI=[r197:SI];r1:SI=[r197:SI+0x4];}
allowing combination of insns 150 and 190
original costs 4 + 0 = 0
replacement costs 8 + 8 = 16
modifying insn i2 150: r0:SI=[sfp:SI-0x24]
deferring rescan insn with uid = 150.
modifying insn i3 190: r1:SI=[sfp:SI-0x20]
deferring rescan insn with uid = 190.
There are lots of instructions between 150 and 190, including another ldm2
which writes r0:
150: r0:SI=[sfp:SI-0x24]
...
163: {r0:SI=[r206:SI];r1:SI=[r206:SI+0x4];}
...
190: r1:SI=[sfp:SI-0x20]
The combination ends up corrupting r0 because one of the loads is lifted across
many instructions without checking liveness. It seems the safest way to split
an instruction is to place the new instructions next to each other.
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 --- Comment #14 from Wilco --- Note there is also an issue with costs, if the cost is zero then it seems to behave like infinite cost. It would be better to properly cost an instruction sequence given there is a new interface for this now. If the cost is still zero, it could get the default cost rather than being treated like infinite cost, resulting in non-optimal replacements.
[Bug bootstrap/87013] Error: junk at end of line, first unrecognized character is `i'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87013 --- Comment #2 from martin --- Created attachment 44565 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44565&action=edit conftest.s Attached is the generated conftest.s file of the command > /media/gcc-8.2.0-compiled/./gcc/xgcc -B/media/gcc-8.2.0-compiled/./gcc/ > -B/opt/gcc-8.2/sparc-linux/bin/ -B/opt/gcc-8.2/sparc-linux/lib/ -isystem > /opt/gcc-8.2/sparc-linux/include -isystem > /opt/gcc-8.2/sparc-linux/sys-include-c -g -O2 -save-temps conftest.c I'm afraid I don't have any assembler tools installed (Only the gcc 7.2 enviroment for C and C++) Let me know, if you need more information.
[Bug target/87014] [x32] __builtin_eh_return should use 64-bit mov to set return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87014 --- Comment #7 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Aug 20 19:14:04 2018 New Revision: 263672 URL: https://gcc.gnu.org/viewcvs?rev=263672&root=gcc&view=rev Log: x86: Always update EH return address in word_mode On x86, return address is always popped in word_mode. eh_return needs to put EH return address in word_mode on stack. gcc/ PR target/87014 * config/i386/i386.md (eh_return): Always update EH return address in word_mode. gcc/testsuite/ PR target/87014 * g++.dg/torture/pr87014.C: New file. Added: trunk/gcc/testsuite/g++.dg/torture/pr87014.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug c++/87029] Add -Wredundant-move warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87029 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86981, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=67906, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81159 --- Comment #2 from Eric Gallager --- See also: bug 67906 and bug 81159
[Bug c++/49974] missing warning for indirectly returning reference to local/temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=986, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=52901 --- Comment #10 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #1) > Isn't this related to PR986? (In reply to Jonathan Wakely from comment #2) > Maybe related, but not the same. So still worth putting under "See Also" then.
[Bug c++/49974] missing warning for indirectly returning reference to local/temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=86982
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> As pointed out in PR 52901 comment 3, this missing warning is likely to bite
> people misusing std::move like so:
>
> X&& f()
> {
> X x;
> return std::move(x);
> }
I created PR 86982 for the special cases of std::move and std::forward, as I
think they're important.
This bug is for the more general case.
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 Eric Gallager changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-08/msg01104.ht ||ml CC||iains at gcc dot gnu.org --- Comment #14 from Eric Gallager --- (In reply to Eric Gallager from comment #13) > gcc-ar, gcc-nm, and gcc-ranlib all fail for me when passed --help or > --version like this: > > /usr/local/bin/gcc-ranlib: Cannot find plugin 'liblto_plugin.so' > > IMO the --help or --version output should be printed before looking for the > plugin. Iain Sandoe has a patch for this: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01104.html
[Bug target/87033] New: The compiler does not generate the LWAX instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87033 Bug ID: 87033 Summary: The compiler does not generate the LWAX instruction Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- Created attachment 44566 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44566&action=edit Simple test case to show the bug The compiler does not generate LWAX instruction to load up a 32-bit integer value and sign extend it to 64-bits. This is due to the constraint for extendsi2 for the LWA being just 'Y' (offset addressing using DS mode instruction format) and it should be 'YZ'.
[Bug target/87033] The compiler does not generate the LWAX instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87033 Michael Meissner changed: What|Removed |Added Target||powerpc64-linux-gnu-*, ||powerpc64le-linux-gnu-* CC||dje at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Host||powerpc64-linux-gnu-*, ||powerpc64le-linux-gnu-* Build||powerpc64-linux-gnu-*, ||powerpc64le-linux-gnu-* --- Comment #1 from Michael Meissner --- It looks like GCC 8 and GCC 7 are probably not generating LWAX also.
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 --- Comment #15 from Segher Boessenkool --- (In reply to Wilco from comment #13) > It seems the safest way > to split an instruction is to place the new instructions next to each other. combine can only place new insns at i2 and i3, in either order. There is code to figure out which way (if any) works; apparently it doesn't work here.
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 --- Comment #16 from Segher Boessenkool --- (In reply to Wilco from comment #14) > Note there is also an issue with costs, if the cost is zero then it seems to > behave like infinite cost. 0 means unknown cost. Any known cost is treated as at least as good as unknown cost. > It would be better to properly cost an > instruction sequence given there is a new interface for this now. Yup. > If the > cost is still zero, it could get the default cost rather than being treated > like infinite cost, resulting in non-optimal replacements. Treating unknown cost as minimal cost is still non-optimal. It might work better for your case of course. But it means for example that combine will modify parallels less often.
[Bug other/84889] Ideas on revamping how we format diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889
--- Comment #11 from David Malcolm ---
Author: dmalcolm
Date: Mon Aug 20 21:06:46 2018
New Revision: 263675
URL: https://gcc.gnu.org/viewcvs?rev=263675&root=gcc&view=rev
Log:
Add support for grouping of related diagnostics (PR other/84889)
We often emit logically-related groups of diagnostics.
A relatively simple case is this:
if (warning_at (body_loc, OPT_Wmultistatement_macros,
"macro expands to multiple statements"))
inform (guard_loc, "some parts of macro expansion are not guarded by "
"this %qs clause", guard_tinfo_to_string (keyword));
where the "note" diagnostic issued by the "inform" call
is guarded by the -Wmultistatement_macros warning.
More complicated examples can be seen in the C++ frontend,
where e.g. print_z_candidates can lead to numerous "note"
diagnostics being emitted.
I'm looking at various ways to improve how we handle such related
diagnostics, but, prior to this patch, there was no explicit
relationship between these diagnostics: the diagnostics subsystem
had no way of "knowing" that these were related.
This patch introduces a simple way to group the diagnostics:
an auto_diagnostic_group class: all diagnostics emitted within
the lifetime of an auto_diagnostic_group instance are logically
grouped.
Hence in the above example, the two diagnostics can be grouped
by simply adding an auto_diagnostic_group instance:
auto_diagnostic_group d;
if (warning_at (body_loc, OPT_Wmultistatement_macros,
"macro expands to multiple statements"))
inform (guard_loc, "some parts of macro expansion are not guarded by "
"this %qs clause", guard_tinfo_to_string (keyword));
Some more awkard cases are of the form:
if (some_condition
&& warning_at (...)
&& more_conditions)
inform (...);
which thus need restructuring to:
if (some_condition)
{
auto_diagnostic_group d;
warning_at (...);
if (more_conditions)
inform (...);
}
so that the lifetime of the auto_diagnostic_group groups the
warning_at and the inform call.
Nesting is handled by simply tracking a nesting depth within the
diagnostic_context.: all diagnostics are treated as grouped until the
final auto_diagnostic_group is popped.
diagnostic.c uses this internally, so that all diagnostics are part of
a group - those that are "by themselves" are treated as being part of
a group with one element.
The diagnostic_context gains optional callbacks for displaying the
start of a group (when the first diagnostic is emitted within it), and
the end of a group (for when the group was non-empty); these callbacks
are unused by default, but a test plugin demonstrates them (and verifies
that the machinery is working).
As noted above, I'm looking at various ways to use the grouping to
improve how we output the diagnostics.
FWIW, I experimented with a more involved implementation, of the form:
diagnostic_group d;
if (d.warning_at (body_loc, OPT_Wmultistatement_macros,
"macro expands to multiple statements"))
d.inform (guard_loc, "some parts of macro expansion are not guarded by "
"this %qs clause", guard_tinfo_to_string (keyword));
which had the advantage of allowing auto-detection of the places where
groups were needed (by converting ::warning_at's return type to bool),
but it was a much more invasive patch, especially when dealing with
the places in the C++ frontend that can emit numerous notes after
an error or warning (and thus having to pass the group around)
Hence I went with this simpler approach.
gcc/c-family/ChangeLog:
PR other/84889
* c-attribs.c (common_handle_aligned_attribute): Add
auto_diagnostic_group instance.
* c-indentation.c (warn_for_misleading_indentation): Likewise.
* c-opts.c (c_common_post_options): Likewise.
* c-warn.c (warn_logical_not_parentheses): Likewise.
(warn_duplicated_cond_add_or_warn): Likewise.
(warn_for_multistatement_macros): Likewise.
gcc/c/ChangeLog:
PR other/84889
* c-decl.c (pushtag): Add auto_diagnostic_group instance.
(diagnose_mismatched_decls): Likewise, in various places.
(warn_if_shadowing): Likewise.
(implicit_decl_warning): Likewise.
(implicitly_declare): Likewise.
(undeclared_variable): Likewise.
(declare_label): Likewise.
(grokdeclarator): Likewise.
(start_function): Likewise.
* c-parser.c (c_parser_declaration_or_fndef): Likewise.
(c_parser_parameter_declaration): Likewise.
(c_parser_binary_expression): Likewise.
* c-typeck.c (c_expr_sizeof_expr): Likewise.
(parser_build_binary_op): Likewise.
(build_unary_op): Likewise.
(error_init): Likewise.
(pedwarn_init): Likewise.
(warning_init): Likewise.
(convert_for_assignment): Likewise.
gcc/cp/ChangeLog:
PR other
[Bug other/84889] Ideas on revamping how we format diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889 --- Comment #12 from David Malcolm --- Another commit related to this: r263564 (add labeling of source ranges)
[Bug c/87023] It's always false, when c_fully_fold_internal deal with C_MAYBE_CONST_EXPR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87023 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Joseph S. Myers --- This is not a bug. The comment on c_fully_fold_internal explains its semantics, which only ever involve clearing *MAYBE_CONST_OPERANDS and *MAYBE_CONST_ITSELF (pointers to variables that may have been set to true in a caller and then are cleared, recursively, in any nested call that discovers a reason for the expression not to be an integer constant expression). Please see also the comment on c_fully_fold where it says "(*MAYBE_CONST should typically be set to true by callers before calling this function.)". Please use the gcc-help mailing list in future to ask questions about code and reserve Bugzilla for when you have an actual bug in GCC to report.
[Bug c++/81761] assembler error on __func__ et al. on attribute target overloads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81761 Eric Gallager changed: What|Removed |Added CC||jason at redhat dot com, ||nathan at acm dot org --- Comment #2 from Eric Gallager --- cc-ing c++ FE maintainers
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 --- Comment #17 from Segher Boessenkool --- Please do the combine dumps with details enabled; these are pretty useless. (-fdump-rtl-combine-all) A C testcase would be very helpful, too (or some magic configure command to run on some cfarm machine).
[Bug c++/45963] inconsistent and poor array initialization diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45963 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 libstdc++/70694] 50 experimental/filesystem/* failures on x86_64-apple-darwin10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70694 Eric Gallager changed: What|Removed |Added Status|WAITING |NEW --- Comment #7 from Eric Gallager --- Removing from WAITING since the patch was reported to work
[Bug target/54006] __atomic_always_lock_free inconsistent with __GCC_ATOMIC_INT_LOCK_FREE et al. on crisv32 and hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54006 Eric Gallager changed: What|Removed |Added Status|WAITING |UNCONFIRMED Last reconfirmed|2017-07-28 00:00:00 | Ever confirmed|1 |0 --- Comment #8 from Eric Gallager --- I guess I'll put it back in UNCONFIRMED instead of leaving it in WAITING...
[Bug target/54006] __atomic_always_lock_free inconsistent with __GCC_ATOMIC_INT_LOCK_FREE et al. on crisv32 and hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54006 Eric Gallager changed: What|Removed |Added CC||dave.anglin at bell dot net, ||law at redhat dot com, ||sch...@linux-m68k.org --- Comment #9 from Eric Gallager --- (In reply to Hans-Peter Nilsson from comment #0) > Created attachment 27820 [details] > Testcase suitable for gcc.dg/torture > > See attached test-case, which fails for crisv32-axis-linux-gnu and > "crisv32-elf -munaligned-atomic-may-use-library" and likely for e.g. m68k > coldfire and definitely for hppa*-* (only library, no patterns). cc-ing maintainers for those targets
[Bug tree-optimization/87034] New: [9 Regression] missing -Wformat-overflow on a sprintf %s with a wide string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87034
Bug ID: 87034
Summary: [9 Regression] missing -Wformat-overflow on a sprintf
%s with a wide string
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC 8 diagnoses the buffer overflow in the test case below, albeit with a
message that isn't entirely accurate. However, as a result of r263607 GCC 9 no
longer does.
$ cat f.c && gcc -O2 -S -Wall f.c
typedef __WCHAR_TYPE__ wchar_t;
extern int sprintf (char*, const char*, ...);
struct S
{
char a[2];
void (*pf)(void);
};
void test (struct S *p)
{
const char *q = (char*)L"\x41424344\x45464748";
sprintf (p->a, "%s", q);
}
f.c: In function ‘test’:
f.c:15:21: warning: ‘sprintf’ writing a terminating nul past the end of the
destination [-Wformat-overflow=]
sprintf (p->a, "%s", q);
^
f.c:15:3: note: ‘sprintf’ output 3 bytes into a destination of size 2
sprintf (p->a, "%s", q);
^~~
[Bug tree-optimization/87034] [9 Regression] missing -Wformat-overflow on a sprintf %s with a wide string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87034 --- Comment #1 from Martin Sebor --- Author: msebor Date: Mon Aug 20 23:03:55 2018 New Revision: 263676 URL: https://gcc.gnu.org/viewcvs?rev=263676&root=gcc&view=rev Log: PR tree-optimization/87034 - missing -Wformat-overflow on a sprintf %s with a wide string gcc/testsuite/ChangeLog: * gcc.dg/builtin-sprintf-warn-20.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-20.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/87031] nios2 optimization for size - two cases of regression relatively to 5.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87031 --- Comment #2 from Michael_S --- After playing with the 2nd case on godbolt I found that it's not target specific. The regression occurred at all targets between gcc6 and gcc7.
[Bug target/54006] __atomic_always_lock_free inconsistent with __GCC_ATOMIC_INT_LOCK_FREE et al. on crisv32 and hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54006 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #10 from John David Anglin --- The test passes on hppa. The hppa-linux target has a kernel helper to implement compare and swap. The hpux target isn't "lock free". There is a debate as to whether the linux implementation Is "lock free" or not. See PR83638.
[Bug testsuite/67958] The tests changed by r223498 now FAILs on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67958 --- Comment #5 from Eric Gallager --- (In reply to Dominique d'Humieres from comment #4) > > > Created attachment 39731 [details] > > > Patch fixing the failures with the patches for pr71767 > > > > please send this patch to gcc-patches for review > > This patch has never been intended to be submitted for review: it does not > take into account comment 2. can't that part be done separately?
[Bug preprocessor/60723] Line directives with incorrect system header flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723
--- Comment #30 from Eric Gallager ---
(In reply to Steve Ellcey from comment #29)
> I posted this question on g...@gcc.gnu.org and got not response so I thought
> I would ask here on the bug report.
>
> I am trying to understand the status of this bug and the patch
> that fixes it. It looks like a patch was submitted and checked
> in for 5.0 to fix the problem reported and I see the new
> behavior caused by the patch in GCC 5.X compilers. This behavior
> caused a number of issues with configures and scripts that examined
> preprocessed output as is mentioned in this bug report.
> There was a later bug, 64864, complaining about the behavior and
> that was closed as invalid.
>
> But when I look at GCC 6.X or ToT (7.X) compilers I do not see the same
> behavior as 5.X. Was this patch reverted or was a new patch submitted
> that undid some of this patches behavior? I couldn't find any revert or
> new patch to replace the original one so I am not sure when or why
> the code changed back after the 5.X releases.
>
> Here is a test case that I am preprocessing with g++ -E:
>
> #include
> class foo {
> void operator= ( bool bit);
> operator bool() const;
> };
>
> GCC 5.4 breaks up the operator delcarations with line markers and GCC 6.2
> does not.
This is the right link for where it is in the archives, right?
https://gcc.gnu.org/ml/gcc/2016-11/msg00116.html
Probably got lost in the change-of-the-month rollover...
[Bug testsuite/62234] warnings/errors from LTO cannot be tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62234 --- Comment #10 from Eric Gallager --- (In reply to Martin Sebor from comment #9) > (In reply to David Malcolm from comment #6) > > I added support for this in r256801: > > dg-lto-warning and dg-lto-message > > https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00257.html > > Awesome! It might be worth an email to the dev list to let people aware of > the limitation know about this enhancement -- I know of least two bugs that > I should add tests for now that this works. > > It might also be helpful to update the README and mention this and the other > dg-lto- directives. Let me post one. Did you do this? If so, link?
[Bug target/87033] The compiler does not generate the LWAX instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87033 --- Comment #2 from Michael Meissner --- Author: meissner Date: Mon Aug 20 23:46:37 2018 New Revision: 263678 URL: https://gcc.gnu.org/viewcvs?rev=263678&root=gcc&view=rev Log: [gcc] 2018-08-20 Michael Meissner PR target/87033 * config/rs6000/rs6000.md (extendsi2): Change constraints from 'Y' to 'YZ' to enable the LWAX instruction to be generated for indexed loads. [gcc/testsuite] 2018-08-20 Michael Meissner PR target/87033 * gcc.target/powerpc/pr87033.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr87033.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md trunk/gcc/testsuite/ChangeLog
[Bug c/87023] It's always false, when c_fully_fold_internal deal with C_MAYBE_CONST_EXPR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87023 --- Comment #2 from hhj --- (In reply to Joseph S. Myers from comment #1) > This is not a bug. The comment on c_fully_fold_internal explains its > semantics, which only ever involve clearing *MAYBE_CONST_OPERANDS and > *MAYBE_CONST_ITSELF (pointers to variables that may have been set to true in > a caller and then are cleared, recursively, in any nested call that > discovers a reason for the expression not to be an integer constant > expression). Please see also the comment on c_fully_fold where it says > "(*MAYBE_CONST should typically be set to true by callers before calling > this function.)". > > Please use the gcc-help mailing list in future to ask questions about code > and reserve Bugzilla for when you have an actual bug in GCC to report. thanks
[Bug translation/80191] diagnostic placeholder "new initializer" must be marked for translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80191 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-08-21 Ever confirmed|0 |1 --- Comment #8 from Eric Gallager --- (In reply to Eric Gallager from comment #7) > Changing component to translation, but leaving UNCONFIRMED since there seems > to be disagreement Putting in WAITING in the hopes that someone else will decide one way or another whether this bug is valid or not.
[Bug target/86832] [8/9 Regression] GCC v8.2.0 tries to use native TLS with -fstack-protector-strong on Windows (mingw-w64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832 Stefan Weil changed: What|Removed |Added CC||sw at weilnetz dot de --- Comment #4 from Stefan Weil --- Related bug reports for other software: https://sourceforge.net/p/mingw-w64/bugs/755/ http://lists.nongnu.org/archive/html/qemu-devel/2018-08/msg04140.html
[Bug c++/87035] New: Can't shadow global const int with unnamed enum in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035
Bug ID: 87035
Summary: Can't shadow global const int with unnamed enum in
class
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
const int N = 5;
struct X {
int Array[N]; // int[5]
enum { N }; // fails, redeclaration
};
This is well-formed, as the enum value N is in another scope and so shadows
::N. Removing the array declaration makes the code also compile.
[Bug c++/87035] Can't shadow global const int with unnamed enum in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski ---
Actually no this is invalid code at least according to the standard. Since N
definition has to be the same when used and at the end of the scope. In this
case, you have a different one.
The error message is very clear about that too:
t8.cc:5:10: error: declaration of ‘N’ [-fpermissive]
enum { N }; // fails, redeclaration
^
t8.cc:1:11: error: changes meaning of ‘N’ from ‘const int N’ [-fpermissive]
const int N = 5;
^
Maybe just the use of N is not in the error message.
[Bug c++/87035] Can't shadow global const int with unnamed enum in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035 --- Comment #2 from Nicolas Lesser --- Huh, interesting. TIL. Where's that rule in the standard? Because I can't find it in [class.mem]. Is it somewhere else or did I just overlook it?
