[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349 Eric Botcazou changed: What|Removed |Added Status|NEW |WAITING --- Comment #8 from Eric Botcazou --- > It won't help. Note that my original reproducer was openSUSE package build > (which always uses bootstrap). Well, at least it would give some hint as to what goes wrong and whether this is an issue in GCC 8 or GCC 9. Can you try with GCC 8 itself then?
[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358
--- Comment #5 from Jonathan Wakely ---
This shows it has nothing to do with r243379 at all:
template
struct binary_function
{
typedef _Arg1 first_argument_type;
typedef _Arg2 second_argument_type;
typedef _Result result_type;
};
template
struct less : public binary_function<_Tp, _Tp, bool>
{
constexpr
bool
operator()(const _Tp& __x, const _Tp& __y) const
{ return __x < __y; }
};
int f(int i, int j);
#if __cplusplus < 201703L
int f(int i, int j)
{
return less()(i, j);
}
#else
int main()
{
return less()(3, 4) == f(2, 1);
}
#endif
g++ -flto -c src.cc
g++ -flto -c src.cc -std=c++17 -o src17.o
g++ -flto src.o src17.o
src.cc:10:10: warning: type ‘struct less’ violates the C++ One Definition Rule
[-Wodr]
struct less : public binary_function<_Tp, _Tp, bool>
^
src.cc:10:10: note: a type with different bases is defined in another
translation unit
struct less : public binary_function<_Tp, _Tp, bool>
^
src.cc:14:5: warning: ‘operator()’ violates the C++ One Definition Rule
[-Wodr]
operator()(const _Tp& __x, const _Tp& __y) const
^
src.cc:14:5: note: ‘operator()’ was previously declared here
operator()(const _Tp& __x, const _Tp& __y) const
^
This shows the exact same source code, compiled with -std=c++14 and -std=c++17,
and bogus warnings about different bases.
[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358 Martin Liška changed: What|Removed |Added CC||fdumont at gcc dot gnu.org Known to work||6.4.0 Summary|Combining -std=c++14 and|[7/8/9 Regression] |-std=c++17 objects gives|Combining -std=c++14 and |ODR warnings|-std=c++17 objects gives ||ODR warnings Known to fail||7.3.0, 8.2.0, 9.0 --- Comment #2 from Martin Liška --- I see it starting with r243379, would it be possible culprit of that?
[Bug rtl-optimization/66152] suboptimal load bytes to stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66152 --- Comment #4 from SztfG at yandex dot ru --- GCC from trunk doing this: .Ltext0: .LC0: .string "" .ascii "\001\002\003\004\005\006\007" bar: .LFB0: sub rsp, 24 mov rax, QWORD PTR .LC0[rip] lea rdi, [rsp+8] mov QWORD PTR [rsp+8], rax call foo .LVL0: add rsp, 24 ret .LFE0: instead movabsq $506097522914230528, %rax
[Bug rtl-optimization/66152] [9 Regression] suboptimal load bytes to stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66152 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-15 Version|unknown |9.0 Target Milestone|--- |9.0 Summary|suboptimal load bytes to|[9 Regression] suboptimal |stack |load bytes to stack Ever confirmed|0 |1 --- Comment #6 from Jakub Jelinek --- That only happens if there is '\0' embedded in the created string before end. Anyway, this makes it a regression.
[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350 --- Comment #8 from Jakub Jelinek --- Created attachment 45728 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45728=edit gcc9-pr89350.patch Untested patch for the argc range stuff.
[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358 --- Comment #6 from Jonathan Wakely --- It's true that the two bases are defined in different translation units, but that's irrelevant. What the C++ language requires is that the definitions consist of the same sequence of tokens, it doesn't matter which file they are defined in. If I am allergic to headers it's perfectly fine to copy & paste the same code into the top of every translation unit instead of using headers. The relevant rule is http://eel.is/c++draft/basic.def.odr#12 and the example above doesn't violate it.
[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349 Martin Liška changed: What|Removed |Added Status|WAITING |NEW --- Comment #7 from Martin Liška --- (In reply to Eric Botcazou from comment #6) > > My reproducer described in the first comment was: > > 1) build gcc trunk w/o bootstrap and install it > > 2) use the compiler and build gcc-8 branch w/o bootstrap > > 3) Ada FE is successfully built, but Ada runtime build fails (with gcc-8 Ada > > FE) > > Sure, but the question is what happens if remove --disable-bootstrap from > the configure line you posted? It won't help. Note that my original reproducer was openSUSE package build (which always uses bootstrap).
[Bug rtl-optimization/66152] suboptimal load bytes to stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66152
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
That changed with r263511, which now treats the {0,1,2,3,4,5,6,7} initializer
like "\0\1\2\3\4\5\6\7", so that means even GCC 8 expanded the latter this way.
[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350 --- Comment #6 from Martin Liška --- Created attachment 45727 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45727=edit original test-case
[Bug lto/88858] ICE in rtl_verify_fallthru, at cfgrtl.c:2930 in Firefox build with LTO and PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88858 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||7.4.0 Resolution|--- |FIXED Known to fail|7.4.0 | --- Comment #5 from Martin Liška --- GCC 7 branch is not affected, closing then.
[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358 --- Comment #4 from Jonathan Wakely --- I see this warning even when compiling preprocessed source that was all produced using -std=c++14 (so the input source code is identical): g++ -E main.cpp -o main.ii g++ -E test.cpp -o test.ii g++ -flto -c main.ii -std=c++17 g++ -flto -c test.ii g++ -flto main.o test.o /usr/include/c++/8/bits/stl_function.h:381:12: note: type ‘struct less’ itself violates the C++ One Definition Rule struct less : public binary_function<_Tp, _Tp, bool> ^ So this appears to be a difference introduced by the compiler, not the source code. Either there's a compiler bug causing unwanted differences depending on -sd options, or the warnings need to be suppressed because the differences are intended.
[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350 --- Comment #4 from Jakub Jelinek --- Note, e.g. C99 guarantees that: "If they are declared, the parameters to the main function shall obey the following constraints: — The value of argc shall be nonnegative." Similarly C++, http://eel.is/c++draft/basic.start.main "The value of argc shall be non-negative." So, we could do this, or perhaps add lang_GNU_C () || lang_GNU_CXX () || lang_GNU_OBJC () check too, evrp is pre-IPA pass and thus it can check the defining language easily.
[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350 --- Comment #5 from Martin Liška --- > That said, I bet the original package code didn't have the warning in main > but somewhere else. Yes.
[Bug tree-optimization/89360] New: GCC doesn't emit movcc instruction in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89360
Bug ID: 89360
Summary: GCC doesn't emit movcc instruction in some cases
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: SztfG at yandex dot ru
Target Milestone: ---
Target: x86_64-linux-gnu
Here are two function:
void sort2_ternary(int a, int b, int *pa, int *pb)
{
*pa = a < b ? a : b;
*pb = a < b ? b : a;
}
void sort2_if(int a, int b, int *pa, int *pb)
{
if (a < b) {
*pa = a;
*pb = b;
}
else
{
*pa = b;
*pb = a;
}
}
GCC does not emit CMOVcc (conditional move) on GCC 8.2 if we compile it as C++
code
https://godbolt.org/z/ytE0Ix
sort2_ternary(int, int, int*, int*):
cmp edi, esi
jge .L2
mov eax, edi
mov edi, esi
mov esi, eax
.L2:
mov DWORD PTR [rdx], esi
mov DWORD PTR [rcx], edi
ret
sort2_if(int, int, int*, int*):
cmp edi, esi
jge .L5
mov DWORD PTR [rdx], edi
mov DWORD PTR [rcx], esi
ret
.L5:
mov DWORD PTR [rdx], esi
mov DWORD PTR [rcx], edi
ret
but if compile it as C code, sort2_ternary have MOVcc:
sort2_ternary:
cmp esi, edi
mov eax, edi
cmovle eax, esi
cmovl esi, edi
mov DWORD PTR [rdx], eax
mov DWORD PTR [rcx], esi
ret
but sort2_if remains same.
On GCC trunk there is no difference between compiling this as C or C++ for
sort2_ternary(), but sort2_if() still doesn't have CMOVcc instruction in it for
both case.
Measuring cmov vs branch-mov performance: https://github.com/xiadz/cmov
[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358 --- Comment #3 from Jonathan Wakely --- That change introduces some differences between C++98 and later modes, but the testcase use C++14 and C++17. There are no differences in the code. There's certainly no difference between std::less in the two modes. Even so, we need to be able to make parts of the std::lib conditional on the standard version, as long as the semantics remain the same. These warnings are not helpful if they make users worry about harmless implementation details.
[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Well, we could perhaps do something like:
--- gcc/gimple-ssa-evrp.c.jj2019-01-01 12:37:15.712998659 +0100
+++ gcc/gimple-ssa-evrp.c 2019-02-15 09:27:49.569441402 +0100
@@ -41,6 +41,7 @@ along with GCC; see the file COPYING3.
#include "tree-cfgcleanup.h"
#include "vr-values.h"
#include "gimple-ssa-evrp-analyze.h"
+#include "tree-dfa.h"
class evrp_folder : public substitute_and_fold_engine
{
@@ -307,6 +308,21 @@ execute_early_vrp ()
scev_initialize ();
calculate_dominance_info (CDI_DOMINATORS);
+ /* argc in main is never negative. */
+ if (MAIN_NAME_P (DECL_NAME (current_function_decl))
+ && DECL_ARGUMENTS (current_function_decl))
+{
+ tree argc = DECL_ARGUMENTS (current_function_decl);
+ if (TYPE_MAIN_VARIANT (TREE_TYPE (argc)) == integer_type_node)
+ {
+ argc = ssa_default_def (cfun, argc);
+ if (argc && SSA_NAME_RANGE_INFO (argc) == NULL)
+ set_range_info (argc, VR_RANGE,
+ wi::zero (TYPE_PRECISION (integer_type_node)),
+ wi::to_wide (TYPE_MAX_VALUE (integer_type_node)));
+ }
+}
+
/* Walk stmts in dominance order and propagate VRP. */
evrp_dom_walker walker;
walker.walk (ENTRY_BLOCK_PTR_FOR_FN (cfun));
(not really sure if it will work fine with Ada, it does some games with main).
That said, I bet the original package code didn't have the warning in main but
somewhere else.
[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350 --- Comment #7 from Martin Liška --- Thanks for analysis. > > The bogus warning can be avoided in the first case simply by punting on > offsets that could be in the negative range, but almost certainly not > without some false negatives. Yes, I can confirm that adding a check for negative values can make the warning gone. > I'm not sure it's necessarily a good tradeoff > (I don't know that it isn't either). Is this code representative of some > wide-spread idiom? I see it just in one package.
[Bug lto/45375] [meta-bug] Issues with building Mozilla (i.e. Firefox) with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 Bug 45375 depends on bug 88858, which changed state. Bug 88858 Summary: ICE in rtl_verify_fallthru, at cfgrtl.c:2930 in Firefox build with LTO and PGO https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88858 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337
--- Comment #10 from Rafael Avila de Espindola ---
(In reply to Martin Sebor from comment #9)
> The warning is very simple: it just looks for excessive sizes in calls
> emitted in the optimized IL. When the call is there (either because it's in
> the source code as is or because it's been synthesized by GCC based on the
> invariants it can infer from the code) it triggers. It runs after all
> high-level optimizations, including DCE, and assumes that if the statement
> is in the IL it is reachable. Compiling the test case with
> -fdump-tree-optimized=/dev/stdout shows the GIMPLE the warning works with:
>
>[local count: 233860936]:
> # iftmp.6_113 = PHI
> memset (iftmp.6_113, 0, 18446744073709551613);
>
> I think the issue can essentially be reduced to the following:
>
> $ cat z.c && gcc -O2 -S -fdump-tree-optimized=/dev/stdout z.c
> void f (char *d, const char *s)
> {
> if (__builtin_strstr (s, "ABC"))
> {
> __SIZE_TYPE__ n = __builtin_strlen (s) - 3;
>
> if (n > __builtin_strlen (s)) // cannot be true
> __builtin_memset (d, 0, n - __builtin_strlen (s));
> }
> }
>
> ;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=0)
>
> Removing basic block 6
> Removing basic block 7
> f (char * d, const char * s)
> {
> char * _1;
> long unsigned int _2;
>
>[local count: 1073741824]:
> _1 = __builtin_strstr (s_5(D), "ABC");
> if (_1 != 0B)
> goto ; [70.00%]
> else
> goto ; [30.00%]
>
>[local count: 751619278]:
> _2 = __builtin_strlen (s_5(D));
> if (_2 <= 2)
> goto ; [33.00%]
> else
> goto ; [67.00%]
>
>[local count: 248034361]:
> __builtin_memset (d_6(D), 0, 18446744073709551613); [tail call]
>
>[local count: 1073741824]:
> return;
>
> }
>
>
> z.c: In function ‘f’:
> z.c:8:9: warning: ‘__builtin_memset’ specified size 18446744073709551613
> exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
> 8 | __builtin_memset (d, 0, n - __builtin_strlen (s));
> | ^
>
> GCC doesn't have the smarts to figure out that when s contains a substring
> of length 3 then strlen(s) must be at least 3. As a result, it doesn't
> eliminate the memset call in the function and the warning triggers. Suppose
> we teach GCC how to figure this out from the strstr call (which might be a
> useful optimization) and then someone comes along with a test case that uses
> strspn() instead of strstr(). We can also teach GCC about strstr() but then
> someone else might use regcomp() or some user-defined function that we won't
> have access to. At some point we'll have to call it good enough.
Absolutely, this is the halting problem after all.
The question is not to give up or not, it is whether to warn when we do. If we
do, we get potential warnings every time gcc gives up on solving the halting
problem.
The uninitialized variable warning was at least split in two, one for the cases
where gcc is not sure.
Maybe we should have a general flag that disables all warnings where gcc cannot
prove that there is a path from a function entry to the broken statement?
[Bug c++/89367] New: Constexpr expression is not constexpr in template, but is constexpr in non-template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89367
Bug ID: 89367
Summary: Constexpr expression is not constexpr in template, but
is constexpr in non-template.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frank.secilia at gmail dot com
Target Milestone: ---
Created attachment 45737
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45737=edit
minimal preprocessed test case
Morning, folks!
I'm trying to make compile-time type ids. It's based on the fact that per-type
static instances have unique addresses. I'm using those addresses as the type
id.
Originally, I figured this wouldn't work because taking the address of
something couldn't be constexpr, but the address of a variable is known at
compile time, so I gave it a try. g++ accepts it for a non-template type, but
not if the type is a template.
Attached is a preprocessed minimal test case, but here is something slightly
more verbose with a few comments:
// Concrete type with unique, per-type constexpr id.
struct type_1
{
static constexpr char const unique_address{};
static constexpr void const* const id{_address};
};
constexpr char const type_1::unique_address;
constexpr void const* const type_1::id;
// Another concrete type with same.
struct type_2
{
static constexpr char const unique_address{};
static constexpr void const* const id{_address};
};
constexpr char const type_2::unique_address;
constexpr void const* const type_2::id;
// Types have different ids and these evaluate at compile time, as expected.
static_assert(type_1::id != type_2::id);
// Same, but in a template.
template
struct type_id
{
static constexpr char const unique_address{};
static constexpr void const* const id{_address};
};
template
constexpr char const type_id::unique_address;
template
constexpr void const* const type_id::id;
// This does not compile.
static_assert(type_id::id != type_id::id);
The reasons I think this is a bug is because the only difference between the
succeeding and failing case is that the failing case is templated, and because
this works on clang.
I posted about this on stack overflow here
https://stackoverflow.com/questions/43955536/constexpr-unique-id-compiles-with-clang-but-not-with-gcc.
The simpler example at the bottom is missing a const on the out-of-line
definitions, but the behavior is the same with or without them.
[Bug go/89368] New: [9 regression] ICE in go/gofrontend/expressions.cc:4669 after r268923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89368 Bug ID: 89368 Summary: [9 regression] ICE in go/gofrontend/expressions.cc:4669 after r268923 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: seurer at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- r268922 builds fine but starting with 268923 a bootstrap build ICEs with libtool: compile: /home/seurer/gcc/build/gcc-test2/./gcc/gccgo -B/home/seurer/gcc/build/gcc-test2/./gcc/ -B/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/sys-include -O2 -g -I . -c -fgo-pkgpath=runtime -fgo-c-header=runtime.inc.raw -fgo-compiling-runtime /home/seurer/gcc/gcc-test2/libgo/go/runtime/alg.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/atomic_pointer.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/cgo_gccgo.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/cgocall.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/cgocheck.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/chan.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/compiler.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/cpuprof.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/cputicks.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/debug.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/env_posix.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/error.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/extern.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/fastlog2.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/fastlog2table.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/ffi.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/float.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/hash64.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/heapdump.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/iface.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/lfstack.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/lfstack_64bit.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/lock_futex.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/malloc.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/map.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/map_fast32.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/map_fast64.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/map_faststr.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mbarrier.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mbitmap.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mcache.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mcentral.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mem_gccgo.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mfinal.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mfixalloc.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mgc.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mgc_gccgo.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mgclarge.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mgcmark.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mgcsweep.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mgcsweepbuf.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mgcwork.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mheap.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mprof.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/msan0.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/msize.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mstats.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/mwbbuf.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/netpoll.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/netpoll_epoll.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/os_gccgo.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/os_linux.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/os_linux_ppc64x.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/panic.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/print.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/proc.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/profbuf.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/proflabel.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/race0.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/rdebug.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/relax_stub.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/runtime.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/runtime1.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/runtime2.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/rwmutex.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/select.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/sema.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/signal_gccgo.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/signal_sighandler.go /home/seurer/gcc/gcc-test2/libgo/go/runtime/signal_unix.go
[Bug c++/89367] Constexpr expression is not constexpr in template, but is constexpr in non-template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89367 --- Comment #1 from Frank Secilia --- Created attachment 45738 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45738=edit verbose compiler output
[Bug c++/88512] Too much STL in error output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512
--- Comment #8 from Jonny Grant ---
Another example. 9 line file. Gives 48 lines of STL warnings... G++ only
needs to say something clear:
"error: std::string 'str' is const, and as such insert() method cannot be
called"
// g++ -Wall -c -o int int.cpp
#include
int main()
{
const std::string str ="abc";// NB. This 'str' should not be const
const std::string str2 ="1 ";
str.insert(4, str2);
return str.size();
}
G++8 output:
$ g++-8 -Wall -c -o int int.cpp
int.cpp: In function ‘int main()’:
int.cpp:13:21: error: no matching function for call to
‘std::__cxx11::basic_string::insert(int, const string&) const’
str.insert(4, str2);
^
In file included from /usr/include/c++/8/string:52,
from int.cpp:3:
/usr/include/c++/8/bits/basic_string.h:1524:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::const_iterator, std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type, _CharT) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator =
__gnu_cxx::__normal_iterator >;
typename __gnu_cxx::__alloc_traits::rebind<_CharT>::other>::pointer = char*;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::const_iterator =
__gnu_cxx::__normal_iterator >;
typename __gnu_cxx::__alloc_traits::rebind<_CharT>::other>::const_pointer =
const char*; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type =
long unsigned int]’
insert(const_iterator __p, size_type __n, _CharT __c)
^~
/usr/include/c++/8/bits/basic_string.h:1524:7: note: candidate expects 3
arguments, 2 provided
/usr/include/c++/8/bits/basic_string.h:1568:9: note: candidate: ‘template std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::iterator std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::const_iterator, _InputIterator, _InputIterator) [with _InputIterator =
_InputIterator; = ; _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator]’
insert(const_iterator __p, _InputIterator __beg, _InputIterator __end)
^~
/usr/include/c++/8/bits/basic_string.h:1568:9: note: template argument
deduction/substitution failed:
int.cpp:13:21: note: candidate expects 3 arguments, 2 provided
str.insert(4, str2);
^
In file included from /usr/include/c++/8/string:52,
from int.cpp:3:
/usr/include/c++/8/bits/basic_string.h:1602:7: note: candidate: ‘void
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator,
std::initializer_list<_Tp>) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator =
__gnu_cxx::__normal_iterator >;
typename __gnu_cxx::__alloc_traits::rebind<_CharT>::other>::pointer = char*]’
insert(iterator __p, initializer_list<_CharT> __l)
^~
/usr/include/c++/8/bits/basic_string.h:1602:7: note: no known conversion for
argument 1 from ‘int’ to ‘std::__cxx11::basic_string::iterator’ {aka
‘__gnu_cxx::__normal_iterator >’}
/usr/include/c++/8/bits/basic_string.h:1622:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type,
const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned
int]’
insert(size_type __pos1, const basic_string& __str)
^~
/usr/include/c++/8/bits/basic_string.h:1622:7: note: passing ‘const string*’
{aka ‘const std::__cxx11::basic_string*’} as ‘this’ argument discards
qualifiers
/usr/include/c++/8/bits/basic_string.h:1645:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type,
const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&,
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type,
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned
int]’
insert(size_type __pos1, const basic_string& __str,
^~
/usr/include/c++/8/bits/basic_string.h:1645:7: note: candidate expects 4
arguments, 2 provided
/usr/include/c++/8/bits/basic_string.h:1668:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #11 from rdapp at linux dot ibm.com --- Ping.
[Bug rtl-optimization/89242] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 5, not 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89242 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||7.4.1 Resolution|--- |FIXED Summary|[7 Regression] ICE in |ICE in verify_dominators, |verify_dominators, at |at dominance.c:1184 (error: |dominance.c:1184 (error:|dominator of 7 should be 5, |dominator of 7 should be 5, |not 2) |not 2) | Known to fail|7.4.0 | --- Comment #7 from Martin Liška --- Fixed on all active branches.
[Bug ipa/89009] [7 Regression] Miscompilation (missing function call) with -fvisibility=hidden -fpic -O2 -fno-inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89009 --- Comment #17 from Martin Liška --- Author: marxin Date: Fri Feb 15 10:58:49 2019 New Revision: 268937 URL: https://gcc.gnu.org/viewcvs?rev=268937=gcc=rev Log: Backport r268762 2019-02-15 Martin Liska Backport from mainline 2019-02-11 Martin Liska PR ipa/89009 * ipa-cp.c (build_toporder_info): Remove usage of a param. * ipa-inline.c (inline_small_functions): Likewise. * ipa-pure-const.c (propagate_pure_const): Likewise. (propagate_nothrow): Likewise. * ipa-reference.c (propagate): Likewise. * ipa-utils.c (struct searchc_env): Remove unused field. (searchc): Always search across AVAIL_INTERPOSABLE. (ipa_reduced_postorder): Always allow AVAIL_INTERPOSABLE as the only called IPA pure const can properly not propagate across interposable boundary. * ipa-utils.h (ipa_reduced_postorder): Remove param. 2019-02-15 Martin Liska Backport from mainline 2019-02-11 Martin Liska PR ipa/89009 * g++.dg/ipa/pr89009.C: New test. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/ipa-cp.c branches/gcc-7-branch/gcc/ipa-inline.c branches/gcc-7-branch/gcc/ipa-pure-const.c branches/gcc-7-branch/gcc/ipa-reference.c branches/gcc-7-branch/gcc/ipa-utils.c branches/gcc-7-branch/gcc/ipa-utils.h branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug ipa/89009] Miscompilation (missing function call) with -fvisibility=hidden -fpic -O2 -fno-inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89009 Martin Liška changed: What|Removed |Added Known to work||7.4.0 Summary|[7 Regression] |Miscompilation (missing |Miscompilation (missing |function call) with |function call) with |-fvisibility=hidden -fpic |-fvisibility=hidden -fpic |-O2 -fno-inline |-O2 -fno-inline | Known to fail|7.4.0 | --- Comment #18 from Martin Liška --- Fixed on all active branches.
[Bug ipa/89330] IPA inliner touches released cgraph_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330 --- Comment #6 from Martin Jambor --- Created attachment 45730 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45730=edit Untested fix I'm testing the attached fix.
[Bug rtl-optimization/88308] ICE in maybe_record_trace_start, at dwarf2cfi.c:2309
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88308 --- Comment #6 from acsawdey at gcc dot gnu.org --- Author: acsawdey Date: Fri Feb 15 15:41:25 2019 New Revision: 268942 URL: https://gcc.gnu.org/viewcvs?rev=268942=gcc=rev Log: 2019-02-15 Aaron Sawdey PR rtl-optimization/88308 * shrink-wrap.c (move_insn_for_shrink_wrap): Fix LABEL_NUSES counts on copied instruction. Modified: trunk/gcc/ChangeLog trunk/gcc/shrink-wrap.c
[Bug c++/89367] Constexpr expression is not constexpr in template, but is constexpr in non-template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89367 --- Comment #2 from Frank Secilia --- I searched for existing bugs. I don't know the codebase, but I think it may be another repro case for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53181.
[Bug rtl-optimization/88308] ICE in maybe_record_trace_start, at dwarf2cfi.c:2309
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88308 acsawdey at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from acsawdey at gcc dot gnu.org --- Fixed in trunk.
[Bug target/85711] [8 regression] ICE in aarch64_classify_address, at config/aarch64/aarch64.c:5678
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85711 Wilco changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-15 CC||wilco at gcc dot gnu.org Summary|ICE in |[8 regression] ICE in |aarch64_classify_address, |aarch64_classify_address, |at |at |config/aarch64/aarch64.c:56 |config/aarch64/aarch64.c:56 |78 |78 Ever confirmed|0 |1 Known to fail||8.0 --- Comment #4 from Wilco --- Fixed in GCC9, still failing in GCC8.
[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349 Martin Liška changed: What|Removed |Added Status|WAITING |NEW --- Comment #9 from Martin Liška --- (In reply to Eric Botcazou from comment #8) > > It won't help. Note that my original reproducer was openSUSE package build > > (which always uses bootstrap). > > Well, at least it would give some hint as to what goes wrong and whether > this is an issue in GCC 8 or GCC 9. Can you try with GCC 8 itself then? Building gcc 8 with gcc 8 is fine. Can you please Eric try to reproduce that locally?
[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- Yeah, it adds an artificial field like: unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea939bd0 context > ignored decl_6 QI pr89358.c:2:8 size unit-size align:8 warn_if_not_align:0 offset_align 8 offset bit-offset context chain > DECL_FIELD_IS_BASE is lost after free-lang-data I'd say, so what LTO ODR checking could look for is FIELD_DECL is NULL DECL_NAME, DECL_ARTIFICIAL, DECL_IGNORED_P with size_zero_node DECL_SIZE and ignore those if missing just in one case?
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #12 from Ian Lance Taylor --- Sorry for the delay, will look at the patch now. You can test a single target libgo target by using make to build the /check target. For example, to test the bytes package, cd to the libgo build directory and run "make bytes/check".
[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
--- Comment #14 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #12)
> (In reply to Martin Sebor from comment #11)
> > Ah, but you mentioned elfutilts, not binutils. I've now downloaded and
> > built elfutils-0.175. It took a bit more effort because --disable-werror
> > doesn't work there but once I got past that I just got the three
> > -Wformat-truncation instances below:
> >
> > DiagnosticCount UniqueFiles
> > -Wformat-truncation= 332
> >
> > -Wformat-truncation Instances:
> > /src/elfutils-0.175/src/ar.c:1468
> > /src/elfutils-0.175/src/ar.c:859
> > /src/elfutils-0.175/src/arlib.c:63
>
> I am not seeing these, but they might have been fixed in git. We like to
> keep the code warning free since we always build with -Werror.
Aha, I now see, you are using -Wformat-truncation=2. Then yes, these snprintfs
formats could produce more characters than would fit in the given buffer/size.
But that is kind of the point of the code, that we don't overflow the given
buffer. The snprintf is supposed to truncate to what would fit in these cases.
I can see if I could come up with something smarter to detect this without
using snprintf, but that seems to defeat the point of using snprintf. So for
now we just don't use -Wformat-truncation=2. (Background, ar files are weird,
they use fixed size character fields for numbers as decimal strings without a
zero terminator, but right padded with spaces.)
The specific warnings which we enable can be found in config/eu.am and depend
on some configure checks to make sure gcc supports them:
AM_CFLAGS = -std=gnu99 -Wall -Wshadow -Wformat=2 \
-Wold-style-definition -Wstrict-prototypes -Wtrampolines \
$(LOGICAL_OP_WARNING) $(DUPLICATED_COND_WARNING) \
$(NULL_DEREFERENCE_WARNING) $(IMPLICIT_FALLTHROUGH_WARNING) \
$(if $($(*F)_no_Werror),,-Werror) \
$(if $($(*F)_no_Wunused),,-Wunused -Wextra) \
$(if $($(*F)_no_Wstack_usage),,$(STACK_USAGE_WARNING)) \
$(if $($(*F)_no_Wpacked_not_aligned),-Wno-packed-not-aligned,) \
$($(*F)_CFLAGS)
With the following (if supported):
STACK_USAGE_WARNING=-Wstack-usage=262144
LOGICAL_OP_WARNING=-Wlogical-op
DUPLICATED_COND_WARNING=-Wduplicated-cond
NULL_DEREFERENCE_WARNING=-Wnull-dereference
IMPLICIT_FALLTHROUGH_WARNING=-Wimplicit-fallthrough=5
As you can see individual files can turn off some of these if necessary in the
Makefile by adding file_no_Wxxx. So the easiest way to see which warnings are
used it by running make V=1 which for this specific case gives (note the -m32
since I am running this on x86_64):
gcc -D_GNU_SOURCE -DHAVE_CONFIG_H -DLOCALEDIR='"/usr/local/share/locale"'
-DDEBUGPRED=0 -DSRCDIR=\"/home/mark/src/elfutils/src\"
-DOBJDIR=\"/opt/local/build/elfutils-obj/src\" -I.
-I/home/mark/src/elfutils/src -I.. -I. -I/home/mark/src/elfutils/src
-I/home/mark/src/elfutils/lib -I.. -I/home/mark/src/elfutils/src/../libelf
-I/home/mark/src/elfutils/src/../libebl -I/home/mark/src/elfutils/src/../libdw
-I/home/mark/src/elfutils/src/../libdwelf
-I/home/mark/src/elfutils/src/../libdwfl
-I/home/mark/src/elfutils/src/../libasm -std=gnu99 -Wall -Wshadow -Wformat=2
-Wold-style-definition -Wstrict-prototypes -Wtrampolines -Wlogical-op
-Wduplicated-cond -Wnull-dereference -Wimplicit-fallthrough=5 -Werror -Wunused
-Wextra-D_FORTIFY_SOURCE=2 -m32 -g -O2 -DBAD_FTS=1 -MT readelf.o -MD -MP
-MF .deps/readelf.Tpo -c -o readelf.o /home/mark/src/elfutils/src/readelf.c
/home/mark/src/elfutils/src/readelf.c: In function ‘print_debug_str_section’:
/home/mark/src/elfutils/src/readelf.c:10167:15: error: ‘%*llx’ directive output
between 4 and 2147483647 bytes may cause result to exceed ‘INT_MAX’
[-Werror=format-overflow=]
10167 | printf (" [%*" PRIx64 "] \"%s\"\n", digits, (uint64_t) offset,
str);
| ^~
/home/mark/src/elfutils/src/readelf.c:10167:18: note: format string is defined
here
10167 | printf (" [%*" PRIx64 "] \"%s\"\n", digits, (uint64_t) offset,
str);
/home/mark/src/elfutils/src/readelf.c:10167:15: note: directive argument in the
range [0, 18446744073709551614]
10167 | printf (" [%*" PRIx64 "] \"%s\"\n", digits, (uint64_t) offset,
str);
| ^~
cc1: all warnings being treated as errors
[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #11 from Jan Hubicka --- I will take a look. I suppose the representation of classes differs based on std setting and that makes the ODR verifier to think they are different.
[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364 Martin Liška changed: What|Removed |Added Status|WAITING |NEW CC||marxin at gcc dot gnu.org Known to work|6.4.0 |8.2.0, 9.0 Known to fail||6.4.0 --- Comment #6 from Martin Liška --- Fixed on trunk in r251412 which is a revision where I introduced switch expansion as a GIMPLE pass.
[Bug rtl-optimization/89242] [7 Regression] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 5, not 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89242 --- Comment #6 from Martin Liška --- Author: marxin Date: Fri Feb 15 10:59:02 2019 New Revision: 268938 URL: https://gcc.gnu.org/viewcvs?rev=268938=gcc=rev Log: Backport r268873 2019-02-15 Martin Liska Backport from mainline 2019-02-14 Martin Liska PR rtl-optimization/89242 * dce.c (delete_unmarked_insns): Call free_dominance_info we process a transformation. 2019-02-15 Martin Liska Backport from mainline 2019-02-14 Martin Liska PR rtl-optimization/89242 * g++.dg/pr89242.C: New test. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/dce.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #9 from Martin Liška ---
So I ended up with:
--- 1.ii ---
struct a {};
struct b : a {
} c;
--- 2.ii ---
cat 2.ii
struct a {};
struct b : a {
} c2;
$ g++ -flto -c -std=c++14 1.ii && g++ -flto -c -std=c++17 2.ii && g++ [12].o
-shared
1.ii:2:8: warning: type ‘struct b’ violates the C++ One Definition Rule [-Wodr]
struct b : a {
^
2.ii:2:8: note: a type with different bases is defined in another translation
unit
struct b : a {
^
[Bug fortran/89366] New: Fails to compile BIND(C) interface with assumed-length character argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366 Bug ID: 89366 Summary: Fails to compile BIND(C) interface with assumed-length character argument Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 45736 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45736=edit test code The extensions in C interop imply that an assumed-length character dummy argument can appear in a BIND(C) interface, and is mapped to a C descriptor. However, the attached test code fails to compile with the following error message: assumed_length_01_pos.f90:12:35: 12 | subroutine process_string(this, ierr) BIND(C) | 1 Error: Character argument ?this? at (1) must be length 1 because procedure ?process_string? is BIND(C)
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #14 from Ian Lance Taylor --- OK, patch committed. Should we leave this bug report open?
[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||hubicka at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #10 from Martin Liška --- Started with r241187.
[Bug target/89361] [7/8/9 Regression] s390 broken without S390_USE_TARGET_ATTRIBUTE, likely since r257489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89361 Jakub Jelinek changed: What|Removed |Added CC||krebbel at gcc dot gnu.org Target Milestone|--- |7.5
[Bug target/89361] New: [7/8/9 Regression] s390 broken without S390_USE_TARGET_ATTRIBUTE, likely since r257489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89361
Bug ID: 89361
Summary: [7/8/9 Regression] s390 broken without
S390_USE_TARGET_ATTRIBUTE, likely since r257489
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
When configuring s390x-linux with old binutils or without binutils, when
HAVE_AS_MACHINE_MACHINEMODE is not defined, the resulting compiler is totally
broken.
The problem is that s390_indirect_branch_settings is never called in that case,
so cfun->machine->indirect_branch_{jump,call} and
cfun->machine->function_return_{reg,mem} are indirect_branch_unset / 0 and thus
it emits unconditionally the indirect branch stuff, regardless of what options
user actually used.
[Bug target/89361] [7/8/9 Regression] s390 broken without S390_USE_TARGET_ATTRIBUTE, likely since r257489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89361 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-15 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 45731 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45731=edit gcc9-pr89361.patch Untested fix.
[Bug target/84616] funsafe-math-optimizations leads to incorrect results for 4x4 matrix inversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84616 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- The issues is gone after r255474.
[Bug ipa/89330] IPA inliner touches released cgraph_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330 --- Comment #7 from Martin Liška --- Created attachment 45733 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45733=edit Follow up patch that releases memory Survives GCC LTO bootstrap and can build Inkscape with LTO.
[Bug fortran/89364] New: Assumed rank object with incorrect values for shape and bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89364 Bug ID: 89364 Summary: Assumed rank object with incorrect values for shape and bounds Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 45734 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45734=edit test code The attached code compiles without complaints with gfortran 9.0 trunk, but produces incorrect values for the SHAPE, LBOUND and UBOUND intrinsics on the last dimension if the actual argument is an assumed-size array.
[Bug fortran/89365] New: Inquiry functions for assumed rank objects fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89365 Bug ID: 89365 Summary: Inquiry functions for assumed rank objects fail Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 45735 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45735=edit test code The attached test code produces failures for the SHAPE, LBOUND and UBOUND intrinsics when applied to assumed-rank objects with the POINTER or ALLOCATABLE attribute. Note that for these cases the behaviour should be as for deferred-shape objects.
[Bug target/84616] funsafe-math-optimizations leads to incorrect results for 4x4 matrix inversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84616 --- Comment #5 from rguenther at suse dot de --- On February 15, 2019 2:37:25 PM GMT+01:00, "marxin at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84616 > >Martin Liška changed: > > What|Removed |Added > > CC||marxin at gcc dot gnu.org > >--- Comment #4 from Martin Liška --- >The issues is gone after r255474. Likely latent. The rev. Shouldn't have affected code generation.
[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358
--- Comment #7 from Jonathan Wakely ---
Taking just this code:
template
struct binary_function
{
typedef _Arg1 first_argument_type;
typedef _Arg2 second_argument_type;
typedef _Result result_type;
};
template
struct less : public binary_function<_Tp, _Tp, bool>
{
constexpr
bool
operator()(const _Tp& __x, const _Tp& __y) const
{ return __x < __y; }
};
int f(int i, int j)
{
return less()(i, j);
}
Compiling as C++14 and C++14 and comparing the -fdump-tree-original dumps I
see:
--- f.cc.003t.original.14 2019-02-15 10:43:10.841906030 +
+++ f.cc.003t.original.17 2019-02-15 10:43:15.442914718 +
@@ -10,5 +10,5 @@
;; enabled by -tree-original
-< = (int) less::operator() (_EXPR
, (const int &) , (const int &) )>>;
+< = (int) less::operator() (_EXPR
, (const int &) , (const int &) )>>;
So the generated code is slightly different when using -std=c++17, would that
cause -Wodr to complain?
[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358 Martin Liška changed: What|Removed |Added Keywords||needs-bisection, ||needs-reduction --- Comment #8 from Martin Liška --- I'm trying to creduce that..
[Bug libbacktrace/89362] New: [8/9 regression] zlib support breaks libbacktrace on strict-alignment platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89362
Bug ID: 89362
Summary: [8/9 regression] zlib support breaks libbacktrace on
strict-alignment platforms
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libbacktrace
Assignee: unassigned at gcc dot gnu.org
Reporter: ebotcazou at gcc dot gnu.org
CC: ian at gcc dot gnu.org
Target Milestone: ---
The new zlib support (PR other/67165) has broken the library on
strict-alignment platforms, for example SPARC64/Linux. Here's a typical ICE
report:
ebotcazou@gcc202:~/build$ gcc/cc1 -quiet pr35318.c -m32 -mcpu=ultrasparc
pr35318.c: In function 'foo':
pr35318.c:9:1: error: unrecognizable insn:
9 | }
| ^
(insn 14 28 29 2 (parallel [
(set (reg:DF 10 %o2 [orig:113 x ] [113])
(asm_operands/v:DF ("") ("=r,r") 0 [
(reg:SI 11 %o3 [orig:113 x+4 ] [113])
(mem/c:DF (plus:SI (reg/f:SI 30 %fp)
(const_int -24 [0xffe8])) [3
%sfp+-24 S8 A64])
]
[
(asm_input:DF ("%0,0") pr35318.c:8)
(asm_input:SI ("m,r") pr35318.c:8)
]
[] pr35318.c:8))
(set (reg:DF 2 %g2 [orig:114 y ] [114])
(asm_operands/v:DF ("") ("=r,r") 1 [
(reg:SI 11 %o3 [orig:113 x+4 ] [113])
(mem/c:DF (plus:SI (reg/f:SI 30 %fp)
(const_int -24 [0xffe8])) [3
%sfp+-24 S8 A64])
]
[
(asm_input:DF ("%0,0") pr35318.c:8)
(asm_input:SI ("m,r") pr35318.c:8)
]
[] pr35318.c:8))
]) "pr35318.c":8:3 -1
(nil))
during RTL pass: reload
during RTL pass: reload
pr35318.c:9:1: internal compiler error: in extract_constrain_insn, at
recog.c:2211
pr35318.c:9:1: internal compiler error: Bus error
Bus error
Program received signal SIGBUS, Bus error.
0x01138ab4 in elf_uncompress_chdr (state=0xfff8000100044000,
compressed=0xfff8000104ca48af "", compressed_size=4074875,
zdebug_table=0xfff800010353e000, error_callback=
0x111dfc4 <__sanitizer::(anonymous namespace)::ErrorCallback(void*,
char const*, int)>, data=0x7fed5b8, uncompressed=0x7fec670,
uncompressed_size=0x7fec668)
at
/home/ebotcazou/src/libsanitizer/libbacktrace/../../libbacktrace/elf.c:2580
2580 if (chdr->ch_type != ELFCOMPRESS_ZLIB)
The problem is that most debug sections have alignment 1 so you cannot do:
chdr = (const b_elf_chdr *) compressed;
and expect to have a valid b_elf_chdr on strict-alignment platforms.
This also breaks the sanitizer on these platforms.
[Bug fortran/89363] New: RANK incorrect for unallocated allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89363 Bug ID: 89363 Summary: RANK incorrect for unallocated allocatable Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 45732 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45732=edit test code The attached program compiles without complaints using gfortran 9.0 trunk build, but delivers an incorrect value for the RANK() intrinsic if the dummy is declared with assumed RANK and the ALLOCATABLE attribute, and the actual argument has the status "not allocated". Instead of "2", values are returned that change from run to run.
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #13 from ian at gcc dot gnu.org --- Author: ian Date: Fri Feb 15 14:51:10 2019 New Revision: 268941 URL: https://gcc.gnu.org/viewcvs?rev=268941=gcc=rev Log: PR go/89123 internal/cpu, runtime: add S/390 CPU capability support Patch by Robin Dapp. Updates https://gcc.gnu.org/PR89123 Reviewed-on: https://go-review.googlesource.com/c/162887 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/internal/cpu/cpu_gccgo.c trunk/libgo/go/internal/cpu/cpu_s390x.go trunk/libgo/go/runtime/os_linux_s390x.go
[Bug target/89369] [9 Regression] pseudo-RNG miscompiled on s390x-linux with -O2 -march=zEC12 -mtune=z13 starting with r266203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89369 --- Comment #1 from Jakub Jelinek --- Created attachment 45739 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45739=edit gcc9-pr89369.patch Untested fix. The recently added patterns want to do x |= (unsigned) ((reg:DI) >> cnt), and as the zero_extract in the patterns show, it always wants to extract exactly 32 bits. So, in my understanding of the rsbg instruction, we want to rotate by 32 + cnt (correct in the pattern) and want to use 32,63 as I3/I4, so we only do the operation on the low 32 bits. In the testcase, rxsbg %r1,%r11,40,63,56 is emitted when we need to do: unsigned long long var = 0x50ef69fef3e09994ULL; unsigned r1 = ...; r1 |= (unsigned) (var >> 8); but that instruction instead of doing |= 0xfef3e099 we need is doing |= 0xf3e099, the top 8 bits are lost. The patch changes it to rxsbg %r1,%r11,32,63,56 which works properly. The patch also changes 3 other rxsbg instructions on the testcase, like rxsbg %r12,%r9,64,63,32 which were emitted for |= (unsigned) (var >> 0), note the strange 64 in there, I bet it is xoring also the upper bits of the 64-bit destination, but we don't really care that much about those. That said, the patch changes that to rxsbg %r12,%r9,32,64,32. Finally, I believe having 256 byte static buffer for each of these instructions (times how many times it is expanded for ) is not a good idea, because it increases .bss unnecessarily, plus the %ld in there will not really work e.g. on cross compilers from 32-bit hosts to s390x-linux, while GEN_INT for these small constants, while it creates rtxes, is all cached and likely already constructed.
[Bug c++/88512] Too much STL in error output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512 --- Comment #11 from Jonathan Wakely --- There's also Bug 53281
[Bug target/89372] New: Incorrect PMULHRSW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89372
Bug ID: 89372
Summary: Incorrect PMULHRSW
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
Target Milestone: ---
Target: i386,x86-64
sse.md has
(define_mode_iterator PMULHRSW
[V4HI V8HI (V16HI "TARGET_AVX2")])
(define_expand "_pmulhrsw3_mask"
[(set (match_operand:PMULHRSW 0 "register_operand")
(vec_merge:PMULHRSW
(truncate:PMULHRSW
(lshiftrt:
(plus:
(lshiftrt:
(mult:
(sign_extend:
(match_operand:PMULHRSW 1 "nonimmediate_operand"))
(sign_extend:
(match_operand:PMULHRSW 2 "nonimmediate_operand")))
(const_int 14))
(match_dup 5))
(const_int 1)))
(match_operand:PMULHRSW 3 "register_operand")
(match_operand: 4 "register_operand")))]
"TARGET_AVX512BW && TARGET_AVX512VL"
{
operands[5] = CONST1_RTX(mode);
ix86_fixup_binary_operands_no_copy (MULT, mode, operands);
})
But AVX512BW doesn't support V4HI.
(define_expand "_pmulhrsw3"
[(set (match_operand:PMULHRSW 0 "register_operand")
(truncate:PMULHRSW
(lshiftrt:
(plus:
(lshiftrt:
(mult:
(sign_extend:
(match_operand:PMULHRSW 1 "nonimmediate_operand"))
(sign_extend:
(match_operand:PMULHRSW 2 "nonimmediate_operand")))
(const_int 14))
(match_dup 3))
(const_int 1]
"TARGET_AVX2"
{
operands[3] = CONST1_RTX(mode);
ix86_fixup_binary_operands_no_copy (MULT, mode, operands);
})
But V4HI V8HI doesn't require AVX2.
[Bug middle-end/89371] missed vectorisation with "#pragma omp simd collapse(2)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89371 Jakub Jelinek changed: What|Removed |Added Keywords||missed-optimization, openmp CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Well, in this case I don't see any advantage of using collapsed loops, it won't make the loop more readable and is much harder to vectorize, so why not to write it that way? Yes, there is certainly room for improvement to undo this kind of stuff.
[Bug c++/89370] Output std::string in diagnostics instead of std::__cxx11::basic_string<_CharT, _Traits, _Alloc>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89370 Jonny Grant changed: What|Removed |Added CC||jg at jguk dot org --- Comment #1 from Jonny Grant --- Many thanks! Happy to pay $200 bounty for this feature to implementer or FSF/GNU etc
[Bug c++/89367] Constexpr expression is not constexpr in template, but is constexpr in non-template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89367 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org, ||redi at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- With -fpic it actually rejects both static_asserts. In all the cases, it is symtab_node::equal_address_to that attempts to decide if the two VAR_DECLs need to be the same or distinct or unknown. Without templates and without -fpic that function returns true, because both are defined locally and we can easily decide that they must be different, but with -fpic, the generic code allows them to be interposed and fails. Even without -fpic, for templates the variables are DECL_COMDAT and thus not really known if defined by the current or some other TU. No idea if C++ standard says anything here and constexpr evaluation shouldn't use some different rules (or in addition to what the generic code says).
[Bug target/89369] New: [9 Regression] pseudo-RNG miscompiled on s390x-linux with -O2 -march=zEC12 -mtune=z13 starting with r266203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89369
Bug ID: 89369
Summary: [9 Regression] pseudo-RNG miscompiled on s390x-linux
with -O2 -march=zEC12 -mtune=z13 starting with r266203
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
The following testcase is miscompiled with -O2 -march=zEC12 -mtune=z13 starting
with r266203:
#if __SIZEOF_INT__ == 4 && __SIZEOF_LONG_LONG__ == 8 && __CHAR_BIT__ == 8
struct S { unsigned int u[4]; };
static void
foo (struct S *out, struct S const *in, int shift)
{
unsigned long long th, tl, oh, ol;
th = ((unsigned long long) in->u[3] << 32) | in->u[2];
tl = ((unsigned long long) in->u[1] << 32) | in->u[0];
oh = th >> (shift * 8);
ol = tl >> (shift * 8);
ol |= th << (64 - shift * 8);
out->u[1] = ol >> 32;
out->u[0] = ol;
out->u[3] = oh >> 32;
out->u[2] = oh;
}
static void
bar (struct S *out, struct S const *in, int shift)
{
unsigned long long th, tl, oh, ol;
th = ((unsigned long long) in->u[3] << 32) | in->u[2];
tl = ((unsigned long long) in->u[1] << 32) | in->u[0];
oh = th << (shift * 8);
ol = tl << (shift * 8);
oh |= tl >> (64 - shift * 8);
out->u[1] = ol >> 32;
out->u[0] = ol;
out->u[3] = oh >> 32;
out->u[2] = oh;
}
__attribute__((noipa)) static void
baz (struct S *r, struct S *a, struct S *b, struct S *c, struct S *d)
{
struct S x, y;
bar (, a, 1);
foo (, c, 1);
r->u[0] = a->u[0] ^ x.u[0] ^ ((b->u[0] >> 11) & 0xdfefU) ^ y.u[0] ^
(d->u[0] << 18);
File rh1677602.c saved
[jakub@tucnak gcc]$ cat rh1677602.c
#if __SIZEOF_INT__ == 4 && __SIZEOF_LONG_LONG__ == 8 && __CHAR_BIT__ == 8
struct S { unsigned int u[4]; };
static void
foo (struct S *out, struct S const *in, int shift)
{
unsigned long long th, tl, oh, ol;
th = ((unsigned long long) in->u[3] << 32) | in->u[2];
tl = ((unsigned long long) in->u[1] << 32) | in->u[0];
oh = th >> (shift * 8);
ol = tl >> (shift * 8);
ol |= th << (64 - shift * 8);
out->u[1] = ol >> 32;
out->u[0] = ol;
out->u[3] = oh >> 32;
out->u[2] = oh;
}
static void
bar (struct S *out, struct S const *in, int shift)
{
unsigned long long th, tl, oh, ol;
th = ((unsigned long long) in->u[3] << 32) | in->u[2];
tl = ((unsigned long long) in->u[1] << 32) | in->u[0];
oh = th << (shift * 8);
ol = tl << (shift * 8);
oh |= tl >> (64 - shift * 8);
out->u[1] = ol >> 32;
out->u[0] = ol;
out->u[3] = oh >> 32;
out->u[2] = oh;
}
__attribute__((noipa)) static void
baz (struct S *r, struct S *a, struct S *b, struct S *c, struct S *d)
{
struct S x, y;
bar (, a, 1);
foo (, c, 1);
r->u[0] = a->u[0] ^ x.u[0] ^ ((b->u[0] >> 11) & 0xdfefU) ^ y.u[0] ^
(d->u[0] << 18);
r->u[1] = a->u[1] ^ x.u[1] ^ ((b->u[1] >> 11) & 0xddfecb7fU) ^ y.u[1] ^
(d->u[1] << 18);
r->u[2] = a->u[2] ^ x.u[2] ^ ((b->u[2] >> 11) & 0xbffaU) ^ y.u[2] ^
(d->u[2] << 18);
r->u[3] = a->u[3] ^ x.u[3] ^ ((b->u[3] >> 11) & 0xbff6U) ^ y.u[3] ^
(d->u[3] << 18);
}
int
main ()
{
struct S a[] = { { 0x04d3, 0xbc5448db, 0xf22bde9f, 0xebb44f8f },
{ 0x03a32799, 0x60be8246, 0xa2d266ed, 0x7aa18536 },
{ 0x15a38518, 0xcf655ce1, 0xf3e09994, 0x50ef69fe },
{ 0x88274b07, 0xe7c94866, 0xc0ea9f47, 0xb6a83c43 },
{ 0xcd0d0032, 0x5d47f5d7, 0x5a0afbf6, 0xaea87b24 },
{ 0, 0, 0, 0 } };
baz ([5], [0], [1], [2], [3]);
if (a[4].u[0] != a[5].u[0] || a[4].u[1] != a[5].u[1]
|| a[4].u[2] != a[5].u[2] || a[4].u[3] != a[5].u[3])
__builtin_abort ();
return 0;
}
#else
int
main ()
{
return 0;
}
#endif
[Bug target/89369] [9 Regression] pseudo-RNG miscompiled on s390x-linux with -O2 -march=zEC12 -mtune=z13 starting with r266203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89369 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-15 CC||iii at gcc dot gnu.org, ||krebbel at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug c++/89370] New: Output std::string in diagnostics instead of std::__cxx11::basic_string<_CharT, _Traits, _Alloc>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89370 Bug ID: 89370 Summary: Output std::string in diagnostics instead of std::__cxx11::basic_string<_CharT, _Traits, _Alloc> Product: gcc Version: 9.0 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: --- Errors involving std::string are unreadable (see Bug 88512 comment 8). Nobody cares that it's: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::__const_iterator, _CharT) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator = __gnu_cxx::__normal_iterator >; typename __gnu_cxx::__alloc_traits::rebind<_CharT>::other>::pointer = char*; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::__const_iterator = __gnu_cxx::__normal_iterator >; typename __gnu_cxx::__alloc_traits::rebind<_CharT>::other>::const_pointer = const char*]' 1745 | insert(__const_iterator __p, _CharT __c) | ^~ The type std::__cxx11::basic_string<_CharT, _Traits, _Alloc> should be shown as std::string. That alone makes it far more readable. And if we don't show it as a template specialization maybe we don't need the entire "[with ...]" part at all, but if we do need it, we should reduce it ... I don't think expanding the return type or the __const_iterator type in the "[with ...]" part is very useful: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator = __gnu_cxx::__normal_iterator >; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator = __gnu_cxx::__normal_iterator >; And why on Earth is it telling us what the pointer and const_pointer types are?! They don't appear in the member function signature at all! typename __gnu_cxx::__alloc_traits::rebind<_CharT>::other>::pointer = char*; typename __gnu_cxx::__alloc_traits::rebind<_CharT>::other>::const_pointer = const char* Cool story bro. Those types are not relevant.
[Bug lto/87525] [7/8/9 Regression] infinite loop generated for fread() if enabling -flto and -D_FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87525
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #19 from Martin Jambor ---
(In reply to Jan Hubicka from comment #14)
> Martin,
> it seems to me that ipa-cp should not clone extern inline functions unless
> it sees that it helps to clone some real functions called from it. Why the
> costmodel thinks it is profitable?
It does not special-case that kind of situation. Still it is not
easy, because the cloning decisions are made on the final sweep over
the call graph from callers to callees and whether any callees would
be cloned will only be decided in the future.
Still, the cost model should probably evaluate these cases
differently, perhaps like the patch below. To the extent to which I
am able to reproduce the issue (only on gcc 8 and in the "correct"
case it segfaults as opposed to endless loop), the adjustment helps,
but it is of course only a heuristics.
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index e868b9c2623..f148ceef393 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -4685,15 +4685,23 @@ decide_about_value (struct cgraph_node *node, int
index, HOST_WIDE_INT offset,
fprintf (dump_file, " (caller_count: %i)\n", caller_count);
}
- if (!good_cloning_opportunity_p (node, val->local_time_benefit,
- freq_sum, count_sum,
- val->local_size_cost)
- && !good_cloning_opportunity_p (node,
- val->local_time_benefit
- + val->prop_time_benefit,
- freq_sum, count_sum,
- val->local_size_cost
- + val->prop_size_cost))
+ if (DECL_EXTERNAL (node->decl) && DECL_DECLARED_INLINE_P (node->decl))
+{
+ if (!good_cloning_opportunity_p (node, val->prop_time_benefit,
+ freq_sum, count_sum,
+ val->local_size_cost
+ + val->prop_size_cost))
+ return false;
+}
+ else if (!good_cloning_opportunity_p (node, val->local_time_benefit,
+ freq_sum, count_sum,
+ val->local_size_cost)
+ && !good_cloning_opportunity_p (node,
+ val->local_time_benefit
+ + val->prop_time_benefit,
+ freq_sum, count_sum,
+ val->local_size_cost
+ + val->prop_size_cost))
return false;
if (dump_file)
[Bug c++/88512] Too much STL in error output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512 --- Comment #12 from Jonny Grant --- (In reply to Jonathan Wakely from comment #9) > It's easy for you to say that after looking at the reason it failed and > knowing what the code is trying to do (obviously "insert" modifies the > string, so it can't be const). But the compiler has to try every overload, > and doesn't know what your intention is, or what the word "insert" means. > > The problem here is (as before) that std::string has eight overloads of > insert (and just as many for assign, and begin, and replace etc), and > there's nothing the compiler can do about that. > > Potentially the compiler could be changed so that if all the overload > candidates are non-const and the object is const, it just says that. But > that's another fairly specialized diagnostic just for this case. Most > classes simply don't have eight overloads of the same function. Sounds good, those insert methods aren't 'const' so at least the first line could say that... eg: $ g++ -Wall -c -o int int.cpp int.cpp: In function ‘int main()’: int.cpp:13:21: error: no matching function for call to ‘std::string::insert(size_t, const string&) const’ str.insert(4, str2); ^ Note, ‘str’ is const and all ‘std::string::insert()’ methods are non-const
[Bug c/88944] Suggested alternative C stdbool.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88944 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-15 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Thanks. FWIW trunk (gcc 9) no longer suggests "_Bool". I have a patch pending (for gcc 10) which implements the header suggestion.
[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349 --- Comment #10 from Eric Botcazou --- > Building gcc 8 with gcc 8 is fine. OK, thanks. > Can you please Eric try to reproduce that locally? Sure, as soon as the compiler builds again for me... https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01155.html
[Bug rtl-optimization/66152] [9 Regression] suboptimal load bytes to stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66152 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 45729 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45729=edit gcc9-pr66152.patch Untested fix to handle '\0's embedded at the start of in the middle of STRING_CSTs when storing it into memory.
[Bug c/87210] [RFE] introduce build time options to zero initialize automatic stack variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210 --- Comment #3 from P J P --- Similar options under review for LLVM -> https://lists.llvm.org/pipermail/cfe-dev/2018-November/060172.html
[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | --- Comment #7 from Martin Liška --- Started probably in r228194 (change from 400MB -> 1400MB RAM usage).
[Bug ipa/89330] IPA inliner touches released cgraph_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330 Martin Jambor changed: What|Removed |Added Assignee|hubicka at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #8 from Martin Jambor --- I have proposed the fix on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01225.html
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 Ian Lance Taylor changed: What|Removed |Added CC||doko at debian dot org --- Comment #15 from Ian Lance Taylor --- *** Bug 89277 has been marked as a duplicate of this bug. ***
[Bug go/89277] [9 Regression] libgo memory hogs in libgo testsuite (at least on s390x-linux-gnu)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89277 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Ian Lance Taylor --- Closing as a duplicate per earlier comment. Please comment if you disagree. *** This bug has been marked as a duplicate of bug 89123 ***
[Bug go/89171] FAIL: go/build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89171 --- Comment #1 from Ian Lance Taylor --- I don't know what is happening here and I don't have access to a riscv64 machine to test on (there doesn't seem to be one in the compile farm). The errors are incorrect in that these are not expected dependencies, not unexpected ones. This may be a bug in the generation of top level composite literals, though I can't think of any reason that would be specific to riscv64, and of course it is working on other systems. Do you have any suggestions for how I could debug this?
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #35 from Eric Botcazou --- > Right: 64-bit Solaris/SPARC uses the full 64-bit address space: > > https://docs.oracle.com/cd/E37838_01/html/E66175/advanced-2. > html#SSFDGadvanced-5 > > The gap between the low and high parts cannot be determined > programmatically right now and varies between different sparc machines. Linux uses an equivalent VM layout (although the primary stack is in the low part instead of the high part). I think that on Linux the hole is fully determined by the number of bits available for virtual addresses. > Even if that could be fixed (there's been talk about adding an interface > to determine that information at runtime), the current shadow address > calculation cannot cope with such a discontinuous address space. Right, but you can tweak it once the position of the hole is determined. I have done so for a 52-bit VM layout (T4 and later apparently) and, modulo fixes all over the place (libsanitizer, libbacktrace, compiler, testsuite), I now have a 100% clean ASAN testsuite on both 32-bit and 64-bit SPARC/Linux. Trying on Solaris now...
[Bug go/89368] [9 regression] ICE in go/gofrontend/expressions.cc:4669 after r268923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89368 --- Comment #1 from ian at gcc dot gnu.org --- Author: ian Date: Fri Feb 15 21:04:58 2019 New Revision: 268948 URL: https://gcc.gnu.org/viewcvs?rev=268948=gcc=rev Log: PR go/89368 compiler: write barrier check nil-check policy tweak Tweak the recipe for generating writeBarrier loads to insure that the dereference expr is marked as not requiring a nil check (not needed for gccgo, but needed for gollvm). Fixes https://gcc.gnu.org/PR89368 Reviewed-on: https://go-review.googlesource.com/c/162904 Modified: trunk/gcc/go/gofrontend/MERGE trunk/gcc/go/gofrontend/wb.cc
[Bug c++/84916] Tweaks to template type elision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84916 David Malcolm changed: What|Removed |Added Target Milestone|9.0 |10.0 --- Comment #4 from David Malcolm --- I have a patch for this, queuing for gcc 10 stage 1.
[Bug c++/88512] Too much STL in error output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512 --- Comment #9 from Jonathan Wakely --- It's easy for you to say that after looking at the reason it failed and knowing what the code is trying to do (obviously "insert" modifies the string, so it can't be const). But the compiler has to try every overload, and doesn't know what your intention is, or what the word "insert" means. The problem here is (as before) that std::string has eight overloads of insert (and just as many for assign, and begin, and replace etc), and there's nothing the compiler can do about that. Potentially the compiler could be changed so that if all the overload candidates are non-const and the object is const, it just says that. But that's another fairly specialized diagnostic just for this case. Most classes simply don't have eight overloads of the same function.
[Bug middle-end/89371] New: missed vectorisation with "#pragma omp simd collapse(2)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89371
Bug ID: 89371
Summary: missed vectorisation with "#pragma omp simd
collapse(2)"
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: arnaud02 at users dot sourceforge.net
Target Milestone: ---
void ff(double* res, double const* a, double const* b, int ncell, int neq)
{
#pragma omp simd collapse(2)
for(int icell=0; icell < ncell; ++icell)
{
for(int ieq=0; ieq
[Bug c++/60920] Crash on double template header due to default template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60920 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #4 from Paolo Carlini --- Fixed by the patch which fixed c++/85264.
[Bug c++/88512] Too much STL in error output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512 --- Comment #10 from Jonathan Wakely --- I've created bug 89370 to request showing the type as std::string.
[Bug c++/84536] [7/8/9 Regression] ICE with non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84536
Paolo Carlini changed:
What|Removed |Added
Priority|P4 |P3
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-15
CC||paolo.carlini at oracle dot com
Ever confirmed|0 |1
--- Comment #1 from Paolo Carlini ---
I would argue for P3, because, if we slightly tweak it to:
template auto foo(N...); // -> void {}
void bar()
{
foo<>();
}
we don't emit any diagnostics before ICEing.
[Bug fortran/89077] ICE using * as len specifier for character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077 --- Comment #17 from Harald Anlauf --- (In reply to Harald Anlauf from comment #16) > Regarding the unwanted padding with \0, the following patch seems to > solve the issue with transfer. Regtested cleanly and submitted here: https://gcc.gnu.org/ml/fortran/2019-02/msg00126.html
[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #9 from Martin Sebor --- Let me put together a patch for the negative offsets. The argc patch is useful on its own, independent of this bug.
[Bug go/89368] [9 regression] ICE in go/gofrontend/expressions.cc:4669 after r268923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89368 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Lance Taylor --- Thanks for the report. Fixed.
[Bug c/89373] New: macro expansion not counting braces correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89373
Bug ID: 89373
Summary: macro expansion not counting braces correctly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mdblack98 at yahoo dot com
Target Milestone: ---
include
#define MYMACRO1(m) MYLIST;
#define MYMACRO(r,m) \
MYMACRO##r(m)
#define MYLIST {1,2,3,4,5}
// too many args -- does not allow for braces such as used for array
initialization
int ii[32] = MYMACRO(1,{1,2,3,4,5});
// too many args -- does not allow for braces such as used for array
initialization
int jj[32] = MYMACRO(1,MYLIST);
// this works
int kk[32] = MYLIST;
int
main()
{
// all 3 of these should print 1,2,3,4,5
for(int i=0;i<5;++i) printf("ii %d,%d\n",i,ii[i]);
for(int i=0;i<5;++i) printf("jj %d,%d\n",i,jj[i]);
for(int i=0;i<5;++i) printf("kk %d,%d\n",i,kk[i]);
return 0;
}
[Bug preprocessor/89373] macro expansion not counting braces correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89373
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|c |preprocessor
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski ---
In the C preprocessor without a '(' everything after the ',' is the next
argument.
