[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 --- Comment #21 from Douglas Mencken --- Created attachment 43334 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43334&action=edit Reverting patch I fully reverted that commit on top of gcc-7_3_0-release, and build succeeds
[Bug c++/84197] New: Segmentation fault when setting -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84197
Bug ID: 84197
Summary: Segmentation fault when setting -g
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Created attachment 43335
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43335&action=edit
Reduced file leading to segfault with "g++ -c -std=c++17 -g"
Attached you find the creduced file for triggering the following behavior with
g++-7.3.0:
% g++ -c -std=gnu++17 c.ii
works, while
% g++ -c -std=gnu++17 -g c.ii
c.ii: In member function ‘auto y< >::operator()()
[with = int]’:
c.ii:123:17: internal compiler error: Segmentation fault
g::g()
{ f; }
segfaults.
[Bug fortran/68649] [6/7/8 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649
Thomas Koenig changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #22 from Thomas Koenig ---
What we _could_ do with our array descriptors is to cast them to
a pointer containing a flexible array member, i.e.
struct type_descr {
type *base_addr;
size_t offset;
dtype_type dtype;
index_type span;
descriptor_dimension dim[];
}
which would make all our function calls equal.
I have lightly tested the concept with a C program, i.e.
foo.c:
struct Xflex { int n; int a[]; };
int foo (struct Xflex *f)
{
int i;
int s;
s = 0;
for (i=0; in; i++)
s += f->a[i];
return s;
}
bar.c:
#include
struct Xflex { int n; int a[]; };
struct X2 { int n; int a[2]; };
struct X2 x;
int foo (struct Xflex *f);
int main(void)
{
x.n = 2;
x.a[0] = 1;
x.a[1] = 3;
printf("%d\n", foo((struct Xflex *) &x));
}
which seems to work.
[Bug tree-optimization/84114] global reassociation pass prevents fma usage, generates slower code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84114 Wilco changed: What|Removed |Added CC||wdijkstr at arm dot com --- Comment #2 from Wilco --- (In reply to Steve Ellcey from comment #0) > Created attachment 43279 [details] > Test case > > The example code comes from milc in SPEC2006. > > GCC on x86 or aarch64 generates better code with -O3 than it does with > -Ofast or '-O3 -ffast-math'. On x86 compiling with '-mfma -O3' I get 5 > vfmadd231sd instructions, 1 vmulsd instruction and 6 vmovsd. With '-mfma > -Ofast' I get 3 vfmadd231sd, 2 vaddsd, 3 vmulsd, and 6 vmovsd. That is two > extra instructions. > > The problem seems to be that -Ofast turns on -ffast-math and that enables > the global reassociation pass (tree-ssa-reassoc.c) and the code changes > done there create some temporary variables which inhibit the recognition > and use of fma instructions. > > Using -O3 and -Ofast on aarch64 shows the same change. I noticed this a while back, the reassociation pass has changed and now we get far fewer fmas. See https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00771.html
[Bug rtl-optimization/59393] [6/7/8 regression] mips16/7/8 code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 Aldy Hernandez changed: What|Removed |Added Status|NEW |WAITING CC||aldyh at gcc dot gnu.org --- Comment #11 from Aldy Hernandez --- I have chatted with Sandra (the original reporter) who has confirmed that the size for the original testcase on current mainline is 2296 bytes on MIPS16. This is better than the reported regression, but still not as good as 4.7. The reporter is OK with closing the PR since they no longer care about MIPS16. However, as far as I understand, this may affect other architectures. Is this at all on our radar to fix, or can we either (a) close as WONTFIX (b) move the target milestone to GCC 9? Thanks.
[Bug ada/84198] New: Illegal program accepted, storing an anonymous access-to-subprogram value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84198 Bug ID: 84198 Summary: Illegal program accepted, storing an anonymous access-to-subprogram value Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jrcarter at acm dot org Target Milestone: --- Created attachment 43336 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43336&action=edit Spec and body of package Store_Anon gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3) System type: Xubuntu 17.10 Options when gcc was configured/built: unknown, distro repository version Command line passed to gcc: gcc-7 -c store_anon.adb Actual behavior: store_anon.adb compiles successfully Expected behavior: The declaration of the constant Illegal in Store_Anon.Store should be rejected as illegal (according to Randy Brukardt, ARG member and ARM editor, on comp.lang.ada)
[Bug testsuite/84094] several correctness issues in gfortran.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84094 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-04 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed. Patch submitted at https://gcc.gnu.org/ml/fortran/2018-02/msg00014.html for four tests.
[Bug fortran/84115] [8 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'indirect_ref' in add_decl_as_local, at fortran/trans-decl.c:256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84115 --- Comment #4 from Paul Thomas --- Author: pault Date: Sun Feb 4 13:18:33 2018 New Revision: 257363 URL: https://gcc.gnu.org/viewcvs?rev=257363&root=gcc&view=rev Log: 2018-02-04 Paul Thomas PR fortran/84115 * trans-decl.c (gfc_get_symbol_decl): Do not finish the decl of 'length' if the symbol charlen backend_decl is an indirect ref. 2018-02-04 Paul Thomas PR fortran/84115 * gfortran.dg/associate_34.f90: New test. * gfortran.dg/associate_35.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/associate_34.f90 trunk/gcc/testsuite/gfortran.dg/associate_35.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/84115] [8 Regression] Failure in associate construct with concatenated character target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84115 Paul Thomas changed: What|Removed |Added Summary|[8 Regression] ICE: tree|[8 Regression] Failure in |check: expected tree that |associate construct with |contains 'decl minimal' |concatenated character |structure, have |target |'indirect_ref' in | |add_decl_as_local, at | |fortran/trans-decl.c:256| --- Comment #5 from Paul Thomas --- The PR is substantially fixed. However, the failure in associate_35.f90 is the only test in the patch that works with 7-branch! The rest compile but fail at run-time. Therefore, I have edited the title and left the PR open. Paul
[Bug c/84166] Wrong warning message emitted for loss of qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84166 Thanassis Tsiodras changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Thanassis Tsiodras --- Many thanks, Joseph. Please close this... and my apologies for the noise - but without your kind suggestion this would be beyond me.
[Bug testsuite/84094] several correctness issues in gfortran.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84094 --- Comment #2 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Sun Feb 4 13:44:52 2018 New Revision: 257364 URL: https://gcc.gnu.org/viewcvs?rev=257364&root=gcc&view=rev Log: 2018-02-04 Dominique d'Humieres PR fortran/84094 * gfortran.dg/associate_23.f90: Fix invalid code. * gfortran.dg/intrinsic_actual_4.f90: Likewise. * gfortran.dg/matmul_3.f90: Likewise. * gfortran.dg/transfer_array_intrinsic_2.f90: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/associate_23.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_actual_4.f90 trunk/gcc/testsuite/gfortran.dg/matmul_3.f90 trunk/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_2.f90
[Bug fortran/33234] Confusing diagnostic when passing intrinsic function as actual argument without INTRINSIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33234
Dominique d'Humieres changed:
What|Removed |Added
Summary|-stf=f* and passing |Confusing diagnostic when
|intrinsic function as |passing intrinsic function
|actual argument without |as actual argument without
|INTRINSIC |INTRINSIC
--- Comment #1 from Dominique d'Humieres ---
Since at least gfortran-4.5.4, compiling the following test with -Wall
subroutine sub (proc, chr)
external proc
integer proc
character*(*) chr
if (proc (chr) .ne. 6) call abort ()
end subroutine sub
implicit none
integer i
i = len ("123")
call sub (len, "abcdef")
end
gives
i = len ("123")
1
Warning: Type specified for intrinsic function 'len' at (1) is ignored
This warning does not point to the actual problem, is confusing, and IMO should
be an error.
[Bug c/84190] [7 Regression] double arithmetic on x86 no longer rounds to nearest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190 --- Comment #4 from joseph at codesourcery dot com --- You need to use -fexcess-precision=standard (or -msse2 -mfpmath=sse) for predictable results from double arithmetic on 32-bit x86. If you do that, do you still see such a problem? If not, this is just a duplicate of bug 323 (and what's a volatile access is irrelevant).
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #9 from Joseph S. Myers --- Not a bug. The appropriate time to raise such an issue is if in future there is otherwise consensus to have a major libc ABI break and move to libc.so.7 SONAME, and the appropriate place is the mailing lists that have such a discussion at that time.
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #10 from Javier Serrano Polo --- (In reply to Joseph S. Myers from comment #9) > Not a bug. The appropriate time to raise such an issue is if in future > there is otherwise consensus to have a major libc ABI break and move to > libc.so.7 SONAME, and the appropriate place is the mailing lists that have > such a discussion at that time. This report is about the patch that will be submitted with multiarch names. It is an enhancement request to support multiarch systems. It has nothing to do with whatever ABI breaks you believe may happen; libc.so.7 is not needed. If you do not understand this goal, status should be "unconfirmed". If you do, it should be "wontfix".
[Bug ada/84198] Illegal program accepted, storing an anonymous access-to-subprogram value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84198 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-04 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Please avoid reporting the same issue twice, this doesn't make things simpler.
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #11 from Marc Glisse --- (In reply to Javier Serrano Polo from comment #10) > This report is about the patch that will be submitted with multiarch names. If you intend to send a patch, you can send it directly to gcc-patc...@gcc.gnu.org, you don't need a bugzilla entry...
[Bug c/84100] [7 Regression] Function __attribute__((optimize(align-loops=32))) gives spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84100
--- Comment #7 from Chris Hall ---
And here's a funny thing...
... if I compile "-O3 -falign-functions -falign-loops=32" I get the alignment I
ask for.
... if I compile "-O3 -falign-functions -falign-loops=32 -fno-tree-vectorize"
I get the alignment I ask for (and I avoid Bug 84101).
... if I compile "-O3 -falign-functions -falign-loops=32" but with:
_Pragma("GCC optimize(\"no-tree-vectorize\")")
extern int func_x(int num) ;
extern int func_y(int num) ;
extern uint64_pair_t pair(int num) ;
extern int func_z(int num) ;
I no longer get the alignment I asked for, I get the default alignment for -O3
!
And, for further amusement:
extern int func_x(int num) ;
extern int func_y(int num) ;
extern uint64_pair_t pair(int num)
__attribute__((optimize("no-tree-vectorize"))) ;
extern int func_z(int num) ;
has exactly the same effect !
FWIW, I have tried _Pragma("GCC push/pop/reset_options") -- the effect of which
is hard to determine; but I can say that pop/reset do not restore all
optimization option settings.
[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518 --- Comment #10 from Aldy Hernandez --- I'm having some trouble reproducing this bug. I'm a little rusty on cross builds, so perhaps someone can lend a hand. I have a set of combined sources which I'm using to build a toolchain like this: ~/src/combined/configure --host=x86_64-linux --build=x86_64-linux --target=armeb-eabi --with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon-fp16 --enable-languages=fortran --disable-libgomp --disable-libsanitizer --disable-werror I then do: cd gcc && make check-fortran RUNTESTFLAGS="execute.exp=in-pack.f90 --target_board=arm-sim" === gfortran tests === Schedule of variations: arm-sim Running target arm-sim Using /usr/share/dejagnu/baseboards/arm-sim.exp as board description file for target. Using /usr/share/dejagnu/config/sim.exp as generic interface file for target. Using /usr/share/dejagnu/baseboards/basic-sim.exp as board description file for target. Using /home/cygnus/aldyh/src/combined/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/cygnus/aldyh/src/combined/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp ... FAIL: gfortran.fortran-torture/execute/in-pack.f90 execution, -O0 FAIL: gfortran.fortran-torture/execute/in-pack.f90 execution, -O1 ... I get failures for everything, but it seems every execution test fails, even simple C tests. Tests fail with no messages, just a simple execution failure, so I had to dig into the simulator. I patched the gdb simulator to trace the instructions to see where we are dying: diff --git a/sim/arm/wrapper.c b/sim/arm/wrapper.c index bc1a043..4492b19 100644 --- a/sim/arm/wrapper.c +++ b/sim/arm/wrapper.c @@ -53,7 +53,7 @@ int stop_simulator; #include "dis-asm.h" This presumably gives us some tracing in gcc/testsuite/*/*.log: /* TODO: Tracing should be converted to common tracing module. */ -int trace = 0; +int trace = 1; int disas = 0; int trace_funcs = 0; The GCC testsuite log file now shows: pc: 8c8c, instr: e3530014 pc: 8c90, instr: 1afb pc: 8c94, instr: e5952000 pc: 8c98, instr: e3a03000 pc: 8c9c, instr: e5856014 pc: 8ca0, instr: e5853018 pc: 8ca4, instr: e1c520fc pc: 4, instr: ea00089b I took a peek at the executable being run with "/my-arm-build/objdudump -D the-executable.exe", and I see we are failing in initialise_monitor_handles(). This suggests we're failing during the start-up code: 8c8c: e3530014cmp r3, #20 8c90: 1afbbne 8c84 8c94: e5952000ldr r2, [r5] 8c98: e3a03000mov r3, #0 8c9c: e5856014str r6, [r5, #20] 8ca0: e5853018str r3, [r5, #24] 8ca4: e1c520fcstrdr2, [r5, #12] It seems that last store is corrupting things and making us jump to a PC of 4??? Before I bark up the wrong trees, I have some questions. Am I running the simulator correctly? Does it require a special flag for cortex-a9? Is the cortex-a9 CPU even handled by the simulator? Should I run the dejagnu tests with -mcpu= or whatever, or is the --with-cpu=cortex-a9 configury flag enough? Does the arm newlib/libgloss/whatever code have instructions that aren't handled by the GDB simulator? I don't want to dig too deep into this, only to find out that our simulator, newlib, or whatever cannot handle cortex-a9 + neon-fp16. For that matter, is this bug reproducible on a more generic Arm variant that *IS* supported by gdb? Sorry for the barrage of questions, but this is a P1, and there doesn't seem to be an easy way to reproduce this.
[Bug rtl-optimization/59393] [6/7/8 regression] mips16/7/8 code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 --- Comment #12 from Jeffrey A. Law --- One more tidbit here. I noted that we got "reasonably" close to having enough state in the combiner to attack this in c#7. The problem is there's a REG object that we really need to be a CONST_INT. It turns out that we're failing to substitute the value from a REG_EQUAL note as combine builds up that hunk of RTL. So if we were to substitute in the REG_EQUAL, then we'd have a fighting chance to address this in the combiner.
[Bug rtl-optimization/59393] [6/7/8 regression] mips16/7/8 code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 --- Comment #13 from Aldy Hernandez --- Do we care though? Does this bug pose a big enough problem on non MIPS16 that we would like addressed? Just curious On Sun, Feb 4, 2018 at 10:50 AM, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 > > --- Comment #12 from Jeffrey A. Law --- > One more tidbit here. I noted that we got "reasonably" close to having enough > state in the combiner to attack this in c#7. The problem is there's a REG > object that we really need to be a CONST_INT. > > It turns out that we're failing to substitute the value from a REG_EQUAL note > as combine builds up that hunk of RTL. So if we were to substitute in the > REG_EQUAL, then we'd have a fighting chance to address this in the combiner. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c/84190] [7 Regression] double arithmetic on x86 no longer rounds to nearest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190 --- Comment #5 from Bruno Haible --- (In reply to jos...@codesourcery.com from comment #4) > You need to use -fexcess-precision=standard (or -msse2 -mfpmath=sse) for > predictable results from double arithmetic on 32-bit x86. If you do that, > do you still see such a problem? If I pass -fexcess-precision=standard or -mfpmath=sse (no need for -msse2 in this case), the test passes. However, something has evidently changed (regressed) in the inliner: 'volatile double', put in sufficiently many places, has the same effect as -fexcess-precision=standard (before gcc 7 and in gcc 7). What has changed, is that if I have 'volatile double' only in the signature of the 'equalfn' function that gets inlined, since gcc 7 this information that the values should be passed as IEEE doubles (discarding excess precision) gets lost.
[Bug ipa/80899] [6/7/8 Regression] Devirtualization causes incorrect code generation with placement new in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80899 --- Comment #6 from Jan Hubicka --- The problem here is that after gimplification we make no distinction between original pointer and pointer returned by placement new. If one can placement new different type to object into arbitrary field of structure, probably one can do it also for automatic and static variables. So we would need to anticipate dynamic type changes absolutely everywhere. This would more or less disable nonspeculative devirtualization completely because in most cases there is some function call between constructor and use of values which prevents us from proving that the value did not change. What we could do is to keep new operations represented in gimple form until later stages of compilation (remove them soonish after IPA is done). So having osmething like new_ptr = __builtin_placement_new (oldptr) which would also hold type of the allocated value (not sure how to do that without having declaration of biultin_placement_new for every type but even that would work well for me). This would be useful information because devirt machinery then could expect that the dynamic type did not change for all polymorphic types and subtypes. Would that make sense to you? Probably something for next stage1 though.
[Bug ipa/79966] [6/7 Regression] run time more than twice slower when using -fipa-cp-clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79966 Jan Hubicka changed: What|Removed |Added Summary|[6/7/8 Regression] run time |[6/7 Regression] run time |more than twice slower when |more than twice slower when |using -fipa-cp-clone|using -fipa-cp-clone --- Comment #5 from Jan Hubicka --- Fixed on trunk.
[Bug ipa/79966] [6/7 Regression] run time more than twice slower when using -fipa-cp-clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79966 --- Comment #6 from Jan Hubicka --- Author: hubicka Date: Sun Feb 4 17:15:36 2018 New Revision: 257367 URL: https://gcc.gnu.org/viewcvs?rev=257367&root=gcc&view=rev Log: PR middle-end/79966 * gfortran.dg/pr79966.f90: New testcase Added: trunk/gcc/testsuite/gfortran.dg/pr79966.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 --- Comment #22 from Douglas Mencken --- So yet I have fully workin’ $ /Developer/GCC/7.3patched/PowerPC/32bit/bin/gcc -v Using built-in specs. COLLECT_GCC=/Developer/GCC/7.3patched/PowerPC/32bit/bin/gcc COLLECT_LTO_WRAPPER=/Developer/GCC/7.3patched/PowerPC/32bit/libexec/gcc/powerpc-unknown-darwin/7.3.0/lto-wrapper Target: powerpc-unknown-darwin Configured with: ../gcc-git/configure --build=powerpc-unknown-darwin --host=powerpc-unknown-darwin --target=powerpc-unknown-darwin --prefix=/Developer/GCC/7.3patched/PowerPC/32bit --enable-languages=c,c++,objc,obj-c++ --enable-shared --enable-static --enable-checking=release --enable-threads=posix --with-__thread --without-system-zlib --disable-nls --disable-werror Thread model: posix gcc version 7.3.0 (GCC) as for https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02040.html I think that optimizing epilogues is a good idea, but not of a cost of unbuildability, even when it’s unbuildability on “quartiary” ( read as “we don’t care” ) platform
[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 --- Comment #23 from Segher Boessenkool --- (In reply to Douglas Mencken from comment #22) > as for https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02040.html > I think that optimizing epilogues is a good idea, but not of a cost of > unbuildability, > even when it’s unbuildability on “quartiary” ( read as “we don’t care” ) > platform GCC 7 was released more than nine months ago, and yet no one has noticed that it does not build at all on powerpc-darwin. We cannot do magic.
[Bug middle-end/84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016 Jan Hubicka changed: What|Removed |Added Depends on||84149 --- Comment #9 from Jan Hubicka --- MCF regression of spec2017 is due to predictor change. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149 [Bug 84149] [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888
[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 --- Comment #24 from Douglas Mencken --- (In reply to Segher Boessenkool from comment #23) > GCC 7 was released more than nine months ago, and yet no one has noticed > that it does not build at all on powerpc-darwin. We cannot do magic. Well, yo can~ “ David and Iain, can you please test on AIX and Darwin? Or is this okay for trunk without testing? ;-) ” © Segher Boessenkool https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02040.html “ This is okay. ” © David Edelsohn https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02051.html [ ..to push without testing ] And it’s more than year and five months since that... Nobody noticed, nor Iain, nor me myself. Until now So. What to do next? Would it be left ”as is” with yet-gained knowledge what to revert for these rare species still building GCC on such too extinct platform? Or there would be some compromise between “Don't emit a use of LR in returns and sibcalls” and buildability on rs6000:darwin from your side?
[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 --- Comment #25 from Segher Boessenkool --- Please test https://gcc.gnu.org/ml/gcc-testresults/2017-01/txtnZhWiDkC4z.txt .
[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 --- Comment #26 from Douglas Mencken --- (In reply to Segher Boessenkool from comment #25) > Please test https://gcc.gnu.org/ml/gcc-testresults/2017-01/txtnZhWiDkC4z.txt Okay, and as I got it, it is supposed to apply upon fresh GCC with that “Don't emit a use of LR in returns and sibcalls” patch, yeah?
[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 --- Comment #27 from Segher Boessenkool --- Yes.
[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 --- Comment #28 from Douglas Mencken --- (In reply to Segher Boessenkool from comment #27) > Yes. Wow, it compiles So I suggest to push patch https://gcc.gnu.org/ml/gcc-testresults/2017-01/txtnZhWiDkC4z.txt after checking on other rs6000 systems to the trunk. And to mark this bug as dupe of #80865 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865 One important question ’s yet: Why this patch has been ignored despite it’s been made just in time?
[Bug c/25892] -Wpointer-sign creates problems for Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892 --- Comment #10 from postmas...@welsh-buck-org.bounceio.net --- Your email was bounced... - ... because something went wrong between you and your recipient. Bummer! What to do next? Well, your specific problem was a *5.1.2 * error. The domain you attempted to contact, welsh-buck.org[1], may have expired. You can check WHOIS for welsh-buck.org here[2] to determine if this is the case. If so, contact your recipient another way (e.g., phone or text message) to confirm their email address. Get more help on 5.1.2 errors here![3] Thanks, have a lovely day. Yours truly, betterbounces.net[4] Rate this email: Helpful[5] :) or... Not Helpful[6] :( © 2017 betterbounces.net, All rights reserved. Privacy[7] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] 1. https://a.b-io.me/c/Y1lM9w9S1Kf4hqMBH_kdL8MeFO_3lx9xBiryJY2Rm7rQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYe4emAxad08WkBe7p1WtWTJS.nK59aaDBqX8Ml3pv4kfCJ5dD8uY12RscIdXDQFm3MJo4OjTTKiL073sGwUmDKGkaMPkuMy3SADoRWZqA56BF0EtiS3ceFpzHs3CIOO6GtjX7LIU.UQ8AbYgVyOhUVYNu5j.inz.23AoU3Z2mJ8MY851JGPURbWxWDghqtbyhCAuvLcI3WN2ewTIUE7DVXtqgddgBCkJKn2vLHfq_o._E4aQ06SoeEEphTiMDN6PygkTuDih8C.4EgrHnL4ZdkLkHb3Deos.A- 2. https://a.b-io.me/c/Y1lM9w9S1Kf4hqMBH_kdL8MeFO_3lx9xBiryJY2Rm7rQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYe4emAxad08WkBe7p1WtWTJS.nK59aaDBqX8Ml3pv4kfCJ5dD8uY12RscIdXDQFm3MJo4OjTTKiL073sGwUmDKGkaMPkuMy3SADoRWZqA56BF0EtiS3ceFpzHs3CIOO6EOfywZJcszwAf.cIZ9_wkKSBwTW7OVDhzEIHLbtH9hJh6Ntt5DcBo4Q_Ff1Hlr7qC5AubVwp4npLVx_SJUN89AxsQKPNnb3.0k6byGqkdo2kKaSqAACxurg.5SDi6gTpIn.YKJJIf1a3nOTslf.Vj49FeLkUJv385AXvIGADZOR4fo8XPiNFng 3. https://a.b-io.me/c/Y1lM9w9S1Kf4hqMBH_kdL8MeFO_3lx9xBiryJY2Rm7rQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYe4emAxad08WkBe7p1WtWTJS.nK59aaDBqX8Ml3pv4kfCJ5dD8uY12RscIdXDQFm3MJo4OjTTKiL073sGwUmDKGkaMPkuMy3SADoRWZqA56BF0EtiS3ceFpzHs3CIOO6FwAfp4V3ojmL5ccHJL4zXMUiZ.VwRVR0vWdj77IuzsZTkK56MgLlgI4h69qy0CfWFgSPpreTGdYr_Y25.TynKEUNqTAUKphhhzPCOkHxucBrS7U6X7QC2.jAehj06y_TTAG2IFcjoVFQ9ZHZGxGh33G3IM.pIr1HDocmlbmsKBujNdXkBC1i6R9FbPDZoBNzGNE4gztylPle8NHh464vf7cDgI42pt6sHCvA42RnAtjJ77ciKWc1ZX7u6sTvb740csynd_Tc3F4GWjALJW_J1jqoVLzf8qZiOMAFgVobzBBQ-- 4. https://a.b-io.me/c/Y1lM9w9S1Kf4hqMBH_kdL8MeFO_3lx9xBiryJY2Rm7rQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYe4emAxad08WkBe7p1WtWTJS.nK59aaDBqX8Ml3pv4kfCJ5dD8uY12RscIdXDQFm3MJo4OjTTKiL073sGwUmDKGkaMPkuMy3SADoRWZqA56BF0EtiS3ceFpzHs3CIOO6EkHU7fZyF3nfEAhw97pISWY6KH48BGme83LnC4yHEAcc9IhrWnm6PTj3vgnMFFcniA6aC5DF1aKBBHRzcRPb1ivS1QV1.NpCCbRUxU.jdCviuUfkmVQ_tRX7giWLw1Ggej6wpTnL4D99kZNtAPyRDdo98PjjUAaWw- 5. https://a.b-io.me/c/Y1lM9w9S1Kf4hqMBH_kdL8MeFO_3lx9xBiryJY2Rm7rQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYe4emAxad08WkBe7p1WtWTJS.nK59aaDBqX8Ml3pv4kfCJ5dD8uY12RscIdXDQFm3MJo4OjTTKiL073sGwUmDKGkaMPkuMy3SADoRWZqA56BF0EtiS3ceFpzHs3CIOO6FwAfp4V3ojmPP6s3M.xTPJkYdS5limhFbaC0b9OzhsfWWsLvKc3LWUt2aivV76Db6UbYAa0ITsDhALziy5P24hWB7Nb7Zixngn.YKJJIf1a3nOTslf.Vj49FeLkUJv385zh.HKmctd1XW2ZoMeK1cgK__YtsXi1Z22K1P3VYjXnSw_zivbLYA8gsXkVv4pjsmdZK_tM9D5EurOblYuJB.1m.MwW0ATJWrAYpf6OPi2Kr8Kd94C06XNIYiv08D3K_WkImBP7UVGGwdN1KTXcuj6iBDNlPd38Sdjcu4YkmZFLvNhZRmsleMJ 6. https://a.b-io.me/c/Y1lM9w9S1Kf4hqMBH_kdL8MeFO_3lx9xBiryJY2Rm7rQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYe4emAxad08WkBe7p1WtWTJS.nK59aaDBqX8Ml3pv4kfCJ5dD8uY12RscIdXDQFm3MJo4OjTTKiL073sGwUmDKGkaMPkuMy3SADoRWZqA56BF0EtiS3ceFpzHs3CIOO6FwAfp4V3ojmPP6s3M.xTPJkYdS5limhFbaC0b9OzhsfWWsLvKc3LWUt2aivV76Db6UbYAa0ITsDhALziy5P24hWB7Nb7Zixngn.YKJJIf1a3nOTslf.Vj49FeLkUJv385zh.HKmctd1XW2ZoMeK1cgE.V.tpZ_s4b3GK8.Zh00RTNdXkBC1i6R9FbPDZoBNzGNE4gztylPle8NHh464vf7cDgI42pt6sGnCuK7Do.KeSJHVp.dzyqgjROBbE9G0kqpmnSy2QeNUjy4vXYux2D1FLtAxEfvU39KEHRh9tlbAqBotb8_CvsVdiMujtpmxZA- 7. https://a.b-io.me/c/Y1lM9w9S1Kf4hqMBH_kdL8MeFO_3lx9xBiryJY2Rm7rQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYe4emAxad08WkBe7p1WtWTJS.nK59aaDBqX8Ml3pv4kfCJ5dD8uY12RscIdXDQFm3MJo4OjTTKiL073sGwUmDKGkaMPkuMy3SADoRWZqA56BF0EtiS3ceFpzHs3CIOO6FwAfp4V3ojmL5ccHJL4zXMUiZ.VwRVR0t9lhaXfDWL3yAcGsBoaDJAmRsO.OlKlKy3AoU3Z2mJ8MY851JGPURbWxWDghqtbyhCAuvLcI3WN2ewTIUE7DVXtqgddgBCkJKn2vLHfq_o._E4aQ06SoeEEphTiMDN6PygkTuDih8C.4EgrHnL4ZdkLkHb3Deos.A-
[Bug target/80865] broken compilation on Mac OS X 10.5 / powerpc: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865 Douglas Mencken changed: What|Removed |Added CC||dougmencken at gmail dot com --- Comment #13 from Douglas Mencken --- bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 is related to this one
[Bug rtl-optimization/59393] [6/7/8 regression] mips16/7/8 code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 --- Comment #14 from Jeffrey A. Law --- I suspect we could likely show a similar codesize and performance regression on other targets. ppc & arm come to mind. aarch64 as well, but it wouldn't be a regression there since it didn't exist when this was first reported. mips16? Na, I don't care too much about that :-)
[Bug rtl-optimization/59393] [6/7/8 regression] mips16/7/8 code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 Aldy Hernandez changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #15 from Aldy Hernandez --- If we care about this on non MIPS16 targets, we can open a new PR and reference this one, perhaps with a less target specific title :).
[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 --- Comment #29 from Segher Boessenkool --- The patch has never been sent to gcc-patches. It also still never was properly tested. Can you do that?
[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 --- Comment #30 from Douglas Mencken --- (In reply to Segher Boessenkool from comment #29) > The patch has never been sent to gcc-patches. It also still never was > properly tested. Can you do that? Like doing ‘make check’ after it completes 3rd stage? Sure
[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 --- Comment #31 from Douglas Mencken --- (In reply to Segher Boessenkool from comment #29) > The patch has never been sent to gcc-patches. It also still never was > properly tested. Can you do that? Or you’re bout sending it to “gcc-patches” by myself?
[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 --- Comment #32 from Segher Boessenkool --- Yes, run "make -k check" (add -jN to taste if you have multiple CPUs). And then run contrib/test_summary. See if that is as expected (compare it to previous powerpc-darwin results on gcc-testresults@; you can also send your testresults there).
[Bug bootstrap/84199] New: Error building gcc 7.3.0 on Odroid XU4 (ARM, Ubuntu): cannot load liblto_plugin.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84199 Bug ID: 84199 Summary: Error building gcc 7.3.0 on Odroid XU4 (ARM, Ubuntu): cannot load liblto_plugin.so Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: bugzi...@poradnik-webmastera.com Target Milestone: --- Created attachment 43337 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43337&action=edit Full build log I was trying to build gcc 7.3.0 on Odroid XU4 (ARM, Ubuntu) but build failed with following error: /gcc/build/./gcc/xgcc -B/gcc/build/./gcc/ -B/gcc-7.3.0/armv7l-unknown-linux-gnueabihf/bin/ -B/gcc-7.3.0/armv7l-unknown-linux-gnueabihf/lib/ -isystem /gcc-7.3.0/armv7l-unknown-linux-gnueabihf/include -isystem /gcc-7.3.0/armv7l-unknown-linux-gnueabihf/sys-include-O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -B./ _thumb1_case_sqi_s.o _thumb1_case_uqi_s.o _thumb1_case_shi_s.o _thumb1_case_uhi_s.o _thumb1_case_si_s.o _udivsi3_s.o _divsi3_s.o _umodsi3_s.o _modsi3_s.o _bb_init_func_s.o _call_via_rX_s.o _interwork_call_via_rX_s.o _lshrdi3_s.o _ashrdi3_s.o _ashldi3_s.o _arm_negdf2_s.o _arm_addsubdf3_s.o [cut cut cut] eqdf2_s.o gedf2_s.o ledf2_s.o muldf3_s.o negdf2_s.o subdf3_s.o unorddf2_s.o fixdfsi_s.o floatsidf_s.o floatunsidf_s.o extendsfdf2_s.o truncdfsf2_s.o enable-execute-stack_s.o unwind-arm_s.o libunwind_s.o pr-support_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && (echo "/* GNU ld script"; echo " Use the shared library, but some functions are only in"; echo " the static library. */"; echo "GROUP ( libgcc_s.so.1 -lgcc )" ) > ./libgcc_s.so /usr/bin/ld: /gcc/build/./gcc/liblto_plugin.so: error loading plugin: /gcc/build/./gcc/liblto_plugin.so: cannot open shared object file: No such file or directory collect2: error: ld returned 1 exit status Makefile:977: recipe for target 'libgcc_s.so' failed make[3]: *** [libgcc_s.so] Error 1 make[3]: Leaving directory '/gcc/build/armv7l-unknown-linux-gnueabihf/libgcc' Makefile:21293: recipe for target 'all-stage2-target-libgcc' failed make[2]: *** [all-stage2-target-libgcc] Error 2 make[2]: Leaving directory '/gcc/build' Makefile:26191: recipe for target 'stage2-bubble' failed make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory '/gcc/build' Makefile:939: recipe for target 'all' failed make: *** [all] Error 2 odroid@odroid-linux-1:~$ gcc --version gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.6) 5.4.0 20160609 Copyright (C) 2015 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. odroid@odroid-linux-1:~$ uname -a Linux odroid-linux-1 3.10.105-138 #1 SMP PREEMPT Fri Apr 7 12:40:29 UTC 2017 armv7l armv7l armv7l GNU/Linux odroid@odroid-linux-1:~$ cat /etc/*release* DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS" NAME="Ubuntu" VERSION="16.04.3 LTS (Xenial Xerus)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 16.04.3 LTS" VERSION_ID="16.04" HOME_URL="http://www.ubuntu.com/"; SUPPORT_URL="http://help.ubuntu.com/"; BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"; VERSION_CODENAME=xenial UBUNTU_CODENAME=xenial odroid@odroid-linux-1:~$
[Bug middle-end/84200] New: r256888 causes 30% performance regression of 519.lbm_r at -Ofast generic tuning on Zen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84200 Bug ID: 84200 Summary: r256888 causes 30% performance regression of 519.lbm_r at -Ofast generic tuning on Zen Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org Target Milestone: --- Revision 256888 caused 30% run-time regression of 519.lbm_r when compiled with -Ofast (with generic march and tuning) and when run on a Zen CPU. I have observed it on both a Ryzen and an EPYC. Surprisingly, the revision does not seem to have any effect on this particular benchmark on my Intel Sandy Bridge desktop. The changelog for the revision is below, I believe it is the first listed change that is the culprit. 2018-01-19 Martin Liska * predict.def (PRED_LOOP_EXIT): Change from 85 to 89. (PRED_LOOP_EXIT_WITH_RECURSION): Change from 72 to 78. (PRED_LOOP_EXTRA_EXIT): Change from 83 to 67. (PRED_OPCODE_POSITIVE): Change from 64 to 59. (PRED_TREE_OPCODE_POSITIVE): Change from 64 to 59. (PRED_CONST_RETURN): Change from 69 to 65. (PRED_NULL_RETURN): Change from 91 to 71. (PRED_LOOP_IV_COMPARE_GUESS): Change from 98 to 64. (PRED_LOOP_GUARD): Change from 66 to 73.
[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 --- Comment #50 from Chris Johns --- I raised an Apple bug report last December, the number is 36163995. Nothing useful has happened. I will ping the bug and ask what is happening.
[Bug target/84201] New: 549.fotonik3d_r from SPEC2017 fails verification with -mprefer-vector-width=256 or 512 on Zen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84201 Bug ID: 84201 Summary: 549.fotonik3d_r from SPEC2017 fails verification with -mprefer-vector-width=256 or 512 on Zen Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org Target Milestone: --- I'm not sure if I can post any more details than what the subject says. On AMD EPYC and Ryzen machines (at least), 549.fotonik3d_r from SPEC 2017 fails with a verification error when compiled with any of the following combination of options: -Ofast -g -march=native -mtune=native -mprefer-vector-width=256 -Ofast -g -march=native -mtune=native -mprefer-vector-width=512 Unfortunately, it does not fail the test run but only the reference run.
[Bug tree-optimization/84202] New: missing -Wnonnull on a returns_nonnull function returning null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84202
Bug ID: 84202
Summary: missing -Wnonnull on a returns_nonnull function
returning null
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC silently accepts definitions of functions such as f() below declared with
attribute returns_nonnull. Clang issues -Wnonnull on functions that trivially
violate that guarantee.
void* __attribute__ ((returns_nonnull)) f ()
{
return 0; // missing -Wnonnull
}
Diagnosing trivial mistakes like the one above is only of very limited
usefulness. GCC can do much better by also diagnosing functions that might
return null such as the two below. Clang doesn't diagnose these.
void* __attribute__ ((returns_nonnull)) g (unsigned n)
{
return __builtin_malloc (n); // missing -Wnonnull
}
void* __attribute__ ((returns_nonnull)) h (unsigned n)
{
static char buf[256];
return n < sizeof buf ? buf : __builtin_malloc (n); // missing -Wnonnull
}
[Bug tree-optimization/84203] New: add -Wsuggest-attribute=returns_nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84203
Bug ID: 84203
Summary: add -Wsuggest-attribute=returns_nonnull
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The option -Wsuggest-attribute= helps improve code generation by annotating
function declarations with attributes like cold, const, pure, malloc and
noreturn. However, the option doesn't make it possible to request suggestions
for the returns_nonnull attribute. Especially in C++ where functions returning
newly allocated memory often never return null (because they throw on failure
to allocate), making use of the attribute could further improve generated code.
$ cat t.C && gcc -Wall -Wextra -O -S -Wsuggest-attribute=noreturn t.C
int f () // -Wsuggest-attribute=noreturn here (good)
{
throw "not implemented";
}
void* f (unsigned n) // missing -Wsuggest-attribute=returns_nonnull
{
return new char[n];
}
t.C: In function ‘int f()’:
t.C:1:5: warning: function might be candidate for attribute ‘noreturn’
[-Wsuggest-attribute=noreturn]
int f () // -Wsuggest-attribute=noreturn here (good)
^
[Bug tree-optimization/84203] add -Wsuggest-attribute=returns_nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84203 Martin Sebor changed: What|Removed |Added Keywords||diagnostic See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84202 Severity|normal |enhancement --- Comment #1 from Martin Sebor --- See also bug 84202.
[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 --- Comment #51 from Jonathan Wakely --- The patch in comment 45 is not acceptable for all platforms. I'll entertain a patch that only affects the broken platforms, but not something that will end up being carried around forever and for platforms with working filesystems.
[Bug tree-optimization/84202] missing -Wnonnull on a returns_nonnull function returning null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84202 Martin Sebor changed: What|Removed |Added Blocks||58689 --- Comment #1 from Martin Sebor --- After some searching I came across bug 58689 that suggests the same thing (among other returns_nonnull enhancements). I'm not sure it makes more sense to resolve this bug as a duplicate of it or to treat bug 58689 as a meta-bug and link this and any other smaller reports/requests having to do with returns_nonnull to it. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58689 [Bug 58689] Enhance returns_nonnull
[Bug tree-optimization/84203] add -Wsuggest-attribute=returns_nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84203 Martin Sebor changed: What|Removed |Added Blocks||58689 --- Comment #2 from Martin Sebor --- I just noticed -Wsuggest-attribute=returns_nonnull mentioned in bug 58689 comment #8. I'm on the fence between resolving this as a duplicate of that bug and treating pr58689 as a meta-bug. Let me go with the latter for now and make this a blocker of it. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58689 [Bug 58689] Enhance returns_nonnull
[Bug tree-optimization/84204] New: [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84204
Bug ID: 84204
Summary: [8 Regression] [graphite] ICE in set_codegen_error, at
graphite-isl-ast-to-gimple.c:206
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20180204 snapshot (r257367) ICEs when compiling the following
snippet w/ -O1 (-O2, -O3, -Ofast) -floop-parallelize-all -fno-tree-loop-im
--param scev-max-expr-size=3:
int oc;
void
mo (int xd)
{
while (xd < 1)
{
for (oc = 0; oc < 2; ++oc)
{
}
++xd;
}
}
% gcc-8.0.0-alpha20180204 -O1 -floop-parallelize-all -fno-tree-loop-im --param
scev-max-expr-size=3 -c xknxs4ob.c
during GIMPLE pass: graphite
xknxs4ob.c: In function 'mo':
xknxs4ob.c:4:1: internal compiler error: in set_codegen_error, at
graphite-isl-ast-to-gimple.c:206
mo (int xd)
^~
0x722ef2 translate_isl_ast_to_gimple::set_codegen_error()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:205
0x723140 translate_isl_ast_to_gimple::set_codegen_error()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/tree.h:3246
0x723140 translate_isl_ast_to_gimple::get_rename_from_scev(tree_node*,
gimple**, loop*, vec)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:1101
0x1450cf9
translate_isl_ast_to_gimple::graphite_copy_stmts_from_block(basic_block_def*,
basic_block_def*, vec)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:1220
0x1451729
translate_isl_ast_to_gimple::copy_bb_and_scalar_dependences(basic_block_def*,
edge_def*, vec)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:1269
0x1451ea1
translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:829
0x1452065 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map, std::allocator > >&)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:622
0x1452339 translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:750
0x1452065 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map, std::allocator > >&)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:622
0x1452339 translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:750
0x145294c graphite_regenerate_ast_isl(scop*)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:1504
0x144eaa3 graphite_transform_loops()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite.c:413
0x144efb0 graphite_transforms
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite.c:475
0x144efb0 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite.c:552
[Bug tree-optimization/84205] New: [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84205
Bug ID: 84205
Summary: [8 Regression] [graphite] ICE in set_codegen_error, at
graphite-isl-ast-to-gimple.c:206
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu*, powerpcspe-*-linux-gnu*,
i?86-*-*
gcc-8.0.0-alpha20180204 snapshot (r257367) ICEs when compiling the following
snippet w/ -O1 (-O2, -O3, -Ofast) -floop-nest-optimize -ftree-pre
-fno-tree-loop-im for 32-bit targets:
long long unsigned int od;
int zj, fk, ea;
void
ke (void)
{
if (od != 0 && zj != 0)
{
for (fk = 0; fk < 2; ++fk)
{
}
if (od == (long long unsigned int) zj)
zj = 0;
for (ea = 0; ea < 2; ++ea)
{
}
}
}
% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180204 -O1 -floop-nest-optimize
-ftree-pre -fno-tree-loop-im -c pqp2ihnp.c
during GIMPLE pass: graphite
pqp2ihnp.c: In function 'ke':
pqp2ihnp.c:5:1: internal compiler error: in set_codegen_error, at
graphite-isl-ast-to-gimple.c:206
ke (void)
^~
0x5836ba translate_isl_ast_to_gimple::set_codegen_error()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:205
0x13fc5e5 translate_isl_ast_to_gimple::set_codegen_error()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:311
0x13fc5e5
translate_isl_ast_to_gimple::gcc_expression_from_isl_expr_int(tree_node*,
isl_ast_expr*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:308
0x13fc7e7 translate_isl_ast_to_gimple::binary_op_to_tree(tree_node*,
isl_ast_expr*, std::map,
std::allocator > >&)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:339
0x13fc7ad translate_isl_ast_to_gimple::binary_op_to_tree(tree_node*,
isl_ast_expr*, std::map,
std::allocator > >&)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:322
0x13fd3b3 translate_isl_ast_to_gimple::graphite_create_new_guard(edge_def*,
isl_ast_expr*, std::map,
std::allocator > >&)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:872
0x1400035 translate_isl_ast_to_gimple::translate_isl_ast_node_if(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:891
0x13fff65 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:858
0x140044c graphite_regenerate_ast_isl(scop*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite-isl-ast-to-gimple.c:1504
0x13fa66d graphite_transform_loops()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite.c:413
0x13fbbef graphite_transforms
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite.c:475
0x13fbbef execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/graphite.c:552
[Bug rtl-optimization/84206] New: ICE in get_all_loop_exits, at sel-sched-ir.h:1138
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84206
Bug ID: 84206
Summary: ICE in get_all_loop_exits, at sel-sched-ir.h:1138
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu, powerpcspe-*-linux-gnu
gcc-8.0.0-alpha20180204 snapshot (r257367) ICEs when compiling the following
snippet w/ -O2 -fselective-scheduling -fsel-sched-pipelining
-fsel-sched-pipelining-outer-loops -fno-forward-propagate -fno-tree-fre:
long long unsigned int ao;
int hk;
void
b8 (void)
{
int *w9;
c8:
ao = 0;
w9 = &ao;
for (;;)
for (hk = 0; hk < 1; ++hk)
for (ao = 0; ao < 4; ++ao)
{
int f4 = (ao != 0) ? *w9 : hk;
if (f4 != 0)
goto c8;
}
}
% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180204 -O2 -fselective-scheduling
-fsel-sched-pipelining -fsel-sched-pipelining-outer-loops
-fno-forward-propagate -fno-tree-fre -w -c isyp3qtx.c
during RTL pass: sched1
isyp3qtx.c: In function 'b8':
isyp3qtx.c:21:1: internal compiler error: in get_all_loop_exits, at
sel-sched-ir.h:1138
}
^
0xbf8740 get_all_loop_exits
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/sel-sched-ir.h:1138
0xbf83ae get_all_loop_exits
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/sel-sched-ir.h:1164
0xbfb7c5 _succ_iter_cond
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/sel-sched-ir.h:1302
0xbfbb2b init_seqno_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/sel-sched.c:6743
0xbfbae9 init_seqno_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/sel-sched.c:6755
0xbfbae9 init_seqno_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/sel-sched.c:6755
0xbfbfd1 init_seqno
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/sel-sched.c:6795
0xc080f1 sel_sched_region_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/sel-sched.c:7529
0xc080f1 sel_sched_region(int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/sel-sched.c:7642
0xc08841 run_selective_scheduling()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/sel-sched.c:7718
0xbdf634 rest_of_handle_sched
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/sched-rgn.c:3715
0xbdf634 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/sched-rgn.c:3825
[Bug tree-optimization/84178] [7/8 Regression] ICE in release_bb_predicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84178
--- Comment #2 from Arseny Solokha ---
Trivial change to the testcase also makes gcc-8 ICE in mark_block_for_update():
--- tt.c~ 2018-02-05 11:46:10.616358242 +0700
+++ tt.c2018-02-05 11:46:14.640320524 +0700
@@ -7,7 +7,7 @@ r8 (long int mu, int *jr, int *fi, short
{
int tx;
- tx = !!h4 ? (zy / h4) : 1;
+ tx = !!h4 ? (zy + h4) : 1;
mu = tx;
*jr = (((unsigned char) mu > (254 >> dv)) ? 0 : (unsigned char) tx) +
*fi;
} while (*jr == 0);
% gcc-8.0.0-alpha20180204 -O3 -fno-tree-forwprop -c tt.c
during GIMPLE pass: ifcvt
tt.c: In function 'r8':
tt.c:4:1: internal compiler error: Segmentation fault
r8 (long int mu, int *jr, int *fi, short int dv)
^~
0xc97d0f crash_signal
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/toplev.c:325
0xd1d788 mark_block_for_update
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/tree-into-ssa.c:449
0xd27297 mark_use_interesting
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/tree-into-ssa.c:2546
0xd27297 prepare_use_sites_for
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/tree-into-ssa.c:2711
0xd27297 prepare_names_to_update
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/tree-into-ssa.c:2779
0xd27297 update_ssa(unsigned int)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/tree-into-ssa.c:3345
0xd028aa version_loop_for_if_conversion
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/tree-if-conv.c:2594
0xd0829a tree_if_conversion(loop*)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/tree-if-conv.c:2854
0xd0a335 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/tree-if-conv.c:2962
[Bug translation/84207] New: Hard coded plural in gimple-fold.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84207 Bug ID: 84207 Summary: Hard coded plural in gimple-fold.c Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- In gimple-fold.c, size_one_node is used to build a hard coded plural rule such as in https://github.com/gcc-mirror/gcc/blob/de590a611e701935c4b3a73e78ec69c2bdfa58a1/gcc/gimple-fold.c#L1698 The rule to pluralize a word must be left to the translator.
[Bug go/68420] Errors with go escape analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68420 Ian Lance Taylor changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ian Lance Taylor --- Escape analysis is complete and as far as I know all the problems are fixed.
[Bug go/71396] "use of undefined type" error in gccgo-6 when go (1.6.1) is perfectly happy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71396 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Ian Lance Taylor --- No test case, no response to request for real test case. Closing. Please comment if you have the real test case.
[Bug go/71635] gcc-go fails to link golang-googlecode-net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71635 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Lance Taylor --- As far as I can tell this works on tip, after some symbol renaming changes. Please comment if you disagree.
[Bug go/53679] Build failure in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53679 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Ian Lance Taylor --- This has been fixed.
[Bug sanitizer/84208] New: fsanitize-address-use-after-scope Not working for ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84208 Bug ID: 84208 Summary: fsanitize-address-use-after-scope Not working for ARM Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: akhilesh.k at samsung dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Dear All I am working On gcc 6.2.1 i wan't to verify use-after-scope feature for ARM Since 6.2.1 don't support this feature I migrated this feature form 7.1 to 6.2.1. After Migration i observed that this Feature is working for My X86 but bot working one ARM target. Test results on ARM (gcc 6.2.1) bash-3.2# ./out_of_scope bash-3.2# Test results on X86 (gcc 6.2.1) bash-3.2# ./out_of_scope = ==45124==ERROR: AddressSanitizer: stack-use-after-scope on address 0xffe5b560 at pc 0x080486b5 bp 0xffe5b508 sp 0xffe5b4fc WRITE of size 1 at 0xffe5b560 thread T0 #0 0x80486b4 in main /home/abuild/rpmbuild/BUILDROOT/test2.c:10 #1 0xf70123d7 in __libc_start_main (/lib/libc.so.6+0x183d7) #2 0x8048500 (/home/abuild/rpmbuild/BUILDROOT/out_of_scope+0x8048500) Address 0xffe5b560 is located in stack of thread T0 at offset 32 in frame #0 0x80485e9 in main /home/abuild/rpmbuild/BUILDROOT/test2.c:3 This frame has 1 object(s): [32, 33) 'my_char' <== Memory access at offset 32 is inside this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: AddressSanitizer stack-use-after-scope /home/abuild/rpmbuild/BUILDROOT/test2.c:10 in main Shadow bytes around the buggy address: 0x3ffcb650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x3ffcb6a0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1[f8]f4 f4 f4 0x3ffcb6b0: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb6c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb6d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb6e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb6f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==45124==ABORTING Query 1. As per my analysis i think This feature is architecture in dependent (Please correct me if i am wrong) Thanks Akhilesh
[Bug sanitizer/84208] fsanitize-address-use-after-scope Not working for ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84208 --- Comment #1 from Andrew Pinski --- Does it work on non changed gcc 7.2 on arm? And with arm do mean arm-linux-gnueabi as the target or aarch64-linux-gnu?
