[Bug tree-optimization/113126] New: [14 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:325 at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113126 Bug ID: 113126 Summary: [14 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:325 at -O1 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 56929 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56929&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O1 testcase.c during GIMPLE pass: isel testcase.c: In function 'foo': testcase.c:8:1: internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:325 8 | foo (void) | ^~~ 0x885994 gimple_expand_vec_cond_expr /repo/gcc-trunk/gcc/gimple-isel.cc:325 0x885994 execute /repo/gcc-trunk/gcc/gimple-isel.cc:389 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-6818-20231224094952-gbd901d76734-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-6818-20231224094952-gbd901d76734-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231224 (experimental) (GCC)
[Bug tree-optimization/113126] [14 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:325 at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113126 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 CC||pinskia at gcc dot gnu.org
[Bug tree-optimization/113126] [14 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:325 at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113126
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-12-24
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
13:
h_6 = (G) f.0_1;
_2 = h_6 <= h_6;
_3 = VEC_COND_EXPR <_2, { -1, -1 }, { 0, 0 }>;
_4 = VIEW_CONVERT_EXPR(_3);
14:
_2 = f.0_1 <= f.0_1;
_3 = VEC_COND_EXPR <_2, { -1, -1 }, { 0, 0 }>;
_4 = VIEW_CONVERT_EXPR(_3);
Funny it was introduced accident by r14-2040-g6b32400e19a702 which is there to
fix a TYPE_PRECISION issue.
The result of `vector(2) float` is `vector(2) ` but match
messes up here ...
Which means the patterns here are only valid for scalar conversions and not
vector based conversions or they need to add an conversion between the
resulting `vector boolean` types ...
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 --- Comment #14 from Hans-Peter Nilsson --- (In reply to GCC Commits from comment #9) > The master branch has been updated by Hans-Peter Nilsson : > > https://gcc.gnu.org/g:3d03630b123411340e52d05124cb0cacfa1fc8b0 > > commit r14-6817-g3d03630b123411340e52d05124cb0cacfa1fc8b0 > Author: Hans-Peter Nilsson > Date: Sun Dec 24 00:10:32 2023 +0100 > > I haven't looked into why this problem, that appeared for the PA > already in 2007, was seen for CRIS only recently (with > r14-6674-g4759383245ac97). I should've removed that paragraph before committing. It's obvious from looking at r14-6674-g4759383245ac97 and the history of the expression in that context, and knowing that pa uses hard_frame_pointer_rtx... Still, why not all those other targets? (In reply to Jiu Fu Guo from comment #13) > (In reply to GCC Commits from comment #9) > > Conceptually, it's logical that stores to incoming args are > > optimized out on the return path or if no loads are seen - > > at least before epilogue expansion, when the subsequent load > > isn't seen in the RTL, as is the case for the "dse1" pass. > > The stores to the argp/frame can be eliminated only if they are not used. > While for this case, the store may be used by EH handler, it should not be > optimized out. That use is not seen before the pro/epilogue expansion pass. Maybe the pass should be restricted in what it does prior to that (not do in dse1, do in dse2). > Thanks for catching and handling this quickly. > > Happy holidays. No worries, same to you!
[Bug c++/113127] New: Unexpected error: '' was not declared 'constexpr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113127
Bug ID: 113127
Summary: Unexpected error: '' was not declared
'constexpr'
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This constexpr variable definition
constexpr bool b = ( delete [][]{ return new int[2]; }(), true );
is accepted in Clang and MSVC. But GCC complains:
:1:64: error: the value of '' is not usable in a
constant
:1:56: note: '' was not declared 'constexpr'
Online demo: https://godbolt.org/z/ovso3neEr
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #17 from Roger Sayle ---
I think this patch might resolve the problem (or move it somewhere else):
diff --git a/gcc/expr.cc b/gcc/expr.cc
index 9fef2bf6585..218bca905f5 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -6274,10 +6274,7 @@ expand_assignment (tree to, tree from, bool nontemporal)
result = store_expr (from, to_rtx, 0, nontemporal, false);
else
{
- rtx to_rtx1
- = lowpart_subreg (subreg_unpromoted_mode (to_rtx),
- SUBREG_REG (to_rtx),
- subreg_promoted_mode (to_rtx));
+ rtx to_rtx1 = gen_reg_rtx (subreg_unpromoted_mode (to_rtx));
result = store_field (to_rtx1, bitsize, bitpos,
bitregion_start, bitregion_end,
mode1, from, get_alias_set (to),
The motivation/solution comes from a comment in expmed.cc:
/* If the destination is a paradoxical subreg such that we need a
truncate to the inner mode, perform the insertion on a temporary and
truncate the result to the original destination. Note that we can't
just truncate the paradoxical subreg as (truncate:N (subreg:W (reg:N
X) 0)) is (reg:N X). */
The same caveat applies to extensions on MIPS, so we should use a new
pseudo temporary register rather than update the SUBREG in place.
If someone could confirm this fixes the issue on MIPS, I'll try to come up
with a milder form of this fix that checks TARGET_MODE_REP_EXTENDED that'll
limit the churn/impact on other targets.
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914 --- Comment #18 from Roger Sayle --- Please ignore comment #17, the above patch is completely bogus/broken.
[Bug libstdc++/107761] Implement C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761 --- Comment #6 from Jonathan Wakely --- OK that's great, thanks for clarifying. (I haven't looked at the impl on godbolt yet, sorry)
Re: ’ ] ' is displayed.
This mailing list is for automated emails from our bug database, not for reporting bugs directly. See https://gcc.gnu.org/bugs/ for how to report bugs, thanks.
[Bug libstdc++/113099] locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099 --- Comment #5 from Jonathan Wakely --- I'm not sure what you mean by "the compiler is free to generate code that takes it into account." Takes what into account? What problem does that freedom cause? The locale facet instantiations are compiled as C++11 (but other parts of the library are compiled as C++17 or newer). We should do this so it uses if-constexpr for everything except C++98: --- a/libstdc++-v3/include/bits/locale_classes.tcc +++ b/libstdc++-v3/include/bits/locale_classes.tcc @@ -87,6 +87,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION __s2.data(), __s2.data() + __s2.length()) < 0); } +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wc++17-extensions" template inline const _Facet* __try_use_facet(const locale& __loc) _GLIBCXX_NOTHROW @@ -97,7 +99,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION // We know these standard facets are always installed in every locale // so dynamic_cast always succeeds, just use static_cast instead. #define _GLIBCXX_STD_FACET(...) \ - if _GLIBCXX17_CONSTEXPR (__is_same(_Facet, __VA_ARGS__)) \ + if _GLIBCXX_CONSTEXPR (__is_same(_Facet, __VA_ARGS__)) \ return static_cast(__facets[__i]) _GLIBCXX_STD_FACET(ctype); @@ -145,6 +147,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION return static_cast(__facets[__i]); #endif } +#pragma GCC diagnostic pop /** * @brief Test for the presence of a facet.
[Bug libstdc++/113099] locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099 --- Comment #6 from Jonathan Wakely --- (In reply to andysem from comment #3) > I think, a failing dynamic_cast would not be useful as this would make > std::use_facet unusable with -fno-rtti. I don't see a problem with that. If you want to use a polymorphic container of facets, you need RTTI. The standard facets will work, but it doesn't seem reasonable to expect it to work for program-defined facets. And a std::use_facet that fails seems better than one that segfaults, doesn't it?
[Bug libstdc++/113099] locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099 --- Comment #7 from Peter Dimov --- You don't necessarily need dynamic_cast because facets are always installed and obtained by their exact type, not via a reference to base. You can store the Facet* as given (like shared_ptr does), and return it. The only reason dynamic_cast is needed here is because you can't static_cast from facet* to Facet* when virtual inheritance. But you are not required to store facet* in the actual container; you can store the original Facet* as void*.
[Bug c++/111485] [11/12 Regression] Constraint mismatch on template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111485 --- Comment #4 from GCC Commits --- The releases/gcc-12 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:f24d6f0031fd515e6497c8c96446afd02aa4dbaa commit r12-10068-gf24d6f0031fd515e6497c8c96446afd02aa4dbaa Author: Patrick Palka Date: Fri Sep 22 06:25:49 2023 -0400 c++: constraint rewriting during ttp coercion [PR111485] In order to compare the constraints of a ttp with that of its argument, we rewrite the ttp's constraints in terms of the argument template's template parameters. The substitution to achieve this currently uses a single level of template arguments, but that never does the right thing because a ttp's template parameters always have level >= 2. This patch fixes this by including the outer template arguments in the substitution, which ought to match the depth of the ttp. The second testcase demonstrates it's better to substitute the concrete outer template arguments instead of generic ones since a ttp's constraints could depend on outer parameters. PR c++/111485 gcc/cp/ChangeLog: * pt.cc (is_compatible_template_arg): New parameter 'args'. Add the outer template arguments 'args' to 'new_args'. (convert_template_argument): Pass 'args' to is_compatible_template_arg. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-ttp5.C: New test. * g++.dg/cpp2a/concepts-ttp6.C: New test. (cherry picked from commit 6f902a42b0afe3f3145bcb864695fc290b5acc3e)
[Bug c++/111485] [11/12 Regression] Constraint mismatch on template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111485 --- Comment #5 from GCC Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:84cab505d69038647d98f9340559fc941446e479 commit r11-11168-g84cab505d69038647d98f9340559fc941446e479 Author: Patrick Palka Date: Fri Sep 22 06:25:49 2023 -0400 c++: constraint rewriting during ttp coercion [PR111485] In order to compare the constraints of a ttp with that of its argument, we rewrite the ttp's constraints in terms of the argument template's template parameters. The substitution to achieve this currently uses a single level of template arguments, but that never does the right thing because a ttp's template parameters always have level >= 2. This patch fixes this by including the outer template arguments in the substitution, which ought to match the depth of the ttp. The second testcase demonstrates it's better to substitute the concrete outer template arguments instead of generic ones since a ttp's constraints could depend on outer parameters. PR c++/111485 gcc/cp/ChangeLog: * pt.c (is_compatible_template_arg): New parameter 'args'. Add the outer template arguments 'args' to 'new_args'. (convert_template_argument): Pass 'args' to is_compatible_template_arg. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-ttp5.C: New test. * g++.dg/cpp2a/concepts-ttp6.C: New test. (cherry picked from commit 6f902a42b0afe3f3145bcb864695fc290b5acc3e)
[Bug libstdc++/113099] locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099 --- Comment #8 from Jonathan Wakely --- (In reply to Peter Dimov from comment #7) > You don't necessarily need dynamic_cast because facets are always installed > and obtained by their exact type, not via a reference to base. Is that true? std::use_facet will return a reference to a facet with X::id but it could actually be something derived from X. e.g. a user can install their own facet derived from std::ctype, which overrides some members. Code that does std::use_facet>(loc) will get the user's facet, but via reference to base. > You can store > the Facet* as given (like shared_ptr does), and return it. > > The only reason dynamic_cast is needed here is because you can't static_cast > from facet* to Facet* when virtual inheritance. But you are not required to > store facet* in the actual container; you can store the original Facet* as > void*. An implementation could do that, but I don't think libstdc++ can do it now without an ABI change.
[Bug libstdc++/113099] locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099 --- Comment #9 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #8) > (In reply to Peter Dimov from comment #7) > > You don't necessarily need dynamic_cast because facets are always installed > > and obtained by their exact type, not via a reference to base. > > Is that true? std::use_facet will return a reference to a facet with > X::id but it could actually be something derived from X. e.g. a user can > install their own facet derived from std::ctype, which overrides some > members. Code that does std::use_facet>(loc) will get the > user's facet, but via reference to base. And I guess if the user's derived facet uses virtual inheritance from std::locale::facet, then this could break with the static_cast*> in libstdc++ today. Hmm.
[Bug libstdc++/113099] locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099 --- Comment #10 from Peter Dimov --- Maybe the right thing to do is to use dynamic_cast only for virtual inheritance (either have a trait or check whether static_cast isn't a valid expression), otherwise static_cast, in both cases (standard and user-defined Facet.)
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914 --- Comment #19 from Roger Sayle --- Created attachment 56930 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56930&action=edit proposed patch And now for a patch that does (or should) work. This even contains an optimization, we middle-end knows we don't need to sign or zero extend if a insv doesn't modify the sign-bit. Testing on MIPS would be much appreciated. TIA.
[Bug c++/113127] Unexpected error: '' was not declared 'constexpr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113127
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Keywords||rejects-valid
Last reconfirmed||2023-12-24
--- Comment #1 from Andrew Pinski ---
Confirmed,
Just to show it is unrelated to lambdas I defined it as a constexpr function:
constexpr auto g() {return new int[2];}
constexpr bool b1 = ( delete []g(), true );
[Bug libstdc++/113099] locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #11 from andysem at mail dot ru ---
> I'm not sure what you mean by "the compiler is free to generate code that
> takes it into account." Takes what into account? What problem does that
> freedom cause?
I mean the compiler could move (some part of) dynamic_cast to precede the check
for the standard facet. I.e. of something like this:
template< typename _Facet >
const _Facet* __try_use_facet(locale const& loc)
{
const size_t __i = _Facet::id._M_id();
const locale::facet** __facets = __loc._M_impl->_M_facets;
const _Facet* __dyn_facet = __dynamic_cast< const _Facet* >(__facets[__i]);
// checks for every standard facet type
if (__is_same(_Facet, ...))
return static_cast(__facets[__i]);
return __dyn_facet;
}
>> I think, a failing dynamic_cast would not be useful as this would make
>> std::use_facet unusable with -fno-rtti.
>
> I don't see a problem with that. If you want to use a polymorphic container
> of facets, you need RTTI. The standard facets will work, but it doesn't seem
> reasonable to expect it to work for program-defined facets.
AFAIK, the standard or libstdc++ docs do not require RTTI for std::locale to
function. In fact, the facet::id stuff seems to exist precisely to make RTTI
optional in the implementations. Besides, the code, as it was written, seems to
intend to work without RTTI by switching to static_cast instead of
dynamic_cast. So making std::use_facet always fail would go against that
intention.
> And a std::use_facet that fails seems better than one that segfaults, doesn't
> it?
No, not really. It still means users cannot use locale without RTTI, just for a
different reason.
> And I guess if the user's derived facet uses virtual inheritance from
> std::locale::facet, then this could break with the
> static_cast*> in libstdc++ today. Hmm.
std::ctype non-virtually derives from std::locale::facet, so no, that would not
break. What wouldn't work is this:
class my_facet : virtual public std::ctype< char > {};
my_facet const& fac = std::use_facet< my_facet >(loc);
But this would fail in compile time with no RTTI, which *is* better than a
segfault or an exception in runtime.
[Bug fortran/113128] New: Wrong implied-do with optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113128 Bug ID: 113128 Summary: Wrong implied-do with optimizations Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gigor-ads at yandex dot ru Target Milestone: --- Hello! With the following small example (called test.f90): program main implicit none integer, parameter :: nal = 5, nbe = 4 real(8) :: v(nal,nal,nbe,nbe) integer :: i,j,k,l open(16,file='ijklab',form='unformatted') write(16) v(i,k,j,l),i=1,merge(k,nal,l==j)),j=1,l),k=1,nal),l=1,nbe) close(16) end program main With different level of optimizations, one can get file 'ijklab' with different sizes. With -O0: gfortran -O0 test.f90 -o test.O0 && ./test.O0 && ls -la -rw-rw-r-- 1 user group 1688 Dec 24 18:02 ijklab With -O1: gfortran -O1 test.f90 -o test.O1 && ./test.O1 && ls -la -rw-rw-r-- 1 user group 2008 Dec 24 18:04 ijklab Tested version: $ gfortran --version GNU Fortran (GCC) 12.2.0 20220819 (HPE) Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 1688 bytes is a correct answer.
[Bug c++/113129] New: "using declaration" not detected as "exported" in exported namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129
Bug ID: 113129
Summary: "using declaration" not detected as "exported" in
exported namespace
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at hexadigm dot com
Target Milestone: ---
Hi there,
See https://godbolt.org/z/MdToP8nP8 for a demo (self-explanatory and very
short). GCC version fails in top window (see error there), while Clang succeeds
in bottom window (also succeeds in MSVC - haven't test any others).
Issue is that the "using" declaration seen in "Consts.cppm" compiles
successfully but the variable being declared ("Test_v") isn't being exported
even though its "Const" namespace is exported. "Test_v" is therefore
inaccessible to any client that imports the "Consts" module (resulting in the
GCC compiler error seen in the top window).
I don't see any obvious reason why it shouldn't compile however unless it's a
GCC bug (but like so many I'm new to modules and this particular construct is a
fuzzy area - maybe Clang and MSVC got it wrong but read on).
Please note that this technique is very useful since it allows existing C++
headers to be easily used in C++ modules without any changes to the headers
themselves (so correcting it would be highly desirable to many). Users
therefore have the choice to either #include the existing header ("Consts.h" in
this example) or import the module instead ("Consts" in this example). The
module just defers to the header itself by applying "using" declarations as
seen in this example (to export whatever it needs from the header, in this case
"Test_v").
[Bug c++/113129] "using declaration" not detected as "exported" in exported namespace (C++ modules)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-12-24 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- Please attach the testcase rather than just linking to godbolt . godbolt has an save feature IIRC. Also it would be best if not using cmake nor ninja either. Plain make or shell commands on how to invoke gcc are best the best options so it is easier to debug. See https://gcc.gnu.org/bugs/ also.
[Bug c++/113129] "using declaration" not detected as "exported" in exported namespace (C++ modules)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129 --- Comment #2 from Larry Smith --- @Andrew Thanks for the feedback. I don't work in Unix-like environments though normally (including Linux) so CMake, make, and shell commands are something I rarely work with (I specialize on Microsoft platforms). TBH I don't have the time to look into it and the equivalent Microsoft code wouldn't be appreciated for GCC I assume (only working with GCC now as the author of https://github.com/HexadigmSystems/FunctionTraits which is platform neutral so it targets GCC among others). The issue is very simple though and the test code very short. The Compiler Explorer link should suffice IMHO unless someone more experienced than myself on GCC wants to attach those few files in the format you've requested (whatever is most appropriate in this forum). Thanks
[Bug fortran/113128] Wrong implied-do with optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113128 kargl at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-12-24 Known to fail||12.2.0 Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||14.0 Ever confirmed|0 |1 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Works with top-of-tree.
[Bug fortran/113128] Wrong implied-do with optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113128 Igor S Gerasimov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Igor S Gerasimov --- Oh! Thank you! I found commit: https://github.com/gcc-mirror/gcc/commit/5ac63ec5da2e93226457bea4dbb3a4f78d5d82c2 Very close to my own patch :D
[Bug fortran/111837] [11/12/13/14 Regression] Out of bounds access with optimization inside io-implied-do-control
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111837 Andrew Pinski changed: What|Removed |Added CC||gigor-ads at yandex dot ru --- Comment #9 from Andrew Pinski --- *** Bug 113128 has been marked as a duplicate of this bug. ***
[Bug fortran/113128] Wrong implied-do with optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113128 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 111837 ***
[Bug middle-end/113130] New: `abs(a) == b` could be expanded as `(a == b || a == -b)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113130
Bug ID: 113130
Summary: `abs(a) == b` could be expanded as `(a == b || a ==
-b)`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int f(int a, int c)
{
// c = 1;
int b = a > 0 ? a : -a;
return b == c;
}
int f1(int a, int c)
{
// c = 1;
return a == -c || a == c;
}
```
These 2 functions should produce the same assembly code.
This is especially true for when c is a 1 or 2.
Note for gimple, it might make sense to `ABS_EXPR == c` as the conconal
form as it is only 2 gimple statements rather than 3.
Note `<`, `>`, `>=`, `<=`, and `!=` should be handled too.
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914 --- Comment #20 from YunQiang Su --- This patch has 2 problems: 1. We may need some more steps to add gcc_assert (outprec < inprec) Now, I met some ICE with it. 2. It doesn't solve the this problem: In combine.cc, jump_insn eats truncate and sign_extend. In fact that is the real problem: How to tell combine.cc: don't eat it; this truncate/sign_extend is really needed by us.
[Bug middle-end/99930] Failure to optimize floating point -abs(x) in nontrivial code at -O2/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99930 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|middle-end --- Comment #11 from Andrew Pinski --- This is worse in GCC 13 because ` _5 = .COPYSIGN (_4, -1.0e+0);` is not expanded as `_4 | 0x800` ...
Re: ’ ] ' is displayed.
Thanks for the tip! 2023年12月24日(日) 23:35 Jonathan Wakely : > This mailing list is for automated emails from our bug database, not > for reporting bugs directly. > > See https://gcc.gnu.org/bugs/ for how to report bugs, thanks. > > >
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914 --- Comment #21 from YunQiang Su --- Sorry, Roger. Your patch is correct. I misunderstood it.
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914 --- Comment #22 from YunQiang Su --- Any way, we should split the assert to another patch. I will try to find all the wrongly used TRULY_NOOP_TRUNCATION_MODES_P.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #26 from JuzheZhong --- CC Li Pan who may also reproduce the bugs for me. Plz give us more details how to reproduce the bugs since we don't see any bugs when build and run SPEC.
[Bug testsuite/113005] 'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' execution test timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005 --- Comment #11 from Lipeng Zhu --- (In reply to Jakub Jelinek from comment #10) >For what I can reproduce on my box (rwlock_1.exe built in the >x86_64-pc-linux-gnu/libgomp/testsuite subdirectory using the -O0 >compilation line from libgomp*/*.sep: >$ OMP_NUM_THREADS=4096 LD_LIBRARY_PATH=../.libs/ time ./rwlock_1.exe > > Error termination. Backtrace: > At line 17 of file > /home/jakub/src/gcc/libgomp/testsuite/libgomp.fortran/rwlock_1.f90 (unit = > 1180) > Fortran runtime error: Cannot open file '***_tst.dat': Too many open files > > > With OMP_NUM_THREADS=512 it works. I can reproduce the "Too many open files" error on my local. The error is caused by the limited open files setting. $ ulimit -n In existing rwlock test case, it will maintain a fd for each thread, with OMP_NUM_THREADS growing, it reached the system limitation. >Anyway: should these test cases be limiting themselves to some lower > 'OMP_NUM_THREADS', for example via 'num_threads' clauses? This proposal could avoid this kind of issue.
[Bug tree-optimization/19832] don't remove an if when we know the value is the same as with the if (subtraction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19832 --- Comment #14 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:59ecd5ff096f800de17b804f1482055f2d84d629 commit r14-6827-g59ecd5ff096f800de17b804f1482055f2d84d629 Author: Andrew Pinski Date: Sun Dec 24 15:51:35 2023 -0800 match: Improve `(a != b) ? (a + b) : (2 * a)` pattern [PR19832] In the testcase provided, we would match f_plus but not g_plus due to a missing `:c` on the plus operator. This fixes the oversight there. Note this was noted in https://github.com/llvm/llvm-project/issues/76318 . Committed as obvious after bootstrap/test on x86_64-linux-gnu. PR tree-optimization/19832 gcc/ChangeLog: * match.pd (`(a != b) ? (a + b) : (2 * a)`): Add `:c` on the plus operator. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/phi-opt-same-2.c: New test. Signed-off-by: Andrew Pinski
[Bug testsuite/113005] 'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' execution test timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005 --- Comment #12 from Lipeng Zhu --- (In reply to Lipeng Zhu from comment #9) > Since I still can't reproduce the failure on my side :(, just curious, will > the new added 'rwlock' test cases failed on mutex lock? OK, I rerun these rwlock* test cases on mutex lock, it reported the similar error: $ export OMP_NUM_THREADS=1024 && time ./rwlock_1.exe At line 28 of file /home/lipzhu/codes/gcc/libgomp/testsuite/libgomp.fortran/rwlock_1.f90 (unit = 1017, file = '***_tst.dat') Fortran runtime error: End of file STOP 2 At line 17 of file /home/lipzhu/codes/gcc/libgomp/testsuite/libgomp.fortran/rwlock_1.f90 (unit = 587) Internal Error: Unit number changed Error termination. Backtrace: At line 17 of file /home/lipzhu/codes/gcc/libgomp/testsuite/libgomp.fortran/rwlock_1.f90 (unit = 732) Internal Error: Unit number changed Error termination. Backtrace: At line 17 of file /home/lipzhu/codes/gcc/libgomp/testsuite/libgomp.fortran/rwlock_1.f90 (unit = 963) At line 17 of file /home/lipzhu/codes/gcc/libgomp/testsuite/libgomp.fortran/rwlock_1.f90 (unit = 980) Internal Error: Unit number changed Internal Error: Unit number changed Error termination. Backtrace: Error termination. Backtrace: At line 17 of file /home/lipzhu/codes/gcc/libgomp/testsuite/libgomp.fortran/rwlock_1.f90 (unit = 421) Internal Error: Unit number changed Error termination. Backtrace: #0 0x7ff587881223 in already_open #0 0x7ff587881223 in already_open #0 0x7ff587881223 in already_open at ../../../libgfortran/io/open.c:742 at ../../../libgfortran/io/open.c:742 at ../../../libgfortran/io/open.c:742 #1 0x400def in ??? #1 0x400def in ??? #1 0x400def in ??? #0 0x7ff587881223 in already_open at ../../../libgfortran/io/open.c:742 #1 0x400def in ??? #0 0x7ff587881223 in already_open at ../../../libgfortran/io/open.c:742 #1 0x400def in ??? #2 0x7ff586e21d2d in gomp_thread_start at ../../../libgomp/team.c:129 #3 0x7ff5866081c9 in ??? #2 0x7ff586e21d2d in gomp_thread_start at ../../../libgomp/team.c:129 #3 0x7ff5866081c9 in ??? #4 0x7ff586239e72 in ??? #4 0x7ff586239e72 in ??? #5 0x in ??? #5 0x in ??? #2 0x7ff586e21d2d in gomp_thread_start at ../../../libgomp/team.c:129 #3 0x7ff5866081c9 in ??? #4 0x7ff586239e72 in ??? #2 0x7ff586e21d2d in gomp_thread_start #5 0x in ??? at ../../../libgomp/team.c:129 #3 0x7ff5866081c9 in ??? #4 0x7ff586239e72 in ??? #5 0x in ??? #2 0x7ff586e21d2d in gomp_thread_start at ../../../libgomp/team.c:129 #3 0x7ff5866081c9 in ??? #4 0x7ff586239e72 in ??? #5 0x in ???
[Bug tree-optimization/113131] New: `((A&B)^C)|B` should be simplified to `C | B`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113131
Bug ID: 113131
Summary: `((A&B)^C)|B` should be simplified to `C | B`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Testcase:
```
int f(int A, int B, int C)
{
return ((A&B)^C)|B; // C|B
}
```
This should be simplified down to `C | B` removing the reference to `A` even.
[Bug tree-optimization/113131] `((A&B)^C)|B` should be simplified to `C | B`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113131 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-12-25 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- .
[Bug testsuite/113005] 'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' execution test timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005 --- Comment #13 from Lipeng Zhu --- OK, I think I find the root cause of this error, when thread number greater than 1000, the file_name = 1000_tst.dat, character(11) will overflow. This will generate the same file_name like ***_tst.dat. diff --git a/libgomp/testsuite/libgomp.fortran/rwlock_1.f90 b/libgomp/testsuite/libgomp.fortran/rwlock_1.f90 index f90ecbeb00f..1c271ae031d 100644 --- a/libgomp/testsuite/libgomp.fortran/rwlock_1.f90 +++ b/libgomp/testsuite/libgomp.fortran/rwlock_1.f90 @@ -7,13 +7,12 @@ program main use omp_lib implicit none integer:: unit_number, v1, v2, i - character(11) :: file_name + character(16) :: file_name character(3) :: async = "no" !$omp parallel private (unit_number, v1, v2, file_name, async, i) do i = 0, 100 unit_number = 10 + omp_get_thread_num () - write (file_name, "(I3, A)") unit_number, "_tst.dat" - file_name = adjustl(file_name) + write (file_name, "(I5.5, A)") unit_number, "_tst.dat" open (unit_number, file=file_name, asynchronous="yes") ! call inquire with file parameter to test find_file in unix.c inquire (file=file_name, asynchronous=async)
