[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340 --- Comment #11 from Richard Biener --- (In reply to Martin Liška from comment #6) > I'm curious how much can save following patch: > > diff --git a/gcc/tree-switch-conversion.h b/gcc/tree-switch-conversion.h > index b3bc4b9ddf7..904827fa040 100644 > --- a/gcc/tree-switch-conversion.h > +++ b/gcc/tree-switch-conversion.h > @@ -271,7 +271,7 @@ struct jump_table_cluster: public group_cluster >static bool is_enabled (void); > >/* Max growth ratio for code that is optimized for size. */ > - static const unsigned HOST_WIDE_INT max_ratio_for_size = 3; > + static const unsigned HOST_WIDE_INT max_ratio_for_size = 2; > >/* Max growth ratio for code that is optimized for speed. */ >static const unsigned HOST_WIDE_INT max_ratio_for_speed = 8; I guess most of these should have been --params ...
[Bug c++/90372] New: [x64][missed optimization] pushes unused r12 onto stack on unique_ptr use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90372 Bug ID: 90372 Summary: [x64][missed optimization] pushes unused r12 onto stack on unique_ptr use Product: gcc Version: 9.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marc at kdab dot com Target Milestone: --- In the following example: https://godbolt.org/z/jHSYue one(), using std::unique_ptr, pushes r12 to the stack just to pop it back at the end. r12 does not appear to be used in-between. The similar two() function does not do this, even though the rest of the function (except the stack unwind trampoline) is instruction-by-instruction identical. Expected: r12 is not pushed/popped.
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 --- Comment #19 from rguenther at suse dot de --- On Tue, 7 May 2019, jb at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 > > --- Comment #18 from Janne Blomqvist --- > (In reply to Thomas Koenig from comment #15) > > Since we applied the fix for PR 87689 to gcc 7, gcc 8 and gcc 9, > > I would suggest that we make -fno-optimize-sibling-calls > > the default on these branches. Maintaining binary compatibility > > (even if it is bug compatibility) with existing packages is > > something we should strive for, especially with such > > important software packages as BLAS and LAPACK. > > +1. Especially considering Steve's benchmark suggesting there's practically no > difference, although there may of course be other code where sibling call > optimization makes a difference. > > > For current trunk, I would recommend keeping the current > > hehavior and contact the LAPACK maintainers to a) give them > > a heads-up for this problem, and b) a year to work out > > the problem. > > Yes. Closer to GCC 10, we can revisit this. I suspect we'll have to make > -fno-optimize-sibling-calls the default for GCC 10 as well; while we might be > able to help LAPACK maintainers fix LAPACKE there's in this timeframe there's > certainly a lot of other code out there with custom C-Fortran interfaces which > might be affected. I don't see how -fno-optimize-sibling-calls helps in a systematic way. It might obfuscate a specific example enough to make it work, but...?
[Bug libstdc++/90371] gcc with newlib do not support std::mutex, std:: thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90371 --- Comment #2 from jojo --- Thanks for your reply:) (In reply to Andrew Pinski from comment #1) > For your target, needs to fully support pthreads and a few other things. > You can look at what is needed via libstdc++/configure.ac and related files. > > Oh this is not the right place to request this kind of help since you are > going to need to modify both newlib and libstdc++ for this support.
[Bug libstdc++/90371] gcc with newlib do not support std::mutex, std:: thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90371 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- For your target, needs to fully support pthreads and a few other things. You can look at what is needed via libstdc++/configure.ac and related files. Oh this is not the right place to request this kind of help since you are going to need to modify both newlib and libstdc++ for this support.
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 --- Comment #18 from Janne Blomqvist --- (In reply to Thomas Koenig from comment #15) > Since we applied the fix for PR 87689 to gcc 7, gcc 8 and gcc 9, > I would suggest that we make -fno-optimize-sibling-calls > the default on these branches. Maintaining binary compatibility > (even if it is bug compatibility) with existing packages is > something we should strive for, especially with such > important software packages as BLAS and LAPACK. +1. Especially considering Steve's benchmark suggesting there's practically no difference, although there may of course be other code where sibling call optimization makes a difference. > For current trunk, I would recommend keeping the current > hehavior and contact the LAPACK maintainers to a) give them > a heads-up for this problem, and b) a year to work out > the problem. Yes. Closer to GCC 10, we can revisit this. I suspect we'll have to make -fno-optimize-sibling-calls the default for GCC 10 as well; while we might be able to help LAPACK maintainers fix LAPACKE there's in this timeframe there's certainly a lot of other code out there with custom C-Fortran interfaces which might be affected.
[Bug libstdc++/90371] New: gcc with newlib do not support std::mutex, std:: thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90371
Bug ID: 90371
Summary: gcc with newlib do not support std::mutex, std::
thread
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rjiejie at me dot com
Target Milestone: ---
with the following code, it's compiled error with gcc-newlib*:
error: ‘mutex’ is not a member of ‘std’
and it's ok in the "gcc-linux*" toolchain,
i want to use std:mutex by gcc with newlib like linux platform,
how do i configure gcc with newlib to build ?
#include
using namespace std;
int func()
{
std::mutex a;
}
[Bug target/86444] [X86] Implementation of SSE comi/ucomi intrinsics does not match recent versions of icc, clang, or MSVC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86444 --- Comment #1 from Hongtao.liu --- Created attachment 46308 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46308&action=edit Fix-ix86_expand_sse_comi_round.patch Fix ix86_expand_sse_comi_round and add runtime tests for it.
[Bug target/89750] Wrong code for _mm_comi_round_ss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89750 --- Comment #2 from Hongtao.liu --- Created attachment 46307 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46307&action=edit Fix-ix86_expand_sse_comi_round.patch Fix ix86_expand_sse_comi_round and add runtime tests for it.
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 --- Comment #17 from Steve Kargl --- On Mon, May 06, 2019 at 04:40:08PM +, kargl at gcc dot gnu.org wrote: > > Since we applied the fix for PR 87689 to gcc 7, gcc 8 and gcc 9, > > I would suggest that we make -fno-optimize-sibling-calls > > the default on these branches. Maintaining binary compatibility > > (even if it is bug compatibility) with existing packages is > > something we should strive for, especially with such > > important software packages as BLAS and LAPACK. These packages > > are one important reason why people still use Fortran, and > > I would hate to push them towards flang with this. > > > > For current trunk, I would recommend keeping the current > > hehavior and contact the LAPACK maintainers to a) give them > > a heads-up for this problem, and b) a year to work out > > the problem. > > > > Would this be something that people could agree on? > > Does -fno-optimizing-sibling-calls effect performance? > A 1% (or less) degradation may be considered negligible, > and an acceptible compromise. 10% would be unacceptable. > > Guess I'll need to dust off my old copy of the Polyhedron > Benchmarks and run a few tests. > So, I dusted off my old PB code and ran some tests. The system is x86_64-*-freebsd. I saw nothing to suggest that this option would have a negative impact on performance. Date & Time : 6 May 2019 13:29:24 Test Name : gfcx Compile Command : gfcx -static -ffpe-summary=none -O3 -pipe -mtune=native -march=native -ffast-math -ftree-vectorize -funroll-loops --param max-unroll-times=4 %n.f90 -o %n Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft Maximum Times : 200.0 Target Error % : 0.100 Minimum Repeats : 5 Maximum Repeats :10 Benchmark Compile Executable Ave Run Number Estim Name(secs) (bytes)(secs) Repeats Err % - --- -- --- --- -- ac 1.60 5511576 8.00 6 0.0893 aermod 49.38 6822120 19.18 5 0.0054 air 7.49 5632568 4.57 5 0.0340 capacita 4.97 5639072 40.91 5 0.0384 channel 1.31 5520904 1.86 10 0.2693 doduc 7.53 5655488 19.33 6 0.0978 fatigue 3.42 5618928 4.41 5 0.0170 gas_dyn 3.80 5604440 1.91 5 0.0214 induct 7.59 5771912 6.18 5 0.0209 linpk 1.23 5486240 7.82 5 0.0096 mdbx 2.97 5553200 7.33 5 0.0388 nf 2.73 5533744 8.57 5 0.0095 protein 4.89 5762320 25.13 5 0.0494 rnflow 7.87 5965568 34.26 5 0.0810 test_fpu 5.90 5705216 6.03 10 0.1206 tfft 1.64 5519096 1.81 5 0.0138 Geometric Mean Execution Time = 7.94 seconds Date & Time : 6 May 2019 16:11:36 Test Name : gfcx Compile Command : gfcx -fno-optimize-sibling-calls -static -ffpe-summary=none -O3 -pipe -mtune=native -march=native -ffast-math -ftree-vectorize -funroll-loops --param max-unroll-times=4 %n.f90 -o %n Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft Maximum Times : 200.0 Target Error % : 0.100 Minimum Repeats : 5 Maximum Repeats :10 Benchmark Compile Executable Ave Run Number Estim Name(secs) (bytes)(secs) Repeats Err % - --- -- --- --- -- ac 1.58 5511576 7.99 5 0.0139 aermod 49.16 6822120 19.17 5 0.0216 air 7.48 5632568 4.57 5 0.0274 capacita 4.95 5639072 41.24 5 0.3593 channel 1.31 5520904 1.86 10 0.2607 doduc 8.00 5655488 19.29 10 0.0947 fatigue 3.43 5618928 4.40 5 0.0545 gas_dyn 3.81 5604440 1.97 5 0.0328 induct 7.58 5771912 6.18 5 0.0121 linpk 1.23 5486240 7.85 5 0.0699 mdbx 2.97 5553200 7.28 5 0.0703 nf 2.72 5533744 8.62 5 0.0998 protein 4.87 5762320 25.30 8 0.1194 rnflow 7.86 5965568 34.28 6 0.2875 test_fpu 5.88 5705216 6.03 8 0.0980 tfft 1.64 5519096 1.74 6 0.0841 Geometric Mean Execu
[Bug libstdc++/90370] Does 0 correspond to a POSIX errno value for std::system_category?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90370
--- Comment #1 from Jonathan Wakely ---
This is the cause of the issue described in 4.10 of https://wg21.link/p0824r1
(but the presentation there is wrong: the comparison semantics are clearly
defined, the implementation divergence is in whether 0 is considered to be a
POSIX errno value).
VC++ appears to agree with libstdc++ that error_code{} != error_condition{}.
[Bug libstdc++/90370] New: Does 0 correspond to a POSIX errno value for std::system_category?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90370 Bug ID: 90370 Summary: Does 0 correspond to a POSIX errno value for std::system_category? Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- The C++ standard says in [syserr.errcat.objects]: "If the argument ev corresponds to a POSIX errno value posv, the function shall return error_condition(posv, generic_category()). Otherwise, the function shall return error_condition(ev, system_category()). What constitutes correspondence for any given operating system is unspecified." Our current implementation (in src/c++11/system_error.cc) does not consider 0 to correspond to a POSIX errno value. I did that because there is no EXXX macro defined by POSIX with value zero, as all error numbers are required to be positive values. Libc++ and Boost.System do consider 0 to correspond to a POSIX errno value, meaning "no error" (and Boost even defines the boost::system::errc::success enumerator with the value zero). I think both positions can be justified. Zero is not an errno value, but it does have special meaning. Should we change our implementation?
[Bug fortran/90290] -std=f2008 should reject non-constant stop and error stop codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90290 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon May 6 23:24:32 2019 New Revision: 270928 URL: https://gcc.gnu.org/viewcvs?rev=270928&root=gcc&view=rev Log: 2019-05-06 Steven G. Kargl PR fortran/90290 * match.c (gfc_match_stopcode): Check F2008 condition on stop code. 2019-05-06 Steven G. Kargl PR fortran/90290 * gfortran.dg/pr90290.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr90290.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340 --- Comment #10 from Fredrik Hederstierna --- Tested also gcc-9.1.0 "max_ratio_for_size = 1" just out of curiosity results was similar compared to gcc-8.2.0: Overall CSiBE was 2 417 695 bytes (+4185 bytes, +0.17%) Example file CSiBE "vsprintf.c" was 2369 bytes (+76 bytes, +3.2%)
[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
--- Comment #11 from Jakub Jelinek ---
Author: jakub
Date: Mon May 6 21:50:14 2019
New Revision: 270924
URL: https://gcc.gnu.org/viewcvs?rev=270924&root=gcc&view=rev
Log:
PR tree-optimization/88709
PR tree-optimization/90271
* params.def (PARAM_STORE_MERGING_MAX_SIZE): New parameter.
* gimple-ssa-store-merging.c (encode_tree_to_bitpos): Handle
non-clobber CONSTRUCTORs with no elts. Remove useless tmp_int
variable.
(imm_store_chain_info::coalesce_immediate_stores): Punt if the size
of the store merging group is larger than
PARAM_STORE_MERGING_MAX_SIZE parameter.
(split_group): Add bzero_first argument. If set, always emit first
the first store which must be = {} of the whole area and then for the
rest of the stores consider all zero bytes as paddings.
(imm_store_chain_info::output_merged_store): Check if first store
is = {} of the whole area and if yes, determine which setting of
bzero_first for split_group gives smaller number of stores. Adjust
split_group callers.
(lhs_valid_for_store_merging_p): Allow decls.
(rhs_valid_for_store_merging_p): Allow non-clobber CONTRUCTORs with
no elts.
(pass_store_merging::process_store): Likewise.
* gcc.dg/store_merging_26.c: New test.
* gcc.dg/store_merging_27.c: New test.
* gcc.dg/store_merging_28.c: New test.
* gcc.dg/store_merging_29.c: New test.
Added:
trunk/gcc/testsuite/gcc.dg/store_merging_26.c
trunk/gcc/testsuite/gcc.dg/store_merging_27.c
trunk/gcc/testsuite/gcc.dg/store_merging_28.c
trunk/gcc/testsuite/gcc.dg/store_merging_29.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c
trunk/gcc/params.def
trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/88709] Improve store-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88709
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Mon May 6 21:50:14 2019
New Revision: 270924
URL: https://gcc.gnu.org/viewcvs?rev=270924&root=gcc&view=rev
Log:
PR tree-optimization/88709
PR tree-optimization/90271
* params.def (PARAM_STORE_MERGING_MAX_SIZE): New parameter.
* gimple-ssa-store-merging.c (encode_tree_to_bitpos): Handle
non-clobber CONSTRUCTORs with no elts. Remove useless tmp_int
variable.
(imm_store_chain_info::coalesce_immediate_stores): Punt if the size
of the store merging group is larger than
PARAM_STORE_MERGING_MAX_SIZE parameter.
(split_group): Add bzero_first argument. If set, always emit first
the first store which must be = {} of the whole area and then for the
rest of the stores consider all zero bytes as paddings.
(imm_store_chain_info::output_merged_store): Check if first store
is = {} of the whole area and if yes, determine which setting of
bzero_first for split_group gives smaller number of stores. Adjust
split_group callers.
(lhs_valid_for_store_merging_p): Allow decls.
(rhs_valid_for_store_merging_p): Allow non-clobber CONTRUCTORs with
no elts.
(pass_store_merging::process_store): Likewise.
* gcc.dg/store_merging_26.c: New test.
* gcc.dg/store_merging_27.c: New test.
* gcc.dg/store_merging_28.c: New test.
* gcc.dg/store_merging_29.c: New test.
Added:
trunk/gcc/testsuite/gcc.dg/store_merging_26.c
trunk/gcc/testsuite/gcc.dg/store_merging_27.c
trunk/gcc/testsuite/gcc.dg/store_merging_28.c
trunk/gcc/testsuite/gcc.dg/store_merging_29.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c
trunk/gcc/params.def
trunk/gcc/testsuite/ChangeLog
[Bug middle-end/90323] powerpc should convert equivalent sequences to vec_sel()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323 --- Comment #7 from Segher Boessenkool --- From the combine dump of without_sel: Trying 8, 9 -> 10: 8: r127:V4SI=r124:V4SI^r131:V4SI REG_DEAD r131:V4SI 9: r122:V4SI=r127:V4SI&r130:V4SI REG_DEAD r130:V4SI REG_DEAD r127:V4SI 10: r128:V4SI=r124:V4SI^r122:V4SI REG_DEAD r124:V4SI REG_DEAD r122:V4SI Failed to match this instruction: (set (reg:V4SI 128 [ l ]) (xor:V4SI (and:V4SI (xor:V4SI (reg/v:V4SI 124 [ l ]) (reg:V4SI 131)) (reg:V4SI 130)) (reg/v:V4SI 124 [ l ]))) That's not canonical form on RTL, and it's not a useful form either.
[Bug middle-end/90323] powerpc should convert equivalent sequences to vec_sel()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323 Segher Boessenkool changed: What|Removed |Added Status|WAITING |NEW --- Comment #6 from Segher Boessenkool --- But we should translate the xor/and/xor back to something saner. Thanks for the testcase!
[Bug target/90363] or1k: Extra mask insn after load from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90363
--- Comment #2 from Stafford Horne ---
(In reply to Segher Boessenkool from comment #1)
> Trying 13 -> 14:
>13: r51:QI=[r50:SI+low(`*.LANCHOR0')]
> REG_DEAD r50:SI
>14: r43:SI=zero_extend(r51:QI)
> REG_DEAD r51:QI
> Failed to match this instruction:
> (set (reg:SI 43 [ g_doswap.0_2+-3 ])
> (zero_extend:SI (mem/v/c:QI (lo_sum:SI (reg/f:SI 50)
> (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])) [0 g_doswap+0
> S1 A8])))
>
> The mem arg in that does not match nonimmediate_operand, since it is const.
> You want something like reg_or_mem_operand.
Yes, thanks sorry, I did investigation a while ago. I forgot to add when I was
creating this bug.
The issue is that the volatile does not match non immediate_operand.
The following patch fixes that:
iff --git a/gcc/config/or1k/or1k.md b/gcc/config/or1k/or1k.md
index 2dad51cd46b..757d899c442 100644
--- a/gcc/config/or1k/or1k.md
+++ b/gcc/config/or1k/or1k.md
@@ -328,11 +328,11 @@
;; Sign Extending
;; -
-;; Zero extension can always be done with AND and an extending load.
+;; Zero extension can always be done with AND or an extending load.
(define_insn "zero_extendsi2"
[(set (match_operand:SI 0 "register_operand" "=r,r")
- (zero_extend:SI (match_operand:I12 1 "nonimmediate_operand" "r,m")))]
+ (zero_extend:SI (match_operand:I12 1 "reg_or_mem_operand" "r,m")))]
""
"@
l.andi\t%0, %1,
@@ -344,7 +344,7 @@
(define_insn "extendsi2"
[(set (match_operand:SI 0 "register_operand" "=r,r")
- (sign_extend:SI (match_operand:I12 1 "nonimmediate_operand" "r,m")))]
+ (sign_extend:SI (match_operand:I12 1 "reg_or_mem_operand" "r,m")))]
"TARGET_SEXT"
"@
l.exts\t%0, %1
diff --git a/gcc/config/or1k/predicates.md b/gcc/config/or1k/predicates.md
index 879236bca49..b895f1b4228 100644
--- a/gcc/config/or1k/predicates.md
+++ b/gcc/config/or1k/predicates.md
@@ -82,3 +82,21 @@
(define_predicate "equality_comparison_operator"
(match_code "ne,eq"))
+
+;; Borrowed from rs6000
+; Return true if the operand is in volatile memory. Note that during the
+;; RTL generation phase, memory_operand does not return TRUE for volatile
+;; memory references. So this function allows us to recognize volatile
+;; references where it's safe.
+(define_predicate "volatile_mem_operand"
+ (and (match_code "mem")
+ (match_test "MEM_VOLATILE_P (op)")
+ (if_then_else (match_test "reload_completed")
+(match_operand 0 "memory_operand")
+(match_test "memory_address_p (mode, XEXP (op, 0))"
+
+;; Return true if the operand is a register or memory; including volatile
+;; memory.
+(define_predicate "reg_or_mem_operand"
+ (ior (match_operand 0 "nonimmediate_operand")
+ (match_operand 0 "volatile_mem_operand")))
[Bug middle-end/90367] Spurious warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367 --- Comment #13 from Martin Sebor --- (In reply to Andrew Pinski from comment #9) > (In reply to Martin Sebor from comment #8) > > This looks very similar to bug 87072. The C test case below is diagnosed by > > GCC 9, 8, and 7. > > > > $ cat a.c && gcc -O3 -S -Wall -Wextra -fdump-tree-vrp=/dev/stdout a.c > > This testcase is bogus and the warning is correct. You're right, I mistook the second 'for' in the testcase for an 'if'. My bad.
[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340 --- Comment #9 from Fredrik Hederstierna --- I did the test suggested, the results was as follows A. gcc-8.2.0 B. gcc-9.1.0 C. gcc-9.1.0 -fno-jump-tables D. gcc-9.1.0 patched "max_ratio_for_size = 2" Overall CSiBE was A: 2 413 510 bytes B: 2 417 915 bytes (+4405 bytes, +0.18%) C: 2 423 413 bytes (+9903 bytes, +0.41%) D: 2 417 739 bytes (+4229 bytes, +0.18%) Example file CSiBE "vsprintf.c" was A: 2369 bytes B: 2589 bytes (+220 bytes, +9.3%) C: 2445 bytes ( +76 bytes, +3.2%) D: 2489 bytes (+120 bytes, +5.1%) So it didn't really solve it, but made it better possibly, though there are othre code size regression aswell for gcc-9.1.0 which might also affect results..
[Bug middle-end/90367] Spurious warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367 --- Comment #12 from Andrew Pinski --- I doubt there is anything GCC can do it here in a reasonable fashion. I will let someone else reduce the testcase in a reasonable way that shows the problem. Most likely GCC decided that FindAndConstruct should not be inlined due to the size limits. So this is a much more complex problem than what the reduced testcases creduce has done (which both have been bogus in the first place).
[Bug middle-end/90367] Spurious warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
--- Comment #11 from Andrew Pinski ---
Changing DenseMapBase's
ValueT &operator[](const KeyT &t)
To:
{
const KeyT Key = t;
return FindAndConstruct(Key).second;
}
This will cause the warning to go away.
This comes from:
RemapSwizzle[i] =
On a few lines.
GCC does not know that FindAndConstruct does not change the value of its
argument or the argument escapes.
[Bug target/90363] or1k: Extra mask insn after load from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90363
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #1 from Segher Boessenkool ---
Trying 13 -> 14:
13: r51:QI=[r50:SI+low(`*.LANCHOR0')]
REG_DEAD r50:SI
14: r43:SI=zero_extend(r51:QI)
REG_DEAD r51:QI
Failed to match this instruction:
(set (reg:SI 43 [ g_doswap.0_2+-3 ])
(zero_extend:SI (mem/v/c:QI (lo_sum:SI (reg/f:SI 50)
(symbol_ref:SI ("*.LANCHOR0") [flags 0x182])) [0 g_doswap+0 S1
A8])))
The mem arg in that does not match nonimmediate_operand, since it is const.
You want something like reg_or_mem_operand.
[Bug middle-end/90367] Spurious warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367 --- Comment #10 from Andrew Pinski --- (In reply to Martin Sebor from comment #8) > This looks very similar to bug 87072. The C test case below is diagnosed by > GCC 9, 8, and 7. More to the point the line number of this reduced testcase is correct and is pointing out access for 1 is above the bounds. In the original testcase, the loop for j
[Bug middle-end/90367] Spurious warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367 Andrew Pinski changed: What|Removed |Added Status|NEW |UNCONFIRMED Ever confirmed|1 |0 --- Comment #9 from Andrew Pinski --- (In reply to Martin Sebor from comment #8) > This looks very similar to bug 87072. The C test case below is diagnosed by > GCC 9, 8, and 7. > > $ cat a.c && gcc -O3 -S -Wall -Wextra -fdump-tree-vrp=/dev/stdout a.c This testcase is bogus and the warning is correct. In the original testcase, the problem is the iterator i has its address taken which causes GCC to lose the bounds of the loop information.
[Bug target/90323] powerpc should convert equivalent sequences to vec_sel()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323 Bill Schmidt changed: What|Removed |Added Keywords||missed-optimization CC||wschmidt at gcc dot gnu.org --- Comment #5 from Bill Schmidt --- I don't see this as a target issue. It seems like a missed opportunity for creating VEC_COND_EXPRs in the middle end.
[Bug middle-end/90367] Spurious warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-05-06
Component|c++ |middle-end
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=87072
Ever confirmed|0 |1
--- Comment #8 from Martin Sebor ---
This looks very similar to bug 87072. The C test case below is diagnosed by
GCC 9, 8, and 7.
$ cat a.c && gcc -O3 -S -Wall -Wextra -fdump-tree-vrp=/dev/stdout a.c
struct a {
int b;
unsigned c;
};
int f (struct a *p) { return p->b && p->c; }
struct d { };
void e (struct d*);
struct a j[1];
struct a g (struct d *h)
{
for (unsigned i = 0; ; i++)
for (; i; )
if (f (&j[i]))
e (h);
}
a.c: In function ‘g’:
a.c:17:16: warning: array subscript 1 is above array bounds of ‘struct a[1]’
[-Warray-bounds]
17 | if (f (&j[i]))
| ~^~~
a.c:17:16: warning: array subscript 1 is above array bounds of ‘struct a[1]’
[-Warray-bounds]
...
g (struct d * h)
{
unsigned int i;
int _7;
unsigned int _10;
[local count: 11811]:
goto ; [100.00%]
[local count: 118111601]:
_7 = MEM[(struct a *)&j][1].b;
if (_7 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 59055800]:
_10 = MEM[(struct a *)&j][1].c;
if (_10 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 29527900]:
e (h_8(D));
[local count: 118111601]:
[local count: 118111600]:
# i_4 = PHI <1(6), 0(2)>
if (i_4 != 0)
goto ; [3.00%]
else
goto ; [97.00%]
[local count: 955630224]:
goto ; [100.00%]
}
[Bug c++/90367] Spurious warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367 --- Comment #7 from Alexandre Ganea --- I used the following GCC version for preprocessing/compiling: $ /usr/bin/c++ --version c++ (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
[Bug c++/90367] Spurious warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367 --- Comment #6 from Alexandre Ganea --- ...and the command-line: /usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Target/AMDGPU -I/mnt/f/svn/llvm/lib/Target/AMDGPU -Iinclude -I/mnt/f/svn/llvm/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -Wextra -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -Wno-unused-parameter -Wno-type-limits -Wno-cast-qual -Wno-deprecated-declarations -Wno-empty-body -Wno-overflow -Wno-unused-variable -Wno-switch -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG-fno-exceptions -fno-rtti -c /mnt/f/svn/llvm/lib/Target/AMDGPU/R600ISelLowering_3.cpp
[Bug c++/90367] Spurious warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367 --- Comment #5 from Alexandre Ganea --- Created attachment 46306 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46306&action=edit preprocessed source Please see attachement.
[Bug c++/90367] Spurious warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367 --- Comment #4 from Andrew Pinski --- Can you attach the original preprocessed source? the original case does look like it looks like a bug.
[Bug c++/90349] missing return with turned on 03 causes infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90349 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=89218, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=87515, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86761 --- Comment #2 from Martin Sebor --- Given the number of bug reports about this maybe the warning should be enabled by default.
[Bug target/90323] powerpc should convert equivalent sequences to vec_sel()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323 --- Comment #3 from Shawn Landden --- Instead: .globl without_sel .type without_sel, @function without_sel: .LFB0: .cfi_startproc xxlxor 36,34,36 xxland 36,36,35 xxlxor 34,34,36 blr .long 0 .byte 0,0,0,0,0,0,0,0 .cfi_endproc .LFE0: .size without_sel,.-without_sel .align 2 .p2align 4,,15 .globl with_sel .type with_sel, @function with_sel: .LFB1: .cfi_startproc xxsel 34,34,36,35 blr .long 0 .byte 0,0,0,0,0,0,0,0 .cfi_endproc .LFE1: .size with_sel,.-with_sel
[Bug c++/78010] --Wsuggest-override reports a redundant warning on a 'final' method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #9 from Marek Polacek --- This can't be too hard to fix; let me try.
[Bug target/90323] powerpc should convert equivalent sequences to vec_sel()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323 --- Comment #4 from Shawn Landden --- that was compiled with -O3
[Bug target/90323] powerpc should convert equivalent sequences to vec_sel()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323 --- Comment #2 from Shawn Landden --- Created attachment 46305 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46305&action=edit test case. These two functions should produce identical code.
[Bug c++/78010] --Wsuggest-override reports a redundant warning on a 'final' method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010 Barry Revzin changed: What|Removed |Added CC||barry.revzin at gmail dot com --- Comment #8 from Barry Revzin --- Still happens on 9.1. This is actually worse than just a spurious warning. I want to use -Wsuggest-override, but we weren't carefully marking overrides in our code base for a long time... so I used clang-tidy's modernize-use-override check (https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-override.html) to do all the marking so that I can enable this warning. Yay tooling. clang-tidy, though, in addition to adding missing "override"s also removes redundant "virtual"s and replaces a redundant "override final" with just "final" (as Jonathan mentions in comment #2, the Core Guidelines also agree this is redundant). Which means that manual intervention is still necessary to get gcc to not warn. This is a really good warning (would've fixed at least two bugs that I've ran into in production), and we even have existing tooling to remove what would have been all the false positives via clang-tidy... just need gcc to not flag the remaining false positive cases.
[Bug target/90323] powerpc should convert equivalent sequences to vec_sel()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323 Segher Boessenkool changed: What|Removed |Added Target|powerpc |powerpc*-*-* Status|UNCONFIRMED |WAITING Last reconfirmed||2019-05-06 CC||segher at gcc dot gnu.org Version|8.3.0 |10.0 Summary|ppc should convert |powerpc should convert |equivalent sequences to |equivalent sequences to |vec_sel() |vec_sel() Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Please provide a compilable testcase? With flags, expected code, and what you see instead?
[Bug lto/90369] New: error: could not unlink output file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90369
Bug ID: 90369
Summary: error: could not unlink output file
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: hoganmeier at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Tested this ARM toolchain:
http://www.freddiechopin.info/en/download/category/11-bleeding-edge-toolchain
In a very specific case I get the aforementioned error: could not unlink output
file
yield.cpp:
void yield() {}
main.cpp:
void yield();
int main() { yield(); }
arm-none-eabi-g++ -o obj/main.cpp.o -c -flto -g -nostdlib -O2 main.cpp
arm-none-eabi-g++ -o obj/yield.cpp.o -c -flto -g -nostdlib -O2 yield.cpp
arm-none-eabi-gcc-ar rc obj/libFrameworkArduino.a obj/main.cpp.o
obj/yield.cpp.o
arm-none-eabi-g++ -o obj/firmware.elf -T empty.ld -Wl,--gc-sections -O2
-save-temps obj/libFrameworkArduino.a
arm-none-eabi/bin/ld.exe: error: could not unlink output file
If you remove any of the -g or -save-temps flags, or merge the code into 1
file, or use the object files directly it works.
[Bug c++/90366] OpenMP default(none) - std::cerr is diagnosed as "not specified in enclosing 'parallel'", unlike clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90366 Roman Lebedev changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=41768 Resolution|--- |INVALID --- Comment #1 from Roman Lebedev --- It is correct.
[Bug sanitizer/90347] [UBSAN] __attribute__((weak))__ results in "declared weak after being used" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90347
--- Comment #3 from Marek Polacek ---
ubsan_maybe_instrument_reference_or_call sets
flag_delete_null_pointer_checks = 1;
and then we call tree_single_nonzero_warnv_p -> maybe_nonzero_address ->
symtab_node::nonzero_address
1979 if (!DECL_WEAK (decl)
1980 && flag_delete_null_pointer_checks)
1981 {
1982 refuse_visibility_changes = true;
1983 return true;
1984 }
[Bug sanitizer/90347] [UBSAN] __attribute__((weak))__ results in "declared weak after being used" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90347 --- Comment #2 from Marek Polacek --- Caused by -fsanitize=null.
[Bug c++/90265] [9/10 Regression] ICE in build_call_a at gcc/cp/call.c:396 since r268377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90265 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- Fixed.
[Bug c++/90265] [9/10 Regression] ICE in build_call_a at gcc/cp/call.c:396 since r268377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90265 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Mon May 6 17:08:08 2019 New Revision: 270919 URL: https://gcc.gnu.org/viewcvs?rev=270919&root=gcc&view=rev Log: PR c++/90265 - ICE with generic lambda. * pt.c (tsubst_copy_and_build): Use a dedicated variable for the last element in the vector. * g++.dg/cpp1y/lambda-generic-90265.C: New test. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-90265.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/pt.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug target/89424] __builtin_vec_ext_v1ti (v, i) results in ICE with variable i (RS6000)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89424 --- Comment #1 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Mon May 6 17:00:46 2019 New Revision: 270918 URL: https://gcc.gnu.org/viewcvs?rev=270918&root=gcc&view=rev Log: gcc/ChangeLog: 2019-05-06 Kelvin Nilsen PR target/89424 * config/rs6000/rs6000.c (rs6000_expand_vector_extract): Add handling of V1TImode. gcc/testsuite/ChangeLog: 2019-05-06 Kelvin Nilsen PR target/89424 * gcc.target/powerpc/pr89424-0.c: New test. * gcc.target/powerpc/vsx-builtin-13a.c: Define macro PR89424 to enable testing of newly patched capability. * gcc.target/powerpc/vsx-builtin-13b.c: Likewise. * gcc.target/powerpc/vsx-builtin-20a.c: Likewise. * gcc.target/powerpc/vsx-builtin-20b.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr89424-0.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20a.c trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20b.c
[Bug c++/90265] [9/10 Regression] ICE in build_call_a at gcc/cp/call.c:396 since r268377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90265 --- Comment #6 from Jakub Jelinek --- Related to PR90172.
[Bug c++/90265] [9/10 Regression] ICE in build_call_a at gcc/cp/call.c:396 since r268377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90265 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Mon May 6 16:56:39 2019 New Revision: 270917 URL: https://gcc.gnu.org/viewcvs?rev=270917&root=gcc&view=rev Log: PR c++/90265 - ICE with generic lambda. * pt.c (tsubst_copy_and_build): Use a dedicated variable for the last element in the vector. * g++.dg/cpp1y/lambda-generic-90265.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-90265.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #16 from kargl at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #15)
> Hi Tomas,
>
> > I understand the compiler may not know and typically does not whether the
> > called function accepts "character(len=1)" or "character(len=*)", so it may
> > have to pass the 1. But the situation where I suggest not writing the 1 is
> > more subtle (see my original post -
> > https://gcc.gnu.org/ml/fortran/2019-05/msg00021.html).
>
> I have given this some thought, and I don't think this can be done
> in the general case, unfortunately.
>
> Consider
>
> program main
> call foo("ab")
> end
>
> subroutine foo(c)
> character*1 c
> call bar(c)
> end
>
> subroutine bar(c)
> character*(*) c
> print *,len(c)
> end
>
> This is legal Fortran going back to F77, and it should print 1.
>
> If your proposal was implemented, this would print 2, which would
> be a wrong-code bug :-(
>
> So, what can we do? Previously, the way of interfacing C
> with Fortran was fragile, non-conforming, and worked. Now
> it is fragile, non-conforming, and does not work.
>
> In your (excellent, by the way) debugging work, you have
> identified an option, -fno-optimize-sibling-calls, which
> restores the status quo because things would go back to
> being fragile, nonconforming, and they would work again.
>
> Since we applied the fix for PR 87689 to gcc 7, gcc 8 and gcc 9,
> I would suggest that we make -fno-optimize-sibling-calls
> the default on these branches. Maintaining binary compatibility
> (even if it is bug compatibility) with existing packages is
> something we should strive for, especially with such
> important software packages as BLAS and LAPACK. These packages
> are one important reason why people still use Fortran, and
> I would hate to push them towards flang with this.
>
> For current trunk, I would recommend keeping the current
> hehavior and contact the LAPACK maintainers to a) give them
> a heads-up for this problem, and b) a year to work out
> the problem.
>
> Would this be something that people could agree on?
Does -fno-optimizing-sibling-calls effect performance?
A 1% (or less) degradation may be considered negligible,
and an acceptible compromise. 10% would be unacceptable.
Guess I'll need to dust off my old copy of the Polyhedron
Benchmarks and run a few tests.
[Bug c++/90265] [9/10 Regression] ICE in build_call_a at gcc/cp/call.c:396 since r268377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90265 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- Posted.
[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
--- Comment #7 from Michael Matz ---
No, this is not a problem in the stack slot sharing algorithm, but rather in
the input. As presented to expand, and only showing the important parts,
and reordering some BBs to make the flow more obvious:
;; basic block 2, loop depth 0
;;pred: ENTRY
_30 = (unsigned long) ∈
ivtmp.27_29 = _30 + 1;
goto ; [100.00%]
So, 'in' becomes "live" here, it's address in _30 and _29. Fallthrough to bb5,
which also uses in, but otherwise is uninteresting, except that it can reach
only BBs 6 and 7:
;; basic block 5, loop depth 1
...
_2 = check_zero (&in, _31);
if (_2 != 0)
goto ; [99.96%]
else
goto ; [0.04%]
bb6 is a no-return block, hence uninteresting. bb7 _is_ interesting in that
it clobbers in:
;; basic block 7, loop depth 1
;;pred: 5
in ={v} {CLOBBER};
if (i_11 != 5)
goto ; [83.33%]
else
goto ; [16.67%]
Note that the semantics of the clobber is not only that the former contents
are destroyed, but rather that the very storage associated with the clobbered
entity is gone. So, from now on, any pointers into 'in', and memory accesses
into 'in' are invalid. Nevertheless the flow from bb7 goes to bb 8 and 9,
the latter being the return block, so:
;; basic block 8, loop depth 1
;;pred: 7
if (i_11 > 0)
goto ; [100.00%]
else
goto ; [0.00%]
and here we finally have a path into bb3, which is the other interesting one:
;; basic block 3, loop depth 2
# ivtmp.20_6 = PHI <_30(8), ivtmp.20_18(3)>
BOOM! Here _30 is used, and ...
_4 = (void *) ivtmp.20_6;
MEM[base: _4, offset: 0B] = 0;
... even written into ... That's invalid. _30 is associated with an
object that is clobbered and gone ...
set_one (&buf);
buf ={v} {CLOBBER};
ivtmp.20_18 = ivtmp.20_6 + 1;
... and as the MEM[] write can't have possibly been into 'in' (as that is
invalid, as 'in' didn't exist at the MEM access), it's okay and sensible to
allocate 'in' and 'buf' into the same memory.
It seems to be a common misconception of what the clobber is really about.
I designed it to mean what I wrote above, the storage associated with the
clobbered entities is gone after the clobber (not merely it's former
contents!).
But ivopts or dom extends the lifetime of 'in' (by moving an address-taken
earlier) and hence the lifetime of its storage, but without doing anything
about the clobber (and hence not _really_ extending the lifetime). That
doesn't work.
It's basically a mirrored transformation of the usual take-address-of-local
and access it out of it's declared scope, just that here the _start_ of the
supposed lifetime is moved out of the declared scope, not the end.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #13 from Than McIntosh --- I've made a stab at revising the test case to try to trigger the long compile time that I'm still seeing the real application code. Still not quite there yet (revised testcase takes maybe a minute to compile, original 45 mins) -- I don't understand quite why. To compile the revised testcase: gccgo -g -c -O2 auxiliary.go gccgo -g -c -O2 -I . generated2.go Having more than one package seems to be part of the equation (changes aliasing in some way? hard to tell). Profile still seems to be pointing to the same routines as before: (pprof) top15 Showing nodes accounting for 41.67s, 83.29% of 50.03s total Dropped 986 nodes (cum <= 0.25s) Showing top 15 nodes out of 88 flat flat% sum%cum cum% 15.12s 30.22% 30.22% 17.43s 34.84% dominated_by_p 7.96s 15.91% 46.13% 33.78s 67.52% get_continuation_for_phi 4.05s 8.10% 54.23% 4.05s 8.10% canon_value_cmp (inline) 3.70s 7.40% 61.62% 8.35s 16.69% canonicalize_values_star 2.31s 4.62% 66.24% 2.31s 4.62% dom_convert_dir_to_idx (inline) 2.29s 4.58% 70.82% 2.29s 4.58% tree_check (inline) 1.34s 2.68% 73.50% 4.25s 8.49% set_slot_part 1.11s 2.22% 75.71% 1.15s 2.30% gimple_vuse (inline) 1.05s 2.10% 77.81% 1.05s 2.10% loc_cmp 0.64s 1.28% 79.09% 0.64s 1.28% bitmap_list_find_element (inline) 0.52s 1.04% 80.13% 0.88s 1.76% hash_table::find_slot_with_hash
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #11 from Than McIntosh --- Created attachment 46303 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46303&action=edit modified test case (file 1 of 2)
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #12 from Than McIntosh --- Created attachment 46304 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46304&action=edit modified test case (file 2 of 2)
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #13 from Iain Sandoe --- (In reply to Matt Thompson from comment #12) > (In reply to Iain Sandoe from comment #11) > > (In reply to Matt Thompson from comment #10) > > > (In reply to Iain Sandoe from comment #9) > > > > (In reply to Matt Thompson from comment #8) > > > > yes, and/or make sure that the GCC toolchain bin dir is before the > > > > system > > > > ones in your path. > > > > > > I'll try this as well as soon as I can (I can maybe manage make -j4 on > > > this > > > laptop, so builds aren't quick!). Do I need to pass FC as well? Or does > > > the > > > gcc build with fortran not care? > > > > Fortran is built with the C++ compiler, but I'd put the GCC bin dir in the > > path first - and then you will be able to do the DYLD_** commands using the > > bootstrap compiler tools to install. > > Well, 9.1.0 built just fine with 8.2.0 loaded in my environment. This seems > to point to clang, which, well, doesn't surprise me as clang and I have had > a difficult life together, but then again clang built 5.4.0 up to 8.2.0 just > fine for me. > > I'm ran a 'make check' and got: > > Fixed: time.h > Fixed: tinfo.h > Fixed: types/vxTypesBase.h > Fixed: unistd.h > Newly fixed header: sys/ucred.h > > There were fixinclude test FAILURES > make[2]: *** [Makefile:177: check] Error 1 > make[2]: Leaving directory > '/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD-820loaded/fixincludes' > make[1]: *** [Makefile:3829: check-fixincludes] Error 2 > make[1]: Leaving directory > '/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD-820loaded' > make: *** [Makefile:2358: do-check] Error 2 do you have runtest and/or autopen in your path - if not then you won't get any results - you probably need to append the path(s) for home-brew to the end of your PATH. > > So...huh. Not sure what to do there. Still, fortune favors the bold/naive > and I'll continue work with this 9.1.0 and try to build my MPI stack, etc. > and see how it handles our model. OK, so I am happy to work with you to get this working for your environment. GCC should build and install with clang as the bootstrap compiler. For that, I think maybe we should just pick up a direct email discussion and close this PR (since it seems something specific to your setup). NOTE: toolchain "vendors" (including macports et. al.) would normally not support anything that they don't test so the advice would be either: a) build in macports/fink/homebrew unchanged or b) configure and build stand-alone with full control over the environment. Personally, I do (b) because I want the toolchain to work independent of any dependencies from the distributions. Many people who are just building a toolchain for their own use can do (a).
[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348 --- Comment #6 from Jakub Jelinek --- We'd probably need to change decl_to_stack_part from hash_map to hash_map that would just map DECL_UIDs which have DECL_RTL_IF_SET equal to pc_rtx to the partition numbers, rather than from decl, or have some other mapping from DECL_UIDs that appear in the points to info vars back to the decls.
[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
I think before ivopts this looks fine, we have:
[local count: 858993460]:
# j_20 = PHI <0(10), j_13(11)>
in[j_20] = 0;
set_one (&buf);
buf ={v} {CLOBBER};
j_13 = j_20 + 1;
if (i_6 > j_20)
goto ; [80.00%]
else
goto ; [20.00%]
in the inner loop and
[local count: 214748365]:
in ={v} {CLOBBER};
i_10 = i_6 + 1;
ivtmp_22 = ivtmp_4 - 1;
if (ivtmp_22 != 0)
goto ; [80.00%]
else
goto ; [20.00%]
near the end of the outer loop. The problem is that ivopts turns the in[j_20]
access into
[local count: 42959980]:
_30 = (unsigned int) ∈
ivtmp.27_29 = _30 + 1;
goto ; [100.00%]
[local count: 171798691]:
ivtmp.21_16 = (unsigned int) ∈
_23 = (unsigned int) ∈
[local count: 858993460]:
# ivtmp.21_21 = PHI
_18 = (void *) ivtmp.21_21;
MEM[base: _18, offset: 0B] = 0;
set_one (&buf);
buf ={v} {CLOBBER};
which is still fine, for the life analysis we still see in as live in bb 10 and
therefore in bb3 too.
But later on dom3 changes
[local count: 171798691]:
- ivtmp.21_16 = (unsigned int) ∈
- _23 = (unsigned int) ∈
+ ivtmp.21_16 = _30;
+ _23 = _30;
and now &in is live clearly only in bb2 before the outer loop for the life
analysis purposes. Now, if we kill that
if (gimple_clobber_p (stmt))
{
tree lhs = gimple_assign_lhs (stmt);
size_t *v;
/* Nested function lowering might introduce LHSs
that are COMPONENT_REFs. */
if (!VAR_P (lhs))
continue;
if (DECL_RTL_IF_SET (lhs) == pc_rtx
&& (v = decl_to_stack_part->get (lhs)))
bitmap_clear_bit (work, *v);
}
you've mentioned, I'm afraid we lose all the stack slot sharing possibilities,
or at least most of them.
So I'm afraid we need to do something smarter.
Either we need to track during the life analysis algorithm what variables
SSA_NAMEs can point to (even for non-pointers, as in this testcase ivopts uses
an integral value (unsigned int) &in and then later casts to integers), or
could we use the alias analysis points to information for that?
For this testcase, it would be enough to walk for referenced pointer SSA_NAMEs
through their points to variables and mark those variables as also seen in the
IL.
[Bug c++/90173] [9 Regression] ICE: Segmentation fault (in strip_declarator_types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90173 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #8 from Paolo Carlini --- Fixed for 9.2.0 too.
[Bug c++/90173] [9 Regression] ICE: Segmentation fault (in strip_declarator_types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90173 --- Comment #7 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon May 6 15:23:37 2019 New Revision: 270915 URL: https://gcc.gnu.org/viewcvs?rev=270915&root=gcc&view=rev Log: /cp 2019-05-06 Paolo Carlini PR c++/90173 * decl.c (grokdeclarator): Set type to error_mark_node upon error about template placeholder type non followed by a simple declarator-id. /testsuite 2019-05-06 Paolo Carlini PR c++/90173 * g++.dg/cpp1z/class-deduction66.C: New. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1z/class-deduction66.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/decl.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug c++/90367] Spurious warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367 --- Comment #3 from Alexandre Ganea --- Another strange thing, if I change 'SDValue NewBldVec[4];' to 'SDValue NewBldVec[14];' in the code where the issue occurs, the warning goes away. If I set it to 13 or less, the warning is still there. https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/AMDGPU/R600ISelLowering.cpp#L1694
[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361 --- Comment #3 from Viktor Ostashevskyi --- (In reply to Jonathan Wakely from comment #2) > I haven't checked a build with that option for ages, so I can easily believe > I've broken it. I'll take a look tomorrow. It worked well in GCC 8.2.0 at least.
[Bug c++/90367] Spurious warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367 --- Comment #2 from Alexandre Ganea --- Slighly modified version with zero-init variables still shows the warning: https://godbolt.org/z/Mht3uF Andrew: you say "I think you reduced it too much". I simply used "gcc file.cpp -O3 -Warray-bounds | grep -i '\-Warray-bounds'" as an interestingness test. Would you suggest something else, I could try it again?
[Bug target/89221] --enable-frame-pointer does not work as intended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89221 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Uroš Bizjak --- Fixed for gcc-10.
[Bug target/89221] --enable-frame-pointer does not work as intended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89221 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Mon May 6 14:58:57 2019 New Revision: 270914 URL: https://gcc.gnu.org/viewcvs?rev=270914&root=gcc&view=rev Log: PR target/89221 * config.gcc (i[34567]86-*-*, x86_64-*-*): Move tests for enable_cld and enable_frame_pointer ... * configure.ac: ... here. Update help strings for --enable-frame-pointer. * configure: Regenerate. * config/i386/i386-options.c (ix86_option_override_internal): Remove USE_X86_64_FRAME_POINTER define, use USE_IX86_FRAME_POINTER instead. * config/i386/sol2.h (USE_IX86_FRAME_POINTER): Remove. (USE_X86_64_FRAME_POINTER): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/i386/i386-options.c trunk/gcc/config/i386/sol2.h trunk/gcc/configure trunk/gcc/configure.ac
[Bug c++/90367] Spurious warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367 --- Comment #1 from Andrew Pinski --- I think you reduced it too much. Because with the reduction the warning is correct. j[i] will be accessed above the array bounds. Though j[0] is always equal to j[0].
[Bug testsuite/90368] New: gdc testsuite uses "ln -s . gdc.test", which doesn't work on msys2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90368
Bug ID: 90368
Summary: gdc testsuite uses "ln -s . gdc.test", which doesn't
work on msys2
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: rai...@emrich-ebersheim.de
Target Milestone: ---
The gdc testsuite uses "ln -s . gdc.test" to link gec.test in the testsuite/gdc
directory. This doesn't work on msys2 and leads to an error:
ERROR: tcl error sourcing
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.0/gcc/testsuite/gdc.test/gdc-test.exp.
ERROR: couldn't open "gdc.test/compilable/99bottles.d": no such file or
directory
while executing
"open $file r"
(procedure "grep" line 19)
invoked from within
"grep $prog "{\[ \t\]\+dg-\[-a-z\]\+\[ \t\]\+.*\[ \t\]\+}" line"
(procedure "dg-get-options" line 4)
invoked from within
"dg-get-options $prog"
(procedure "saved-dg-test" line 75)
invoked from within
"saved-dg-test gdc.test/compilable/99bottles.d { }
-I/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.0/gcc/testsuite/gdc.test/compilable"
("eval" body line 1)
invoked from within
"eval saved-dg-test $args "
(procedure "dg-test" line 4)
invoked from within
"dg-test $test "$flags $flags_t" ${default-extra-flags}"
(procedure "gdc-dg-runtest" line 23)
invoked from within
"gdc-dg-runtest $filename $flags $imports"
(procedure "gdc-do-test" line 86)
invoked from within
"gdc-do-test"
(file
"/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.0/gcc/testsuite/gdc.test/gdc-test.exp"
line 468)
invoked from within
"source
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.0/gcc/testsuite/gdc.test/gdc-test.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.0/gcc/testsuite/gdc.test/gdc-test.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
[Bug c++/90367] New: Spurious warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
Bug ID: 90367
Summary: Spurious warning array subscript is above array bounds
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alexandre.ganea at ubisoft dot com
Target Milestone: ---
We get what seems like a spurious warning at the following location in LLVM:
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/AMDGPU/R600ISelLowering.cpp#L1718
The warning is:
//warning: array subscript is above array bounds [-Warray-bounds]
//if (NewBldVec[i] == NewBldVec[j]) {
//~~~^
This only occurs when compiling with GCC 7.1+ and 9.1/trunk (not with 8), with
-O3 -Warray-bounds
This has been creduce'd to:
class a {
int b;
unsigned c;
public:
bool operator==(a) { return b && c; }
};
class d {
public:
void e();
};
class f {
a g(d &) const;
};
a f::g(d &h) const {
a j[1];
for (unsigned i = 0;; i++)
for (; i;)
if (j[i] == j[0])
h.e();
}
[Bug middle-end/63477] [6/7/8 Regression] Bogus warning with -O3 -Warray-bounds: array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63477 --- Comment #5 from Martin Sebor --- (In reply to Alexandre Ganea from comment #4) The test case has been reduced a little too far -- it reads an uninitialized variable: for (unsigned i;; i++) for (; i;) if (j[i] == j[0]) h.e(); But the false positive can also be reproduced by initializing the variable to zero. Can you please open a new bug with the corrected test case?
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #12 from Matt Thompson --- (In reply to Iain Sandoe from comment #11) > (In reply to Matt Thompson from comment #10) > > (In reply to Iain Sandoe from comment #9) > > > (In reply to Matt Thompson from comment #8) > > > > I don't usually remove it from my path because it had never caused any > > issues before. Note that I specifically do not let brew install gcc (or > > MPI). I like that control. I'm currently running a "no /usr/local/bin" test > > so we shall see if it helps. > > OK - let's be clear here. You must install GCC into the path that its > configured with in order for the correct shared libraries to be found at > runtime. > > so, if yo configure --prefix=/foo/bar/baz and then intstall into > /baz/bar/foo that will not work correctly. > > The error you are showing seems that you are not finding the same libstdc++ > at runtime as was assumed to be available by the build. Oh. I only ever do "make install" if I get --prefix wrong, I rebuild the whole thing. > > > > If you can find the exact command line that fails and repeat it, prepended > > > by DYLD_PRINT_LIBRARIES=1, that will show you which dylibs are loaded as > > > the > > > command tries to execute (there might be quite a lot of output, so not > > > necessarily easy to interpret) > > > > I just tried this and nothing happens. I tried both "DYLD_PRINT_LIBRARIES=1 > > g++ ..." and "env DYLD_PRINT_LIBRARIES=1 g++ ..." No change in output. > > "which g++" probably says you are using clang++ and that it a protected exe > that will elide DYLD_* when invoked. In that case, it's hard to do that test. > > Yeah. > > > > > > I have built > > > > gcc 8.2.0. Instead of using clang, I could try that...though I'm not > > > > sure > > > > how. Just pass in CC and CXX to configure? > > > > > > yes, and/or make sure that the GCC toolchain bin dir is before the system > > > ones in your path. > > > > I'll try this as well as soon as I can (I can maybe manage make -j4 on this > > laptop, so builds aren't quick!). Do I need to pass FC as well? Or does the > > gcc build with fortran not care? > > Fortran is built with the C++ compiler, but I'd put the GCC bin dir in the > path first - and then you will be able to do the DYLD_** commands using the > bootstrap compiler tools to install. Well, 9.1.0 built just fine with 8.2.0 loaded in my environment. This seems to point to clang, which, well, doesn't surprise me as clang and I have had a difficult life together, but then again clang built 5.4.0 up to 8.2.0 just fine for me. I'm ran a 'make check' and got: Fixed: time.h Fixed: tinfo.h Fixed: types/vxTypesBase.h Fixed: unistd.h Newly fixed header: sys/ucred.h There were fixinclude test FAILURES make[2]: *** [Makefile:177: check] Error 1 make[2]: Leaving directory '/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD-820loaded/fixincludes' make[1]: *** [Makefile:3829: check-fixincludes] Error 2 make[1]: Leaving directory '/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD-820loaded' make: *** [Makefile:2358: do-check] Error 2 So...huh. Not sure what to do there. Still, fortune favors the bold/naive and I'll continue work with this 9.1.0 and try to build my MPI stack, etc. and see how it handles our model.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #10 from Than McIntosh --- Update: it looks like we are not out of the woods quite yet -- I am seeing some similar behavior farther into the build. I will try to produce another reduced test case (this one is proving more difficult replicate).
[Bug c/90365] OpenMP default(none) + schedule(dynamic, variable) - difference with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90365 Roman Lebedev changed: What|Removed |Added See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=41767 --- Comment #3 from Roman Lebedev --- (In reply to Jakub Jelinek from comment #2) > clang is wrong. > OpenMP 5 clarified this, on combined/composite constructs clauses which > apply just to one of the constructs combined/composited together are > considered as present on those constructs and expressions in those clauses > are used inside of the construct (exception is target teams with 2 teams > specific clauses). Thank you for the reply! > So, this testcase is to be handled as > #pragma omp parallel default(none) > #pragma omp for schedule(dynamic, chunkSize) > for(int i = 0; i < 10; i++) sink(); > and at least that one clang handles properly.
[Bug sanitizer/90312] Address sanitizer cannot be used with -mabi=ms since r266073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90312 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.1.1 Resolution|--- |FIXED Known to fail|9.1.0 | --- Comment #8 from Martin Liška --- Fixed.
[Bug sanitizer/90312] Address sanitizer cannot be used with -mabi=ms since r266073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90312 --- Comment #7 from Martin Liška --- Author: marxin Date: Mon May 6 14:01:45 2019 New Revision: 270912 URL: https://gcc.gnu.org/viewcvs?rev=270912&root=gcc&view=rev Log: Backport r270899 2019-05-06 Martin Liska Backport from mainline 2019-05-06 Martin Liska PR sanitizer/90312 * config/i386/i386-options.c (ix86_option_override_internal): Error only when -mabi is selected to a non-default version. 2019-05-06 Martin Liska Backport from mainline 2019-05-06 Martin Liska PR sanitizer/90312 * gcc.dg/asan/pr87930.c: Run the test only on *linux or *gnu systems. * gcc.dg/tsan/pr88017.c: Likewise. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/i386/i386.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gcc.dg/asan/pr87930.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/tsan/pr88017.c
[Bug c++/90366] New: OpenMP default(none) - std::cerr is diagnosed as "not specified in enclosing 'parallel'", unlike clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90366
Bug ID: 90366
Summary: OpenMP default(none) - std::cerr is diagnosed as "not
specified in enclosing 'parallel'", unlike clang
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
#include
void test(int chunkSize) {
#pragma omp parallel default(none)
std::cerr << "hi";
}
clang accepts that code, gcc does not:
: In function 'void test(int)':
:4:18: error: 'cerr' not specified in enclosing 'parallel'
4 | std::cerr << "hi";
| ^~~~
:3:9: error: enclosing 'parallel'
3 | #pragma omp parallel default(none)
| ^~~
Compiler returned: 1
https://godbolt.org/z/hC0cbC
This diagnostic is correct?
[Bug c/90365] OpenMP default(none) + schedule(dynamic, variable) - difference with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90365 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Jakub Jelinek --- clang is wrong. OpenMP 5 clarified this, on combined/composite constructs clauses which apply just to one of the constructs combined/composited together are considered as present on those constructs and expressions in those clauses are used inside of the construct (exception is target teams with 2 teams specific clauses). So, this testcase is to be handled as #pragma omp parallel default(none) #pragma omp for schedule(dynamic, chunkSize) for(int i = 0; i < 10; i++) sink(); and at least that one clang handles properly.
[Bug c/90365] OpenMP default(none) + schedule(dynamic, variable) - difference with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90365 --- Comment #1 from Roman Lebedev --- Forgot to add https://godbolt.org/z/CeVhEu
[Bug c/90365] New: OpenMP default(none) + schedule(dynamic, variable) - difference with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90365
Bug ID: 90365
Summary: OpenMP default(none) + schedule(dynamic, variable) -
difference with clang
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
void sink();
void test(int chunkSize) {
#pragma omp parallel for default(none) schedule(dynamic, chunkSize)
for(int i = 0; i < 10; i++)
sink();
}
clang takes this, gcc does not:
source>: In function 'void test(int)':
:4:5: error: 'chunkSize' not specified in enclosing 'parallel'
4 | for(int i = 0; i < 10; i++)
| ^~~
:3:9: error: enclosing 'parallel'
3 | #pragma omp parallel for default(none) schedule(dynamic, chunkSize)
| ^~~
Compiler returned: 1
Is the diagnostic correct here?
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 90358, which changed state. Bug 90358 Summary: [10 Regression] 526.blender_r train run does not finish after r270847 on znver1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90358 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/90358] [10 Regression] 526.blender_r train run does not finish after r270847 on znver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90358 --- Comment #6 from Richard Biener --- Author: rguenth Date: Mon May 6 13:40:00 2019 New Revision: 270911 URL: https://gcc.gnu.org/viewcvs?rev=270911&root=gcc&view=rev Log: 2019-05-06 Richard Biener PR tree-optimization/90358 * tree-vect-stmts.c (get_group_load_store_type): Properly detect unused upper half of load. (vectorizable_load): Likewise. * gcc.target/i386/pr90358.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr90358.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/90358] [10 Regression] 526.blender_r train run does not finish after r270847 on znver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90358 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #15 from Thomas Koenig ---
Hi Tomas,
> I understand the compiler may not know and typically does not whether the
> called function accepts "character(len=1)" or "character(len=*)", so it may
> have to pass the 1. But the situation where I suggest not writing the 1 is
> more subtle (see my original post -
> https://gcc.gnu.org/ml/fortran/2019-05/msg00021.html).
I have given this some thought, and I don't think this can be done
in the general case, unfortunately.
Consider
program main
call foo("ab")
end
subroutine foo(c)
character*1 c
call bar(c)
end
subroutine bar(c)
character*(*) c
print *,len(c)
end
This is legal Fortran going back to F77, and it should print 1.
If your proposal was implemented, this would print 2, which would
be a wrong-code bug :-(
So, what can we do? Previously, the way of interfacing C
with Fortran was fragile, non-conforming, and worked. Now
it is fragile, non-conforming, and does not work.
In your (excellent, by the way) debugging work, you have
identified an option, -fno-optimize-sibling-calls, which
restores the status quo because things would go back to
being fragile, nonconforming, and they would work again.
Since we applied the fix for PR 87689 to gcc 7, gcc 8 and gcc 9,
I would suggest that we make -fno-optimize-sibling-calls
the default on these branches. Maintaining binary compatibility
(even if it is bug compatibility) with existing packages is
something we should strive for, especially with such
important software packages as BLAS and LAPACK. These packages
are one important reason why people still use Fortran, and
I would hate to push them towards flang with this.
For current trunk, I would recommend keeping the current
hehavior and contact the LAPACK maintainers to a) give them
a heads-up for this problem, and b) a year to work out
the problem.
Would this be something that people could agree on?
[Bug middle-end/63477] [6/7/8 Regression] Bogus warning with -O3 -Warray-bounds: array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63477
Alexandre Ganea changed:
What|Removed |Added
CC||alexandre.ganea at ubisoft dot
com
--- Comment #4 from Alexandre Ganea ---
Hi,
We get what seems like a spurious warning at the following location in LLVM:
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/AMDGPU/R600ISelLowering.cpp#L1718
The warning is:
//warning: array subscript is above array bounds [-Warray-bounds]
//if (NewBldVec[i] == NewBldVec[j]) {
//~~~^
This only occurs when compiling with GCC 7.1+ and 9.1/trunk (not with 8), with
-O3 -Warray-bounds
This has been creduce'd to:
class a {
int b;
unsigned c;
public:
bool operator==(a) { return b && c; }
};
class d {
public:
void e();
};
class f {
a g(d &) const;
};
a f::g(d &h) const {
a j[1];
for (unsigned i;; i++)
for (; i;)
if (j[i] == j[0])
h.e();
}
Could you please confirm the issue?
Thank you!
[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-06 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |9.2 Summary|Undefined symbols in|[9/10 Regression] Undefined |libstdc++ when building |symbols in libstdc++ when |with|building with |--with-default-libstdcxx-ab |--with-default-libstdcxx-ab |i=gcc4-compatible |i=gcc4-compatible Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- I haven't checked a build with that option for ages, so I can easily believe I've broken it. I'll take a look tomorrow.
[Bug libstdc++/90361] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361 --- Comment #1 from Richard Biener --- I can link correctly with -D_GLIBCXX_USE_CXX11_ABI=0 have yet to check a build with the gcc4 ABI as default.
[Bug gcov-profile/90364] 521.wrf_r is 9.5 % slower with PGO on Zen CPUs at -Ofast and native march/mtune
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90364 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-06 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- > > > Note that calls to libmvec are gone with PGO. However, they could > only be generated because the system I used had the necessary Fortran > include file, which IIUC the LNT worker did not have until last week > and yet the regression can be seen in earlier data too. I can confirm that. I'll take a look why the libvmec calls are not used with PGO.
[Bug libstdc++/90277] Debug Mode test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90277 --- Comment #4 from Jonathan Wakely --- (In reply to François Dumont from comment #3) > As stated in my message this patch can be consider as a fix for this PR as > it reserve buckets for 11 buckets so iterators are not invalidated during > execution of the tests. You shouldn't have anymore failures, do you ? > > But maybe you would prefer to make those tests independent of this > implementation detail. I'll do that too. I think it's OK to rely on the detail as long as the tests make that explicit. A comment saying that they assume there's no rehashing would be OK, even better would be to use VERIFY to assert that the count doesn't change. If we make the tests actually verify there's no rehashing, then it's OK to assume no hashing :-) Currently it's just a silent assumption, which isn't even true any more.
[Bug gcov-profile/90364] New: 521.wrf_r is 9.5 % slower with PGO on Zen CPUs at -Ofast and native march/mtune
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90364 Bug ID: 90364 Summary: 521.wrf_r is 9.5 % slower with PGO on Zen CPUs at -Ofast and native march/mtune Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: x86_64-linux Target: x86_64-linux In my measurements using trunk r270639, profile guided optimization (PGO) regresses the run time of 521.wrf_r from SPEC FPrate 2017 by 9.5% (and even LTO+PGO is 7% slower than when using neither) when compiling with -Ofast -march=native -mtune=native. My observations are consistent with data from LNT: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=33.548.0&plot.1=15.548.0&plot.2=12.548.0&plot.3=17.548.0&; Perf stat and report for the two runs are: Non-PGO (fast): 304790.490558 task-clock:u (msec) #0.994 CPUs utilized 0 context-switches:u#0.000 K/sec 0 cpu-migrations:u #0.000 K/sec 292908 page-faults:u #0.961 K/sec 962209421444 cycles:u # 24018297656 stalled-cycles-frontend:u #2.50% frontend cycles idle (83.35%) 142992971234 stalled-cycles-backend:u # 14.86% backend cycles idle (83.33%) 1792410646274 instructions:u#1.86 insn per cycle #0.08 stalled cycles per insn (83.34%) 185705451528 branches:u# 609.289 M/sec (83.34%) 2087790818 branch-misses:u #1.12% of all branches (83.35%) 306.542849367 seconds time elapsed # Samples: 1M of event 'cycles' # Event count (approx.): 964214205064 # # OverheadSamples Shared Object Symbol # . ... .. # 7.02% 85562 libm-2.29.so __logf_fma 5.99% 72982 libm-2.29.so __powf_fma 5.44% 66794 wrf_r_peak.std __module_advect_em_MOD_advect_scalar_pd 5.21% 63576 libm-2.29.so __atanf 4.30% 52426 libmvec-2.29.so _ZGVbN4v_expf_sse4 4.04% 49253 wrf_r_peak.std__module_mp_wsm5_MOD_wsm52d 3.93% 47888 wrf_r_peak.std__module_mp_wsm5_MOD_nislfv_rain_plm 2.97% 36505 wrf_r_peak.std __module_small_step_em_MOD_advance_uv 2.67% 32786 wrf_r_peak.std __module_small_step_em_MOD_advance_mu_t 2.63% 32334 wrf_r_peak.std__module_small_step_em_MOD_advance_w 2.52% 30796 wrf_r_peak.std__module_mp_wsm5_MOD_slope_wsm5 2.52% 30948 wrf_r_peak.std__module_advect_em_MOD_advect_scalar 2.34% 28718 libc-2.29.so __memset_avx2_unaligned_erms 2.32% 28336 wrf_r_peak.std__module_bl_ysu_MOD_ysu2d 2.18% 26624 wrf_r_peak.stdpsim_unstable 2.09% 25667 libmvec-2.29.so _ZGVbN4vv_powf_sse4 2.08% 25418 libmvec-2.29.so _ZGVbN4v_logf_sse4 1.87% 22858 wrf_r_peak.stdpsih_unstable 1.65% 20244 wrf_r_peak.std __module_big_step_utilities_em_MOD_phy_prep 1.56% 19006 wrf_r_peak.std__module_ra_rrtm_MOD_rtrn 1.40% 17198 wrf_r_peak.std__module_bc_MOD_set_physical_bc3d 1.25% 15339 wrf_r_peak.std __module_big_step_utilities_em_MOD_horizontal_diffusion 1.22% 15029 libc-2.29.so __memmove_avx_unaligned_erms 1.22% 14833 libm-2.29.so __expf_fma 1.15% 14101 wrf_r_peak.std __module_small_step_em_MOD_calc_p_rho 1.08% 13312 wrf_r_peak.std __module_big_step_utilities_em_MOD_horizontal_pressure_gradient 1.00% 12345 wrf_r_peak.std __module_big_step_utilities_em_MOD_rhs_ph PGO (slow): 325215.123075 task-clock:u (msec) #0.993 CPUs utilized 0 context-switches:u#0.000 K/sec 0 cpu-migrations:u #0.000 K/sec 302283 page-faults:u #0.929 K/sec 1026804177693 cycles:u #3.157 GHz (83.33%) 29812608056 stalled-cycles-frontend:u #2.90% frontend cycles idle (83.35%) 126544641902 stalled-cycles-backend:u # 12.32% backend cycles idle (83.34%) 1968104678527 instructions
[Bug tree-optimization/88828] Inefficient update of the first element of vector registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88828 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon May 6 12:43:30 2019 New Revision: 270908 URL: https://gcc.gnu.org/viewcvs?rev=270908&root=gcc&view=rev Log: 2019-05-06 Richard Biener PR tree-optimization/88828 * tree-ssa-forwprop.c (get_bit_field_ref_def): Split out from... (simplify_vector_constructor): ...here. Handle constants in the constructor. * gcc.target/i386/pr88828-0.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr88828-0.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c
[Bug bootstrap/89656] [9 Regression] profiledbootstrap failure on aarch64-linux since r269453
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89656 --- Comment #6 from Richard Biener --- Author: rguenth Date: Mon May 6 12:40:18 2019 New Revision: 270907 URL: https://gcc.gnu.org/viewcvs?rev=270907&root=gcc&view=rev Log: 2019-05-06 Richard Biener PR bootstrap/90359 Backport from mainline 2019-03-11 Jakub Jelinek PR middle-end/89655 PR bootstrap/89656 * vr-values.c (vr_values::update_value_range): If old_vr->varying_p (), don't update it, make new_vr also VARYING and return false. * gcc.c-torture/compile/pr89655.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/pr89655.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/vr-values.c
[Bug target/90362] or1k: Soft divide does not work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90362 --- Comment #2 from Stafford Horne --- Originally reported by Richard Selvaggi.
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 --- Comment #14 from rguenther at suse dot de --- On Mon, 6 May 2019, tomas.kalibera at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 > > --- Comment #13 from Tomas Kalibera --- > I understand the compiler may not know and typically does not whether the > called function accepts "character(len=1)" or "character(len=*)", so it may > have to pass the 1. But the situation where I suggest not writing the 1 is > more > subtle (see my original post - > https://gcc.gnu.org/ml/fortran/2019-05/msg00021.html). > > There DPOSV is tail-calling (jumping) into DPOTRS). DPOSV wants to pass on the > length of UPLO (1) to DPOTRS. DPOSV knows it was called with this hidden > length > argument of 1, and indeed at the same location on the stack as it is needed > for > DPOTRS, as the length of the same variable UPLO, but it still writes a > compile-time constant 1 to that location on the stack that already has (should > have) 1. I think that's called sibling-calling, not tailcalling (tail-call with same arguments).
[Bug target/90363] or1k: Extra mask insn after load from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90363 Stafford Horne changed: What|Removed |Added Target||or1k Status|UNCONFIRMED |ASSIGNED URL||https://github.com/stffrdhr ||n/gcc/issues/4 Last reconfirmed||2019-05-06 Assignee|unassigned at gcc dot gnu.org |shorne at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/90363] New: or1k: Extra mask insn after load from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90363
Bug ID: 90363
Summary: or1k: Extra mask insn after load from memory
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: shorne at gcc dot gnu.org
Target Milestone: ---
When compiling the below code we see and extra "l.andi r17, r17, 0xff" mask
instruction when reading a byte from memory. This is not needed as loads
already zero extend.
Example:
#include
volatile uint8_t g_doswap = 1;
uint64_t swap_1(uint64_t u64)
{
uint32_t u64_lo, u64_hi, u64_tmp;
u64_lo = u64 & 0x;
u64_hi = u64 >> 32;
if (g_doswap) {
u64_tmp = u64_lo;
u64_lo = u64_hi;
u64_hi = u64_tmp;
}
u64 = u64_lo;
u64 += ((uint64_t) u64_hi << 32);
return u64;
} // swap_1
Output: or1k-elf-gcc -O2 -S doswap_1.c
.file "doswap_1.c"
.section.text
.align 4
.global swap_1
.type swap_1, @function
swap_1:
l.movhi r17, ha(.LANCHOR0)
l.lbz r17, lo(.LANCHOR0)(r17)
l.andi r17, r17, 0xff// < Where is this
coming from
l.movhi r19, hi(0)
l.sfeq r17, r19
l.orr12, r4, r4
l.bf.L6
l.orr11, r3, r3
l.bf.L6
l.orr11, r4, r4
l.orr12, r3, r3
.L6:
l.jrr9
l.nop
.size swap_1, .-swap_1
.global g_doswap
.section.data
.set.LANCHOR0,. + 0
.type g_doswap, @object
.size g_doswap, 1
g_doswap:
.byte 1
.ident "GCC: (GNU) 9.0.1 20190326 (experimental)"
[Bug target/90359] [8 Regression] profiled bootstrap fails on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90359 --- Comment #3 from Richard Biener --- Author: rguenth Date: Mon May 6 12:40:18 2019 New Revision: 270907 URL: https://gcc.gnu.org/viewcvs?rev=270907&root=gcc&view=rev Log: 2019-05-06 Richard Biener PR bootstrap/90359 Backport from mainline 2019-03-11 Jakub Jelinek PR middle-end/89655 PR bootstrap/89656 * vr-values.c (vr_values::update_value_range): If old_vr->varying_p (), don't update it, make new_vr also VARYING and return false. * gcc.c-torture/compile/pr89655.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/pr89655.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/vr-values.c
[Bug middle-end/89655] GCC crashes building linux kernel for arm 32-bit (culprit r269453)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89655 --- Comment #9 from Richard Biener --- Author: rguenth Date: Mon May 6 12:40:18 2019 New Revision: 270907 URL: https://gcc.gnu.org/viewcvs?rev=270907&root=gcc&view=rev Log: 2019-05-06 Richard Biener PR bootstrap/90359 Backport from mainline 2019-03-11 Jakub Jelinek PR middle-end/89655 PR bootstrap/89656 * vr-values.c (vr_values::update_value_range): If old_vr->varying_p (), don't update it, make new_vr also VARYING and return false. * gcc.c-torture/compile/pr89655.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/pr89655.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/vr-values.c
[Bug target/90359] [8 Regression] profiled bootstrap fails on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90359 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed.
[Bug tree-optimization/90328] [7/8/9 Regression] Wrong loop distribution with aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90328 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon May 6 12:38:35 2019 New Revision: 270906 URL: https://gcc.gnu.org/viewcvs?rev=270906&root=gcc&view=rev Log: 2019-05-06 Richard Biener PR tree-optimization/90328 * tree-data-ref.h (dr_may_alias_p): Pass in the actual loop nest. * tree-data-ref.c (dr_may_alias_p): Check whether the clique is valid in the loop nest before using it. (initialize_data_dependence_relation): Adjust. * graphite-scop-detection.c (build_alias_set): Pass the SCOP enclosing loop as loop-nest to dr_may_alias_p. * gcc.dg/torture/pr90328.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr90328.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-scop-detection.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c trunk/gcc/tree-data-ref.h
[Bug tree-optimization/90328] [7/8/9 Regression] Wrong loop distribution with aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90328 Richard Biener changed: What|Removed |Added Known to work||10.0 Summary|[7/8/9/10 Regression] Wrong |[7/8/9 Regression] Wrong |loop distribution with |loop distribution with |aliasing|aliasing Known to fail||9.1.0 --- Comment #4 from Richard Biener --- Fixed on trunk sofar.
[Bug target/90362] or1k: Soft divide does not work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90362 Stafford Horne changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |shorne at gcc dot gnu.org
[Bug target/90362] or1k: Soft divide does not work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90362 Stafford Horne changed: What|Removed |Added Target||or1k Status|UNCONFIRMED |NEW URL||https://github.com/stffrdhr ||n/gcc/issues/6 Last reconfirmed||2019-05-06 CC||shorne at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Stafford Horne --- Proposed patch: diff --git a/libgcc/config/or1k/lib1funcs.S b/libgcc/config/or1k/lib1funcs.S index d2103923486..6d058977229 100644 --- a/libgcc/config/or1k/lib1funcs.S +++ b/libgcc/config/or1k/lib1funcs.S @@ -68,18 +68,18 @@ __udivmodsi3_internal: is not clobbered by this routine, and use that as to save a return address without creating a stack frame. */ - l.sfeqi r4, 0 /* division by zero; return 0. */ + l.sfeq r4, r0 /* division by zero; return 0. */ l.ori r11, r0, 0 /* initial quotient */ l.bf9f l.ori r12, r3, 0 /* initial remainder */ /* Given X/Y, shift Y left until Y >= X. */ l.ori r6, r0, 1 /* mask = 1 */ -1: l.sfltsir4, 0 /* y has msb set */ +1: l.sflts r4, r0 /* y has msb set */ l.bf2f l.sfltur4, r12 /* y < x */ l.add r4, r4, r4 /* y <<= 1 */ - l.bnf 1b + l.bf1b
