[Bug c++/86230] New: missing exception specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86230
Bug ID: 86230
Summary: missing exception specification
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code sample is as follow:
#include
#include
#define VERIFY assert
struct T { int i; };
int swap_calls;
namespace std
{
// Should be most specialized.
#if 1
template<>
#endif
inline void
swap(vector >&, vector >&)
{ ++swap_calls; }
}
void test01()
{
bool test __attribute__((unused)) = true;
std::vector A;
std::vector B;
swap_calls = 0;
std::swap(A, B);
VERIFY(1 == swap_calls); // XXX fails
}
void test02()
{
bool test __attribute__((unused)) = true;
using namespace std;
vector A;
vector B;
swap_calls = 0;
swap(A, B);
VERIFY(1 == swap_calls);
}
int main()
{
test01();
test02();
return 0;
}
g++ accepts the code, but clang++ rejects it with an error message:
error: 'swap >' is missing exception specification
'noexcept(noexcept(__x.swap(__y)))'
swap(vector >&, vector >&)
Is this a piece of ill-formed code?
[Bug sanitizer/86229] New: ASAN Reports "alloc-dealloc mismatch" intsead of "attempted delete without new"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86229 Bug ID: 86229 Summary: ASAN Reports "alloc-dealloc mismatch" intsead of "attempted delete without new" Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: mitranopeter at gmail dot com 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: --- Created attachment 44298 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44298=edit preprocessed file GCC version: 8.0.1 20180311 System Type: Ubuntu 16.04 GCC Build options: defaults Compile command: g++ -std=c++11 -fsanitize=address main.cpp First time reporting here, so forgive me if this out of scope of wontfix. ASAN gives me different (true) error messages depending on some very strange small changes to my code. I either get (1) alloc-dealloc-mismatch (INVALID vs operator delete) Or (2) attempting free on address which was not malloc()-ed: In the attached preprocessed file, you should see error (1) which isn't very helpful. What's super weird is that if I make my struct have less than three ints, or if I remove the iostream business, I get (2) which I believe to be a much more useful error message. If I could attach more than one file I'd give you both *.cpp files to demonstrate, but hopefully this is clear as is.
[Bug c++/86227] invalid suffix on floating constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86227 --- Comment #3 from zhonghao at pku dot org.cn --- (In reply to zhonghao from comment #2) > (In reply to Andrew Pinski from comment #1) > > Did you add -pedantic-error or use -std=c++11 ? This is the decimal > > floating point extension that gcc supports that llvm does not. > > I tried.g++ still accepts it and does not produce any error messages. With the flag, -pedantic -error, g++ produces a warning message, but the message seems to be irrelevant.
[Bug c++/86227] invalid suffix on floating constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86227 --- Comment #2 from zhonghao at pku dot org.cn --- (In reply to Andrew Pinski from comment #1) > Did you add -pedantic-error or use -std=c++11 ? This is the decimal > floating point extension that gcc supports that llvm does not. I tried.g++ still accepts it and does not produce any error messages.
[Bug c++/86227] invalid suffix on floating constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86227 --- Comment #1 from Andrew Pinski --- Did you add -pedantic-error or use -std=c++11 ? This is the decimal floating point extension that gcc supports that llvm does not.
[Bug c++/86228] New: ordered comparison between pointer and zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86228
Bug ID: 86228
Summary: ordered comparison between pointer and zero
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
extern void* p;
int main() { return ( p<0 ? 1 : 0 ); }
clang++ rejects it with an error message:
error: ordered comparison between pointer and zero ('void *' and 'int')
int main() { return ( p<0 ? 1 : 0 ); }
However, g++ accepts it without any warnings.
Is this code ill-formed?
[Bug c++/86227] New: invalid suffix on floating constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86227
Bug ID: 86227
Summary: invalid suffix on floating constant
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code sample is as follow:
#include
int main() {
typeid( 0.dd );
}
g++ accepts this code, but clang++ rejects it with a message:
error: invalid suffix 'dd' on floating constant
typeid( 0.dd );
Shall g++ reject the code as well?
[Bug c++/86226] New: A bug seems to be not fully fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86226
Bug ID: 86226
Summary: A bug seems to be not fully fixed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
int main() {
auto l = [](){};
l.operator()();
}
It was reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77914. Michele
Caini complains that g++ does not produce any warnings for this ill-formed
code.
The report is said to be resolved, since 7+.
I tried on 8.0.1 with the same flags, -Wall -pedantic. I got a warning:
lambda templates are only available with -std=c++2a or -std=gnu++2a
So, I change the flag to -std=c++2a. This time, g++ accepts it without any
messages.
I also tried clang++. It produces the following error messages:
error: expected body of lambda expression
auto l = [](){};
error: expected a qualified name after 'typename'
auto l = [](){};
It seems that the bug is not fixed, right?
[Bug c++/86225] New: Missing error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86225
Bug ID: 86225
Summary: Missing error message
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
struct A
{
virtual ~A () {}
};
struct B : public A
{
virtual ~B () {}
};
template < int > void foo ()
{
B *b = new B;
b->~A ();
}
int main ()
{
foo < 0 > ();
return 0;
}
g++ accepts the code, but clang++ rejects it. The error message is as follow:
error: destructor type 'A' in object destruction expression does not match the
type 'B' of the object being destroyed
b->~A ();
note: type 'A' is declared here
struct A
^
1 error generated.
Shall g++ present similar error messages?
[Bug libgcc/86224] New: [m68k] textrels in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86224 Bug ID: 86224 Summary: [m68k] textrels in libgcc Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: bugdal at aerifal dot cx Target Milestone: --- The lb1sf68.S math asm makes calls to its own functions via the PICCALL macro, which expands to a PC-relative branch. However, the symbols have default visibilty, and thus are not bound at link-time, leaving R_68K_PC32 textrels in the output libgcc_s and potentially in PIE programs or shared libraries linked to the static libgcc.a. Hidden aliases are probably the best solution. Alternatively the PICCALL macro could be adjusted to use the @PLT form of the target.
[Bug target/86222] ICE in final_scan_insn_1 calling strncmp() with a bound of PTRDIFF_MAX + 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86222 Peter Bergner changed: What|Removed |Added CC||acsawdey at gcc dot gnu.org --- Comment #2 from Peter Bergner --- CCimg Aaron since he's worked on strncmp expansion recently.
[Bug libfortran/78549] Very slow formatted internal file output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #34 from Jerry DeLisle --- Closing, have done enough.
[Bug libstdc++/70966] new_delete_resource() has deinit lifetime issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70966 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-20 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug libfortran/85906] Conditional jump depends on uninitialized value in write_decimal / write_integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85906 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jerry DeLisle --- Fixed
[Bug libstdc++/70129] [6 Regression] stdlib.h: No such file or directory when using -isystem /usr/include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129 --- Comment #8 from Jonathan Wakely --- (In reply to chuck cranor from comment #3) > I think you'll find most build systems that do "-isystem /usr/include" > instead of "-I /usr/include" are only using "-isystem" for the change > in the warning behavior. The change in the include path order is not > wanted... Then they should stop (mis)using -isystem, since it's clearly documented to affect the order directories are searched: If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option is ignored. The directory is still searched but as a system directory at its normal position in the system include chain. This is to ensure that GCC's procedure to fix buggy system headers and the ordering for the "#include_next" directive are not inadvertently changed. If you really need to change the search order for system directories, use the -nostdinc and/or -isystem options. The corollary is that you shouldn't use it unless you really need to change the search order for system directories!
[Bug target/86222] ICE in final_scan_insn_1 calling strncmp() with a bound of PTRDIFF_MAX + 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86222 David Edelsohn changed: What|Removed |Added Target|powerpc-ibm-aix7.2 |powerpc-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-19 CC||bergner at gcc dot gnu.org, ||segher at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Fails for all 32 bit PowerPC.
[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85602 --- Comment #12 from Martin Sebor --- Author: msebor Date: Tue Jun 19 22:35:45 2018 New Revision: 261774 URL: https://gcc.gnu.org/viewcvs?rev=261774=gcc=rev Log: PR middle-end/85602 - -Warray-bounds fails to detect the out of bound array access gcc/testsuite/ChangeLog: * c-c++-common/attr-nonstring-8.c: Adjust text of expected warning to also match C++. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-28.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/70129] [6 Regression] stdlib.h: No such file or directory when using -isystem /usr/include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129 Shaun Jackman changed: What|Removed |Added CC||sjackman at gmail dot com --- Comment #7 from Shaun Jackman --- Thanks for reporting and trouble shooting this issue, Markus. This issue also affects the Linuxbrew package manager. See the downstream issue at https://github.com/Linuxbrew/brew/issues/724. It'd be great if this issue were addressed by GCC. Thanks to the trouble shooting here, we can work around the issue in the mean time. Cheers, Shaun
[Bug middle-end/48560] [4.6/4.7 Regression] -Warray-bounds fails to detect the out of bound array access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48560
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
CC||msebor at gcc dot gnu.org
Known to work||4.5.3, 5.1.0
Blocks||56456
Resolution|WONTFIX |FIXED
Known to fail||4.7.4
--- Comment #2 from Martin Sebor ---
The code is diagnosed by recent versions of GCC:
$ cat pr48560.c && gcc -O2 -S -Wall pr48560.c
char
foo1 (int i)
{
static char s[] = "foo";
switch (i)
{
case 30:
return s[30];
}
return s[i];
}
pr48560.c: In function ‘foo1’:
pr48560.c:8:13: warning: array subscript 30 is above array bounds of ‘char[4]’
[-Warray-bounds]
return s[30];
~^~~~
Bisection points to r213045 (gcc 5.1.0) as the commit that restored the
warning. Let me add the test case to the test suite and change the resolution
to fixed.
r213045 | rguenth | 2014-07-25 03:44:57 -0400 (Fri, 25 Jul 2014) | 22 lines
2014-07-25 Richard Biener
PR middle-end/61762
PR middle-end/61894
* fold-const.c (native_encode_int): Add and handle offset
parameter to do partial encodings of expr.
(native_encode_fixed): Likewise.
(native_encode_real): Likewise.
(native_encode_complex): Likewise.
(native_encode_vector): Likewise.
(native_encode_string): Likewise.
(native_encode_expr): Likewise.
* fold-const.c (native_encode_expr): Add offset parameter
defaulting to -1.
* gimple-fold.c (fold_string_cst_ctor_reference): Remove.
(fold_ctor_reference): Handle all reads from tcc_constant
ctors.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug tree-optimization/86223] missing -Warray-bounds on an access to an implicitly zeroed out array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86223 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Known to fail||4.8.4, 4.9.4, 5.5.0, 6.4.0, ||7.2.0, 8.1.0, 9.0 --- Comment #1 from Martin Sebor --- This was never diagnosed so not a regression.
[Bug tree-optimization/86223] New: missing -Warray-bounds on an access to an implicitly zeroed out array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86223
Bug ID: 86223
Summary: missing -Warray-bounds on an access to an implicitly
zeroed out array
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
When both bounds of an array index are out of range, GCC diagnoses the use of
the index to refer beyond the bounds of a local array whose elements have all
been explicitly initialized, but it fails to diagnose the same out-of-bounds
access when the array has not been fully initialized.
$ cat d.c && gcc -O2 -S -Wall d.c
void f (int);
void g (unsigned i)
{
if (i < 5 || 123 < i)
i = 5;
int a[3] = { 0 };
f (a[i]); // missing -Warray-bounds
}
void h (unsigned i)
{
if (i < 5 || 123 < i)
i = 5;
int a[3] = { 0, 0, 0 };
f (a[i]); // -Warray-bounds (good)
}
d.c: In function ‘h’:
d.c:18:3: warning: array subscript 5 is above array bounds of ‘int[3]’
[-Warray-bounds]
f (a[i]); // -Warray-bounds (good)
^~~~
[Bug c++/48665] type of const member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48665 --- Comment #17 from Jonathan Wakely --- (In reply to David Blaikie from comment #15) > "The compiler still reuses the same representation for const/volatile and > for some attributes, sometimes misinterpreting one for the other." - sounds > like rejecting this valid code is a workaround for that choice of > representation? That comment you quoted is explaining why the diagnostic printed "void () __attribute__((const))" insetad of "void () const", not why the code should be rejected. It's not rejected because of a limitation in GCC.
[Bug c++/48665] type of const member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48665 --- Comment #16 from Jonathan Wakely --- It's not valid. [expr.typeid] p5 says typeid(cv T) is the same as typeid(T) but that isn't relevant here. 'void () const' is not the cv-qualified version of 'void ()', because there are no cv-qualified function types. See [dcl.fct] p7. 'void () const' is a function type with a cv-qualifier-seq and can only appear in a few specific places, which does not include a typeid expression. See [dcl.fct] p6.
[Bug libstdc++/86138] C++17: getline(istream, string) crashes on Cygwin because incompatible C++14 function is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86138 Jonathan Wakely changed: What|Removed |Added CC||irfanadilovic at gmail dot com --- Comment #10 from Jonathan Wakely --- *** Bug 81522 has been marked as a duplicate of this bug. ***
[Bug libstdc++/81522] c++17/old-abi/cygwin empty stringstream invalid memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81522 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- Looks like Bug 86138 *** This bug has been marked as a duplicate of bug 86138 ***
[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85602 --- Comment #11 from seurer at gcc dot gnu.org --- It is fixed now. Thanks!
[Bug c++/86218] [9 Regression] ICE in compare_ics, at cp/call.c:9769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86218
--- Comment #2 from Marek Polacek ---
Is this really valid though?
clang++ says
86218.C:8:7: error: type 'double' cannot be narrowed to 'char' in initializer
list [-Wc++11-narrowing]
and if I use
f ({static_cast(2.0)});
then g++ compiles it fine.
[Bug c++/48665] type of const member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48665 David Blaikie changed: What|Removed |Added CC||dblaikie at gmail dot com, ||richard-gccbugzilla@metafoo ||.co.uk --- Comment #15 from David Blaikie --- (jumping in here from https://bugs.llvm.org/show_bug.cgi?id=37846 ) Rejecting 'typeid(void() const)' seems like rejecting valid (if uncommon) code. Perhaps this should be fixed to accept the code, rather than reject it? "The compiler still reuses the same representation for const/volatile and for some attributes, sometimes misinterpreting one for the other." - sounds like rejecting this valid code is a workaround for that choice of representation?
[Bug target/65416] xtensa: memory allocated by alloca is used before the stack pointer is updated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65416 --- Comment #7 from jcmvbkbc at gcc dot gnu.org --- Author: jcmvbkbc Date: Tue Jun 19 21:08:46 2018 New Revision: 261765 URL: https://gcc.gnu.org/viewcvs?rev=261765=gcc=rev Log: xtensa: fix PR target/65416 The issue is caused by reordering of stack pointer update after stack space allocation with instructions that write to the allocated stack space. In windowed ABI register spill area for the previous call frame is located just below the stack pointer and may be reloaded back into the register file on movsp. Implement allocate_stack pattern for windowed ABI configuration and insert an instruction that prevents reordering of frame memory access and stack pointer update. gcc/ 2018-06-19 Max Filippov Backport from mainline 2018-06-19 Max Filippov * config/xtensa/xtensa.md (UNSPEC_FRAME_BLOCKAGE): New unspec constant. (allocate_stack, frame_blockage, *frame_blockage): New patterns. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/xtensa/xtensa.md
[Bug fortran/86206] ICE in gfc_resolve_forall, at fortran/resolve.c:9989
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86206 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #2 from Harald Anlauf --- 4.8 and 4.9 work, thus 5 regression.
[Bug target/65416] xtensa: memory allocated by alloca is used before the stack pointer is updated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65416 --- Comment #6 from jcmvbkbc at gcc dot gnu.org --- Author: jcmvbkbc Date: Tue Jun 19 21:01:22 2018 New Revision: 261764 URL: https://gcc.gnu.org/viewcvs?rev=261764=gcc=rev Log: xtensa: fix PR target/65416 The issue is caused by reordering of stack pointer update after stack space allocation with instructions that write to the allocated stack space. In windowed ABI register spill area for the previous call frame is located just below the stack pointer and may be reloaded back into the register file on movsp. Implement allocate_stack pattern for windowed ABI configuration and insert an instruction that prevents reordering of frame memory access and stack pointer update. gcc/ 2018-06-19 Max Filippov Backport from mainline 2018-06-19 Max Filippov * config/xtensa/xtensa.md (UNSPEC_FRAME_BLOCKAGE): New unspec constant. (allocate_stack, frame_blockage, *frame_blockage): New patterns. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/xtensa/xtensa.md
[Bug target/65416] xtensa: memory allocated by alloca is used before the stack pointer is updated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65416 --- Comment #5 from jcmvbkbc at gcc dot gnu.org --- Author: jcmvbkbc Date: Tue Jun 19 20:57:46 2018 New Revision: 261763 URL: https://gcc.gnu.org/viewcvs?rev=261763=gcc=rev Log: xtensa: fix PR target/65416 The issue is caused by reordering of stack pointer update after stack space allocation with instructions that write to the allocated stack space. In windowed ABI register spill area for the previous call frame is located just below the stack pointer and may be reloaded back into the register file on movsp. Implement allocate_stack pattern for windowed ABI configuration and insert an instruction that prevents reordering of frame memory access and stack pointer update. gcc/ 2018-06-19 Max Filippov Backport from mainline 2018-06-19 Max Filippov * config/xtensa/xtensa.md (UNSPEC_FRAME_BLOCKAGE): New unspec constant. (allocate_stack, frame_blockage, *frame_blockage): New patterns. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/xtensa/xtensa.md
[Bug rtl-optimization/86222] New: ICE in final_scan_insn_1 calling strncmp() with a bound of PTRDIFF_MAX + 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86222
Bug ID: 86222
Summary: ICE in final_scan_insn_1 calling strncmp() with a
bound of PTRDIFF_MAX + 1
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The following test case was reduced from a powerpc-ibm-aix7.2 ICE in the
gcc.dg/attr-nonstring-3.c test case added in r261704:
$ cat c.i && /ssd/build/powerpc-ibm-aix7.2/gcc-8-branch/gcc/xgcc -B
/ssd/build/powerpc-ibm-aix7.2/gcc-8-branch/gcc -S -O2 -Wall -Wextra
-fdump-tree-optimized=/dev/stdout c.i
typedef typeof (sizeof 0) size_t;
extern int strncmp (const char*, const char*, size_t);
int f (void)
{
size_t n = 0x7fffL; // PTRDIFF_MAX
extern char a[];
extern char b[16];
return strncmp (a, b, n + 1);
}
;; Function f (f, funcdef_no=0, decl_uid=2619, cgraph_uid=0, symbol_order=0)
f ()
{
int _2;
[local count: 1073741825]:
_2 = strncmp (, , 2147483648); [tail call]
return _2;
}
c.i: In function ‘f’:
c.i:12:1: error: could not split insn
}
^
(insn 116 118 194 (set (reg:SI 5 5)
(const_int -2147483680 [0x7fe0])) "c.i":11 485
{*movsi_internal1}
(nil))
during RTL pass: final
c.i:12:1: internal compiler error: in final_scan_insn_1, at final.c:3142
0xfed675 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/src/gcc/8-branch/gcc/rtl-error.c:108
0xb5c13c final_scan_insn_1
/src/gcc/8-branch/gcc/final.c:3142
0xb5c7a9 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/src/gcc/8-branch/gcc/final.c:3221
0xb58a26 final_1
/src/gcc/8-branch/gcc/final.c:2091
0xb616ce rest_of_handle_final
/src/gcc/8-branch/gcc/final.c:4674
0xb61b56 execute
/src/gcc/8-branch/gcc/final.c:4748
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/86220] [9 Regression] ICE in gfc_conv_structure, at fortran/trans-expr.c:7789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86220 --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to G. Steinmetz from comment #0) > Introduced between 20180520 and 20180527. It wasn't introduced. It wa uncovered. :-) > > $ cat z1.f90 > program p >type t > real :: a = 1 > integer, pointer :: b >end type >type(t) :: z >integer, save, target :: x = 789 >data z%b /x/ > end > The code is invalid Fortran, so technically gfortran can do anything including ICE.
[Bug c/86221] _Generic not match function return that has _Atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86221 --- Comment #1 from joseph at codesourcery dot com --- The C17 specification for function return types says "function returning the unqualified version of T", not "function returning the unqualified, non-atomic version of T". I believe the normal rule applies that _Atomic, although syntactically a qualifier, is not treated as such unless explicitly stated otherwise (in line with the possibility that an atomic type has different size and alignment, for example, so a function returning an atomic type could quite possibly have a different ABI from a function returning the corresponding non-atomic type). So I believe GCC is correct to have the _Generic match with const, volatile and restrict but not _Atomic.
[Bug c++/38658] trivial try/catch statement not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38658 Martin Sebor changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- Summary|inefficient code on trivial |trivial try/catch statement |try/catch statement |not eliminated --- Comment #3 from Martin Sebor --- There are situations when throwing an exception is required to result in a call to std::terminate() but those require the exception to escape the function where it's thrown from. Outside of those, it seems to me that as long as the observable effect of the optimized code is indistinguishable from the original (such as in the test case) removing try/catch statements should be a valid optimization. Allocating memory is not an observable effect of throwing an exception so it doesn't count. std::uncaught_exception() has to be called along the way so that is also out to the extent that GCC can see the code between the throw expression and the catch block. It's clear that not all cases can be optimized as I suggest but I believe at least some of them can (the one in the test case in comment #0). I'm going to reopen this request. If it turns out that there's something I'm missing we can close it once it's made clear in a test case that the optimization would either be invalid even in that subset of cases, or if it looks like it would not be profitable enough to bother.
[Bug c++/86219] [8/9 Regression] ICE in coerce_template_parms, at cp/pt.c:8515
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86219 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-19 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |8.2 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r258659.
[Bug c/86221] New: _Generic not match function return that has _Atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86221
Bug ID: 86221
Summary: _Generic not match function return that has _Atomic
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
static int * f1(void){return NULL;}
int main(void){
int i = _Generic(f1, int * _Atomic (*)(void): 1, default: 0);
return i;
}
The above _Generic() should match, but does not.
If _Atomic is replaced with any of: const, volatile, restrict,
then it works as expected.
[Bug c++/86218] [9 Regression] ICE in compare_ics, at cp/call.c:9769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86218 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-19 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r261241.
[Bug fortran/86220] New: [9 Regression] ICE in gfc_conv_structure, at fortran/trans-expr.c:7789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86220 Bug ID: 86220 Summary: [9 Regression] ICE in gfc_conv_structure, at fortran/trans-expr.c:7789 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Introduced between 20180520 and 20180527. Inspired by gfortran.dg/data_stmt_pointer.f90 : $ cat z1.f90 program p type t real :: a = 1 integer, pointer :: b end type type(t) :: z integer, save, target :: x = 789 data z%b /x/ end $ gfortran-9-20180520 -c z1.f90 z1.f90:8:14: data z%b /x/ 1 Error: Symbol 'x' must be a PARAMETER in DATA statement at (1) $ gfortran-9-20180617 -c z1.f90 z1.f90:1:0: program p internal compiler error: Segmentation fault 0xb4d14f crash_signal ../../gcc/toplev.c:324 0x7392f0 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc/fortran/trans-expr.c:7789 0x738ec1 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.c:6951 0x7232fa gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1795 0x726007 generate_local_decl ../../gcc/fortran/trans-decl.c:5558 0x6ead4b do_traverse_symtree ../../gcc/fortran/symbol.c:4167 0x7270fc generate_local_vars ../../gcc/fortran/trans-decl.c:5758 0x7270fc gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6402 0x6b63e0 translate_all_program_units ../../gcc/fortran/parse.c:6125 0x6b63e0 gfc_parse_file() ../../gcc/fortran/parse.c:6328 0x6fd4ff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug target/65416] xtensa: memory allocated by alloca is used before the stack pointer is updated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65416 jcmvbkbc at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from jcmvbkbc at gcc dot gnu.org --- The fix is committed to trunk.
[Bug c++/86219] New: [8/9 Regression] ICE in coerce_template_parms, at cp/pt.c:8515
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86219
Bug ID: 86219
Summary: [8/9 Regression] ICE in coerce_template_parms, at
cp/pt.c:8515
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20180318 and 20180325 :
$ cat z1.cc
template struct t;
template
void f ()
{
const int b = "";
t::c;
}
$ gcc-8-20180318 -c z1.cc
$
$ gcc-9-20180617 -c z1.cc
z1.cc: In function 'void f()':
z1.cc:6:7: internal compiler error: in coerce_template_parms, at cp/pt.c:8515
t::c;
^
0x725621 coerce_template_parms
../../gcc/cp/pt.c:8515
0x72d802 lookup_template_class_1
../../gcc/cp/pt.c:9295
0x72d802 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:9647
0x74a71d finish_template_type(tree_node*, tree_node*, int)
../../gcc/cp/semantics.c:3240
0x6f12a2 cp_parser_template_id
../../gcc/cp/parser.c:15943
0x6f13a5 cp_parser_class_name
../../gcc/cp/parser.c:22478
0x6f9ef7 cp_parser_qualifying_entity
../../gcc/cp/parser.c:6564
0x6f9ef7 cp_parser_nested_name_specifier_opt
../../gcc/cp/parser.c:6250
0x6f7dde cp_parser_simple_type_specifier
../../gcc/cp/parser.c:17270
0x6eae95 cp_parser_type_specifier
../../gcc/cp/parser.c:16945
0x6fc399 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:13709
0x703381 cp_parser_simple_declaration
../../gcc/cp/parser.c:13018
0x704e89 cp_parser_declaration_statement
../../gcc/cp/parser.c:12556
0x6eca95 cp_parser_statement
../../gcc/cp/parser.c:10900
0x6ed5b7 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11249
0x6ed68f cp_parser_compound_statement
../../gcc/cp/parser.c:11203
0x6fed01 cp_parser_function_body
../../gcc/cp/parser.c:21886
0x6fed01 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:21921
0x6ff4d0 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:26937
0x7024e1 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:26854
[Bug c++/86218] New: [9 Regression] ICE in compare_ics, at cp/call.c:9769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86218
Bug ID: 86218
Summary: [9 Regression] ICE in compare_ics, at cp/call.c:9769
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed recently, between 20180603 and 20180610 :
$ cat z1.cc
template
void f (const char (&)[a]) { }
void f (int) { }
template
void
g ()
{
f ({2.0});
}
$ gcc-9-20180603 -c z1.cc
$
$ gcc-9-20180617 -c z1.cc
z1.cc: In function 'void g()':
z1.cc:8:11: internal compiler error: Segmentation fault
f ({2.0});
^
0xbabeff crash_signal
../../gcc/toplev.c:324
0x632448 compare_ics
../../gcc/cp/call.c:9769
0x635552 joust
../../gcc/cp/call.c:10158
0x636433 joust
../../gcc/cp/call.c:10094
0x636433 tourney
../../gcc/cp/call.c:10560
0x63ccf8 perform_overload_resolution
../../gcc/cp/call.c:4209
0x63e0d2 build_new_function_call(tree_node*, vec**, int)
../../gcc/cp/call.c:4274
0x74ae15 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.c:2544
0x6f8ced cp_parser_postfix_expression
../../gcc/cp/parser.c:7219
0x700507 cp_parser_unary_expression
../../gcc/cp/parser.c:8295
0x6e0e72 cp_parser_cast_expression
../../gcc/cp/parser.c:9063
0x6e1511 cp_parser_binary_expression
../../gcc/cp/parser.c:9164
0x6e1bc3 cp_parser_assignment_expression
../../gcc/cp/parser.c:9459
0x6e2264 cp_parser_expression
../../gcc/cp/parser.c:9628
0x6e4d94 cp_parser_expression_statement
../../gcc/cp/parser.c:11106
0x6ec8b7 cp_parser_statement
../../gcc/cp/parser.c:10910
0x6ed5b7 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11249
0x6ed68f cp_parser_compound_statement
../../gcc/cp/parser.c:11203
0x6fed01 cp_parser_function_body
../../gcc/cp/parser.c:21886
0x6fed01 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:21921
[Bug c++/86192] A not fully fixed bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86192 --- Comment #2 from Jason Merrill --- Author: jason Date: Tue Jun 19 18:46:51 2018 New Revision: 261757 URL: https://gcc.gnu.org/viewcvs?rev=261757=gcc=rev Log: PR c++/86192 - ICE with anonymous union passed to template. * pt.c (tsubst_expr) [DECL_EXPR]: Handle an anonymous union type used to declare a named variable. Added: trunk/gcc/testsuite/g++.dg/template/anonunion3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c/86217] New: option aux-info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86217
Bug ID: 86217
Summary: option aux-info
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hans.buchmann at fhnw dot ch
Target Milestone: ---
Created attachment 44297
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44297=edit
The output file
Compiling the code
static inline int arch_within_stack_frames(const void * const stack,
const void * const stackend,
const void *obj, unsigned long len)
{
return 0;
}
static int arch_within_stack_frames(const void * const stack,
const void * const stackend,
const void *obj, unsigned long len);
---
with
gcc -aux-info aux-info.data \
-c \
-oaux-info.o \
aux-info.c
yields for aux-info.data:
---
/* compiled from: . */
/* aux-info.c:2:NF */
static int arch_within_stack_frames (const void *const const stack, const void
*const const stackend, const void *obj, long unsigned int len);
// !!twice
const
/* (stack, stackend, obj, len) const void *const const stack; const void *const
const stackend; const void *obj; long unsigned int len; */
/* aux-info.c:10:NC */
static int arch_within_stack_frames (const void *const , const void *const ,
const void *, long unsigned int);
it seems that the keyword 'inline' doubles the keyword const.
gcc -v:
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 8.1.1 20180531 (GCC)
Sincerely
Hans Buchmann
[Bug c++/86216] g++ ICE on valid code: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86216 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-19 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. Even GCC 5 ICEs.
[Bug c++/86216] New: g++ ICE on valid code: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86216
Bug ID: 86216
Summary: g++ ICE on valid code: verify_ssa failed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: helloqirun at gmail dot com
Target Milestone: ---
g++8.1 emits yet another error...
$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.0 20180619 (experimental) [trunk revision 261742] (GCC)
$ g++-trunk -c abc.c
abc.c: In lambda function:
abc.c:11:23: error: definition in block 2 follows the use
int main() { b(2, 3); }
^
for SSA_NAME: _1 in statement:
_1 = _1 + 1;
during GIMPLE pass: ssa
abc.c:11:23: internal compiler error: verify_ssa failed
0x108c557 verify_ssa(bool, bool)
../../gcc/gcc/tree-ssa.c:1188
0xdcc8ad execute_function_todo
../../gcc/gcc/passes.c:1950
0xdcd6be execute_todo
../../gcc/gcc/passes.c:1997
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ g++-8.1 abc.c
during RTL pass: expand
abc.c: In lambda function:
abc.c:7:5: internal compiler error: in expand_expr_real_1, at expr.c:10001
n = sizeof(buffer1[n]);
^
0x5d5fbe expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-8.1.0/gcc/expr.c:9995
0x8e9202 expand_expr
../../gcc-8.1.0/gcc/expr.h:280
0x8e9202 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc-8.1.0/gcc/expr.c:8466
0x7e9151 expand_gimple_stmt_1
../../gcc-8.1.0/gcc/cfgexpand.c:3729
0x7e9151 expand_gimple_stmt
../../gcc-8.1.0/gcc/cfgexpand.c:3790
0x7ea0df expand_gimple_basic_block
../../gcc-8.1.0/gcc/cfgexpand.c:5819
0x7ef4e6 execute
../../gcc-8.1.0/gcc/cfgexpand.c:6425
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ cat abc.c
typedef int intptr_t;
template void b(intptr_t n, T arg) {
typedef intptr_t ArrTy[arg];
ArrTy buffer2;
ArrTy buffer1[arg];
[&] {
n = sizeof(buffer1[n]);
[&] { n = sizeof(buffer2); }();
}();
}
int main() { b(2, 3); }
[Bug target/65416] xtensa: memory allocated by alloca is used before the stack pointer is updated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65416 --- Comment #3 from jcmvbkbc at gcc dot gnu.org --- Author: jcmvbkbc Date: Tue Jun 19 18:26:07 2018 New Revision: 261755 URL: https://gcc.gnu.org/viewcvs?rev=261755=gcc=rev Log: xtensa: fix PR target/65416 The issue is caused by reordering of stack pointer update after stack space allocation with instructions that write to the allocated stack space. In windowed ABI register spill area for the previous call frame is located just below the stack pointer and may be reloaded back into the register file on movsp. Implement allocate_stack pattern for windowed ABI configuration and insert an instruction that prevents reordering of frame memory access and stack pointer update. gcc/ 2018-06-19 Max Filippov * config/xtensa/xtensa.md (UNSPEC_FRAME_BLOCKAGE): New unspec constant. (allocate_stack, frame_blockage, *frame_blockage): New patterns. Modified: trunk/gcc/ChangeLog trunk/gcc/config/xtensa/xtensa.md
[Bug c++/81668] LTO ODR warnings are not helpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668 --- Comment #12 from sgunderson at bigfoot dot com --- The spurious warning seems to be gone in GCC 8.
[Bug libgcc/86215] New: Exceptions are broken on OSX when linking with -static-libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86215
Bug ID: 86215
Summary: Exceptions are broken on OSX when linking with
-static-libgcc
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: ryan.burn at gmail dot com
Target Milestone: ---
If I compile program below with g++-7 main.cpp -static-libgcc -static-libstdc++
and run it on OSX, I get
$ ./a.out
Abort trap: 6
$ echo $?
134
instead of printing abc123 as expected
/// main.cpp
#include
#include
int main() try {
throw std::runtime_error{"abc123"};
return 0;
} catch (const std::runtime_error& e) {
std::cout << e.what() << "\n";
return 0;
}
//
Additional information about the environment
$ uname -a
Darwin Ryans-MacBook-Pro.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15
17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64
$ g++-7 --version
g++-7 (Homebrew GCC 7.3.0_1) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See also https://stackoverflow.com/q/50920999/4447365
[Bug libstdc++/86138] C++17: getline(istream, string) crashes on Cygwin because incompatible C++14 function is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86138 --- Comment #9 from Jonathan Wakely --- (In reply to Christian Franke from comment #0) > This is because there is a bogus prototype specialization in basic_string.h: > > template<> > basic_istream& > getline(basic_istream& __in, basic_string& __str, > char __delim); > > There is no implementation for this specialization. As stated above, tThis is wrong, see src/c++98/istream-string.cc where the specialization is defined. > This has apparently the > same effect as the 'extern template' which is disabled for C++17 in > basic_string.tcc: > > #if _GLIBCXX_EXTERN_TEMPLATE > 0 && __cplusplus <= 201402L > ... > extern template > basic_istream& > getline(basic_istream&, string&, char); > ... > #endif > > As a consequence, no C++17 compatible code for this getline() is generated > and the old getline() from cygstdc++-6.dll is called instead. The problem is nothing to do with "C++17 compatible code" it's entirely to do with whether the std::string template is instantiated in the current translation unit, or only in the DLL. Cygwin apparently can't combine definitions of static objects across DLLs, and so fails when anything is instantiated in the current translation unit (so presumably would also happen with Debug Mode, and if _GLIBCXX_EXTERN_TEMPLATE=0, independent of C++14 vs C++17 modes).
[Bug libstdc++/86138] C++17: getline(istream, string) crashes on Cygwin because incompatible C++14 function is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86138
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2018-06-15 00:00:00 |2018-06-19
Ever confirmed|0 |1
--- Comment #8 from Jonathan Wakely ---
(In reply to Christian Franke from comment #5)
> (In reply to Jonathan Wakely from comment #4)
> > What's bogus about it?
>
> Here a simple example which demonstrates the same situation:
>
> $ cat bug.cpp
> template void f(T & x) { x = T(); }
>
> #ifndef FIXED
> template<> void f(int &);
> // no visible implementation => same effect as extern template below!
Not true. Declaring the specialization says there is an explicit
specialization. That's not the same as declaring an explicit instantiation.
Both will prevent the implicit instantiation of the primary template, but they
still mean different things.
You still haven't explained why declaring the specialization is bogus. The
explicit specialization is defined at
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B98/istream-string.cc;h=feb3569c8be48539af52b66d6462c455dfd09a47;hb=HEAD#l120
Why do you think it's bogus to declare that?
"It fixes my crash" doesn't make it bogus.
> > This patch won't be accepted, it's papering over some other problem not
> > fixing anything.
>
> I disagree. This should be fixed anyway, see above.
There's nothing to fix.
If Cygwin doesn't correctly ensure uniqueness of static objects across DLLs
then we can't workaround that, but simply deleting the declaration of the
specialization is wrong (and will result in worse performance because the
specialization for 'char' will not be used when it could be).
Does Cygwin's binutils not support STB_GNU_UNIQUE or the equivalent?
[Bug c++/86190] [6/7/8/9 Regression] -Wsign-conversion ignores explicit conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86190
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #6 from Marek Polacek ---
The warning is produced in
5350 if (! converted)
5351 {
5352 if (TREE_TYPE (op0) != result_type)
5353 op0 = cp_convert_and_check (result_type, op0, complain);
5354 if (TREE_TYPE (op1) != result_type)
5355 op1 = cp_convert_and_check (result_type, op1, complain);
which we didn't enter before, because of this hunk:
@@ -5028,20 +5022,12 @@ cp_build_binary_op (location_t location,
if (short_compare)
{
- /* Don't write , etc., because that would prevent op0
-from being kept in a register.
-Instead, make copies of the our local variables and
-pass the copies by reference, then copy them back afterward. */
- tree xop0 = op0, xop1 = op1, xresult_type = result_type;
+ /* We call shorten_compare only for diagnostic-reason. */
+ tree xop0 = fold_simple (op0), xop1 = fold_simple (op1),
+ xresult_type = result_type;
enum tree_code xresultcode = resultcode;
- tree val
- = shorten_compare (location, , , _type,
+ shorten_compare (location, , , _type,
);
- if (val != 0)
- return cp_convert (boolean_type_node, val, complain);
- op0 = xop0, op1 = xop1;
- converted = 1;
- resultcode = xresultcode;
}
if ((short_compare || code == MIN_EXPR || code == MAX_EXPR)
so converted is now 0 whereas before it was 1.
[Bug libstdc++/86138] C++17: getline(istream, string) crashes on Cygwin because incompatible C++14 function is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86138 --- Comment #7 from Jonathan Wakely --- OK, so then this is the whack Windows linker model, where every DLL has its own address space, and probably the same as PR 81522. Does Cygwin default to _GLIBCXX_USE_CXX11_ABI=0?
[Bug tree-optimization/86203] duplicate non-constant call to strlen() not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86203
--- Comment #4 from Martin Sebor ---
You're right, a strict reading of the standard does imply that the pointer
argument to strlen could point to the integer. I keep forgetting about this
unfortunate loophole. Ironically, the equivalent code using snprintf could be
optimized because the argument to %s "shall be a pointer to the initial element
of an array of character type." I.e., it cannot point to an int object:
int n;
int f (char *s)
{
n = __builtin_snprintf (0, 0, "%s", s);
return __builtin_snprintf (0, 0, "%s", s); // could be replaced by return
n;
}
[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85602 --- Comment #9 from Martin Sebor --- Thanks, r261751 should take care of it. --- Comment #10 from Martin Sebor --- Author: msebor Date: Tue Jun 19 17:30:47 2018 New Revision: 261751 URL: https://gcc.gnu.org/viewcvs?rev=261751=gcc=rev Log: gcc/testsuite/ChangeLog: PR middle-end/85602 * c-c++-common/attr-nonstring-8.c: Adjust text of expected warning to also match C++. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attr-nonstring-8.c
[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85602 --- Comment #9 from Martin Sebor --- Thanks, r261751 should take care of it.
[Bug libstdc++/86138] C++17: getline(istream, string) crashes on Cygwin because incompatible C++14 function is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86138
--- Comment #6 from Christian Franke ---
(In reply to Jonathan Wakely from comment #4)
> Could you please debug this to find where it's crashing and why?
It segfaults with a bogus pointer below std::string::_Rep::_M_dispose().
A comparison of assembly output and object file symbols leads to the root of
the problem:
1) -std=c++14: string::string() and getline() are called from cygstdc++6.dll.
OK.
2) -std=c++17: getline() is called from cygstdc++6.dll. All code for
string::string() is part of the executable. The empty string is initialized
with the static std::string::_Rep::_S_empty_rep_storage[] from the executable.
But getline() uses the string() implementation from the DLL which checks
against the DLL version of _S_empty_rep_storage[] here:
_M_dispose(const _Alloc& __a) _GLIBCXX_NOEXCEPT
{
#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0
if (__builtin_expect(this != &_S_empty_rep(), false))
#endif
{ ... }
This finally results in a bogus delete[] of the _S_empty_rep_storage[] from the
executable.
2) -std=c++17 -static: The linker does not pull another _S_empty_rep_storage[]
from the static library because it already exists in the object file. OK.
This version of the testcase does not crash because _S_empty_rep_storage[] is
not used:
int main()
{
std::string line("x");
std::istringstream stream("*");
std::getline(stream, line, '\n');
return (int)line.c_str()[0];
}
[Bug libstdc++/86138] C++17: getline(istream, string) crashes on Cygwin because incompatible C++14 function is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86138
--- Comment #5 from Christian Franke ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Christian Franke from comment #3)
> > > The extern templates are disabled because std::basic_string has additional
> > > member functions in C++17 mode, and they're not instantiated in the
> > > library.
> > > By disabling the explicit instantiation declarations the compiler will
> > > emit
> > > definitions for the C++17-only member functions.
> > This has no effect due to the bogus specialization in basic_string.h (see
> > patch below).
>
> What's bogus about it?
Here a simple example which demonstrates the same situation:
$ cat bug.cpp
template void f(T & x) { x = T(); }
#ifndef FIXED
template<> void f(int &);
// no visible implementation => same effect as extern template below!
#endif
#if __cplusplus <= 201402L
extern template void f(int &);
#endif
void call_f(int & i) {
f(i);
}
$ g++ -std=c++14 -c -o bug-14.o bug.cpp
$ g++ -std=c++17 -c -o bug-17.o bug.cpp
$ g++ -std=c++17 -DFIXED -c -o bug-17-fixed.o bug.cpp
$ diff -qs bug-14.o bug-17.o ; diff -qs bug-17.o bug-17-fixed.o
Files bug-14.o and bug-17.o are identical
Files bug-17.o and bug-17-fixed.o differ
$ nm -C bug-17.o | grep ' [TU] '
U void f(int&)
T call_f(int&)
$ nm -C bug-17-fixed.o | grep ' [TU] '
T void f(int&)
T call_f(int&)
> This patch won't be accepted, it's papering over some other problem not
> fixing anything.
I disagree. This should be fixed anyway, see above.
[Bug tree-optimization/86214] New: [8 Regression] Strongly increased stack usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86214
Bug ID: 86214
Summary: [8 Regression] Strongly increased stack usage
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Created attachment 44296
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44296=edit
Test case
Hi,
We noticed that MySQL does not pass its test suite when compiled with GCC 8; it
runs out of stack. (GCC 7 is fine.) A reduced test case is included (mostly by
C-Reduce, but it needed some help by hand); most of it appears to be fluff that
keeps the compiler from just optimizing away the entire thing, but the gist of
it seems to be that it inlines the bg::bl() function several times without
caring that it balloons the stack size, and then doesn't manage to shrink the
stack again by overlapping variables. Putting the noinline attribute on
bg::bl() seems to be a workaround for now.
For comparison:
> g++-7 -O2 -Wstack-usage=1 -Wno-return-type -Wno-unused-result -c stack.i
stack.i: In function ‘void c()’:
stack.i:34:6: warning: stack usage is 8240 bytes [-Wstack-usage=]
void c() {
^
> g++-8 -O2 -Wstack-usage=1 -Wno-return-type -Wno-unused-result -c stack.i
>
stack.i: In function ‘void c()’:
stack.i:34:6: warning: stack usage is 32816 bytes [-Wstack-usage=]
void c() {
^
The actual, unreduced file can be found at
https://github.com/mysql/mysql-server/blob/8.0/storage/innobase/row/row0ins.cc#L926
(the line is positioned on a function whose adding noinline helps, although I
don't think it corresponds directly to bg::bl; I think bg::bl might be
ib::error, and the 8192-sized buffer comes from ib::logger::msg).
[Bug libgcc/86213] New: -fsplit-stack runtime may clobber SSE input param reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86213 Bug ID: 86213 Summary: -fsplit-stack runtime may clobber SSE input param reg Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: thanm at google dot com Target Milestone: --- Created attachment 44295 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44295=edit tar file with reproducer sources and makefile The runtime code in libgcc that supports the -fsplit-stack flag can in some cases clobber an SSE register that is being used for parameter passing. The scenario is as follows: - routine A calls routine B, passing a floating point argument (which does in xmm0) - the routine B (compiled with -fsplit-stack) invokes "__morestack", which in turn may wind up calling out to other system routines (mmap for example) - routine B then does something with its floating point argument (xmm0) The code as written in __morestack does not save incoming SSE registers, so if something gets calls that uses SSE, it can lose param values. At the moment the only way to trigger this problem is to insure that the very first call made to __morestack is from a routine with a live floating point input argument (since the SSE clobbering takes place during a call to "getenv", which typically only is invoked on the first pass through the code). So this qualifies as a pretty obscure bug. Reproducer case attached (written for linux/x86). Example of failing run: $ make clean ; make run rm -f *.o *.so main gcc -c -O -fPIC -o main.o main.c gcc -c -fsplit-stack -O -fPIC -o m1.o m1.c gcc -c -O -fPIC -o m2.o m2.c gcc -O -fuse-ld=gold -fPIC -shared m1.o m2.o -o m1.so gcc -O -fuse-ld=gold main.o -o main m1.so LD_LIBRARY_PATH=`pwd` ./main in main noframe(64.00) = 0.00 Last value should be 64.0, not 0.0. Example of passing run (here with -m32): $ make clean ; make run EXTRA=-m32 rm -f *.o *.so main gcc -c -O -m32 -fPIC -o main.o main.c gcc -c -fsplit-stack -O -m32 -fPIC -o m1.o m1.c gcc -c -O -m32 -fPIC -o m2.o m2.c gcc -O -m32 -fuse-ld=gold -fPIC -shared m1.o m2.o -o m1.so gcc -O -m32 -fuse-ld=gold main.o -o main m1.so LD_LIBRARY_PATH=`pwd` ./main in main noframe(64.00) = 64.00
[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85602 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #8 from seurer at gcc dot gnu.org --- The new test cases fails in some cases: make -k check-gcc RUNTESTFLAGS=dg.exp=c-c++-common/attr-nonstring-8.c # of expected passes17 # of expected passes45 # of unexpected failures6 FAIL: c-c++-common/attr-nonstring-8.c -std=gnu++98 (test for warnings, line 63) FAIL: c-c++-common/attr-nonstring-8.c -std=gnu++98 (test for excess errors) FAIL: c-c++-common/attr-nonstring-8.c -std=gnu++11 (test for warnings, line 63) FAIL: c-c++-common/attr-nonstring-8.c -std=gnu++11 (test for excess errors) FAIL: c-c++-common/attr-nonstring-8.c -std=gnu++14 (test for warnings, line 63) FAIL: c-c++-common/attr-nonstring-8.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/attr-nonstring-8.c -std=gnu++98 (test for excess errors) Excess errors: /home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/attr-nonstring-8.c:63:3: warning: argument to 'sizeof' in 'char* strncat(char*, const char*, long unsigned int)' call is the same expression as the source; did you mean to provide an explicit length? [-Wsizeof-pointer-memaccess]
[Bug other/86198] Libbacktrace does not properly work with ".note.gnu.build-id" section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86198 --- Comment #3 from Ian Lance Taylor --- I don't a reason to change the test to ==. I don't see what would be helped by that. Note that Richi already approved the change to <=.
[Bug libstdc++/70940] pmr::resource_adaptor requires optional allocator requirements and incorrectly aligns returned pointers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940 Jonathan Wakely changed: What|Removed |Added Target Milestone|7.4 |---
[Bug c++/85731] [8/9 Regression] Inner class method declaration changes meaning of outer template class template method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85731 Jonathan Wakely changed: What|Removed |Added CC||paolo.monteverde at gmail dot com --- Comment #5 from Jonathan Wakely --- *** Bug 86195 has been marked as a duplicate of this bug. ***
[Bug c++/86195] [9 Regression] Ref-qualified nested class member function issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86195 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Jonathan Wakely --- This was fixed on gcc-8-branch by r261197 PR c++/85731 - wrong error with qualified-id in template. * semantics.c (finish_qualified_id_expr): build_qualified_name for unbound names in the current class. And it's also fixed on current trunk, presumably by r261196 I'm going to close this as a dup of Bug 85731 since it started to fail with the same revision, and was fixed by the same revision. *** This bug has been marked as a duplicate of bug 85731 ***
[Bug other/86198] Libbacktrace does not properly work with ".note.gnu.build-id" section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86198
--- Comment #2 from Denis Khalikov ---
Looks like that feature was implemented by this patch:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blobdiff;f=bfd/opncls.c;h=b4d4dcf64643145e71e70dba29cd8208c945ddec;hp=10684d2682da7623f4b2f3426eaa2d2ba0cd85b0;hb=2425a30e406a0523020b7e70abb864a06a45bb97;hpb=620214f742f7816e2844e1bb7f78a7a684431927
As I understood that code right, it takes "error" branch if size of the section
less than 0x24.
if (size < 0x24)
{
bfd_set_error (bfd_error_invalid_operation);
return NULL;
}
The libbacktrace instead verifies the section to be less than 0x24, should we
change it
from:
2871 && shdr->sh_size < 12 + ((note->namesz + 3) & ~ 3) +
note->descsz)
to:
2871 && shdr->sh_size == 12 + ((note->namesz + 3) & ~ 3) +
note->descsz)
?
[Bug c++/86212] [9 Regression] ICE in tsubst_copy, at cp/pt.c:15935
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86212 --- Comment #3 from Marek Polacek --- Started with r258755.
[Bug c++/86212] [9 Regression] ICE in tsubst_copy, at cp/pt.c:15935
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86212 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |9.0 Summary|ICE in tsubst_copy, at |[9 Regression] ICE in |cp/pt.c:15935 |tsubst_copy, at ||cp/pt.c:15935
[Bug c++/86212] ICE in tsubst_copy, at cp/pt.c:15935
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86212 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-19 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed. Has to be compiled with -fconcepts.
[Bug libstdc++/82644] Non-standard hypergeometric special functions defined in strict modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82644 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.2 --- Comment #8 from Jonathan Wakely --- Fixed for 8.2 I'm not going to backport this to gcc-7-branch now, as it only affects C++17 mode and I think it's reasonable to tell people to use gcc-8 or trunk if they need these fixes.
[Bug libstdc++/82644] Non-standard hypergeometric special functions defined in strict modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82644 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Tue Jun 19 13:16:44 2018 New Revision: 261743 URL: https://gcc.gnu.org/viewcvs?rev=261743=gcc=rev Log: PR libstdc++/82644 define TR1 hypergeometric functions in strict modes Following a recent change for PR 82644 the non-standard hypergeomtric functions are not defined by when __STRICT_ANSI__ is defined (e.g. for -std=c++17, or -std=c++14 -D__STDCPP_WANT_MATH_SPEC_FUNCS__). That caused errors in because the using-declarations for tr1::hyperg et al are invalid in strict modes. The solution is to define the TR1 hypergeometric functions inline in if __STRICT_ANSI__ is defined. Backport from mainline 2018-05-03 Jonathan Wakely PR libstdc++/82644 * include/tr1/cmath [__STRICT_ANSI__] (hypergf, hypergl, hyperg): Use inline definitions instead of using-declarations. [__STRICT_ANSI__] (conf_hypergf, conf_hypergl, conf_hyperg): Likewise. * testsuite/tr1/5_numerical_facilities/special_functions/ 07_conf_hyperg/compile_cxx17.cc: New. * testsuite/tr1/5_numerical_facilities/special_functions/ 17_hyperg/compile_cxx17.cc: New. Added: branches/gcc-8-branch/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/07_conf_hyperg/compile_cxx17.cc branches/gcc-8-branch/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/17_hyperg/compile_cxx17.cc Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/tr1/cmath
[Bug other/86198] Libbacktrace does not properly work with ".note.gnu.build-id" section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86198
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #1 from Ian Lance Taylor ---
I think you're right but it's interesting to note that I was just copying this
code more or less from gdb, and in bfd/opncls.c the code says
/* FIXME: Should we support smaller build-id notes ? */
if (size < 0x24)
{
bfd_set_error (bfd_error_invalid_operation);
return NULL;
}
I wonder if that should also be <=.
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 --- Comment #6 from Richard Biener --- Since you are trying to combine loads you may run afoul of STLF issues on modern CPU architectures which generally cannot forward from separate stores to a larger load. Not sure if that applies to ARM but I would be surprised if at least high-performance cores do not have store-to-load forwarding capabilities. Merging stores is generally fine (well, x86 knowledge only...) since forwarding from larger stores to smaller loads can work.
[Bug ada/86211] GCC 8 ada cannot build GCC 7 ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86211 Arnaud Charlet changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Arnaud Charlet --- Ah yes, so basically you're doomed: this is a pretty fundamental change which has zero chance to work with GCC 7, sorry.
[Bug c++/86210] [6/7/8/9 Regression] Missing -Wnonnull warning for function defined in the same TU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86210 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.5
[Bug ada/86211] GCC 8 ada cannot build GCC 7 ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86211 --- Comment #2 from rguenther at suse dot de --- On Tue, 19 Jun 2018, charlet at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86211 > > Arnaud Charlet changed: > >What|Removed |Added > > CC||charlet at gcc dot gnu.org > > --- Comment #1 from Arnaud Charlet --- > As you said, this combination isn't guaranteed to work, although I'm > surprising > by the gcc command line you showed, which doesn't include -Iada/libgnat or > -I../../gcc/ada/libgnat as per ADA_INCLUDES in gcc-interface/Make-lang.in: > > ADA_INCLUDES = -nostdinc -I- -I. -Iada/generated -Iada -I$(srcdir)/ada > -I$(srcdir)/ada/gcc-interface -Iada/libgnat -I$(srcdir)/ada/libgnat > > So I'd suggest double checking your source tree here, maybe you have some > local > changes that are modifying ADA_INCLUDES? I'm building the GCC 7 branch which has the following in gcc-interface/Make-lang.in: ADA_INCLUDES = -nostdinc -I- -I. -Iada/generated -Iada -I$(srcdir)/ada -I$(srcdir)/ada/gcc-interface The GCC 7 branch doesn't seem to have a libgnat subdirectory under ada/
[Bug ada/86211] GCC 8 ada cannot build GCC 7 ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86211 Arnaud Charlet changed: What|Removed |Added CC||charlet at gcc dot gnu.org --- Comment #1 from Arnaud Charlet --- As you said, this combination isn't guaranteed to work, although I'm surprising by the gcc command line you showed, which doesn't include -Iada/libgnat or -I../../gcc/ada/libgnat as per ADA_INCLUDES in gcc-interface/Make-lang.in: ADA_INCLUDES = -nostdinc -I- -I. -Iada/generated -Iada -I$(srcdir)/ada -I$(srcdir)/ada/gcc-interface -Iada/libgnat -I$(srcdir)/ada/libgnat So I'd suggest double checking your source tree here, maybe you have some local changes that are modifying ADA_INCLUDES?
[Bug c++/86212] ICE in tsubst_copy, at cp/pt.c:15935
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86212 --- Comment #1 from Hannes Hauswedell --- Created attachment 44294 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44294=edit second intermediate file
[Bug c++/86212] New: ICE in tsubst_copy, at cp/pt.c:15935
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86212
Bug ID: 86212
Summary: ICE in tsubst_copy, at cp/pt.c:15935
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Created attachment 44293
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44293=edit
rename to .gz and gunzip
% uname -a
FreeBSD 11.1-RELEASE-p4 FreeBSD 11.1-RELEASE-p4 #0: Tue Nov 14 06:12:40
UTC 2017 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
amd64
% g++9 --version
g++9 (FreeBSD Ports Collection) 9.0.0 20180603 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
The ICE does not occur on GCC7 and GCC8. I have attached intermediate files.
This is the build error log:
/home/mi/h4nn3s/devel/seqan3/submodules/range-v3/include/range/v3/view_adaptor.hpp:
In instantiation of 'constexpr
ranges::v3::adaptor_cursor<__gnu_cxx::__normal_iterator >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor
>::adaptor_cursor(Args&& ...) [with Args =
{__gnu_cxx::__normal_iterator > >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor};
typename
meta::v1::detail::_if_::type::value ...>, std::integer_sequence::type::value) || true ...> >, int>,
std::integral_constant >::type = 0][inherited from
ranges::v3::compressed_tuple_detail::compressed_tuple_ > >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor >,
std::integer_sequence >]':
/home/mi/h4nn3s/devel/seqan3/submodules/range-v3/include/range/v3/view_adaptor.hpp:405:50:
required from 'static constexpr ranges::v3::adaptor_cursor_t
ranges::v3::view_adaptor::begin_cursor_(D&) [with D =
const
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >; Derived =
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >; BaseRng =
ranges::v3::iterator_range<__gnu_cxx::__normal_iterator >, __gnu_cxx::__normal_iterator > >; ranges::v3::cardinality Cardinality =
(ranges::v3::cardinality)-1; ranges::v3::adaptor_cursor_t =
ranges::v3::adaptor_cursor<__gnu_cxx::__normal_iterator >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor >;
typename std::decay(), 42))>::type =
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor;
typename std::decay(),
42))>::type>().begin(declval()))>::type =
__gnu_cxx::__normal_iterator >]'
/home/mi/h4nn3s/devel/seqan3/submodules/range-v3/include/range/v3/view_adaptor.hpp:423:193:
required by substitution of 'template > >,
__gnu_cxx::__normal_iterator > > >,
ranges::v3::indirected > > >::type() &&
ranges::v3::concepts::models > >,
__gnu_cxx::__normal_iterator > > > >())), int>::type > constexpr
decltype
(ranges::v3::view_adaptor >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >,
ranges::v3::iterator_range<__gnu_cxx::__normal_iterator >, __gnu_cxx::__normal_iterator > >,
(ranges::v3::cardinality)-1>::begin_cursor_(declval()))
ranges::v3::view_adaptor >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >,
ranges::v3::iterator_range<__gnu_cxx::__normal_iterator >, __gnu_cxx::__normal_iterator > >, (ranges::v3::cardinality)-1>::begin_cursor >() const [with D =
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >; int
_concept_requires_421 = 42; typename std::enable_if<((_concept_requires_421 ==
43) || (typename ranges::v3::concepts::Same::same > >,
__gnu_cxx::__normal_iterator > > >,
ranges::v3::indirected > > >::type() &&
ranges::v3::concepts::models > >,
__gnu_cxx::__normal_iterator > > > >())), int>::type = 0]'
/home/mi/h4nn3s/devel/seqan3/submodules/range-v3/include/range/v3/range_access.hpp:175:35:
required by substitution of 'template static constexpr decltype
(static_cast(rng).begin_cursor())
ranges::v3::range_access::begin_cursor(Rng&, int) [with Rng = const
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >]'
/home/mi/h4nn3s/devel/seqan3/submodules/range-v3/include/range/v3/view_facade.hpp:35:68:
required by substitution of 'template using facade_iterator_t
= ranges::v3::_basic_iterator_::basic_iterator(), 42))>::type> [with
Derived = const
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >]'
/home/mi/h4nn3s/devel/seqan3/submodules/range-v3/include/range/v3/view_facade.hpp:91:48:
required by substitution of 'template > >,
__gnu_cxx::__normal_iterator >
[Bug ada/86211] New: GCC 8 ada cannot build GCC 7 ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86211 Bug ID: 86211 Summary: GCC 8 ada cannot build GCC 7 ada Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- Not sure whether this can be worked around for GCC 7 or GCC 8 but it's unfortunate that the GCC 8 ada compiler cannot be used to bootstrap GCC 7 with ada enabled. Yes, I know this isn't really supported but it's unfortunate because it makes me unable to bootstrap/test patches with ada on the GCC 6 and 7 branches on the systems that have the system compiler updated to GCC 8. The specific error I am getting is [ 154s] gcc -c -g -O2 -gnatp -gnatws -nostdinc -I- -I. -Iada/generated -Iada -I../../gcc/ada -I../../gcc/ada/gcc-interface \ [ 154s] ada/b_gnat1.adb -o ada/b_gnat1.o [ 154s] b_gnat1.adb:174:79: "SS_Stack" not declared in "Secondary_Stack" [ 154s] b_gnat1.adb:174:89: incorrect constraint for this kind of type [ 154s] b_gnat1.adb:268:56: "Runtime_Default_Sec_Stack_Size" not declared in "Parameters" [ 154s] make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:949: ada/b_gnat1.o] Error 1 maybe there's a workaround available? Using system GCC 7 was fine for bootstrapping and testing patches on the GCC 6 branch.
[Bug target/86197] POWERPC: float128 parameter passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86197 --- Comment #3 from Segher Boessenkool --- Author: segher Date: Tue Jun 19 10:52:39 2018 New Revision: 261738 URL: https://gcc.gnu.org/viewcvs?rev=261738=gcc=rev Log: rs6000: Fix vector homogeneous aggregates (PR86197) The existing code allows only 4 vectors worth of ieee128 homogeneous aggregates, but it should be 8. This happens because at one spot it is mistakenly qualified as being passed in floating point registers. PR target/86197 * config/rs6000/rs6000.md (rs6000_discover_homogeneous_aggregate): An ieee128 argument takes up only one (vector) register, not two (floating point) registers. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug c++/86210] New: [6/7/8/9 Regression] Missing -Wnonnull warning for function defined in the same TU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86210
Bug ID: 86210
Summary: [6/7/8/9 Regression] Missing -Wnonnull warning for
function defined in the same TU
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
void * declared_not_defined(void * p) __attribute__((nonnull));
inline void * declared_and_defined(void * p) __attribute__((nonnull));
int main()
{
int * const p = 0;
declared_not_defined(p);
declared_and_defined(p);
}
void * declared_and_defined(void * p) { return p; }
G++ 5 and 6 fail to give any warnings at all, at any optimisation level.
G++ 7 and 8 and trunk only warn at -O1 and higher, and only for one of the two
calls:
x.cc: In function ‘int main()’:
x.cc:8:25: warning: argument 1 null where non-null expected [-Wnonnull]
declared_not_defined(p);
^~~
x.cc:1:8: note: in a call to function ‘void* declared_not_defined(void*)’
declared here
void * declared_not_defined(void * p) __attribute__((nonnull));
^~~~
G++ 4.7, 4.8 and 4.9 warns about both calls, without any optimisation:
x.cc: In function ‘int main()’:
x.cc:8:27: warning: null argument where non-null required (argument 1)
[-Wnonnull]
declared_not_defined(p);
^
x.cc:9:27: warning: null argument where non-null required (argument 1)
[-Wnonnull]
declared_and_defined(p);
^
Compiling it as C gives almost the opposite results! I get no warnings for any
release before 7.1, and a warning for only one function with 7.1 but only with
optimisation, and warnings for both function for 8.1 with optimisation. So for
C thigns have been getting gradually better, but worse for C++.
[Bug lto/86004] [9 regression] Several lto test cases begin failing with r260963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86004 --- Comment #6 from Jan Hubicka --- If I recall correctly, old binutils issue warning when plugin produce IL file which is done for incremental linking. I do not think there is a way to prevent this message from gcc side other than requiring binutils 2.27+ One way to silence the warning would be simply to add -flinker-output=nolto-rel to all the testcases (so we do not do incremental IL linking) but it will make it still harder to add testcases for incremental link IL linking if we want to support them on older binutils somehow (i.e. by disabling the tests or tolerating false warning)
[Bug c++/86207] A recurring bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86207 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- This is the same as Bug 86192 that you already reported, which is a duplicate of Bug 80061 In fact it's almost identical to Bug 80061 comment 1. Please search for duplicates before filing bugs. *** This bug has been marked as a duplicate of bug 80061 ***
[Bug c++/80061] error on constexpr function with an unevaluated throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80061 --- Comment #6 from Jonathan Wakely --- *** Bug 86207 has been marked as a duplicate of this bug. ***
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 --- Comment #5 from sameerad at gcc dot gnu.org --- The gimple store merging pass performs load/store merging only if the LHS is memory or constant. I am also working on the GIMPLE pass which will enhance this to merge other stores as well. However, wanted to do the performance measurement, that is why using the peephole2 pass.
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #4 from ktkachov at gcc dot gnu.org --- I see this effect too. Note that if you want to combine two LDRHs into an LDR you will be creating an unaligned access in a lot of cases, so it may not always be profitable. Also, I think the GIMPLE store merging pass can also merge loads these days. Would be good to check why it doesn't handle this case.
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 --- Comment #3 from Ramana Radhakrishnan --- (In reply to sameerad from comment #2) > Ramana, it is another peephole that I am trying to explore for falkor. It > combines loads/stores of shorter types (QI/HI/SI) into single load/store of > larger type (SI/DI). Ah I see. Sorry , not enough coffee yet.
[Bug c++/86208] [6/7/8/9 Regression] improper handling of an extern declared inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86208 --- Comment #2 from Jonathan Wakely --- Possibly related to Bug 82204
[Bug libstdc++/86138] C++17: getline(istream, string) crashes on Cygwin because incompatible C++14 function is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86138 Jonathan Wakely changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #4 from Jonathan Wakely --- (In reply to Christian Franke from comment #3) > > The extern templates are disabled because std::basic_string has additional > > member functions in C++17 mode, and they're not instantiated in the library. > > By disabling the explicit instantiation declarations the compiler will emit > > definitions for the C++17-only member functions. > This has no effect due to the bogus specialization in basic_string.h (see > patch below). What's bogus about it? > Sorry. New testcase below: Thanks. > $ g++ -std=c++17 -o getlinetest getlinetest.cpp && ./getlinetest; echo $? > Aborted (core dumped) > 134 Could you please debug this to find where it's crashing and why? > $ g++ -std=c++17 -static -o getlinetest getlinetest.cpp && ./getlinetest;\ > echo $? > 42 > > Interestingly the statically linked version works. Is there possibly some > template function called by getline() which is not C++17 compatible? There should be nothing in libstdc++ which is not C++17 compatible. > Possible fix (char only, should also be done for wchar_t): This patch won't be accepted, it's papering over some other problem not fixing anything.
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 --- Comment #2 from sameerad at gcc dot gnu.org --- Ramana, it is another peephole that I am trying to explore for falkor. It combines loads/stores of shorter types (QI/HI/SI) into single load/store of larger type (SI/DI).
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Comment #1 from Ramana Radhakrishnan ---
(In reply to sameerad from comment #0)
> While implementing peephole2 for combining shorter types loads/stores into
> larger type load/store, following testcase was found for aarch64 for which
> peephole does not happen because the type of zero/sign extended operands is
> not the same.
>
> Test program:
> unsigned short
> subus (unsigned short *array)
> {
> return array[0] + array[1];
> }
>
> Expander generated RTL:
> (insn 6 3 7 2 (set (reg:HI 96)
> (mem:HI (reg/v/f:DI 94 [ array ]) [1 *array_4(D)+0 S2 A16]))
> (nil))
> (insn 7 6 8 2 (set (reg:HI 97)
> (mem:HI (plus:DI (reg/v/f:DI 94 [ array ])
> (const_int 2 [0x2])) [1 MEM[(short unsigned int *)array_4(D)
> + 2B]+0 S2 A16]))
> (nil))
> (insn 8 7 9 2 (set (reg:SI 99)
> (subreg:SI (reg:HI 97) 0))
> (nil))
> (insn 9 8 10 2 (set (reg:SI 98)
> (plus:SI (subreg:SI (reg:HI 96) 0)
> (reg:SI 99)))
> (expr_list:REG_EQUAL (plus:SI (subreg:SI (reg:HI 96) 0)
> (subreg:SI (reg:HI 97) 0))
> (nil)))
>
> The combiner combines insn 7 and 8 to generate zero extension to SI mode.
>
> (insn 8 7 9 2 (set (reg:SI 99 [ MEM[(short unsigned int *)array_4(D) + 2B] ])
> (zero_extend:SI (mem:HI (plus:DI (reg/v/f:DI 94 [ array ])
> (const_int 2 [0x2])) [1 MEM[(short unsigned int
> *)array_4(D) + 2B]+0 S2 A16]))) {*zero_extendhisi2_aarch64}
> (expr_list:REG_DEAD (reg/v/f:DI 94 [ array ])
> (nil)))
>
> The reload pass removes SUBREGs, which holds information about desired
> type, because of which HImode regs are zero extended to DImode.
>
> (insn 8 7 6 2 (set (reg:SI 1 x1 [orig:99 MEM[(short unsigned int
> *)array_4(D) + 2B] ] [99])
> (zero_extend:SI (mem:HI (plus:DI (reg/v/f:DI 0 x0 [orig:94 array ]
> [94])
> (const_int 2 [0x2])) [1 MEM[(short unsigned int
> *)array_4(D) + 2B]+0 S2 A16]))) {*zero_extendhisi2_aarch64}
> (nil))
> (insn 6 8 9 2 (set (reg:DI 0 x0)
> (zero_extend:DI (mem:HI (reg/v/f:DI 0 x0 [orig:94 array ] [94]) [1
> *array_4(D)+0 S2 A16]))) {*zero_extendhidi2_aarch64}
> (nil))
> (insn 9 6 14 2 (set (reg:SI 0 x0 [98])
> (plus:SI (reg:SI 0 x0 [orig:96 *array_4(D) ] [96])
> (reg:SI 1 x1 [orig:99 MEM[(short unsigned int *)array_4(D) + 2B]
> ] [99]))){*addsi3_aarch64}
> (nil))
> (insn 14 9 15 2 (set (reg/i:HI 0 x0)
> (reg:HI 0 x0 [98])) {*movhi_aarch64}
> (nil))
> (insn 15 14 17 2 (use (reg/i:HI 0 x0))
> (nil))
> (note 17 15 18 NOTE_INSN_DELETED)
> (note 18 17 0 NOTE_INSN_DELETED)
>
> Now as both memory accesses have different extended types, they cannot be
> combined by peephole.
>
> Because of this, even when sched_fusion has brought the loads/stores closer,
> they cannot be merged.
Hmmm,
ldr w0, [x0]
ldr w1, [x0, 2]
is not the same as
ldp w0, w1, [x0]
ldp w0, w1, [x0] is the same as merging
ldr w0, [x0]
ldr w1, [x0, 4]
Am I missing something ? That would mean it isn't possible to merge this
combination.
Thoughts ...
[Bug target/86209] New: Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
Bug ID: 86209
Summary: Peephole does not happen because the type of zero/sign
extended operands is not the same.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sameerad at gcc dot gnu.org
Target Milestone: ---
While implementing peephole2 for combining shorter types loads/stores into
larger type load/store, following testcase was found for aarch64 for which
peephole does not happen because the type of zero/sign extended operands is not
the same.
Test program:
unsigned short
subus (unsigned short *array)
{
return array[0] + array[1];
}
Expander generated RTL:
(insn 6 3 7 2 (set (reg:HI 96)
(mem:HI (reg/v/f:DI 94 [ array ]) [1 *array_4(D)+0 S2 A16]))
(nil))
(insn 7 6 8 2 (set (reg:HI 97)
(mem:HI (plus:DI (reg/v/f:DI 94 [ array ])
(const_int 2 [0x2])) [1 MEM[(short unsigned int *)array_4(D) +
2B]+0 S2 A16]))
(nil))
(insn 8 7 9 2 (set (reg:SI 99)
(subreg:SI (reg:HI 97) 0))
(nil))
(insn 9 8 10 2 (set (reg:SI 98)
(plus:SI (subreg:SI (reg:HI 96) 0)
(reg:SI 99)))
(expr_list:REG_EQUAL (plus:SI (subreg:SI (reg:HI 96) 0)
(subreg:SI (reg:HI 97) 0))
(nil)))
The combiner combines insn 7 and 8 to generate zero extension to SI mode.
(insn 8 7 9 2 (set (reg:SI 99 [ MEM[(short unsigned int *)array_4(D) + 2B] ])
(zero_extend:SI (mem:HI (plus:DI (reg/v/f:DI 94 [ array ])
(const_int 2 [0x2])) [1 MEM[(short unsigned int
*)array_4(D) + 2B]+0 S2 A16]))) {*zero_extendhisi2_aarch64}
(expr_list:REG_DEAD (reg/v/f:DI 94 [ array ])
(nil)))
The reload pass removes SUBREGs, which holds information about desired type,
because of which HImode regs are zero extended to DImode.
(insn 8 7 6 2 (set (reg:SI 1 x1 [orig:99 MEM[(short unsigned int *)array_4(D) +
2B] ] [99])
(zero_extend:SI (mem:HI (plus:DI (reg/v/f:DI 0 x0 [orig:94 array ]
[94])
(const_int 2 [0x2])) [1 MEM[(short unsigned int
*)array_4(D) + 2B]+0 S2 A16]))) {*zero_extendhisi2_aarch64}
(nil))
(insn 6 8 9 2 (set (reg:DI 0 x0)
(zero_extend:DI (mem:HI (reg/v/f:DI 0 x0 [orig:94 array ] [94]) [1
*array_4(D)+0 S2 A16]))) {*zero_extendhidi2_aarch64}
(nil))
(insn 9 6 14 2 (set (reg:SI 0 x0 [98])
(plus:SI (reg:SI 0 x0 [orig:96 *array_4(D) ] [96])
(reg:SI 1 x1 [orig:99 MEM[(short unsigned int *)array_4(D) + 2B] ]
[99]))){*addsi3_aarch64}
(nil))
(insn 14 9 15 2 (set (reg/i:HI 0 x0)
(reg:HI 0 x0 [98])) {*movhi_aarch64}
(nil))
(insn 15 14 17 2 (use (reg/i:HI 0 x0))
(nil))
(note 17 15 18 NOTE_INSN_DELETED)
(note 18 17 0 NOTE_INSN_DELETED)
Now as both memory accesses have different extended types, they cannot be
combined by peephole.
Because of this, even when sched_fusion has brought the loads/stores closer,
they cannot be merged.
[Bug fortran/86206] ICE in gfc_resolve_forall, at fortran/resolve.c:9989
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86206 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-19 Summary|ICE in forall |ICE in gfc_resolve_forall, ||at fortran/resolve.c:9989 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug c++/86208] [6/7/8/9 Regression] improper handling of an extern declared inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86208 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||3.4.6 Version|unknown |8.1.1 Keywords||link-failure Last reconfirmed||2018-06-19 Ever confirmed|0 |1 Summary|improper handling of an |[6/7/8/9 Regression] |extern declared inline |improper handling of an |function|extern declared inline ||function Target Milestone|--- |6.5 Known to fail||4.0.0 --- Comment #1 from Richard Biener --- Confirmed. clang++ compiles the code OK. We do so only when optimizing (and then probably inlining the call). Seems to be an old regression.
[Bug c++/86208] New: improper handling of an extern declared inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86208
Bug ID: 86208
Summary: improper handling of an extern declared inline
function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
class X {
public:
int i;
};
inline const int& OHashKey(const X& x) {
return x.i;
}
int main() {
extern const int& OHashKey(const X& x);
X x;
return OHashKey(x);
}
It comes from a previous bug report
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3698).
It says that g++3.0 produces a error message when compiling the code:
undefined reference to `OHashKey(X const&)'
I tried the latest g++, and it still produces the identical error message.
Is this a recurring bug?
[Bug c++/86207] A recurring bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86207 --- Comment #1 from zhonghao at pku dot org.cn --- BTW, clang++ accepts the above code.
[Bug c++/86207] New: A recurring bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86207
Bug ID: 86207
Summary: A recurring bug?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
constexpr int f(){
if(true) return 0;
throw 0;
}
int main(){
constexpr auto i = f();
}
It comes from a previous report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371
Benjamin Buch said that the fixed code accepts the above code. I tried the
latest gcc, but it still produces error messages:
expression ‘’ is not a constant expression
throw 0;
Is this a recurring bug?
[Bug fortran/86206] New: ICE in forall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86206 Bug ID: 86206 Summary: ICE in forall Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- This is from c.l.f. posted by Beliavsky on April 27, 2016, it gave (at that time) an ICE in gfortran 5.3, and still does so in the actual trunk. I think this was never reported here on bugzilla. Here is the code: module zero_mod implicit none contains ! pure function zero_vec(xx) result(ret) real , intent(in) :: xx(:) real :: ret(size(xx)) integer :: i forall (i=1:size(xx)) ret(i) = 0.0 end function zero_vec ! pure function zero_mat(xx) result(ret) real , intent(in) :: xx(:,:) real :: ret(size(xx,1),size(xx,2)) integer :: i forall (i=1:size(xx,2)) ret(:,i) = zero_vec(xx(:,i)) end function zero_mat end module zero_mod
