[Bug libfortran/83811] New: fortran 'e' format broken for single digit exponents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83811 Bug ID: 83811 Summary: fortran 'e' format broken for single digit exponents Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: alexander.heger at monash dot edu Target Milestone: --- ~/test>gfortran --version GNU Fortran (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2) 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. ~/test>cat test.f program test character*10 :: s write(s, '(1pe5.0e1)') 1.e-4 print*,s write(s, '(e5.1e1)') 1.e12 print*,s end ~/test>gfortran test.f ~/test>./a.out 1.E+0 .1E+2 This does not look right to me. It broke some time with version 7.1.x (Fedora 26 default) but remains broken in 7.2.1 (Fedora 27). Was still OK in Fedora 25. As a side note, if I replace the first 'e' by 'g' in each format string, the formatting works as expected 1.E-4 * -Alexander
[Bug target/83810] New: sh: s-scaval.adb:103:07: warning: "IV_Ilf" overlays smaller object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83810 Bug ID: 83810 Summary: sh: s-scaval.adb:103:07: warning: "IV_Ilf" overlays smaller object Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- Created attachment 43113 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43113&action=edit Makefile to build the cross GCC I tried to build an Ada compiler for sh-rtems5. I am not sure if it is worth to support Ada on this target. I use in mainly to test the compiler build. /home/sh/b-gcc-sh/./gcc/xgcc -B/home/sh/b-gcc-sh/./gcc/ -nostdinc -B/home/sh/b-gcc-sh/sh-rtems5/newlib/ -isystem /home/sh/b-gcc-sh/sh-rtems5/newlib/targ-include -isystem /home/sh/src/gcc/newlib/libc/include -B/home/sh/install/sh-rtems5/bin/ -B/home/sh/install/sh-rtems5/lib/ -isystem /home/sh/install/sh-rtems5/include -isystem /home/sh/install/sh-rtems5/sys-include-c -g -O2 -m4-single-only -W -Wall -gnatpg -nostdinc -m4-single-only s-scaval.adb -o s-scaval.o s-scaval.adb:103:07: warning: "IV_Ilf" overlays smaller object s-scaval.adb:103:07: warning: program execution may be erroneous s-scaval.adb:103:07: warning: size of "IV_Ilf" is 64 s-scaval.adb:103:07: warning: size of "IS_Ilf" is 32 s-scaval.adb:104:07: warning: "IV_Ill" overlays smaller object s-scaval.adb:104:07: warning: program execution may be erroneous s-scaval.adb:104:07: warning: size of "IV_Ill" is 96 s-scaval.adb:104:07: warning: size of "IS_Ill" is 64 The attached Makefile can be used to reproduce the build. make clone make native make install/bin/sh-rtems5-ld make install/bin/sh-rtems5-gcc
[Bug target/83809] New: epiphany: a-direct.ads:478:09: alignment for "Search_Typeb119s" must be at least 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83809 Bug ID: 83809 Summary: epiphany: a-direct.ads:478:09: alignment for "Search_Typeb119s" must be at least 8 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- Created attachment 43112 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43112&action=edit Makefile to build the cross GCC I tried to build an Ada compiler for epiphany-rtems5. I am not sure if it is worth to support Ada on this target. I use in mainly to test the compiler build. /home/sh/b-gcc-epiphany/./gcc/xgcc -B/home/sh/b-gcc-epiphany/./gcc/ -nostdinc -B/home/sh/b-gcc-epiphany/epiphany-rtems5/newlib/ -isystem /home/sh/b-gcc-epiphany/epiphany-rtems5/newlib/targ-include -isystem /home/sh/src/gcc/newlib/libc/include -B/home/sh/install/epiphany-rtems5/bin/ -B/home/sh/install/epiphany-rtems5/lib/ -isystem /home/sh/install/epiphany-rtems5/include -isystem /home/sh/install/epiphany-rtems5/sys-include-c -g -O2 -W -Wall -gnatpg -nostdinc a-direct.adb -o a-direct.o a-direct.ads:478:09: alignment for "Search_Typeb119s" must be at least 8 The attached Makefile can be used to reproduce the build. make clone make native make install/bin/epiphany-rtems5-ld make install/bin/epiphany-rtems5-gcc
[Bug regression/39508] gcc libdecnumber 4.3.4 & 4.3.3 x86_64 linux : /usr/bin/ld: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.4//libgcc.a(bid_decimal_globals.o): TLS transition from R_X86_64_TLSGD to R_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39508 Roel Van de Paar changed: What|Removed |Added CC||roel at vandepaar dot com --- Comment #5 from Roel Van de Paar --- Jason, thank you for your work on this here. Would you have a look at https://github.com/jdbirdwell/afl/issues/5 which looks to be the same issue, and it seems you may be able to contribute there. Thank you & God bless, Roel
[Bug bootstrap/81926] [7 regression] go/parse.o differs between stage2 and stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #40 from Rainer Orth --- Author: ro Date: Fri Jan 12 05:32:31 2018 New Revision: 256562 URL: https://gcc.gnu.org/viewcvs?rev=256562&root=gcc&view=rev Log: Avoid Solaris/SPARC comparison failures with Solaris as (PR bootstrap/81926) Backport from mainline 2018-01-04 Rainer Orth PR bootstrap/81926 * cgraphunit.c (symbol_table::compile): Switch to text_section before calling assembly_start debug hook. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/cgraphunit.c
[Bug libquadmath/83800] [libquadmath] M_SQRT2q & sqrtq(2.0Q) off by one ULP ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83800 --- Comment #2 from sisyphus1 at optusnet dot com.au --- The issue with sqrtq() is more widespread than I expected. Checking the square roots of the integer values from 2 to 300, I found that sqrtq differs from mpfr for 2, 6, 8, 13, 15, 19, 24, 30, 31, 32, 33, 37, 41, 43, 45, 52, 60, 66, 76, 83, 96, 97, 101, 102, 105, 114, 117, 120, 123, 124, 128, 130, 132, 133, 142, 148, 150, 153, 155, 163, 164, 172, 174, 177, 178, 179, 180, 182, 185, 187, 190, 191, 194, 203, 207, 208, 210, 213, 215, 223, 231, 235, 237, 240, 243, 246, 247, 249, 253, 258, 264, 265, 269, 274, 277, 294, and 297. In all cases it's a 1 ULP discrepancy - though I only checked that visually. I programmatically checked that the 2 values straddle the actual value, and that the value provided by mpfr is the closer approximation. I got identical results with both gcc-5.4.0 (on Ubuntu) and gcc-7.2.0 (on Windows). Cheers, Rob
[Bug c++/83778] [8 regression] g++.dg/ext/altivec-cell-2.C fails starting with r256448
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83778 --- Comment #3 from David Malcolm --- I still haven't been able to reproduce this; sorry.
[Bug c++/83779] Trivial bounds error not detected with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83779 --- Comment #5 from Walter Spector --- Thanks for mentioning that, Martin. A couple of us in the project I work on were reviewing the options we specify in our debug builds to try to smoke out problems. We already use options like -Wall, -Wextra and such for both g++ and gfortran. We also use -fbounds-check with gfortran. Just wondering if -fbounds-check would help find things on the c++ side. But seems it doesn't - as documented.
[Bug c/82922] Request: add -Wstrict-prototypes to -Wextra as K&R style is obsolescent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82922 --- Comment #4 from Martin Sebor --- Correction, the patch is here: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00935.html
[Bug c/82922] Request: add -Wstrict-prototypes to -Wextra as K&R style is obsolescent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82922 --- Comment #3 from Martin Sebor --- Incremental patch for the testsuite: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00962.html Unfortunately it sounds like it might be too late to enable the option in GCC 8.
[Bug preprocessor/83773] Warning for redefined macro does not have its own -Wsomething switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83773 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-11 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed.
[Bug c++/83799] [8 Regression] bogus "no matching function for call to" error when building llvm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83799 --- Comment #4 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00984.html
[Bug middle-end/79220] missing -Wstringop-overflow= on a memcpy overflow with a small power-of-2 size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79220 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=83508 --- Comment #4 from Martin Sebor --- In GCC 8.0 the overflow is diagnosed in both functions. In f() by -Wstringop-overflow as before, and in both functions (perhaps surprisingly) by the newly enhanced -Warray-bounds warning (r255755). There is still no -Wstringop-overflow for g() so the limitation hasn't really been removed yet and this bug should stay open until it is, and until the overflow in g() is diagnosed -Wstringop-overflow when -Warray-bounds is disabled. As an aside, the -Wstringop-overflow for f() will disappear if/when the patch submitted for bug 83508 is committed. pr79220.c: In function ‘g’: pr79220.c:12:3: warning: ‘memcpy’ forming offset [4, 8] is out of the bounds [0, 3] of object ‘d’ with type ‘char[3]’ [-Warray-bounds] memcpy (d, s, 8); ^~~~ pr79220.c:3:6: note: ‘d’ declared here char d[3]; ^ pr79220.c: In function ‘f’: pr79220.c:7:3: warning: ‘memcpy’ forming offset [4, 8] is out of the bounds [0, 3] of object ‘d’ with type ‘char[3]’ [-Warray-bounds] memcpy (d, "0123456789", 8); ^~~ pr79220.c:3:6: note: ‘d’ declared here char d[3]; ^ pr79220.c:7:3: warning: ‘memcpy’ writing 8 bytes into a region of size 3 overflows the destination [-Wstringop-overflow=] memcpy (d, "0123456789", 8); ^~~
[Bug c++/83779] Trivial bounds error not detected with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83779 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- Not sure if that will help you but with -O1 and above, the test case triggers a -Waggressive-loop-optimizations warning: warning: iteration 20 invokes undefined behavior [-Waggressive-loop-optimizations] array1[i] = i; ~~^~~ z.c:7:3: note: within this loop for (int i=0; i<25; i++) ^~~
[Bug c++/83797] Inconsistent error messages for main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83797 Martin Sebor changed: What|Removed |Added Keywords||diagnostic, easyhack Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-11 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |trivial --- Comment #1 from Martin Sebor --- Confirmed. Keywords should be quoted and main should be referred to consistently.
[Bug c++/83808] New: "internal compiler error" for invalid input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83808 Bug ID: 83808 Summary: "internal compiler error" for invalid input Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dibbex at gmail dot com Target Milestone: --- Created attachment 43111 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43111&action=edit Small test case The attached sample C++ program fails compilation with this error: $ /usr/lib/gcc-snapshot/bin/g++ -std=c++17 -c broken.cc broken.cc: In function 'void f()': broken.cc:9:3: internal compiler error: in process_init_constructor_array, at cp/typeck2.c:1318 }; ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. If I've understood the standard correctly, the expression used as the size of the array should be a constexpr, and the compiler should complain about it. Asking the user to file a bug report instead of fixing their code is the wrong response. $ /usr/lib/gcc-snapshot/bin/g++ -v Using built-in specs. COLLECT_GCC=/usr/lib/gcc-snapshot/bin/g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20180107-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix= --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.0.0 20180107 (experimental) [trunk revision 256322] (Debian 20180107-1) I know that this comes from a Debian release, but the code is 100% the same (the code itself is not patched). I've found the same error in version 7.2.0. Version 6.4.0 instead accepts the code without complaining.
[Bug target/83203] [8 Regression] Inefficient int to avx2 vector conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83203 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed. You really need -mtune=intel or similar if you want a vmovq, because the inter-unit moves are very costly on AMD.
[Bug middle-end/83653] [6/7/8 Regression] GCC fails to remove a can't-happen call on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83653 --- Comment #15 from Jakub Jelinek --- (In reply to Matthew Wilcox from comment #14) > Confirmed this fixes the problem. I'll send it to Tony and see if he likes > it. May I add your Signed-off-by to the patch? Sure. Feel free to reformat it as the kernel wants, it has been almost 20 years since I've been active in the kernel, so don't know the formatting rules anymore.
[Bug middle-end/83653] [6/7/8 Regression] GCC fails to remove a can't-happen call on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83653 --- Comment #14 from Matthew Wilcox --- Confirmed this fixes the problem. I'll send it to Tony and see if he likes it. May I add your Signed-off-by to the patch?
[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- As I said earlier, the patch is IMHO wrong and instead ARM/AArch64 should implement efficient mempcpy in the library. If not, we should have a target hook whether the target has sane mempcpy or not and use it at least for cases like this, where using it will allow tail-calling it, while using memcpy precludes that. And then XFAIL the test on targets with bad mempcpy implementation.
[Bug fortran/83803] Using -fc-prototypes on modules with empty dummy arg lists does not close paren.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83803 --- Comment #3 from emsr at gcc dot gnu.org --- Created attachment 43110 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43110&action=edit patchlet (untested)
[Bug target/83735] [8 Regression] generating unaligned store to stack with vmovaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from H.J. Lu --- Fixed.
[Bug middle-end/83653] [6/7/8 Regression] GCC fails to remove a can't-happen call on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83653
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #13 from Jakub Jelinek ---
What about this approach, force __builtin_constant_p to evaluate in the FE
before optimizations and decide just on that. Will work with constant literals
passed to the macro, will do the fallback if you say use it in inline and hope
that if the inline is called with a constant it will propagate:
struct V { int counter; };
int ia64_fetch_and_add(int, int *);
int ia64_atomic_sub(int, struct V *);
#ifdef __OPTIMIZE__
#define atomic_sub_return_1(i,v,c) \
({ \
int __ia64_asr_i = (i); \
static const int __ia64_asr_p_##c \
= __builtin_constant_p(i) \
? ((i) == 1 || (i) == 4 || (i) == 8 || (i) == 16\
|| (i) == -1 || (i) == -4 || (i) == -8 || (i) == -16)\
: 0;\
__ia64_asr_p_##c\
? ia64_fetch_and_add(-__ia64_asr_i, &(v)->counter)\
: ia64_atomic_sub(__ia64_asr_i, v); \
})
#define atomic_sub_return_2(i,v,c) atomic_sub_return_1(i,v,c)
#define atomic_sub_return(i,v) atomic_sub_return_2(i,v,__COUNTER__)
#else
#define atomic_sub_return(i,v) ia64_atomic_sub(i,v)
#endif
void
foo (struct V *p, int i)
{
atomic_sub_return (4, p);
atomic_sub_return (8, p);
atomic_sub_return (16, p);
atomic_sub_return (7, p);
atomic_sub_return (i, p);
}
[Bug fortran/29651] Subroutine: Kind convertion of intent(out) value: signal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29651 --- Comment #12 from Harald Anlauf --- (In reply to Jerry DeLisle from comment #9) > An easy fix to this would be to disallow kind=2 integer as an argument > during checking. Since SIGNAL is a GNU extension, we are at liberty what to allow. What is definitely needed is a kind=8 version of status for 64-bit platforms. From the manpage signal(2): SYNOPSIS #include typedef void (*sighandler_t)(int); sighandler_t signal(int signum, sighandler_t handler); A modified version of the code in comment#1, implicit none integer :: i1,i2 integer(4) :: status4, proc4 integer(8) :: status8, proc8 i1 = 0; i2 = 0 call signal(i1, proc4, status4) print *,status4 call signal(i2, proc8, status8) print *,status8 end produces the dump excerpt: integer(kind=4) D.3682; integer(kind=4) D.3683; D.3682 = (integer(kind=4)) proc8; D.3683 = (integer(kind=4)) status8; _gfortran_signal_sub_int (&i2, &D.3682, &D.3683); If one wants to save the old signal handler, proc and status of type integer(c_intptr_t) need to be supported. One may even require that they have the same kind value, as different values do not make much sense. Looking at libgfortran/intrinsics/signal.c, I think the appropriate support from the library side is trivial. However, I think that the argument status from the existing functions signal_sub and signal_sub_int need to be changed from int* to GFC_INTEGER_4* for the existing version, and GFC_INTEGER_8* for the other version to be added. If there is consensus on such restrictions, I could try to work on a trivial patch for supporting the above.
[Bug target/83203] [8 Regression] Inefficient int to avx2 vector conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83203
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Thu Jan 11 20:49:40 2018
New Revision: 256556
URL: https://gcc.gnu.org/viewcvs?rev=256556&root=gcc&view=rev
Log:
PR target/83203
* config/i386/i386.c (ix86_expand_vector_init_one_nonzero): If one_var
is 0, for V{8,16}S[IF] and V[48]D[IF]mode use gen_vec_set_0.
* config/i386/sse.md (VI8_AVX_AVX512F, VI4F_256_512): New mode
iterators.
(ssescalarmodesuffix): Add 512-bit vectors. Use "d" or "q" for
integral modes instead of "ss" and "sd".
(vec_set_0): New define_insns for 256-bit and 512-bit
vectors with 32-bit and 64-bit elements.
(vecdupssescalarmodesuffix): New mode attribute.
(vec_dup): Use it.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sse.md
[Bug target/83330] [7/8 Regression] generating unaligned store to stack for SSE register with -mno-push-args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83330 --- Comment #7 from hjl at gcc dot gnu.org --- Author: hjl Date: Thu Jan 11 20:44:46 2018 New Revision: 256555 URL: https://gcc.gnu.org/viewcvs?rev=256555&root=gcc&view=rev Log: i386: Align stack frame if argument is passed on stack When a function call is removed, it may become a leaf function. But if argument may be passed on stack, we need to align the stack frame when there is no tail call. Tested on Linux/i686 and Linux/x86-64. gcc/ PR target/83330 * config/i386/i386.c (ix86_compute_frame_layout): Align stack frame if argument is passed on stack. gcc/testsuite/ PR target/83330 * gcc.target/i386/pr83330.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr83330.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/83653] [6/7/8 Regression] GCC fails to remove a can't-happen call on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83653 --- Comment #12 from Aldy Hernandez --- (In reply to Matthew Wilcox from comment #9) > Maybe I'm a little slow, but I don't see what the path is that sets 'nr' to > 0. It's 1UL << compound_order. Typically, compound_order is 0, although it > may be anything up to log2(number of pages in the machine). Are you saying Sorry, yes 1<<0 will be 1, which is handled. Let me dig into the threading.
[Bug middle-end/83653] [6/7/8 Regression] GCC fails to remove a can't-happen call on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83653 --- Comment #11 from Matthew Wilcox --- I'm sorry, I still don't get it. What I think you're saying is that GCC performs this optimisation: nr = 1UL << compound_order(page); atomic_sub_return(x, nr); into: if (PageHead(page)) atomic_sub_return(x, 1); else atomic_sub_return(x, 1UL << page[1].order) That seems like a great optimisation to me, and I'm all for it. What I don't understand is where the b_c_p call gets lost. Also, this bug is pretty fragile. If I replace the 'nr' in the call to atomic_sub_return with '1UL << compound_order(page)', the bug goes away. Anyway, I have no vested interest in ia64 or the code that's currently using __b_c_p. I just want it to stop blocking me getting my patch in. It's a bit different from 72785 because I can't just resolve it by removing the checking code. Just tell me what the macro should look like.
[Bug fortran/79383] USE statement error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79383 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |8.0 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to Walt Brainerd from comment #3) > Yes, Sounds like you have it fixed. Thanks. > Walt, thanks for the bug report and confirmation that the output I got was expected. I've converted your code into 2 testcases, so hopefully the problem never returns.
[Bug fortran/79383] USE statement error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79383 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Thu Jan 11 20:24:36 2018 New Revision: 256554 URL: https://gcc.gnu.org/viewcvs?rev=256554&root=gcc&view=rev Log: 2018-01-11 Steven G. Kargl PR fortran/79383 * gfortran.dg/dtio_31.f03: New test. * gfortran.dg/dtio_32.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/dtio_31.f03 trunk/gcc/testsuite/gfortran.dg/dtio_32.f03 Modified: trunk/gcc/testsuite/ChangeLog
[Bug go/83794] misc/cgo/test uses gigabytes of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83794 Ian Lance Taylor changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Ian Lance Taylor --- Thanks for investigating. I fixed the problem you found in TestBuildID. The logs generated by t.Logf are saved until the test is complete, because tests can run in parallel and interleaved logs are hard to read. So 1) that explains why you didn't see any of the logs; 2) it explains why the program allocated memory very quickly and without bound. Let me know if you still see a problem with `make check-gotools` after that patch. I don't know if there is anything else going on.
[Bug go/83794] misc/cgo/test uses gigabytes of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83794 --- Comment #3 from ian at gcc dot gnu.org --- Author: ian Date: Thu Jan 11 19:58:55 2018 New Revision: 256553 URL: https://gcc.gnu.org/viewcvs?rev=256553&root=gcc&view=rev Log: PR go/83794 misc/cgo/test: avoid endless loop when we can't parse notes Reviewed-on: https://go-review.googlesource.com/87416 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/misc/cgo/test/buildid_linux.go
[Bug target/82682] [8 Regression] FAIL: gcc.target/i386/pr50038.c scan-assembler-times movzbl 2 (found 3 times) since r253958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82682 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jeffrey A. Law --- Fixed by Jakub's patch on the trunk.
[Bug c++/83799] [8 Regression] bogus "no matching function for call to" error when building llvm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83799 --- Comment #3 from David Malcolm --- Created attachment 43109 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43109&action=edit Reduced test case for the first error Here's a reduced version of the first error seen in the original attachment (am keeping the other one around for now, in case there are multiple issues here). Am investigating.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #8 from Jan Kratochvil --- (In reply to Jakub Jelinek from comment #7) > Thanks. Is that something that can be fixed in GDB easily? Expecting a significant performance hit on initial scan of a file when .gdb_index/.debug_names is not present there. But personally I do not think that matters as such scanning without any index was always very slow, that is what the index is there for. I am leaving the fix and/or assignment of the fix up to Pedro.
[Bug middle-end/83653] [6/7/8 Regression] GCC fails to remove a can't-happen call on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83653 Jeffrey A. Law changed: What|Removed |Added Status|WAITING |RESOLVED CC||law at redhat dot com See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=72785 Resolution|--- |INVALID --- Comment #10 from Jeffrey A. Law --- So look for something similar to this: [local count: 96151367]: # i_280 = PHI <0(28), 0(30)> if (i_280 < nr_300) goto ; [92.50%] else goto ; [7.50%] The subscripts may change, but I think that's what you're looking for. i_280 will be replaced with zero resulting in if (0 < nr_300) true else false And because nr is unsigned that will turn into an equality comparison if (nr_300 != 0) true else false At that point the compiler knows that nr_300 has the value 0 on the false arm of the conditional. Anyway, this isn't a GCC bug. I'll note that it may be worth reviewing pr72785 which is essentially the same issue with misunderstanding how builtin_constant_p works.
[Bug c++/43486] Preserve variable-use locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486 --- Comment #13 from David Malcolm --- Author: dmalcolm Date: Thu Jan 11 19:38:52 2018 New Revision: 256552 URL: https://gcc.gnu.org/viewcvs?rev=256552&root=gcc&view=rev Log: Add some reproducers for issues found developing the location-wrappers patch gcc/testsuite/ChangeLog: PR c++/43486 * g++.dg/wrappers: New subdirectory. * g++.dg/wrappers/README: New file. * g++.dg/wrappers/alloc.C: New test case. * g++.dg/wrappers/cow-istream-string.C: New test case. * g++.dg/wrappers/cp-stdlib.C: New test case. * g++.dg/wrappers/sanitizer_coverage_libcdep_new.C: New test case. * g++.dg/wrappers/wrapper-around-type-pack-expansion.C: New test case. Added: trunk/gcc/testsuite/g++.dg/wrappers/ trunk/gcc/testsuite/g++.dg/wrappers/README trunk/gcc/testsuite/g++.dg/wrappers/alloc.C trunk/gcc/testsuite/g++.dg/wrappers/cow-istream-string.C trunk/gcc/testsuite/g++.dg/wrappers/cp-stdlib.C trunk/gcc/testsuite/g++.dg/wrappers/sanitizer_coverage_libcdep_new.C trunk/gcc/testsuite/g++.dg/wrappers/wrapper-around-type-pack-expansion.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/82682] [8 Regression] FAIL: gcc.target/i386/pr50038.c scan-assembler-times movzbl 2 (found 3 times) since r253958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82682 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Thu Jan 11 19:34:56 2018 New Revision: 256551 URL: https://gcc.gnu.org/viewcvs?rev=256551&root=gcc&view=rev Log: PR target/82682 * ree.c (combine_reaching_defs): Optimize also reg2=exp; reg1=reg2; reg2=any_extend(reg1); into reg2=any_extend(exp); reg1=reg2;, formatting fix. Modified: trunk/gcc/ChangeLog trunk/gcc/ree.c
[Bug middle-end/83653] [6/7/8 Regression] GCC fails to remove a can't-happen call on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83653 --- Comment #9 from Matthew Wilcox --- Maybe I'm a little slow, but I don't see what the path is that sets 'nr' to 0. It's 1UL << compound_order. Typically, compound_order is 0, although it may be anything up to log2(number of pages in the machine). Are you saying that nr could be 0 because DOM2 thinks compound_order() could be larger than 64, and thus undefined?
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #7 from Jakub Jelinek --- Thanks. Is that something that can be fixed in GDB easily? I mean, for -freorder-blocks-and-partition optimized main we can't pretend it is a single range when it is not.
[Bug middle-end/83653] [6/7/8 Regression] GCC fails to remove a can't-happen call on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83653
--- Comment #8 from Aldy Hernandez ---
Ah, I see what the problem is.
unsigned long i, nr = 1UL << compound_order(page);
...
page_ref_sub(page, nr); // calls __builtin_constant_p(nr) eventually
The problem is that there is a path to __builtin_constant_p(nr) for which NR is
0, and thus a constant. This is because compound_order() is defined as:
static inline unsigned int compound_order(struct page *page)
{
if (!PageHead(page))
return 0;
return page[1].compound_order;
}
The dom2 threading pass is isolating the path returning 0, and realizing that
that particular path is a constant. Your series of if's does not handle 0, and
you get the __bad_increment_for_ia64_fetch_and_add exposed.
Don't blame me, I'm just the messenger :).
Perhaps Richi has a suggestion on how to code your macro.
If, as Richard says, this is a known quirk, perhaps we should document it in
the section for __builtin_constant_p() in the manual, along with a suggestion
on how to code an alternative.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #6 from Jan Kratochvil --- (In reply to Jakub Jelinek from comment #5) > where gdb sees the difference and why doesn't it make the file > containing main the default? pr43051-1.exe.good <1><117>: Abbrev Number: 3 (DW_TAG_subprogram) <118> DW_AT_abstract_origin: <0x69> <11c> DW_AT_low_pc : 0x400410 <124> DW_AT_high_pc : 0x3d ... pr43051-1.exe.bad <1><117>: Abbrev Number: 3 (DW_TAG_subprogram) <118> DW_AT_abstract_origin: <0x69> <11c> DW_AT_ranges : 0x0 ... GDB read_partial_die() does support DW_AT_low_pc+DW_AT_high_pc but not DW_AT_ranges. Therefore for pr43051-1.exe.bad GDB considers it only as a declaration of main() and not its definition, not worth expanding its CU.
[Bug c++/83690] [8 regression] spurious unused variable warings for variables used only in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83690 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed.
[Bug c++/82728] [8 regression] Incorrect -Wunused-but-set-variable warning with a const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82728 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/83690] [8 regression] spurious unused variable warings for variables used only in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83690 --- Comment #3 from Jason Merrill --- Author: jason Date: Thu Jan 11 19:08:41 2018 New Revision: 256550 URL: https://gcc.gnu.org/viewcvs?rev=256550&root=gcc&view=rev Log: PR c++/82728 - wrong -Wunused-but-set-variable PR c++/82799 PR c++/83690 * call.c (perform_implicit_conversion_flags): Call mark_rvalue_use. * decl.c (case_conversion): Likewise. * semantics.c (finish_static_assert): Call perform_implicit_conversion_flags. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch2.C trunk/gcc/testsuite/g++.dg/warn/Wunused-var-27.C trunk/gcc/testsuite/g++.dg/warn/Wunused-var-28.C trunk/gcc/testsuite/g++.dg/warn/Wunused-var-29.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/decl.c trunk/gcc/cp/semantics.c
[Bug c++/82799] [8 Regression] -Wunused-but-set-variable false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82799 --- Comment #4 from Jason Merrill --- Author: jason Date: Thu Jan 11 19:08:41 2018 New Revision: 256550 URL: https://gcc.gnu.org/viewcvs?rev=256550&root=gcc&view=rev Log: PR c++/82728 - wrong -Wunused-but-set-variable PR c++/82799 PR c++/83690 * call.c (perform_implicit_conversion_flags): Call mark_rvalue_use. * decl.c (case_conversion): Likewise. * semantics.c (finish_static_assert): Call perform_implicit_conversion_flags. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch2.C trunk/gcc/testsuite/g++.dg/warn/Wunused-var-27.C trunk/gcc/testsuite/g++.dg/warn/Wunused-var-28.C trunk/gcc/testsuite/g++.dg/warn/Wunused-var-29.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/decl.c trunk/gcc/cp/semantics.c
[Bug c++/82728] [8 regression] Incorrect -Wunused-but-set-variable warning with a const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82728 --- Comment #4 from Jason Merrill --- Author: jason Date: Thu Jan 11 19:08:41 2018 New Revision: 256550 URL: https://gcc.gnu.org/viewcvs?rev=256550&root=gcc&view=rev Log: PR c++/82728 - wrong -Wunused-but-set-variable PR c++/82799 PR c++/83690 * call.c (perform_implicit_conversion_flags): Call mark_rvalue_use. * decl.c (case_conversion): Likewise. * semantics.c (finish_static_assert): Call perform_implicit_conversion_flags. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch2.C trunk/gcc/testsuite/g++.dg/warn/Wunused-var-27.C trunk/gcc/testsuite/g++.dg/warn/Wunused-var-28.C trunk/gcc/testsuite/g++.dg/warn/Wunused-var-29.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/decl.c trunk/gcc/cp/semantics.c
[Bug c++/83806] New: Spurious unused-but-set-parameter with nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83806
Bug ID: 83806
Summary: Spurious unused-but-set-parameter with nullptr
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
This program:
template
bool equals(X x, Y y) {
return (x == y);
}
int main() {
const char* p = nullptr;
equals(p, nullptr);
}
When compiled as:
$ g++ -std=c++1z -Wunused-but-set-parameter bad.cxx
bad.cxx: In instantiation of ‘bool equals(X, Y) [with X = const char*; Y =
std::nullptr_t]’:
bad.cxx:8:22: required from here
bad.cxx:2:20: warning: parameter ‘y’ set but not used
[-Wunused-but-set-parameter]
bool equals(X x, Y y) {
^
But y is used, in a meaningful sense.
[Bug c/83801] [8 Regression][avr] String constant in __flash not put into .progmem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83801 --- Comment #6 from gandalf at winds dot org --- (In reply to Georg-Johann Lay from comment #1) > Old v7.2 does it correctly: one string in flash, one in RAM. My more specific testcase (comment #3 in PR83729) references a 32-byte string in a function that is only called once in my program, in a slow code path (e.g. initialization). I understand there is a slowdown incurred by LPM instructions when using __flash, hence the compiler may want to optimize this condition. But since RAM is more limited than Flash on AVR (and I know my use of memory vs. large strings), I specifically use __flash to specify I want certain strings like this one located in flash memory instead of RAM. Is that not the purpose of __flash? Why would the compiler duplicate this string in RAM? What if my string happened to be larger than the total RAM available?
[Bug ipa/83532] [8 Regression] ICE in apply_scale, at profile-count.h:955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83532 Jan Hubicka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jan Hubicka --- Fixed by patch for PR83718
[Bug middle-end/83718] [8 Regression] ICE: Floating point exception in profile_count::apply_scale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83718 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jan Hubicka --- Fixed.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155
Jakub Jelinek changed:
What|Removed |Added
CC||jan.kratochvil at redhat dot
com,
||palves at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
So, I guess we need help on how does gdb determine the initial file when
loading a program (i.e. when you run gdb ./program , when you get prompt, what
file is l showing or b putting breakpoint in).
With the new LTO debug info, we have
.file ""
with both -f{,no-}reorder-blocks-and-partition.
The CU that imports the unit with main has:
.long .LASF1 # DW_AT_name: ""
.long .LASF2 # DW_AT_comp_dir: "/usr/src/gcc/obj/gcc"
too. Pedro/Jan, could you try this (I can provide binaries off-line) and say
where gdb sees the difference and why doesn't it make the file containing main
the default?
[Bug target/83785] sh: ICE in maybe_record_trace_start, at dwarf2cfi.c:2344
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83785 --- Comment #1 from joseph at codesourcery dot com --- I suspect this has the same cause as bug 78459, bug 80863 and bug 83760, all of which involve ICEs in maybe_record_trace_start for SH and the first two of which mysteriously went away (but the bugs are still open), probably as a result of something being perturbed by other changes rather than an actual fix.
[Bug tree-optimization/83189] [8 regression] internal compiler error: in probability_in, at profile-count.h:1050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83189 --- Comment #9 from Jan Hubicka --- Author: hubicka Date: Thu Jan 11 17:47:20 2018 New Revision: 256545 URL: https://gcc.gnu.org/viewcvs?rev=256545&root=gcc&view=rev Log: PR middle-end/83189 * gimple-ssa-isolate-paths.c (isolate_path): Fix profile update. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-isolate-paths.c
[Bug middle-end/83718] [8 Regression] ICE: Floating point exception in profile_count::apply_scale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83718 --- Comment #5 from Jan Hubicka --- Author: hubicka Date: Thu Jan 11 17:46:01 2018 New Revision: 256544 URL: https://gcc.gnu.org/viewcvs?rev=256544&root=gcc&view=rev Log: PR middle-end/83718 * tree-inline.c (copy_cfg_body): Adjust num&den for scaling after they are computed. * g++.dg/torture/pr83718.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr83718.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c
[Bug c/83801] [8 Regression][avr] String constant in __flash not put into .progmem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83801 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- I never said there is a bug in the C FE, I think the testcases just make invalid assumptions. In any case, the change that matters here is likely my r254930 or r255285, and one could do something like add say: && (ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (TREE_TYPE (decl))) || !AGGREGATE_TYPE_P (TREE_TYPE (decl))) to decl_constant_value_1 conditions to prevent it from looking at aggregate initializers in non-generic address spaces. Perhaps there should be also some cap on the size of decl that is optimized regardless of the address space, e.g. 7.x and earlier had: || TREE_CODE (TREE_TYPE (exp)) == ARRAY_TYPE || DECL_MODE (exp) == BLKmode) condition to punt. Now, sometimes it is beneficial to have even BLKmode or array decls to go through, say if we have str[5], similarly const_var.field,then not punting on those will allow it to be optimized into constant, while 7.x couldn't. But, with something large and non-constant access it might actually regress (duplicate the constant).
[Bug tree-optimization/35513] Improve targetm.binds_local_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35513 H.J. Lu changed: What|Removed |Added CC||rafael.espindola at gmail dot com --- Comment #4 from H.J. Lu --- *** Bug 83782 has been marked as a duplicate of this bug. ***
[Bug target/83782] Inconsistent address for hidden ifunc in a shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83782 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 35513 ***
[Bug tree-optimization/35513] Improve targetm.binds_local_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35513 --- Comment #3 from H.J. Lu --- Hidden ifunc address has the similar issue, see the testcase in PR 83782. If targetm.binds_local_p needs to know if the symbol is used for read, write or branch, so that all function pointers, including hidden ones, are treated as as global, when -fPIC is used.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
As
make check-gcc
RUNTESTFLAGS='--target_board=unix\{-fno-reorder-blocks-and-partition,-freorder-blocks-and-partition\}
guality.exp=pr43051-1.c'
shows, it is a -freorder-blocks-and-partition related, but it actually isn't
about missing debug info for those vars, it is all there.
gdb ./pr43051-1.exe
(gdb) b pr43051-1.c:34
Breakpoint 2 at 0x4005ff: file
/usr/src/gcc/gcc/testsuite/gcc.dg/guality/pr43051-1.c, line 34.
(gdb) r
Starting program: /usr/src/gcc/obj/gcc/pr43051-1.exe
Breakpoint 2, bar (c=0x601060 , v=1, e=0x601070 ) at
/usr/src/gcc/gcc/testsuite/gcc.dg/guality/pr43051-1.c:34
34foo ("c", (__UINTPTR_TYPE__) c, 0); /* { dg-final {
gdb-test 34 "c" "\&a\[0\]" } } */
(gdb) p c
$1 = (struct S *) 0x601060
(gdb) n
35foo ("v", v, 1); /* { dg-final {
gdb-test 35 "v" "1" } } */
(gdb) p v
$2 = 1
(gdb) n
36foo ("e", (__UINTPTR_TYPE__) e, 2); /* { dg-final {
gdb-test 36 "e" "\&a\[1\]" } } */
(gdb) p e
$3 = (struct S *) 0x601070
(gdb) b 39
Breakpoint 3 at 0x4005c0: file
/usr/src/gcc/gcc/testsuite/gcc.dg/guality/pr43051-1.c, line 39.
(gdb) c
Continuing.
Breakpoint 3, bar (c=0x601060 , v=1, e=0x601070 ) at
/usr/src/gcc/gcc/testsuite/gcc.dg/guality/pr43051-1.c:39
39foo ("c", (__UINTPTR_TYPE__) c, 3); /* { dg-final {
gdb-test 39 "c" "\&a\[0\]" } } */
(gdb) p c
$4 = (struct S *) 0x601060
(gdb) n
40foo ("v", v, 4); /* { dg-final {
gdb-test 40 "v" "1" } } */
(gdb) p v
$5 = 1
(gdb) n
41foo ("e", (__UINTPTR_TYPE__) e, 5); /* { dg-final {
gdb-test 41 "e" "\&a\[1\]" } } */
(gdb) p e
$6 = (struct S *) 0x601070
The reason it fails is different, in the logs there is:
spawn gdb -nx -nw -quiet -batch -x pr43051-1.gdb ./pr43051-1.exe
No line 34 in the current file.
Make breakpoint pending on future shared library load? (y or [n]) [answered N;
input not from terminal]
and indeed that is what one can see:
gdba ./pr43051-1.exe
(gdb) l
1 : No such file or directory.
(gdb) b 34
No line 34 in the current file.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (34) pending.
So, either gdb 8.0.1-33.fc27 is too old to handle the LTO debug info, or there
is something wrong in it.
[Bug c/83801] [8 Regression][avr] String constant in __flash not put into .progmem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83801 --- Comment #4 from Georg-Johann Lay --- *** Bug 83805 has been marked as a duplicate of this bug. ***
[Bug c/83805] [8 Regression] Wrong constant merging for objects in different address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83805 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Component|middle-end |c Resolution|--- |DUPLICATE --- Comment #11 from Georg-Johann Lay --- According to Jakub, a C FE bug (STRING_CST is used with non-generic address space). *** This bug has been marked as a duplicate of bug 83801 ***
[Bug c/83801] [8 Regression][avr] String constant in __flash not put into .progmem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83801 Georg-Johann Lay changed: What|Removed |Added Keywords||addr-space Component|target |c --- Comment #3 from Georg-Johann Lay --- According to Jelinek, STRING_CST must always be in the default AS: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83805#c9 Hence this is a C front-end bug: STRING_CST must not be used for AS stuff, and the C FE must use a VAR_DECL in this case like v7 did.
[Bug middle-end/83805] [8 Regression] Wrong constant merging for objects in different address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83805
--- Comment #10 from Georg-Johann Lay ---
(In reply to Jakub Jelinek from comment #9)
> I don't see any bug actually. You are just saying that the str1 variable is
> __flash, during optimization (already in C FE) it optimizes str1[i] into
> "0123456789"[i] and that is the string literal that is mergeable, string
> literals unlike variables don't really have non-default address spaces.
Well, it's access as if it was located in an address space (namely using LPM
which is only used if the accessing code is accessing AS). The object sections
and accessor code must macht, otherwise it's wrong code.
If STRING_CST must not reside in AS (I already wondered that non-DECLs are in
AS) then my proposed fix to PR83801 is wrong: In that PR, a STRING_CST is
passed to TARGET_ASM_SELECT_SECTION, and it's TREE_TYP has some AS set. The
patch puts the STRING_CST in some AS-related section, and if that's wrong then
it's abut in the C front because the code is accessing an AS object.
IIUC you are saying that my fix to PR83801 is wrong and that the C FE should
never use a STRING_CST but should use a VAR_DECL (like v7 and prior did).
> If you want to prevent that, either make the var const volatile, or use some
> optimization barrier, like:
> static const __flash char str1[] = "0123456789";
> const char *ptr;
> __asm ("" : "=r" (ptr) : "0" (str1));
> return ptr[i];
Really, I have to control over code in user space, and the code supplied in the
test case is valid.
And the code you are showing makes really on sense...
[Bug c++/83798] Enhancement to Wmain warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83798 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-11 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to denis.campredon from comment #0) > In the first three warnings, just '::main' should be displayed, like when > compiled with gcc, instead of the full signature. What do you mean "when compiled with gcc"? The C front-end doesn't print "::main" because there is no :: scope resolution operator in C, and for C++ there's no difference in diagnostics whether you invoke gcc or g++. Do you just mean like the cases in PR 83797?
[Bug middle-end/83805] [8 Regression] Wrong constant merging for objects in different address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83805
--- Comment #9 from Jakub Jelinek ---
I don't see any bug actually. You are just saying that the str1 variable is
__flash, during optimization (already in C FE) it optimizes str1[i] into
"0123456789"[i] and that is the string literal that is mergeable, string
literals unlike variables don't really have non-default address spaces.
If you want to prevent that, either make the var const volatile, or use some
optimization barrier, like:
static const __flash char str1[] = "0123456789";
const char *ptr;
__asm ("" : "=r" (ptr) : "0" (str1));
return ptr[i];
or similar.
[Bug ipa/60871] [4.9 Regression] internal compiler error: in possible_polymorphic_call_targets, at ipa-devirt.c:1510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60871 --- Comment #22 from Neil Kindlon --- I am so sorry. Please disregard my earlier comments. It seems I hadn't exported the path variables to the correct correct compiler. When actually compiled with 7.1.0, there is no problem. My apologies.
[Bug middle-end/83805] [8 Regression] Wrong constant merging for objects in different address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83805 --- Comment #8 from Georg-Johann Lay --- (In reply to Jakub Jelinek from comment #7) > Well, you have 3 objects, str1, str2 and the string literal, if the compiler > thinks all 3 are needed, it emits all of them. Without > -fmerge-all-constants str1 can't be merged with str2 nor with any other > object. Whatever you call it -- .LC0 is shared between fun1 and fun2 and the result is wrong code. This even happens with -fno-merge-constants -fno-merge-all-constants.
[Bug middle-end/83805] [8 Regression] Wrong constant merging for objects in different address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83805 --- Comment #7 from Jakub Jelinek --- Well, you have 3 objects, str1, str2 and the string literal, if the compiler thinks all 3 are needed, it emits all of them. Without -fmerge-all-constants str1 can't be merged with str2 nor with any other object.
[Bug middle-end/83805] [8 Regression] Wrong constant merging for objects in different address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83805 --- Comment #6 from Georg-Johann Lay --- (In reply to Jakub Jelinek from comment #1) > If so, avr should override the select_section and unique_section target > hooks and return something different for the __flash strings. Also tried TARGET_ASM_UNIQUE_SECTION (again atop the patch for PR83801): Doesn't solve the problem. With -fdata-sections, I can change one of the section names, namely str2 (which already was correctly put into .rodata). But .LC0 is still shared between fun1 and fun2. TARGET_ASM_UNIQUE_SECTION is called 2 times: For the 2 VAR_DECLs str1 and str2, but not for STRING_CST .LC0.
[Bug tree-optimization/83776] [6/7/8 Regression] missing -Warray-bounds indexing past the end of a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83776 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- I'm testing a patch for this bug.
[Bug rtl-optimization/83770] [8 Regression] ICE in create_preheader, at cfgloopmanip.c:1536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83770 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-11 CC||abel at gcc dot gnu.org, ||amonakov at gcc dot gnu.org, ||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r250360.
[Bug middle-end/83805] [8 Regression] Wrong constant merging for objects in different address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83805 --- Comment #5 from Georg-Johann Lay --- (In reply to Jakub Jelinek from comment #4) > Well, 7.2 certainly doesn't have any special casing for address spaces in > categorize_decl_for_section etc., so before claiming it is a regression > you'd better bisect what change actually changed it. avr already implemented TARGET_ASM_SELECT_SECTION (it just didn't handle STRING_CSTs) so that default_elf_select_section is not used -- and thereby dito for the logic in categorize_decl_for_section. Or more precisely, it's only used for non-address-space cases in avr_asm_select_section.
[Bug tree-optimization/83695] [8 Regression] ICE on valid code at -O3: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83695 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #7 from Jeffrey A. Law --- Fixed by Bin's change on the trunk.
[Bug ipa/83178] [8 regression] g++.dg/ipa/devirt-22.C fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83178 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #9 from Jeffrey A. Law --- Fixed by Martin's patch on the trunk.
[Bug ipa/83178] [8 regression] g++.dg/ipa/devirt-22.C fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83178 --- Comment #8 from Jeffrey A. Law --- Author: law Date: Thu Jan 11 15:56:07 2018 New Revision: 256542 URL: https://gcc.gnu.org/viewcvs?rev=256542&root=gcc&view=rev Log: PR ipa/83178 * g++.dg/ipa/devirt-22.C: Adjust scan-dump-times count. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ipa/devirt-22.C
[Bug go/83787] [8 regression] Many 32-bit Solaris/SPARC Go tests FAIL after Go1.10beta1 update
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83787 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug middle-end/83805] [8 Regression] Wrong constant merging for objects in different address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83805 --- Comment #4 from Jakub Jelinek --- Well, 7.2 certainly doesn't have any special casing for address spaces in categorize_decl_for_section etc., so before claiming it is a regression you'd better bisect what change actually changed it.
[Bug tree-optimization/83695] [8 Regression] ICE on valid code at -O3: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83695 --- Comment #6 from amker at gcc dot gnu.org --- Author: amker Date: Thu Jan 11 15:41:41 2018 New Revision: 256541 URL: https://gcc.gnu.org/viewcvs?rev=256541&root=gcc&view=rev Log: PR tree-optimization/83695 * gimple-loop-linterchange.cc (tree_loop_interchange::interchange_loops): Call scev_reset_htab to reset cached scev information after interchange. (pass_linterchange::execute): Remove call to scev_reset_htab. gcc/testsuite PR tree-optimization/83695 * gcc.dg/tree-ssa/pr83695.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr83695.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-loop-interchange.cc trunk/gcc/testsuite/ChangeLog
[Bug debug/68860] [6/7/8 regression] FAIL: gcc.dg/guality/pr36728-1.c -flto -O3 -g line 16/7 arg1 == 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860 Richard Biener changed: What|Removed |Added Attachment #37097|0 |1 is obsolete|| --- Comment #22 from Richard Biener --- Created attachment 43108 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43108&action=edit updated patch Forward-ported Jakubs patch. It still doesn't have the desired effect on the pr68860-1.c testcase, it also crashes during expand somewhere (in addition to the tree-inline.c "fix").
[Bug libquadmath/83800] [libquadmath] M_SQRT2q & sqrtq(2.0Q) off by one ULP ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83800 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The constants were fixed in glibc with https://sourceware.org/git/?p=glibc.git;a=commit;h=2d10d547c1e41138e439d74105246eca31547693 and for GCC in r250343. This is not going to be backported to older GCC versions. Haven't checked sqrtq.
[Bug fortran/83803] Using -fc-prototypes on modules with empty dummy arg lists does not close paren.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83803 --- Comment #2 from Ed Smith-Rowland <3dw4rd at verizon dot net> --- Forgot compiler info: ed@ed-VirtualBox:~$ ./bin/bin/gfortran -v Using built-in specs. COLLECT_GCC=./bin/bin/gfortran COLLECT_LTO_WRAPPER=/home/ed/bin/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/home/ed/bin --enable-languages=c,brig,c++,fortran,go,lto,objc,obj-c++ : (reconfigured) ../gcc/configure --prefix=/home/ed/bin --enable-languages=c,brig,c++,fortran,go,lto,objc,obj-c++ --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/home/ed/bin --enable-languages=c,brig,c++,fortran,go,lto,objc,obj-c++ --no-create --no-recursion Thread model: posix gcc version 8.0.0 20171228 (experimental) (GCC)
[Bug middle-end/83805] [8 Regression] Wrong constant merging for objects in different address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83805 Georg-Johann Lay changed: What|Removed |Added Known to work||7.2.1 Summary|Wrong constant merging for |[8 Regression] Wrong |objects in different|constant merging for |address spaces |objects in different ||address spaces --- Comment #3 from Georg-Johann Lay --- v7.2 did it correctly (any only popped 2 objects).
[Bug middle-end/83805] Wrong constant merging for objects in different address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83805 --- Comment #2 from Georg-Johann Lay --- (In reply to Jakub Jelinek from comment #1) > If so, avr should override the select_section and unique_section target > hooks and return something different for the __flash strings. I am just working on a patch to fix PR83801 which adds STRING_CST handling to the hooks (v7.2 passed VAR_DECL instead of STRING_CST). But even with that patch I am getting wrong results for the code above. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83801#c2 avr doesn't implement TARGET_ASM_UNIQUE_SECTION, but when I supply that hook (atop of the patch above) then this hook is never called for the test case...
[Bug target/83801] [8 Regression][avr] String constant in __flash not put into .progmem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83801 --- Comment #2 from Georg-Johann Lay --- Created attachment 43107 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43107&action=edit proposed patch
[Bug target/81821] [RX] xchg_mem uses wrong memory operand size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81821 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Oleg Endo --- Fixed on trunk and on GCC 7, where atomics were initially added with this bug.
[Bug other/83805] Wrong constant merging for objects in different address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83805 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- If so, avr should override the select_section and unique_section target hooks and return something different for the __flash strings.
[Bug target/83801] [8 Regression][avr] String constant in __flash not put into .progmem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83801 Georg-Johann Lay changed: What|Removed |Added Known to work||7.2.1 Summary|[avr] String constant in|[8 Regression][avr] String |__flash not put into|constant in __flash not put |.progmem|into .progmem --- Comment #1 from Georg-Johann Lay --- Old v7.2 does it correctly: one string in flash, one in RAM.
[Bug target/81821] [RX] xchg_mem uses wrong memory operand size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81821 --- Comment #4 from Oleg Endo --- Author: olegendo Date: Thu Jan 11 15:18:38 2018 New Revision: 256538 URL: https://gcc.gnu.org/viewcvs?rev=256538&root=gcc&view=rev Log: gcc/ Backport from mainline 2018-01-11 Oleg Endo PR target/81821 * config/rx/rx.md (BW): New mode attribute. (sync_lock_test_and_setsi): Add mode suffix to insn output. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/rx/rx.md
[Bug other/83805] Wrong constant merging for objects in different address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83805 Georg-Johann Lay changed: What|Removed |Added Keywords||addr-space, wrong-code Target||avr Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-11 Ever confirmed|0 |1
[Bug target/81821] [RX] xchg_mem uses wrong memory operand size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81821 --- Comment #3 from Oleg Endo --- Author: olegendo Date: Thu Jan 11 15:16:21 2018 New Revision: 256536 URL: https://gcc.gnu.org/viewcvs?rev=256536&root=gcc&view=rev Log: gcc/ PR target/81821 * config/rx/rx.md (BW): New mode attribute. (sync_lock_test_and_setsi): Add mode suffix to insn output. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rx/rx.md
[Bug other/83805] New: Wrong constant merging for objects in different address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83805
Bug ID: 83805
Summary: Wrong constant merging for objects in different
address spaces
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Compile the following code with
$ avr-gcc -Os bug.c -S -mmcu=avr5
char fun1 (unsigned i)
{
static const __flash char str1[] = "0123456789";
__asm ("; " :: "r" (str1));
return str1[i];
}
char fun2 (unsigned i)
{
static const char str2[] = "0123456789";
__asm ("; " :: "r" (str2));
return str2[i];
}
str1 and str2 reside in different address spaces, and they should end up in
different sections; namely str1 in flash (.progmem.data) which is the case, and
str2 in RAM (.rodata) which is not the case.
Instead, the two objects are merged together in .LC0:
.section.progmem.data.str1.1,"aMS",@progbits,1
.LC0:
.string "0123456789"
.text
fun1:
ldi r18,lo8(str1.1511)
ldi r19,hi8(str1.1511)
/* #APP */
;
/* #NOAPP */
movw r30,r24
subi r30,lo8(-(.LC0))
sbci r31,hi8(-(.LC0))
lpm r24,Z
ret
fun2:
ldi r18,lo8(str2.1515)
ldi r19,hi8(str2.1515)
/* #APP */
;
/* #NOAPP */
movw r30,r24
subi r30,lo8(-(.LC0))
sbci r31,hi8(-(.LC0))
ld r24,Z
ret
.section.rodata
str2.1515:
.string "0123456789"
.section.progmem.data,"a",@progbits
str1.1511:
.string "0123456789"
Hence .LC0 is once accessed by LPM (which can only access flash but not RAM)
and once by LD (which can only access RAM but not flash)
Moreover, there are three(!) instances of the string "0123456789" where two
would be enough (one in flash, one in RAM).
[Bug fortran/83803] Using -fc-prototypes on modules with empty dummy arg lists does not close paren.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83803 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-11 CC||tkoenig at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Thomas Koenig --- At least somebody uses it :-) Let's take a look.
[Bug fortran/79383] USE statement error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79383 --- Comment #3 from Walt Brainerd --- Yes, Sounds like you have it fixed. Thanks. On Wed, Jan 10, 2018 at 7:06 PM, kargl at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79383 > > kargl at gcc dot gnu.org changed: > >What|Removed |Added > > > CC||kargl at gcc dot gnu.org > > --- Comment #2 from kargl at gcc dot gnu.org --- > The attached code compiles with both 7-branch an trunk. > When the resulting excutable is run I get 15.10 on output. > Is this the expected behavior? > > -- > You are receiving this mail because: > You reported the bug.
[Bug target/83203] [8 Regression] Inefficient int to avx2 vector conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83203 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 43106 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43106&action=edit gcc8-pr83203.patch Untested fix.
[Bug lto/83804] [meta] LTO memory consumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83804 --- Comment #5 from Martin Liška --- So comparing memory footprint of GCC 7 and GCC 8, I see small increase for WPA phase (~5%).
[Bug lto/83804] [meta] LTO memory consumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83804 --- Comment #4 from Martin Liška --- Created attachment 43105 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43105&action=edit CPU & memory consumption for Inkscape with GCC 8
[Bug lto/83804] [meta] LTO memory consumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83804 --- Comment #3 from Martin Liška --- Created attachment 43104 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43104&action=edit CPU & memory consumption for Inkscape with GCC 7
[Bug lto/83804] [meta] LTO memory consumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83804 --- Comment #2 from Martin Liška --- Created attachment 43103 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43103&action=edit -fmem-report-wpa for Inkscape with -O2 for GCC 8
[Bug lto/83804] [meta] LTO memory consumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83804 --- Comment #1 from Martin Liška --- Created attachment 43102 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43102&action=edit -fmem-report-wpa for Inkscape with -O2 for GCC 7
