[Bug fortran/87495] Warning: ‘fastcall’ attribute ignored [-Wattributes] for !GCC$ ATTRIBUTES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495
--- Comment #4 from rguenther at suse dot de ---
On Mon, 15 Oct 2018, burnus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495
>
> Tobias Burnus changed:
>
>What|Removed |Added
>
> CC||burnus at gcc dot gnu.org
>
> --- Comment #3 from Tobias Burnus ---
> I wonder whether that's an ABI problem.
>
> At least, if I use "-m32", it compiles without warning – while -m64 shows the
> warning on my 86-64-gnu-linux.
>
> I also see the following in doc/extend.texi:
>
> @item fastcall
> @cindex @code{fastcall} function attribute, x86-32
> @cindex functions that pop the argument stack on x86-32
> On x86-32 targets, the @code{fastcall} attribute causes the compiler to
> pass the first argument (if of integral type) in the register ECX and
> the second argument (if of integral type) in the register EDX@. Subsequent
> and other typed arguments are passed on the stack. The called function
> pops the arguments off the stack. If the number of arguments is variable all
> arguments are pushed on the stack.
>
> Side note: on Microsoft's page, I do see a __fastcall for x64 Windows:
> https://msdn.microsoft.com/en-us/library/ms235286.aspx
fastcall is definitely a -m32 attribute only (on x86_64 arguments
are already passed by registers)
[Bug middle-end/87610] [6/7/8 Regression] wrong-code with restrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87610 --- Comment #4 from Richard Biener --- Author: rguenth Date: Tue Oct 16 07:28:49 2018 New Revision: 265185 URL: https://gcc.gnu.org/viewcvs?rev=265185&root=gcc&view=rev Log: 2018-10-16 Richard Biener Backport from mainline 2018-10-15 Richard Biener PR middle-end/87610 * tree-ssa-structalias.c (struct vls_data): Add escaped_p member. (visit_loadstore): When a used restrict tag escaped verify that the points-to solution of "other" pointers do not include escaped. (compute_dependence_clique): If a used restrict tag escaped communicated that down to visit_loadstore. * gcc.dg/torture/restrict-6.c: New testcase. 2018-10-01 Richard Biener PR tree-optimization/87465 * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Fix typo causing branch miscounts. * gcc.dg/tree-ssa/cunroll-15.c: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/restrict-6.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/tree-ssa/cunroll-15.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-loop-ivcanon.c branches/gcc-8-branch/gcc/tree-ssa-structalias.c
[Bug tree-optimization/87465] [8 Regression] Loop removal regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87465 --- Comment #5 from Richard Biener --- Author: rguenth Date: Tue Oct 16 07:28:49 2018 New Revision: 265185 URL: https://gcc.gnu.org/viewcvs?rev=265185&root=gcc&view=rev Log: 2018-10-16 Richard Biener Backport from mainline 2018-10-15 Richard Biener PR middle-end/87610 * tree-ssa-structalias.c (struct vls_data): Add escaped_p member. (visit_loadstore): When a used restrict tag escaped verify that the points-to solution of "other" pointers do not include escaped. (compute_dependence_clique): If a used restrict tag escaped communicated that down to visit_loadstore. * gcc.dg/torture/restrict-6.c: New testcase. 2018-10-01 Richard Biener PR tree-optimization/87465 * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Fix typo causing branch miscounts. * gcc.dg/tree-ssa/cunroll-15.c: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/restrict-6.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/tree-ssa/cunroll-15.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-loop-ivcanon.c branches/gcc-8-branch/gcc/tree-ssa-structalias.c
[Bug tree-optimization/87465] [8 Regression] Loop removal regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87465 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|ASSIGNED|RESOLVED Known to work||8.2.1 Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug demangler/87620] New: NULL deref in iterate_demangle_function (117536819)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87620 Bug ID: 87620 Summary: NULL deref in iterate_demangle_function (117536819) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: security-tps at google dot com Target Milestone: --- Created attachment 44843 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44843&action=edit artifacts Hello demangle team, As part of our fuzzing efforts at Google, we have identified an issue affecting binutils (tested with revision * master 673fe0f0a7a0624819f1b4cdc289f43691567e91 from https://sourceware.org/git/binutils-gdb.git). To reproduce, we are attaching a Dockerfile which compiles the project with LLVM, taking advantage of the sanitizers that it offers. More information about how to use the attached Dockerfile can be found here: https://docs.docker.com/engine/reference/builder/ Instructions: `unzip artifacts_117536819.zip` `docker build --build-arg SANITIZER=address --tag=autofuzz-binutils-117536819 autofuzz_117536819` `docker run --entrypoint /fuzzing/repro.sh --cap-add=SYS_PTRACE -v $PWD/autofuzz_117536819/poc-606ae8a2c7f8322fdfbbb8b89142c457f14d52dd65ae4a05becbc18619e68504_min:/tmp/poc autofuzz-binutils-117536819 "" /tmp/poc` `docker run --cap-add=SYS_PTRACE -v $PWD/autofuzz_117536819/poc-606ae8a2c7f8322fdfbbb8b89142c457f14d52dd65ae4a05becbc18619e68504_min:/tmp/poc -it autofuzz-binutils-117536819` Alternatively, and depending on the bug, you could use gcc, valgrind or other instrumentation tools to aid in the investigation. The sanitizer error that we encountered is here: ``` INFO: Seed: 3245898553 INFO: Loaded 0 modules (0 guards): /fuzzing/binutils-gdb/build/demangle_fuzzer: Running 1 inputs 500 time(s) each. Running: /tmp/poc-606ae8a2c7f8322fdfbbb8b89142c457f14d52dd65ae4a05becbc18619e68504 ASAN:DEADLYSIGNAL = ==7==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x7f3986f88676 bp 0x7ffc1870b420 sp 0x7ffc1870aba8 T0) ==7==The signal is caused by a READ memory access. ==7==Hint: address points to the zero page. #0 0x7f3986f88675 in strlen (/lib/x86_64-linux-gnu/libc.so.6+0x80675) #1 0x476d5c in __interceptor_strlen.part.31 (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x476d5c) #2 0x525619 in work_stuff_copy_to_from /fuzzing/binutils-gdb/libiberty/cplus-dem.c:1345:17 #3 0x52381f in iterate_demangle_function /fuzzing/binutils-gdb/libiberty/cplus-dem.c:2731:3 #4 0x51afe2 in internal_cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:1253:14 #5 0x519f28 in cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:918:9 #6 0x5215e2 in demangle_template_value_parm /fuzzing/binutils-gdb/libiberty/cplus-dem.c:2128:12 #7 0x51f238 in demangle_template /fuzzing/binutils-gdb/libiberty/cplus-dem.c:2313:14 #8 0x51d439 in demangle_signature /fuzzing/binutils-gdb/libiberty/cplus-dem.c:1628:14 #9 0x523876 in iterate_demangle_function /fuzzing/binutils-gdb/libiberty/cplus-dem.c:2743:14 #10 0x51afe2 in internal_cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:1253:14 #11 0x519f28 in cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:918:9 #12 0x517a1d in LLVMFuzzerTestOneInput /fuzzing/security-research-pocs/autofuzz/demangle_fuzzer.cc:11:21 #13 0x54aa3e in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x54aa3e) #14 0x53fb8e in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x53fb8e) #15 0x544097 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x544097) #16 0x53f8ab in main (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x53f8ab) #17 0x7f3986f282e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) #18 0x41f479 in _start (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x41f479) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0x80675) in strlen ==7==ABORTING ``` We will gladly work with you so you can successfully confirm and reproduce this issue. Do let us know if you have any feedback surrounding the documentation. Once you have reproduced the issue, we'd appreciate to learn your expected timeline for an update to be released. With any fix, please attribute the report to "Google Autofuzz project". We are also pleased to inform you that your project is eligible for inclusion to the OSS-Fuzz project, which can provide additional continuous fuzzing, and encourage you to investigate integration options. Don't hesitate to let us know if you have any questions! Google AutoFuzz Team
[Bug rtl-optimization/71976] insn-combiner deletes a live 64-bit shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71976 Clay McClure changed: What|Removed |Added CC||clay at daemons dot net --- Comment #12 from Clay McClure --- Georg, was this issue specific to the avr target, or could it affect other targets as well? If so, could you please give me a hint as to how I could write a failing test case on, say, x86_64?
[Bug libstdc++/87614] User related warnings are hidden in system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87614 --- Comment #3 from Jonathan Wakely --- Yes, that warning seems useful. The user has caused a conversion that alters the value. The fact it happens deep inside libstdc++ headers is only because the library templates preserve the types all the way down the call stack.
[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878 --- Comment #34 from Tamar Christina --- Sorry for the delay getting back to you Eric. So the workaround I have is basically to have a dummy program `translate_paths.c` which just prints back all arguments it receives in argv (besides the program name). This when compiled with the host compiler which is a native GCC will cause the msys2 runtime to translate the paths when they're passed to it (it doesn't do this for gnatlink because of the quotes around the arguments). So if GCC_LINK then becomes something like GCC_LINK_RAW=$(CXX) $(GCC_LINK_FLAGS) $(LDFLAGS) GCC_LINK=$(shell $(translate_paths) $(GCC_LINK_RAW)) it'll translate the paths before storing them and all is well The problem I have is where to put the compilation of translate_paths. There are plenty of usages of GCC_LINK so ideally this should be one of the first things done in the file. I tried putting it under the "Makefile" target but that didn't trigger any compilation. Maybe configure is a better place? Any suggestions?
[Bug libstdc++/87618] Missing symbol for std::__cxx11::basic_stringbuf, std::allocator >::basic_stringbuf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87618 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-16 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/87495] Warning: ‘fastcall’ attribute ignored [-Wattributes] for !GCC$ ATTRIBUTES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495 --- Comment #5 from Tobias Burnus --- Martin: Can we close this as INVALID or WORKSFORME? Or is there still an issue? - At least it seems to work for -m32 and -m64 is not supported by construction of the x86_64 ABI. (In reply to Martin Liška from comment #0) > Looks GCC ATTRIBUTES are broken: (In reply to Tobias Burnus from comment #3) > At least, if I use "-m32", it compiles without warning – while -m64 shows > the warning on my 86-64-gnu-linux. (In reply to rguent...@suse.de from comment #4) > fastcall is definitely a -m32 attribute only (on x86_64 arguments > are already passed by registers)
[Bug libstdc++/87618] [9 Regression] Missing symbol for std::__cxx11::basic_stringbuf, std::allocator >::basic_stringbuf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87618
Jonathan Wakely changed:
What|Removed |Added
Known to work||8.2.0
Summary|Missing symbol for |[9 Regression] Missing
|std::__cxx11::basic_stringb |symbol for
|uf, |uf|std::char_traits,
|>::basic_stringbuf()|std::allocator
||>::basic_stringbuf()
Known to fail||9.0
--- Comment #1 from Jonathan Wakely ---
I made a typo in the linker script:
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2035,7 +2035,7 @@ GLIBCXX_3.4.26 {
_ZNSt15basic_stringbuf[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
_ZNSt18basic_stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
_ZNSt19basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
-_ZNSt7__cxx1115basic_stringbuf[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
+_ZNSt7__cxx1115basic_stringbufI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
_ZNSt7__cxx1118basic_stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
_ZNSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
[Bug libstdc++/87618] [9 Regression] Missing symbol for std::__cxx11::basic_stringbuf, std::allocator >::basic_stringbuf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87618
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> I made a typo in the linker script:
>
> --- a/libstdc++-v3/config/abi/pre/gnu.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> @@ -2035,7 +2035,7 @@ GLIBCXX_3.4.26 {
> _ZNSt15basic_stringbuf[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
^^ And here too.
The tests for these functions are built with -O2 and so the constructor is
inlined and we didn't notice the definition isn't exported. Ouch.
[Bug libstdc++/87618] [9 Regression] Missing symbol for std::__cxx11::basic_stringbuf, std::allocator >::basic_stringbuf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87618 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug tree-optimization/87613] Non-reachable default required in switch statement to get optimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87613 Richard Biener changed: What|Removed |Added Keywords||missed-optimization CC||mliska at suse dot cz Component|c++ |tree-optimization --- Comment #1 from Richard Biener --- The optimization is fixed, the warning is spurious but it cannot be avoided if you do not either add an unreachable return or mark the unreachable path with __builtin_unreachable ().
[Bug c/87615] Possible excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 Richard Biener changed: What|Removed |Added Keywords||compile-time-hog Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-16 CC||hubicka at gcc dot gnu.org, ||jamborm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Richard Biener --- Confirmed. Looking at GCC 7 (120s compile-time) I see (-ftime-report -ftime-report-details): ipa cp : 0.19 ( 0%) usr 0.00 ( 0%) sys 0.24 ( 0%) wall 8576 kB ( 2%) ggc `- dominance computation: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc `- alias stmt walking : 76.66 (61%) usr 0.07 ( 3%) sys 76.70 (60%) wall 0 kB ( 0%) ggc GCC 8 (180s compile-time): ipa cp : 0.20 ( 0%) 0.01 ( 0%) 0.23 ( 0%) 10168 kB ( 2%) `- dominance computation : 0.02 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- ipa dead code removal : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 kB ( 0%) `- alias stmt walking : 125.65 ( 70%) 0.29 ( 13%) 125.95 ( 70%) 0 kB ( 0%) GCC 9 (240s compile-time): ipa cp : 0.33 ( 0%) 0.00 ( 0%) 0.28 ( 0%) 9657 kB ( 2%) `- dominance computation : 0.02 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- alias stmt walking : 139.23 ( 55%) 0.05 ( 2%) 139.35 ( 54%) 0 kB ( 0%) tree FRE : 49.71 ( 20%) 0.57 ( 24%) 50.25 ( 20%) 1824 kB ( 0%) `- tree CFG cleanup: 0.04 ( 0%) 0.00 ( 0%) 0.06 ( 0%) 0 kB ( 0%) `- loop fini : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 kB ( 0%) `- alias stmt walking : 0.55 ( 0%) 0.00 ( 0%) 0.58 ( 0%) 3 kB ( 0%) the FRE thing is the new value-numbering algorithm. Looks like the IPA-CP stmt walking is still unbound?
[Bug tree-optimization/87621] New: auto-vectorization fails for exponentiation code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87621
Bug ID: 87621
Summary: auto-vectorization fails for exponentiation code
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hoganmeier at gmail dot com
Target Milestone: ---
https://godbolt.org/z/bgieBT
template
T pow(T x, unsigned int n)
{
if (!n)
return 1;
T y = 1;
while (n > 1)
{
if (n%2)
y *= x;
x = x*x; // unsupported use in stmt
n /= 2;
}
return x*y;
}
void testVec(int* x)
{
// loop nest containing two or more consecutive inner loops cannot be
vectorized
for (int i = 0; i < 8; ++i)
x[i] = pow(x[i], 10);
}
[Bug tree-optimization/87621] auto-vectorization fails for exponentiation code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87621 --- Comment #1 from krux --- Interestingly it happily unrolls the loop even with -fno-unroll-loops.
[Bug c/87615] Possible excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 --- Comment #6 from Richard Biener --- Btw, compiles in 8s with -O1 which is what we suggest for machine-generated code like this.
[Bug rtl-optimization/84101] [7/8/9 Regression] -O3 and -ftree-vectorize trying too hard for function returning trivial pair-of-uint64_t-structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84101 --- Comment #4 from krux --- Also happens with pairs of floats: https://godbolt.org/z/QrP0VD
[Bug libstdc++/87618] [9 Regression] Missing symbol for std::__cxx11::basic_stringbuf, std::allocator >::basic_stringbuf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87618 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Tue Oct 16 11:14:37 2018 New Revision: 265188 URL: https://gcc.gnu.org/viewcvs?rev=265188&root=gcc&view=rev Log: PR libstdc++/87618 fix typos in linker script PR libstdc++/87618 * config/abi/pre/gnu.ver: Fix typos in patterns for basic_stringbuf. * testsuite/27_io/basic_stringbuf/cons/char/default.cc: Disable optimisation to check constructor definition can be linked to. * testsuite/27_io/basic_stringbuf/cons/wchar_t/default.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/testsuite/27_io/basic_stringbuf/cons/char/default.cc trunk/libstdc++-v3/testsuite/27_io/basic_stringbuf/cons/wchar_t/default.cc
[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878 --- Comment #35 from Eric Botcazou --- > Sorry for the delay getting back to you Eric. No problem. > So the workaround I have is basically to have a dummy program > `translate_paths.c` which just prints back all arguments it receives in argv > (besides the program name). > > This when compiled with the host compiler which is a native GCC will cause > the msys2 runtime to translate the paths when they're passed to it (it > doesn't do this for gnatlink because of the quotes around the arguments). That seems like a big hammer though and I'm not sure other Ada maintainers will really be thrilled with it... Can't we devise a kludge in the gnattools dir? IMO it would have a far better chance of being accepted than this.
[Bug middle-end/63155] [6/7/8 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #46 from Richard Biener --- Author: rguenth Date: Tue Oct 16 11:23:22 2018 New Revision: 265189 URL: https://gcc.gnu.org/viewcvs?rev=265189&root=gcc&view=rev Log: 2018-10-16 Richard Biener Backport from mainline 2018-09-18 Richard Biener PR middle-end/63155 * tree-ssa-coalesce.c (tree_int_map_hasher): Remove. (compute_samebase_partition_bases): Likewise. (coalesce_ssa_name): Always use compute_optimized_partition_bases. (gimple_can_coalesce_p): Simplify. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-coalesce.c
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86804, which changed state. Bug 86804 Summary: s390 port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86804 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/86804] s390 port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86804
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #1 from Andreas Krebbel ---
Fixed with:
Author: krebbel
Date: Thu Sep 27 08:03:42 2018
New Revision: 264663
URL: https://gcc.gnu.org/viewcvs?rev=264663&root=gcc&view=rev
Log:
S/390: Implement speculation barrier
gcc/ChangeLog:
2018-09-27 Andreas Krebbel
* config/s390/s390.md (PPA_TX_ABORT, PPA_OOO_BARRIER): New
constant definitions.
("tx_assist"): Replace magic number with PPA_TX_ABORT.
("*ppa"): Enable pattern also for -march=zEC12 -mno-htm.
("speculation_barrier"): New expander definition.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.md
[Bug fortran/87622] New: coarray does not run in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87622 Bug ID: 87622 Summary: coarray does not run in parallel Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: klein at cage dot ugent.be Target Milestone: --- I have a minimal co array program program mini implicit none real, dimension(2500,2500),codimension[*] :: a,b real, dimension(2500,2500) :: c print *, "start" !switch b and c and itworks as expected a=matmul(b,c) !Wast time print *, "end" end program mini There is no interaction between the images. Thus I expect a that running two images on two cores is as fast as running 1 image on 1 core. But there runtime doubles it seems that each image does the work of both images. Curiossly everything works as expected if I replacte matmul(b,c) by matmul(c,b). The program runs twice as fast in this case.
[Bug sanitizer/81275] [6/7 Regression] -fsanitize=thread produce incorrect -Wreturn-type warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81275
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #12 from Tom de Vries ---
(In reply to Dmitry G. Dyachenko from comment #0)
> -fsanitize={address,undefined} unaffected
FWIW, I've run into this with -fsanitize=address and gcc 7.3 (minimized from
gdb/gdbtypes.c):
...
$ cat test.c
struct i
{
unsigned int i;
};
typedef struct i si;
extern const si const1;
extern const si const2;
si
foo (int c, int d)
{
si var = { 0 };
switch (c)
{
case 1:
switch (d)
{
case 2:
return var;
default:
return const1;
}
break;
default:
return const2;
}
}
$ g++-7 -O0 test.c -c -Wreturn-type -fsanitize=address
test.c: In function ‘si foo(int, int)’:
test.c:28:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
$ g++-7 -O0 test.c -c -Wreturn-type
$
...
[Bug tree-optimization/87621] outer loop auto-vectorization fails for exponentiation code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87621 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-16 CC||rguenth at gcc dot gnu.org Blocks||53947 Summary|auto-vectorization fails|outer loop |for exponentiation code |auto-vectorization fails ||for exponentiation code Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- The issue is the unsupported reduction. We can't vectorize a x = x*x; reduction. And I don't see how we could. We could eventually vectorize the outer loop but outer loop vectorization is "confused" by the if-conversion we need to do to the inner loop. Fixing that (y *= n%2 ? x : 1) yields outer loop vectorization failure like t.ii:20:20: note: vect_is_simple_use: operand y_36 = PHI <1(3), prephitmp_27(10)>, type of def: unknown t.ii:20:20: missed: Unsupported pattern. t.ii:17:6: missed: not vectorized: unsupported use in stmt. t.ii:20:20: missed: unexpected pattern. t.ii:20:20: missed: couldn't vectorize loop that is because we "simplified" the multiplication by 1 and thus the reduction op becomes y = n%2 ? new_y : y; and appearantly we do not like this (not sure why the reduction structure is relevant for outer loop vectorization). We do not actually detect this as reduction, but we could simply identify inner loop reductions by looking for the loop-closed PHIs. So - were you expecting outer loop vectorization to happen? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878 --- Comment #36 from Tamar Christina --- > That seems like a big hammer though and I'm not sure other Ada maintainers > will really be thrilled with it... Can't we devise a kludge in the gnattools > dir? > IMO it would have a far better chance of being accepted than this. You mean the use of translate_paths? So the problem is that if we look at GCC_LINK=$(CXX) $(GCC_LINK_FLAGS) $(ADA_INCLUDES) $(LDFLAGS) Most of the paths come from $(CXX) which is normally fine as you'd use $(CXX) normally as a command, e.g. $(CXX) . When you do this the same thing happens, xgcc is a native program so it's paths get translated. You have `fix_srcfile_path` that can translate a single path, but this won't recognize multiple paths in a string, or paths to options, such as -L, so even splitting GCC_LINK by spaces and iterating over them calling fix_srcfile_path won't work. One way to fix this without needing any second program is to change how gnatlink consumes arguments, e.g. instead of --LINK="" use --LINK -- or similar. E.g. an explicit start and end marker so the options don't have to be quoted. (same for --GCC). This would also have the side benefit of allowing support for paths with spaces in them since you can now quote "" individual paths. Would this be a better approach? Or did you mean make translate_paths and put it in the "tools" folder when ../stamp-tools is created? That would probably work too.
[Bug target/87511] [9 Regression][AArch64] UBFIZ instruction with invalid immediate emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87511 --- Comment #3 from Wilco --- Author: wilco Date: Tue Oct 16 12:26:00 2018 New Revision: 265191 URL: https://gcc.gnu.org/viewcvs?rev=265191&root=gcc&view=rev Log: [AArch64] Fix PR87511 As mentioned in PR87511, the shift used in aarch64_mask_and_shift_for_ubfiz_p should be evaluated as a HOST_WIDE_INT rather than int. Backported from mainline gcc/ PR target/87511 * config/aarch64/aarch64.c (aarch64_mask_and_shift_for_ubfiz_p): Use HOST_WIDE_INT_1U for shift. testsuite/ PR target/87511 * gcc.target/aarch64/pr87511.c: Add new test. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/aarch64/aarch64.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
SAP Business One Demo at your offices
Dear Business Partner, ProCons4IT team in Lebanon is glad to schedule a demo of SAP Business One complete ERP software solution at your offices to showcase how it can help you cope with digital transformation. ProCons 4IT is the largest SAP Business One partner in Middle East and TOP 10 globally with more than 50 consultants across all its offices. SAP Business One is the ideal integrated ERP software solution on Premise or Cloud for Small to Medium companies around the world with more than 50 clients in Lebanon and 60,000 worldwide. It manages all your business from Finance, Accounting, Sales, Stock, Inventory to Warehouse, production, HR & Payroll all in one screen. Please reply to this message with your preferred date/time and will be happy to contact you asap to confirm accordingly. We look forward to meeting with you very soon. Warm Regards, ProCons 4IT Team. Run better with SAP. Run simple with SAP Business One. Procons 4 IT Al Moudir Bldg, 3^rd Floor, Jal El Dib Beirut, Lebanon Phone : +961 4 725601 (tel:+96120420725601) /2/3 www.procons-4it.com (https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.procons-4it.com%2F&data=02%7C01%7Ctarek.hamdan%40procons-4it.com%7Ccdcba7b8ef6b4cebf7ea08d62e778721%7C5cab5bf6d1834be397b42a5ff8c5d330%7C1%7C0%7C636747488251771984&sdata=QhHZaB%2BjUNdyzzbdvFQYzNgmVSas8qlaw1VbNSXvPyU%3D&reserved=0) ProCons sap SAP Master Value Added Reseller (VAR) Lebanon, Dubai, KSA, Kuwait, Qatar, Oman sap To Stop Receiving our email please reply with REMOVE You received this email because you are in GFC.media (https://gfc.media/) newsletter list This email was sent to gcc-bugs@gcc.gnu.org (mailto:gcc-bugs@gcc.gnu.org) why did I get this? (https://battleparkae.us19.list-manage.com/about?u=90bac0906b280fc6945d7b273&id=4a9f8b0547&e=9a0a13d120&c=f9bb640b61) unsubscribe from this list (https://battleparkae.us19.list-manage.com/unsubscribe?u=90bac0906b280fc6945d7b273&id=4a9f8b0547&e=9a0a13d120&c=f9bb640b61) update subscription preferences (https://battleparkae.us19.list-manage.com/profile?u=90bac0906b280fc6945d7b273&id=4a9f8b0547&e=9a0a13d120) BP AE . UAE . Dubai . United Arab Emirates
[Bug middle-end/63155] [6/7/8 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #47 from Richard Biener --- Author: rguenth Date: Tue Oct 16 13:23:56 2018 New Revision: 265193 URL: https://gcc.gnu.org/viewcvs?rev=265193&root=gcc&view=rev Log: 2018-10-16 Richard Biener Backport from mainline 2018-10-08 Richard Biener PR tree-optimization/63155 * tree-ssa-propagate.c (add_ssa_edge): Do cheap check first. (ssa_propagation_engine::ssa_propagate): Remove redundant bitmap bit clearing. 2018-10-05 Richard Biener PR tree-optimization/63155 * tree-ssa-ccp.c (ccp_propagate::visit_phi): Avoid excess vertical space in dumpfiles. * tree-ssa-propagate.h (ssa_propagation_engine::process_ssa_edge_worklist): Remove. * tree-ssa-propagate.c (cfg_blocks_back): New global. (ssa_edge_worklist_back): Likewise. (curr_order): Likewise. (cfg_blocks_get): Remove abstraction. (cfg_blocks_add): Likewise. (cfg_blocks_empty_p): Likewise. (add_ssa_edge): Add to current or next worklist based on RPO index. (add_control_edge): Likewise. (ssa_propagation_engine::process_ssa_edge_worklist): Fold into ... (ssa_propagation_engine::ssa_propagate): ... here. Unify iteration from CFG and SSA edge worklist so we process everything in RPO order, prioritizing forward progress over iteration. (ssa_prop_init): Allocate new worklists, do not dump immediate uses. (ssa_prop_fini): Free new worklists. 2018-09-24 Richard Biener PR tree-optimization/63155 * tree-ssa-propagate.c (add_ssa_edge): Avoid adding PHIs to the worklist when the edge of the respective argument isn't executable. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-propagate.c
[Bug tree-optimization/87465] [8 Regression] Loop removal regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87465 --- Comment #7 from Richard Biener --- Author: rguenth Date: Tue Oct 16 13:25:43 2018 New Revision: 265194 URL: https://gcc.gnu.org/viewcvs?rev=265194&root=gcc&view=rev Log: 2018-10-16 Richard Biener PR tree-optimization/87465 * gcc.dg/tree-ssa/cunroll-15.c: Fix pattern. Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.dg/tree-ssa/cunroll-15.c
[Bug target/87511] [9 Regression][AArch64] UBFIZ instruction with invalid immediate emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87511 --- Comment #4 from Wilco --- Author: wilco Date: Tue Oct 16 13:40:57 2018 New Revision: 265195 URL: https://gcc.gnu.org/viewcvs?rev=265195&root=gcc&view=rev Log: [AArch64] Fix PR87511 As mentioned in PR87511, the shift used in aarch64_mask_and_shift_for_ubfiz_p should be evaluated as a HOST_WIDE_INT rather than int. Backported from mainline gcc/ PR target/87511 * config/aarch64/aarch64.c (aarch64_mask_and_shift_for_ubfiz_p): Use HOST_WIDE_INT_1U for shift. testsuite/ PR target/87511 * gcc.target/aarch64/pr87511.c: Add new test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/aarch64/pr87511.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/aarch64/aarch64.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug target/87511] [9 Regression][AArch64] UBFIZ instruction with invalid immediate emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87511 Wilco changed: What|Removed |Added Status|NEW |RESOLVED Version|9.0 |7.3.1 Resolution|--- |FIXED --- Comment #5 from Wilco --- Fixed on trunk, gcc8 and gcc7, so closing as resolved.
[Bug c/87615] Possible excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 --- Comment #7 from Jan Hubicka --- > Looks like the IPA-CP stmt walking is still unbound? There is also walking in ipa-fnsummary that is unbound, perhaps that is the problem... Honza
[Bug c++/87602] Integer Overflow in cplus-dem.c in c++filt in bintuils which leads to Undefined-behavior(OOM in this POC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87602
--- Comment #2 from Cheng Wen ---
I have further analyzed this bug. The variable n in function get_count (const
char **type, int *count) have an Integer overflow problem. The value pass to
the variable count.
> do
> {
> n *= 10;
> n += *p - '0';
> p++;
> }
> while (ISDIGIT ((unsigned char)*p));
> if (*p == '_')
> {
> *type = p + 1;
> *count = n;
> }
After that in XNEWVEC (char *, r); pass the *count as parameter
> work->tmpl_argvec = XNEWVEC (char *, r);
Finally malloc the negative size in /libiberty/./xmalloc.c:147:12.
[Bug tree-optimization/87621] outer loop auto-vectorization fails for exponentiation code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87621 --- Comment #3 from krux --- Yes see the godbolt link. clang compiles it down to a few vpmulld's.
[Bug c++/60364] [[noreturn]] specified for second declaration but not first doesn't result in a diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60364 --- Comment #4 from Martin Sebor --- *** Bug 84352 has been marked as a duplicate of this bug. ***
[Bug c++/84352] noreturn function previously declared without the attribute accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84352 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Sebor --- This is a duplicate of pr60364. *** This bug has been marked as a duplicate of bug 60364 ***
[Bug tree-optimization/87623] New: bytes swapped in register when comparing cause fail when comiled with -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87623
Bug ID: 87623
Summary: bytes swapped in register when comparing cause fail
when comiled with -O1 or higher
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: george.thopas at gmail dot com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
Build: gcc version 8.2.0 (Gentoo 8.2.0-r3 p1.4)
- Compare of two single char fields in two structures with different
scalar_storage_order order goes wrong. Reduced test case below.
- Observed in 6.3.1 and reproducible in 8.2.0 , Target x86_64-pc-linux-gnu
---[howto]
passed test:
$ gcc -O0 test.c
$ ./a.out
failed test:
$ gcc -O1 test.c
$ ./a.out
Aborted
-- [code]
/* test.c */
#include
struct be {
unsigned short pad[1];
unsigned char a;
unsigned char b;
} __attribute__((scalar_storage_order("big-endian")));
typedef struct be t_be;
struct le {
unsigned short pad[3];
unsigned char a;
unsigned char b;
};
typedef struct le t_le;
int a_or_b_different(t_be *x,t_le *y)
{
return ((x->a != y->a) ||
(x->b != y->b));
}
int main(int argc,char *argv[])
{
t_be x = { .a=1, .b=2 };
t_le y = { .a=1, .b=2 };
if (a_or_b_different(&x,&y))
abort();
return 0;
}
--
jbeu@bt9923 ~ $ gcc -v -O1 test.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/8.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 8.2.0-r3 p1.4' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap
--enable-vtable-verify --enable-libvtv --enable-lto --without-isl
--enable-libsanitizer --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 8.2.0 (Gentoo 8.2.0-r3 p1.4)
COLLECT_GCC_OPTIONS='-v' '-O1' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/cc1 -quiet -v bug.c -quiet
-dumpbase bug.c -mtune=generic -march=x86-64 -auxbase bug -O1 -version -o
/tmp/ccdpdLOi.s
GNU C17 (Gentoo 8.2.0-r3 p1.4) version 8.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
/usr/include
End of search list.
GNU C17 (Gentoo 8.2.0-r3 p1.4) version 8.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 91d4bd0e38b68a0f50315f89ba003c77
COLLECT_GCC_OPTIONS='-v' '-O1' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/as
-v --64 -o /tmp/ccsw11XW.o /tmp/ccdpdLOi.s
GNU assembler version 2.31.1 (x86_64-pc-linux-gnu) using BFD version (Gentoo
2.31.1 p3) 2.31.1
COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../
[Bug ipa/87624] New: improve interprocedural clean up of null pointer checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87624
Bug ID: 87624
Summary: improve interprocedural clean up of null pointer
checks
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
On the following example the 'p' argument in 'f' can be proven to be nonnull.
In practice this should help to clean up null pointer checks that become
redundant in LTO mode.
Is that something IPA-VRP could handle? I think currently it doesn't work
because there isn't a separate SSA name under the check that can be recorded to
be non-null?
void g(void);
__attribute__((noinline))
static void f(void *p)
{
if (!p)
g();
}
void h(void *p1, void *p2)
{
if (p1)
f(p1);
if (p2)
f(p2);
}
[Bug c++/84705] [6/7/8/9 Regression] internal compiler error: in add_stmt, at cp/semantics.c:390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84705 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #4 from Paolo Carlini --- This is basically fixed in mainline, but we emit a duplicate diagnostic about the static_cast, I'm fixing that too.
[Bug fortran/87556] FORM TEAM statement team-number argument interpreted incorrectly when function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87556 --- Comment #2 from Tobias Burnus --- Author: burnus Date: Tue Oct 16 18:32:11 2018 New Revision: 265211 URL: https://gcc.gnu.org/viewcvs?rev=265211&root=gcc&view=rev Log: Handle form_team w/ function args PR fortran/87556 * trans-stmt.c (form_team, change_team, sync_team): Don't ignore argse.pre/argse.post. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c
[Bug fortran/67125] Incorrect bounds with source allocation, source=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67125 --- Comment #4 from Tobias Burnus --- Author: burnus Date: Tue Oct 16 18:37:08 2018 New Revision: 265212 URL: https://gcc.gnu.org/viewcvs?rev=265212&root=gcc&view=rev Log: Fix bounds with ALLOCATE with source-expr PR fortran/67125 * trans-array.c (gfc_array_init_size, gfc_array_allocate): Rename argument e3_is_array_constr to e3_has_nodescriptor and update comments. * trans-stmt.c (gfc_trans_allocate): Also fix lower bound to 1 for nonalloc/nonpointer func results/vars besides array constructors. PR fortran/67125 * gfortran.dg/allocate_with_source_26.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/allocate_with_source_26.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/87625] New: [OOP] (re)allocate on assignment fails for polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87625 Bug ID: 87625 Summary: [OOP] (re)allocate on assignment fails for polymorphic array Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: pault at gcc dot gnu.org Target Milestone: --- I believe the following code should work and (re)allocate "var" when it gets assigned a constructor. However, there is no memory allocation done at all. It looks as if the allocatable attribute is not correctly checked for for "CLASS" variables. [If one manually allocates the variable, it works. As it does if one uses TYPE instead of CLASS.] implicit none type t integer :: i end type t class(t), allocatable :: var(:) call poly_init() print *, var(:)%i if (var(1)%i /= 11 .or. var(2)%i /= 12) call abort() contains subroutine poly_init() !allocate(var(2)) var = [t :: t(11), t(12)] end subroutine poly_init end
[Bug c/87626] New: Named address spaces don't work in standard-conforming mode, but macros for them are defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87626 Bug ID: 87626 Summary: Named address spaces don't work in standard-conforming mode, but macros for them are defined Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bugdal at aerifal dot cx Target Milestone: --- When invoked in standards conforming mode, e.g. -std=c99, gcc on x86 defined __SEG_FS and __SEG_GS but they __seg_fs and __seg_gs keywords do not work and produce errors. This is because c/c-decl.c: c_register_addr_space explicitly refuses to register the keyword if flag_no_asm is set, presumably because some targets define address space names that are not in the reserved namespace. Either the macros __SEG_* should be suppressed when the functionality they represent is not available, or it should be fixed to work in all cases. I would highly prefer the latter. A simple fix would be only returning without doing anything if word[0]!='_'||word[1]!='_'. A better fix might be automatically registering the __-prefixed version if word itself is not __-prefixed, and registering both when flag_no_asm is not set.
[Bug fortran/67125] Incorrect bounds with source allocation, source=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67125 --- Comment #5 from Tobias Burnus --- Author: burnus Date: Tue Oct 16 21:07:31 2018 New Revision: 265215 URL: https://gcc.gnu.org/viewcvs?rev=265215&root=gcc&view=rev Log: Extend source-expr test case PR fortran/67125 * gfortran.dg/allocate_with_source_26.f90: Extend testcase with polymorphic variables. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/allocate_with_source_26.f90
[Bug fortran/87625] [OOP] (re)allocate on assignment fails for polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87625
--- Comment #1 from Tobias Burnus ---
gfc_is_reallocatable_lhs() is not working:
/* An allocatable class variable with no reference. */
if (sym->ts.type == BT_CLASS
&& !sym->attr.associate_var
&& CLASS_DATA (sym)->attr.allocatable
&& expr->ref && expr->ref->type == REF_COMPONENT
&& strcmp (expr->ref->u.c.component->name, "_data") == 0
&& expr->ref->next == NULL)
return true;
And we have:
(gdb) p expr1->ts.u.derived->components->attr.allocatable
$19 = 1
(gdb) p *expr1->ref
$23 = {type = REF_ARRAY, u = {ar = {type = AR_FULL, dimen = 1, next = 0x0}
[Bug libstdc++/85494] implementation of random_device on mingw is useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85494 --- Comment #5 from Jonathan Wakely --- Proposed patch posted to https://gcc.gnu.org/ml/libstdc++/2018-10/msg00082.html I would be grateful for any testing you can do on mingw targets.
[Bug target/87627] New: GCC generates rube-goldberg machine for trivial tail call on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627
Bug ID: 87627
Summary: GCC generates rube-goldberg machine for trivial tail
call on 32-bit x86
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
Simple test case:
extern void bar();
extern void bah(int, int, int);
void foo(int a, int b, int c)
{
bar();
bah(a, b, c);
}
Expected output:
subl $12, %esp
call bar
addl $12, %esp
jmp bah
Actual:
pushl %edi
pushl %esi
pushl %ebx
movl 16(%esp), %ebx
movl 20(%esp), %esi
movl 24(%esp), %edi
call bar
movl %edi, 24(%esp)
movl %esi, 20(%esp)
movl %ebx, 16(%esp)
popl %ebx
popl %esi
popl %edi
jmp bah
I'm not clear on whether GCC is unaware that the argument space belongs to the
callee and is preserved across calls, or whether it somehow thinks using
call-saved registers is more optimal in typical cases and is missing the
trivial reason why it's not here.
[Bug target/87627] GCC generates rube-goldberg machine for trivial tail call on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627 --- Comment #1 from Rich Felker --- Results are similarly bad for 64-bit, except at -Os where it effectively just pushes/pops the argument registers around the call to bar rather than allocating call-saved registers for them. Using -Os on 32-bit does not help. -O0 does suppress the register shuffling but also suppresses the tail call.
[Bug target/87627] GCC generates rube-goldberg machine for trivial tail call on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627 --- Comment #2 from Rich Felker --- Further trial-and-error shows that it seems to be the sibcall itself that causes the mess. My first guess is that something in the RTL considers the whole argument area as clobbered/belonging to the sibcallee as soon as it starts setting up for the sibcall, thereby forcing the arguments to be backed up somewhere else and restored, but I'm not sure why that wouldn't affect the case where there's no intervening call.
[Bug target/83868] i386: Clean up thunk function generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83868 --- Comment #3 from Eric Gallager --- (In reply to H.J. Lu from comment #2) > (In reply to Eric Gallager from comment #1) > > (In reply to H.J. Lu from comment #0) > > > output_indirect_thunk_function and ix86_code_end should be generated > > > the way in which normal thunks are output from middle-end. > > > > Which way is that? > > See: > > https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01357.html Oh right I should have remembered that thread because it was TARGET_MACHO
[Bug libstdc++/87618] [9 Regression] Missing symbol for std::__cxx11::basic_stringbuf, std::allocator >::basic_stringbuf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87618 --- Comment #4 from Daniel Scharrer --- Thanks, everything works for me now.
[Bug c++/87628] New: Redundant check of pointer when delete is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87628
Bug ID: 87628
Summary: Redundant check of pointer when delete is called
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
https://godbolt.org/z/DY9ruv
void if_delete(char *p) {
if (p) {
delete(p);
}
}
$ gcc-8.2 -Os -fno-exceptions
if_delete(char*):
test rdi, rdi
je .L1
mov esi, 1
jmp operator delete(void*, unsigned long)
.L1:
ret
While clang removes the check at -Oz:
$ clang -Oz -fno-exceptions
if_delete(char*):
jmp operator delete(void*)
[Bug target/87627] GCC generates rube-goldberg machine for trivial tail call on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #3 from Alexander Monakov --- Noticed this back when working on -fno-plt patches: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00229.html Emitting a tailcall on RTL drops REG_EQUIV notes (perhaps because in the general case equivalences might not hold just before the sibcall when the new arguments are being prepared), and this penalizes code generation for the whole function. I'm not sure why you say "Results are similarly bad for 64-bit", there's nothing to improve in this example with three arguments all of which are on registers and thus need to be somehow saved/restored anyway?
