[Bug sanitizer/100665] New: [hwsanitizer] nested funtion pointer is tagged but never checked.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100665
Bug ID: 100665
Summary: [hwsanitizer] nested funtion pointer is tagged but
never checked.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
hjl.tools at gmail dot com, jakub at gcc dot gnu.org,
kcc at gcc dot gnu.org, marxin at gcc dot gnu.org,
matmal01 at gcc dot gnu.org
Target Milestone: ---
testcase is gcc/testsuite/gcc.dg/hwasan/nested-functions-0.c
__attribute__((noinline))
int *Ident(void *x) {
return x;
}
int __attribute__ ((noinline))
intermediate (void (*f) (int, char),
char num)
{
if (num == 1)
/* NOTE: We need to overrun by an amount greater than the "extra data" in a
nonlocal goto structure. The entire structure is allocated on the stack
with a single tag, which means hwasan can't tell if a closed-over buffer
was overrun by an amount small enough that the access was still to some
data in that nonlocal goto structure. */
f (100, 100);
else
f (3, 100);
/* Just return something ... */
return num % 3;
}
int* __attribute__ ((noinline))
nested_function (char num)
{
int big_array[16];
int other_array[16];
void store (int index, char value)
{ big_array[index] = value; }
return Ident(_array[intermediate (store, num)]);
}
#ifndef MAIN
int main ()
{
nested_function (0);
return 0;
}
#endif
nest function store is defined and resides one the stack of nested_function,
function pointer of store will be tagged since hwasan thought it was stack
variable, but since there's no explicit load for the function pointer, the tag
is never checked, so i wonder, is hwasan supposed to tag the function pointer?
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 --- Comment #8 from Steve Kargl --- On Wed, May 19, 2021 at 01:43:28AM +, yuri at tsoft dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 > > --- Comment #7 from Yuri --- > fpu-387.h is in the gcc10 source tree: > > $ find . -name "fpu-*" > > ./work/gcc-10.3.0/libgfortran/config/fpu-generic.h > > ./work/gcc-10.3.0/libgfortran/config/fpu-sysv.h > > ./work/gcc-10.3.0/libgfortran/config/fpu-glibc.h > > ./work/gcc-10.3.0/libgfortran/config/fpu-aix.h > > ./work/gcc-10.3.0/libgfortran/config/fpu-387.h > > fpu-aarch64.h isn't in the gcc10 tree, and not among FreeBSD-installed > headers. > > It seems that it is missing in gcc? > Yes, you would need to write the fpu-aarch64.h header.
[Bug libstdc++/100664] ranges::drop_view fails to meet its complexity requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100664 --- Comment #1 from 康桓瑋 --- (In reply to 康桓瑋 from comment #0) > Hi, in ranges#L2043, the _S_needs_cached_begin of reverse_view is defined as: This is drop_view, sorry for the typo.
[Bug libstdc++/100664] New: ranges::drop_view fails to meet its complexity requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100664
Bug ID: 100664
Summary: ranges::drop_view fails to meet its complexity
requirements
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Hi, in ranges#L2043, the _S_needs_cached_begin of reverse_view is defined as:
static constexpr bool _S_needs_cached_begin
= !(random_access_range && sized_range);
I think this definition is insufficient, because there may be a non-simple_view
V that can satisfy random_access_range && sized_range but
not random_access_range<_Vp> && sized_range<_Vp>, in this case, the complexity
of ranges::next would be O(n).
There is no such view in the standard library, but it can be easily
implemented:
(https://godbolt.org/z/oxY4e77br)
template
struct common_non_const_view : view_interface> {
private:
using I = iterator_t;
using S = sentinel_t;
V base_ = V();
public:
common_non_const_view() = default;
constexpr common_non_const_view(V base) : base_(std::move(base)) {}
constexpr auto begin()
{ return std::common_iterator{ranges::begin(base_)}; }
constexpr auto begin() const requires ranges::range
{ return std::ranges::begin(base_); }
constexpr auto end()
{ return std::common_iterator{ranges::end(base_)}; }
constexpr auto end() const requires ranges::range
{ return ranges::end(base_); }
constexpr auto size() requires sized_range
{ return ranges::size(base_); }
constexpr auto size() const requires sized_range
{ return ranges::size(base_); }
};
subrange sub(std::counted_iterator(views::iota(0).begin(), 42),
std::default_sentinel);
const common_non_const_view cr{sub};
static_assert(random_access_range);
static_assert(sized_range);
common_non_const_view r{sub};
static_assert(!random_access_range);
static_assert(forward_range);
static_assert(sized_range);
The above *const* common_non_const_view models random_access_range and
sized_range, but the non-const one only models sized_range. Since it also
models forward_range, we still need to cache the results of ranges::next() in
the begin() of drop_view, just as says in [[range.drop#view-4]]:
auto drop = r | std::views::drop(41);
static_assert(forward_range);
auto it = drop.begin(); // need cached
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 --- Comment #7 from Yuri --- fpu-387.h is in the gcc10 source tree: > $ find . -name "fpu-*" > ./work/gcc-10.3.0/libgfortran/config/fpu-generic.h > ./work/gcc-10.3.0/libgfortran/config/fpu-sysv.h > ./work/gcc-10.3.0/libgfortran/config/fpu-glibc.h > ./work/gcc-10.3.0/libgfortran/config/fpu-aix.h > ./work/gcc-10.3.0/libgfortran/config/fpu-387.h fpu-aarch64.h isn't in the gcc10 tree, and not among FreeBSD-installed headers. It seems that it is missing in gcc?
[Bug tree-optimization/100653] usage of scalar_storage_order produces incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100653 Andrew Pinski changed: What|Removed |Added Known to fail||10.1.0, 11.1.0, 12.0, 7.3.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-19 Keywords||wrong-code --- Comment #1 from Andrew Pinski --- Confirmed. It looks like some pass loses REF_REVERSE_STORAGE_ORDER. As far as I can tell it has never worked.
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662
--- Comment #6 from Steve Kargl ---
On Wed, May 19, 2021 at 12:56:57AM +, yuri at tsoft dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662
>
> --- Comment #5 from Yuri ---
> config.log doesn't contain the IEEE string even on amd64.
>
> libgfortran/configure.host seems to only enable IEEE modules on i?86 | x86_64
> architectures through this code:
>
> > case "${host_cpu}" in
> > i?86 | x86_64)
> > if test "x${have_soft_float}" = "xyes"; then
> > fpu_host='fpu-generic'
> > else
> > fpu_host='fpu-387'
> > fi
> > ieee_support='yes'
> > ;;
> > esac
>
> What does gcc need from OS for IEEE754?
> Shouldn't it just compile with relevant to IEEE754 opcodes?
>
In
x86_64-unknown-freebsd14.0/libgfortran/config.log
I see
configure:26522: FPU dependent file will be fpu-387.h
configure:26524: Support for IEEE modules: yes
Looking at libgfortran/configure and libgfortran/configure.host
and looking in libgfortran/config/, it seems you'll need to define
an fpu-aarch64.h
I don't have an aarch64 system nor access to such a system,
so can't help you more.
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662
--- Comment #5 from Yuri ---
config.log doesn't contain the IEEE string even on amd64.
libgfortran/configure.host seems to only enable IEEE modules on i?86 | x86_64
architectures through this code:
> case "${host_cpu}" in
> i?86 | x86_64)
> if test "x${have_soft_float}" = "xyes"; then
> fpu_host='fpu-generic'
> else
> fpu_host='fpu-387'
> fi
> ieee_support='yes'
> ;;
> esac
What does gcc need from OS for IEEE754?
Shouldn't it just compile with relevant to IEEE754 opcodes?
[Bug c++/100261] [11/12 Regression] ICE: tree check: expected var_decl or type_decl, have error_mark in emit_tinfo_decl, at cp/rtti.c:1643
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100261 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:fff482625ab184210d9121515b9ea98945dc0b6f commit r11-8434-gfff482625ab184210d9121515b9ea98945dc0b6f Author: Jason Merrill Date: Tue May 18 17:15:42 2021 -0400 c++: ICE with bad definition of decimal32 [PR100261] The change to only look at the global binding for non-classes meant that here, when dealing with decimal32 which is magically mangled like its first non-static data member, we got a collision with the mangling for float. Fixed by also looking up an existing binding for such magical classes. PR c++/100261 gcc/cp/ChangeLog: * rtti.c (get_tinfo_decl_direct): Check TYPE_TRANSPARENT_AGGR. gcc/testsuite/ChangeLog: * g++.dg/dfp/mangle-6.C: New test.
[Bug c++/100372] [11/12 Regression] ICE with variadic template template, internal compiler error: in strip_typedefs, at cp/tree.c:1544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100372 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:74ad5558d2acddcf4f5e96129ec29dd2f3d47d3a commit r11-8433-g74ad5558d2acddcf4f5e96129ec29dd2f3d47d3a Author: Jason Merrill Date: Tue May 18 17:12:37 2021 -0400 c++: template template parm pack expansion [PR100372] Here we have a pack expansion of a template template parameter pack, of which the pattern is a TEMPLATE_DECL, which strip_typedefs doesn't want to see. PR c++/100372 gcc/cp/ChangeLog: * tree.c (strip_typedefs): Only look at the pattern of a TYPE_PACK_EXPANSION if it's a type. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/alias-decl-ttp1.C: New test.
[Bug jit/95415] Add support for thread-local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95415 --- Comment #3 from Antoni --- Created attachment 50842 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50842=edit Patch to add this feature I created a patch to add TLS variables.
[Bug c++/100261] [11/12 Regression] ICE: tree check: expected var_decl or type_decl, have error_mark in emit_tinfo_decl, at cp/rtti.c:1643
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100261 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:01b2864757540d24c4e717a77b40b29369c064b2 commit r12-895-g01b2864757540d24c4e717a77b40b29369c064b2 Author: Jason Merrill Date: Tue May 18 17:15:42 2021 -0400 c++: ICE with bad definition of decimal32 [PR100261] The change to only look at the global binding for non-classes meant that here, when dealing with decimal32 which is magically mangled like its first non-static data member, we got a collision with the mangling for float. Fixed by also looking up an existing binding for such magical classes. PR c++/100261 gcc/cp/ChangeLog: * rtti.c (get_tinfo_decl_direct): Check TYPE_TRANSPARENT_AGGR. gcc/testsuite/ChangeLog: * g++.dg/dfp/mangle-6.C: New test.
[Bug c++/100372] [11/12 Regression] ICE with variadic template template, internal compiler error: in strip_typedefs, at cp/tree.c:1544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100372 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:061fe8c58ac4d436906a404f7fb46b0a6e0d7b4f commit r12-894-g061fe8c58ac4d436906a404f7fb46b0a6e0d7b4f Author: Jason Merrill Date: Tue May 18 17:12:37 2021 -0400 c++: template template parm pack expansion [PR100372] Here we have a pack expansion of a template template parameter pack, of which the pattern is a TEMPLATE_DECL, which strip_typedefs doesn't want to see. PR c++/100372 gcc/cp/ChangeLog: * tree.c (strip_typedefs): Only look at the pattern of a TYPE_PACK_EXPANSION if it's a type. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/alias-decl-ttp1.C: New test.
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 --- Comment #4 from Steve Kargl --- On Tue, May 18, 2021 at 10:47:30PM +, yuri at tsoft dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 > > --- Comment #3 from Yuri --- > On amd64 gcc installs the file finclude/ieee_arithmetic.mod > and on aarch64 this file isn't installed. > > What is installed is defined by the gcc build process. > Does FreeBSD support IEEE754 on aarch64? What does config.log say about IEEE modules?
[Bug libstdc++/100606] Please complete LWG3490: ranges::drop_while_view::begin() is missing a precondition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100606 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-05-19 Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 --- Comment #3 from Yuri --- On amd64 gcc installs the file finclude/ieee_arithmetic.mod and on aarch64 this file isn't installed. What is installed is defined by the gcc build process.
[Bug libstdc++/100663] dietlibc build fail 'FP_NAN' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100663
Andrew Pinski changed:
What|Removed |Added
Keywords||build
Severity|normal |enhancement
--- Comment #1 from Andrew Pinski ---
I don't think *-linux-dietlibc support has been ever upstreamed into GCC.
I am just seeing the support from config.{guess,sub} and libtool. Nothing in
libgcc/config.host, gcc/config.gcc, or libstdc++/configure.host .
So you will need to add much more support than just libstdc++ here.
Since this was never supported, I am thinking about closing this as invalid but
I will let someone else make that call.
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 --- Comment #2 from Yuri --- intrinsic::ieee_arithmetic works fine on amd64/i386 architectures on the same OS. What do you think is missing/wrong in the OS that causes it?
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Looks like an OS problem. Not sure GCC can do anything here.
[Bug c++/100644] [11/12 regression] Deleted move constructor prevents templated constructor from being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100644 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6384e940a6db379b0524465cf6cbbd0996b48485 commit r11-8431-g6384e940a6db379b0524465cf6cbbd0996b48485 Author: Jason Merrill Date: Tue May 18 12:06:36 2021 -0400 c++: "perfect" implicitly deleted move [PR100644] Here we were ignoring the template constructor because the implicit move constructor had all perfect conversions. But CWG1402 says that an implicitly deleted move constructor is ignored by overload resolution; we implement that instead by preferring any other candidate in joust, to get better diagnostics, but that means we need to handle that case here as well. gcc/cp/ChangeLog: PR c++/100644 * call.c (perfect_candidate_p): An implicitly deleted move is not perfect. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/implicit-delete1.C: New test.
[Bug c++/100205] [11/12 Regression] error: invalid use of non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b786dafe9eb933f23686c68c6d7110fef5656985 commit r11-8430-gb786dafe9eb933f23686c68c6d7110fef5656985 Author: Jason Merrill Date: Wed Apr 14 11:24:50 2021 -0400 c++: constant expressions are evaluated [PR93314] My GCC 11 patch for PR93314 turned off cp_unevaluated_operand while processing an id-expression that names a non-static data member, but the broader issue is that in general, a constant-expression is evaluated even in an unevaluated operand. This also fixes 100205, introduced by the earlier patch that couldn't distinguish between the different allow_non_constant_p cases. PR c++/100205 PR c++/93314 gcc/cp/ChangeLog: * cp-tree.h (cp_evaluated): Add reset parm to constructor. * parser.c (cp_parser_constant_expression): Change allow_non_constant_p to int. Use cp_evaluated. (cp_parser_initializer_clause): Pass 2 to allow_non_constant_p. * semantics.c (finish_id_expression_1): Don't mess with cp_unevaluated_operand here. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/decltype-nonstatic1.C: New test.
[Bug c++/93314] [9/10 Regression] Invalid use of non-static data member causes ICE in gimplify_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93314 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b786dafe9eb933f23686c68c6d7110fef5656985 commit r11-8430-gb786dafe9eb933f23686c68c6d7110fef5656985 Author: Jason Merrill Date: Wed Apr 14 11:24:50 2021 -0400 c++: constant expressions are evaluated [PR93314] My GCC 11 patch for PR93314 turned off cp_unevaluated_operand while processing an id-expression that names a non-static data member, but the broader issue is that in general, a constant-expression is evaluated even in an unevaluated operand. This also fixes 100205, introduced by the earlier patch that couldn't distinguish between the different allow_non_constant_p cases. PR c++/100205 PR c++/93314 gcc/cp/ChangeLog: * cp-tree.h (cp_evaluated): Add reset parm to constructor. * parser.c (cp_parser_constant_expression): Change allow_non_constant_p to int. Use cp_evaluated. (cp_parser_initializer_clause): Pass 2 to allow_non_constant_p. * semantics.c (finish_id_expression_1): Don't mess with cp_unevaluated_operand here. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/decltype-nonstatic1.C: New test.
[Bug c++/100261] [11/12 Regression] ICE: tree check: expected var_decl or type_decl, have error_mark in emit_tinfo_decl, at cp/rtti.c:1643
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100261 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org
[Bug libstdc++/100663] New: dietlibc build fail 'FP_NAN' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100663 Bug ID: 100663 Summary: dietlibc build fail 'FP_NAN' was not declared in this scope Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- Created attachment 50841 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50841=edit error message There are other build issues. 1. __leaf variables are macros on dietlibc. 2. libstdc++ script mistreats dietlibc as glibc and uses glibc's locale setting which needs to be fixed.
[Bug fortran/98411] [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 --- Comment #9 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #8) Looking some more into this: I couldn't find a consistent concept of setting variables to implicit-save as e.g. described in F2018 section 8.5.16 clause 4. A hackish approach to fix the remaining part of this PR could look like diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c index 406b4aeb1d4..a2498a04fb9 100644 --- a/gcc/fortran/trans-decl.c +++ b/gcc/fortran/trans-decl.c @@ -737,8 +737,10 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym) /* Keep variables larger than max-stack-var-size off stack. */ if (!(sym->ns->proc_name && sym->ns->proc_name->attr.recursive) + && !(sym->ns->proc_name && sym->ns->proc_name->attr.is_main_program) && !sym->attr.automatic && sym->attr.save != SAVE_EXPLICIT + && sym->attr.save != SAVE_IMPLICIT && INTEGER_CST_P (DECL_SIZE_UNIT (decl)) && !gfc_can_put_var_on_stack (DECL_SIZE_UNIT (decl)) /* Put variable length auto array pointers always into stack. */ However, the first part of this patch would only address variables in the main program, and the second part needs proper setting of SAVE_IMPLICIT, which is not yet done. As a sidenote: the above would regtest ok and fix comment#0.
[Bug c++/100372] [11/12 Regression] ICE with variadic template template, internal compiler error: in strip_typedefs, at cp/tree.c:1544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100372 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/98617] Failure to recognize pack expansion argument for non-pack parameter of alias template when alias is "exact"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98617
--- Comment #1 from Jonathan Wakely ---
Please provide the actual code, not only a CE link:
template struct Base {};
template using A = Base;
template using B = Base;
template using C = Base;
template
using AliasA = A; // this should fail
template
using AliasB = B;
template
using AliasC = C;
Reduced to remove the bits that do fail as expected:
template struct Base {};
template using A = Base;
template
using AliasA = A; // this should fail
[Bug c++/98617] Failure to recognize pack expansion argument for non-pack parameter of alias template when alias is "exact"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98617 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-18 Status|UNCONFIRMED |NEW
[Bug c/100619] [11/12 Regression] ICE: in build_attr_access_from_parms, at c-family/c-attribs.c:5038 since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100619 Martin Sebor changed: What|Removed |Added Known to fail||11.1.0, 12.0 Keywords||ice-on-valid-code Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/100205] [11/12 Regression] error: invalid use of non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205 --- Comment #11 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Awesome, thank you, Jason!
[Bug c++/99976] gcc accepts requires-clause contains unexpanded parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99976 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99967 Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-18 Ever confirmed|0 |1
[Bug c++/99967] gcc accepts declaration type contains unexpanded parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99967 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-18 Status|UNCONFIRMED |NEW
[Bug c++/84337] Variadic expansion is accepted on not parameter pack template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84337 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- That's not a pack expansion, that's a printf-style varargs function. The comma before the ellipsis is optional.
[Bug testsuite/100658] Typos in dg commands and texi files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100658 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-05-18 Keywords||easyhack Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug testsuite/100655] 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655 --- Comment #2 from Jonathan Wakely --- It's not glibc-specific though, it's going to be in the next POSIX standard and other C libraries. It's a bit of a hack, but you could include any libstdc++ header and then check _GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT (because libstdc++ already has autoconf checks for it).
[Bug target/99314] [Patch] [RISC-V] g++.dg/opt/memcpy1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99314
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:8c114759b8c9c9e2ec90b82d92a24b5a71647017
commit r12-886-g8c114759b8c9c9e2ec90b82d92a24b5a71647017
Author: Jason Merrill
Date: Tue May 18 12:18:56 2021 -0400
c++: non-static member, decltype, {} [PR100205]
This test was fixed by my second patch for PR93314, which distinguishes
between constant-expression and potentially-constant-evaluated contexts in
a
way that my first patch did not.
PR c++/100205
PR c++/99314
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/decltype-nonstatic1.C: New test.
[Bug c++/100205] [11/12 Regression] error: invalid use of non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:8c114759b8c9c9e2ec90b82d92a24b5a71647017
commit r12-886-g8c114759b8c9c9e2ec90b82d92a24b5a71647017
Author: Jason Merrill
Date: Tue May 18 12:18:56 2021 -0400
c++: non-static member, decltype, {} [PR100205]
This test was fixed by my second patch for PR93314, which distinguishes
between constant-expression and potentially-constant-evaluated contexts in
a
way that my first patch did not.
PR c++/100205
PR c++/99314
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/decltype-nonstatic1.C: New test.
[Bug c++/100644] [11/12 regression] Deleted move constructor prevents templated constructor from being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100644 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:f71ca97def69b8aeb046d716eaea2367736f505e commit r12-885-gf71ca97def69b8aeb046d716eaea2367736f505e Author: Jason Merrill Date: Tue May 18 12:06:36 2021 -0400 c++: "perfect" implicitly deleted move [PR100644] Here we were ignoring the template constructor because the implicit move constructor had all perfect conversions. But CWG1402 says that an implicitly deleted move constructor is ignored by overload resolution; we implement that instead by preferring any other candidate in joust, to get better diagnostics, but that means we need to handle that case here as well. gcc/cp/ChangeLog: PR c++/100644 * call.c (perfect_candidate_p): An implicitly deleted move is not perfect. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/implicit-delete1.C: New test.
[Bug libstdc++/100639] reverse_iterator::reference erroneously uses iterator_traits::reference instead of iter_reference_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100639 --- Comment #1 from Patrick Palka --- The assertion also fails when __int128 isn't available (which can be simulated by compiling with -U__SIZEOF_INT128__), because in that case iota_view's difference_type is the integer-like class type __max_diff_type, and integer-like class types aren't integral even in GNU mode.
[Bug fortran/100662] New: intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 Bug ID: 100662 Summary: intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: yuri at tsoft dot com Target Milestone: --- Fortran codes using intrinsic::ieee_arithmetic on aarch, powerpc architectures fail to compile. See details in this FreeBSD bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255890
[Bug fortran/100602] [11/12 Regression] Erroneous "pointer argument is not associated" runtime error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100602 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-May/056049.html
[Bug libstdc++/100639] reverse_iterator::reference erroneously uses iterator_traits::reference instead of iter_reference_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100639 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Summary|reverse_view::reference |reverse_iterator::refere |erroneously uses|nce erroneously uses |iterator_traits::referen |iterator_traits::referen |ce instead of |ce instead of |iter_reference_t |iter_reference_t
[Bug fortran/100656] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100656 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-05-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug c/100661] New: [11/12 Regression] ICE in refs_may_alias_p_2, at tree-ssa-alias.c:2460
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100661
Bug ID: 100661
Summary: [11/12 Regression] ICE in refs_may_alias_p_2, at
tree-ssa-alias.c:2460
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20201018 and 20201108 :
$ cat z1.c
void f (char **x)
{
#pragma omp parallel for
for (int i = 0; i < 16; i++)
{
char c[50];
__builtin_strcpy (c, x[i]);
int g (char)
{
__builtin_strcat (c, "foo");
}
}
}
$ gcc-11-20201018 -c z1.c -O2 -fopenmp
z1.c: In function 'g':
z1.c:8:14: error: parameter name omitted
8 | int g (char)
| ^~~~
$ gcc-12-20210516 -c z1.c -O2 -fopenmp
during GIMPLE pass: fre
z1.c: In function 'f._omp_fn.0':
z1.c:13:1: internal compiler error: in refs_may_alias_p_2, at
tree-ssa-alias.c:2460
13 | }
| ^
0xc40fa0 refs_may_alias_p_2
../../gcc/tree-ssa-alias.c:2460
0xc40fa0 refs_may_alias_p_1(ao_ref*, ao_ref*, bool)
../../gcc/tree-ssa-alias.c:2469
0xc4196d check_fnspec
../../gcc/tree-ssa-alias.c:2677
0xc41c30 call_may_clobber_ref_p_1(gcall*, ao_ref*, bool)
../../gcc/tree-ssa-alias.c:3051
0xc4293e stmt_may_clobber_ref_p_1(gimple*, ao_ref*, bool)
../../gcc/tree-ssa-alias.c:3127
0xc42b66 maybe_skip_until
../../gcc/tree-ssa-alias.c:3524
0xc42b66 get_continuation_for_phi(gimple*, ao_ref*, bool, unsigned int&,
bitmap_head**, bool, void* (*)(ao_ref*, tree_node*, void*, translate_flags*),
void*, translate_flags)
../../gcc/tree-ssa-alias.c:3601
0xc42f18 walk_non_aliased_vuses(ao_ref*, tree_node*, bool, void* (*)(ao_ref*,
tree_node*, void*), void* (*)(ao_ref*, tree_node*, void*, translate_flags*),
tree_node* (*)(tree_node*), unsigned int&, void*)
../../gcc/tree-ssa-alias.c:3690
0xcf4b96 vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**, tree_node*)
../../gcc/tree-ssa-sccvn.c:3614
0xcfabc4 visit_reference_op_load
../../gcc/tree-ssa-sccvn.c:5063
0xcfabc4 visit_stmt
../../gcc/tree-ssa-sccvn.c:5503
0xcfb67b process_bb
../../gcc/tree-ssa-sccvn.c:7203
0xcfd0b8 do_rpo_vn
../../gcc/tree-ssa-sccvn.c:7688
0xcfda5f execute
../../gcc/tree-ssa-sccvn.c:7956
[Bug middle-end/100593] [ELF] -fno-pic: Use GOT to take address of an external default visibility function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #8 from Fangrui Song ---
Seems that -fno-plt -fno-pic does have the required properties.
A side effect is that all external calls use the (x86-64) call
*f@GOTPCREL(%rip) (x86-32) call *f@GOT form.
The instruction is one byte longer. (Calling a function is a common case.
Taking the address in a non-vtable case is uncommon. So I'd rather punish the
uncommon address taking).
When the linker notices that the branch target is defined in the executable, it
can optimize out the GOT to use an addr32 prefix instead.
(gold and ld.lld haven't implemented the optimization for 32-bit)
__attribute__((noplt))
int f();
void h() {}
void *g()
{
h(); // call h
f(); // call *f@GOTPCREL(%rip)
return f; // movq f@GOTPCREL(%rip), %rax
}
[Bug c/100660] New: [11/12 Regression] ICE in visit_assignment, at tree-ssa-ccp.c:2451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100660
Bug ID: 100660
Summary: [11/12 Regression] ICE in visit_assignment, at
tree-ssa-ccp.c:2451
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20210418 and 20210425.
Testcase derived from gcc.target/i386/pr98911.c
with modification s/return// :
$ cat z1.c
typedef char v16qi __attribute__ ((vector_size (16)));
v16qi
f5 (v16qi a, v16qi b)
{
__builtin_ia32_pcmpgtb128 (a, b);
}
$ gcc-12-20210516 -c z1.c -O2
during GIMPLE pass: ccp
z1.c: In function 'f5':
z1.c:7:1: internal compiler error: Segmentation fault
7 | }
| ^
0xb68d3f crash_signal
../../gcc/toplev.c:327
0xc4d033 visit_assignment
../../gcc/tree-ssa-ccp.c:2451
0xcd2003 ssa_propagation_engine::simulate_stmt(gimple*)
../../gcc/tree-ssa-propagate.c:230
0xcd227a ssa_propagation_engine::simulate_block(basic_block_def*)
../../gcc/tree-ssa-propagate.c:337
0xcd2782 ssa_propagation_engine::ssa_propagate()
../../gcc/tree-ssa-propagate.c:504
0xc454b7 do_ssa_ccp
../../gcc/tree-ssa-ccp.c:2574
0xc454b7 execute
../../gcc/tree-ssa-ccp.c:2618
---
during GIMPLE pass: lower
z1.c: In function 'f5':
z1.c:4:1: internal compiler error: Segmentation fault
4 | f5 (v16qi a, v16qi b)
| ^~
0xd46ddf crash_signal
../../gcc/toplev.c:327
0xd8b9a5 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3469
0xd8b9a5 verify_gimple_assign_ternary
../../gcc/tree-cfg.c:4191
0xd8b9a5 verify_gimple_assign
../../gcc/tree-cfg.c:4701
0xd8b9a5 verify_gimple_stmt
../../gcc/tree-cfg.c:4957
0xd8d5af verify_gimple_in_seq_2
../../gcc/tree-cfg.c:5119
0xd91fa1 verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:5158
0xc4fdaa execute_function_todo
../../gcc/passes.c:2044
0xc50af2 execute_todo
../../gcc/passes.c:2096
[Bug c++/100659] New: [11/12 Regression] ICE in supplement_binding_1, at cp/name-lookup.c:2702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100659
Bug ID: 100659
Summary: [11/12 Regression] ICE in supplement_binding_1, at
cp/name-lookup.c:2702
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20201108 and 20201115 :
$ cat z1.cc
template struct A
{
A::E::V;
enum { V };
};
$ g++-12-20210516 -c z1.cc
z1.cc:3:3: warning: access declarations are deprecated in favour of
using-declarations; suggestion: add the 'using' keyword [-Wdeprecated]
3 | A::E::V;
| ^
z1.cc:4:10: internal compiler error: Segmentation fault
4 | enum { V };
| ^
0xce3fcf crash_signal
../../gcc/toplev.c:327
0x75543c supplement_binding_1
../../gcc/cp/name-lookup.c:2702
0x759e06 supplement_binding
../../gcc/cp/name-lookup.c:2746
0x759e06 push_class_level_binding_1
../../gcc/cp/name-lookup.c:5549
0x759e06 push_class_level_binding(tree_node*, tree_node*)
../../gcc/cp/name-lookup.c:5567
0x759f7e pushdecl_class_level(tree_node*)
../../gcc/cp/name-lookup.c:5280
0x7eb4d7 finish_member_declaration(tree_node*)
../../gcc/cp/semantics.c:3468
0x6dda21 build_enumerator(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int)
../../gcc/cp/decl.c:16323
0x781d79 cp_parser_enumerator_definition
../../gcc/cp/parser.c:20284
0x781d79 cp_parser_enumerator_list
../../gcc/cp/parser.c:20213
0x781d79 cp_parser_enum_specifier
../../gcc/cp/parser.c:20143
0x781d79 cp_parser_type_specifier
../../gcc/cp/parser.c:18455
0x782246 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:15086
0x7a560a cp_parser_member_declaration
../../gcc/cp/parser.c:26003
0x77f7de cp_parser_member_specification_opt
../../gcc/cp/parser.c:25860
0x77f7de cp_parser_class_specifier_1
../../gcc/cp/parser.c:24932
0x781750 cp_parser_class_specifier
../../gcc/cp/parser.c:25248
0x781750 cp_parser_type_specifier
../../gcc/cp/parser.c:18485
0x782246 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:15086
0x7a43f5 cp_parser_single_declaration
../../gcc/cp/parser.c:30513
[Bug testsuite/100655] 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655 --- Comment #1 from Michael de Lang --- It'd be fairly trivial to wrap the test in an ifdef: #ifdef __GLIBC__ #if (__GLIBC__ >= 2 && __GLIBC_MINOR__>= 30) || __GLIBC__>= 3 // test here #endif #endif
[Bug testsuite/100658] New: Typos in dg commands and texi files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100658
Bug ID: 100658
Summary: Typos in dg commands and texi files
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
There is one naming difference : s/Identifification/Identification/
./gcc/ada/gnat_rm.texi:20880:@item @code{Ada.Task_Identifification}
@emph{(C.7.1)}
---
Another typo : s/identfier/identifier/
./gcc/testsuite/gcc.dg/ucnid-5-utf8.c:2:/* { dg-skip-if "No dollar in
identfiers" { avr-*-* powerpc-ibm-aix* } } */
./gcc/testsuite/gcc.dg/ucnid-5.c:2:/* { dg-skip-if "No dollar in identfiers" {
avr-*-* powerpc-ibm-aix* } } */
Additionally, other places use sign "$" explicitly, if that matters here at all
:
./gcc/testsuite/gcc.dg/cpp/lexident.c:8:/* Escaped newlines, _ and $ in
identifiers. */
./gcc/testsuite/gcc.target/i386/pr91298-1.c:4:/* { dg-xfail-if "No support for
$ in identifiers" { *-*-solaris2.* && { ! gas } } } */
./gcc/testsuite/gcc.target/i386/pr91298-2.c:4:/* { dg-xfail-if "No support for
$ in identifiers" { *-*-solaris2.* && { ! gas } } } */
./libcpp/charset.c:1131: cpp_error (pfile, CPP_DL_PEDWARN, "'$' in
identifier or number");
./libcpp/lex.c:1335: cpp_error (pfile, CPP_DL_PEDWARN, "'$' in identifier
or number");
---
Other cases :
s/identier/identifier/
./gcc/jit/libgccjit.c:912: C's rules for identiers upon the name, using
ISALPHA and ISALNUM
s/identifer/identifier/
./gcc/cp/mangle.c:838:/* Interface to substitution and identifer mangling, used
by the
./gcc/testsuite/gcc.dg/local1.c:13: identifer has external linkage.
[Bug target/100657] New: [GCN offloading] 'libgomp.c-c++-common/reduction-6.c' execution times out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100657 Bug ID: 100657 Summary: [GCN offloading] 'libgomp.c-c++-common/reduction-6.c' execution times out Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: ams at gcc dot gnu.org, burnus at gcc dot gnu.org, jakub at gcc dot gnu.org, jules at gcc dot gnu.org Target Milestone: --- Target: gcn For GCN '-foffload=amdgcn-amdhsa=-march=gfx908' (only), the 'libgomp.c-c++-common/reduction-6.c' testcase recently added with commit r12-614-g33b647956caa977d1ae489f9baed9cef70b4f382 "OpenMP: Fix SIMT for complex/float reduction with && and ||" seems to consistently time out, both C and C++ execution testing. On other GCN/other offloading configurations it seems almost instantaneous to execute. I've confirmed this on both our amd-instinct1 and amd-instinct2 systems.
[Bug fortran/100656] New: ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100656 Bug ID: 100656 Summary: ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : (with option -fcheck=all or -fcheck=bounds) $ cat z1.f90 subroutine s(x) character(:), allocatable, optional :: x(:) if ( present(x) ) then if ( allocated(x) ) then x = 'a' // x // 'e' end if end if end $ gfortran-12-20210516 -c z1.f90 -fcheck=all z1.f90:5:28: 5 | x = 'a' // x // 'e' |1 internal compiler error: in gfc_conv_expr_present, at fortran/trans-expr.c:1934 0x767b80 gfc_conv_expr_present(gfc_symbol*, bool) ../../gcc/fortran/trans-expr.c:1934 0x745114 gfc_conv_ss_startstride(gfc_loopinfo*) ../../gcc/fortran/trans-array.c:4723 0x77b991 gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:11218 0x73dcb7 trans_code ../../gcc/fortran/trans.c:1932 0x7aa2f5 gfc_trans_if_1 ../../gcc/fortran/trans-stmt.c:1475 0x7b1e8a gfc_trans_if(gfc_code*) ../../gcc/fortran/trans-stmt.c:1507 0x73ddd7 trans_code ../../gcc/fortran/trans.c:2020 0x7aa2f5 gfc_trans_if_1 ../../gcc/fortran/trans-stmt.c:1475 0x7b1e8a gfc_trans_if(gfc_code*) ../../gcc/fortran/trans-stmt.c:1507 0x73ddd7 trans_code ../../gcc/fortran/trans.c:2020 0x764314 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6885 0x6eac86 translate_all_program_units ../../gcc/fortran/parse.c:6370 0x6eac86 gfc_parse_file() ../../gcc/fortran/parse.c:6639 0x736f7f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug testsuite/100655] New: 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655 Bug ID: 100655 Summary: 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: kingoipo at gmail dot com, marxin at gcc dot gnu.org Target Milestone: --- This new testcase recently added in commit r12-794-g80b4ce1a5190ebe764b1009afae57dcef45f92c2 "TSAN: add new test" FAILs on one of my testing systems: +FAIL: g++.dg/tsan/pthread_cond_clockwait.C -O0 (test for excess errors) +UNRESOLVED: g++.dg/tsan/pthread_cond_clockwait.C -O0 compilation failed to produce executable +FAIL: g++.dg/tsan/pthread_cond_clockwait.C -O2 (test for excess errors) +UNRESOLVED: g++.dg/tsan/pthread_cond_clockwait.C -O2 compilation failed to produce executable [...]/gcc/testsuite/g++.dg/tsan/pthread_cond_clockwait.C: In function 'int main()': [...]/gcc/testsuite/g++.dg/tsan/pthread_cond_clockwait.C:26:5: error: 'pthread_cond_clockwait' was not declared in this scope; did you mean 'pthread_cond_wait'? Apparently 'pthread_cond_clockwait' has been added in glibc 2.30, released 2019-08-01. Leave it as it is, or conditionalize the testcase in some way?
[Bug analyzer/100615] analyzer failed to report leak in rxtxcpu's parse_cpu_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100615 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:cd323d97d0592135ca4345701ef051659d8d4507 commit r12-884-gcd323d97d0592135ca4345701ef051659d8d4507 Author: David Malcolm Date: Tue May 18 12:29:58 2021 -0400 analyzer: fix missing leak after call to strsep [PR100615] PR analyzer/100615 reports a missing leak diagnostic. The issue is that the code calls strsep which the analyzer doesn't have special knowledge of, and so conservatively assumes that it could free the pointer, so drops malloc state for it. Properly "teaching" the analyzer about strsep would require it to support bifurcating state at a call, which is currently fiddly to do, so for now this patch notes that strsep doesn't affect the malloc state machine, allowing the analyzer to correctly detect the leak. gcc/analyzer/ChangeLog: PR analyzer/100615 * sm-malloc.cc: Include "analyzer/function-set.h". (malloc_state_machine::on_stmt): Call unaffected_by_call_p and bail on the functions it recognizes. (malloc_state_machine::unaffected_by_call_p): New. gcc/testsuite/ChangeLog: PR analyzer/100615 * gcc.dg/analyzer/pr100615.c: New test.
[Bug c++/100367] [11/12 Regression] Internal compiler error when std::lexicographical_compare_three_way third and fourth argument are reverse iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100367 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug bootstrap/100654] New: trunk bootstrap errors with -O0 and -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100654 Bug ID: 100654 Summary: trunk bootstrap errors with -O0 and -O1 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: manfred99 at gmx dot ch Target Milestone: --- linux x86_64 and i686 (GCC 7.5 as bootstrap compiler), with BOOT_CFLAGS="-O0 -g": ../../gcc-trunk-source/gcc/gcc/opts.c: In function 'void print_filtered_help(unsigned int, unsigned int, unsigned int, unsigned int, gcc_options*, unsigned int)': ../../gcc-trunk-source/gcc/gcc/opts.c:1406:26: error: ' ' directive output may be truncated writing 2 bytes into a region of size between 1 and 256 [-Werror=format-truncation=] 1406 | "%s %s", help, _(use_diagnosed_msg)); | ^~ ../../gcc-trunk-source/gcc/gcc/opts.c:1405:22: note: 'snprintf' output 3 or more bytes (assuming 258) into a destination of size 256 1405 | snprintf (new_help, sizeof new_help, | ~^~~ 1406 | "%s %s", help, _(use_diagnosed_msg)); | ~ last successful bootstrap for my daily builds with "-O0" was 99e8df7a4cc0bb1bfa49e69ccb0f7e02c9755e3c (2021-05-05). with BOOT_CFLAGS="-O1 -g": ../../gcc-trunk-source/gcc/gcc/gimplify.c: In function 'gimplify_status gimplify_omp_loop(tree_node**, gimple**)': ../../gcc-trunk-source/gcc/gcc/gimplify.c:12967:17: error: 'last' may be used uninitialized in this function [-Werror=maybe-uninitialized] 12967 | if (pass != last) | ^~ trunk builds fine with "-O2" however.
[Bug c++/100205] [11/12 Regression] error: invalid use of non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/100644] [11/12 regression] Deleted move constructor prevents templated constructor from being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100644 Jason Merrill changed: What|Removed |Added Last reconfirmed||2021-05-18 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 Andrew Macleod changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #16 from Andrew Macleod --- Aldy and I are discussing this. Ranger itself can't do anything outside of the gimple IL, its effectively just a GIMPLE interface to range-ops. ... but I don't think it would be hard to add a range-ops expression evaluator. I notice the multiple_of_p's "top" argument is an expression tree ie: g_2823_lsm.5_13 * 7854 + 57682 We could add an expression evaluator that can walk that expression, invoking range-ops on each expression, and calling a ranger instance to evaluate a range for any ssa_name it finds. It would bail if there are unknown tree-codes to range-ops. I don't think this is a particularly difficult thing to do, but by itself doesn't really tell you if an overflow is possible Once we can evaluate an expression outside of the IL like this, it would also not be difficult to then evaluate the expression in an increased precision. We could cast the range at each point of the evaluation to the increased precision and invoke range-ops on that range. We could tell at any point if an overflow is possible because the increased precision calculation would be different than the original. so the original expression is in 16 bit math, and if it was evaluated as [0, 65535] * [7854, 7854] + [57682, 57682] in 32 bit precision, it would come back with the answer [57682, 514769572]. Casting the final original value to 32 bit would yield a different result, and we could conclude than an overflow is possible. Would this be useful? and would it solve this problem? I'm sure there are other details to work out related to the increased precision, but it seems like it might work? I think Martin Sebor was also interested in something along these lines so I'm CC ing him. I think he wanted to do this within the IL for some of his warnings.. but I think something similar is feasible with an IL walk rather than expression walk.
[Bug debug/78685] -Og generates too many ""s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 --- Comment #20 from rsandifo at gcc dot gnu.org --- (In reply to Eric Gallager from comment #19) > (In reply to rsand...@gcc.gnu.org from comment #18) > > (In reply to Eric Gallager from comment #17) > > > Richard Sandiford had a series of patches radically overhauling how -Og > > > works in general that might affect this bug: > > > https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01392.html > > > cc-ing him so he can comment on if it does in fact affect this bug. > > > > Yeah, part 2 of the series fixes this PR: > > https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01394.html > > Has this series been merged yet? Or at least pinged recently? It was only an RFC and wasn't ready for inclusion. There didn't seem to be much support for the idea so TBH I've mostly dropped it.
[Bug target/100637] [i386] Vectorize 4-byte vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100637 --- Comment #2 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:46ca31d65092e5afcef292f807fcf14c5363280d commit r12-883-g46ca31d65092e5afcef292f807fcf14c5363280d Author: Uros Bizjak Date: Tue May 18 17:25:54 2021 +0200 i386: Implement 4-byte vector support [PR100637] Add infrastructure, logic and arithmetic support for 4-byte vectors. These can be used with SSE2 targets, where movd instructions from/to XMM registers are available. x86_64 ABI passes 4-byte vectors in integer registers, so also add logic operations with integer registers. 2021-05-18 Uroš Bizjak gcc/ PR target/100637 * config/i386/i386.h (VALID_SSE2_REG_MODE): Add V4QI and V2HI modes. (VALID_INT_MODE_P): Ditto. * config/i386/mmx.md (VI_32): New mode iterator. (mmxvecsize): Handle V4QI and V2HI. (Yv_Yw): Ditto. (mov): New expander. (*mov_internal): New insn pattern. (movmisalign): New expander. (neg): New expander. (3): New expander. (*3): New insn pattern. (mulv2hi3): New expander. (*mulv2hi3): New insn pattern. (one_cmpl2): New expander. (*andnot3): New insn pattern. (3): New expander. (*3): New insn pattern. gcc/testsuite/ PR target/100637 * gcc.target/i386/pr100637-1b.c: New test. * gcc.target/i386/pr100637-1w.c: Ditto. * gcc.target/i386/pr92658-avx2-2.c: Do not XFAIL scan for pmovsxbq. * gcc.target/i386/pr92658-avx2.c: Do not XFAIL scan for pmovzxbq. * gcc.target/i386/pr92658-avx512vl.c: Do not XFAIL scan for vpmovdb. * gcc.target/i386/pr92658-sse4-2.c: Do not XFAIL scan for pmovsxbd and pmovsxwq. * gcc.target/i386/pr92658-sse4.c: Do not XFAIL scan for pmovzxbd and pmovzxwq.
[Bug tree-optimization/100653] New: usage of scalar_storage_order produces incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100653 Bug ID: 100653 Summary: usage of scalar_storage_order produces incorrect result Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- Created attachment 50840 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50840=edit scalar_storage_order test case Attached test case produces invalid results with -O2, good with -O1. Known to fail : 11.1 10.3 9.3 8.5 7.5 Known to work: 6.5 Target: x86_64-linux-gnu $ gcc test.c -o /tmp/test -O2 -Wall -Wextra && /tmp/test a0a1e01 EQ? 11e0a0a 0 $ gcc test.c -o /tmp/test -O1 -Wall -Wextra && /tmp/test a0a1e01 EQ? a0a1e01 1 Thank you
[Bug c++/100652] Unexpanded parameter pack in partial specialization of variable template not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100652 Marek Polacek changed: What|Removed |Added Keywords||accepts-invalid Last reconfirmed||2021-05-18 Summary|Uexpanded parameter pack in |Unexpanded parameter pack |partial specialization of |in partial specialization |variable template not |of variable template not |rejected|rejected Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/100649] [9/10/11/12 Regression] ICE in coerce_template_parms (releases) or cxx_eval_constant_expression (trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100649 --- Comment #4 from Eric Botcazou --- > Confirmed. Compiled without errors with GCC 7. The error is properly issued in C++11 mode (-std=c++11): t.cpp: In member function 'void B::foo(const A<32>&)': t.cpp:12:23: error: 'mesg' is not a constant expression 12 | A<2 + mesg.size()> local_mesg; | ^
[Bug fortran/100642] [12 Regression] ICE in omp_code_to_statement, at fortran/openmp.c:6907 since r12-20-ga61c4964cd714462
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100642 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tobias Burnus --- FIXED. Thanks for this and the many other reports!
[Bug c++/100652] New: Uexpanded parameter pack in partial specialization of variable template not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100652
Bug ID: 100652
Summary: Uexpanded parameter pack in partial specialization of
variable template not rejected
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
template struct A { };
template inline constexpr bool is_a = false;
template inline constexpr bool is_a> = true;
GCC silently accepts the above testcase and doesn't diagnose the unexpanded
parameter pack Ts inside the partial specialization of 'is_a'.
[Bug c++/87765] Internal compiler error: coerce_template_parms (8.2) or cxx_eval_constant_expression (trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87765 Marek Polacek changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #7 from Marek Polacek --- *** Bug 100649 has been marked as a duplicate of this bug. ***
[Bug c++/100649] [9/10/11/12 Regression] ICE in coerce_template_parms (releases) or cxx_eval_constant_expression (trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100649 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Marek Polacek --- Oh, it's a dup. *** This bug has been marked as a duplicate of bug 87765 ***
[Bug c++/100649] [9/10/11/12 Regression] ICE in coerce_template_parms (releases) or cxx_eval_constant_expression (trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100649 --- Comment #2 from Marek Polacek --- The ICE appeared with r251423.
[Bug c++/100649] [9/10/11/12 Regression] ICE in coerce_template_parms (releases) or cxx_eval_constant_expression (trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100649 Marek Polacek changed: What|Removed |Added Target Milestone|--- |9.4 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed||2021-05-18 Summary|ICE in |[9/10/11/12 Regression] ICE |coerce_template_parms |in coerce_template_parms |(releases) or |(releases) or |cxx_eval_constant_expressio |cxx_eval_constant_expressio |n (trunk) |n (trunk) Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Confirmed. Compiled without errors with GCC 7.
[Bug fortran/100642] [12 Regression] ICE in omp_code_to_statement, at fortran/openmp.c:6907 since r12-20-ga61c4964cd714462
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100642 --- Comment #2 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:cc193ac840d58ee0ffb57b14b542706cde3db0e7 commit r12-881-gcc193ac840d58ee0ffb57b14b542706cde3db0e7 Author: Tobias Burnus Date: Tue May 18 16:40:45 2021 +0200 Fortran/OpenMP: Add missing EXEC_OMP_DEPOBJ case val [PR100642] PR fortran/100642 gcc/fortran/ChangeLog: * openmp.c (omp_code_to_statement): Add missing EXEC_OMP_DEPOBJ. gcc/testsuite/ChangeLog: * gfortran.dg/goacc-gomp/depobj.f90: New test.
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 Jorn Wolfgang Rennecke changed: What|Removed |Added Attachment #50837|0 |1 is obsolete|| --- Comment #7 from Jorn Wolfgang Rennecke --- Created attachment 50839 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50839=edit Amended patch This patch also disables the affected tests.
[Bug libstdc++/100631] ranges::elements_view:: _Sentinel is missing __distance_from() that can access _M_current of _Iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100631 --- Comment #9 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:38751c4d5e15bd1c682ac4c868a2c4ce48ca5503 commit r12-880-g38751c4d5e15bd1c682ac4c868a2c4ce48ca5503 Author: Patrick Palka Date: Tue May 18 10:21:27 2021 -0400 libstdc++: Fix access issue in elements_view::_Sentinel [PR100631] In the earlier commit r12-854 I forgot to also rewrite the other operator- overload in terms of the split-out member function _M_distance_from. libstdc++-v3/ChangeLog: PR libstdc++/100631 * include/std/ranges (elements_view::_Sentinel::operator-): Use _M_distance_from in the other operator- overload too. * testsuite/std/ranges/adaptors/elements.cc (test06): Augment test.
[Bug fortran/100651] New: Weird memory corruption with multiple triggers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651 Bug ID: 100651 Summary: Weird memory corruption with multiple triggers Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: matthew.thompson at nasa dot gov Target Milestone: --- Created attachment 50838 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50838=edit Reproducing program This is a bug that is tripped by GCC 9.3.0, 10.1.0, and 11.1.0 (at least, but I only have access to those) on Linux and macOS. For the rest of this bug report, I'll be using macOS (as it's my main workstation). First: ❯ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/Users/mathomp4/installed/Core/gcc-gfortran/11.1.0/libexec/gcc/x86_64-apple-darwin19.6.0/11.1.0/lto-wrapper Target: x86_64-apple-darwin19.6.0 Configured with: ../gcc-11.1.0/configure --prefix=/Users/mathomp4/installed/Core/gcc-gfortran/11.1.0 --enable-languages=c,c++,fortran --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.1.0 (GCC) If you compile and run (NOTE: the -g -O0 is not necessary, I only use it to make the traceback a bit better): ❯ gfortran -g -O0 opt_string.F90 ❯ ./a.out opt_string.F90 122 T opt_string.F90 123 542594713 a.out(15473,0x1129d4e00) malloc: can't allocate region :*** mach_vm_map(size=140733735985152, flags: 100) failed (error code=3) a.out(15473,0x1129d4e00) malloc: *** set a breakpoint in malloc_error_break to debug Operating system error: Cannot allocate memory Memory allocation failure in xrealloc Error termination. Backtrace: #0 0x103249de2 in ??? #1 0x10324aab5 in ??? #2 0x10324acb3 in ??? #3 0x10324939a in ??? #4 0x10347a455 in ??? #5 0x10346bb99 in ??? #6 0x1034740a7 in ??? #7 0x1034792be in ??? #8 0x10347a237 in ??? #9 0x103231c2d in __test_intnode_MOD_test_casting_fail at /Users/mathomp4/F90Files/TomOptStringGCCBug/opt_string.F90:124 #10 0x103231c5c in MAIN__ at /Users/mathomp4/F90Files/TomOptStringGCCBug/opt_string.F90:135 #11 0x103231c98 in main at /Users/mathomp4/F90Files/TomOptStringGCCBug/opt_string.F90:132 The (runtime) error disappears if *any* of the following 3 lines are commented out/deleted: * Line 31 (generic assignment) * Line 85 (unused component of a derived type) * Line 121 (unused local variable) On Linux the output is: $ ./a.out opt_string.F90 122 T opt_string.F90 123 -1431350024 Operating system error: Cannot allocate memory Memory allocation failure in xrealloc Error termination. Backtrace: #0 0x2af20a07 in write_character at ../../../gcc-11.1.0/libgfortran/io/write.c:1416 #1 0x2af25ba6 in list_formatted_write_scalar at ../../../gcc-11.1.0/libgfortran/io/write.c:1900 #2 0x400cef in __test_intnode_MOD_test_casting_fail at /home/mathomp4/F90Files/TomOptStringGCCBug/opt_string.F90:124 #3 0x400d1e in MAIN__ at /home/mathomp4/F90Files/TomOptStringGCCBug/opt_string.F90:135 #4 0x400d55 in main at /home/mathomp4/F90Files/TomOptStringGCCBug/opt_string.F90:132
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #6 from Jonathan Wakely --- That patch isn't OK, because the declarations in would still be present, but using them would give linker errors. I think we should just check __SIZE_WIDTH__ < 32 (in that .cc file and in the header). If somebody wants to contribute an implementation that doesn't use the tables and trades off time for space then we can support them, but I don't think that's a good use of Patrick's time.
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #5 from Jorn Wolfgang Rennecke --- (In reply to Patrick Palka from comment #3) > Btw, we already disable the floating-point to_chars on targets without a > binary64 double. So is our test for detecting binary64 not accurate enough, > or are these 16-bit targets whose double type really is binary64? At least in the case of eSi-RISC, it is the latter.
[Bug libstdc++/100631] ranges::elements_view:: _Sentinel is missing __distance_from() that can access _M_current of _Iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100631
--- Comment #8 from Patrick Palka ---
(In reply to 康桓瑋 from comment #7)
> (In reply to CVS Commits from comment #6)
> > The master branch has been updated by Patrick Palka :
> >
> > https://gcc.gnu.org/g:2e2eef80ac0c21f9533e6791ccf5e29458cbb77c
> >
> > commit r12-854-g2e2eef80ac0c21f9533e6791ccf5e29458cbb77c
> > Author: Patrick Palka
> > Date: Tue May 18 00:26:07 2021 -0400
> >
> > libstdc++: Fix miscellaneous issues with elements_view::_Sentinel
> > [PR100631]
> >
> > libstdc++-v3/ChangeLog:
> >
> > PR libstdc++/100631
> > * include/std/ranges (elements_view::_Iterator): Also befriend
> > _Sentinel.
> > (elements_view::_Sentinel::_M_equal): Templatize.
> > (elements_view::_Sentinel::_M_distance_from): Split out from ...
> > (elements_view::_Sentinel::operator-): ... here. Depend on
> > _Base2 instead of _Base in the return type.
> > * testsuite/std/ranges/adaptors/elements.cc (test06, test07):
> > New tests.
>
>
>
> Hey, Patrick, you missed the second one:
>
>
> template typename _Base2 = __detail::__maybe_const_t<_Const2, _Vp>>
> requires sized_sentinel_for, iterator_t<_Base2>>
> friend constexpr range_difference_t<_Base2>
> operator-(const _Iterator<_Const2>& __x, const _Sentinel& __y)
> { return __x._M_current - __y._M_end; }
>
>
> this should be return -__y._M_distance_from(__x).
Indeed, thanks for catching that. Fix incoming shortly..
[Bug target/100626] [11/12 Regression] ICE Segmentation fault (during RTL pass: split1) since r11-165-geb72dc663e9070b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100626 --- Comment #6 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:d39fbed75810fc7478842503ecb0268b85dc9c2e commit r12-878-gd39fbed75810fc7478842503ecb0268b85dc9c2e Author: Uros Bizjak Date: Tue May 18 15:45:54 2021 +0200 i386: Fix split_double_mode with paradoxical subreg [PR100626] split_double_mode calls simplify_gen_subreg, which fails for the high half of the paradoxical subreg. Return temporary register instead of NULL RTX in this case. 2021-05-18 Uroš Bizjak gcc/ PR target/100626 * config/i386/i386-expand.c (split_double_mode): Return temporary register when simplify_gen_subreg fails with the high half od the paradoxical subreg.
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #4 from Jorn Wolfgang Rennecke --- Created attachment 50837 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50837=edit Proposed patch This patch fixes the problem for eSi-RISC and bootstraps on x86_64-pc-linux-gnu , with floating_to_chars.o properly built in each stage. Could you check that this also works for msp430?
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #3 from Patrick Palka --- (In reply to Jonathan Wakely from comment #2) > Patrick, is the table an optimization, or essential? We might be able to > avoid it, but he functions would be much slower. The tables are essential for Ryu's d2exp_buffered_n and d2fixed_buffered_n routines, which we use for fast explicit-precision formatting of float/double. > > Maybe we should just disable the floating-point to_chars for 16-bit targets. Agreed.. though in theory we could just go through printf as a fallback for d2exp_buffered_n and d2fixed_buffered_n on these targets. Btw, we already disable the floating-point to_chars on targets without a binary64 double. So is our test for detecting binary64 not accurate enough, or are these 16-bit targets whose double type really is binary64?
[Bug debug/78685] -Og generates too many ""s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||fredrik at dolda2000 dot com, ||john.carter at taitradio dot com, ||marxin at gcc dot gnu.org, ||philipp.lucas at siemens dot com, ||yuxian.chen at intel dot com --- Comment #19 from Eric Gallager --- This bug came up on the gcc-help mailing list here: https://gcc.gnu.org/pipermail/gcc-help/2021-May/140304.html ...and, while I'm here, let me update a few things... (In reply to rsand...@gcc.gnu.org from comment #18) > (In reply to Eric Gallager from comment #17) > > Richard Sandiford had a series of patches radically overhauling how -Og > > works in general that might affect this bug: > > https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01392.html > > cc-ing him so he can comment on if it does in fact affect this bug. > > Yeah, part 2 of the series fixes this PR: > https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01394.html Has this series been merged yet? Or at least pinged recently? (also, I'm redoing some CCs that seem to have been accidentally removed from the CC list without showing up in the bug history as having been removed; presumably this was from the server migration...)
[Bug analyzer/100546] -Wanayzer-null-dereference false positive through noreturn function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-18 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- The "noreturn"-ness of the function pointer is affected by attributes. Hence if you add the attribute to the function pointer type, the warning goes away: void (*noReturnPtr)(const char *str) __attribute__((noreturn)) = That said, given that we're in "main", the analyzer ought to figure out that noReturnPtr can't have been changed by the point of the call, and for some reason it's not doing that; am investigating.
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 Jonathan Wakely changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #2 from Jonathan Wakely --- Patrick, is the table an optimization, or essential? We might be able to avoid it, but he functions would be much slower. Maybe we should just disable the floating-point to_chars for 16-bit targets.
[Bug fortran/100650] New: Passing a derived-type array constructor to the reshape intrinsic gives incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100650 Bug ID: 100650 Summary: Passing a derived-type array constructor to the reshape intrinsic gives incorrect results Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: here.is.a.gcc.bug at gmail dot com Target Milestone: --- Created attachment 50836 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50836=edit A minimum broken example. Needs no special compiler flags. A type `String` has a `character(:), allocatable` component. When an array constructor of type `String` is passed to the reshape intrinsic, the components of the resulting array are incorrect. The bug does not trigger if the array constructor is used to create a named array and this named array is passed to the reshape intrinsic. This affects at least versions 7.4.0, 10.1.0 and 11.1.1 of gfortran.
[Bug jit/95325] Support 128-bit integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95325 --- Comment #1 from Antoni --- Created attachment 50835 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50835=edit Patch add support for sized integer types That patch not only add support for 128-bit integers, but also all other sized integers.
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 Jorn Wolfgang Rennecke changed: What|Removed |Added CC||amylaar at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-05-18 --- Comment #1 from Jorn Wolfgang Rennecke --- I also see this for 16 bit eSi-RISC targets. This array can't fit into a 16 bit address space that addresses 8 bit units.
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #15 from rguenther at suse dot de ---
On Tue, 18 May 2021, amker at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
>
> --- Comment #14 from bin cheng ---
> (In reply to Richard Biener from comment #12)
> > So in number_of_iterations_ne it looks like the step 's' is always constant
> > which makes me wonder if we can somehow use ranger to tell multiple_of_p
> > (type, c, s)
> > or at least whether, if c is x * s, the multiplication could have
> > overflowed?
>
> Yeah, I am looking if "multiple of" can be feasibly checked in niter analysis,
> with help of some basic information from multiple_of_p.
>
> BTW, I am not following changes in "ranger", how should I used in analysis? or
> similar to value range info?
I'm not sure - let's see if the ranger folks have any good idea here.
Btw, there's tree_ctz which looks more conservative and could be used
for power-of-two 's'. split_constant_offset also recently got
refactoring to avoid a plethora of overflow issues it ran into,
so we can eventually improve multiple_of_p to be correct without
pre-conditions. But I fear that for DECL_SIZE & friends where
we "know" that multiplications by 8 to get from byte to bit size
do not overflow we cannot be too conservative here. Maybe in the
end we need to distinguish those with new MULT_NO_OVERFLOW,
PLUS_NO_OVERFLOW, etc. When creating those expressions we should
already be using size_{bin,un}op. The conversion handling of course
still looks bogus to me even in this context.
[Bug c++/100649] New: ICE in coerce_template_parms (releases) or cxx_eval_constant_expression (trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100649
Bug ID: 100649
Summary: ICE in coerce_template_parms (releases) or
cxx_eval_constant_expression (trunk)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ebotcazou at gcc dot gnu.org
Target Milestone: ---
The compiler ICEs either in coerce_template_parms for releases:
t.cpp: In member function 'void B::foo(const A<32>&)':
t.cpp:12:24: internal compiler error: in coerce_template_parms, at cp/pt.c:9082
12 | A<2 + mesg.size()> local_mesg;
|^
0x6267e6 coerce_template_parms
/home/eric/cvs/gcc-11/gcc/cp/pt.c:9082
or in cxx_eval_constant_expression on the trunk:
t.cpp: In member function 'void B::foo(const A<32>&)':
t.cpp:12:24: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.c:6622
12 | A<2 + mesg.size()> local_mesg;
|^
0x651967 cxx_eval_constant_expression
/home/eric/cvs/gcc/gcc/cp/constexpr.c:6622
for the following testcase:
template
struct A
{
constexpr int size () const { return N; }
};
template
struct B
{
void foo (const A<32> )
{
A<2 + mesg.size()> local_mesg;
}
};
The code is correctly rejected when the 2nd template declaration is removed:
t.cpp: In member function 'void B::foo(const A<32>&)':
t.cpp:12:24: error: 'mesg' is not a constant expression
12 | A<2 + mesg.size()> local_mesg;
|^
t.cpp:12:11: note: in template argument for type 'int'
12 | A<2 + mesg.size()> local_mesg;
| ~~^
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #14 from bin cheng --- (In reply to Richard Biener from comment #12) > So in number_of_iterations_ne it looks like the step 's' is always constant > which makes me wonder if we can somehow use ranger to tell multiple_of_p > (type, c, s) > or at least whether, if c is x * s, the multiplication could have overflowed? Yeah, I am looking if "multiple of" can be feasibly checked in niter analysis, with help of some basic information from multiple_of_p. BTW, I am not following changes in "ranger", how should I used in analysis? or similar to value range info? Thanks
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #13 from bin cheng --- (In reply to Richard Biener from comment #10) > (In reply to bin cheng from comment #9) > > Seems we have a long standing bug in fold-const.c:multiple_of_p in case of > > wrapping types. Take unsigned int as an example: > > (0xfffc * 0x3) % 0x3 = 0x1 > > But multiple_of_p returns true here. > > > > The same issue also stands for MINUS_EXPR and PLUS_EXPR. Given > > multiple_of_p is used elsewhere, the fix might break existing optimizations. > > Especially, number of loop iterations is computed in unsigned types > > multiple_of_p is mostly used in contexts where overflow "cannot happen" > (in TYPE/DECL_SIZE computation context), and in niter analysis it seems to > be guarded similarly. This restriction of multiple_of_p seems undocumented, Oh, I am not aware of this. Actually my previous change to it seems broke this assumption already. Will see how to fix or revert the change. > so fixing that might be good. > > Now, you don't say what's the chain of events that lead to a multiple_of_p > call > eventually leading to the wrong answer, but I guess it's the code added > under the > > + if (!niter->control.no_overflow > + && (integer_onep (s) || multiple_of_p (type, c, s))) > > check as !niter->control.no_overflow seems to suggest that the multiple_of_p > check is not properly guarded?
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 Richard Biener changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #12 from Richard Biener --- So in number_of_iterations_ne it looks like the step 's' is always constant which makes me wonder if we can somehow use ranger to tell multiple_of_p (type, c, s) or at least whether, if c is x * s, the multiplication could have overflowed?
[Bug other/100598] [12 Regression] MinGW Canadian cross toolchain fails to build due to missing BASEVER in genversion.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100598 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Liška --- Should be fixed now.
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||law at gcc dot gnu.org
--- Comment #11 from Richard Biener ---
But there's still
int
multiple_of_p (tree type, const_tree top, const_tree bottom)
{
...
case NOP_EXPR:
/* Can't handle conversions from non-integral or wider integral type. */
if ((TREE_CODE (TREE_TYPE (TREE_OPERAND (top, 0))) != INTEGER_TYPE)
|| (TYPE_PRECISION (type)
< TYPE_PRECISION (TREE_TYPE (TREE_OPERAND (top, 0)
return 0;
/* fall through */
case SAVE_EXPR:
return multiple_of_p (type, TREE_OPERAND (top, 0), bottom);
which makes guards like
|| (TYPE_OVERFLOW_UNDEFINED (type)
&& multiple_of_p (type, c, s)))
break for say multiple_of_p (int, (int)(unsigned)(x*s), s). So it's a bit
fishy in the end ... :/
Jeff originally introduced multiple_of_p, maybe he remembers something.
[Bug other/100598] [12 Regression] MinGW Canadian cross toolchain fails to build due to missing BASEVER in genversion.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100598
--- Comment #4 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:5116b54e4644cb0d7b99891c76f8f015097f6530
commit r12-872-g5116b54e4644cb0d7b99891c76f8f015097f6530
Author: Tobias Burnus
Date: Tue May 18 11:56:05 2021 +0200
gcc/configure.ac: Fix cross build by using $(CFLAGS-$@) [PR100598]
BUILD_CFLAGS is set by configure; by default, BUILD_CFLAGS = $(ALL_CFLAGS)
is used. The latter contains (see gcc/Makefile.in) $(CFLAGS-$@), which is
used
to pass .o-file specific flags to the compiler.
For cross builds, BUILD_CFLAGS is constructed in configure{,.ac} and missed
the $(CFLAGS-$@) - despite the comment above ALL_CFLAGS that configure.ac
might have to kept in sync.
gcc/ChangeLog:
PR other/100598
* configure: Regenerate.
* configure.ac (BUILD_CFLAG, BUILD_CXXFLAGS): Add $(CFLAGS-$@).
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #10 from Richard Biener --- (In reply to bin cheng from comment #9) > Seems we have a long standing bug in fold-const.c:multiple_of_p in case of > wrapping types. Take unsigned int as an example: > (0xfffc * 0x3) % 0x3 = 0x1 > But multiple_of_p returns true here. > > The same issue also stands for MINUS_EXPR and PLUS_EXPR. Given > multiple_of_p is used elsewhere, the fix might break existing optimizations. > Especially, number of loop iterations is computed in unsigned types multiple_of_p is mostly used in contexts where overflow "cannot happen" (in TYPE/DECL_SIZE computation context), and in niter analysis it seems to be guarded similarly. This restriction of multiple_of_p seems undocumented, so fixing that might be good. Now, you don't say what's the chain of events that lead to a multiple_of_p call eventually leading to the wrong answer, but I guess it's the code added under the + if (!niter->control.no_overflow + && (integer_onep (s) || multiple_of_p (type, c, s))) check as !niter->control.no_overflow seems to suggest that the multiple_of_p check is not properly guarded?
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573 --- Comment #5 from Jakub Jelinek --- The intent of this particular test is to test how orphaned distribute works and was done before the host teams construct support has been added, which means we do not want the target teams visible in the individual functions.
[Bug middle-end/100593] [ELF] -fno-pic: Use GOT to take address of an external default visibility function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #7 from Alexander Monakov ---
Thanks. I agree that inferring address significance on the linker side is
problematic.
Thinking about your original request, I was about to say that it would be very
reasonable to do under -fno-plt flag, but then I found it was already
implemented for x86-64 in gcc-7 and for 32-bit x86 in gcc-8. Compiling
int f();
void *g()
{
return f;
}
with -fno-pic -fno-plt yields
g:
movqf@GOTPCREL(%rip), %rax
ret
(yields GOTPCRELX relocation) and
g:
movlf@GOT, %eax
ret
on 32-bit (yields GOT32X relocation), so on x86 it's already implemented?
[Bug target/100369] crash after error in gcc.target/aarch64/simd/vgetq_lane_s64_indices_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100369 Alex Coplan changed: What|Removed |Added Known to fail||10.3.0, 11.1.0, 9.3.0 --- Comment #4 from Alex Coplan --- I can reproduce it back to GCC 8 (not a regression).
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #4 from Jakub Jelinek ---
(In reply to Tom de Vries from comment #3)
> Hmm, I reproduced the problem on the original test-case:
> libgomp.c-c++-common/for-3.c, and minimized from there:
> ...
> $ cat libgomp/testsuite/libgomp.c-c++-common/for-3.c
> /* { dg-additional-options "-std=gnu99" { target c } } */
>
> #include
> extern void abort ();
>
> #define N 1500
>
> int a[N];
>
> int
> main (void)
> {
> int err = 0;
>
> #pragma omp target map(tofrom: err) map (tofrom: a)
> #pragma omp teams num_teams (15) reduction(|:err)
> {
> int i;
>
> for (i = 0; i < N; i++)
> a[i] = 0;
Even this loop is a problem because every initial thread in its team
clears the whole array.
>
> do {} while (0);
>
> #pragma omp distribute
> for (i = 0; i < N; i++)
> a[i] += 2;
>
> do {} while (0);
And this of course too.
>
> for (i = 0; i < N; i++)
> if (a[i] != 2)
> err |= 1;
> }
I think we want to fix both for-3.c and for-9.c similarly to
r11-2571-g916c7a201a9a1dc94f2c056a773826a26d1daca9
i.e.
#define DO_PRAGMA(x) _Pragma (#x)
#define OMPTEAMS DO_PRAGMA (omp target teams)
#define OMPFROM(v) DO_PRAGMA (omp target update from(v))
#define OMPTO(v) DO_PRAGMA (omp target update to(v))
and changing main not to do #pragma omp target teams reduction(|:err)
[Bug target/100369] crash after error in gcc.target/aarch64/simd/vgetq_lane_s64_indices_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100369
Alex Coplan changed:
What|Removed |Added
Known to fail||12.0
CC||acoplan at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords||error-recovery
Last reconfirmed||2021-05-18
--- Comment #3 from Alex Coplan ---
Confirmed. Here is a reduced testcase:
$ cat neon.c
#include
int64x2_t v;
void f() { vgetq_lane_s64(v, 2); }
$ ./arm-eabi-gcc -c neon.c -march=armv8-a+simd
In file included from neon.c:1:
In function 'vgetq_lane_s64',
inlined from 'f' at neon.c:3:12:
/home/alecop01/toolchain/build-arm-eabi-armv8.1-m.main+mve.fp+fp.dp/install/lib/gcc/arm-eabi/12.0.0/include/arm_neon.h:6313:10:
error: lane 2 out of range 0 - 1
6313 | return (int64_t)__builtin_neon_vget_lanev2di (__a, __b);
| ^~~~
during RTL pass: expand
/home/alecop01/toolchain/build-arm-eabi-armv8.1-m.main+mve.fp+fp.dp/install/lib/gcc/arm-eabi/12.0.0/include/arm_neon.h:
In function 'f':
/home/alecop01/toolchain/build-arm-eabi-armv8.1-m.main+mve.fp+fp.dp/install/lib/gcc/arm-eabi/12.0.0/include/arm_neon.h:6313:10:
internal compiler error: in gen_neon_vget_lanev2di, at config/arm/neon.md:3288
0x15f54df gen_neon_vget_lanev2di(rtx_def*, rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/config/arm/neon.md:3288
0x120c3e0 rtx_insn* insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*) const
/home/alecop01/toolchain/src/gcc/gcc/recog.h:407
0x120c3e0 arm_expand_builtin_args
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm-builtins.c:3160
0x120c3e0 arm_expand_builtin_1
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm-builtins.c:3309
0x120d082 arm_expand_neon_builtin
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm-builtins.c:3389
0x120d082 arm_expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm-builtins.c:3469
0x7ca04f expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/alecop01/toolchain/src/gcc/gcc/builtins.c:9753
0x94984d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:11405
0x94ad22 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:8621
0x9538c7 store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:5986
0x95554a expand_assignment(tree_node*, tree_node*, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:5721
0x80123b expand_call_stmt
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:2841
0x80123b expand_gimple_stmt_1
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:3847
0x80123b expand_gimple_stmt
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:4011
0x80a339 expand_gimple_basic_block
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:6053
0x80b546 execute
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:6737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/100648] New: Optimize away x<0 as mask argument of a blend for AVX512 mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100648 Bug ID: 100648 Summary: Optimize away x<0 as mask argument of a blend for AVX512 mask Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: crazylht at gmail dot com CC: hjl.tools at gmail dot com Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-*-* i?86-*-* Similar to PR target/54700, but for AVX512 mask
