[Bug hsa/86948] Internal compiler error compiling brig.dg/test/gimple/mulhi.hsail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86948 --- Comment #5 from Pekka Jääskeläinen --- Hi Alexander. I just verified that the patch fixes the make check-brig regression here. Are you going to post this to ML for review or how shall we proceed?
[Bug debug/86985] Generated DWARF does not distinguish between zero-length and flexible array types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86985 --- Comment #3 from Omar Sandoval --- They are not equivalent in GCC, see https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html. In particular, flexible arrays cannot be the only member in a struct, cannot be a member of a union, cannot be used as a dimension of a multidimensional array, and can have a static initializer with elements; the opposite is true for zero length arrays.
[Bug debug/86985] Generated DWARF does not distinguish between zero-length and flexible array types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86985 --- Comment #2 from Andrew Pinski --- Considering GCC considers zero length array as the same as flexible array types, I don't think this is really an issue. >this fails in some cases where zero-length and flexible array types are not interchangable. There should never be a possiblity of this anyways. NOTE zero-length array types are a GCC extension anyways.
[Bug debug/86985] Generated DWARF does not distinguish between zero-length and flexible array types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86985 --- Comment #1 from Omar Sandoval --- Posted a patch here: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00994.html.
[Bug c++/86986] New: Unexpected errors for template parameter pack in a template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86986
Bug ID: 86986
Summary: Unexpected errors for template parameter pack in a
template template parameter
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: v.reshetnikov at gmail dot com
Target Milestone: ---
/* SOURCE */
template
struct X {
template class...>
struct Y { };
};
using type = X::Y<>;
/*** END SOURCE ***/
/* OUTPUT */
: In instantiation of 'struct X':
:7:20: required from here
:4:12: error: '' is not a valid type for a
template non-type parameter
4 | struct Y { };
|^
:4:12: error: '' is not a valid type for a
template non-type parameter
:7:22: error: 'Y' in 'struct X' does not name a template type
7 | using type = X::Y<>;
| ^
Compiler returned: 1
/*** END OUTPUT ***/
Clang compiles this code successfully
[Bug debug/86985] New: https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86985
Bug ID: 86985
Summary: https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: osandov at osandov dot com
Target Milestone: ---
It is currently impossible for a debugger to distinguish between a zero-length
and a flexible array given the debug info generated by GCC:
$ cat zero_length.c
struct {
int foo;
int bar[0];
} baz;
$ cat flexible.c
struct {
int foo;
int bar[];
} baz;
$ gcc -g -c zero_length.c
$ gcc -g -c flexible.c
$ gdb -batch -ex 'ptype baz' zero_length.o
type = struct {
int foo;
int bar[];
}
$ gdb -batch -ex 'ptype baz' flexible.o
type = struct {
int foo;
int bar[];
}
However, when compiling with clang:
$ clang -g -c zero_length.c
$ clang -g -c flexible.c
$ gdb -batch -ex 'ptype baz' zero_length.o
type = struct {
int foo;
int bar[0];
}
$ gdb -batch -ex 'ptype baz' flexible.o
type = struct {
int foo;
int bar[];
}
This distinction would be useful for certain tools. For example, I have a tool
which feeds the structure definitions from debug info back into a C compiler,
but this fails in some cases where zero-length and flexible array types are not
interchangable.
[Bug tree-optimization/86853] sprintf optimization for wide strings doesn't account for conversion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86853 --- Comment #2 from Jeffrey A. Law --- Author: law Date: Fri Aug 17 04:01:14 2018 New Revision: 263612 URL: https://gcc.gnu.org/viewcvs?rev=263612&root=gcc&view=rev Log: gcc/ChangeLog: PR tree-optimization/86853 * gimple-ssa-sprintf.c (struct format_result): Rename member. (struct fmtresult): Add member and initialize it in ctors. (format_character): Handle %C. Extend range to NUL. Set MAYFAIL. (format_string): Handle %S the same as %ls. Set MAYFAIL. (format_directive): Set POSUNDER4K when MAYFAIL is set. (parse_directive): Handle %C same as %c. (sprintf_dom_walker::compute_format_length): Adjust. (is_call_safe): Adjust. gcc/testsuite/ChangeLog: PR tree-optimization/86853 * gcc.dg/tree-ssa/builtin-sprintf-10.c: New test. * gcc.dg/tree-ssa/builtin-sprintf-11.c: New test. * gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: Adjust. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-10.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-11.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-sprintf.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c
[Bug c++/16166] -Weffc++ finer granularity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16166 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #13 from Eric Gallager --- (In reply to Jonathan Wakely from comment #12) > Created attachment 43443 [details] > Patch to split -Weffc++ into separate options. > > This adds several new warning options to replace -Weffc++, and makes > -Weffc++ enable them all. Right I've been meaning to try this patch but couldn't, due to having been blocked from bootstrapping for a while by bug 82092... it looks like that one might be getting fixed around now though, so once I've verified that, I'll try this...
[Bug c++/86980] Lambda function with return type rvalue reference dtor issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86980
--- Comment #3 from Neeraj ---
Ah! Alright so the following two code snippets are equivalent.
// --
auto f = []() {
Traceable tmp;
return std::move(tmp);
};
// ---
auto f = []() -> Traceable {
Traceable tmp;
return std::move(tmp);
};
// x--
[Bug fortran/84539] ICE and segfault with assignment to CLASS(*) array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84539 --- Comment #4 from Neil Carlson --- Update with 8.2.0 The ICE is gone, but a run time segfault remains: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f82986c06df in ??? #1 0x400754 in MAIN__ at gfortran-20180223a.f90:2 #2 0x400979 in main at gfortran-20180223a.f90:7 Segmentation fault (core dumped)
[Bug target/86984] invalid relocation accessing a const char arrray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86984 --- Comment #2 from Martin Sebor --- The excessive offset appears in the first RTL dump: $ grep -A3 -B3 2305843009213693936 plural.c.230r.expand (insn 87 86 88 10 (set (reg:DI 154) (lshiftrt:DI (reg:DI 155) (const_int 3 [0x3]))) -1 (expr_list:REG_EQUAL (const_int 2305843009213693936 [0x1ff0]) (nil))) (insn 88 87 89 10 (set (reg/f:DI 152) (plus:DI (reg:DI 153)
[Bug target/86984] invalid relocation accessing a const char arrray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86984 --- Comment #1 from Martin Sebor --- Created attachment 44552 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44552&action=edit Reduced test case. Compiling the attached test case shows the invalid offsets in the assembly: $ gcc -S -O2 -Wall -Wwrite-strings -Werror -fmerge-all-constants -fno-stack-protector -mieee plural.c -o/dev/stdout | grep gprelhigh ldah $1,yypgoto+2305843009213693936($29)!gprelhigh ldah $1,yypact($29) !gprelhigh ldah $1,yytable($29)!gprelhigh ldah $1,yydefact($29) !gprelhigh ldah $2,yyr2($29) !gprelhigh ldah $15,yyr1($29) !gprelhigh ldah $1,yypgoto($29)!gprelhigh ldah $5,yycheck($29)!gprelhigh ldah $1,yydefgoto($29) !gprelhigh ldah $2,yypgoto+2305843009213693936($29)!gprelhigh ldah $2,yytable($29)!gprelhigh
[Bug target/86984] New: invalid relocation accessing a const char arrray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86984 Bug ID: 86984 Summary: invalid relocation accessing a const char arrray Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- As discussed here https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00839.html, the Alpha back end seems to emit invalid relocations for accesses to constant arrays in some cases, causing Glibc build failures. This must have been latent a bug that was triggered by the transformation of braced array initializers to STRING_CSTs in r263511 as the same issue can be reproduced by replacing the initializer with a string literal in the test case.
[Bug c++/67906] Missing warning about std::move without effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906
--- Comment #9 from Nikolay Orliuk ---
Yes. Return value optimization blocked by abusing std::move also close. Somehow
I had feeling that I saw something similar from gcc in pre-C++11 times.
Regarding sample:
struct X {
X() { }
X(const X&) { }
X(const X&&) { }
};
const X x;
const X y = std::move(x);
It shouldn't warn because std::move is effective here and makes choice between
default (const X&) and (const X&&) overloads. I.e. we are not ignoring the fact
that it is rvalue.
As I stated initially I agree that most likely templates will cause false
triggering. Like for other warnings (ex. -Wduplicated-branches ).
The main point here was to identify places that potentially migrated
incompletely. Kinda temporary flag.
Trigger rule might be: cast to rvalue for overloads one of which have slightly
different qualifiers combinations (e.g. const vs non-const).
That should a bit reduce chances of false trigerring compared to "whenever we
ignore rvalue".
If someone will want more noise they can request adding -Wsuggest-move-overload
to supported flags :)
[Bug c++/86094] [8/9 Regression] Call ABI changed for small objects with defaulted ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86094
Azat changed:
What|Removed |Added
CC||a3at.mail at gmail dot com
--- Comment #12 from Azat ---
Shouldn't such case also be warned by `g++ -Wabi=12` ?
struct noncopyable
{
public:
noncopyable(noncopyable &&) = default;
};
struct S : public noncopyable
{
int i;
};
void foo(S s) {}
[Bug target/84438] Another code pattern that breaks PDP11 with -m10: including reproducer code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84438 Patrick Conlon changed: What|Removed |Added CC||cptjustice at gmail dot com --- Comment #1 from Patrick Conlon --- gcc version 9.0.0 20180808 (experimental) (GCC) does not give me this compiler error. pdp11-aout-gcc -m10 -S 43447_divide_tp_by_10_return_remainder.c -o 43447_divide_tp_by_10_return_remainder.s outputs: cat 43447_divide_tp_by_10_return_remainder.s .text .even _div10quickm: mov r5,-(sp) mov sp,r5 add $-020,sp mov r2,-(sp) mov r3,-(sp) mov 04(r5),r0 mov (r0),-04(r5) mov 02(r0),-02(r5) mov -04(r5),r0 mov -02(r5),r1 clc ror r0 ror r1 mov r0,-020(r5) mov r1,-016(r5) mov -04(r5),r0 mov -02(r5),r1 clc ror r0 ror r1 asr r0 ror r1 mov -020(r5),r2 mov -016(r5),r3 add r0,r2 add r1,r3 adc r2 mov r2,-010(r5) mov r3,-06(r5) mov -010(r5),r0 mov -06(r5),r1 mov $04,r2 mov -010(r5),r0 mov -06(r5),r1 L_7: clc ror r0 ror r1 dec r2 bne L_7 add r0,-010(r5) add r1,-06(r5) adc -010(r5) mov -010(r5),r0 mov -06(r5),r1 mov $010,r2 mov -010(r5),r0 mov -06(r5),r1 L_8: clc ror r0 ror r1 dec r2 bne L_8 add r0,-010(r5) add r1,-06(r5) adc -010(r5) mov -010(r5),r0 mov -06(r5),r1 mov $020,r2 mov -010(r5),r0 mov -06(r5),r1 L_9: clc ror r0 ror r1 dec r2 bne L_9 add r0,-010(r5) add r1,-06(r5) adc -010(r5) clc ror -010(r5) ror -06(r5) asr -010(r5) ror -06(r5) asr -010(r5) ror -06(r5) mov -010(r5),r0 mov -06(r5),r1 asl r1 rol r0 asl r1 rol r0 add -010(r5),r0 add -06(r5),r1 adc r0 asl r1 rol r0 mov -04(r5),r2 mov -02(r5),r3 sub r0,r2 sub r1,r3 sbc r2 mov r2,-014(r5) mov r3,-012(r5) mov -014(r5),r0 mov -012(r5),r1 mov $011,r2 mov -014(r5),r0 mov -012(r5),r1 L_10: clc ror r0 ror r1 dec r2 bne L_10 mov -010(r5),r2 mov -06(r5),r3 add r0,r2 add r1,r3 adc r2 mov r2,-04(r5) mov r3,-02(r5) mov 04(r5),r0 mov -04(r5),(r0) mov -02(r5),02(r0) asl -02(r5) rol -04(r5) mov -04(r5),r0 mov -02(r5),r1 asl r1 rol r0 asl r1 rol r0 add r0,-04(r5) add r1,-02(r5) adc -04(r5) mov 04(r5),r0 mov (r0),r0 mov 02(r0),r1 sub -04(r5),r0 sub -02(r5),r1 sbc r0 mov (sp)+,r3 mov (sp)+,r2 mov r5,sp mov (sp)+,r5 rts pc cptnapalm@oracle~/s/p/p/g/84438_alan_cox> pdp11-aout-gcc -v Using built-in specs. COLLECT_GCC=pdp11-aout-gcc COLLECT_LTO_WRAPPER=/home/cptnapalm/opt/pdp11-aout/libexec/gcc/pdp11-aout/9.0.0/lto-wrapper Target: pdp11-aout Configured with: /home/cptnapalm/src/gnu/gcc/configure --target=pdp11-aout --prefix=/home/cptnapalm/opt/pdp11-aout --disable-libstdcxx --disable-nls --without-headers --enable-languages=c : (reconfigured) /home/cptnapalm/src/gnu/gcc/configure --target=pdp11-aout --prefix=/home/cptnapalm/opt/pdp11-aout --disable-libstdcxx --disable-nls --without-headers --enable-languages=c --disable-libssp : (reconfigured) /home/cptnapalm/src/gnu/gcc/configure --target=pdp11-aout --prefix=/home/cptnapalm/opt/pdp11-aout --disable-libstdcxx --disable-nls --without-headers --enable-languages=c --disable-libssp Thread model: single gcc version 9.0.0 20180808 (experimental) (GCC)
[Bug target/84437] long long casting breaks PDP-11 with -m10 model option (includes trivial reproducer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84437 Patrick Conlon changed: What|Removed |Added CC||cptjustice at gmail dot com --- Comment #1 from Patrick Conlon --- gcc version 9.0.0 20180808 (experimental) (GCC) no longer produces this compiler error. Below is the output I got: cptnapalm@oracle~/s/p/p/g/84437 > cat long_long_m10.s .text .even .globl _x _x: mov r5,-(sp) mov sp,r5 add $-014,sp mov r2,-(sp) mov r3,-(sp) mov r4,-(sp) mov 06(r5),r0 mov r0,-02(r5) mov -02(r5),r4 mov r4,-06(r5) mov -02(r5),r4 mov $017,r0 mov r0,-04(r5) mov -02(r5),r4 mov -04(r5),r0 L_4: asr r4 dec r0 bne L_4 mov r4,-010(r5) mov r4,-012(r5) mov r4,-014(r5) mov 04(r5),r4 mov -014(r5),(r4) mov -012(r5),02(r4) mov -010(r5),04(r4) mov -06(r5),06(r4) mov 04(r5),r0 mov (sp)+,r4 mov (sp)+,r3 mov (sp)+,r2 mov r5,sp mov (sp)+,r5 rts pc
[Bug rtl-optimization/59942] pdp11-aout-gcc: PDP-11/10 code generation crashes when trying to do multiple shifts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59942 Patrick Conlon changed: What|Removed |Added CC||cptjustice at gmail dot com --- Comment #1 from Patrick Conlon --- gcc version 9.0.0 20180808 (experimental) (GCC) no longer produces this compiler error. Output of pdp11-aout-gcc -m10... : .text .even .globl _main _main: mov r5,-(sp) mov sp,r5 add $-04,sp jsr pc,___main mov $023420,-02(r5) mov -02(r5),r0 mov $011,r1 mov -02(r5),r0 L_5: asr r0 dec r1 bne L_5 mov r0,-04(r5) clr r0 mov r5,sp mov (sp)+,r5 rts pc Output of -m40 option: .text .even .globl _main _main: mov r5,-(sp) mov sp,r5 add $-04,sp jsr pc,___main mov $023420,-02(r5) mov -02(r5),r0 ash $-011,r0 mov r0,-04(r5) clr r0 mov r5,sp mov (sp)+,r5 rts pc
[Bug target/59847] cast to long makes compiler crash if using option pdp-11/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59847
Patrick Conlon changed:
What|Removed |Added
CC||cptjustice at gmail dot com
--- Comment #1 from Patrick Conlon ---
On gcc 9.0.0 20180808 (experimental) this code no longer give this error.
pdp11-aout-gcc no longer produces the sxt instruction with the -m10 option, but
still does for -m40 as it should.
cptnapalm@oracle~/s/p/p/g/59847_cast_to_long_m10> pdp11-aout-gcc -v
Using built-in specs.
COLLECT_GCC=pdp11-aout-gcc
COLLECT_LTO_WRAPPER=/home/cptnapalm/opt/pdp11-aout/libexec/gcc/pdp11-aout/9.0.0/lto-wrapper
Target: pdp11-aout
Configured with: /home/cptnapalm/src/gnu/gcc/configure --target=pdp11-aout
--prefix=/home/cptnapalm/opt/pdp11-aout --disable-libstdcxx --disable-nls
--without-headers --enable-languages=c : (reconfigured)
/home/cptnapalm/src/gnu/gcc/configure --target=pdp11-aout
--prefix=/home/cptnapalm/opt/pdp11-aout --disable-libstdcxx --disable-nls
--without-headers --enable-languages=c --disable-libssp : (reconfigured)
/home/cptnapalm/src/gnu/gcc/configure --target=pdp11-aout
--prefix=/home/cptnapalm/opt/pdp11-aout --disable-libstdcxx --disable-nls
--without-headers --enable-languages=c --disable-libssp20180808 (experimental)
Thread model: single
gcc version 9.0.0 20180808 (experimental) (GCC)
cptnapalm@oracle~/s/p/p/g/59847_cast_to_long_m10> pdp11-aout-gcc -m10 -S -o
cast_to_long_m10.s cast_to_long_m10.c
cast_to_long_m10.c:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
test ()
^~~~
cptnapalm@oracle~/s/p/p/g/59847_cast_to_long_m10> cat cast_to_long_m10.s
.text
.even
.globl _test
_test:
mov r5,-(sp)
mov sp,r5
add $-06,sp
mov r2,-(sp)
clr -04(r5)
mov $012,-02(r5)
mov $012,-06(r5)
mov -06(r5),r0
mov r0,-02(r5)
mov r0,r1
mov $017,r2
mov r0,r1
L_3:
asr r1
dec r2
bne L_3
mov r1,-04(r5)
nop
mov (sp)+,r2
mov r5,sp
mov (sp)+,r5
rts pc
cptnapalm@oracle~/s/p/p/g/59847_cast_to_long_m10> pdp11-aout-gcc -m40 -S -o
cast_to_long_m40.s cast_to_long_m10.c
cast_to_long_m10.c:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
test ()
^~~~
cptnapalm@oracle~/s/p/p/g/59847_cast_to_long_m10> cat cast_to_long_m40.s
.text
.even
.globl _test
_test:
mov r5,-(sp)
mov sp,r5
add $-06,sp
clr -04(r5)
mov $012,-02(r5)
mov $012,-06(r5)
mov -06(r5),-02(r5)
sxt -04(r5)
nop
mov r5,sp
mov (sp)+,r5
rts pc
cptnapalm@oracle~/s/p/p/g/59847_cast_to_long_m10> cat cast_to_long_m10.c
test ()
{
long a = 10;
short b = 10;
a = (long) b;
}
[Bug tree-optimization/78257] missing memcmp optimization with constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78257 --- Comment #8 from Martin Sebor --- With r263561 brace-enclosed initializers for constant character arrays are handled by transforming them into STRING_CSTs. It should be possible to also handle wide character types (wchar_t, char16_t, char32_t). Handling arrays of arbitrary integers will probably take a different approach.
[Bug target/86592] [9 regression] gcc.target/powerpc/p8-vec-xl-xst-v2.c fails starting with r261510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86592 --- Comment #1 from Will Schmidt --- This should have cleared up once the gimple-folding support for unaligned loads and stores went in, and the instruction counts settled on the expected values. commit c16f12a2dc14256226e85a9a9f82b54eb1de2187 Author: willschm Date: Mon Aug 13 18:13:20 2018 + I'll keep an eye on this space to make sure. thanks,
[Bug c/86983] New: documentation inconsistent with always_inline diagnostics for computed goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86983 Bug ID: 86983 Summary: documentation inconsistent with always_inline diagnostics for computed goto Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: richard-gccbugzilla at metafoo dot co.uk Target Milestone: --- Per https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html a function containing a computed goto can be inlined (so long as no label within it is used to initialize a static variable): > The &&foo expressions for the same label might have different values if the > containing function is inlined or cloned. If a program relies on them being > always the same, __attribute__((__noinline__,__noclone__)) should be used to > prevent inlining and cloning. If &&foo is used in a static variable > initializer, inlining and cloning is forbidden. However, applying __attribute__((__always_inline__)) to a function containing a computed goto produces this diagnostic: > error: function 'void* f(void*)' can never be inlined because it contains a > computed goto ... which claims that a computed goto prevents inlining. (See https://godbolt.org/g/XFhwQq) Also, GCC warns on returning the address of a label from a function, which makes sense if different invocations of the same function can have different addresses for their labels (through inlining / cloning), but is a false positive on an example such as the one at that godbolt.org link otherwise. So, which is it? Is GCC reserving the right to inline functions containing computed gotos in some future version? (In which case, the always_inline diagnostic is somewhere between misleading and wrong, and should probably be weakened from "can never be inlined" to something like "was not inlined".) Or has the computed goto rule been changed to "functions containing computed goto will never be inlined or cloned"? (In which case the documentation is wrong, and the warning on returning the address of a label seems questionable, at least for an enabled-by-default warning, since it warns on reasonable code and there doesn't seem to be a simple syntactic way to suppress the warning.)
[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 #26 from Jonathan Wakely --- This still fails on any Debian system, such as gcc20 in the compile farm. I'd like to either make it pass, or add dg-xfail-if or dg-skip-if to the test. 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? Maybe we can change it to a different locale that still tests the same code, but using a locale that has consistent localedata across distros?
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #18 from Rainer Orth --- (In reply to qinzhao from comment #17) > the patch has been committed as: > > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=263563 The commit message lacked the ChangeLog entry fragment and didns't otherwise contain the reference to PR testsuite/86519, so bugzilla didn't pick it up. What's worse, the patch caused the testcase to regress on 32-bit sparc: +FAIL: gcc.dg/strcmpopt_6.c scan-assembler-times memcmp 2 The file has sethi %hi(memcmp), %g1 jmp %g1 + %lo(memcmp) sethi %hi(memcmp), %g1 jmp %g1 + %lo(memcmp) while for sparcv9 there's only: callmemcmp, 0 callmemcmp, 0 Seems scan-assembler-times isn't reliable here. Rainer
[Bug libstdc++/71641] 22_locale/time_get/get_date/wchar_t/4.cc runs failure if static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71641 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=31413 --- Comment #6 from Jonathan Wakely --- Yes, Debian carries a patch for glibc: localedata/locale-zh_TW.diff That has a comment referring to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352600 which has a comment from one John David Anglin linking to our own PR 31413 :-) So since this bug is specifically about static linking (which is a glibc bug) I'll move the discussion of the Debian FAIL back to PR 31413.
[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 #25 from Jonathan Wakely ---
The test is disabled unless the machine actually has the relevant locale
installed:
// { dg-require-namedlocale "zh_TW.UTF-8" }
That will be why some systems show UNSUPPORTED.
[Bug testsuite/86745] [9 regression] gcc.target/i386/avx-cvt-2.c etc. FAIL on 64-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86745 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|target |testsuite Resolution|--- |FIXED --- Comment #5 from Uroš Bizjak --- Fixed.
[Bug target/86745] [9 regression] gcc.target/i386/avx-cvt-2.c etc. FAIL on 64-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86745 --- Comment #4 from uros at gcc dot gnu.org --- Author: uros Date: Thu Aug 16 18:52:26 2018 New Revision: 263598 URL: https://gcc.gnu.org/viewcvs?rev=263598&root=gcc&view=rev Log: PR testsuite/86745 * gcc.target/i386/avx-cvt-2.c: Loosen scan-assembler strings. * gcc.target/i386/avx-cvt-2.c: Ditto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/avx-cvt-2.c trunk/gcc/testsuite/gcc.target/i386/avx2-cvt-2.c
[Bug libstdc++/71641] 22_locale/time_get/get_date/wchar_t/4.cc runs failure if static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71641 --- Comment #5 from dave.anglin at bell dot net --- On 2018-08-16 7:35 AM, redi at gcc dot gnu.org wrote: > So this is not a libstdc++ bug, it's a glibc bug. Debian's glibc 2.13 has bad > locale data for zh_TW, and all versions of glibc have the static linking bug. I vaguely recall that that this is a "political" issue. Dave
[Bug c++/86980] Lambda function with return type rvalue reference dtor issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86980
--- Comment #2 from Neeraj ---
(In reply to Jonathan Wakely from comment #1)
> This is a bug in your code, not GCC. you're returning a reference to a local
> variable, which goes out of scope, leaving a dangling reference.
>
I was just playing with alternatives, hence tried return rvalue reference. The
larger question still remains, which is what is the return type in case of the
following?
auto f = []() {
Traceable tmp;
return std::move(tmp);
};
Traceable a = f();
Additionally, the above code retains the instance till the move is complete
(see the console output below).
// ---
[MoveReturn] START
[0x7ffe53dec857] ctor Traceable
[0x7ffe53dec887] move ctor Traceable, &other = 0x7ffe53dec857
[0x7ffe53dec857] dtor Traceable
[0x7ffe53dec887] dtor Traceable
// x--
> When you don't give the lambda an explicit return type it returns by value,
> so works correctly.
>
> You should just do:
>
> auto f = []() {
> Traceable tmp;
> return tmp;
> };
>
> This returns by value and can elide the move, so is safer and faster.
I agree, but just curious to see possibilities with lambda function :)
[Bug libstdc++/71641] 22_locale/time_get/get_date/wchar_t/4.cc runs failure if static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71641 --- Comment #4 from dave.anglin at bell dot net --- On 2018-08-16 12:26 PM, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71641 > > --- Comment #3 from Jonathan Wakely --- > (In reply to John David Anglin from comment #1) >> Fails on hppa-linux with libc 2.25: > Is that a Debian system too? Yes. Currently, running Debian sid/unstable with glibc 2.27. Some people run Gentoo. Don't know if Gentoo is affected.
[Bug c/86972] [6/7/8/9 Regression] Incorrect array-bounds warning with -O2 when creating pointer from array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86972 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Martin Sebor --- The result of pointer addition or subtraction must point at an existing element of an array or just past the last one, otherwise the behavior is undefined. In the test case in comment #0 the subtraction doesn't satisfy this requirement and the warning correctly points that out. What makes you think otherwise?
[Bug c++/86911] [9 Regression] ICE in gcc/c-family/c-indentation.c:403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86911 --- Comment #3 from David Malcolm --- Does r263595 fix the issue? (it relates to having stray carriage returns somewhere above in the file, leading to line-numbering becoming confused)
[Bug c++/70693] valgrind error in get_visual_column
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70693 --- Comment #10 from David Malcolm --- Author: dmalcolm Date: Thu Aug 16 17:07:15 2018 New Revision: 263595 URL: https://gcc.gnu.org/viewcvs?rev=263595&root=gcc&view=rev Log: -Wmisleading-indentation: fix ICE in get_visual_column (PR c++/70693) PR c++/70693 reports a crash within -Wmisleading-indentation in get_visual_column, reading past the end of a source line. The issue occurs due to a stray carriage return aka '\r' aka ^M, occurring towards the end of line 35 of attachment 38289 - but not at the end itself. This carriage return confuses our line numbering: from that point in the file, the lexer (and thus location_t values) use line numbers that are one larger than those seen by input.c, "cat -n" and emacs. This discrepancy between the lexer's line numbering and input.c's line numbering leads to an out-of-range read in get_visual_column (trying to read column 8, to locate the first non-whitespace on the line containing "break;", but finding the next line, which is only 4 characters long). This patch fixes the ICE by adding a range check to get_visual_column before accessing the input.c line buffer. This is arguably papering over the root cause, but there are presumably other ways of triggering such an out-of-range read by writing to the source file after the lexer but before -Wmisleading-indentation, and we ought to be not ICE in the face of that. gcc/c-family/ChangeLog: PR c++/70693 * c-common.c (selftest::c_family_tests): Call selftest::c_indentation_c_tests. * c-common.h (selftest::c_indentation_c_tests): New decl. * c-indentation.c: Include "selftest.h". (next_tab_stop): Add "tab_width" param, rather than accessing cpp_opts. (get_visual_column): Likewise. Clarify comment. Bulletproof against reading past the end of the line. (get_first_nws_vis_column): Add "tab_width" param. (detect_intervening_unindent): Likewise. (should_warn_for_misleading_indentation): Read tab width from cpp_opts and pass around. (selftest::test_next_tab_stop): New test. (selftest::assert_get_visual_column_succeeds): New function. (ASSERT_GET_VISUAL_COLUMN_SUCCEEDS): New macro. (selftest::assert_get_visual_column_fails): New function. (ASSERT_GET_VISUAL_COLUMN_FAILS): New macro. (selftest::test_get_visual_column): New test. (selftest::c_indentation_c_tests): New function. gcc/testsuite/ChangeLog: PR c++/70693 * c-c++-common/Wmisleading-indentation-pr70693.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Wmisleading-indentation-pr70693.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-indentation.c trunk/gcc/testsuite/ChangeLog
[Bug target/86640] [8/9 regression] ICE in combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86640 Tamar Christina changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Tamar Christina --- Fixed in trunk and backported to GCC-8
[Bug middle-end/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 --- Comment #4 from joseph at codesourcery dot com --- Any unaligned access things that don't work for big-endian ARM are probably fallout from the issues with big-endian NEON (NEON architectural lane numbers are different from the architecture-independent lane numbers in GNU C vector extensions and GCC IR, and GCC expects each machine mode to have a single defined memory layout and a single defined layout in any given register, and to be able to move between core and NEON registers, and between core registers and memory, in the respective layouts used for those registers, but some NEON loads and stores for big-endian don't work with those expectations, so unaligned vector operations are limited for big-endian ARM).
[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590 --- Comment #30 from Jakub Jelinek --- The thing is that even with the foo that doesn't contain all those __builtin_constant_p 's after early inlining, we with -std=c++17 -O3 don't inline for some reason _M_construct.constprop, while we do inline it with -std=c++14. With -std=c++14 -O3 we are considering inlining _M_construct.constprop 4 times, into basic_string ctor twice and into foo twice, with -std=c++17 -O3 only 2 times, both into the ctor. Richard or Honza, can you please find out why the inliner doesn't consider inlining it into foo?
[Bug libstdc++/71641] 22_locale/time_get/get_date/wchar_t/4.cc runs failure if static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71641 --- Comment #3 from Jonathan Wakely --- (In reply to John David Anglin from comment #1) > Fails on hppa-linux with libc 2.25: Is that a Debian system too? Maybe we can figure out a condition to use for dg-xfail-if or dg-skip-if.
[Bug libstdc++/86447] gcc 9.0 from r262456 can't build cross compiler for mingw-w64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86447 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Thu Aug 16 15:56:21 2018 New Revision: 263590 URL: https://gcc.gnu.org/viewcvs?rev=263590&root=gcc&view=rev Log: Fix bootstrap with --enable-fully-dynamic-string PR libstdc++/86447 * src/c++11/cow-stdexcept.cc [_GLIBCXX_FULLY_DYNAMIC_STRING] (logic_error::logic_error(logic_error&&)) (logic_error::operator=(logic_error&&)) (runtime_error::runtime_error(runtime_error&&)) (runtime_error::operator=(runtime_error&&)): Copy strings instead of moving, to avoid allocating empty reps for moved-from strings. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc
[Bug libstdc++/86447] gcc 9.0 from r262456 can't build cross compiler for mingw-w64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86447 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #2 from Jonathan Wakely --- Should be fixed - thanks for the report.
[Bug c++/86982] New: Make -Wreturn-local-addr know about std::move and std::forward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86982
Bug ID: 86982
Summary: Make -Wreturn-local-addr know about std::move and
std::forward
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
This fails to warn:
#include
int&& f() { int i = 0; return std::move(i); }
The equivalent code using a static_cast to rvalue reference warns:
move.cc: In function 'int&& f2()':
move.cc:3:52: warning: reference to local variable 'i' returned
[-Wreturn-local-addr]
3 | int&& f2() { int i = 0; return static_cast(i); }
|^
move.cc:3:18: note: declared here
3 | int&& f2() { int i = 0; return static_cast(i); }
| ^
This leads to bugs in users' code, like PR 86980.
As std::move is so fundamental to modern C++ I think it deserves special
treatment by the front end, to ensure this warns. (The special handling might
be useful for implementing PR 86981 as well).
It would be great to do the same for std::forward, which has the same problem:
#include
int&& f() { int i = 0; return std::move(i); }
int&& g() { int i = 0; return std::forward(i); }
std::forward can also be used to return references to temporaries:
int&& h() { long l = 0; return std::forward(l); }
Again, the equivalent with a static_cast gives a warning:
move.cc: In function 'int&& h2()':
move.cc:5:53: warning: returning reference to temporary [-Wreturn-local-addr]
5 | int&& h2() { long l = 0; return static_cast(l); }
|
[Bug c++/86981] Add Clang's -Wpessmizing-move warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86981 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-16 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/67906] Missing warning about std::move without effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906 --- Comment #8 from Jonathan Wakely --- Kinda related: PR 86981
[Bug c++/86981] New: Add Clang's -Wpessmizing-move warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86981
Bug ID: 86981
Summary: Add Clang's -Wpessmizing-move warning
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
struct T {
T() { }
T(const T&) { }
T(T&&) { }
};
T f() {
T t;
return std::move(t);
}
Clang warns about this:
m.cc:5:21: warning: moving a local object in a return statement prevents copy
elision [-Wpessimizing-move]
T f() { T t; return std::move(t); }
^
m.cc:5:21: note: remove std::move call here
T f() { T t; return std::move(t); }
^~ ~
1 warning generated.
[Bug c++/86980] Lambda function with return type rvalue reference dtor issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86980
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Jonathan Wakely ---
This is a bug in your code, not GCC. you're returning a reference to a local
variable, which goes out of scope, leaving a dangling reference.
When you don't give the lambda an explicit return type it returns by value, so
works correctly.
You should just do:
auto f = []() {
Traceable tmp;
return tmp;
};
This returns by value and can elide the move, so is safer and faster.
[Bug fortran/25829] [F03] Asynchronous IO support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829 --- Comment #54 from Thomas Koenig --- Grepping for IN in the execution traces and then running a diff reveals interesting things: IN: __libc_start_main IN: __libc_start_main IN: _dl_discover_osversion -IN: uname -IN: uname +IN: __uname +IN: __uname IN: _dl_discover_osversion IN: _dl_discover_osversion IN: _dl_discover_osversion @@ -53,18 +53,18 @@ IN: __udivsi3 IN: __udivsi3 IN: __libc_setup_tls -IN: sbrk -IN: sbrk +IN: __sbrk +IN: __sbrk IN: __brk IN: __brk IN: __brk -IN: sbrk -IN: sbrk -IN: sbrk -IN: sbrk -IN: sbrk -IN: sbrk -IN: sbrk +IN: __sbrk +IN: __sbrk +IN: __sbrk +IN: __sbrk +IN: __sbrk +IN: __sbrk +IN: __sbrk [...] @@ -445,12 +446,13 @@ IN: _gfortran_set_options IN: _gfortran_set_options IN: _gfortran_set_options -IN: bsd_signal -IN: bsd_signal +IN: ssignal +IN: ssignal IN: __bsd_signal.part.0 IN: __bsd_signal.part.0 -IN: __sigaction -IN: __sigaction +IN: sigaction +IN: sigaction +IN: sigaction IN: __libc_sigaction IN: __libc_sigaction IN: memcpy It seems that the test case is calling a different C library version with and without the patch; especially, it is using the bsd_signal function without the patch and ssignal with it. This is strange, to say the least, and points towards a basic problem with the OS, or the emulator... I am a bit at a loss of how to proceed.
[Bug target/86640] [8/9 regression] ICE in combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86640 --- Comment #13 from Tamar Christina --- Author: tnfchris Date: Thu Aug 16 14:32:18 2018 New Revision: 263589 URL: https://gcc.gnu.org/viewcvs?rev=263589&root=gcc&view=rev Log: Backporting two Arm fixes from mainline fixing PR86640 gcc/testsuite/ 2018-07-31 Segher Boessenkool PR target/86640 * gcc.target/arm/pr86640.c: New testcase. gcc/ 2018-07-31 Segher Boessenkool PR target/86640 * gcc.target/arm/pr86640.c: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/arm/pr86640.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/arm/arm.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/86980] New: Lambda function with return type rvalue reference dtor issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86980
Bug ID: 86980
Summary: Lambda function with return type rvalue reference dtor
issue
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: neeraj.sharma at alumni dot iitg.ernet.in
Target Milestone: ---
Created attachment 44551
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44551&action=edit
preprocessed file for bug
## Summary
The following code misbehaves as the destructor is called before move ctor (see
the console output further below). I not sure as to what is going wrong here!
// ---
auto f = []() -> Traceable&& {
Traceable tmp;
return std::move(tmp);
};
// compiler will call move ctor here because the
// anonymous function above returns a lvalue
//
// Note: One ctor, one move ctor and two dtor invoked
Traceable a = f();
// x--
## Console output
[0x7ffe7d335ca7] ctor Traceable
[0x7ffe7d335ca7] dtor Traceable
[0x7ffe7d335cd7] move ctor Traceable, &other = 0x7ffe7d335ca7
[0x7ffe7d335cd7] dtor Traceable
## Workaround
If I remove the return type then things work as expected.
// ---
auto f = []() {
Traceable tmp;
return std::move(tmp);
};
// compiler will call move ctor here because the
// anonymous function above returns a lvalue
//
// Note: One ctor, one move ctor and two dtor invoked
Traceable a = f();
// x--
## GCC Version Information
Using built-in specs.
COLLECT_GCC=g++-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.1.0-5ubuntu1~16.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 --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
Thread model: posix
gcc version 8.1.0 (Ubuntu 8.1.0-5ubuntu1~16.04)
## Build Command
g++-8 -save-temps -std=c++17 -Wall -Wextra -g -I include/ -I /usr/local/include
-MP -MMD bug.cpp
Note: No compiler warnings or errors were reported by the above command.
[Bug fortran/81849] Size of automatic array argument specified by host-associated variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81849 Jürgen Reuter changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #3 from Jürgen Reuter --- Confirmed. Still present in gfortran 9.0.
[Bug c++/68093] [concepts] friend function declarations that differ only by constraints are rejected as redefinitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68093
--- Comment #4 from Jonathan Wakely ---
This is the accepts-invalid example from PR 86978:
template
struct S
{
template
requires false
friend void foobar(S, t2) {}
};
int main()
{
foobar(S{}, int{});
}
[Bug c++/86978] [concepts] constraints for friend functions ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86978 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|c++-concepts|8.1.0 Resolution|--- |DUPLICATE Summary|constraints for friend |[concepts] constraints for |functions ignored |friend functions ignored --- Comment #1 from Jonathan Wakely --- Seems like a dup. I'll add your case to the other bug. *** This bug has been marked as a duplicate of bug 68093 ***
[Bug c++/68093] [concepts] friend function declarations that differ only by constraints are rejected as redefinitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68093 --- Comment #3 from Jonathan Wakely --- *** Bug 86978 has been marked as a duplicate of this bug. ***
[Bug c++/68093] [concepts] friend function declarations that differ only by constraints are rejected as redefinitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68093 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-16 Ever confirmed|0 |1
[Bug c++/86969] [8/9 Regression] ICE (in tsubst_copy) for a generic recursive lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86969 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Summary|[Regression] ICE (in|[8/9 Regression] ICE (in |tsubst_copy) for a generic |tsubst_copy) for a generic |recursive lambda|recursive lambda --- Comment #2 from Marek Polacek --- commit 10b389b8b205392d32d6d181dc1dbc05cff4e311 Author: jason Date: Tue Apr 3 17:41:12 2018 + PR c++/85149 - generic lambda and constexpr if. * pt.c (build_extra_args, add_extra_args): Split from tsubst_pack_expansion. (tsubst_expr) [IF_STMT]: Use them. * cp-tree.h (IF_STMT_EXTRA_ARGS): New. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@259043 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c++/86969] [Regression] ICE (in tsubst_copy) for a generic recursive lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86969 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-16 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug middle-end/86979] New: [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979 Bug ID: 86979 Summary: [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr Target Milestone: --- On x86_64-apple-darwin17the test gcc.c-torture/compile/pr69102.c fails with -m32 % gfc /opt/gcc/work/gcc/testsuite/gcc.c-torture/compile/pr69102.c -Og -fschedule-insns2 -fselective-scheduling2 -fno-tree-fre --param=max-sched-extend-regions-iters=2 -m32 during RTL pass: dwarf2 /opt/gcc/work/gcc/testsuite/gcc.c-torture/compile/pr69102.c: In function 'foo': /opt/gcc/work/gcc/testsuite/gcc.c-torture/compile/pr69102.c:23:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2348 23 | } | ^ Revision r263503 was OK, r263560 is not.
[Bug fortran/86945] [8/9 Regression] BUG with optimisation of select case statement in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86945 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||7.3.0 Keywords||wrong-code Last reconfirmed||2018-08-16 Ever confirmed|0 |1 Summary|BUG with optimisation of|[8/9 Regression] BUG with |select case statement in|optimisation of select case |gfortran v8.x |statement in gfortran Target Milestone|--- |8.3 Known to fail||8.2.0, 9.0 --- Comment #5 from Dominique d'Humieres --- The bug appeared between revisions r251624 (2017-09-03, OK) and r251946 (2017-09-10, wrong code).
[Bug middle-end/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
--- Comment #3 from Sven ---
I'm not familiar with GCC internals. So my following comments may be completely
off.
This has been classified as a "missed optimization". I would not expect the
optimizer to change 4 ldrb into a single ldr. This seems like a code generation
issue to me, not like an optimization issue. As can be seen with -O0, the
aligned big endian access uses a single ldr but the unaligned big endian access
uses the 4 ldrb.
It seems gcc behaves like this:
if (big_endian_access) {
if (aligned_access) {
issue "ldr"
issue "rev"
} else {
issue 4 "ldrb" in big-endian order
}
} else {
if (aligned_access || arch_supports_unaligned) {
issue "ldr"
} else {
issue 4 "ldrb" in little-endian order
}
}
When instead, gcc should behave like this:
if (aligned_access || arch_supports_unaligned) {
issue "ldr"
if (big_endian_access) {
issue "rev"
}
} else {
if (big_endian_access) {
issue 4 "ldrb" in big-endian order
} else {
issue 4 "ldrb" in little-endian order
}
}
[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 #6 from Arjen Markus --- Yes, I am :). Regards, Arjen 2018-08-16 14:02 GMT+02:00 snowfed at mail dot ru : > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80931 > > --- Comment #5 from snowfed --- > If you don't mind my asking, are you the Fortran book author Arjen Markus? > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug libstdc++/51618] synchronous futures are slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-16 Ever confirmed|0 |1 --- Comment #5 from Jonathan Wakely --- Confirming as an enhancement request, though I'm not sure what (if anything) is possible here. Multiple threads can still call wait() on a std::future, and only the first should run the deferred function. The others need to synchronize on the invocation, and the completion. We should at least investigate and see if there's any improvement that can be made.
[Bug c++/68093] [concepts] friend function declarations that differ only by constraints are rejected as redefinitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68093 Hannes Hauswedell changed: What|Removed |Added CC||h2+bugs at fsfe dot org --- Comment #2 from Hannes Hauswedell --- Constraints on friend member functions seemed to be stripped entirely, therefore making two functions with only different constraints appear the same: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86978
[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 #5 from snowfed --- If you don't mind my asking, are you the Fortran book author Arjen Markus?
[Bug c++/86978] New: constraints for friend functions ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86978
Bug ID: 86978
Summary: constraints for friend functions ignored
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Take the following code:
template
struct S
{
template
requires false
friend void foobar(S, t2) {}
};
int main()
{
foobar(S{}, int{});
}
Obviously the friend function should never be available, but the code compiles
just fine, because apparently the constraints on friend functions are ignored
entirely? This took quite long to find, because there is no diagnostic of any
kind, just wrong behaviour.
Tested with GCC 7.3 and 8.1 on godbolt.org
I think this explains https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68093 as
well, because of the constraints are stripped from friend functions than two
functions which differ only in constraints appear as redefinitions.
[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52477 --- Comment #15 from Martin Liška --- (In reply to Rainer Orth from comment #14) > (In reply to Martin Liška from comment #13) > > Well, after we documented that can we simply close it? > > Quite the contrary: that documents a *current* limitation! See Jason's > comment #6 > for what needs to happen. I see, thanks for clarification.
[Bug libstdc++/85732] use_facet>(mylocale) retrieving wrong locale information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85732 Jonathan Wakely changed: What|Removed |Added CC||cctsai57 at gmail dot com --- Comment #9 from Jonathan Wakely --- *** Bug 71641 has been marked as a duplicate of this bug. ***
[Bug libstdc++/71641] 22_locale/time_get/get_date/wchar_t/4.cc runs failure if static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71641
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
URL||https://sourceware.org/bugz
||illa/show_bug.cgi?id=23164
Resolution|--- |DUPLICATE
--- Comment #2 from Jonathan Wakely ---
There are two different issues causing this test to fail. It consistently fails
on gcc20 in the compiler farm, even with dynamic linking, which might be the
case for hppa-linux too.
On gcc20 it fails because errorstate == failbit, which happens because the
D_FMT string does not match what the testcase expects.
On my Fedora system D_FMT for the zh_TW locale is "西元%Y年%m月%d日" but on gcc20
(Debian 7.11) it's "%Y年%m月%d日".
The static linking case depends on whether libc is linked statically or not,
because it doesn't fail with -static-libstdc++, so this is the same as
https://sourceware.org/bugzilla/show_bug.cgi?id=23164 (and so a duplicate of PR
85732).
Here's my simplified C testcase:
#define _GNU_SOURCE
#include
#include
#include
int main()
{
locale_t loc = newlocale(1 << LC_ALL, "zh_TW.UTF-8", 0);
const char* dfmt = nl_langinfo_l(D_FMT, loc);
printf("date format: %s\n", dfmt);
while (*dfmt)
printf("\\x%x", (unsigned char)*dfmt++);
printf("\n");
return 0;
}
On Fedora 27 (glibc 2.26) this prints:
date format: 西元%Y年%m月%d日
\xe8\xa5\xbf\xe5\x85\x83\x25\x59\xe5\xb9\xb4\x25\x6d\xe6\x9c\x88\x25\x64\xe6\x97\xa5
On Debian 7.11 (glibc 2.13) this prints:
date format: %Y年%m月%d日
\x25\x59\xe5\xb9\xb4\x25\x6d\xe6\x9c\x88\x25\x64\xe6\x97\xa5
And on either system with static linking it fails to find the locale data:
date format: %m/%d/%y
\x25\x6d\x2f\x25\x64\x2f\x25\x79
So this is not a libstdc++ bug, it's a glibc bug. Debian's glibc 2.13 has bad
locale data for zh_TW, and all versions of glibc have the static linking bug.
*** This bug has been marked as a duplicate of bug 85732 ***
[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52477 --- Comment #14 from Rainer Orth --- (In reply to Martin Liška from comment #13) > Well, after we documented that can we simply close it? Quite the contrary: that documents a *current* limitation! See Jason's comment #6 for what needs to happen.
[Bug libstdc++/86447] gcc 9.0 from r262456 can't build cross compiler for mingw-w64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86447 Jonathan Wakely changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-08-16 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/84711] AArch32 big-endian fails when taking subreg of a vector mode to a scalar mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84711
--- Comment #17 from Tamar Christina ---
Author: tnfchris
Date: Thu Aug 16 10:39:13 2018
New Revision: 263584
URL: https://gcc.gnu.org/viewcvs?rev=263584&root=gcc&view=rev
Log:
Update fall through pattern for FP16 patterns in ARM.
The original issue comes from the fact that the code does
... foo (... bar)
{
return bar;
}
The expansion of the return statement causes GCC to try to return the value in
a register. GCC will try to emit the move then, from MEM to REG (due to the
SSA
temporary.). It checks for a mov optab for this which isn't available and
then tries to do the move in bits using emit_move_multi_word.
emit_move_multi_word will split the move into sub parts, but then needs to get
the sub parts and does this using subregs, but it's told it can't do subregs!
The compiler is now stuck in an infinite loop.
The way this is worked around in the back-end is that we have move patterns in
neon.md that usually just force the register instead of checking with the
back-end. This prevents emit_move_multi_word from being needed. However the
pattern for V4HF and V8HF were guarded by TARGET_NEON && TARGET_FP16.
I don't believe the TARGET_FP16 guard to be needed, because the pattern doesn't
actually generate code and requires another pattern for that, and a reg to reg
move
should always be possible anyway. So allowing the force to register here is
safe
and it allows the compiler to generate a correct error instead of ICEing in an
infinite loop.
gcc/
2018-08-16 Tamar Christina
PR target/84711
* config/arm/arm.c (arm_can_change_mode_class): Disallow subreg.
* config/arm/neon.md (movv4hf, movv8hf): Refactored to..
(mov): ..this and enable unconditionally.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/neon.md
[Bug testsuite/78544] FAIL: gcc.dg/tree-prof/section-attr-*.c compilation, -fprofile-generate -D_PROFILE_GENERATE on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78544 --- Comment #6 from Iain Sandoe --- Author: iains Date: Thu Aug 16 10:33:03 2018 New Revision: 263583 URL: https://gcc.gnu.org/viewcvs?rev=263583&root=gcc&view=rev Log: fix section naming convention for Darwin in three tests 2018-08-15 Iain Sandoe gcc/testsuite: PR testsuite/78544 * gcc.dg/tree-prof/section-attr-1.c: Add Darwin-specific section attributes and matching. * gcc.dg/tree-prof/section-attr-2.c: Likewise. * gcc.dg/tree-prof/section-attr-3.c: Likewise. 6 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-prof/section-attr-1.c trunk/gcc/testsuite/gcc.dg/tree-prof/section-attr-2.c trunk/gcc/testsuite/gcc.dg/tree-prof/section-attr-3.c
[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52477 --- Comment #13 from Martin Liška --- Well, after we documented that can we simply close it?
[Bug fortran/86545] [6/7/8/9 Regression] ICE in transfer_expr on invalid WRITE statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86545 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #1) > I guess the problem is the absence of the error message that one gets when > calling the specific function directly, without going through the generic > interface: > > write(*,*) trim_string(s) ! correctly rejected >1 > Error: Data transfer element at (1) cannot have ALLOCATABLE components > unless it is processed by a defined input/output procedure That error message comes from resolve_transfer (in resolve.c).
[Bug libstdc++/86977] [g++ 8.1.0-5ubuntu1~14.04] error: static assertion failed: unordered container must have the same value_type as its allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86977 --- Comment #4 from Jonathan Wakely --- (In reply to João Neto from comment #2) > Hi Jonathan! Thanks for the quick reply! > > Two follow-up questions: > > (1) Shouldn't it be also flagged as an error in `gcc-6` and `gcc-7` with > `-std=c++17`? No because the static assertion was only added in gcc 8. > (2) How can I reliably find the node-type allocated by the map if I'd want > to use `-std=c++17`? Isn't it implementation-defined? (In reply to João Neto from comment #3) > Please ignore my stupidity. c++17 has a `node_type` No, that's nothing to do with it. Read the error message! Or read comment 1! The allocator's value type must be the same as the container's VALUE TYPE. Not its node type. I really don't know how to make the static assertion any clearer. The container's value_type is std::pair.
[Bug bootstrap/81397] mistakes in .opt files not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81397 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #3 from Martin Liška --- As we're staying with Awk, for now I'm planning to work on that.
[Bug sanitizer/86022] TCB size calculated in ThreadDescriptorSize() is wrong for glibc-2.14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86022 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Liška --- Fixed.
[Bug sanitizer/86022] TCB size calculated in ThreadDescriptorSize() is wrong for glibc-2.14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86022 --- Comment #7 from Martin Liška --- Author: marxin Date: Thu Aug 16 10:19:16 2018 New Revision: 263581 URL: https://gcc.gnu.org/viewcvs?rev=263581&root=gcc&view=rev Log: Backport r263246 2018-08-16 Martin Liska Backport from mainline 2018-08-02 Martin Liska PR sanitizer/86022 * sanitizer_common/sanitizer_linux_libcdep.cc (ThreadDescriptorSize): Cherry-pick compiler-rt revision 338606. Modified: branches/gcc-7-branch/libsanitizer/ChangeLog branches/gcc-7-branch/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
[Bug libstdc++/86977] [g++ 8.1.0-5ubuntu1~14.04] error: static assertion failed: unordered container must have the same value_type as its allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86977 --- Comment #3 from João Neto --- > > (2) How can I reliably find the node-type allocated by the map if I'd want > to use `-std=c++17`? Isn't it implementation-defined? > Please ignore my stupidity. c++17 has a `node_type` The other one I think is relevant though. (Sorry for the spam!)
[Bug gcov-profile/86817] [8 Regression] Misleading warning in gcov since r254672
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86817 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed.
[Bug sanitizer/86022] TCB size calculated in ThreadDescriptorSize() is wrong for glibc-2.14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86022 --- Comment #6 from Martin Liška --- Author: marxin Date: Thu Aug 16 10:16:17 2018 New Revision: 263579 URL: https://gcc.gnu.org/viewcvs?rev=263579&root=gcc&view=rev Log: Backport r263246 2018-08-16 Martin Liska Backport from mainline 2018-08-02 Martin Liska PR sanitizer/86022 * sanitizer_common/sanitizer_linux_libcdep.cc (ThreadDescriptorSize): Cherry-pick compiler-rt revision 338606. Modified: branches/gcc-8-branch/libsanitizer/ChangeLog branches/gcc-8-branch/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
[Bug gcov-profile/86817] [8 Regression] Misleading warning in gcov since r254672
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86817 --- Comment #2 from Martin Liška --- Author: marxin Date: Thu Aug 16 10:16:32 2018 New Revision: 263580 URL: https://gcc.gnu.org/viewcvs?rev=263580&root=gcc&view=rev Log: Backport r263248 2018-08-16 Martin Liska Backport from mainline 2018-08-02 Martin Liska PR gcov-profile/86817 * gcov.c (process_all_functions): New function. (main): Call it. (process_file): Move functions processing to process_all_functions. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/gcov.c
[Bug libstdc++/86977] [g++ 8.1.0-5ubuntu1~14.04] error: static assertion failed: unordered container must have the same value_type as its allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86977 --- Comment #2 from João Neto --- Hi Jonathan! Thanks for the quick reply! Two follow-up questions: (1) Shouldn't it be also flagged as an error in `gcc-6` and `gcc-7` with `-std=c++17`? (2) How can I reliably find the node-type allocated by the map if I'd want to use `-std=c++17`? Isn't it implementation-defined? https://stackoverflow.com/questions/49736817/stdunordered-map-with-boostinterprocess-allocator-in-shared-memory-drawbac/49738871#49738871
[Bug tree-optimization/78257] missing memcmp optimization with constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78257 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #7 from Martin Liška --- Leaving unassigned as I'm not planning to working on that.
[Bug libstdc++/86447] gcc 9.0 from r262456 can't build cross compiler for mingw-w64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86447 --- Comment #1 from mateuszb at poczta dot onet.pl --- This bug is when you configure GCC with option --enable-fully-dynamic-string
[Bug libstdc++/86977] [g++ 8.1.0-5ubuntu1~14.04] error: static assertion failed: unordered container must have the same value_type as its allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86977 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- (In reply to João Neto from comment #0) > using HashMap = std::unordered_map>; This is invalid, the allocator's value type is not the same as the container's value type (which is exactly what the error tells you!) GCC will accept it as an extension in -std=gnu++17 mode, but you compiled with -std=c++17 which disables the non-standard extension.
[Bug libstdc++/86977] New: [g++ 8.1.0-5ubuntu1~14.04] error: static assertion failed: unordered container must have the same value_type as its allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86977
Bug ID: 86977
Summary: [g++ 8.1.0-5ubuntu1~14.04] error: static assertion
failed: unordered container must have the same
value_type as its allocator
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: joao at neto dot pt
Target Milestone: ---
**I'm not sure this is a bug; but I couldn't find alternate root cause. Sorry
if it's not!**
The following code can be compiled successfully in `g++-6` and `g++-7`, but not
in `g++-8`, which results in an error:
```
In file included from /usr/include/c++/8/unordered_map:46,
from /usr/include/c++/8/functional:61,
from test.cpp:3:
/usr/include/c++/8/bits/hashtable.h: In instantiation of ‘class
std::_Hashtable,
boost::interprocess::allocator,
boost::interprocess::iset_index> >, std::__detail::_Select1st,
std::equal_to, std::hash, std::__detail::_Mod_range_hashing,
std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy,
std::__detail::_Hashtable_traits >’:
/usr/include/c++/8/bits/unordered_map.h:105:18: required from ‘class
std::unordered_map, std::equal_to,
boost::interprocess::allocator,
boost::interprocess::iset_index> > >’
test.cpp:30:15: required from here
/usr/include/c++/8/bits/hashtable.h:192:21: error: static assertion failed:
unordered container must have the same value_type as its allocator
static_assert(is_same{},
^~
```
```
#include
#include
#include
#include
#include
#include
#include
#include
#include
class Thing {
public:
volatile Thing *_parent;
explicit Thing(Thing *parent) : _parent(parent) {}
};
namespace ipc = boost::interprocess;
using Segment = ipc::managed_shared_memory;
using Manager = Segment::segment_manager;
template using Alloc = ipc::allocator;
template , typename KEq =
std::equal_to>
using HashMap = std::unordered_map>;
typedef HashMap ThingMap;
int main() {
boost::interprocess::shared_memory_object::remove("test");
Segment my_segment{ipc::create_only, "test", 1ul<<40};
Manager *my_manager = my_segment.get_segment_manager();
ThingMap *my_map =
my_segment.find_or_construct("my_map")(my_manager);
my_map->emplace(123, nullptr);
printf("Hello world\n");
return 0;
}
```
The code can be seen on GitHub, and there is a Travis build reproducing the
issue. I've posted on StackOverflow but got no replies.
https://github.com/joaomlneto/clang-tidbit
https://travis-ci.com/joaomlneto/clang-tidbit/builds/81896897
https://stackoverflow.com/questions/51858747/compilation-tidbits-on-g-clang-using-libboost-g8-compilation-fails-wh
Using `libboost 1.54` (default for `apt-get install libboost-all-dev` in Ubuntu
14.04).
Compiled with `$(CXX) -std=c++17 $^ -o $@ -pthread -ldl -rdynamic -lrt`
If I change to `-std=gnu++17`, then it works.
https://travis-ci.com/joaomlneto/clang-tidbit/builds/81897835
Below is information on the system (although is a pretty standard Ubuntu
14.04):
```
# g++-8 -v
Using built-in specs.
COLLECT_GCC=g++-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.1.0-5ubuntu1~14.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=gcc4-compatible --disable-libstdcxx-dual-abi
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx
--enable-plugin --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
Thread model: posix
gcc version 8.1.0 (Ubuntu 8.1.0-5ubuntu1~14.04)
```
```
# uname -a
Linux d0710afa7fb5 4.15.0-30-generic #32-Ubuntu SMP Thu Jul 26 17:42:43 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux
```
```
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 14.04.5 LTS
Release:14.04
Codename: trusty
```
[Bug target/86745] [9 regression] gcc.target/i386/avx-cvt-2.c etc. FAIL on 64-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86745 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-08-16 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1 --- Comment #3 from Uroš Bizjak --- Created attachment 44550 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44550&action=edit Proposed patch The combine is now able to combine memory operand with the instruction, creating: vcvtps2pd f(%rip), %ymm0 This doesn't match the pattern. The matching pattern is too tight, attached patch "fixes" the PR.
[Bug c/86972] [6/7/8/9 Regression] Incorrect array-bounds warning with -O2 when creating pointer from array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86972 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-16 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Summary|Incorrect array-bounds |[6/7/8/9 Regression] |warning with -O2 when |Incorrect array-bounds |creating pointer from array |warning with -O2 when ||creating pointer from array Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with Richi's r222146.
[Bug libstdc++/83607] std::boyer_moore_searcher is slow searching through arrays of std::byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83607 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #7 from Jonathan Wakely --- I'm no longer planning to backport this to gcc-7-branch. It's fixed for GCC 8.1 and later.
[Bug c++/83615] A reference binding involving a qualification conversion is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83615 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-16 Ever confirmed|0 |1
[Bug libstdc++/83906] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 Jonathan Wakely changed: What|Removed |Added Target Milestone|8.3 |---
[Bug libstdc++/86976] [meta-bug] Issues with std::time_get, std::time_put etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86976 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-16 Depends on||79833, 84216, 77760 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77760 [Bug 77760] get_time needs to set tm_wday amd tm_yday https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79833 [Bug 79833] std::put_time has the wrong values for 2 digit years https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84216 [Bug 84216] std::get_time fails to parse output from std::put_time, but strptime can parse them (c++11)
[Bug c++/86971] -Wabi warns it will not warn about anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86971 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Component|libstdc++ |c++ --- Comment #3 from Jonathan Wakely --- OK so let's change the component back to c++ then.
[Bug libstdc++/86976] New: [meta-bug] Issues with std::time_get, std::time_put etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86976 Bug ID: 86976 Summary: [meta-bug] Issues with std::time_get, std::time_put etc. Product: gcc Version: unknown Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Depends on: 9635, 9780, 45896, 71367, 71557, 78714, 86967 Target Milestone: --- This is a meta-bug for issues in the std::locale time category. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9635 [Bug 9635] time_get<>::date_order unimplemented https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9780 [Bug 9780] issues with time_get, time_put not being tied to correct _punct facet. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45896 [Bug 45896] [C++0x] Facet time_get not reading dates according to the IEEE 1003 standard. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71367 [Bug 71367] std::time_get does not implement 'r' or 'p' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71557 [Bug 71557] time_get is case sensitive https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78714 [Bug 78714] std::get_time / std::time_get::get does not accept full month name in %b https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86967 [Bug 86967] time_get fails to parse abbreviated weekday with %A format string
[Bug libstdc++/86971] -Wabi warns it will not warn about anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86971 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- I think the wording of the opening line can be made unambiguous, which is probably nice for translators. Can we change it to say e.g.: cc1plus: warning: -Wabi by itself does not issue any warnings
[Bug target/86975] New: wrong peephole optimization applied on nios2 and mips targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86975
Bug ID: 86975
Summary: wrong peephole optimization applied on nios2 and mips
targets
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: ---
On MIPS and Nios2 architectures logical instruction immediate (andi, ori)
zero-extend immediate field. It means that on this targets small negative
constants in logical expressions are more expensive than small (or not so
small) positive constants. Peephole optimization phase should take it into
account when selecting substitution patterns, but right now it's not smart
enough.
Code:
int isE(int x) { return (x=='e') || (x=='E') ; }
RISV32 (-Os -rv32im) :
:
0: fdf57513andia0,a0,-33
4: fbb50513addia0,a0,-69
8: 00153513seqza0,a0
c: 8082ret
That's good, because RISC-V sign-extends field in logical instructions which
means that it has no problems with small integer constants.
MIPS ( -Os -mips32r6 -mcompact-branches=always) :
:
0: 2402ffdfli v0,-33
4: 00821024and v0,a0,v0
8: 38420045xoriv0,v0,0x45
c: 2c420001sltiu v0,v0,1
10: d81fjrc ra
Nios2 (-Os) :
:
0: 00bff7c4movir2,-33
4: 2084703aand r2,r4,r2
8: 10801160cmpeqi r2,r2,69
c: f800283aret
That not so good. Both of them are sub-optimal.
These targets should use substitution pattern based on small positive constant.
Like that:
MIPS:
:
0: 34820020ori v0,a0,0x20
4: 38420065xoriv0,v0,0x65
8: 2c420001sltiu v0,v0,1
c: d81fjrc ra
Nios2:
:
0: 20800814ori r2,r4,32
4: 10801960cmpeqi r2,r2,101
8: f800283aret
[Bug c++/86974] New: Support Clang's require_constant_initialization attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86974 Bug ID: 86974 Summary: Support Clang's require_constant_initialization attribute Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- As documented at https://clang.llvm.org/docs/AttributeReference.html#require-constant-initialization-clang-require-constant-initialization This attribute is very useful to check that a global uses constant initialization, thus avoiding the Static Initialization Order Fiasco. For example, see PR 83428 where it was mistakenly believed that the variable should not be dynamically initialized, but actually there was a bug in the code preventing it. If the variable will not get constant initialization Clang gives an error and states the reason for dynamic init: 83428.cc:20:54: error: variable does not have a constant initializer __attribute__((require_constant_initialization)) S2 objX; ^~~~ 83428.cc:20:17: note: required by 'require_constant_initialization' attribute here __attribute__((require_constant_initialization)) S2 objX; ^~~ 83428.cc:12:7: note: undefined constructor 'S1' cannot be used in a constant expression : m_tabS1() ^ 83428.cc:20:54: note: in call to 'S2()' __attribute__((require_constant_initialization)) S2 objX; ^ 83428.cc:3:15: note: declared here constexpr S1 (); ^ 1 error generated. So this doesn't change the meaning of any code, it just acts as an assertion that a property is true.
[Bug libstdc++/86971] -Wabi warns it will not warn about anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86971 Jonathan Wakely changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #1 from Jonathan Wakely --- No, the wording is correct, "anything else" would not make sense. You need to look at the full output: cc1plus: warning: -Wabi won't warn about anything [-Wabi] cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, which is also used by default cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7 This has already been fixed on trunk with r262824
[Bug c/19315] document undocumented extension that allows code where variable is not emitted in the asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19315 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Iain Sandoe --- fixed on trunk
[Bug sanitizer/86973] [6/7/8/9 Regression] ICE in expand_call, at calls.c:4217
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86973 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-16 Known to work||5.4.0 Ever confirmed|0 |1 Known to fail||6.4.0, 7.3.0, 8.2.0, 9.0
[Bug sanitizer/86973] New: [6/7/8/9 Regression] ICE in expand_call, at calls.c:4217
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86973
Bug ID: 86973
Summary: [6/7/8/9 Regression] ICE in expand_call, at
calls.c:4217
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Following ICEs starting from r222173:
$ cat ice.i
__attribute__((sysv_abi))
void a(__attribute__((__vector_size__(8 * sizeof(double double b,
__builtin_va_list c) {
__builtin_va_arg(c, int);
}
$ gcc -fsanitize=thread -c -mabi=ms -mavx512f ice.i
during RTL pass: expand
ice.i: In function ‘a’:
ice.i:3:24: internal compiler error: in expand_call, at calls.c:4217
3 | __builtin_va_list c) {
|^
0x89d231 expand_call(tree_node*, rtx_def*, int)
/home/marxin/Programming/gcc/gcc/calls.c:4215
0x88d4f5 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/marxin/Programming/gcc/gcc/builtins.c:8122
0x9b9e81 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:10911
0x8afb99 expand_expr
/home/marxin/Programming/gcc/gcc/expr.h:279
0x8afb99 expand_call_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:2687
0x8afb99 expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3575
0x8afb99 expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3734
0x8b0a8f expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:5770
0x8b57f7 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6373
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
