[PATCH] i386, v2: Fix some -mavx512vl -mno-avx512bw bugs [PR99321]
On Sat, Mar 06, 2021 at 01:39:23PM +0100, Uros Bizjak via Gcc-patches wrote:
> > One possibility would be to change the meaning of Yw, because it
> > is an internal undocumented constraint and all uses in GCC currently use it
> > as xYw:
> > constraints.md:(define_register_constraint "Yw"
> > mmx.md: [(set (match_operand:V4HI 0 "register_operand" "=y,xYw")
> > mmx.md: (match_operand:V4HI 1 "register_mmxmem_operand" "ym,xYw")
> > mmx.md: [(set (match_operand:V4HI 0 "register_operand" "=y,xYw")
> > mmx.md: (match_operand:SI 1 "register_operand" "0,xYw"]
> > Would that be ok?
>
> Yes, this is an excellent idea.
Ok, here is the full patch, now including a testcase.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-03-07 Jakub Jelinek
PR target/99321
* config/i386/constraints.md (Yw): Use SSE_REGS if TARGET_SSE
but TARGET_AVX512BW or TARGET_AVX512VL is not set. Adjust description
and comment.
* config/i386/sse.md (v_Yw): New define_mode_attr.
(*3, *mul3, *avx2_3,
*sse4_1_3): Use instead of v
in constraints.
* config/i386/mmx.md (mmx_pshufw_1, *vec_dupv4hi): Use Yw instead of
xYw in constraints.
* lib/target-supports.exp
(check_effective_target_assembler_march_noavx512bw): New effective
target.
* gcc.target/i386/avx512vl-pr99321-1.c: New test.
--- gcc/config/i386/constraints.md.jj 2021-01-04 10:25:45.116162680 +0100
+++ gcc/config/i386/constraints.md 2021-03-06 13:47:38.950644696 +0100
@@ -110,7 +110,7 @@ (define_register_constraint "v" "TARGET_
;; v any EVEX encodable SSE register for AVX512VL target,
;; otherwise any SSE register
;; w any EVEX encodable SSE register for AVX512BW with TARGET_AVX512VL
-;; target.
+;; target, otherwise any SSE register.
(define_register_constraint "Yz" "TARGET_SSE ? SSE_FIRST_REG : NO_REGS"
"First SSE register (@code{%xmm0}).")
@@ -148,8 +148,8 @@ (define_register_constraint "Yv"
"@internal For AVX512VL, any EVEX encodable SSE register
(@code{%xmm0-%xmm31}), otherwise any SSE register.")
(define_register_constraint "Yw"
- "TARGET_AVX512BW && TARGET_AVX512VL ? ALL_SSE_REGS : NO_REGS"
- "@internal Any EVEX encodable SSE register (@code{%xmm0-%xmm31}) for AVX512BW
with TARGET_AVX512VL target.")
+ "TARGET_AVX512BW && TARGET_AVX512VL ? ALL_SSE_REGS : TARGET_SSE ? SSE_REGS :
NO_REGS"
+ "@internal Any EVEX encodable SSE register (@code{%xmm0-%xmm31}) for AVX512BW
with TARGET_AVX512VL target, otherwise any SSE register.")
;; We use the B prefix to denote any number of internal operands:
;; f FLAGS_REG
--- gcc/config/i386/sse.md.jj 2021-03-05 21:51:33.728349881 +0100
+++ gcc/config/i386/sse.md 2021-03-06 13:48:13.283261323 +0100
@@ -560,6 +560,14 @@ (define_mode_attr avx512
(V4SF "avx512vl") (V8SF "avx512vl") (V16SF "avx512f")
(V2DF "avx512vl") (V4DF "avx512vl") (V8DF "avx512f")])
+(define_mode_attr v_Yw
+ [(V16QI "Yw") (V32QI "Yw") (V64QI "v")
+ (V8HI "Yw") (V16HI "Yw") (V32HI "v")
+ (V4SI "v") (V8SI "v") (V16SI "v")
+ (V2DI "v") (V4DI "v") (V8DI "v")
+ (V4SF "v") (V8SF "v") (V16SF "v")
+ (V2DF "v") (V4DF "v") (V8DF "v")])
+
(define_mode_attr sse2_avx_avx512f
[(V16QI "sse2") (V32QI "avx") (V64QI "avx512f")
(V8HI "avx512vl") (V16HI "avx512vl") (V32HI "avx512bw")
@@ -11677,10 +11685,10 @@ (define_expand "3_mask"
"ix86_fixup_binary_operands_no_copy (, mode, operands);")
(define_insn "*3"
- [(set (match_operand:VI_AVX2 0 "register_operand" "=x,v")
+ [(set (match_operand:VI_AVX2 0 "register_operand" "=x,")
(plusminus:VI_AVX2
- (match_operand:VI_AVX2 1 "bcst_vector_operand" "0,v")
- (match_operand:VI_AVX2 2 "bcst_vector_operand" "xBm,vmBr")))]
+ (match_operand:VI_AVX2 1 "bcst_vector_operand" "0,")
+ (match_operand:VI_AVX2 2 "bcst_vector_operand" "xBm,mBr")))]
"TARGET_SSE2 && ix86_binary_operator_ok (, mode, operands)"
"@
p\t{%2, %0|%0, %2}
@@ -11790,9 +11798,9 @@ (define_expand "mul3"
"ix86_fixup_binary_operands_no_copy (MULT, mode, operands);")
(define_insn "*mul3"
- [(set (match_operand:VI2_AVX2 0 "register_operand" "=x,v")
- (mult:VI2_AVX2 (match_operand:VI2_AVX2 1 "vector_operand" "%0,v")
- (match_operand:VI2_AVX2 2 "vector_operand" "xBm,vm")))]
+ [(set (match_operand:VI2_AVX2 0 "register_operand" "=x,")
+ (mult:VI2_AVX2 (match_operand:VI2_AVX2 1 "vector_operand" "%0,")
+ (match_operand:VI2_AVX2 2 "vector_operand"
"xBm,m")))]
"TARGET_SSE2 && !(MEM_P (operands[1]) && MEM_P (operands[2]))
&& && "
"@
@@ -12618,10 +12626,10 @@ (define_expand "3"
"ix86_fixup_binary_operands_no_copy (, mode, operands);")
(define_insn "*avx2_3"
- [(set (match_operand:VI124_256 0 "register_operand" "=v")
+ [(set (match_operand:VI124_256 0 "register_operand" "=")
(maxmin:VI124_256
- (match_operand:VI124_256 1 "nonimm
Re: [PATCH] i386, v2: Fix some -mavx512vl -mno-avx512bw bugs [PR99321]
On Sun, Mar 7, 2021 at 9:41 AM Jakub Jelinek wrote:
>
> On Sat, Mar 06, 2021 at 01:39:23PM +0100, Uros Bizjak via Gcc-patches wrote:
> > > One possibility would be to change the meaning of Yw, because it
> > > is an internal undocumented constraint and all uses in GCC currently use
> > > it
> > > as xYw:
> > > constraints.md:(define_register_constraint "Yw"
> > > mmx.md: [(set (match_operand:V4HI 0 "register_operand" "=y,xYw")
> > > mmx.md: (match_operand:V4HI 1 "register_mmxmem_operand" "ym,xYw")
> > > mmx.md: [(set (match_operand:V4HI 0 "register_operand" "=y,xYw")
> > > mmx.md: (match_operand:SI 1 "register_operand" "0,xYw"]
> > > Would that be ok?
> >
> > Yes, this is an excellent idea.
>
> Ok, here is the full patch, now including a testcase.
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2021-03-07 Jakub Jelinek
>
> PR target/99321
> * config/i386/constraints.md (Yw): Use SSE_REGS if TARGET_SSE
> but TARGET_AVX512BW or TARGET_AVX512VL is not set. Adjust description
> and comment.
> * config/i386/sse.md (v_Yw): New define_mode_attr.
> (*3, *mul3, *avx2_3,
> *sse4_1_3): Use instead of v
> in constraints.
> * config/i386/mmx.md (mmx_pshufw_1, *vec_dupv4hi): Use Yw instead of
> xYw in constraints.
>
> * lib/target-supports.exp
> (check_effective_target_assembler_march_noavx512bw): New effective
> target.
> * gcc.target/i386/avx512vl-pr99321-1.c: New test.
OK.
Thanks,
Uros.
>
> --- gcc/config/i386/constraints.md.jj 2021-01-04 10:25:45.116162680 +0100
> +++ gcc/config/i386/constraints.md 2021-03-06 13:47:38.950644696 +0100
> @@ -110,7 +110,7 @@ (define_register_constraint "v" "TARGET_
> ;; v any EVEX encodable SSE register for AVX512VL target,
> ;; otherwise any SSE register
> ;; w any EVEX encodable SSE register for AVX512BW with TARGET_AVX512VL
> -;; target.
> +;; target, otherwise any SSE register.
>
> (define_register_constraint "Yz" "TARGET_SSE ? SSE_FIRST_REG : NO_REGS"
> "First SSE register (@code{%xmm0}).")
> @@ -148,8 +148,8 @@ (define_register_constraint "Yv"
> "@internal For AVX512VL, any EVEX encodable SSE register
> (@code{%xmm0-%xmm31}), otherwise any SSE register.")
>
> (define_register_constraint "Yw"
> - "TARGET_AVX512BW && TARGET_AVX512VL ? ALL_SSE_REGS : NO_REGS"
> - "@internal Any EVEX encodable SSE register (@code{%xmm0-%xmm31}) for
> AVX512BW with TARGET_AVX512VL target.")
> + "TARGET_AVX512BW && TARGET_AVX512VL ? ALL_SSE_REGS : TARGET_SSE ? SSE_REGS
> : NO_REGS"
> + "@internal Any EVEX encodable SSE register (@code{%xmm0-%xmm31}) for
> AVX512BW with TARGET_AVX512VL target, otherwise any SSE register.")
>
> ;; We use the B prefix to denote any number of internal operands:
> ;; f FLAGS_REG
> --- gcc/config/i386/sse.md.jj 2021-03-05 21:51:33.728349881 +0100
> +++ gcc/config/i386/sse.md 2021-03-06 13:48:13.283261323 +0100
> @@ -560,6 +560,14 @@ (define_mode_attr avx512
> (V4SF "avx512vl") (V8SF "avx512vl") (V16SF "avx512f")
> (V2DF "avx512vl") (V4DF "avx512vl") (V8DF "avx512f")])
>
> +(define_mode_attr v_Yw
> + [(V16QI "Yw") (V32QI "Yw") (V64QI "v")
> + (V8HI "Yw") (V16HI "Yw") (V32HI "v")
> + (V4SI "v") (V8SI "v") (V16SI "v")
> + (V2DI "v") (V4DI "v") (V8DI "v")
> + (V4SF "v") (V8SF "v") (V16SF "v")
> + (V2DF "v") (V4DF "v") (V8DF "v")])
> +
> (define_mode_attr sse2_avx_avx512f
>[(V16QI "sse2") (V32QI "avx") (V64QI "avx512f")
> (V8HI "avx512vl") (V16HI "avx512vl") (V32HI "avx512bw")
> @@ -11677,10 +11685,10 @@ (define_expand "3_mask"
>"ix86_fixup_binary_operands_no_copy (, mode, operands);")
>
> (define_insn "*3"
> - [(set (match_operand:VI_AVX2 0 "register_operand" "=x,v")
> + [(set (match_operand:VI_AVX2 0 "register_operand" "=x,")
> (plusminus:VI_AVX2
> - (match_operand:VI_AVX2 1 "bcst_vector_operand" "0,v")
> - (match_operand:VI_AVX2 2 "bcst_vector_operand" "xBm,vmBr")))]
> + (match_operand:VI_AVX2 1 "bcst_vector_operand" "0,")
> + (match_operand:VI_AVX2 2 "bcst_vector_operand" "xBm,mBr")))]
>"TARGET_SSE2 && ix86_binary_operator_ok (, mode, operands)"
>"@
> p\t{%2, %0|%0, %2}
> @@ -11790,9 +11798,9 @@ (define_expand "mul3"
>"ix86_fixup_binary_operands_no_copy (MULT, mode, operands);")
>
> (define_insn "*mul3"
> - [(set (match_operand:VI2_AVX2 0 "register_operand" "=x,v")
> - (mult:VI2_AVX2 (match_operand:VI2_AVX2 1 "vector_operand" "%0,v")
> - (match_operand:VI2_AVX2 2 "vector_operand" "xBm,vm")))]
> + [(set (match_operand:VI2_AVX2 0 "register_operand" "=x,")
> + (mult:VI2_AVX2 (match_operand:VI2_AVX2 1 "vector_operand" "%0,")
> + (match_operand:VI2_AVX2 2 "vector_operand"
> "xBm,m")))]
>"TARGET_SSE2 && !(MEM_P (operands[1]) && MEM_P (operands[2]))
> && && "
>"@
> @@ -12618,10 +12626,10 @@ (define_expand "3"
>
New Esperanto PO file for 'cpplib' (version 11.1-b20210207)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Esperanto team of translators. The file is available at: https://translationproject.org/latest/cpplib/eo.po (This file, 'cpplib-11.1-b20210207.eo.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Contents of PO file 'cpplib-11.1-b20210207.eo.po'
cpplib-11.1-b20210207.eo.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH v2] fix Ada bootstrap on Cygwin64 (PR bootstrap/94918)
On Sun, Jan 10, 2021 at 2:04 PM Mikael Pettersson wrote: > > On Sun, Jan 10, 2021 at 11:57 AM Arnaud Charlet wrote: > > > > > This fixes a compilation error preventing bootstrap with Ada on > > > x86_64-pc-cygwin. See PR bootstrap/94918 for details. > > > > > > Compared to the initial patch sent in May 2020, this v2 patch places > > > the fix in Ada's raise-gcc.c instead of the shared unwind-generic.h, > > > which should hopefully simplify getting it applied. > > > > Not sure why. Applying it there looks incomplete and kludgy, don't you > > agree? > > Ok, then here's v3 which places the fix in unwind-generic.h. The fix > matches what Ada's mingw32.h does. > > Tested by bootstrapping this and the preliminary workaround for > PR98590 on x86_64-pc-cygwin. > > Ok for master and branches? Ping. This is currently the only blocker for bootstrapping gcc-11 with Ada on Cygwin64. > > libgcc/ > > 2021-01-10 Mikael Pettersson > > PR bootstrap/94918 > * unwind-generic.h (__SEH__): Prevent windows.h from including > x86intrin.h or emmintrin.h on Cygwin64. > > --- gcc-11-20210103/libgcc/unwind-generic.h.~1~ 2021-01-03 > 23:32:20.0 +0100 > +++ gcc-11-20210103/libgcc/unwind-generic.h 2021-01-09 > 14:51:16.262378715 +0100 > @@ -30,6 +30,12 @@ > > #if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__) > /* Only for _GCC_specific_handler. */ > +#if defined (__CYGWIN__) && !defined (__CYGWIN32__) && !defined (IN_RTS) > +/* Note: windows.h on cygwin-64 includes x86intrin.h which uses malloc. > + That fails to compile, if malloc is poisoned, i.e. if !IN_RTS. */ > +#define _X86INTRIN_H_INCLUDED > +#define _EMMINTRIN_H_INCLUDED > +#endif > #include > #endif
Re: [PATCH v2] fix Ada bootstrap on Cygwin64 (PR bootstrap/94918)
> > > > This fixes a compilation error preventing bootstrap with Ada on > > > > x86_64-pc-cygwin. See PR bootstrap/94918 for details. > > > > > > > > Compared to the initial patch sent in May 2020, this v2 patch places > > > > the fix in Ada's raise-gcc.c instead of the shared unwind-generic.h, > > > > which should hopefully simplify getting it applied. > > > > > > Not sure why. Applying it there looks incomplete and kludgy, don't you > > > agree? > > > > Ok, then here's v3 which places the fix in unwind-generic.h. The fix > > matches what Ada's mingw32.h does. > > > > Tested by bootstrapping this and the preliminary workaround for > > PR98590 on x86_64-pc-cygwin. > > > > Ok for master and branches? > > Ping. This is currently the only blocker for bootstrapping gcc-11 with > Ada on Cygwin64. Unfortunately changes in libgcc are outside my area, you'll need to find another maintainer for this one. > > libgcc/ > > > > 2021-01-10 Mikael Pettersson > > > > PR bootstrap/94918 > > * unwind-generic.h (__SEH__): Prevent windows.h from including > > x86intrin.h or emmintrin.h on Cygwin64. > > > > --- gcc-11-20210103/libgcc/unwind-generic.h.~1~ 2021-01-03 > > 23:32:20.0 +0100 > > +++ gcc-11-20210103/libgcc/unwind-generic.h 2021-01-09 > > 14:51:16.262378715 +0100 > > @@ -30,6 +30,12 @@ > > > > #if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__) > > /* Only for _GCC_specific_handler. */ > > +#if defined (__CYGWIN__) && !defined (__CYGWIN32__) && !defined (IN_RTS) > > +/* Note: windows.h on cygwin-64 includes x86intrin.h which uses malloc. > > + That fails to compile, if malloc is poisoned, i.e. if !IN_RTS. */ > > +#define _X86INTRIN_H_INCLUDED > > +#define _EMMINTRIN_H_INCLUDED > > +#endif > > #include > > #endif >
New Swedish PO file for 'gcc' (version 11.1-b20210207)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/gcc/sv.po (This file, 'gcc-11.1-b20210207.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [Bug libstdc++/99402] [10/11 Regression] std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator
Here is the patch to correctly deal with the new __dp_sign_max_size.
I prefer to introduce new __can_advance overloads for this to correctly
deal with the _Distance_precision in it. _M_valid_range was also
ignoring __dp_sign_max_size.
libstdc++: [_GLIBCXX_DEBUG] Fix management of __dp_sign_max_size
[PR 99402]
libstdc++-v3/ChangeLog:
PR libstdc++/99402
* include/debug/helper_functions.h
(__can_advance(_InputIterator,
const std::pair<_Diff, _Distance_precision>&, int)): New.
(__can_advance(const _Safe_iterator<>&,
const std::pair<_Diff, _Distance_precision>&, int)): New.
* include/debug/macros.h
(__glibcxx_check_can_increment_dist): New,
use latter.
(__glibcxx_check_can_increment_range): Adapt to use latter.
(__glibcxx_check_can_decrement_range): Likewise.
* include/debug/safe_iterator.h
(_Safe_iterator<>::_M_can_advance(const std::pair<_Diff,
_Distance_precision>&,
int)): New.
(__can_advance(const _Safe_iterator<>&,
const std::pair<_Diff, _Distance_precision>&, int)): New.
* include/debug/safe_iterator.tcc
(_Safe_iterator<>::_M_can_advance(const std::pair<_Diff,
_Distance_precision>&,
int)): New.
(_Safe_iterator<>::_M_valid_range(const _Safe_iterator<>&,
std::pair&, bool)):
Adapt for
__dp_sign_max_size.
(__copy_move_a): Adapt to use
__glibcxx_check_can_increment_dist.
(__copy_move_backward_a): Likewise.
(__equal_aux): Likewise.
* include/debug/stl_iterator.h (__can_advance(const
std::reverse_iterator<>&,
const std::pair<_Diff, _Distance_precision>&, int)): New.
(__can_advance(const std::move_iterator<>&,
const std::pair<_Diff, _Distance_precision>&, int)): New.
* testsuite/25_algorithms/copy/debug/99402.cc: New test.
Tested under Linux x86_64.
Ok to commit ?
François
diff --git a/libstdc++-v3/include/debug/helper_functions.h b/libstdc++-v3/include/debug/helper_functions.h
index 513e5460eba..c0144ced979 100644
--- a/libstdc++-v3/include/debug/helper_functions.h
+++ b/libstdc++-v3/include/debug/helper_functions.h
@@ -291,6 +291,18 @@ namespace __gnu_debug
__can_advance(const _Safe_iterator<_Iterator, _Sequence, _Category>&,
_Size);
+ template
+_GLIBCXX_CONSTEXPR
+inline bool
+__can_advance(_InputIterator, const std::pair<_Diff, _Distance_precision>&, int)
+{ return true; }
+
+ template
+bool
+__can_advance(const _Safe_iterator<_Iterator, _Sequence, _Category>&,
+ const std::pair<_Diff, _Distance_precision>&, int);
+
/** Helper function to extract base iterator of random access safe iterator
* in order to reduce performance impact of debug mode. Limited to random
* access iterator because it is the only category for which it is possible
diff --git a/libstdc++-v3/include/debug/macros.h b/libstdc++-v3/include/debug/macros.h
index 0988437046f..9ac52ebd09d 100644
--- a/libstdc++-v3/include/debug/macros.h
+++ b/libstdc++-v3/include/debug/macros.h
@@ -94,6 +94,12 @@ _GLIBCXX_DEBUG_VERIFY(__gnu_debug::__can_advance(_First, _Size), \
._M_iterator(_First, #_First) \
._M_integer(_Size, #_Size))
+#define __glibcxx_check_can_increment_dist(_First,_Dist,_Way) \
+ _GLIBCXX_DEBUG_VERIFY(__gnu_debug::__can_advance(_First, _Dist, _Way), \
+ _M_message(__gnu_debug::__msg_iter_subscript_oob) \
+ ._M_iterator(_First, #_First) \
+ ._M_integer(_Way * _Dist.first, #_Dist))
+
#define __glibcxx_check_can_increment_range(_First1,_Last1,_First2) \
do \
{ \
@@ -105,7 +111,7 @@ _GLIBCXX_DEBUG_VERIFY(__gnu_debug::__can_advance(_First, _Size), \
._M_iterator(_Last1, #_Last1), \
__FILE__,__LINE__,__PRETTY_FUNCTION__); \
_GLIBCXX_DEBUG_VERIFY_AT_F( \
- __gnu_debug::__can_advance(_First2, __dist.first),\
+ __gnu_debug::__can_advance(_First2, __dist, 1), \
_M_message(__gnu_debug::__msg_iter_subscript_oob)\
._M_iterator(_First2, #_First2) \
._M_integer(__dist.first), \
@@ -123,7 +129,7 @@ _GLIBCXX_DEBUG_VERIFY(__gnu_debug::__can_advance(_First, _Size), \
._M_iterator(_Last1, #_Last1), \
__FILE__,__LINE__,__PRETTY_FUNCTION__); \
_GLIBCXX_DEBUG_VERIFY_AT_F( \
- __gnu_debug::__can_advance(_First2, -__dist.first),\
+ __gnu_debug::__can_advance(_First2, __dist, -1), \
_M_message(__gnu_debug::__msg_iter_subscript_oob)\
._M_iterator(_First2, #_First2) \
._M_integer(-__dist.first), \
diff --git a/libstdc++-v3/include/debug/safe_iterator.h b/libstdc++-v3/include/debug/safe_iterator.h
index a10df190969..8e138fd32e5 100644
--- a/libstdc++-v3/include/debug/safe_iterator.h
+++ b/libstdc++-v3/include/debug/safe_iterator.h
@@ -407,6 +407,12 @@ namespace __gnu_debug
bool
_M_can_a
[PATCH] Fix typo in gcc/asan.c comment
Hi all,
This is my first contribution for an open source project. Please guide
me if anything is missing.
diff --git a/gcc/gcc/asan.c b/gcc/gcc/asan.c
index 89ecd99b182..836f50bd44a 100755
--- a/gcc/gcc/asan.c
+++ b/gcc/gcc/asan.c
@@ -105,7 +105,7 @@ along with GCC; see the file COPYING3. If not see
int
foo ()
{
- char a[23] = {0};
+ char a[24] = {0};
int b[2] = {0};
a[5] = 1;
Author: Husni Faiz
Date: Mon Mar 8 03:28:51 2021 +0530
Fix typo in gcc/asan.c comment
The size of the variable 'a' should be 24 bytes as mentioned in line
no.126.
diff --git a/gcc/gcc/asan.c b/gcc/gcc/asan.c
index 89ecd99b182..836f50bd44a 100755
--- a/gcc/gcc/asan.c
+++ b/gcc/gcc/asan.c
@@ -105,7 +105,7 @@ along with GCC; see the file COPYING3. If not see
int
foo ()
{
- char a[23] = {0};
+ char a[24] = {0};
int b[2] = {0};
a[5] = 1;
[PATCH] skip testing time before epoch on mips
When execute libstdc++ testcases on mips, I notice that last_write_time
alawys failed, and the failed VERIFY is "VERIFY(
approx_equal(last_write_time(f.path), time) );" where testing time before
than epoch.
Below is the minimal case:
```
// gcc a.c
int main()
{
struct timespec times[2] = {{1, UTIME_OMIT}, {-1201, 98500}};
utimensat(AT_FDCWD, "test", times, 0);
}
```
$ touch test && gcc a.c && ./a.out && stat test
File: test
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 805h/2053d Inode: 1056841 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ deepin) Gid: ( 1000/ deepin)
Access: 2021-03-08 13:52:55.966354501 +0800
Modify: 2106-02-07 14:08:15.98500 +0800
Change: 2021-03-08 13:52:56.907782193 +0800
Birth: -
Undoubtedly, mtime's type is unsigned somewhere on mips.
After debuging kernel, it turns out that mtime is always -1201 in
ext4_setattr, cp_new_stat, newlstat and etc, so the problem should not
occur in kernel space.
go back to user space via copy_to_user, I finally found mips used
"unsigned int st_mtime_sec;" in struct kernel_stat, which is used to
receive -1201 from kernel.
Maybe sparc also suffers from this problem, but I have no machine to
verify.
---
.../testsuite/27_io/filesystem/operations/last_write_time.cc| 2 ++
.../experimental/filesystem/operations/last_write_time.cc | 2 ++
2 files changed, 4 insertions(+)
diff --git
a/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
b/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
index 6ae64c482b6..72272d4e781 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
@@ -200,11 +200,13 @@ test02()
VERIFY( approx_equal(last_write_time(f.path), time) );
ec = bad_ec;
+ #ifndef __mips__
// A time before than the epoch
time -= chrono::milliseconds(1000 * 60 * 20 + 15);
last_write_time(f.path, time, ec);
VERIFY( !ec );
VERIFY( approx_equal(last_write_time(f.path), time) );
+ #endif
}
int
diff --git
a/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc
b/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc
index 536ab1f28f6..6fb490a6bc3 100644
---
a/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc
+++
b/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc
@@ -165,11 +165,13 @@ test02()
VERIFY( !ec );
VERIFY( approx_equal(last_write_time(f.path), time) );
+ #ifndef __mips__
ec = bad_ec;
time -= chrono::milliseconds(1000 * 60 * 10 + 15);
last_write_time(f.path, time, ec);
VERIFY( !ec );
VERIFY( approx_equal(last_write_time(f.path), time) );
+ #endif
}
int
--
2.30.0
Re: [PATCH] skip testing time before epoch on mips
Chen Li 于2021年3月8日周一 下午2:35写道：
>
>
> When execute libstdc++ testcases on mips, I notice that last_write_time
> alawys failed, and the failed VERIFY is "VERIFY(
> approx_equal(last_write_time(f.path), time) );" where testing time before
> than epoch.
>
> Below is the minimal case:
>
> ```
> // gcc a.c
> int main()
> {
> struct timespec times[2] = {{1, UTIME_OMIT}, {-1201, 98500}};
> utimensat(AT_FDCWD, "test", times, 0);
>
> }
> ```
>
> $ touch test && gcc a.c && ./a.out && stat test
> File: test
> Size: 0 Blocks: 0 IO Block: 4096 regular empty file
> Device: 805h/2053d Inode: 1056841 Links: 1
> Access: (0644/-rw-r--r--) Uid: ( 1000/ deepin) Gid: ( 1000/ deepin)
> Access: 2021-03-08 13:52:55.966354501 +0800
> Modify: 2106-02-07 14:08:15.98500 +0800
> Change: 2021-03-08 13:52:56.907782193 +0800
> Birth: -
>
> Undoubtedly, mtime's type is unsigned somewhere on mips.
>
It only has this problem on mips64.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983769
> After debuging kernel, it turns out that mtime is always -1201 in
> ext4_setattr, cp_new_stat, newlstat and etc, so the problem should not
> occur in kernel space.
>
> go back to user space via copy_to_user, I finally found mips used
> "unsigned int st_mtime_sec;" in struct kernel_stat, which is used to
> receive -1201 from kernel.
>
> Maybe sparc also suffers from this problem, but I have no machine to
> verify.
> ---
> .../testsuite/27_io/filesystem/operations/last_write_time.cc| 2 ++
> .../experimental/filesystem/operations/last_write_time.cc | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git
> a/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
> b/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
> index 6ae64c482b6..72272d4e781 100644
> --- a/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
> +++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
> @@ -200,11 +200,13 @@ test02()
>VERIFY( approx_equal(last_write_time(f.path), time) );
>
>ec = bad_ec;
> + #ifndef __mips__
>// A time before than the epoch
>time -= chrono::milliseconds(1000 * 60 * 20 + 15);
>last_write_time(f.path, time, ec);
>VERIFY( !ec );
>VERIFY( approx_equal(last_write_time(f.path), time) );
> + #endif
> }
>
> int
> diff --git
> a/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc
>
> b/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc
> index 536ab1f28f6..6fb490a6bc3 100644
> ---
> a/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc
> +++
> b/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc
> @@ -165,11 +165,13 @@ test02()
>VERIFY( !ec );
>VERIFY( approx_equal(last_write_time(f.path), time) );
>
> + #ifndef __mips__
>ec = bad_ec;
>time -= chrono::milliseconds(1000 * 60 * 10 + 15);
>last_write_time(f.path, time, ec);
>VERIFY( !ec );
>VERIFY( approx_equal(last_write_time(f.path), time) );
> + #endif
> }
>
> int
> --
> 2.30.0
>
>
>
--
YunQiang Su
Re: [PATCH v3] IBM Z: Fix usage of "f" constraint with long doubles
On 3/4/21 3:08 PM, Ilya Leoshkevich wrote: > v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563799.html > v1 -> v2: > - Handle constraint modifiers, use AR constraint instead of R, add > testcases for & and %. > > v2: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564380.html > v2 -> v3: > - The main prereq is now committed: > https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566237.html > - Dropped long-double-asm-abi.c test, because its prereq is not > approved (yet): > https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566218.html > - Removed superfluous constraint pointer increment. > > > > After switching the s390 backend to store long doubles in vector > registers, "f" constraint broke when used with the former: long doubles > correspond to TFmode, which in combination with "f" corresponds to > hard regs %v0-%v15, however, asm users expect a %f0-%f15 pair. > > Fix by using TARGET_MD_ASM_ADJUST hook to convert TFmode values to > FPRX2mode and back. > > gcc/ChangeLog: > > 2020-12-14 Ilya Leoshkevich > > * config/s390/s390.c (f_constraint_p): New function. > (s390_md_asm_adjust): Implement TARGET_MD_ASM_ADJUST. > (TARGET_MD_ASM_ADJUST): Likewise. > * config/s390/vector.md (fprx2_to_tf): Rename from *fprx2_to_tf, > add memory alternative. > (tf_to_fprx2): New pattern. > > gcc/testsuite/ChangeLog: > > 2020-12-14 Ilya Leoshkevich > > * gcc.target/s390/vector/long-double-asm-commutative.c: New > test. > * gcc.target/s390/vector/long-double-asm-earlyclobber.c: New > test. > * gcc.target/s390/vector/long-double-asm-in-out.c: New test. > * gcc.target/s390/vector/long-double-asm-inout.c: New test. > * gcc.target/s390/vector/long-double-asm-matching.c: New test. > * gcc.target/s390/vector/long-double-asm-regmem.c: New test. > * gcc.target/s390/vector/long-double-volatile-from-i64.c: New > test. Ok. Thanks! Andreas
Re: [Patch] tree-nested: Update assert for Fortran module vars [PR97927]
On Fri, 5 Mar 2021, Tobias Burnus wrote:
> Nested functions are permitted for C but not C++ as extension.
> They are also permitted for Fortran, which generates DECL_CONTEXT
> == NAMESPACE_DECL for module variables.
>
> That causes the gcc_assert (decl_function_context (decl) == info->context)
> to fail in tree-nested.c's lookup_field_for_decl.
>
> The call happens in convert_local_reference_stmt for:
> 2524case GIMPLE_ASSIGN:
> 2525 if (gimple_clobber_p (stmt))
> 2528 if (DECL_P (lhs)
> 2529 && !use_pointer_in_frame (lhs)
> 2530 && lookup_field_for_decl (info, lhs, NO_INSERT))
>
> The latter runs into the assert mentioned above. And the
> '= {CLOBBER}' occurs in gfortran due to the intent(out).
>
> As additional ingredient, a nested (internal) procedure involved,
> obviously as otherwise tree-nested.c wouldn't be involved.
>
> The patch fixes the assert and in terms of the assert it makes
> sense, but I am not sure whether there are assumptions
> elsewhere which are wrong for NAMESPACE_DECL.
I think the bug is elsewhere. We're not expecting non-local
(non-auto) variables to be queried with lookup_field_for_decl.
I think a reasonable fix would be sth like (also see
convert_local_reference_op on how it processes decls).
diff --git a/gcc/tree-nested.c b/gcc/tree-nested.c
index addd6eef9ab..5619ebc85d4 100644
--- a/gcc/tree-nested.c
+++ b/gcc/tree-nested.c
@@ -2526,6 +2526,7 @@ convert_local_reference_stmt (gimple_stmt_iterator
*gsi, bool *handled_ops_p,
{
tree lhs = gimple_assign_lhs (stmt);
if (DECL_P (lhs)
+ && auto_var_p (lhs)
&& !use_pointer_in_frame (lhs)
&& lookup_field_for_decl (info, lhs, NO_INSERT))
{
> OK for mainline? GCC 10?
>
> Tobias
>
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
> Thürauf
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
