Re: std::vector code cleanup fixes optimizations
A small refresh on this patch now tested also for versioned namespace which require printers.py to be updated. Note that this simplification works also for normal mode so I can apply it independently from the stl_bvector.h part. * include/bits/stl_bvector.h [_GLIBCXX_INLINE_VERSION](_Bvector_impl_data::_M_start): Define as _Bit_type*. (_Bvector_impl_data(const _Bvector_impl_data&)): Default. (_Bvector_impl_data(_Bvector_impl_data&&)): Delegate to latter. (_Bvector_impl_data::operator=(const _Bvector_impl_data&)): Default. (_Bvector_impl_data::_M_move_data(_Bvector_impl_data&&)): Use latter. (_Bvector_impl_data::_M_reset()): Likewise. (_Bvector_impl_data::_M_swap_data): New. (_Bvector_impl::_Bvector_impl(_Bvector_impl&&)): Implement explicitely. (_Bvector_impl::_Bvector_impl(_Bit_alloc_type&&, _Bvector_impl&&)): New. (_Bvector_base::_Bvector_base(_Bvector_base&&, const allocator_type&)): New, use latter. (vector::vector(vector&&, const allocator_type&, true_type)): New, use latter. (vector::vector(vector&&, const allocator_type&, false_type)): New. (vector::vector(vector&&, const allocator_type&)): Use latters. (vector::vector(const vector&, const allocator_type&)): Adapt. [__cplusplus >= 201103](vector::vector(_InputIt, _InputIt, const allocator_type&)): Use _M_initialize_range. (vector::operator[](size_type)): Use iterator operator[]. (vector::operator[](size_type) const): Use const_iterator operator[]. (vector::swap(vector&)): Add assertions on allocators. Use _M_swap_data. [__cplusplus >= 201103](vector::insert(const_iterator, _InputIt, _InputIt)): Use _M_insert_range. (vector::_M_initialize(size_type)): Adapt. [__cplusplus >= 201103](vector::_M_initialize_dispatch): Remove. [__cplusplus >= 201103](vector::_M_insert_dispatch): Remove. * python/libstdcxx/v6/printers.py (StdVectorPrinter._iterator): Stop using start _M_offset. (StdVectorPrinter.to_string): Likewise. * testsuite/23_containers/vector/bool/allocator/swap.cc: Adapt. * testsuite/23_containers/vector/bool/cons/noexcept_move_construct.cc: Add check. François On 6/24/19 9:31 PM, François Dumont wrote: Hi Any feedback regarding this patch ? Thanks On 5/14/19 7:46 AM, François Dumont wrote: Hi This is the patch on vector to: - Optimize sizeof in Versioned namespace mode. We could go one step further by removing _M_p from _M_finish and just transform it into an offset but it is a little bit more impacting for the code. - Implement the swap optimization already done on main std::vector template class. - Fix move constructor so that it is noexcept no matter allocator move constructor noexcept qualification - Optimize move constructor with allocator when allocator type is always equal. - Use shortcuts in C++11 by skipping the _M_XXX_dispatch methods. Those are now defined only in pre-C++11 mode, I can't see any abi issue in doing so. * include/bits/stl_bvector.h [_GLIBCXX_INLINE_VERSION](_Bvector_impl_data::_M_start): Define as _Bit_type*. (_Bvector_impl_data(const _Bvector_impl_data&)): Default. (_Bvector_impl_data(_Bvector_impl_data&&)): Delegate to latter. (_Bvector_impl_data::operator=(const _Bvector_impl_data&)): Default. (_Bvector_impl_data::_M_move_data(_Bvector_impl_data&&)): Use latter. (_Bvector_impl_data::_M_reset()): Likewise. (_Bvector_impl_data::_M_swap_data): New. (_Bvector_impl::_Bvector_impl(_Bvector_impl&&)): Implement explicitely. (_Bvector_impl::_Bvector_impl(_Bit_alloc_type&&, _Bvector_impl&&)): New. (_Bvector_base::_Bvector_base(_Bvector_base&&, const allocator_type&)): New, use latter. (vector::vector(vector&&, const allocator_type&, true_type)): New, use latter. (vector::vector(vector&&, const allocator_type&, false_type)): New. (vector::vector(vector&&, const allocator_type&)): Use latters. (vector::vector(const vector&, const allocator_type&)): Adapt. [__cplusplus >= 201103](vector::vector(_InputIt, _InputIt, const allocator_type&)): Use _M_initialize_range. (vector::operator[](size_type)): Use iterator operator[]. (vector::operator[](size_type) const): Use const_iterator operator[]. (vector::swap(vector&)): Adapt. (vector::_M_initialize(size_type)): Add assertions on allocators. Use _M_swap_data. [__cplusplus >= 201103](vector::insert(const_iterator, _InputIt, _InputIt)): Use _M_insert_range. [__cplusplus >= 201103](vector::_M_initialize_dispatch): Remove. [__cplusplus >= 201103](vector::_M_insert_dispatch): Remove. * testsuite/23_containers/vector/bool/allocator/swap.cc: Adapt. * testsuite/23_containers/vector/bool/cons/noexcept_move_construct.cc: Add check. Tested under Linux x86_64, normal and debug modes. Ok to commit ? François diff --git a/libstdc++-v3/include/bits/stl_bvector.h
[Committed] Add some __int128 bitfield testcases
Hi,
While working on the bit-field lowering patch, I noticed there was
no testcases that used int128_t as bit-fields. So I added some.
Including two that uses scalar_storage_order. These are just compile
testcases.
Committed as obvious after testing on x86_64 to make sure the testcases pass.
Thanks,
Andrew Pinski
testsuite/ChangeLog:
* gcc.c-torture/compile/bitfield-1.c: New test.
* gcc.c-torture/compile/bitfield-endian-1.c: New test.
* gcc.c-torture/compile/bitfield-endian-2.c: New test.
Index: ChangeLog
===
--- ChangeLog (revision 279408)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2019-12-15 Andrew Pinski
+
+ * gcc.c-torture/compile/bitfield-1.c: New test.
+ * gcc.c-torture/compile/bitfield-endian-1.c: New test.
+ * gcc.c-torture/compile/bitfield-endian-2.c: New test.
+
2019-12-14 Jakub Jelinek
PR tree-optimization/92930
Index: gcc.c-torture/compile/bitfield-1.c
===
--- gcc.c-torture/compile/bitfield-1.c (nonexistent)
+++ gcc.c-torture/compile/bitfield-1.c (working copy)
@@ -0,0 +1,13 @@
+/* { dg-require-effective-target int128 } */
+
+struct f
+{
+ __uint128_t t:124;
+ __uint128_t t1:4;
+};
+
+struct f g(void)
+{
+ struct f t = {1, 2};
+ return t;
+}
Index: gcc.c-torture/compile/bitfield-endian-1.c
===
--- gcc.c-torture/compile/bitfield-endian-1.c (nonexistent)
+++ gcc.c-torture/compile/bitfield-endian-1.c (working copy)
@@ -0,0 +1,15 @@
+/* { dg-require-effective-target int128 } */
+
+#define ENDIAN __attribute((scalar_storage_order ("big-endian")))
+
+typedef struct ENDIAN
+{
+ __uint128_t t:124;
+ __uint128_t t1:4;
+}f;
+
+f g(void)
+{
+ f t = {1, 2};
+ return t;
+}
Index: gcc.c-torture/compile/bitfield-endian-2.c
===
--- gcc.c-torture/compile/bitfield-endian-2.c (nonexistent)
+++ gcc.c-torture/compile/bitfield-endian-2.c (working copy)
@@ -0,0 +1,15 @@
+/* { dg-require-effective-target int128 } */
+
+#define ENDIAN __attribute((scalar_storage_order ("little-endian")))
+
+typedef struct ENDIAN
+{
+ __uint128_t t:124;
+ __uint128_t t1:4;
+}f;
+
+f g(void)
+{
+ f t = {1, 2};
+ return t;
+}
Re: [PATCH 1/2] pretty-print: support URL escape sequences (PR 87488)
> Which revision of gcc is this? Using built-in specs. COLLECT_GCC=/opt/gcc-10.0-20191208/bin/gcc-10.0-20191208 COLLECT_LTO_WRAPPER=/opt/gcc-10.0-20191208/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-10-20191208/configure --prefix=/usr/local --sysconfdir=/etc --localstatedir=/var --libexecdir='/usr/local/lib' --enable-version-specific-runtime-libs --disable-rpath --with-system-zlib --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,fortran,lto --enable-plugin --enable-initfini-array --enable-gnu-indirect-function --program-suffix=-10.0-20191208 Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.0 20191208 (experimental) (GCC) > Which terminal are you using, and what version? libvte 2.90. Also tested on MATE Terminal 1.16.3 and Terminator 1.90, showing garbled outputs on warning lines and beeps. Tested on xfce4-terminal 0.8.3, it produces no beep but garbled outputs; however I think this is due to broken terminal bell support of xfce4-terminal in my system. 2019-12-15 23:09 GMT+08:00, David Malcolm : > On Sun, 2019-12-15 at 19:38 +0800, 王昊然 wrote: >> This patch has made my terminal beeps on every warning message, which >> is so noisy. > > Sorry about this. > >> May be this feature should be disabled by default, unless enabled by >> configure time option, runtime option or runtime environment >> variables. > > Which revision of gcc is this? > > Which terminal are you using, and what version? > > > Thanks > David > >
Re: [PATCH, c] all plattforms: support using a CC_REG instead cc0_rtx
On Sun, Dec 15, 2019 at 03:45:34PM -0700, Jeff Law wrote: > For x86, patterns which set/clobber the condition codes have explicit > sets/clobbers of the flags register. As a result the dataflow is > accurately represented and the optimizers don't really have to do > anything special. It's no different than cases there other hard > registers hold live data. Yup. And since x86 uses a fixed register as CC, already the earliest passes cannot just create one anywhere. Compare to if it used pseudos: you can just create a fresh pseudo wherever you want, it is a new one, nothing refers to it yet, nothing can conflict with it. If you used pseudos although there is only one hard register that can be used, you end up with quite a lot of save/restore code, and those are typically expensive insns as well. Quite a bit worse than the lost optimisations you get from using a fixed register (insns cannot move as much, lifetimes have to stay short, but that's about it). > Contrast to a cc0 target (such as the H8 still in the tree). On a cc0 > target patterns which modify the condition codes do not describe them > at the RTL level (with the exception of cmp/tst insns). Dataflow is > incomplete and as a result, most RTL passes have to handle things > specially to avoid the situation you're worried about. Search for > HAVE_cc0. Only the insn immediately after a cc0 setter can use the value set (well, ignoring branch delay slots. Ignoring those is a great idea, unless you are unlucky enough to have to use them ;-) ). So it isn't hard to handle the "dataflow" for them, in principle, but it is special cases *everywhere*. Segher
Re: [PATCH, c] all plattforms: support using a CC_REG instead cc0_rtx
On Sat, 2019-12-14 at 03:55 +0100, Stefan Franke wrote:
> Am 2019-12-13 21:59, schrieb Segher Boessenkool:
> > On Fri, Dec 13, 2019 at 08:55:15PM +0100, Stefan Franke wrote:
> > > Am 2019-12-13 18:58, schrieb Segher Boessenkool:
> > > > On Fri, Dec 13, 2019 at 05:25:41PM +0100, Stefan Franke wrote:
> > > > > Why? If you are using a cc register plus your architecture as many
> > > > > instructions which may clobber that cc register, some passes (e.g.
> > > > > gcse)
> > > > > will reorder the insns. This can lead to the situation that an insn is
> > > > > moved between a compare and it' consuming jump insn. Which yields
> > > > > invalid code. (Note that at these stages clobbers are not yet tracked
> > > > > as
> > > > > CLOBBER insns).
> > > >
> > > > Then that port has a bug. In the m68k port, there are no separate
> > > > compare
> > > > and jump insns ever, but for most ports those won't yet exist during
> > > > gcse.
> > >
> > > it looks like t2o insn for the m68k
> > >
> > > (insn 115 114 116 5 (set (cc0)
> > > (compare (subreg:HI (reg:SI 272) 2)
> > > (reg:HI 273)))
> > > /tmp/compiler-explorer-compiler1191113-13975-1allrsj.w8mc/example.c:216
> > > 17 {*m68k.md:559}
> > > (nil))
> > > (jump_insn 116 115 117 5 (set (pc)
> > > (if_then_else (ne (cc0)
> > > (const_int 0 [0]))
> > > (label_ref 99)
> > > (pc)))
> > > /tmp/compiler-explorer-compiler1191113-13975-1allrsj.w8mc/example.c:216
> > > 411 {bne}
> > > (int_list:REG_BR_PROB 4 (nil))
> > > -> 99)
> >
> > This is an older compiler. m68k no longer uses cc0 (except it is still
> > mentioned in two comments (well, commented-out code)).
> >
> > > > This is not unique to cc0 conversions: every port has a similar problem
> > > > with all FIXED_REGISTERS.
> > >
> > > It's not related to fixed registers.
> >
> > No, it is exactly the same situation. You cannot introduce uses of
> > such
> > a register if it might already exist in the insn stream somewhere, not
> > without checking first, and you better have a backup plan too.
> >
> > > It's unique to CC registers since
> > > these are on some plattforms modified by side effects. So after split2
> > > it's modelled using CLOBBERs
> >
> > There are no such implicit side effects if you have gotten rid of cc0.
> > That is the *point* of removing cc0.
> >
> > > > @findex cc0_rtx
> > > > There is only one expression object of code @code{cc0}; it is the
> > > > value of the variable @code{cc0_rtx}. Any attempt to create an
> > > > expression of code @code{cc0} will return @code{cc0_rtx}.
> > > >
> > > > There is a lot of code that depends on this property, you cannot break
> > > > it without fixing everything.
> > >
> > > There is no need to change the definition or modify any piece
> > > elsewhere.
> > > And the modified comparison will still work for cc0.
> >
> > Then you do not need your patch. You can compare cc0_rtx by identity.
> >
> >
> > Segher
>
> since I still don't get it: i386.md expands cbranch into two insns, e.g.
>
>
> (insn 17 16 18 4 (set (reg:CCNO 17 flags)
> (compare:CCNO (reg/v:SI 96 [ ])
> (const_int 0 [0]))) "x.c":2 3 {*cmpsi_ccno_1}
> (nil))
> (jump_insn 18 17 19 4 (set (pc)
> (if_then_else (le (reg:CCNO 17 flags)
> (const_int 0 [0]))
> (label_ref:DI 28)
> (pc))) "x.c":2 627 {*jcc_1}
> (int_list:REG_BR_PROB 1500 (nil))
>
>
> What mechanism guarantees that no other insn is inserted inbetween the
> compare and the jump?
THose are not cc0. Those are using a hard register in CC mode.
For x86, patterns which set/clobber the condition codes have explicit
sets/clobbers of the flags register. As a result the dataflow is
accurately represented and the optimizers don't really have to do
anything special. It's no different than cases there other hard
registers hold live data.
Contrast to a cc0 target (such as the H8 still in the tree). On a cc0
target patterns which modify the condition codes do not describe them
at the RTL level (with the exception of cmp/tst insns). Dataflow is
incomplete and as a result, most RTL passes have to handle things
specially to avoid the situation you're worried about. Search for
HAVE_cc0.
Jeff
Re: [PATCH, c] all plattforms: support using a CC_REG instead cc0_rtx
On Fri, 2019-12-13 at 17:25 +0100, Stefan Franke wrote: > Hi there, > > I suggest this patch to allow architectures do substitute cc0_rtx with a > generated cc register. > > Why? If you are using a cc register plus your architecture as many > instructions which may clobber that cc register, some passes (e.g. gcse) > will reorder the insns. This can lead to the situation that an insn is > moved between a compare and it' consuming jump insn. Which yields > invalid code. (Note that at these stages clobbers are not yet tracked as > CLOBBER insns). > > To get around this behaviour you have to fake HAVE_CC0, e.g. by adding > some dummy code to your md file: > > (define_peephole2 [(set (match_operand 0 "" "") (cc0))] "" > [(const_int 0)] "") > > plus some empty macros. All of this can be handled by the arch > implementation, but not the check for the cc0 inside of > >int sets_cc0_p(const_rtx x) > > > Changelog > > gcc/jump.c: use rtx_equal do determine the identity of cc0_rtx This is wrong. cc0_rtx is a shared RTX expression. There can be only one. Pointer equality is the right way to test, not rtx_equal_p. Furthermore on a cc0 machine the setter and user are always consecutive in the RTL stream. The optimizers know they're not supposed to separate them. Whatever you're doing, you're doing it wrong. jeff >
Re: [Patch, fortran] PR92753 - [9/10 Regression] ICE in gfc_trans_call, at fortran/trans-stmt.c:392
On Sun, Dec 15, 2019 at 06:41:50PM +, Paul Richard Thomas wrote: > This patch is straight forward and well explained by the ChangeLogs. > The ICE comes about because the simplification of the inquiry_part_ref > expressions produced bad expressions. > > Thanks to Steve for spotting the error in the INQUIRY_RE and > INQUIRY_IM parts that was so blindingly obvious that I couldn't see > it. This was not in the PR but was detected while fixing it. > > Regtested on FC31/x86_64 - OK for 9- and 10- branches? > OK. -- Steve
[Patch, fortran] PR92753 - [9/10 Regression] ICE in gfc_trans_call, at fortran/trans-stmt.c:392
This patch is straight forward and well explained by the ChangeLogs.
The ICE comes about because the simplification of the inquiry_part_ref
expressions produced bad expressions.
Thanks to Steve for spotting the error in the INQUIRY_RE and
INQUIRY_IM parts that was so blindingly obvious that I couldn't see
it. This was not in the PR but was detected while fixing it.
Regtested on FC31/x86_64 - OK for 9- and 10- branches?
Cheers
Paul
2019-12-15 Paul Thomas
PR fortran/92753
* expr.c (find_inquiry_ref): Catch INQUIRY_LEN case, where the
temporary expression has been converted to a constant and make
the new expression accordingly. Correct the error in INQUIRY_RE
and INQUIRY_IM cases. The original rather than the resolved
expression was being used as the source in mpfr_set.
2019-12-15 Paul Thomas
PR fortran/92753
* gfortran.dg/inquiry_type_ref_5.f90 : New test.
Index: gcc/fortran/expr.c
===
*** gcc/fortran/expr.c (revision 278354)
--- gcc/fortran/expr.c (working copy)
*** find_inquiry_ref (gfc_expr *p, gfc_expr
*** 1787,1797
if (!gfc_notify_std (GFC_STD_F2003, "LEN part_ref at %C"))
goto cleanup;
! if (!tmp->ts.u.cl->length
! || tmp->ts.u.cl->length->expr_type != EXPR_CONSTANT)
goto cleanup;
- *newp = gfc_copy_expr (tmp->ts.u.cl->length);
break;
case INQUIRY_KIND:
--- 1787,1801
if (!gfc_notify_std (GFC_STD_F2003, "LEN part_ref at %C"))
goto cleanup;
! if (tmp->ts.u.cl->length
! && tmp->ts.u.cl->length->expr_type == EXPR_CONSTANT)
! *newp = gfc_copy_expr (tmp->ts.u.cl->length);
! else if (tmp->expr_type == EXPR_CONSTANT)
! *newp = gfc_get_int_expr (gfc_default_integer_kind,
! NULL, tmp->value.character.length);
! else
goto cleanup;
break;
case INQUIRY_KIND:
*** find_inquiry_ref (gfc_expr *p, gfc_expr
*** 1814,1820
*newp = gfc_get_constant_expr (BT_REAL, tmp->ts.kind, >where);
mpfr_set ((*newp)->value.real,
! mpc_realref (p->value.complex), GFC_RND_MODE);
break;
case INQUIRY_IM:
--- 1818,1824
*newp = gfc_get_constant_expr (BT_REAL, tmp->ts.kind, >where);
mpfr_set ((*newp)->value.real,
! mpc_realref (tmp->value.complex), GFC_RND_MODE);
break;
case INQUIRY_IM:
*** find_inquiry_ref (gfc_expr *p, gfc_expr
*** 1826,1832
*newp = gfc_get_constant_expr (BT_REAL, tmp->ts.kind, >where);
mpfr_set ((*newp)->value.real,
! mpc_imagref (p->value.complex), GFC_RND_MODE);
break;
}
tmp = gfc_copy_expr (*newp);
--- 1830,1836
*newp = gfc_get_constant_expr (BT_REAL, tmp->ts.kind, >where);
mpfr_set ((*newp)->value.real,
! mpc_imagref (tmp->value.complex), GFC_RND_MODE);
break;
}
tmp = gfc_copy_expr (*newp);
Index: gcc/testsuite/gfortran.dg/inquiry_type_ref_5.f90
===
*** gcc/testsuite/gfortran.dg/inquiry_type_ref_5.f90 (nonexistent)
--- gcc/testsuite/gfortran.dg/inquiry_type_ref_5.f90 (working copy)
***
*** 0
--- 1,29
+ ! { dg-do run }
+ !
+ ! Test the fix for pr92753
+ !
+ ! Contributed by Gerhardt Steinmetz
+ !
+ module m
+type t
+ character(3) :: c
+end type
+type u
+ complex :: z
+end type
+type(t), parameter :: x = t ('abc')
+integer, parameter :: l = x%c%len ! Used to ICE
+
+type(u), parameter :: z = u ((42.0,-42.0))
+ end
+ program p
+use m
+call s (x%c%len)! ditto
+
+if (int (z%z%re) .ne. 42) stop 1! Produced wrong code and
+if (int (z%z%re) .ne. -int (z%z%im)) stop 2 ! runtime seg fault
+ contains
+subroutine s(n)
+ if (n .ne. l) stop 3
+end
+ end
[PATCH] Fix documentation of -mpoke-function-name ARM option
Hi!
Since in ARM state the value of PC is the address of the current
instruction plus 8 bytes, the code inspecting the value of PC stored at
FP + 0 should look at location PC - 16 : PC - 8 points to the stmfd
instruction, PC - 16 points two words before, where the top 8 bits are
set.
gcc/
2019-12-14 Jérémy Lefaure
* config/arm/arm.c (-mpoke-function-name): Fix documentation in comment.
* doc/invoke.texi (-mpoke-function-name): Fix documentation.
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c
+++ gcc/config/arm/arm.c
@@ -20738,9 +20738,9 @@ arm_asm_declare_function_name (FILE *file, const c
When performing a stack backtrace, code can inspect the value
of 'pc' stored at 'fp' + 0. If the trace function then looks
- at location pc - 12 and the top 8 bits are set, then we know
+ at location pc - 16 and the top 8 bits are set, then we know
that there is a function name embedded immediately preceding this
- location and has length ((pc[-3]) & 0xff00).
+ location and has length ((pc[-4]) & 0xff00).
We assume that pc is declared as a pointer to an unsigned long.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -18080,9 +18080,9 @@ preceding the function prologue. The generated co
When performing a stack backtrace, code can inspect the value of
@code{pc} stored at @code{fp + 0}. If the trace function then looks at
-location @code{pc - 12} and the top 8 bits are set, then we know that
+location @code{pc - 16} and the top 8 bits are set, then we know that
there is a function name embedded immediately preceding this location
-and has length @code{((pc[-3]) & 0xff00)}.
+and has length @code{((pc[-4]) & 0xff00)}.
@item -mthumb
@itemx -marm
Re: *Ping* Introduce -finline-arg-packing
On Sun, Dec 15, 2019 at 07:11:25PM +0100, Thomas Koenig wrote: > Am 10.12.19 um 22:22 schrieb Thomas Koenig: > > Steve made an excellent suggestion: -finline-arg-packing . > > > > So, OK with that change? > > In other words, is > > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00485.html > > OK with renaming the option to -finline-arg-packing ? > I think it's ok. -- Steve
*Ping* Introduce -finline-arg-packing
Am 10.12.19 um 22:22 schrieb Thomas Koenig: Steve made an excellent suggestion: -finline-arg-packing . So, OK with that change? In other words, is https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00485.html OK with renaming the option to -finline-arg-packing ? Regards Thomas
Re: [PATCH 1/2] pretty-print: support URL escape sequences (PR 87488)
On Sun, 2019-12-15 at 19:38 +0800, 王昊然 wrote: > This patch has made my terminal beeps on every warning message, which > is so noisy. Sorry about this. > May be this feature should be disabled by default, unless enabled by > configure time option, runtime option or runtime environment > variables. Which revision of gcc is this? Which terminal are you using, and what version? Thanks David
Re: [PATCH 1/2] pretty-print: support URL escape sequences (PR 87488)
This patch has made my terminal beeps on every warning message, which is so noisy. May be this feature should be disabled by default, unless enabled by configure time option, runtime option or runtime environment variables.
Re: [PATCH] Fix skip.exp test failure observed with gcc-9.2.0
Oh, sorry, worng mailing list. Please ignore this one. On 12/15/19 12:25 PM, Bernd Edlinger wrote: > Hi, > > this is the split out patch on skip.exp which fixes a pre-existing > compatibilty issue with that test case and gcc-9.2.0 (and gcc-10 from > trunk of a few weeks ago at least, likely other versions too). > > > Is it OK for trunk? > > > Thanks > Bernd. >
[PATCH] Fix skip.exp test failure observed with gcc-9.2.0
Hi,
this is the split out patch on skip.exp which fixes a pre-existing
compatibilty issue with that test case and gcc-9.2.0 (and gcc-10 from
trunk of a few weeks ago at least, likely other versions too).
Is it OK for trunk?
Thanks
Bernd.
gdb/testsuite:
2019-12-15 Bernd Edlinger
* gdb.base/skip.exp: Fix test failure observed with gcc-9.2.0.
From b15964b769373f25f276430914c5efa84d411032 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Sun, 15 Dec 2019 11:05:47 +0100
Subject: [PATCH] Fix skip.exp test failure observed with gcc-9.2.0
Need to step a second time because with this gcc version
the first step jumps back to main before entering foo.
---
gdb/testsuite/gdb.base/skip.exp | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/gdb/testsuite/gdb.base/skip.exp b/gdb/testsuite/gdb.base/skip.exp
index d763194..15dec42 100644
--- a/gdb/testsuite/gdb.base/skip.exp
+++ b/gdb/testsuite/gdb.base/skip.exp
@@ -21,8 +21,8 @@ load_lib completion-support.exp
standard_testfile
if { [prepare_for_testing "failed to prepare" "skip" \
- {skip.c skip1.c } \
- {debug nowarnings}] } {
+ {skip.c skip1.c } \
+ {debug nowarnings}] } {
return -1
}
@@ -142,7 +142,9 @@ with_test_prefix "step after disabling 3" {
gdb_test "step" "bar \\(\\) at.*" "step 1"
gdb_test "step" ".*" "step 2"; # Return from foo()
-gdb_test "step" "foo \\(\\) at.*" "step 3"
+# With gcc 9.2.0 we jump once back to main before entering foo here.
+# If that happens try to step a second time.
+gdb_test "step" "foo \\(\\) at.*" "step 3" "main \\(\\) at .*" "step"
gdb_test "step" ".*" "step 4"; # Return from bar()
gdb_test "step" "main \\(\\) at.*" "step 5"
}
@@ -261,7 +263,9 @@ with_test_prefix "step using -fu for baz" {
gdb_test_no_output "skip enable 7"
gdb_test "step" "bar \\(\\) at.*" "step 1"
gdb_test "step" ".*" "step 2"; # Return from bar()
-gdb_test "step" "foo \\(\\) at.*" "step 3"
+# With gcc 9.2.0 we jump once back to main before entering foo here.
+# If that happens try to step a second time.
+gdb_test "step" "foo \\(\\) at.*" "step 3" "main \\(\\) at.*" "step"
gdb_test "step" ".*" "step 4"; # Return from foo()
gdb_test "step" "main \\(\\) at.*" "step 5"
}
@@ -276,7 +280,9 @@ with_test_prefix "step using -rfu for baz" {
gdb_test_no_output "skip enable 8"
gdb_test "step" "bar \\(\\) at.*" "step 1"
gdb_test "step" ".*" "step 2"; # Return from bar()
-gdb_test "step" "foo \\(\\) at.*" "step 3"
+# With gcc 9.2.0 we jump once back to main before entering foo here.
+# If that happens try to step a second time.
+gdb_test "step" "foo \\(\\) at.*" "step 3" "main \\(\\) at.*" "step"
gdb_test "step" ".*" "step 4"; # Return from foo()
gdb_test "step" "main \\(\\) at.*" "step 5"
}
--
1.9.1
