[Bug fortran/90169] Setting an allocatable variable length character array in a type incorrectly sets all members of the array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90169 kargl at gcc dot gnu.org changed: What|Removed |Added Resolution|INVALID |WONTFIX --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to menospaamthereaper from comment #3) > Also why was this bug marked as resolved / invalid? It still exists for > 7.3.0 whether or not it will be resolved, and is rather serious. I choose the wrong menu item. Changing it to WONTFIX. The allocation/deallocation is fairly complicated. Whether a patch is back ported depends on the person who fixed the bug and how difficult the back may be. There are too many bugs to fix and features to implement for the available man power.
[Bug fortran/90169] Setting an allocatable variable length character array in a type incorrectly sets all members of the array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90169 --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to menospaamthereaper from comment #2) > (In reply to kargl from comment #1) > > The problem is fixed on trunk. Don't know if anyone intends to back port. > > Doubt it as no one has done so. > > > > PR 78578 is irrelevant as the individual who submitted > > the testcase has a typo in his/her code. > > Thanks kargl, can you identify for which release(s) this case works > correctly? I already have. The problem is fixed on trunk. The first release with the fix will be 9.1, which should be released in the next few weeks.
[Bug tree-optimization/32605] Missing byte swap optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32605
Jed Brown changed:
What|Removed |Added
CC||jed at 59A2 dot org
--- Comment #5 from Jed Brown ---
The missed optimization even exists for code such as this, which should compile
to a simple load on LE architectures.
unsigned read_u32_le(const unsigned char arr[]) {
return (arr[0] << 0)
| (arr[1] << 8)
| (arr[2] << 16)
| (arr[3] << 24);
}
gcc-8.3/trunk -O:
read_u32_le:
movzx eax, BYTE PTR [rdi+1]
sal eax, 8
movzx edx, BYTE PTR [rdi+2]
sal edx, 16
or eax, edx
movzx edx, BYTE PTR [rdi]
or eax, edx
movzx edx, BYTE PTR [rdi+3]
sal edx, 24
or eax, edx
ret
clang-8 -O:
read_u32_le: # @read_u32_le
mov eax, dword ptr [rdi]
ret
https://gcc.godbolt.org/z/8lGeCF
[Bug fortran/90169] Setting an allocatable variable length character array in a type incorrectly sets all members of the array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90169 --- Comment #3 from menospaamthereaper at hotmail dot com --- Also why was this bug marked as resolved / invalid? It still exists for 7.3.0 whether or not it will be resolved, and is rather serious.
[Bug fortran/90169] Setting an allocatable variable length character array in a type incorrectly sets all members of the array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90169 --- Comment #2 from menospaamthereaper at hotmail dot com --- (In reply to kargl from comment #1) > The problem is fixed on trunk. Don't know if anyone intends to back port. > Doubt it as no one has done so. > > PR 78578 is irrelevant as the individual who submitted > the testcase has a typo in his/her code. Thanks kargl, can you identify for which release(s) this case works correctly?
[Bug inline-asm/90193] New: asm goto with TLS "m" input operand generates incorrect assembler in O1 and O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90193
Bug ID: 90193
Summary: asm goto with TLS "m" input operand generates
incorrect assembler in O1 and O2
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: mathieu.desnoyers at efficios dot com
Target Milestone: ---
This issue can be reproduced with:
gcc version 8.3.0 (GCC)
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/efficios/local
Command line reproducing the bug:
/home/efficios/local/bin/gcc -O1 -o test-asm-goto test-asm-goto.c
(same with -O2)
Compiler output:
/tmp/ccsWO2Fm.o: In function `main':
test-asm-goto.c:(.text+0x1): undefined reference to `.L2'
collect2: error: ld returned 1 exit status
Preprocessed file reproducing the bug:
# 1 "test-asm-goto.c"
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 "test-asm-goto.c"
__thread int var;
static int fct(void)
{
asm goto ( "jmp %l[testlabel]\n\t"
: : [var] "m" (var) : : testlabel);
return 0;
testlabel:
return 1;
}
int main()
{
return fct();
}
It works fine with gcc 7.3.0 with and without optimizations, and it works fine
with gcc 8.3.0 without optimizations. It also affects compilation with -m32
(32-bit x86).
[Bug c++/90190] [8/9 regression] CTAD confuses with {one element} initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90190 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-20 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug other/90144] Use portable test(1) in isl/configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90144 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #1 from Andrew Pinski --- isl is not part of the GCC project and is not included with GCC's sources. The project page is http://isl.gforge.inria.fr/ .
[Bug c++/90178] [9 Regression] Missed optimization: duplicated terminal basic block with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90178
--- Comment #6 from H.J. Lu ---
(In reply to H.J. Lu from comment #3)
> It is caused by r266358.
The nop INSN can be removed by split_all_insns later:
if (INSN_P (insn))
{
rtx set = single_set (insn);
/* Don't split no-op move insns. These should silently
disappear later in final. Splitting such insns would
break the code that handles LIBCALL blocks. */
if (set && set_noop_p (set))
{
/* Nops get in the way while scheduling, so delete them
now if register allocation has already been done. It
is too risky to try to do this before register
allocation, and there are unlikely to be very many
nops then anyways. */
if (reload_completed)
delete_insn_and_edges (insn);
[Bug fortran/90166] Compiler Fails at Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90166 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P5 |P4 Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |9.0 Severity|enhancement |minor --- Comment #5 from kargl at gcc dot gnu.org --- Patch submitted to mail listings. https://gcc.gnu.org/ml/fortran/2019-04/msg00096.html
[Bug libstdc++/90192] New: std::vector::resize() requires more than the CopyInsertable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90192
Bug ID: 90192
Summary: std::vector::resize() requires more than the
CopyInsertable
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lemo1234 at gmail dot com
Target Milestone: ---
std::vector::resize(size_type count, const value_type& value) requires
CopyInsertable, but recent libstdc++ versions try to use the assignment
operator (https://godbolt.org/z/xrutNZ)
#include
struct X { const int c; };
void foo() {
std::vector v;
v.resize(10, X{});
}
n file included from
/opt/compiler-explorer/gcc-8.3.0/include/c++/8.3.0/vector:60,
from :2:
/opt/compiler-explorer/gcc-8.3.0/include/c++/8.3.0/bits/stl_algobase.h: In
instantiation of 'typename __gnu_cxx::__enable_if<(!
std::__is_scalar<_Tp>::__value), void>::__type std::__fill_a(_ForwardIterator,
_ForwardIterator, const _Tp&) [with _ForwardIterator = X*; _Tp = X; typename
__gnu_cxx::__enable_if<(! std::__is_scalar<_Tp>::__value), void>::__type =
void]':
/opt/compiler-explorer/gcc-8.3.0/include/c++/8.3.0/bits/stl_algobase.h:731:20:
required from 'void std::fill(_ForwardIterator, _ForwardIterator, const _Tp&)
[with _ForwardIterator = X*; _Tp = X]'
/opt/compiler-explorer/gcc-8.3.0/include/c++/8.3.0/bits/vector.tcc:505:14:
required from 'void std::vector<_Tp, _Alloc>::_M_fill_insert(std::vector<_Tp,
_Alloc>::iterator, std::vector<_Tp, _Alloc>::size_type, const value_type&)
[with _Tp = X; _Alloc = std::allocator; std::vector<_Tp, _Alloc>::iterator =
__gnu_cxx::__normal_iterator >; typename
std::_Vector_base<_Tp, _Alloc>::pointer = X*; std::vector<_Tp,
_Alloc>::size_type = long unsigned int; std::vector<_Tp, _Alloc>::value_type =
X]'
/opt/compiler-explorer/gcc-8.3.0/include/c++/8.3.0/bits/stl_vector.h:847:4:
required from 'void std::vector<_Tp, _Alloc>::resize(std::vector<_Tp,
_Alloc>::size_type, const value_type&) [with _Tp = X; _Alloc =
std::allocator; std::vector<_Tp, _Alloc>::size_type = long unsigned int;
std::vector<_Tp, _Alloc>::value_type = X]'
:8:21: required from here
/opt/compiler-explorer/gcc-8.3.0/include/c++/8.3.0/bits/stl_algobase.h:685:11:
error: use of deleted function 'X& X::operator=(const X&)'
*__first = __value;
~^
:4:8: note: 'X& X::operator=(const X&)' is implicitly deleted because
the default definition would be ill-formed:
struct X { const int c; };
^
:4:8: error: non-static const member 'const int X::c', can't use
default assignment operator
In file included from
/opt/compiler-explorer/gcc-8.3.0/include/c++/8.3.0/vector:60,
from :2:
/opt/compiler-explorer/gcc-8.3.0/include/c++/8.3.0/bits/stl_algobase.h: In
instantiation of 'static _Tp* std::__copy_move_backward<_IsMove, true,
std::random_access_iterator_tag>::__copy_move_b(const _Tp*, const _Tp*, _Tp*)
[with _Tp = X; bool _IsMove = true]':
/opt/compiler-explorer/gcc-8.3.0/include/c++/8.3.0/bits/stl_algobase.h:588:37:
required from '_BI2 std::__copy_move_backward_a(_BI1, _BI1, _BI2) [with bool
_IsMove = true; _BI1 = X*; _BI2 = X*]'
/opt/compiler-explorer/gcc-8.3.0/include/c++/8.3.0/bits/stl_algobase.h:598:5:
required from '_BI2 std::__copy_move_backward_a2(_BI1, _BI1, _BI2) [with bool
_IsMove = true; _BI1 = X*; _BI2 = X*]'
/opt/compiler-explorer/gcc-8.3.0/include/c++/8.3.0/bits/stl_algobase.h:668:48:
required from '_BI2 std::move_backward(_BI1, _BI1, _BI2) [with _BI1 = X*; _BI2
= X*]'
/opt/compiler-explorer/gcc-8.3.0/include/c++/8.3.0/bits/vector.tcc:503:5:
required from 'void std::vector<_Tp, _Alloc>::_M_fill_insert(std::vector<_Tp,
_Alloc>::iterator, std::vector<_Tp, _Alloc>::size_type, const value_type&)
[with _Tp = X; _Alloc = std::allocator; std::vector<_Tp, _Alloc>::iterator =
__gnu_cxx::__normal_iterator >; typename
std::_Vector_base<_Tp, _Alloc>::pointer = X*; std::vector<_Tp,
_Alloc>::size_type = long unsigned int; std::vector<_Tp, _Alloc>::value_type =
X]'
/opt/compiler-explorer/gcc-8.3.0/include/c++/8.3.0/bits/stl_vector.h:847:4:
required from 'void std::vector<_Tp, _Alloc>::resize(std::vector<_Tp,
_Alloc>::size_type, const value_type&) [with _Tp = X; _Alloc =
std::allocator; std::vector<_Tp, _Alloc>::size_type = long unsigned int;
std::vector<_Tp, _Alloc>::value_type = X]'
:8:21: required from here
/opt/compiler-explorer/gcc-8.3.0/include/c++/8.3.0/bits/stl_algobase.h:566:19:
error: static assertion failed: type is not assignable
static_assert( __assignable::type::value, "type is not assignable" );
^~~~
Compiler returned: 1
[Bug middle-end/90191] New: [9 regression] -Wformat-overflow depends on --param max-jump-thread-duplication-stmts=17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90191
Bug ID: 90191
Summary: [9 regression] -Wformat-overflow depends on --param
max-jump-thread-duplication-stmts=17
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
Target Milestone: ---
r265568 PASS
r265754 FAIL
r270458 FAIL
Warn if compiled with "-O2 --param max-jump-thread-duplication-stmts=17"
And not warn if compiled with -O2
Original code fill & printf() 2 vectors of chars (pseudo-code see below)
-- If second vector is in "if() {}" then warning emitted.
-- If second vector is out of "if() {}" then no warning produced.
-- if printf() divided into 2 printf there are no warning.
$ cat a.ii
extern "C" int printf(const char *...);
struct i {
void j(char *p1, int) { delete p1; }
};
struct q {
typedef char
};
struct t {
static char *u();
};
template void ad(e, ab, g,
h);
char *m;
struct v {
struct w {
char *l;
};
v(int p1) {
int o = p1, a = o;
m = a ? t::u() : 0;
n.l = m;
}
~v() {
char *c = n.l, *p = c;
int f = 0;
i k;
k.j(p, f);
}
w n;
};
int s;
struct x : v {
x() : v(y()) {
i b;
ad(0, 0, s, b);
}
q::d operator[](int p1) { return *(n.l + p1); }
static int y();
};
unsigned ap();
char r;
static int av() {
{
x d;
if (0)
goto ay;
char = d[0];
printf("%s = %s\n", , );
}
ay:
return 0;
}
unsigned ap() {
av();
return 0;
}
$ /usr/local/gcc_current/bin/g++ -O2 -fpreprocessed -Wall -Wextra -c a.ii
$ /usr/local/gcc_current/bin/g++ -O2 --param
max-jump-thread-duplication-stmts=17 -fpreprocessed -Wall -Wextra -c a.ii
In function 'int av()',
inlined from 'unsigned int ap()' at a.ii:53:5:
a.ii:47:11: warning: '%s' directive argument is null [-Wformat-overflow=]
47 | printf("%s = %s\n", , );
| ~~^
Original code looks as
size_t l1, l2, sel;
if(foo_1())
goto err;
if(foo_2(, ))
goto err;
std::vector v(l1);
if(bar_1([0])
goto err;
if(sel) {
std::vector w(l2); // <--- if move out of block then warning disappears
if(bar_2([0]))
goto err;
printf("%s = %s\n", [0], [0]); // <-- if divided to 2 calls then warning
disappears
return;
}
err:
return;
$ /usr/local/gcc_current/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc_current/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --enable-checking=yes,df,fold,rtl,extra
--enable-languages=c,c++,lto --disable-multilib --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --with-tune=native
Thread model: posix
gcc version 9.0.1 20190419 (experimental) [trunk revision 270458] (GCC)
[Bug c++/90190] New: [8/9 regression] CTAD confuses with {one element} initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90190
Bug ID: 90190
Summary: [8/9 regression] CTAD confuses with {one element}
initializer_list
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lichray at gmail dot com
Target Milestone: ---
Created attachment 46213
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46213=edit
test case
https://godbolt.org/z/f8rKSG
#include
#include
enum class X {};
struct Term {
double a;
X i;
};
template
struct sum {
sum(std::initializer_list) {}
};
int main() {
auto c2 = sum{{1, X()}, {2, X()}};
auto c1 = sum{{1, X()}}; // fails only this
auto c0 = sum{{}};
}
:18:25: note: cannot convert '{1, (X)0}' (type '') to type 'std::initializer_list'
auto c1 = sum{{1, X()}};
-- It's certainly convertible if you add <>.
Works in GCC 7, MSVC, Clang.
[Bug inline-asm/90181] Feature request: provide a way to explicitly select specific named registers in constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181 --- Comment #3 from nfxjfg at googlemail dot com --- Yes, it's documented this way, but it makes it appear all kinds of fragile. For one, I normally expect that the compiler will reorder and interleave any statements in my code (because that's what compilers always tend to do from a user's POV), so it seems weird that it works at all, since there is nothing that strictly associates the register declaration and the asm block. Yes, the gcc docs (the part you quoted in particular) sort of make it clear that it's simply the lexical order of operations that matters here. In the gcc example for example, the compiler can't just move the initialization of t1 below the p1 initialization, although with normal code it can and will do that. Anyway, that is not the central point of this feature request. I only brought it up as an argument that register variables are confusing and roundabout. The central point of this feature request is that I'm asking for a way to specify a named register in a contraint directly, instead of having to use this detour over register variables. Can I ask why this feature request has been rejected?
[Bug translation/90176] diagnostics should generally contain underscore only inside quotes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90176 Roland Illig changed: What|Removed |Added Attachment #46206|0 |1 is obsolete|| --- Comment #3 from Roland Illig --- Created attachment 46212 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46212=edit linter with extended checks
[Bug c++/90178] [9 Regression] Missed optimization: duplicated terminal basic block with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90178 --- Comment #5 from H.J. Lu --- zveroupper pass drops: (insn 36 37 51 8 (use (reg/i:DI 0 ax)) "x.i":8:1 -1 (nil))
[Bug c++/90178] [9 Regression] Missed optimization: duplicated terminal basic block with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90178
--- Comment #4 from H.J. Lu ---
The removed insn is insn 35 in:
;; basic block 8, loop depth 0, count 114863532 (estimated locally), maybe hot
;; prev block 7, next block 1, flags: (REACHABLE, HOT_PARTITION, RTL)
;; pred: 7 [always] count:6317494 (estimated locally) (FALLTHRU)
;; 4 [5.5% (guessed)] count:55807731 (estimated locally)
(LOOP_EXIT)
;; 6 [always] count:52738306 (estimated locally)
;; bb 8 artificial_defs: { }
;; bb 8 artificial_uses: { u44(6){ }u45(7){ }u46(16){ }u47(19){ }}
;; lr in6 [bp] 7 [sp] 16 [argp] 19 [frame] 90
;; lr use 6 [bp] 7 [sp] 16 [argp] 19 [frame] 90
;; lr def 0 [ax]
(code_label 34 6 37 8 1 (nil) [2 uses])
(note 37 34 35 8 [bb 8] NOTE_INSN_BASIC_BLOCK)
(insn 35 37 36 8 (set (reg/i:DI 0 ax)
(reg/f:DI 90 [ ])) "x.i":8:1 66 {*movdi_internal}
(expr_list:REG_DEAD (reg/f:DI 90 [ ])
(nil)))
(insn 36 35 0 8 (use (reg/i:DI 0 ax)) "x.i":8:1 -1
(nil))
;; succ: EXIT [always] count:114863532 (estimated locally) (FALLTHRU)
;; lr out 0 [ax] 6 [bp] 7 [sp] 16 [argp] 19 [frame]
With -mvzeroupper, it becomes:
;; basic block 8, loop depth 0, count 114863532 (estimated locally), maybe hot
;; prev block 7, next block 1, flags: (HOT_PARTITION, RTL)
;; pred: 7 [always] count:6317494 (estimated locally) (FALLTHRU)
;; 4 [5.5% (guessed)] count:55807731 (estimated locally)
(LOOP_EXIT)
;; 6 [always] count:52738306 (estimated locally)
;; bb 8 artificial_defs: { }
;; bb 8 artificial_uses: { u-1(7){ }}
;; lr in0 [ax] 7 [sp]
;; lr use 7 [sp] [ax] is missing.
;; lr def
;; live in 0 [ax] 7 [sp]
;; live gen
;; live kill
(code_label 54 36 53 8 6 (nil) [2 uses])
(note 53 54 51 8 [bb 8] NOTE_INSN_BASIC_BLOCK)
;; succ: EXIT [always] count:114863532 (estimated locally) (FALLTHRU)
;; lr out 0 [ax] 7 [sp]
;; live out 0 [ax] 7 [sp]
[Bug translation/90163] untranslated placeholder in warn_once_call_ms2sysv_xlogues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90163
--- Comment #3 from Roland Illig ---
(In reply to Daniel Santos from comment #2)
> Yes, this is mine. Does this only become untranslatable when feature is
> "static call chains"?
In German, this might result in:
%<-mcall-ms2sysv-xlogues%> ist nicht mit static call chains kompatibel
This would be a change of language in the middle of the sentence without any
indication. Therefore yes, I consider it impossible to translate.
> But given that, what would be the ideal way to present this?
Two variants of the warning:
static void warn_once_call_ms2sysv_xlogues (const char *feature, bool q)
{
static bool warned_once = false;
if (warned_once)
return;
warned_once = true;
if (q)
{
/* TRANSLATORS: %qs is either a command line option or the name of a
* built-in function. */
warning (0, "%<-mcall-ms2sysv-xlogues%> is not compatible with %qs",
feature);
}
else
{
warning (0, "%<-mcall-ms2sysv-xlogues%> is not compatible with "
"nested functions");
}
}
Either way, it's strange that the "feature" parameter is not used at all in the
!q case. That's only complicated because of the warned_once variable. If it
were possible to extract the warned_once variable out of this function, the
variant for nested functions could be called directly.
[Bug translation/90183] ambiguous diagnostics "only available with"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90183 --- Comment #2 from Roland Illig --- The same diagnostic also appears for %<-std=c++-17%> and several others, and these are in the past. Are the options from these standard only available in that particular version of the standard? I don't guess so.
[Bug c++/90184] confusing diagnostic "attribute using prefix"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90184 --- Comment #2 from Roland Illig --- (In reply to Jonathan Wakely from comment #1) > But is it confusing in context when the diagnostic points to a piece of code > saying [[using gnu: noinline]] ? Yes, it is. I just had a look at gen-attrs-66.C, and even when seeing the corresponding source code, I am still confused by the highly ambiguous grammar. My try for a better wording: the % prefix for attributes is only available ... This follows the GCC Guidelines for Diagnostics more closely, which say that diagnostics should be complete sentences.
[Bug c++/90178] [9 Regression] Missed optimization: duplicated terminal basic block with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90178 --- Comment #3 from H.J. Lu --- It is caused by r266358.
[Bug c++/90189] New: Spurious "error: parameter packs not expanded" when a dependent name coincides
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90189
Bug ID: 90189
Summary: Spurious "error: parameter packs not expanded" when a
dependent name coincides
Product: gcc
Version: 9.0
URL: https://godbolt.org/z/UuwYK4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lkoppel at uwaterloo dot ca
Target Milestone: ---
Source:
struct A {
using CommonName = char;
};
template
struct B {
using V = typename T::CommonName;
};
template struct B;
Output:
:7:37: error: parameter packs not expanded with '...':
7 | using V = typename T::CommonName;
| ^
:7:37: note: 'CommonName'
Compiler returned: 1
Rejected by all GCC versions. Accepted by clang, msvc.
[Bug translation/90148] Closing quote in wrong position in plugin.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90148 --- Comment #5 from Roland Illig --- From fortran/intrinsic.c: gfc_warning_now (OPT_Wintrinsics_std, "The intrinsic %qs at %L is not " "included in the selected standard but %s and %qs will" " be treated as if declared EXTERNAL. Use an" " appropriate %<-std=%>* option or define" " %<-fall-intrinsics%> to allow this intrinsic.", sym->name, , symstd, sym->name); After the "-std=".
[Bug c++/90178] [9 Regression] Missed optimization: duplicated terminal basic block with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90178 H.J. Lu changed: What|Removed |Added Host||ubizjak at gmail dot com --- Comment #2 from H.J. Lu --- Add -mno-vzeroupper fixes it.
[Bug c++/90185] diagnostic "argument pack of characters" sounds like a complaint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90185 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-19 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Agreed. I think "ISO C++ does not support..." is how we usually say this. It's a -pedantic warning, so that already tells users that this is warning about a feature GCC supports as an extension.
[Bug c++/90184] confusing diagnostic "attribute using prefix"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90184 --- Comment #1 from Jonathan Wakely --- But is it confusing in context when the diagnostic points to a piece of code saying [[using gnu: noinline]] ?
[Bug inline-asm/90181] Feature request: provide a way to explicitly select specific named registers in constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Andrew Pinski --- I think the manual is clear (when it comes to the following questions: will r_a7 occupy the a7 register for the entire function (suppose there is more C code around it)? What if call_ecall gets inlined into a larger function? ) https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html#Local-Register-Variables Warning: In the above example, be aware that a register (for example r0) can be call-clobbered by subsequent code, including function calls and library calls for arithmetic operators on other variables (for example the initialization of p2).
[Bug translation/90183] ambiguous diagnostics "only available with"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90183 --- Comment #1 from Jonathan Wakely --- Currently there's nothing later than c++2a so it's correct. To be future proof it could say "or later" but that's a bit misleading, as there is (currently) nothing later.
[Bug c++/90188] New: ambiguous diagnostic "may not"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90188
Bug ID: 90188
Summary: ambiguous diagnostic "may not"
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From cp/parser.c:
parser->type_definition_forbidden_message
= G_("types may not be defined in iterator type");
The term "may not" is ambiguous. It can either mean:
it could be that types are not defined in iterator type
or:
types should/must not be defined in iterator type
In this case I guess it's the latter. The diagnostic should be worded more
clearly. There's a reason that RFC 2119 does not include "may not" in its list
of keywords.
[Bug c++/90171] [9 Regression] ICE in build_op_delete_call, at cp/call.c:6630
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90171 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-19 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/90178] [9 Regression] Missed optimization: duplicated terminal basic block with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90178 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-19 Summary|Missed optimization:|[9 Regression] Missed |duplicated terminal basic |optimization: duplicated |block with -mavx|terminal basic block with ||-mavx Ever confirmed|0 |1
[Bug translation/90118] Missing space between words
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90118
--- Comment #8 from Roland Illig ---
(In reply to Christophe Lyon from comment #7)
> Do you mean something like that?
>
> if p.startswith('-'):
> if len(p) >= 2 and (p[1].isalpha() and p != '-INF'):
> -print('%s: %s' % (origin, text))
> +reason = 'Illegal string after "-"'
> +print('%s: %s: %s' % (origin, reason, text))
Almost. The guidelines recommend to say _why_ something is wrong. It could also
be more specific by additionally providing the information that this diagnostic
is meant to match command line arguments.
In my current local version of the linter, the code is:
if part.startswith('-'):
if len(part) >= 2 and part[1].isalpha() and part != '-INF':
warn(msg, 'command line option outside %')
> elif p.startswith('__builtin_'):
> -print('%s: %s' % (origin, text))
> +reason = 'Starts with _builtin_'
> +print('%s: %s: %s' % (origin, reason, text))
And why is that bad? I chose the following diagnostic:
elif part.startswith('__builtin_'):
warn(msg, 'builtin function outside %')
> if re.search("[^%]'", p):
> -print('%s: %s' % (origin, text))
> +reason = 'Illegal single quote'
> +print('%s: %s: %s' % (origin, reason, text))
if re.search("[^%]'", msgid):
warn(msg, 'apostrophe without leading %')
> # %< should not be preceded by a non-punctuation
> # %character.
> if re.search("[a-zA-Z0-9]%<", p):
> -print('%s: %s' % (origin, text))
> +reason = 'Illegal character before %<'
> +print('%s: %s: %s' % (origin, reason, text))
# from bug 90118: Missing space between words
if re.search("[a-zA-Z0-9]%<", msgid):
warn(msg, '%< directly following a letter or digit')
See bug 90119 and bug 90176 for my versions of the linter from today's
afternoon. I've added some more changes since then.
Of course it would be even nicer if the linter would also offer an explanation,
like I did in https://github.com/rillig/pkglint, or like the MIPSPro compiler
has with its separate explain(1) utility. That could be the next step.
[Bug target/84369] test case gcc.dg/sms-10.c fails on power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84369 --- Comment #7 from pthaugen at gcc dot gnu.org --- Author: pthaugen Date: Fri Apr 19 17:14:57 2019 New Revision: 270461 URL: https://gcc.gnu.org/viewcvs?rev=270461=gcc=rev Log: Backport from mainline: 2019-04-16 Pat Haugen PR target/84369 * config/rs6000/power9.md: Add store forwarding bypass. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/rs6000/power9.md
[Bug tree-optimization/88055] [9 regression] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Segher Boessenkool --- Fixed.
[Bug tree-optimization/88055] [9 regression] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 --- Comment #10 from Segher Boessenkool --- Author: segher Date: Fri Apr 19 16:58:01 2019 New Revision: 270460 URL: https://gcc.gnu.org/viewcvs?rev=270460=gcc=rev Log: tree-call-cdce: If !HONOR_NANS do not make code with NaNs (PR88055) If we don't HONOR_NANS we should not try to use any unordered comparison results. Best case those will just be optimized away; realistically, they ICE. For example, the rs6000 backend has some code that specifically checks we never do this. PR tree-optimization/88055 * tree-call-cdce.c (comparison_code_if_no_nans): New function. (gen_one_condition): Use it if !HONOR_NANS. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-call-cdce.c
[Bug c++/90178] Missed optimization: duplicated terminal basic block with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90178
H.J. Lu changed:
What|Removed |Added
Summary|Missed optimization:|Missed optimization:
|duplicated terminal basic |duplicated terminal basic
|block |block with -mavx
--- Comment #1 from H.J. Lu ---
This is triggered by -mavx:
[hjl@gnu-cfl-1 pr90178]$ cat x.i
int* find_ptr(int* mem, int sz, int val) {
for (int i = 0; i < sz; i++) {
if (mem[i] == val) {
return [i];
}
}
return 0;
}
[hjl@gnu-cfl-1 pr90178]$ make
/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/ -O2 -mavx
-S x.i
[hjl@gnu-cfl-1 pr90178]$ cat x.s
.file "x.i"
.text
.p2align 4
.globl find_ptr
.type find_ptr, @function
find_ptr:
.LFB0:
.cfi_startproc
movq%rdi, %rax
testl %esi, %esi
jle .L4
leal-1(%rsi), %ecx
leaq4(%rdi,%rcx,4), %rcx
jmp .L3
.p2align 4,,10
.p2align 3
.L9:
addq$4, %rax
cmpq%rcx, %rax
je .L8
.L3:
cmpl%edx, (%rax)
jne .L9
ret
.p2align 4,,10
.p2align 3
.L8:
xorl%eax, %eax
ret
.L4:
xorl%eax, %eax
ret
.cfi_endproc
.LFE0:
.size find_ptr, .-find_ptr
.ident "GCC: (GNU) 9.0.1 20190418 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 pr90178]$
/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/ -O2 -S
x.i
[hjl@gnu-cfl-1 pr90178]$ cat x.s
.file "x.i"
.text
.p2align 4
.globl find_ptr
.type find_ptr, @function
find_ptr:
.LFB0:
.cfi_startproc
movq%rdi, %rax
testl %esi, %esi
jle .L4
leal-1(%rsi), %ecx
leaq4(%rdi,%rcx,4), %rcx
jmp .L3
.p2align 4,,10
.p2align 3
.L7:
addq$4, %rax
cmpq%rcx, %rax
je .L4
.L3:
cmpl%edx, (%rax)
jne .L7
ret
.p2align 4,,10
.p2align 3
.L4:
xorl%eax, %eax
ret
.cfi_endproc
.LFE0:
.size find_ptr, .-find_ptr
.ident "GCC: (GNU) 9.0.1 20190418 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 pr90178]$
[Bug c++/90187] New: ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187 Bug ID: 90187 Summary: ICE in extract_insn, at recog.c:2304 x86_64 Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ianbriggsutah at gmail dot com Target Milestone: --- Created attachment 46211 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46211=edit Creduced file which triggers the ICE the exact version of GCC: gcc version 8.2.0 (Ubuntu 8.2.0-1ubuntu2~18.04) the system type: x86_64-linux-gnu the options given when GCC was configured/built: ../src/configure -v --with-pkgversion='Ubuntu 8.2.0-1ubuntu2~18.04' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu the complete command line that triggers the bug: g++-8 -Ofast -ffloat-store -c test.c the compiler output: test.cpp: In member function ‘int* e::g()’: test.cpp:30:1: error: unrecognizable insn: } ^ (insn 38 37 39 6 (set (reg:V2DF 120) (smin:V2DF (mem/c:V2DF (plus:DI (reg/f:DI 82 virtual-stack-vars) (const_int -64 [0xffc0])) [3 vect__5.6+0 S16 A128]) (mem/c:V2DF (plus:DI (reg/f:DI 82 virtual-stack-vars) (const_int -48 [0xffd0])) [3 vect__6.9+0 S16 A128]))) -1 (nil)) during RTL pass: vregs test.cpp:30:1: internal compiler error: in extract_insn, at recog.c:2304 Please submit a full bug report, with preprocessed source if appropriate. See for instructions.
[Bug translation/90180] ambiguous diagnostic for "out of range"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90180 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-19 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Most middle-end diagnostics format ranges using the [min, max] notation (and less commonly [min, max + 1) for half open intervals). If I'm reading the s390.c code correctly, here (0..%wu) would be rendered as the closed interval [0, %wu] by the middle-end. We should adopt the same convention throughout. Thus confirmed.
[Bug translation/90164] wrong tense in ABI change diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90164 --- Comment #3 from Martin Sebor --- Agreed.
[Bug testsuite/81058] FAIL: gcc.target/i386/avx512bw-vpmovu?swb-1.c scan-assembler-times vpmovu?swb.*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81058
--- Comment #5 from Iain Sandoe ---
Created attachment 46210
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46210=edit
Patch for testing
Darwin doesn't support non-pic for user-space programs, so these tests fail
(and the codeine is sufficiently different that it would be better to write a
second set of tests if that is seen as useful). {aside, why is there no PIC
test for Linux, I guess?]
There is "dynamic-no-pic" for m32 but it doesn't seem worth jumping through
hoops to make a test case for that, since it's not realistically going to be
used on a machine supporting AVX512.
[Bug c++/89923] printf format check and char8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923 --- Comment #6 from Tom Honermann --- (In reply to jos...@codesourcery.com from comment #5) > We (GCC) don't control printf; I know, by "we" I meant the C and C++ standards community. > the format checking should match what the > actual libc supports. Agreed.
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #12 from Vittorio Zecca ---
Here are two more test cases with undefined behaviour in poly-int.h
Must be compiled with nonzero optimization
cat gccerr73.c
// must be compiled with nonzero optimization
// ../../gcc/gcc/poly-int.h:753:21: runtime error: signed integer
overflow: -5621332293356458048 * 8 cannot be represented in type 'long
int'
int a[4];
void f()
{
long int b = 7818038963515661296;
a[0xA699ECD2C348A3A0] = a[b];
}
[vitti cc]$cat gccerr74.c
// Must be compiled with nonzero optimization
// ../../gcc/gcc/poly-int.h:944:5: runtime error: signed integer
overflow: 162675373468811328 - -9060696663385964544 cannot be
represented in type 'long int'
long b[1][9];
typedef long V __attribute__((vector_size (16), may_alias));
void
foo ()
{
V *c = (V *) ((char *) b + -9060696663385964544);
*c = (V) { 1, 1 };
long __attribute__((may_alias)) *d = (long *) ((char *) b +
162675373468811328);
*d = 1;
}
[Bug c++/90186] New: optimizing options -O1 and -O2 produce different results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90186 Bug ID: 90186 Summary: optimizing options -O1 and -O2 produce different results Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: austin.card at torchtechnologies dot com Target Milestone: --- Created attachment 46209 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46209=edit source code and input .txt file CentOS 7: g++ -std=c++11 -O1 -o CheckSum main.cpp CheckSum.cpp -I/usr/local/include ./CheckSum prints a different checksum result than g++ -std=c++11 -O2 -o CheckSum main.cpp CheckSum.cpp -I/usr/local/include ./CheckSum If you uncomment line 144 of Udp.h, then both builds output the same result. Attached is the source code and an input .txt file.
[Bug c++/89900] [9 Regression] ICE: Segmentation fault (in check_instantiated_arg)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89900 --- Comment #8 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Apr 19 15:36:20 2019 New Revision: 270459 URL: https://gcc.gnu.org/viewcvs?rev=270459=gcc=rev Log: /cp 2019-04-19 Paolo Carlini PR c++/89900 * pt.c (fn_type_unification): When handling null explicit arguments do not special case non-parameter packs. /testsuite 2019-04-19 Paolo Carlini PR c++/89900 * g++.dg/cpp0x/pr89900-1.C: New. * g++.dg/cpp0x/pr89900-2.C: Likewise. * g++.dg/cpp0x/pr89900-3.C: Likewise. * g++.dg/cpp0x/pr89900-4.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr89900-1.C trunk/gcc/testsuite/g++.dg/cpp0x/pr89900-2.C trunk/gcc/testsuite/g++.dg/cpp0x/pr89900-3.C trunk/gcc/testsuite/g++.dg/cpp0x/pr89900-4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug translation/90118] Missing space between words
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90118
--- Comment #7 from Christophe Lyon ---
(In reply to Roland Illig from comment #5)
> It would be good if the check-internal-format-escaping.py linter would
> actually output what is wrong in the msgid. The number of checks will
> increase as I'm trying to translate the rest of GCC 9, therefore it will
> become more difficult to guess what is wrong with a translation. Ideally
> this linter should follow the GCC guidelines for diagnostics, which are
> described in
> https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Diagnostics.html.
Do you mean something like that?
diff --git a/contrib/check-internal-format-escaping.py
b/contrib/check-internal-format-escaping.py
index 9c62586..802dff2 100755
--- a/contrib/check-internal-format-escaping.py
+++ b/contrib/check-internal-format-escaping.py
@@ -53,15 +53,19 @@ for i, l in enumerate(lines):
for p in parts:
if p.startswith('-'):
if len(p) >= 2 and (p[1].isalpha() and p != '-INF'):
-print('%s: %s' % (origin, text))
+reason = 'Illegal string after "-"'
+print('%s: %s: %s' % (origin, reason, text))
elif p.startswith('__builtin_'):
-print('%s: %s' % (origin, text))
+reason = 'Starts with _builtin_'
+print('%s: %s: %s' % (origin, reason, text))
if re.search("[^%]'", p):
-print('%s: %s' % (origin, text))
+reason = 'Illegal single quote'
+print('%s: %s: %s' % (origin, reason, text))
# %< should not be preceded by a non-punctuation
# %character.
if re.search("[a-zA-Z0-9]%<", p):
-print('%s: %s' % (origin, text))
+reason = 'Illegal character before %<'
+print('%s: %s: %s' % (origin, reason, text))
j += 1
origin = None
[Bug c++/90185] New: diagnostic "argument pack of characters" sounds like a complaint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90185 Bug ID: 90185 Summary: diagnostic "argument pack of characters" sounds like a complaint Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From cp/parser.c: /* http://cplusplus.github.io/EWG/ewg-active.html#66 */ pedwarn (DECL_SOURCE_LOCATION (decl), OPT_Wpedantic, "ISO C++ did not adopt string literal operator templa" "tes taking an argument pack of characters"); First, the words "templa" and "tes" should not be split. Second, this diagnostic doesn't conform to the GCC Guidelines for Diagnostics, which say that diagnostics should be helpful and lead the reader into the right direction. The part "ISO C++ did not accept" is not helpful at all. So what? When? What were the circumstances? What would have happened if they had adopted them? And what does this all mean for me? How do I fix my code when I get this warning? That's the essential question that the diagnostic should answer.
[Bug c++/90184] New: confusing diagnostic "attribute using prefix"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90184 Bug ID: 90184 Summary: confusing diagnostic "attribute using prefix" Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From cp/parser.c: pedwarn (input_location, 0, "attribute using prefix only available " "with %<-std=c++17%> or %<-std=gnu++17%>"); The words "attribute using prefix" can be interpreted by humans in really many different ways: - "attribute" can be a noun or an adjective - "using" can be a verb or the C++ keyword Is this about an "attribute that is using a prefix"? Is this about a "prefix to an attribute called "using""? Is this about a prefix called "attribute using"? Since the comment above this diagnostic mentions that "attribute-using-prefix" is a fixed term in the C++ grammar, the diagnostic should use hyphens instead of spaces.
[Bug translation/90183] New: ambiguous diagnostics "only available with"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90183 Bug ID: 90183 Summary: ambiguous diagnostics "only available with" Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- For example: pedwarn (cp_lexer_peek_token (parser->lexer)->location, OPT_Wpedantic, "nested inline namespace definitions only " "available with %<-std=c++2a%> or %<-std=gnu++2a%>"); Should this be really "only available with", or shouldn't it better be "only available since" or "only available starting with"?
[Bug translation/90182] New: missing space in multiline string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90182
Bug ID: 90182
Summary: missing space in multiline string literal
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
Fixing this issue for good is being done in bug 79618. That is more complicated
than "trivial".
In this bug I collect the trivial occurrences that should be fixed
individually, until the general solution is ready.
From cp/decl.c:
error ("too many braces around scalar initializer"
"for type %qT", type);
[Bug translation/90163] untranslated placeholder in warn_once_call_ms2sysv_xlogues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90163 --- Comment #2 from Daniel Santos --- Yes, this is mine. Does this only become untranslatable when feature is "static call chains"? iiuc, static call chains are only used with nested functions (a GNU C extension) and closure functions -- is this correct? So using the descriptor "static call chains" is probably bad in the first place. We might be able to just change this to "nested functions". But given that, what would be the ideal way to present this? This is one of those things that *could* be implemented but was initially deemed to be more work than it would be worth. It would be better to disable -mcall-ms2sysv-xloguesthe for the affected functions, but this is pretty much for Wine and, to my knowledge, we haven't encountered this error in the wild.
[Bug c/60591] Report enum conversions as part of Wconversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60591
--- Comment #4 from Jonny Grant ---
Clang++ gives a nice error, can gcc improve to also make it clear it is an
enum?
-Wall -Wconversion -Wextra
1
Find
x86-64 clang (trunk) - 349ms
#1 with x86-64 clang (trunk)
:8:9: error: assigning to 'enum hello' from incompatible type 'enum
things'
h = a;
^
1 error generated.
Compiler returned: 1
#1 with x86-64 gcc (trunk)
: In function 'int main()':
:8:9: error: cannot convert 'things' to 'hello' in assignment
8 | h = a;
| ^
| |
| things
Compiler returned: 1
enum things { thing=-1 };
enum hello {t};
int main()
{
enum things a;
a= thing;
enum hello h;
h = a;
return (int)a;
}
[Bug c/60591] Report enum conversions as part of Wconversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60591
Jonny Grant changed:
What|Removed |Added
CC||jg at jguk dot org
--- Comment #3 from Jonny Grant ---
Clang++ gives a signedness conversion warning that g++ doesn't for C++ code.
#1 with x86-64 clang (trunk)
:4:22: warning: implicit conversion changes signedness: 'things' to
'unsigned int' [-Wsign-conversion]
unsigned int i = thing;
~ ^
1 warning generated.
Compiler returned: 0
enum things { thing=-1 }; //< declaration of a constant of type int
int main()
{
unsigned int i = thing;
return (int)i;
}
[Bug inline-asm/90181] Feature request: provide a way to explicitly select specific named registers in constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181 --- Comment #1 from Andreas Schwab --- x86 doesn't support this either. It just happens to have a few register classes that consist of a single register, but only because of ISA constraints.
[Bug c++/90138] [7/8 Regression] ICE on invalid in contains_struct_check()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90138 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.0 Resolution|--- |FIXED Summary|[7/8/9 Regression] ICE on |[7/8 Regression] ICE on |invalid in |invalid in |contains_struct_check() |contains_struct_check() Known to fail||7.4.0, 8.3.0 --- Comment #5 from Jakub Jelinek --- Fixed for 9.1+ so far. error-recovery, so not backporting it to release branches.
[Bug middle-end/90139] [9 Regression] ICE in emit_block_move_hints, at expr.c:1601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug c/89888] [7/8 Regression] When switch controlling expression is promoted from type narrower than int, GCC does not diagnose identical cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89888 Jakub Jelinek changed: What|Removed |Added Summary|[7/8/9 Regression] When |[7/8 Regression] When |switch controlling |switch controlling |expression is promoted from |expression is promoted from |type narrower than int, GCC |type narrower than int, GCC |does not diagnose identical |does not diagnose identical |cases |cases --- Comment #7 from Jakub Jelinek --- Fixed for 9.1 (so far).
[Bug c++/90108] ICE: Segmentation fault (in c_tree_chain_next)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90108 Jakub Jelinek changed: What|Removed |Added Known to work||9.0 Known to fail|9.0 | --- Comment #5 from Jakub Jelinek --- Fixed on the trunk.
[Bug middle-end/90139] [9 Regression] ICE in emit_block_move_hints, at expr.c:1601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Apr 19 11:58:11 2019 New Revision: 270457 URL: https://gcc.gnu.org/viewcvs?rev=270457=gcc=rev Log: PR middle-end/90139 * tree-outof-ssa.c (get_temp_reg): If reg_mode is BLKmode, return assign_temp instead of gen_reg_rtx. * gcc.c-torture/compile/pr90139.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr90139.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-outof-ssa.c
[Bug c++/90138] [7/8/9 Regression] ICE on invalid in contains_struct_check()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90138 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Apr 19 11:57:23 2019 New Revision: 270456 URL: https://gcc.gnu.org/viewcvs?rev=270456=gcc=rev Log: PR c++/90138 * pt.c (process_template_parm): Set decl to pushdecl result. If !is_non_type, also set parm to that. * g++.dg/template/pr90138.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/pr90138.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c/89888] [7/8/9 Regression] When switch controlling expression is promoted from type narrower than int, GCC does not diagnose identical cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89888 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Apr 19 11:56:07 2019 New Revision: 270455 URL: https://gcc.gnu.org/viewcvs?rev=270455=gcc=rev Log: PR c/89888 * c-common.h (c_add_case_label): Remove orig_type and outside_range_p arguments. (c_do_switch_warnings): Remove outside_range_p argument. * c-common.c (check_case_bounds): Removed. (c_add_case_label): Remove orig_type and outside_range_p arguments. Don't call check_case_bounds. Fold low_value as well as high_value. * c-warn.c (c_do_switch_warnings): Remove outside_range_p argument. Check for case labels outside of range of original type here and adjust them. c/ * c-typeck.c (struct c_switch): Remove outside_range_p member. (c_start_case): Don't clear it. (do_case): Adjust c_add_case_label caller. (c_finish_case): Adjust c_do_switch_warnings caller. cp/ * decl.c (struct cp_switch): Remove outside_range_p member. (push_switch): Don't clear it. (pop_switch): Adjust c_do_switch_warnings caller. (finish_case_label): Adjust c_add_case_label caller. testsuite/ * c-c++-common/pr89888.c: New test. * g++.dg/torture/pr40335.C: Change dg-bogus into dg-warning. Don't expect -Wswitch-unreachable warning. Added: trunk/gcc/testsuite/c-c++-common/pr89888.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/c-family/c-warn.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/torture/pr40335.C
[Bug translation/90164] wrong tense in ABI change diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90164 --- Comment #2 from Roland Illig --- (In reply to Martin Sebor from comment #1) > Confirmed. There seems to be little consistency between "changes" and "has > changed" -- it's 11 vs 6. To me it looks completely consistent. If something changed in the GCC history, it's "changed". If something is changing in the current GCC major version (which GCC 8 was last year), it's "changes". It's just that whoever wrote that code didn't remember to update the word to "changed" after the release. The other diagnostics refer to options that the GCC user can actively influence at any time, therefore "changes" is appropriate. In summary, it's really only this one "GCC 8 changed" that is inconsistent.
[Bug inline-asm/90181] New: Feature request: provide a way to explicitly select specific named registers in constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181
Bug ID: 90181
Summary: Feature request: provide a way to explicitly select
specific named registers in constraints
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: nfxjfg at googlemail dot com
Target Milestone: ---
Currently, inline assembler constraints have no way to select an explicitly
named register. Apparently you're supposed to use register variables. There is
even text that register variables exist only for this use case.
For example, suppose you want to pass something through the register a7 on the
RISC-V platform. You need to do:
void call_ecall(size_t num)
{
register size_t r_a7 __asm("a7") = num;
__asm volatile("ecall" : : "r" (r_a7) : "memory");
}
This gets awkward fast. It adds a lot of extra noise if you have many registers
to pass (the ecall instruction provides an example where this may be needed).
The semantics are also not entirely clear: will r_a7 occupy the a7 register for
the entire function (suppose there is more C code around it)? What if
call_ecall gets inlined into a larger function? I think the intended (and
actual) semantics are that it's effective only at the points where it's passed
with register inline asm constraints.
Why can't this just be:
void call_ecall(size_t num)
{
__asm volatile("ecall" : : "a7" (num) : "memory");
}
Some architectures do support this (like x86), but not all.
If this is not possible, I'd be nice if the gcc developers could establish why
not, and in particular why a new architecture/backend like RISC-V does not.
[Bug translation/90180] ambiguous diagnostic for "out of range"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90180 --- Comment #1 from Roland Illig --- While here, the two diagnostics in s390_const_operand_ok are very similar. It would be nice if the first of them had the same text as the second one, passing the 0 as an argument.
[Bug translation/90180] New: ambiguous diagnostic for "out of range"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90180
Bug ID: 90180
Summary: ambiguous diagnostic for "out of range"
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From s390.c:
error ("constant argument %d for builtin %qF is out of range "
"(0..%wu)", argnum, decl,
(HOST_WIDE_INT_1U << bitwidth) - 1);
In other places, the round parentheses are used to exclude one edge of the
interval, like in [0..size). In the German translation I have therefore omitted
the parentheses:
... liegt außerhalb des Bereichs 0..%wu
[Bug translation/90148] Closing quote in wrong position in plugin.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90148
--- Comment #4 from Roland Illig ---
From rx.c:
error ("use %<__builtin_rx_mvtc%> (0, ... ) to write arbitrary values to
PSW");
The closing quote should be after the closing parenthesis.
[Bug translation/90179] New: typo in diagnostic for unrecognized control register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90179 Bug ID: 90179 Summary: typo in diagnostic for unrecognized control register Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From rx.c: warning (0, "unrecognized control register number: %d" "- using %", (int) INTVAL (op)); Between the %d and the hyphen should be a space.
[Bug translation/90148] Closing quote in wrong position in plugin.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90148
--- Comment #3 from Roland Illig ---
From rs6000/linux64.h:
error ("%<-mcmodel incompatible with other toc options%>"); \
The closing quote should be directly behind the "-mcmodel".
[Bug testsuite/82920] cet test failures on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82920 Iain Sandoe changed: What|Removed |Added Keywords||ABI, wrong-code --- Comment #6 from Iain Sandoe --- This will need a similar patch for 8.x Note that the target-supports test for set should include the "-fcf-protection" flag as noted in comment #3. That is not included in the patch above.
[Bug testsuite/82920] cet test failures on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82920 --- Comment #5 from Iain Sandoe --- Created attachment 46208 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46208=edit Patch for codegen and testsuite This is not just a testsuite issue, there are multiple places where incorrect code is generated because the output mechanism doesn't use __USER_LABEL_PREFIX__. Thus this is breaking ABI on Darwin - the fact that there's a relatively small number of test fails is only because most of the tests are compile-only and just test what is generated (so there is nothing catching the wrong code except a single test that does link). Once the output is corrected there are a lot of fails and thus the test-suite part of the patch is large, if mostly mechanical. Darwin folks, please test this - I have limited test resources for the next couple of weeks.
[Bug translation/90119] Merge translation msgids that only differ in placeholders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119 --- Comment #4 from Roland Illig --- Created attachment 46207 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46207=edit linter that checks diagnostics that only differ in placeholder content Using polib, writing the linter was not trivial, but still easy. When you consider to commit this, please coordinate with bug 90176 since I have submitted an older version of the linter there, too. Since the linter gets more and more features, it may be the right time to rename it to something more generic.
[Bug libstdc++/90045] [9 Regression] fails to build a rx-elf cross toolchain with C++ enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #13 from Nick Clifton --- FYI - I have now checked in a patch to the RX assembler which fixes this problem. Martin - I will leave it to you to verify that the build now works (since I am lazy, and it is the start of a long weekend) but if there are problems please let me know. Cheers Nick
[Bug translation/90118] Missing space between words
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90118 --- Comment #6 from Christophe Lyon --- Author: clyon Date: Fri Apr 19 09:08:49 2019 New Revision: 270454 URL: https://gcc.gnu.org/viewcvs?rev=270454=gcc=rev Log: PR translation/90118 Missing space between words 2019-04-19 Christophe Lyon PR translation/90118 contrib/ * check-internal-format-escaping.py: Check that %< is not next to a word. gcc/ * config/aarch64/aarch64.c (aarch64_override_options_internal): Add missing space before %<. Modified: trunk/contrib/ChangeLog trunk/contrib/check-internal-format-escaping.py trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c
[Bug translation/90176] diagnostics should generally contain underscore only inside quotes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90176 Roland Illig changed: What|Removed |Added Attachment #46204|0 |1 is obsolete|| --- Comment #2 from Roland Illig --- Created attachment 46206 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46206=edit linter ported to using polib
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 Jakub Jelinek changed: What|Removed |Added Attachment #46202|0 |1 is obsolete|| Attachment #46203|0 |1 is obsolete|| --- Comment #76 from Jakub Jelinek --- Created attachment 46205 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46205=edit gcc9-pr89093.patch Updated patch.
[Bug translation/90176] diagnostics should generally contain underscore only inside quotes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90176 --- Comment #1 from Roland Illig --- Created attachment 46204 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46204=edit linter ported to using polib I rewrote the linter to use polib. As this is a complete rewrite, a diff would be less readable. I also added the check for underscores outside of %. It finds many occurrences. The ones in fortran/simplify.c are mostly internal function names, related to internal compiler errors. In the German translation, these are left untranslated, and only prefixed by "Interner Fehler: ". The ones in config/arm/arm-builtins.c refer to names of builtin functions and are really boring and error-prone to translate, as pointed out in bug 90119. The ones in tree.c do not conform to the GCC Guidelines for Diagnostics since they use GCC-internal words like TYPE_METHOD_BASETYPE, therefore they are left untranslated in the German translation, and only prefixed by "Interner Fehler: ". It's exactly this use of internal identifiers I wanted to show by filing this bug.
[Bug inline-asm/67944] GCC emits unnecessary push/pop for callee-save reads.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67944 Alex Reinking changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Alex Reinking --- Closing as invalid per Segher's comments.
[Bug rtl-optimization/90168] context-sensitive local register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90168 Eric Botcazou changed: What|Removed |Added Status|WAITING |NEW Version|unknown |9.0 Severity|minor |enhancement
[Bug c++/90178] New: Missed optimization: duplicated terminal basic block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90178
Bug ID: 90178
Summary: Missed optimization: duplicated terminal basic block
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alex.reinking at gmail dot com
Target Milestone: ---
The following short C program,
int* find_ptr(int* mem, int sz, int val) {
for (int i = 0; i < sz; i++) {
if (mem[i] == val) {
return [i];
}
}
return nullptr;
}
compiles to the following on GCC (trunk) with -O3 -march=skylake on Godbolt.
find_ptr(int*, int, int):
mov rax, rdi
testesi, esi
jle .L4 ## Why not .L8?
lea ecx, [rsi-1]
lea rcx, [rdi+4+rcx*4]
jmp .L3
.L9:
add rax, 4
cmp rax, rcx
je .L8
.L3:
cmp DWORD PTR [rax], edx
jne .L9
ret
.L8:
xor eax, eax
ret
.L4:
xor eax, eax
ret
Godbolt link: https://godbolt.org/z/WczJ3J
Here the terminal basic blocks .L8 and .L4 are identical. It seems to me that
there is no benefit to keeping .L4 around, and jumps should be redirected to
.L8. Disabling AVX via -mno-avx eliminates the duplicate. However, a similar
code generation quirk exists in Clang for this program, so I apologize if there
is a microarchitectural subtlety I'm missing here.
Godbolt link for Clang comparison: https://godbolt.org/z/2uVZ8v
[Bug c++/90108] ICE: Segmentation fault (in c_tree_chain_next)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90108 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Apr 19 08:24:05 2019 New Revision: 270453 URL: https://gcc.gnu.org/viewcvs?rev=270453=gcc=rev Log: PR c++/90108 * c-decl.c (merge_decls): If remove is main variant and DECL_ORIGINAL_TYPE is some other type, remove a DECL_ORIGINAL_TYPE variant that has newdecl as TYPE_NAME if any. * decl.c (duplicate_decls): If remove is main variant and DECL_ORIGINAL_TYPE is some other type, remove a DECL_ORIGINAL_TYPE variant that has newdecl as TYPE_NAME if any. * c-c++-common/pr90108.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr90108.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/81598] -fsanitize=enum does not detect range violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81598
Julien Blanc changed:
What|Removed |Added
CC||julien.blanc at sprinte dot eu
--- Comment #9 from Julien Blanc ---
I recently ran into this while trying to use -fsanitize=enum for the codebase.
The situation is worse for C++ enum class : since you can only assign them with
static_cast, no load check can be done (clang also fails to detect such cases).
Here’s a sample code that should trigger but does not :
#include
enum class Foo
{
foo1 = 0,
foo2 = 1
};
std::ostream& operator<<(std::ostream& o, Foo foo)
{
switch(foo)
{
case Foo::foo1:
return o << "foo1";
case Foo::foo2:
return o << "foo2";
}
return o << "unknown";
}
int main()
{
Foo foo = static_cast(3);
std::cout << foo << std::endl;
return 0;
}
$ g++ -fsanitize=enum -fsanitize=undefined -fno-sanitize-recover enum.cpp
$ ./a.out
unknown
$
Note that clang++ is no better :
$ clang++-7 -fsanitize=enum -fsanitize=undefined -fno-sanitize-recover=all
enum.cpp
$ ./a.out
unknown
$
But i’d expect both checkers to detect such misuse. While it could be valid
code, there’s a high chance that its a bug. Ideally an attribute could be used
if it is expected behaviour.
[Bug rtl-optimization/90168] context-sensitive local register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90168
--- Comment #2 from Feng Xue ---
(In reply to Eric Botcazou from comment #1)
> > Supposed a function as the following, in which 'cond', 'S1' and 'S2' are
> > completely irrelevant, means they do not access same variables(in term of
> > RA, they own separate live range set).
> >
> > f1()
> > {
> > if (cond) {
> > S1
> > } else {
> > S2
> > }
> > }
> >
> > Ideally, we can expect that register allocation on 'S1'is totally
> > independent of 'S2', w or w/o which makes no difference.
>
> This seems a rather far-fetched assumption, to say the least. This would
> essentially imply that no global optimization is applied to the function.
>
> > Its result should be same as below function consisting of only 'S1':
> >
> > f2()
> > {
> > S1
> > }
> >
> > But we found gcc does not has this property. Strictly speaking, this is not
> > a bug, but exposes some kind of instability in code generation, has
> > undeterminable impact on some optimization, such as inlining.
>
> And do you know of any non-toy/production compiler that has the property?
llvm has, and icc nearly has(only minor difference in register number, but
completely same spills).
>
> > Investigation shows this is related to integer-based frequency normalization
> > (REG_FREQ_FROM_BB) used by RA, which always rounds up a small frequency
> > (less than 1) to 1. In foo1(), introduction of new code makes profile counts
> > of CODES be decreased, so that impact of frequency normalization error
> > becomes more significant and actually distorts original proportion of
> > profile counts among basic blocks in CODES. For example, in foo(), two
> > blocks have counts of 3 and 100 receptively, and in foo1(), they become 0.3
> > and 10, after rounding up, they are 1 and 10, thus proportion is changed
> > from (3 vs 100) to (1 vs 10).
> >
> > Possible solution might be to adjust two scale factors used by
> > REG_FREQ_FROM_BB : REG_FREQ_MAX and BB_FREQ_MAX, or to use float type to
> > hold frequency?
>
> Which version of the compiler are you using? This changed in GCC 8.
GCC trunk (9.0.1 20190325)
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 --- Comment #75 from Jakub Jelinek --- It failed for me as well. And a GCC version check won't really help when using earlier GCC 9 snapshot as system compiler (though, admittedly that isn't supported). Another option would be to define the attribute only #ifdef IN_RTS, because when it is #ifdef IN_GCC_FRONTEND, it is compiled with -fno-exceptions and so won't be really invoked.
[Bug rtl-optimization/90168] context-sensitive local register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90168
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2019-04-19
CC||ebotcazou at gcc dot gnu.org
Summary|Unstable register |context-sensitive local
|allocation result for same |register allocation
|source code |
Ever confirmed|0 |1
Severity|normal |minor
--- Comment #1 from Eric Botcazou ---
> Supposed a function as the following, in which 'cond', 'S1' and 'S2' are
> completely irrelevant, means they do not access same variables(in term of
> RA, they own separate live range set).
>
> f1()
> {
> if (cond) {
> S1
> } else {
> S2
> }
> }
>
> Ideally, we can expect that register allocation on 'S1'is totally
> independent of 'S2', w or w/o which makes no difference.
This seems a rather far-fetched assumption, to say the least. This would
essentially imply that no global optimization is applied to the function.
> Its result should be same as below function consisting of only 'S1':
>
> f2()
> {
> S1
> }
>
> But we found gcc does not has this property. Strictly speaking, this is not
> a bug, but exposes some kind of instability in code generation, has
> undeterminable impact on some optimization, such as inlining.
And do you know of any non-toy/production compiler that has the property?
> Investigation shows this is related to integer-based frequency normalization
> (REG_FREQ_FROM_BB) used by RA, which always rounds up a small frequency
> (less than 1) to 1. In foo1(), introduction of new code makes profile counts
> of CODES be decreased, so that impact of frequency normalization error
> becomes more significant and actually distorts original proportion of
> profile counts among basic blocks in CODES. For example, in foo(), two
> blocks have counts of 3 and 100 receptively, and in foo1(), they become 0.3
> and 10, after rounding up, they are 1 and 10, thus proportion is changed
> from (3 vs 100) to (1 vs 10).
>
> Possible solution might be to adjust two scale factors used by
> REG_FREQ_FROM_BB : REG_FREQ_MAX and BB_FREQ_MAX, or to use float type to
> hold frequency?
Which version of the compiler are you using? This changed in GCC 8.
[Bug target/90177] New: nds32: diagnostic says "must be enable"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90177
Bug ID: 90177
Summary: nds32: diagnostic says "must be enable"
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From nds32.c:
error ("Disable FPU ISA, "
"the ABI option must be enable %<-mfloat-abi=soft%>");
else
error ("%<-mabi=2fp+%> option only support when FPU available, "
"must be enable %<-mext-fpu-sp%> or %<-mext-fpu-dp%>");
As the German translator, I'm not sure what to make out of these two
diagnostics.
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #11 from Vittorio Zecca ---
After applying your fixes I still have overflow compiling the following
// Must be compiled with nonzero optimization
//../../gcc/gcc/poly-int.h:1095:5: runtime error: signed integer
overflow: 9223372036854775807 * 8 cannot be represented in type 'long
int'
// 87042
const char a[] = {};
int b() { '\0' == a[9223372036854775807]; }
../../gcc/gcc/poly-int.h:1095:5: runtime error: signed integer
overflow: 9223372036854775807 * 8 cannot be represented in type 'long
int'
Remember must be compiled with nonzero optimization
[Bug translation/90176] New: diagnostics should generally contain underscore only inside quotes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90176
Bug ID: 90176
Summary: diagnostics should generally contain underscore only
inside quotes
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From nds32.c:
if (!TREE_PUBLIC (decl))
error ("indirect_call attribute can%'t apply for static function");
Names of attributes or pragmas are usually %. Since many attributes
correspond to an English adjective, this can produce ambiguous warnings like
this:
warning (OPT_Wattributes,
"critical attribute has no effect on interrupt functions");
The "critical attribute" is so difficult to decide that I think only humans can
do this, as of April 2019. The case of "indirect_call attribute" is easier to
decide though since written everyday English doesn't make use of the underscore
character.
It's debatable whether words like x86_64 need to be quoted in every case. To
find out which words need to be quoted and which words don't, the
check-internal-format-escaping.py should be extended to warn about all words
that contain an underscore and appear outside of any %.
To do this, it's probably time to switch the linter to using polib, so that
diagnostics that consist of multiple lines can be checked correctly, such as:
msgid ""
"%<"
"this_is_ok"
"%>"
" "
"and_this_is_not"
The check might then be:
for each occurrence of "_" in msg.msgid:
before = text before the "_"
if count("%<", before) == count("%>", before):
warn(msg, 'underscore outside of quotes')
[Bug target/90175] New: ambiguous wording "critical attribute" in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90175
Bug ID: 90175
Summary: ambiguous wording "critical attribute" in diagnostic
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From msp430.c:
if (is_critical_func (* node))
{
warning (OPT_Wattributes,
"critical attribute has no effect on interrupt functions");
DECL_ATTRIBUTES (*node) = remove_attribute (ATTR_CRIT,
DECL_ATTRIBUTES (*
node));
}
The words "critical attribute" could either mean an attribute that is critical
for producing correct code. Or, alternatively, they could mean "the
% attribute", which is more probable in this case.
While here, I noticed that the warning message "naked functions cannot be
reentrant" is never translated properly. This message, and the other ones must
be enclosed in N_(...).
It's unfortunate that the function attributes are often named after English
adjectives, so that constructing these ambiguous sentences is possible in the
first place.
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 Bernd Edlinger changed: What|Removed |Added Attachment #46200|0 |1 is obsolete|| --- Comment #74 from Bernd Edlinger --- Created attachment 46203 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46203=edit gcc9-pr89093.patch Same patch, just guard the target attribute with a version check, so that supported boot-strap configurations should work
[Bug translation/90163] untranslated placeholder in warn_once_call_ms2sysv_xlogues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90163 Eric Gallager changed: What|Removed |Added CC||daniel.santos at pobox dot com, ||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- pretty sure Daniel Santos did this code
[Bug c++/52961] Make -Wempty-body less noisy and enable it with -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52961
--- Comment #12 from Eric Gallager ---
(In reply to Manuel López-Ibáñez from comment #10)
> Clang... suggests placing the ";" on a different line to silence
> the warning:
>
>
> warning: if statement has empty body [-Wempty-body]
> if(a);
>^
> note: put the semicolon on a separate line to silence this warning
>
> which seems a nicer way to silence the warning instead of ugly { ; }
That's a debatable opinion; I think the braces do a better job expressing
grouping
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 --- Comment #73 from Bernd Edlinger --- Okay, the requirement is only to be able to boot-strap with a released gcc version, so gcc-8 should not use the pragma, while gcc-9 should use the pagma. I was able to bootstrap from x86_64 -> arm cross -> arm native that worked fine. I will guard the pragma with a gcc-version check.
