[Bug target/93037] New: Slow 'while' loop unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93037 Bug ID: 93037 Summary: Slow 'while' loop unrolling Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hehaochen at hotmail dot com Target Milestone: --- Created attachment 47538 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47538&action=edit Adobe_C++Benchmarks Compile and run 'loop unroll test' in Adobe C++ benchmark (https://stlab.adobe.com/performance/). We find slowdown in GCC-8(docker) when adding '-O3': ╔╦═╦═╦═╦══╗ ║ Total absolute execution time (sec.) ║ O1 ║ O2 ║ O3 ║ comments ║ ╠═╦══╬═╬═╬═╬══╣ ║ gcc-8 ║ int32_t for loop unrolling ║ 259 ║ 167 ║ 149 ║ ok ║ ║ ╠══╬═╬═╬═╬══╣ ║ ║ int32_t while loop unrolling ║ 257 ║ 164 ║ 204 ║ SLOW ║ ╠═╬══╬═╬═╬═╬══╣ ║ clang-6 ║ int32_t for loop unrolling ║ 326 ║ 206 ║ 181 ║ ok ║ ║ ╠══╬═╬═╬═╬══╣ ║ ║ int32_t while loop unrolling ║ 347 ║ 206 ║ 181 ║ ok ║ ╚═╩══╩═╩═╩═╩══╝ The this performance issue do not occur in 'for' loop unrolling test or clang either.
[Bug ipa/93015] [10 Regression] Segmentation fault (ipcp_store_vr_results(void))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93015 --- Comment #4 from Martin Jambor --- Author: jamborm Date: Sat Dec 21 11:25:05 2019 New Revision: 279695 URL: https://gcc.gnu.org/viewcvs?rev=279695&root=gcc&view=rev Log: Avoid segfault when doing IPA-VRP but not IPA-CP (PR 93015) 2019-12-21 Martin Jambor PR ipa/93015 * ipa-cp.c (ipcp_store_vr_results): Check that info exists testsuite/ * gcc.dg/lto/pr93015_0.c: New test. Added: trunk/gcc/testsuite/gcc.dg/lto/pr93015_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c trunk/gcc/testsuite/ChangeLog
[Bug c++/93028] internal compiler error: in write_type, at cp/mangle.c:2073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93028 --- Comment #3 from Colin H Close --- Created attachment 47539 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47539&action=edit Shell script containing compiler commands
[Bug c++/93028] internal compiler error: in write_type, at cp/mangle.c:2073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93028 --- Comment #4 from Colin H Close --- Here's a new link for the sources (much reduced in size) Which have been massaged to make them more portable. https://drive.google.com/file/d/13KecN2DjtNsO2i3oJDhFoaUv06CoP6OB/view?usp=sharing Untar the archive, copy the new shell script to the directory above that of the source directory. The new shell script requires the path to the top level directory of the sources as it's argument (The directory in which you untarred the sources). You may need to install some basic linux development packages to satisfy any missing includes. I hope there's now enough input to allow you to chase this one dowm.
[Bug c/93031] Wish: When the underlying ISA does not force pointer alignment, option to make GCC not assume it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93031 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- That must be the most well-written report I've seen so far sacrificed to the God of Unfairly Closed Bugreports. Note that GCC aims to allow partial overlap for situations when alignment
[Bug analyzer/58237] gcc fails to detect obvious resource leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58237 --- Comment #9 from David Malcolm --- (In reply to David Malcolm from comment #7) [...] > (there are some issues with the paths, where some of the events aren't being > printed, presumably due to having UNKNOWN_LOCATION; will investigate) Fixed on branch by: * "[PATCH 1/2] (analyzer) tree-diagnostic-path.cc: properly handle ad-hoc wrappers of UNKNOWN_LOCATION" * https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01471.html * "[PATCH 2/2] analyzer: fix tests for UNKNOWN_LOCATION" * https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01472.html
[Bug d/93038] New: Missing dependencies in depfile for imported files at compilation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93038
Bug ID: 93038
Summary: Missing dependencies in depfile for imported files at
compilation time
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: bouvier.pierrick at yahoo dot fr
Target Milestone: ---
Dear GDC developers,
when gdc is used to generate a depfile (make format), if code uses feature
import(file), file is not reported in list of dependencies.
I tested with gdc-{8,9,10}.
# cat main.d
import std.stdio;
void main() { writeln(import(".bashrc")); }
# gdc main.d -J. -MMD
# cat main.deps
main.o: main.d
Until version 8, gdc has support for fdeps option. Problem is that format used
(dictated by dmd) is useless in Make/Ninja build systems.
# gdc-8 -fdeps main.d -J.
...
depsFile main (main.d) : .bashrc (/home/user/.bashrc)
...
I build my code using meson project, which relies on depfiles created by
compiler. Thus, a dependency is missed.
Would that be possible to add file imported at compilation time in list of
dependencies? Technically, I think this file is not read at same time than
other import, but I still think that would be a great add to gdc.
Thank you,
Pierrick
[Bug target/93039] New: Fails to use SSE bitwise ops for float-as-int manipulations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93039
Bug ID: 93039
Summary: Fails to use SSE bitwise ops for float-as-int
manipulations
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
(the non-regression part of PR 92905)
libm functions need to manipulate individual bits of float/double
representations with good efficiency, but on x86 gcc typically does them on
gprs even when it results in sse-gpreg-sse move chain:
float foo(float x)
{
union {float f; unsigned i;} u = {x};
u.i &= ~0x8000;
return u.f;
}
foo:
movdeax, xmm0
and eax, 2147483647
movdxmm0, eax
ret
It's good to use bitwise ops on general registers if the source or destination
needs to be in a general registe, but for cases like the above creating a
roundtrip is not desirable.
(GCC gets this example right on aarch64; LLVM on x86 compiles this to SSE/AVX
bitwise 'and', taking the immediate from memory)
[Bug target/92905] [10 Regression] Spills float-int union to memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905 --- Comment #8 from Alexander Monakov --- (In reply to Alexander Monakov from comment #0) > Eventually it would be nicer to use SSE bitwise operations for this, for > example LLVM already generates > f: > orps.LCPI0_0(%rip), %xmm0 This is now reported separately as PR 93039.
[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #2 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #0)
> Currently GCC considers the 'inline' keyword as a hint for inlining, not
> just a request for comdat semantics.
>
> This is a problem in C++20 where arbitrarily complex functions are marked
> 'constexpr' so that they can be used at compile time, and a constexpr
> function is implicitly an inline function. But we do not want the function
> to get additional weighting for runtime optimizations just because it is
> eligible for use in compile-time constant expressions.
>
> It would be useful to have a new attribute that tells the inliner to ignore
> whether the function is 'inline' and only consider its size, use in hot/cold
> regions etc.
>
> Alternatively, do not interpret 'constexpr' on its own as an inlining hint,
> and only treat it as a hint when a constexpr function is explicitly declared
> with the 'inline' specifier (or is defined in the class body).
>
I would prefer this second approach.
>
> constexpr void f() { } // not an inline hint
> constexpr inline void g() { } // inline hint
> inline constexpr void h() { } // inline hint
>
> struct X {
> constexpr void i() { } // inline hint
> };
[Bug fortran/91661] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91661 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #6 from Thomas Koenig --- (In reply to anlauf from comment #5) > (In reply to anlauf from comment #4) > > Given the clumsiness to circumvent the issue with type-bound procedures, > > I feel that the simplifications involved should be done at an earlier stage. > > Anybody knows where that might be? > > My feeling was right: it appears that Tobias' fix for PR92996 (r279638) > collaterally fixed this one, too! > > Add a testcase and close? Sounds good. Incidentally, I suspect that this commit fixed quite a few other bugs, so I will do some testing on bugs that I suspect may be similar.
[Bug target/93039] Fails to use SSE bitwise ops for float-as-int manipulations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93039 Marc Glisse changed: What|Removed |Added Target||x86_64-*-* --- Comment #1 from Marc Glisse --- This looks related to Bug 54716 (which was restricted to vectors).
[Bug fortran/92753] [9/10 Regression] ICE in gfc_trans_call, at fortran/trans-stmt.c:392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92753 --- Comment #9 from Paul Thomas --- Author: pault Date: Sat Dec 21 16:19:42 2019 New Revision: 279696 URL: https://gcc.gnu.org/viewcvs?rev=279696&root=gcc&view=rev Log: 2019-12-21 Paul Thomas PR fortran/92753 * expr.c (find_inquiry_ref): Catch INQUIRY_LEN case, where the temporary expression has been converted to a constant and make the new expression accordingly. Correct the error in INQUIRY_RE and INQUIRY_IM cases. The original rather than the resolved expression was being used as the source in mpfr_set. 2019-12-21 Paul Thomas PR fortran/92753 * gfortran.dg/inquiry_type_ref_5.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/inquiry_type_ref_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug c/93031] Wish: When the underlying ISA does not force pointer alignment, option to make GCC not assume it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93031
--- Comment #3 from Pascal Cuoq ---
@amonakov
The two blog posts below exist themselves, and describe tools that exist,
because software that makes misaligned access exists, although it seems to
be a “examples too numerous to list” situation (or, more optimistically,
perhaps one where the source code is fixed upstream as problems are found).
https://blogs.oracle.com/d/on-misaligned-memory-accesses
https://blog.quarkslab.com/unaligned-accesses-in-cc-what-why-and-solutions-to-do-it-properly.html
(In the end it's the binary executable that doesn't work, and both
posts deal with that aspect at some point, but these executables were
not written in SPARC or respectively ARM assembly. If they had been,
they would have been written to work. Instead, they were written in a
higher-level language that was translated to SPARC/ARM assembly,
presumably C.)
For a specific example, fifteen minutes of looking around knowing what
one is looking for turns up the LZO implementation from
http://www.oberhumer.com/opensource/lzo/ . In the latest
version to date, 2.10:
#if (LZO_ARCH_ALPHA)
# define LZO_OPT_AVOID_UINT_INDEX 1
#elif (LZO_ARCH_AMD64)
# define LZO_OPT_AVOID_INT_INDEX 1
# define LZO_OPT_AVOID_UINT_INDEX 1
# ifndef LZO_OPT_UNALIGNED16
# define LZO_OPT_UNALIGNED16 1
# endif
# ifndef LZO_OPT_UNALIGNED32
# define LZO_OPT_UNALIGNED32 1
# endif
# ifndef LZO_OPT_UNALIGNED64
# define LZO_OPT_UNALIGNED64 1
# endif
#elif (LZO_ARCH_ARM)
# if defined(__ARM_FEATURE_UNALIGNED)
# if ((__ARM_FEATURE_UNALIGNED)+0)
#ifndef LZO_OPT_UNALIGNED16
#define LZO_OPT_UNALIGNED16 1
#endif
#ifndef LZO_OPT_UNALIGNED32
#define LZO_OPT_UNALIGNED32 1
#endif
# endif
# elif 1 && (LZO_ARCH_ARM_THUMB2)
...
#if (LZO_OPT_UNALIGNED32)
LZO_COMPILE_TIME_ASSERT_HEADER(sizeof(*(lzo_memops_TU4p)0)==4)
#define LZO_MEMOPS_COPY4(dd,ss) \
* (lzo_memops_TU4p) (lzo_memops_TU0p) (dd) = * (const lzo_memops_TU4p)
(const lzo_memops_TU0p) (ss)
#elif defined(lzo_memops_tcheck__)
#define LZO_MEMOPS_COPY4(dd,ss) \
LZO_BLOCK_BEGIN if (lzo_memops_tcheck__(lzo_memops_TU4,4,1)) { \
* (lzo_memops_TU4p) (lzo_memops_TU0p) (dd) = * (const lzo_memops_TU4p)
(const lzo_memops_TU0p) (ss); \
} else { LZO_MEMOPS_MOVE4(dd,ss); } LZO_BLOCK_END
#else
#define LZO_MEMOPS_COPY4(dd,ss) LZO_MEMOPS_MOVE4(dd,ss)
#endif
...
It is good news that this particular piece of software is already
designed to work on compilation platforms where misaligned accesses
are forbidden. But if anyone compiles it today with GCC for amd64 or
for “__ARM_FEATURE_UNALIGNED”, they are at risk of an optimization
firing and making the library not work as intended, perhaps in obscure
cases with safety or security implications.
I will state, despite the risk of tedious repetition, that the LZO
implementation invokes Undefined Behavior. I know it, Oberhumer
clearly knows it, and anyone who has read this far knows it. However
the perception of some GCC users (not me!) may be that GCC is once
again changing the rules and taking an Undefined Behavior that would
obviously never cause an actual demon to come out of one's nose, such
as a source file missing a final newline, and changing it into
one that does.
[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008 --- Comment #3 from Jonathan Wakely --- (In reply to Eric Gallager from comment #2) > I would prefer this second approach. The downside of it is that it requires adding a keyword that the standard says is completely redundant, in order to get compiler-specific behaviour. It's not clear why it's there, or if it's OK to remove it. A compiler-specific attribute obviously has compiler-specific effects.
[Bug fortran/92753] [9/10 Regression] ICE in gfc_trans_call, at fortran/trans-stmt.c:392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92753 --- Comment #10 from Paul Thomas --- Author: pault Date: Sat Dec 21 18:21:21 2019 New Revision: 279697 URL: https://gcc.gnu.org/viewcvs?rev=279697&root=gcc&view=rev Log: 2019-12-21 Paul Thomas PR fortran/92753 * expr.c (find_inquiry_ref): Catch INQUIRY_LEN case, where the temporary expression has been converted to a constant and make the new expression accordingly. Correct the error in INQUIRY_RE and INQUIRY_IM cases. The original rather than the resolved expression was being used as the source in mpfr_set. 2019-12-21 Paul Thomas PR fortran/92753 * gfortran.dg/inquiry_type_ref_5.f90 : New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/inquiry_type_ref_5.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/expr.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/92753] [9/10 Regression] ICE in gfc_trans_call, at fortran/trans-stmt.c:392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92753 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Paul Thomas --- Fixed on both branches. Thanks for the report. Paul
[Bug target/92999] [armhf] struct with adjacent __fp16's copies wrongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92999 --- Comment #1 from Jim Rees --- Reproduced on gcc-9.2 and figured out a fix, though I'm not savvy enough with this code to say it's a complete fix. In (gcc-9.2.0 release) gcc/config/arm/arm.c: 6226a6227 > int ag_mode_size; 6241c6242,6243 < shift = GET_MODE_SIZE(ag_mode) / GET_MODE_SIZE(SFmode); --- > ag_mode_size = MAX (GET_MODE_SIZE (ag_mode), GET_MODE_SIZE (SFmode)); > shift = ag_mode_size / GET_MODE_SIZE(SFmode); Prior to the patch, shift becomes 0 when ag_mode is HFmode, which is what causes every field of the struct to get mapped to the same floating-point register.
[Bug fortran/93026] gfortran.dg/goacc/finalize-1.f – FAILs since r279626
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93026
Thomas Schwinge changed:
What|Removed |Added
Keywords||openacc
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2019-12-21
CC||jules at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot
gnu.org
Summary|gfortran.dg/goacc/finalize- |gfortran.dg/goacc/finalize-
|1.f – FAILs since r279531 |1.f – FAILs since r279626
Ever confirmed|0 |1
--- Comment #1 from Thomas Schwinge ---
(In reply to Tobias Burnus from comment #0)
| Summary: gfortran.dg/goacc/finalize-1.f – FAILs since r279531
No, that used to PASS as of r279531.
It FAILs since r279626 "OpenACC 2.6 deep copy: middle-end parts", because that
commit is doing more than just the OpenACC 2.6 manual deep copy changes; see
the 'gcc/gimplify.c' changes related to the PR92929 discussion.
> Commit r279531 [...] added
> !$ACC EXIT DATA FINALIZE DELETE (del_f_p(2:5))
> !$ACC EXIT DATA COPYOUT (cpo_f_p(4:10)) FINALIZE
>
> And associated
>dg-final { scan-tree-dump-times
>
> However, they currently fails [...]
> #pragma omp target oacc_enter_exit_data map(delete:MEM[(c_char *)_10] [len:
> D.3954]) finalize
> #pragma omp target oacc_enter_exit_data map(force_from:MEM[(c_char *)_20]
> [len: D.3962]) finalize
For now, I'll commit the obvious patch, to make it PASS again.
[Bug middle-end/92929] OpenACC/OpenMP 'target' 'exit data'/'update' optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92929 --- Comment #4 from Thomas Schwinge --- The recent r279626 "OpenACC 2.6 deep copy: middle-end parts" contains changes related to this (which caused PR93026). Would've been good to first sort out the desired behavior (this PR92929) before introducing new functionality (OpenACC 2.6 manual deep copy) that supposedly depends on these optimizations? In particular, this needs careful attention, because we have to stay ABI compatible with existing GCC releases: libgomp needs to do the right things for both the "old" and the "new" way. (I'm not claiming that it isn't -- just that it needs careful attention.)
[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008 --- Comment #4 from Eric Gallager --- (In reply to Jonathan Wakely from comment #3) > (In reply to Eric Gallager from comment #2) > > I would prefer this second approach. > > The downside of it is that it requires adding a keyword that the standard > says is completely redundant, in order to get compiler-specific behaviour. > It's not clear why it's there, or if it's OK to remove it. > > A compiler-specific attribute obviously has compiler-specific effects. As someone who likes redundancy when it's done for the benefit of explicitness, I don't necessarily see that as a downside.
[Bug fortran/92990] INVALID code with NULLIFY – partially misleading error message "If bounds remapping is specified at (1), the pointer target shall not be NULL"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92990 --- Comment #3 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sat Dec 21 20:25:43 2019 New Revision: 279698 URL: https://gcc.gnu.org/viewcvs?rev=279698&root=gcc&view=rev Log: 2019-12-21 Harald Anlauf PR fortran/92990 * match.c (gfc_match_nullify): Check for valid pointer object. Reject bounds remapping. PR fortran/92990 * gfortran.dg/pr92990.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr92990.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/92990] INVALID code with NULLIFY – partially misleading error message "If bounds remapping is specified at (1), the pointer target shall not be NULL"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92990 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from anlauf at gcc dot gnu.org --- Fixed.
[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008 --- Comment #5 from Jonathan Wakely --- But it wouldn't be redundant for GCC, it would have a different, non-portable meaning. Does it say "inline constexpr" because the code was written by someone who likes redundancy for the sake of explicitness, or because somebody wants the GCC-specific optimisation hint? If you have to add a comment to the code saying "don't remove this keyword, it's here because it does something" then the meaning is neither redundant, not explicit. It's non-obvious and an implicit meaning not backed up by other compilers or the standard. IMO the ideal solution is for GCC to stop using whether a function is inline as an optimisation hint. Then we wouldn't need some extra GCC-specific way to override that.
[Bug fortran/91661] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91661 --- Comment #7 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sat Dec 21 20:42:14 2019 New Revision: 279699 URL: https://gcc.gnu.org/viewcvs?rev=279699&root=gcc&view=rev Log: 2019-12-21 Harald Anlauf PR fortran/91661 * gfortran.dg/pr91661.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr91661.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/91661] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91661 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed in GCC 10. Thanks for the report!
[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823 Eric Gallager changed: What|Removed |Added Severity|normal |trivial
[Bug c++/86176] Wnull-dereference warning disappears with a call to std::cout on the line after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86176 --- Comment #6 from Eric Gallager --- (In reply to Jonathan Wakely from comment #3) > No, because GCC is not a static analyser. It'll have one once David Malcolm's static analyzer branch is merged
[Bug fortran/93026] gfortran.dg/goacc/finalize-1.f – FAILs since r279626
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93026 --- Comment #2 from Thomas Schwinge --- Author: tschwinge Date: Sat Dec 21 21:32:36 2019 New Revision: 279700 URL: https://gcc.gnu.org/viewcvs?rev=279700&root=gcc&view=rev Log: [PR93026, PR92929] Adjust 'gfortran.dg/goacc/finalize-1.f' for r279626 changes gcc/testsuite/ PR fortran/93026 PR middle-end/92929 * gfortran.dg/goacc/finalize-1.f: Adjust. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/goacc/finalize-1.f
[Bug middle-end/92929] OpenACC/OpenMP 'target' 'exit data'/'update' optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92929 --- Comment #5 from Thomas Schwinge --- Author: tschwinge Date: Sat Dec 21 21:32:36 2019 New Revision: 279700 URL: https://gcc.gnu.org/viewcvs?rev=279700&root=gcc&view=rev Log: [PR93026, PR92929] Adjust 'gfortran.dg/goacc/finalize-1.f' for r279626 changes gcc/testsuite/ PR fortran/93026 PR middle-end/92929 * gfortran.dg/goacc/finalize-1.f: Adjust. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/goacc/finalize-1.f
[Bug fortran/72715] [OpenACC] ICE in gfc_trans_omp_do, at fortran/trans-openmp.c:3164
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72715 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid CC||anlauf at gcc dot gnu.org Summary|ICE in gfc_trans_omp_do, at |[OpenACC] ICE in |fortran/trans-openmp.c:3164 |gfc_trans_omp_do, at ||fortran/trans-openmp.c:3164 --- Comment #6 from anlauf at gcc dot gnu.org --- Code is still rejected with current 10-trunk: x.f90:4:23: 4 | do concurrent (i=1:3) | 1 Error: !$ACC LOOP cannot be a DO CONCURRENT loop at (1)
[Bug c++/93028] internal compiler error: in write_type, at cp/mangle.c:2073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93028 --- Comment #5 from Colin H Close --- Created attachment 47540 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47540&action=edit Easy compile of pre-processed source Even easier reproduction of the fault. Untar the archive and run create_errorpp.sh The pre-processed source is test.cpp
[Bug c++/93028] internal compiler error: in write_type, at cp/mangle.c:2073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93028 --- Comment #6 from Colin H Close --- Removing the lto flag allowed the source to compile without error. To make sure it wasn't a linker issue I ran tests with both the bfd and gold linkers by using -fuser-ld= both failed with the identical error. Something in lto has been broken by commit git 067e9a502dcaabcecda20a00b3f7c6160d8eea93 git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@269859 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug testsuite/92998] aarch64/sve/acle/general/dupq_1.c fails on big-endian linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92998
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2019-12-22
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
I will take care of this.
/* { dg-require-effective-target aarch64_little_endian } */
is needed.
[Bug rtl-optimization/93040] New: gcc doesn't optimize unaligned accesses to a 16-bit value on the x86 as well as it does a 32-bit value (or clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93040
Bug ID: 93040
Summary: gcc doesn't optimize unaligned accesses to a 16-bit
value on the x86 as well as it does a 32-bit value (or
clang)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: miles at gnu dot org
Target Milestone: ---
Given the following code:
unsigned short get_unaligned_16 (unsigned char *p)
{
return p[0] | (p[1] << 8);
}
unsigned int get_unaligned_32 (unsigned char *p)
{
return get_unaligned_16 (p) | (get_unaligned_16 (p + 2) << 16);
}
unsigned int get_unaligned_32_alt (unsigned char *p)
{
return p[0] | (p[1] << 8) | (p[2] << 16) | (p[3] << 24);
}
... Clang/LLVM (trunk, but it has the same results many versions back)
generates the following very nice output:
get_unaligned_16: # @get_unaligned_16
movzx eax, word ptr [rdi]
ret
get_unaligned_32: # @get_unaligned_32
mov eax, dword ptr [rdi]
ret
get_unaligned_32_alt: # @get_unaligned_32_alt
mov eax, dword ptr [rdi]
ret
Whereas gcc (trunk but ditto) generates:
get_unaligned_16:
movzx eax, BYTE PTR [rdi+1]
sal eax, 8
mov edx, eax
movzx eax, BYTE PTR [rdi]
or eax, edx
ret
get_unaligned_32:
movzx eax, BYTE PTR [rdi+3]
sal eax, 8
mov edx, eax
movzx eax, BYTE PTR [rdi+2]
or eax, edx
movzx edx, BYTE PTR [rdi+1]
sal eax, 16
mov ecx, edx
movzx edx, BYTE PTR [rdi]
sal ecx, 8
or edx, ecx
movzx edx, dx
or eax, edx
ret
get_unaligned_32_alt:
mov eax, DWORD PTR [rdi]
ret
Notice that in the "get_unaligned_32_alt" version, gcc _does_ detect
that this is really an unaligned access to a 32-bit integer and
reduces it to a single instruction on the x86, as that architecture
supports unaligned accesses.
However the 16-bit version, "get_unaligned_16", and get_unaligned_32
derived from that, it just uses the component bit-munching operations.
It does seem curious that gcc manages the 32-bit case, but fails on
the 16-bit case...
I tested gcc on godbolt.com, and Clang locally (and on godbolt).
Flags used:
-O2 -march=skylake
-Os and -O3 yield the same results.
Versions:
gcc (Compiler-Explorer-Build) 10.0.0 20191220 (experimental)
clang version 10.0.0 (https://github.com/llvm/llvm-project.git
b4dfa74a5d80b3602a5315fac2ef5f98b0e63708)
[Bug tree-optimization/93040] gcc doesn't optimize unaligned accesses to a 16-bit value on the x86 as well as it does a 32-bit value (or clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93040 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/93040] gcc doesn't optimize unaligned accesses to a 16-bit value on the x86 as well as it does a 32-bit value (or clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93040 --- Comment #1 from Andrew Pinski --- the bswap pass should have detected it.
[Bug tree-optimization/93040] gcc doesn't optimize unaligned accesses to a 16-bit value on the x86 as well as it does a 32-bit value (or clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93040
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-12-22
Version|unknown |10.0
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
If we rewrite get_unaligned_16 slightly like:
unsigned short get_unaligned_16_1 (unsigned char *p)
{
unsigned short t0 = p[0];
unsigned short t1 = p[1];
t1 <<= 8;
return t0 | t1;
}
GCC is able to detect it as a nop/bswap (on big-endian targets).
[Bug testsuite/92998] aarch64/sve/acle/general/dupq_1.c fails on big-endian linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92998 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Andrew Pinski --- Fixed.
[Bug testsuite/92998] aarch64/sve/acle/general/dupq_1.c fails on big-endian linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92998 --- Comment #4 from Andrew Pinski --- Author: pinskia Date: Sun Dec 22 01:35:08 2019 New Revision: 279709 URL: https://gcc.gnu.org/viewcvs?rev=279709&root=gcc&view=rev Log: Restrict some aarch64 testcases to little-endian 2019-12-21 Andrew Pinski PR testsuite/92998 * gcc.target/aarch64/sve/acle/general/dupq_1.c: Restrict to aarch64_little_endian only. * gcc.target/aarch64/torture/simd-abi-8.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/sve/acle/general/dupq_1.c trunk/gcc/testsuite/gcc.target/aarch64/torture/simd-abi-8.c
[Bug tree-optimization/51680] g++ 4.7 fails to inline trivial template stuff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680 --- Comment #22 from miles at gnu dot org --- This seems to have been fixed a long time ago (all the examples in the comment yield the "right" result). Can somebody close this bug?
[Bug middle-end/93041] New: GCC 10.0 with '-Os', '-O2' and '-O3' compiled program crashes when it shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93041
Bug ID: 93041
Summary: GCC 10.0 with '-Os', '-O2' and '-O3' compiled program
crashes when it shouldn't
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msl023508 at gmail dot com
Target Milestone: ---
$ cat preprocessed.c
int g1 = 2;
int *g2 = &g1;
int g3 = 6;
void func1(int **p) {
label1:
if(p) goto label1;
g3 = **p;
}
int main() {
func1(&g2);
return g3;
}
$ gcc-10.0-20191222-r279709 -v
Using built-in specs.
COLLECT_GCC=gcc-10.0-20191222-r279709
COLLECT_LTO_WRAPPER=/opt/gcc-10.0-20191222-r279709/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-10-current/configure --prefix=/usr/local
--sysconfdir=/etc --localstatedir=/var --libexecdir='/usr/local/lib'
--enable-version-specific-runtime-libs --disable-rpath --with-system-zlib
--enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,fortran,lto
--enable-plugin --enable-initfini-array --enable-gnu-indirect-function
--program-suffix=-10.0-20191222-r279709
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20191222 (experimental) (GCC)
$ gcc-10.0-20191222-r279709 -Wall -Os preprocessed.c
$ ./a.out
Segmentation fault
[Bug middle-end/93041] GCC 10.0 with '-Os', '-O2' and '-O3' compiled program crashes when it shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93041 --- Comment #1 from WHR --- This happens with in x86_64 (-m64) and i386 (-m32) targets. But not in early versions such GCC 9.2. As a reference, compiling it with GCC 9.2 didn't trigger the crash: $ gcc-9.2 -v Using built-in specs. COLLECT_GCC=gcc-9.2 COLLECT_LTO_WRAPPER=/opt/gcc-9.2/bin/../lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-9.2.0/configure --prefix=/usr/local --sysconfdir=/etc --localstatedir=/var --libexecdir='/usr/local/lib' --enable-version-specific-runtime-libs --disable-rpath --with-system-zlib --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,fortran,lto --enable-plugin --enable-initfini-array --enable-gnu-indirect-function --program-suffix=-9.2 : (reconfigured) ../gcc-9.2.0/configure --prefix=/usr/local --sysconfdir=/etc --localstatedir=/var --libexecdir='/usr/local/lib' --enable-version-specific-runtime-libs --disable-rpath --with-system-zlib --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,fortran,lto --enable-plugin --enable-initfini-array --enable-gnu-indirect-function --program-suffix=-9.2 Thread model: posix gcc version 9.2.0 (GCC) $ gcc-9.2 -Wall preprocessed.c $ ./a.out ^C $ (the program should never exit)
[Bug middle-end/93041] GCC 10.0 with '-Os', '-O2' and '-O3' compiled program crashes when it shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93041 --- Comment #2 from Andrew Pinski --- So what is happening is (infinite) loops can be removed if they have no side effects. So we start with: : label1: if (p_3(D) != 0B) goto ; [INV] else goto ; [INV] : // predicted unlikely by goto predictor. goto ; [INV] : _1 = *p_3(D); _2 = *_1; g3 = _2; return; And then we prop 0 into p_3 and then we remove the infinite loop. So we run into undefined behavior from dereferencing a null pointer. I think this code is undefined due to forward progress is required by the standards.
