[Bug c++/100111] [10 Regression] `-fno-elide-constructors` with `constexpr` ctors causes ICE in GCC 10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100111 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:31447dcaf15c37e5b9c42b2984f4c8b649fe9b74 commit r10-9730-g31447dcaf15c37e5b9c42b2984f4c8b649fe9b74 Author: Jakub Jelinek Date: Fri Apr 16 17:37:07 2021 +0200 c++: Fix empty base stores in cxx_eval_store_expression [PR100111] In r11-6895 handling of empty bases has been fixed such that non-lval stores of empty classes are not added when the type of *valp doesn't match the type of the initializer, but as this testcase shows it is done only when *valp is non-NULL. If it is NULL, we still shouldn't add empty class constructors if the type of the constructor elt *valp points to doesn't match. 2021-04-16 Jakub Jelinek PR c++/100111 * constexpr.c (cxx_eval_store_expression): Don't add CONSTRUCTORs for empty classes into *valp when types don't match even when *valp is NULL. * g++.dg/cpp0x/constexpr-100111.C: New test. (cherry picked from commit 35e8b38a91d9fb49a4759649576f15e76c129d99)
[Bug target/99767] [9/10 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:3360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99767
--- Comment #9 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:1730b5d6793127b1a47970f44d60da8082bab514
commit r10-9729-g1730b5d6793127b1a47970f44d60da8082bab514
Author: Jakub Jelinek
Date: Fri Apr 16 11:44:04 2021 +0200
vectorizer: Remove dead scalar .COND_* calls from vectorized loops
[PR99767]
The following testcase ICEs because disabling of DCE means there are dead
stmts in the loop (though, in theory they could become dead only shortly
before if-conv through some optimization), ifcvt which goes through all
stmts in the loop if-converts them into .COND_DIV etc. internal fn calls
in the copy of the loop meant for vectorization only, the loop is
successfully vectorized but the particular .COND_* call is not because
it isn't a live statement and the scalar .COND_* remains in the IL until
expansion where it ICEs because these ifns only support vectors and not
scalars.
These ifns are similar to .MASK_{LOAD,STORE} in this behavior.
One possible fix could be to expand scalar versions of them during
expansion, basically undoing what if-conv did to create them, i.e.
expand them as the lhs = else; if (mask) { lhs = statement; } or so.
For .MASK_LOAD we have code to replace them in vect_transform_loop already
though (not needed for .MASK_STORE, as stores should be always live
and thus always vectorized), so this patch instead replaces .COND_*
similarly to .MASK_LOAD in that loop, with the small difference
that lhs = .MASK_LOAD (...); is replaced by lhs = 0; while
lhs = .COND_* (..., else_arg); is replaced by lhs = else_arg.
The statement must be dead, otherwise it would be vectorized, so I think
it is not a big deal we don't turn it back into multiple basic blocks etc.
(and it might be not possible to do that at that point).
2021-04-16 Jakub Jelinek
PR target/99767
* tree-vect-loop.c (vect_transform_loop): Don't remove just
dead scalar .MASK_LOAD calls, but also dead .COND_* calls - replace
them by their last argument.
* gcc.target/aarch64/pr99767.c: New test.
(cherry picked from commit b44ab138b7d4aaa5a9ee7956121ffc94777f6a42)
[Bug c++/99833] [8/9/10 Regression] structured binding + if init + generic lambda = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99833 --- Comment #13 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:06d50ebc9fb2761ed2bdda5e76adb4d47a8ca983 commit r10-9728-g06d50ebc9fb2761ed2bdda5e76adb4d47a8ca983 Author: Jakub Jelinek Date: Fri Apr 16 09:32:44 2021 +0200 c++: Fix up handling of structured bindings in extract_locals_r [PR99833] The following testcase ICEs in tsubst_decomp_names because the assumptions that the structured binding artificial var is followed in DECL_CHAIN by the corresponding structured binding vars is violated. I've tracked it to extract_locals* which is done for the constexpr IF_STMT. extract_locals_r when it sees a DECL_EXPR adds that decl into a hash set so that such decls aren't returned from extract_locals*, but in the case of a structured binding that just means the artificial var and not the vars corresponding to structured binding identifiers. The following patch fixes it by pushing not just the artificial var for structured bindings but also the other vars. 2021-04-16 Jakub Jelinek PR c++/99833 * pt.c (extract_locals_r): When handling DECL_EXPR of a structured binding, add to data.internal also all corresponding structured binding decls. * g++.dg/cpp1z/pr99833.C: New test. * g++.dg/cpp2a/pr99833.C: New test. (cherry picked from commit 20eb7a1891cfd7fa85295a236cebe0322d041edd)
[Bug rtl-optimization/99905] [8/9/10 Regression] wrong code with -mno-mmx -mno-sse since r7-4540-gb229ab2a712ccd44
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99905
--- Comment #11 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:c965254e5af9dc68444e0289250c393ae0cd6131
commit r10-9727-gc965254e5af9dc68444e0289250c393ae0cd6131
Author: Jakub Jelinek
Date: Tue Apr 13 01:01:45 2021 +0200
combine: Fix up expand_compound_operation [PR99905]
The following testcase is miscompiled on x86_64-linux.
expand_compound_operation is called on
(zero_extract:DI (mem/c:TI (reg/f:DI 16 argp) [3 i+0 S16 A128])
(const_int 16 [0x10])
(const_int 63 [0x3f]))
so mode is DImode, inner_mode is TImode, pos 63, len 16 and modewidth 64.
A couple of lines above the problematic spot we have:
if (modewidth >= pos + len)
{
tem = gen_lowpart (mode, XEXP (x, 0));
where the code uses gen_lowpart and then shift left/right to extract it
in mode. But the guarding condition is false - 64 >= 63 + 16
and so we enter the next condition, where the code shifts XEXP (x, 0)
right by pos and then adds AND. It does so incorrectly though.
Given the modewidth < pos + len, inner_mode must be necessarily larger
than mode and XEXP (x, 0) has the innermode, but it was calling
simplify_shift_const with mode rather than inner_mode, which meant
inconsistent arguments to simplify_shift_const and in this case made
a DImode MEM shift out of it.
The following patch fixes it, by doing the shift in inner_mode properly
and then after the shift doing the lowpart subreg and masking already
in mode.
2021-04-13 Jakub Jelinek
PR rtl-optimization/99905
* combine.c (expand_compound_operation): If pos + len > modewidth,
perform the right shift by pos in inner_mode and then convert to
mode,
instead of trying to simplify a shift of rtx with inner_mode by pos
as if it was a shift in mode.
* gcc.target/i386/pr99905.c: New test.
(cherry picked from commit ffc4155b6e45b8ab71d49a4b584f7cacb693e6b9)
[Bug debug/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99830 --- Comment #17 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4ac7483ede91fef7cfd548ff6e30e46eeb9d95ae commit r10-9726-g4ac7483ede91fef7cfd548ff6e30e46eeb9d95ae Author: Jakub Jelinek Date: Tue Apr 13 01:00:48 2021 +0200 combine: Don't fold away side-effects in simplify_and_const_int_1 [PR99830] Here is an alternate patch for the PR99830 bug. As discussed on IRC and in the PR, the reason why a (clobber:TI (const_int 0)) has been propagated into the debug insns is that it got optimized away during simplification from the i3 instruction pattern. And that happened because simplify_and_const_int_1 (SImode, varop, 255) with varop of (ashift:SI (subreg:SI (and:TI (clobber:TI (const_int 0 [0])) (const_int 255 [0xff])) 0) (const_int 16 [0x10])) was called and through nonzero_bits determined that (whatever << 16) & 255 is const0_rtx. It is, but if there are side-effects in varop and such clobbers are considered as such, we shouldn't optimize those away. 2021-04-13 Jakub Jelinek PR debug/99830 * combine.c (simplify_and_const_int_1): Don't optimize varop away if it has side-effects. * gcc.dg/pr99830.c: New test. (cherry picked from commit 9c1c8ad8339d551ac91a7af5614f29b9a687189a)
[Bug c/99990] [8/9/10 Regression] ICE in gimplifier on invalid va_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:91e076f3a66c1c9f6aa51e9d53d07803606e3bf1 commit r10-9725-g91e076f3a66c1c9f6aa51e9d53d07803606e3bf1 Author: Jakub Jelinek Date: Sat Apr 10 17:01:54 2021 +0200 c: Avoid clobbering TREE_TYPE (error_mark_node) [PR0] The following testcase ICEs during error recovery, because finish_decl overwrites TREE_TYPE (error_mark_node), which better should stay always to be error_mark_node. 2021-04-10 Jakub Jelinek PR c/0 * c-decl.c (finish_decl): Don't overwrite TREE_TYPE of error_mark_node. * gcc.dg/pr0.c: New test. (cherry picked from commit 9f7d77bd6d65aa1cf2e195d3776052705c6e636b)
[Bug lto/99849] [8/9/10 Regression] ICE in expand_expr_real_1, at expr.c:11556 since r5-5407-g30d5d8c5189064c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99849 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2e57bc7eedb084869d17fe07b538d907b8fee819 commit r10-9724-g2e57bc7eedb084869d17fe07b538d907b8fee819 Author: Jakub Jelinek Date: Sat Apr 10 12:49:01 2021 +0200 expand: Fix up LTO ICE with COMPOUND_LITERAL_EXPR [PR99849] The gimplifier optimizes away COMPOUND_LITERAL_EXPRs, but they can remain in the form of ADDR_EXPR of COMPOUND_LITERAL_EXPRs in static initializers. By the TREE_STATIC check I meant to check that the underlying decl of the compound literal is a global rather than automatic variable which obviously can't be referenced in static initializers, but unfortunately with LTO it might end up in another partition and thus be DECL_EXTERNAL instead. 2021-04-10 Jakub Jelinek PR lto/99849 * expr.c (expand_expr_addr_expr_1): Test is_global_var rather than just TREE_STATIC on COMPOUND_LITERAL_EXPR_DECLs. * gcc.dg/lto/pr99849_0.c: New test. (cherry picked from commit 22aede7a1228617661105048a91fddd8797e141b)
[Bug rtl-optimization/98601] [8/9/10 Regression] aarch64: ICE in rtx_addr_can_trap_p_1, at rtlanal.c:467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98601 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e68ac8c2b46997af1464f2549ac520a192c928b1 commit r10-9723-ge68ac8c2b46997af1464f2549ac520a192c928b1 Author: Jakub Jelinek Date: Sat Apr 10 12:46:09 2021 +0200 rtlanal: Another fix for VOIDmode MEMs [PR98601] This is a sequel to the PR85022 changes, inline-asm can (unfortunately) introduce VOIDmode MEMs and in PR85022 they have been changed so that we don't pretend we know their size (as opposed to assuming they have zero size). This time we ICE in rtx_addr_can_trap_p_1 because it assumes that all memory but BLKmode has known size. The patch just treats VOIDmode MEMs like BLKmode in that regard. And, the STRICT_ALIGNMENT change is needed because VOIDmode has GET_MODE_SIZE of 0 and we don't want to check if something is a multiple of 0. 2021-04-10 Jakub Jelinek PR rtl-optimization/98601 * rtlanal.c (rtx_addr_can_trap_p_1): Allow in assert unknown size not just for BLKmode, but also for VOIDmode. For STRICT_ALIGNMENT unaligned_mems handle VOIDmode like BLKmode. * gcc.dg/torture/pr98601.c: New test. (cherry picked from commit 7a493fcd27d6a1af896c4f5ef4ab1e0afe8a839d)
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859 --- Comment #20 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e961da38630c892dfc0723e0726b6a0b0833e951 commit r10-9722-ge961da38630c892dfc0723e0726b6a0b0833e951 Author: Jakub Jelinek Date: Thu Apr 8 17:15:39 2021 +0200 c++: Don't cache constexpr functions which are passed pointers to heap or static vars being constructed [PR99859] When cxx_bind_parameters_in_call is called e.g. on a method on an automatic variable, we evaluate the argument and because ADDR_EXPR of an automatic decl is not TREE_CONSTANT, we set *non_constant_args and don't cache it. But when it is called on an object located on the heap (allocated using C++20 constexpr new) where we represent it as TREE_STATIC artificial var, or when it is called on a static var that is currently being constructed, such ADDR_EXPRs are TREE_CONSTANT and we happily cache such calls, but they can in those cases have side-effects in the heap or static var objects and so caching them means such side-effects will happen only once and not as many times as that method or function is called. Furthermore, as Patrick mentioned in the PR, the argument doesn't need to be just ADDR_EXPR of the heap or static var or its components, but it could be a CONSTRUCTOR that has the ADDR_EXPR embedded anywhere. And the incorrectly cached function doesn't need to modify the pointed vars or their components, but some caller could be changing them in between the call that was cached and the call that used the cached result. The following patch fixes it by setting *non_constant_args also when the argument contains somewhere such an ADDR_EXPR, either of a heap artificial var or component thereof, or of a static var currently being constructed (where for that it uses the same check as cxx_eval_store_expression, ctx->global->values.get (...); addresses of other static variables would be rejected by cxx_eval_store_expression and therefore it is ok to cache such calls). 2021-04-08 Jakub Jelinek PR c++/99859 * constexpr.c (addr_of_non_const_var): New function. (cxx_bind_parameters_in_call): Set *non_constant_args to true even if cp_walk_tree on arg with addr_of_non_const_var callback returns true. * g++.dg/cpp1y/constexpr-99859-1.C: New test. * g++.dg/cpp1y/constexpr-99859-2.C: New test. * g++.dg/cpp2a/constexpr-new18.C: New test. * g++.dg/cpp2a/constexpr-new19.C: New test. (cherry picked from commit 559d2f1e0eafd96c19dc5324db1a466286c0e7fc)
[Bug rtl-optimization/99863] [10 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #21 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7a2f91d413eb7a3eb0ba52c7ac9618a35addd12a commit r10-9721-g7a2f91d413eb7a3eb0ba52c7ac9618a35addd12a Author: Jakub Jelinek Date: Sat Apr 3 10:07:09 2021 +0200 dse: Fix up hard reg conflict checking in replace_read [PR99863] Since PR37922 fix RTL DSE has hard register conflict checking in replace_read, so that if the replacement sequence sets (or typically just clobbers) some hard register (usually condition codes) we verify that hard register is not live. Unfortunately, it compares the hard reg set clobbered/set by the sequence (regs_set) against the currently live hard register set, but it then emits the insn sequence not at the current insn position, but before store_insn->insn. So, we should not compare against the current live hard register set, but against the hard register live set at the point of the store insn. Fortunately, we already have that remembered in store_insn->fixed_regs_live. In addition to bootstrapping/regtesting this patch on x86_64-linux and i686-linux, I've also added statistics gathering and it seems the only place where we end up rejecting the replace_read is the newly added testcase (the PR37922 is no longer effective at that) and fixed_regs_live has been always non-NULL at the if (store_insn->fixed_regs_live) spot. Rather than having there an assert, I chose to just keep regs_set as is, which means in that hypothetical case where fixed_regs_live wouldn't be computed for some store we'd still accept sequences that don't clobber/set any hard registers and just punt on those that clobber/set those. 2021-04-03 Jakub Jelinek PR rtl-optimization/99863 * dse.c (replace_read): Drop regs_live argument. Instead of regs_live, use store_insn->fixed_regs_live if non-NULL, otherwise punt if insns sequence clobbers or sets any hard registers. * gcc.target/i386/pr99863.c: New test. (cherry picked from commit 9c7473688e78dc41fd4312a983453df195dd7786)
[Bug target/97653] [11 Regression] Incorrect long double calculation with -mabi=ibmlongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #19 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:8642b73a0f0df1f8e1e2d2102d67a76f8ed0a255
commit r10-9720-g8642b73a0f0df1f8e1e2d2102d67a76f8ed0a255
Author: Jakub Jelinek
Date: Sat Apr 3 10:05:32 2021 +0200
rs6000: Fix up libgcc ABI when built with --with-long-double-format=ieee
[PR97653]
__floatunditf and __fixtfdi and a couple of other libgcc{.a,_s.so}
entrypoints for backwards compatibility should mean IBM double double
handling (i.e. IFmode), gcc emits such calls for that format and
form IEEE long double emits *kf* instead.
When gcc is configured without --with-long-double-format=ieee ,
everything is fine, but when it is not, we need to compile those
libgcc sources with -mno-gnu-attribute -mabi=ibmlongdouble.
The following snippet in libgcc/config/rs6000/t-linux was attempting
to ensure that, and for some routines it works fine (e.g. for _powitf2).
But, due to 4 different types of bugs it doesn't work for most of those
functions, which means that in --with-long-double-format=ieee
configured gcc those *tf* entrypoints instead handle the long double
arguments as if they were KFmode.
The bugs are:
1) the first few objs properly use $(objext) as suffix, but
several other contain a typo and use $(object) instead,
which is a variable that isn't set to anything, so we don't
add .o etc. extensions
2) while unsigned fix are properly called _fixuns*, unsigned float
are called _floatun* (without s), but the var was using there
the extra s and so didn't match
3) the variable didn't cover any of the TF <-> TI conversions,
only TF <-> DI conversions
4) nothing in libgcc_s.so was handled, as those object files are
called *_s.o rather than *.o and IBM128_SHARED_OBJS used wrong
syntax of the GNU make substitution reference, which should be
$(var:a=b) standing for $(patsubst a,b,$(var)) but it used
$(var:a:b) instead
2021-04-03 Jakub Jelinek
PR target/97653
* config/rs6000/t-linux (IBM128_STATIC_OBJS): Fix spelling, use
$(objext) instead of $(object). Use _floatunditf instead of
_floatunsditf. Add tf <-> ti conversion objects.
(IBM128_SHARED_OBJS): Use proper substitution reference syntax.
(cherry picked from commit cda41ce0e8414aec59e6b9fbe645d96e6e8193e2)
Re: On US corporate influence over Free Software and the GCC Steering Committee
On 20/04/2021 08:54, Giacomo Tesio wrote: > Hi GCC developers, > > just to further clarify why I think the current Steering Committee is highly > problematic, > I'd like you to give a look at this commit > message over Linux MAINTAINERS > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=4acd47644ef1e1c8f8f5bc40b7cf1c5b9bcbbc4e > > Here the relevant excerpt (but please go chech the quotation): > > "As an IBM employee, you are not allowed to use your gmail account to work in > any way > on VNIC. You are not allowed to use your personal email account as a "hobby". > You > are an IBM employee 100% of the time. > Please remove yourself completely from the maintainers file. I grant you a 1 > time > exception on contributions to VNIC to make this change." > > > This is happened yesterday (literally). I know nothing of this case other than the link you sent. But it seems to me that the complaint from IBM is that the developer used his private gmail address here rather than his IBM address. It is normal practice in most countries that if you are employed full time to do a certain type of job, then you can't do the same kind of work outside of the job without prior arrangement with the employer. That applies whether it is extra paid work, or unpaid (hobby) work. This is partly because it can quickly become a conflict of interests, and partly because you are supposed to be refreshed and ready for work each day and not tired out from an all-night debugging session on a different project. Usually employers are quite flexible about these things unless there is a clear conflict of interests (like working on DB2 during the day, and Postgresql in the evening). Some employers prefer to keep things standardised and rigid. A company like IBM that is heavily involved in Linux kernel coding will want to keep their copyrights and attributions clear. So if they have an employee that is working on this code - whether it is part of their day job or not - it makes sense to insist that attributions, maintainer contact information and copyrights all make it clear that the work is done by an IBM employee. It is not only IBM's right to insist on this, it might also be a legal obligation. (It is quite possible that this guy's manager could have expressed things a bit better - we are not privy to the rest of the email or any other communication involved.) This is precisely why copyright assignment for the FSF can involve complicated forms and agreements from contributors' employers. > > And while this is IBM, the other US corporations with affiliations in > the Steering Committee are no better: > https://gcc.gnu.org/pipermail/gcc/2021-April/235777.html > I can't see any relevance in that post other than your "big corporations are completely evil because there are examples of them being bad" comments. > I can understand that some of you consider working for such corporations "a > joy". > But for the rest of us, and to most people outside the US, their influence > over the leadership of GCC is a threat. Please stop claiming to speak for anyone but yourself. You certainly do not speak for /me/. I don't work for "such corporations", I am outside the US, but I do not see IBM or others having noticeable influence over gcc and thus there is no threat. David
[wwwdocs] Remove part about coordination with FSF.
Pushed after Jakub's confirmation. We do not coordinate major release with FSF. Martin --- htdocs/releasing.html | 3 --- 1 file changed, 3 deletions(-) diff --git a/htdocs/releasing.html b/htdocs/releasing.html index d51d6fc7..cb7bb5fe 100644 --- a/htdocs/releasing.html +++ b/htdocs/releasing.html @@ -121,9 +121,6 @@ to point to the online-documentation for the branch. and info-...@gnu.org mailing lists. Make sure that most mirrors have retrieved the new release already. - -In the case of a major release, coordinate announcements with the -FSF. -- 2.31.1
Re: move selftests into their own files?
FWIW, I agree with Martin. Source files with lots of tests make finding things difficult. For example, value-range.cc has 400 lines of tests (which I wrote ;-)). Even though these tests have proven invaluable in finding bugs, they make navigating the source file cumbersome. Aldy On Tue, Apr 20, 2021 at 1:27 AM Martin Sebor via Gcc-patches wrote: > > On 4/19/21 3:13 PM, Koning, Paul wrote: > > > > > >> On Apr 19, 2021, at 4:50 PM, Martin Sebor via Gcc-patches > >> wrote: > >> > >> On 4/19/21 2:03 PM, David Malcolm wrote: > >>> On Mon, 2021-04-19 at 13:47 -0600, Martin Sebor via Gcc-patches wrote: > The selftests at the end of many source files are only rarely read > or modified, but they contribute to the size/complexity of the files > and make moving within the rest of the code more difficult. > > >>> FWIW I prefer having the tests in the same file as the code they test. > Would anyone be opposed to moving any of them into new files of their > own? E.g., those in tree.c to tree-tests.c, etc.? I would be happy > to do this for a subset of these, with the goal of eventually moving > all of them and adding new ones accordingly. > >>> Having the selftests in the same source file as the thing they test > >>> allows for the selftest to use "static" declarations and anonymous > >>> namespaces from that file. For example, the selftests in diagnostic- > >>> show-locus.c make use of various things declared in an anonymous > >>> namespace in that file. If I had to move the selftests to a different > >>> file, I'd have to expose these interfaces, which I don't want to do. > >> > >> I was actually thinking of just #including each foo-tests.c file > >> to bring in the code right where it is now, so this shouldn't be > >> a problem. Would that work for you? > >> > >> Martin > > > > How does that help the problem you said need to be solved? If having self > > test code be part of the compilation unit makes modifying things more > > difficult, it doesn't matter whether that code is in the compilation unit > > due to being in the main source file, or due to being a #include. > > The self tests make the sources bigger and so harder to move around > in and difficult to find just the calls to tested functions made > from elsewhere in the file or from other parts of the compiler (i.e., > not tests). They are only rarely relevant when reading or changing > the file. > > Keeping them separate from the code they exercise will be helpful > to me and I assumed to others as well. But I wouldn't want to make > some common tasks difficult, so if you or someone else has one that > would be made so by it, I won't pursue it. Do you? > > Martin >
[Bug c/100150] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #2 from David Binderman --- Starting git bisect ...
Re: [PATCH] [libstdc++] Refactor/cleanup of atomic wait implementation
On 19/04/21 12:23 -0700, Thomas Rodgers wrote:
namespace __detail
{
-using __platform_wait_t = int;
-
-constexpr auto __atomic_spin_count_1 = 16;
-constexpr auto __atomic_spin_count_2 = 12;
-
-template
- inline constexpr bool __platform_wait_uses_type
#ifdef _GLIBCXX_HAVE_LINUX_FUTEX
- = is_same_v, __platform_wait_t>;
+using __platform_wait_t = int;
#else
- = false;
+using __platform_wait_t = uint64_t;
+#endif
+static constexpr size_t __platform_wait_alignment
+ = alignof(__platform_wait_t);
The value of this constant can't be alignof(__platform_wait_t). As
discussed, a futex always needs 4-byte alignment, but on at least one
target that GCC supports, alignof(int) == 2.
+ } // namespace __detail
+
+ template
+inline constexpr bool __platform_wait_uses_type
+#ifdef _GLIBCXX_HAVE_PLATFORM_WAIT
+ = is_scalar_v<_Tp>
+ && ((sizeof(_Tp) == sizeof(__detail::__platform_wait_t))
+ && (alignof(_Tp*) >= alignof(__detail::__platform_wait_t)));
Now that we have the __platform_wait_alignment it should be used here
(so that when we fix the constant, this gets fixed too).
+#else
+ = false;
#endif
+ namespace __detail
+ {
#ifdef _GLIBCXX_HAVE_LINUX_FUTEX
+#define _GLIBCXX_HAVE_PLATFORM_WAIT 1
enum class __futex_wait_flags : int
{
#ifdef _GLIBCXX_HAVE_LINUX_FUTEX_PRIVATE
+
+ static __waiter_type&
+ _S_for(const void* __addr)
+ {
+ static_assert(sizeof(__waiter_type) == sizeof(__waiter_pool_base));
+ auto& res = __waiter_pool_base::_S_for(__addr);
+ return reinterpret_cast<__waiter_type&>(res);
+ }
Nit: this is still indented as if it were a function template.
: _M_a(__expected) { }
@@ -73,8 +73,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_GLIBCXX_ALWAYS_INLINE void
wait() const noexcept
{
- auto const __old = __atomic_impl::load(&_M_a, memory_order::acquire);
- std::__atomic_wait(&_M_a, __old, [this] { return this->try_wait(); });
+ auto const __pred = [this] { return this->try_wait(); };
+ std::__atomic_wait_address(&_M_a, __pred);
}
_GLIBCXX_ALWAYS_INLINE void
@@ -85,7 +85,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
private:
-alignas(__alignof__(ptrdiff_t)) ptrdiff_t _M_a;
+alignas(__alignof__(__detail::__platform_wait_t))
__detail::__platform_wait_t _M_a;
This should use the new constant too.
RE: [PATCH] Adjust guality xfails for aarch64*-*-*
> -Original Message-
> From: Richard Sandiford
> Sent: 19 April 2021 20:34
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Kyrylo Tkachov
>
> Subject: [PATCH] Adjust guality xfails for aarch64*-*-*
>
> This patch gives clean guality.exp test results for aarch64-linux-gnu
> with modern (top-of-tree) gdb.
>
> For people using older gdbs, it will trade one set of noisy results for
> another set. I still think it's better to have the xfails based on
> one “clean” and “modern” run rather than have FAILs and XPASSes for
> all runs.
>
> It's hard to tell which of these results are aarch64-specific and
> which aren't. If other target maintainers want to do something similar,
> and are prepared to assume the same gdb version, then it should become
> clearer over time which ones are target-specific and which aren't.
>
> There are no new skips here, so changes in test results will still
> show up as XPASSes.
>
> I've not analysed the failures or filed PRs for them. In some
> ways the guality directory itself seems like the best place to
> start looking for xfails, if someone's interested in working
> in this area.
>
> Tested on aarch64-linux-gnu. I'd like to install this once the
> earlier no-opts/any-opts patch is in, but please let me know
> if you think it's a bad idea.
It's okay with me.
Thanks,
Kyrill
>
> Richard
>
>
> gcc/testsuite/
> * gcc.dg/guality/example.c: Update aarch64*-*-* xfails.
> * gcc.dg/guality/guality.c: Likewise.
> * gcc.dg/guality/inline-params.c: Likewise.
> * gcc.dg/guality/loop-1.c: Likewise.
> * gcc.dg/guality/pr36728-1.c: Likewise.
> * gcc.dg/guality/pr36728-2.c: Likewise.
> * gcc.dg/guality/pr36728-3.c: Likewise.
> * gcc.dg/guality/pr41447-1.c: Likewise.
> * gcc.dg/guality/pr54200.c: Likewise.
> * gcc.dg/guality/pr54519-1.c: Likewise.
> * gcc.dg/guality/pr54519-2.c: Likewise.
> * gcc.dg/guality/pr54519-3.c: Likewise.
> * gcc.dg/guality/pr54519-4.c: Likewise.
> * gcc.dg/guality/pr54519-5.c: Likewise.
> * gcc.dg/guality/pr54519-6.c: Likewise.
> * gcc.dg/guality/pr54693-2.c: Likewise.
> * gcc.dg/guality/pr56154-1.c: Likewise.
> * gcc.dg/guality/pr59776.c: Likewise.
> * gcc.dg/guality/pr68860-1.c: Likewise.
> * gcc.dg/guality/pr68860-2.c: Likewise.
> * gcc.dg/guality/pr90074.c: Likewise.
> * gcc.dg/guality/pr90716.c: Likewise.
> * gcc.dg/guality/sra-1.c: Likewise.
> ---
> gcc/testsuite/gcc.dg/guality/example.c | 3 +-
> gcc/testsuite/gcc.dg/guality/guality.c | 2 +-
> gcc/testsuite/gcc.dg/guality/inline-params.c | 2 +-
> gcc/testsuite/gcc.dg/guality/loop-1.c| 2 +-
> gcc/testsuite/gcc.dg/guality/pr36728-1.c | 2 +-
> gcc/testsuite/gcc.dg/guality/pr36728-2.c | 30 ++--
> gcc/testsuite/gcc.dg/guality/pr36728-3.c | 2 +-
> gcc/testsuite/gcc.dg/guality/pr41447-1.c | 1 +
> gcc/testsuite/gcc.dg/guality/pr54200.c | 2 +-
> gcc/testsuite/gcc.dg/guality/pr54519-1.c | 8 +++---
> gcc/testsuite/gcc.dg/guality/pr54519-2.c | 2 +-
> gcc/testsuite/gcc.dg/guality/pr54519-3.c | 8 +++---
> gcc/testsuite/gcc.dg/guality/pr54519-4.c | 2 +-
> gcc/testsuite/gcc.dg/guality/pr54519-5.c | 2 +-
> gcc/testsuite/gcc.dg/guality/pr54519-6.c | 2 +-
> gcc/testsuite/gcc.dg/guality/pr54693-2.c | 2 +-
> gcc/testsuite/gcc.dg/guality/pr56154-1.c | 2 +-
> gcc/testsuite/gcc.dg/guality/pr59776.c | 12
> gcc/testsuite/gcc.dg/guality/pr68860-1.c | 2 +-
> gcc/testsuite/gcc.dg/guality/pr68860-2.c | 2 +-
> gcc/testsuite/gcc.dg/guality/pr90074.c | 4 +--
> gcc/testsuite/gcc.dg/guality/pr90716.c | 2 +-
> gcc/testsuite/gcc.dg/guality/sra-1.c | 8 +++---
> 23 files changed, 53 insertions(+), 51 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.dg/guality/example.c
> b/gcc/testsuite/gcc.dg/guality/example.c
> index 26d25c28590..6f1c017a253 100644
> --- a/gcc/testsuite/gcc.dg/guality/example.c
> +++ b/gcc/testsuite/gcc.dg/guality/example.c
> @@ -1,5 +1,6 @@
> -/* { dg-do run { xfail *-*-* } } */
> +/* { dg-do run { xfail { ! aarch64*-*-* } } } */
> /* { dg-options "-g" } */
> +/* { dg-xfail-run-if "" aarch64*-*-* "*" { "-O[01g]" } } */
>
> #define GUALITY_DONT_FORCE_LIVE_AFTER -1
>
> diff --git a/gcc/testsuite/gcc.dg/guality/guality.c
> b/gcc/testsuite/gcc.dg/guality/guality.c
> index db015e6a558..a4de5646fc7 100644
> --- a/gcc/testsuite/gcc.dg/guality/guality.c
> +++ b/gcc/testsuite/gcc.dg/guality/guality.c
> @@ -1,4 +1,4 @@
> -/* { dg-do run { xfail *-*-* } } */
> +/* { dg-do run { xfail { ! aarch64*-*-* } } } */
> /* { dg-options "-g" } */
> /* { dg-require-effective-target alloca } */
>
> diff --git a/gcc/testsuite/gcc.dg/guality/inline-params.c
> b/gcc/testsuite/gcc.dg/guality/inline-params.c
> index f4c5f15094c..6be240a28d2 100644
> --- a/gcc/testsuite/gcc.dg/guality/inline-params.c
> +++
[PATCH][DOC] Document ranger-logical-depth in invoke.texi
Pushed as obvious to master (and releases/gcc-11 branch).
Martin
gcc/ChangeLog:
* doc/invoke.texi: Document new param.
---
gcc/doc/invoke.texi | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8b70fdf580d..a1b50406048 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -14364,6 +14364,10 @@ The parameter is used only in GIMPLE FE.
The maximum number of 'after supernode' exploded nodes within the analyzer
per supernode, before terminating analysis.
+@item ranger-logical-depth
+Maximum depth of logical expression evaluation ranger will look through
+when evaluting outgoing edge ranges.
+
@item openacc-kernels
Specify mode of OpenACC `kernels' constructs handling.
With @option{--param=openacc-kernels=decompose}, OpenACC `kernels'
--
2.31.1
Re: [Patch, fortran] PR100110 - Parameterized Derived Types, problems with global variable
Hi Tobias, Thanks. Commit r11-8255-g67378cd63d62bf0c69e966d1d202a1e586550a68. By the way, I did check that there were no problems with pdt_26.f03 reported by valgrind, given the decrease in the malloc count. Cheers Paul On Mon, 19 Apr 2021 at 14:08, Tobias Burnus wrote: > Hi Paul, > > On 19.04.21 14:40, Paul Richard Thomas via Gcc-patches wrote: > > I was just about to announce that I will only do backports and > regressions, > > while I finally attack the fundamental problem with the representation of > > Parameterized Derived Types. Then this PR came up that was such clear low > > hanging fruit that I decided to fix it right away. > > > > Regtests on FC33/x86_64 - OK for mainline? > > LGTM. > > Thanks, > > Tobias > > - > Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank > Thürauf > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[Bug gcov-profile/100145] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100145
Richard Biener changed:
What|Removed |Added
Component|ipa |gcov-profile
--- Comment #2 from Richard Biener ---
So we get optimize_edge_for_size_p () returning OPTIMIZE_SIZE_BALANCED and
thus optimize_edge_for_speed_p which is
340 bool
341 optimize_edge_for_speed_p (edge e)
342 {
343 return !optimize_edge_for_size_p (e);
344 }
return false. And that's likely because this is 'main'. At -O2 BB counts
are broken:
[local count: 1073741824]:
c = 0;
b.1_7 = b;
if (b.1_7 != 0)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 708669600]:
goto ; [100.00%]
[local count: 3318838410]:
c = 1;
[local count: 1073741824]:
d = 1;
here 3->4 artificially appears 'hot'. The bogus counts appear during IPA
inlining of g() into main.
[Bug middle-end/100144] [OpenMP] Data race with "omp parallel master taskloop ... shared(scalar)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100144 --- Comment #2 from Tobias Burnus --- Sollve_vv's testcase has been fixed: Issue: https://github.com/SOLLVE/sollve_vv/issues/324 Patch test_parallel_master_taskloop.c: https://github.com/SOLLVE/sollve_vv/pull/325 Patch test_parallel_master_taskloop_device.c: https://github.com/SOLLVE/sollve_vv/pull/326
[Bug ipa/100145] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100145
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |ipa
Keywords||missed-optimization
Ever confirmed|0 |1
Last reconfirmed||2021-04-20
CC||hubicka at gcc dot gnu.org,
||marxin at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Version|unknown |11.0
--- Comment #1 from Richard Biener ---
At -O2 we optimize things in thread3, at -O3 we have a PHI less there and thus
do no backwards threading which is because 'c' wasn't PREd for some reason
(-fno-tree-vectorize or -fno-tree-partial-pre do not help)
int main ()
{
- int D.2001;
- int b.1_7;
- int prephitmp_16;
+ int _1;
+ int b.1_6;
[local count: 1073741824]:
c = 0;
- b.1_7 = b;
- if (b.1_7 != 0)
+ b.1_6 = b;
+ if (b.1_6 != 0)
goto ; [34.00%]
else
goto ; [66.00%]
- [local count: 3318838410]:
+ [local count: 365072224]:
c = 1;
[local count: 1073741824]:
- # prephitmp_16 = PHI <0(2), 1(3)>
d = 1;
- if (prephitmp_16 > 100)
+ _1 = c;
+ if (_1 > 100)
goto ; [33.00%]
else
goto ; [67.00%]
the issue seems to be the guessed profile (but BB counts are the same!):
+Skipping partial redundancy for expression {mem_ref<0B>,addr_expr<>}@.MEM_7
(
0001), no redundancy on to be optimized for speed edge
so that leaves the "global" hot count we IPA compute somehow? Honza?
[PATCH] testsuite: Fix gcc.dg/vect/bb-slp-39.c on IBM Z
On IBM Z the aliasing stores are realized through one element vector
instructions, if no cost model for vectorization is used which is the
default according to vect.exp. Fixed by changing the number of times
the pattern must be found in the dump.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/bb-slp-39.c: Change number of times the pattern
must match for target IBM Z only.
Ok for mainline?
---
gcc/testsuite/gcc.dg/vect/bb-slp-39.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-39.c
b/gcc/testsuite/gcc.dg/vect/bb-slp-39.c
index 255bb1095dc..ee596cfa08b 100644
--- a/gcc/testsuite/gcc.dg/vect/bb-slp-39.c
+++ b/gcc/testsuite/gcc.dg/vect/bb-slp-39.c
@@ -16,4 +16,5 @@ void foo (double *p)
}
/* See that we vectorize three SLP instances. */
-/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 3 "slp2" }
} */
+/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 3 "slp2" {
target { ! s390*-*-* } } } } */
+/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 5 "slp2" {
target { s390*-*-* } } } } */
--
2.23.0
[Bug c/100150] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #1 from David Binderman --- Created attachment 50634 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50634=edit x86_64 object module
[Bug ipa/100112] missed optimization for dead code elimination at -O3, -Os (vs. -O1, -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100112 Richard Biener changed: What|Removed |Added Component|tree-optimization |ipa Keywords||missed-optimization Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Version|unknown |11.0 Last reconfirmed||2021-04-20 --- Comment #1 from Richard Biener --- It's very late eliminated at -O1 (DCE7) while with -O3 we still have [local count: 1073741824]: _2 = e; _3 = _2 + 1; e = _3; c.1_4 = c; if (c.1_4 == 0B) goto ; [48.88%] else goto ; [51.12%] [local count: 524845000]: foo (); there. In the end it's some IPA issue, failing to make 'c' readonly at -O3 vs. -O1.
[Bug c/100150] New: ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 Bug ID: 100150 Summary: ice in bp_unpack_string Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 50633 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50633=edit x86_64 object module For recent gcc, I get $ /home/dcb/gcc/results/bin/gcc -o /dev/null src/bin/tolua.o lib/libtolua++-5.3.so lto1: internal compiler error: Segmentation fault 0xbdfb79 crash_signal(int) ../../trunk.git/gcc/toplev.c:327 0x70d3a0 bp_unpack_string(data_in*, bitpack_d*) ../../trunk.git/gcc/data-streamer-in.c:112 0xae67df cl_optimization_stream_in(data_in*, bitpack_d*, cl_optimization*) /home/dcb/gcc/working/gcc/options-save.c:12731 0xe44dda streamer_read_tree_bitfields(lto_input_block*, data_in*, tree_node*) ../../trunk.git/gcc/tree-streamer-in.c:552 The fault first seems to occur sometime between git hash 4a1493f0603262a7 and 329d2f0df7d6d22c.
[Bug tree-optimization/100113] missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100113 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-20 Ever confirmed|0 |1 Version|unknown |11.0 --- Comment #1 from Richard Biener --- dom3 manages to optimize it with -O1 but it gets different input with -O3.
[Bug target/99960] MVE: Wrong code storing V2DI vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99960 Alex Coplan changed: What|Removed |Added Last reconfirmed||2021-04-20 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org --- Comment #2 from Alex Coplan --- Taking a look at this.
Re: On US corporate influence over Free Software and the GCC Steering Committee
Obviously the dude was not Eric Raymond, because he would have sent the IBM Fuckhead an appropriate reply. These are the developers at IBM, who after being watched by the IBM Panopticon, they obey! Now repeat after me, "Whenever I hear the voice say, 'Now, listen to me, ' I will obey." "When I hear the voice say, 'Now, listen to me, ' I will obey." > Sent: Tuesday, April 20, 2021 at 7:37 PM > From: "Eric Botcazou" > To: "Giacomo Tesio" > Cc: gcc@gcc.gnu.org > Subject: Re: On US corporate influence over Free Software and the GCC > Steering Committee > > > Here the relevant excerpt (but please go chech the quotation): > > > > "As an IBM employee, you are not allowed to use your gmail account to work > > in any way on VNIC. You are not allowed to use your personal email account > > as a "hobby". You are an IBM employee 100% of the time. > > Please remove yourself completely from the maintainers file. I grant you a 1 > > time exception on contributions to VNIC to make this change." > > > > > > This is happened yesterday (literally). > > Troubling indeed, but this might just be an overzealous manager. IBM, like > other corporations, has made significant technical contributions to GCC over > the years, for example the scheduler and the vectorizer, and thus has assigned > the copyright of these contributions to the FSF. > > -- > Eric Botcazou > > >
[Bug c++/61259] [Regression 8/9/10/11] Spurious "ISO C++ forbids zero-size array" warning with -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61259
Volker Reichelt changed:
What|Removed |Added
Known to fail||10.3.0, 4.4.0
CC||reichelt at gcc dot gnu.org
Summary|Spurious "ISO C++ forbids |[Regression 8/9/10/11]
|zero-size array" warning|Spurious "ISO C++ forbids
|with -pedantic |zero-size array" warning
||with -pedantic
Last reconfirmed|2014-05-20 00:00:00 |2021-4-20
Keywords||rejects-valid
--- Comment #4 from Volker Reichelt ---
If you compile the code with "-pedantic-errors" the code is wrongly rejected,
so marking it as rejects-valid.
Self-contained example:
==
int foo(int x[2])
{
int i(int(x[0])*1);
return i;
}
==
Re: removing toxic emailers
On Tue, 20 Apr 2021 at 04:47, Frosku wrote:
>
> On Mon Apr 19, 2021 at 4:06 PM BST, Thomas Rodgers wrote:
> > Google doesn't pay anybody to work on GCC all day. You know nothing
> > about
> > GCC or the "problems" you're complaining about. Your input to this
> > conversation is not constructive.
>
> This feels like that moment in 8Mile, "pay attention, you're saying the
> same shit that he said." The personal insults and technical semantic
> arguments are testament to the fact that you're not willing or not able
> to argue the points. It's quite incredible that two people have replied
> to the same multiple-hundred word e-mail about a broad issue of trying
> to gatekeep discussion and both have focused on semantics ("it's not
> *all* day"). I will remember not to use hyperbole in future for fear of
> it being taken literally and used as an excuse to dodge the point.
Check the git logs, Google employees are minor contributors these
days. The GPLv3 scared Google away from GCC years ago.
I've unsubscribed from this list now, so please stop CCing me. I'm not
interested in continuing this.
[Bug libstdc++/95983] `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983 --- Comment #4 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Hi Patrick, thank you for that patch. I guess that it also fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96070. Will this patch be backported to gcc-10? Great work!
Re: On US corporate influence over Free Software and the GCC Steering Committee
> Here the relevant excerpt (but please go chech the quotation): > > "As an IBM employee, you are not allowed to use your gmail account to work > in any way on VNIC. You are not allowed to use your personal email account > as a "hobby". You are an IBM employee 100% of the time. > Please remove yourself completely from the maintainers file. I grant you a 1 > time exception on contributions to VNIC to make this change." > > > This is happened yesterday (literally). Troubling indeed, but this might just be an overzealous manager. IBM, like other corporations, has made significant technical contributions to GCC over the years, for example the scheduler and the vectorizer, and thus has assigned the copyright of these contributions to the FSF. -- Eric Botcazou
Re: [PATCH] testsuite: Fix up gcc.target/s390/zero-scratch-regs-1.c
On 4/20/21 9:17 AM, Stefan Schulze Frielinghaus wrote:
> Depending on whether GCC is configured using --with-mode=zarch or not,
> for the 31bit target instructions are generated either for ESA or
> z/Architecture. For the sake of simplicity and robustness test only for
> the latter by adding manually option -mzarch.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/zero-scratch-regs-1.c: Force test to run for
> z/Architecture only.>
> Ok for mainline?
Ok. Thanks!
Andreas
>
> ---
> .../gcc.target/s390/zero-scratch-regs-1.c | 95 ---
> 1 file changed, 40 insertions(+), 55 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/s390/zero-scratch-regs-1.c
> b/gcc/testsuite/gcc.target/s390/zero-scratch-regs-1.c
> index c394c4b69e7..1c02c0c4e51 100644
> --- a/gcc/testsuite/gcc.target/s390/zero-scratch-regs-1.c
> +++ b/gcc/testsuite/gcc.target/s390/zero-scratch-regs-1.c
> @@ -1,65 +1,50 @@
> /* { dg-do compile } */
> -/* { dg-options "-O2 -fzero-call-used-regs=all -march=z13" } */
> +/* { dg-options "-O2 -fzero-call-used-regs=all -march=z13 -mzarch" } */
>
> /* Ensure that all call clobbered GPRs, FPRs, and VRs are zeroed and all call
> saved registers are kept. */
>
> void foo (void) { }
>
> -/* { dg-final { scan-assembler-times "lhi\t" 6 { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lhi\t%r0,0" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lhi\t%r1,0" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lhi\t%r2,0" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lhi\t%r3,0" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lhi\t%r4,0" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lhi\t%r5,0" { target { ! lp64 } } } } */
> +/* { dg-final { scan-assembler-times "lghi\t" 6 } } */
> +/* { dg-final { scan-assembler "lghi\t%r0,0" } } */
> +/* { dg-final { scan-assembler "lghi\t%r1,0" } } */
> +/* { dg-final { scan-assembler "lghi\t%r2,0" } } */
> +/* { dg-final { scan-assembler "lghi\t%r3,0" } } */
> +/* { dg-final { scan-assembler "lghi\t%r4,0" } } */
> +/* { dg-final { scan-assembler "lghi\t%r5,0" } } */
>
> -/* { dg-final { scan-assembler-times "lzdr\t" 14 { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lzdr\t%f0" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lzdr\t%f1" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lzdr\t%f2" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lzdr\t%f3" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lzdr\t%f5" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lzdr\t%f7" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lzdr\t%f8" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lzdr\t%f9" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lzdr\t%f10" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lzdr\t%f11" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lzdr\t%f12" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lzdr\t%f13" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lzdr\t%f14" { target { ! lp64 } } } } */
> -/* { dg-final { scan-assembler "lzdr\t%f15" { target { ! lp64 } } } } */
> -
> -/* { dg-final { scan-assembler-times "lghi\t" 6 { target { lp64 } } } } */
> -/* { dg-final { scan-assembler "lghi\t%r0,0" { target { lp64 } } } } */
> -/* { dg-final { scan-assembler "lghi\t%r1,0" { target { lp64 } } } } */
> -/* { dg-final { scan-assembler "lghi\t%r2,0" { target { lp64 } } } } */
> -/* { dg-final { scan-assembler "lghi\t%r3,0" { target { lp64 } } } } */
> -/* { dg-final { scan-assembler "lghi\t%r4,0" { target { lp64 } } } } */
> -/* { dg-final { scan-assembler "lghi\t%r5,0" { target { lp64 } } } } */
> -
> -/* { dg-final { scan-assembler-times "vzero\t" 24 { target { lp64 } } } } */
> -/* { dg-final { scan-assembler "vzero\t%v0" { target { lp64 } } } } */
> -/* { dg-final { scan-assembler "vzero\t%v1" { target { lp64 } } } } */
> -/* { dg-final { scan-assembler "vzero\t%v2" { target { lp64 } } } } */
> -/* { dg-final { scan-assembler "vzero\t%v3" { target { lp64 } } } } */
> +/* { dg-final { scan-assembler-times "vzero\t" 30 { target { ! lp64 } } } }
> */
> +/* { dg-final { scan-assembler-times "vzero\t" 24 { target { lp64 } } } }
> */
> +/* { dg-final { scan-assembler "vzero\t%v0" } } */
> +/* { dg-final { scan-assembler "vzero\t%v1" } } */
> +/* { dg-final { scan-assembler "vzero\t%v2" } } */
> +/* { dg-final { scan-assembler "vzero\t%v3" } } */
> /* { dg-final { scan-assembler "vzero\t%v4" { target { lp64 } } } } */
> -/* { dg-final { scan-assembler "vzero\t%v5" { target { lp64 } } } } */
> +/* { dg-final { scan-assembler "vzero\t%v5" } } */
> /* { dg-final { scan-assembler "vzero\t%v6" { target { lp64 } } } } */
> -/* { dg-final { scan-assembler "vzero\t%v7" { target { lp64 } } } } */
> -/* { dg-final {
[PATCH] testsuite: Fix up gcc.target/s390/zero-scratch-regs-1.c
Depending on whether GCC is configured using --with-mode=zarch or not,
for the 31bit target instructions are generated either for ESA or
z/Architecture. For the sake of simplicity and robustness test only for
the latter by adding manually option -mzarch.
gcc/testsuite/ChangeLog:
* gcc.target/s390/zero-scratch-regs-1.c: Force test to run for
z/Architecture only.
Ok for mainline?
---
.../gcc.target/s390/zero-scratch-regs-1.c | 95 ---
1 file changed, 40 insertions(+), 55 deletions(-)
diff --git a/gcc/testsuite/gcc.target/s390/zero-scratch-regs-1.c
b/gcc/testsuite/gcc.target/s390/zero-scratch-regs-1.c
index c394c4b69e7..1c02c0c4e51 100644
--- a/gcc/testsuite/gcc.target/s390/zero-scratch-regs-1.c
+++ b/gcc/testsuite/gcc.target/s390/zero-scratch-regs-1.c
@@ -1,65 +1,50 @@
/* { dg-do compile } */
-/* { dg-options "-O2 -fzero-call-used-regs=all -march=z13" } */
+/* { dg-options "-O2 -fzero-call-used-regs=all -march=z13 -mzarch" } */
/* Ensure that all call clobbered GPRs, FPRs, and VRs are zeroed and all call
saved registers are kept. */
void foo (void) { }
-/* { dg-final { scan-assembler-times "lhi\t" 6 { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lhi\t%r0,0" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lhi\t%r1,0" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lhi\t%r2,0" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lhi\t%r3,0" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lhi\t%r4,0" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lhi\t%r5,0" { target { ! lp64 } } } } */
+/* { dg-final { scan-assembler-times "lghi\t" 6 } } */
+/* { dg-final { scan-assembler "lghi\t%r0,0" } } */
+/* { dg-final { scan-assembler "lghi\t%r1,0" } } */
+/* { dg-final { scan-assembler "lghi\t%r2,0" } } */
+/* { dg-final { scan-assembler "lghi\t%r3,0" } } */
+/* { dg-final { scan-assembler "lghi\t%r4,0" } } */
+/* { dg-final { scan-assembler "lghi\t%r5,0" } } */
-/* { dg-final { scan-assembler-times "lzdr\t" 14 { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lzdr\t%f0" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lzdr\t%f1" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lzdr\t%f2" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lzdr\t%f3" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lzdr\t%f5" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lzdr\t%f7" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lzdr\t%f8" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lzdr\t%f9" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lzdr\t%f10" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lzdr\t%f11" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lzdr\t%f12" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lzdr\t%f13" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lzdr\t%f14" { target { ! lp64 } } } } */
-/* { dg-final { scan-assembler "lzdr\t%f15" { target { ! lp64 } } } } */
-
-/* { dg-final { scan-assembler-times "lghi\t" 6 { target { lp64 } } } } */
-/* { dg-final { scan-assembler "lghi\t%r0,0" { target { lp64 } } } } */
-/* { dg-final { scan-assembler "lghi\t%r1,0" { target { lp64 } } } } */
-/* { dg-final { scan-assembler "lghi\t%r2,0" { target { lp64 } } } } */
-/* { dg-final { scan-assembler "lghi\t%r3,0" { target { lp64 } } } } */
-/* { dg-final { scan-assembler "lghi\t%r4,0" { target { lp64 } } } } */
-/* { dg-final { scan-assembler "lghi\t%r5,0" { target { lp64 } } } } */
-
-/* { dg-final { scan-assembler-times "vzero\t" 24 { target { lp64 } } } } */
-/* { dg-final { scan-assembler "vzero\t%v0" { target { lp64 } } } } */
-/* { dg-final { scan-assembler "vzero\t%v1" { target { lp64 } } } } */
-/* { dg-final { scan-assembler "vzero\t%v2" { target { lp64 } } } } */
-/* { dg-final { scan-assembler "vzero\t%v3" { target { lp64 } } } } */
+/* { dg-final { scan-assembler-times "vzero\t" 30 { target { ! lp64 } } } } */
+/* { dg-final { scan-assembler-times "vzero\t" 24 { target { lp64 } } } } */
+/* { dg-final { scan-assembler "vzero\t%v0" } } */
+/* { dg-final { scan-assembler "vzero\t%v1" } } */
+/* { dg-final { scan-assembler "vzero\t%v2" } } */
+/* { dg-final { scan-assembler "vzero\t%v3" } } */
/* { dg-final { scan-assembler "vzero\t%v4" { target { lp64 } } } } */
-/* { dg-final { scan-assembler "vzero\t%v5" { target { lp64 } } } } */
+/* { dg-final { scan-assembler "vzero\t%v5" } } */
/* { dg-final { scan-assembler "vzero\t%v6" { target { lp64 } } } } */
-/* { dg-final { scan-assembler "vzero\t%v7" { target { lp64 } } } } */
-/* { dg-final { scan-assembler "vzero\t%v16" { target { lp64 } } } } */
-/* { dg-final { scan-assembler "vzero\t%v17" { target { lp64 } } } } */
-/* { dg-final { scan-assembler "vzero\t%v18" { target { lp64 } } } } */
-/* { dg-final { scan-assembler "vzero\t%v19" { target {
Re: [PATCH] s390/testsuite: Fix oscbreak-1.c.
On 4/16/21 3:59 PM, Robin Dapp wrote: > Hi, > > checking for an osc break is somewhat brittle especially with many > passes potentially introducing new insns and moving them around. > Therefore, only run the test with -O1 -fschedule-insns in order to limit > the influence of other passes. Yeah, that's because of the very limited analysis we do in the backend to detect such cases. In fact we probably would want to have an OSC break in many of them as well. For me the testcase appears to work with -O2 on all the -march levels. I think -O2 would be preferred because that's what is most frequently used. > > Is it OK? Yes, either with -O2 or the options you have proposed if -O2 doesn't work out for you. Thanks! Andreas > > Regards > Robin > > -- > > gcc/testsuite/ChangeLog: > > * gcc.target/s390/oscbreak-1.c: Compile with -O1 > -fschedule-insns. >
Re: Fix Fortran rounding issues, PR fortran/96983.
On Mon, Apr 19, 2021 at 9:40 PM Michael Meissner via Fortran wrote: > > Fix Fortran rounding issues, PR fortran/96983. > > I was looking at Fortran PR 96983, which fails on the PowerPC when trying to > run the test PR96711.F90. The compiler ICEs because the PowerPC does not have > a floating point type with a type precision of 128. The reason is that the > PowerPC has 3 different 128 bit floating point types (__float128/_Float128, > __ibm128, and long double). Currently long double uses the IBM extended > double > type, but we would like to switch to using IEEE 128-bit long doubles in the > future. > > In order to prevent the compiler from converting explicit __ibm128 types to > long double when long double uses the IEEE 128-bit representation, we have set > up the precision for __ibm128 to be 128, long double to be 127, and > __float128/_Float128 to be 126. > > Originally, I was trying to see if for Fortran, I could change the precision > of > long double to be 128 (Fortran doesn't access __ibm128), but it quickly became > hard to get the changes to work. > > I looked at the Fortran code in build_round_expr, and I came to the conclusion > that there is no reason to promote the floating point type. If you just do a > normal round of the value using the current floating point format and then > convert it to the integer type. We don't have an appropriate built-in > function > that provides the equivalent of llround for 128-bit integer types. > > This patch fixes the compiler crash. > > However, while with this patch, the PowerPC compiler will not crash when > building the test case, it will not run on the current default installation. > The failure is because the test is explicitly expecting 128-bit floating point > to handle 10384593717069655257060992658440192_16 (i.e. 2**113). > > By default, the PowerPC uses IBM extended double used for 128-bit floating > point. The IBM extended double format is a pair of doubles that provides more > mantissa bits but does not grow the expoenent range. The value in the test is > fine for IEEE 128-bit floating point, but it is too large for the PowerPC > extended double setup. > > I have built the following tests with this patch: > >* I have built a bootstrap compiler on a little endian power9 Linux system > with the default long double format (IBM extended double). The > pr96711.f90 test builds, but it does not run due to the range of the > real*16 exponent. There were no other regressions in the C/C++/Fortran > tests. > >* I have built a bootstrap compiler on a little endian power9 Linux system > with the default long double format set to IEEE 128-bit. I used the > Advance Toolchain 14.0-2 to provide the IEEE 128-bits. The compiler was > configured to build power9 code by default, so the test generated native > power9 IEEE 128-bit instructions. The pr96711.f90 test builds and runs > correctly in this setup. > >* I have built a bootstrap compiler on a big endian power8 Linux system > with > the default long double format (IBM extended double). Like the first > case, the pr96711.f90 test does not crash the compiler, but the test > fails > due to the range of the real*16 exponent.There were no other > regressions in the C/C++/Fortran tests. > >* I built a bootstrap compiler on my x86_64 laptop. There were no > regressions in the tests. > > > Can I check this change into the GCC trunk? The patch looks fine technically and is definitely an improvement since the intermediate conversion looks odd. But it might be that the standard requires such dance though the preceeding cases handled don't seem to care. I'm thinking of a FP format where round(1.6) == 3 because of lack of precision but using an intermediate FP format with higher precision would "correctly" compute 2. Of course the current code doesn't handle this correctly for the case if llroundf either. Richard. > I've not contributed to the Fortran front end before. If the maintainers like > the patch, can somebody point out if I need to do additional things to commit > the patch? > > gcc/fortran/ > 2021-04-19 Michael Meissner > > PR gfortran/96983 > * trans-intrinsic.c (build_round_expr): If int type is larger than > long long, do the round and convert to the integer type. Do not > try to find a floating point type the exact size of the integer > type. > --- > gcc/fortran/trans-intrinsic.c | 26 -- > 1 file changed, 8 insertions(+), 18 deletions(-) > > diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c > index 5e53d1162fa..cceef8f34ac 100644 > --- a/gcc/fortran/trans-intrinsic.c > +++ b/gcc/fortran/trans-intrinsic.c > @@ -386,30 +386,20 @@ build_round_expr (tree arg, tree restype) >argprec = TYPE_PRECISION (argtype); >resprec = TYPE_PRECISION (restype); > > - /* Depending on the type of the result, choose
On US corporate influence over Free Software and the GCC Steering Committee
Hi GCC developers, just to further clarify why I think the current Steering Committee is highly problematic, I'd like you to give a look at this commit message over Linux MAINTAINERS https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=4acd47644ef1e1c8f8f5bc40b7cf1c5b9bcbbc4e Here the relevant excerpt (but please go chech the quotation): "As an IBM employee, you are not allowed to use your gmail account to work in any way on VNIC. You are not allowed to use your personal email account as a "hobby". You are an IBM employee 100% of the time. Please remove yourself completely from the maintainers file. I grant you a 1 time exception on contributions to VNIC to make this change." This is happened yesterday (literally). And while this is IBM, the other US corporations with affiliations in the Steering Committee are no better: https://gcc.gnu.org/pipermail/gcc/2021-April/235777.html I can understand that some of you consider working for such corporations "a joy". But for the rest of us, and to most people outside the US, their influence over the leadership of GCC is a threat. Please, do not create a hostile environment for indipendent contributors. Please... please... Fix the GCC Steering Committee. Giacomo
[Bug fortran/100110] Parameterized Derived Types, problems with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100110 --- Comment #3 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:67378cd63d62bf0c69e966d1d202a1e586550a68 commit r11-8255-g67378cd63d62bf0c69e966d1d202a1e586550a68 Author: Paul Thomas Date: Tue Apr 20 07:30:07 2021 +0100 Fortran: Fix host associated PDT entity initialization [PR99307]. 2021-04-20 Paul Thomas gcc/fortran PR fortran/100110 * trans-decl.c (gfc_get_symbol_decl): Replace test for host association with a check that the current and symbol namespaces are the same. gcc/testsuite/ PR fortran/100110 * gfortran.dg/pdt_31.f03: New test. * gfortran.dg/pdt_26.f03: Reduce 'builtin_malloc' count from 9 to 8.
[Bug target/100106] [10/11 Regression] ICE in gen_movdi, at config/arm/arm.md:6187 since r10-2840-g70cdb21e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100106 --- Comment #3 from Bernd Edlinger --- Yes, indeed something like the following seems to fix the issue: diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c index d13c390..56271e9 100644 --- a/gcc/simplify-rtx.c +++ b/gcc/simplify-rtx.c @@ -7217,6 +7217,7 @@ simplify_context::simplify_subreg (machine_mode outermode have instruction to move the whole thing. */ && (! MEM_VOLATILE_P (op) || ! have_insn_for (SET, innermode)) + && (STRICT_ALIGNMENT && GET_MODE_ALIGNMENT (outermode) < MEM_ALIGN (op)) && known_le (outersize, innersize)) return adjust_address_nv (op, outermode, byte);
