As noted in BZ104044 we've got a few places where we have extraneous
semicolons.
Committed as obvious to the trunk,
Jeff
commit 6d82e0fea5f988e829912aaa70a9964a81ad4e5e
Author: Jeff Law
Date: Sat Nov 19 19:21:37 2022 -0700
[PR other/104044] Remove extraneous semicolons
gcc/
The tester started tripping this on s390-linux-gnu:
Tests that now fail, but worked before (19 tests):
gcc.dg/pr96542.c scan-tree-dump-times evrp "254" 2
The problem is we search for "254" in the dump file. The dump file
contains UIDs for function declarations. So changes in the number of
From: Andrew Pinski
This another one of these ICE after error issues with the
gimplifier and a fallout from r12-3278-g823685221de986af.
The problem here is gimplify_modify_expr does not
check if either from or to was an error operand.
This adds the check and fixes the ICE.
OK? Bootstrapped and t
On 19/11/2022 10:46, Tobias Burnus wrote:
On 18.11.22 18:49, Andrew Stubbs wrote:
On 18/11/2022 17:20, Tobias Burnus wrote:
This looks wrong:
+ /* stackbase = (stack_segment_decr & 0x)
+ + stack_wave_offset);
+ seg_size = dispatch_ptr->private_segment_size;
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This makes all the [iterator.range] functions always-inline, except the
ones that construct a std::reverse_iterator, as they do a little more
work. They could probably be made always_inline too though, and maybe
the std::reverse_iterator constructor
On 11/17/22 21:53, Palmer Dabbelt wrote:
On Thu, 17 Nov 2022 14:44:31 PST (-0800), jeffreya...@gmail.com wrote:
On 11/8/22 12:55, Philipp Tomsich wrote:
If we are testing a register or a paradoxical subreg (i.e. anything
that is not
a partial subreg) for equality/non-equality with zero, we c
On 11/18/22 19:53, Andrew Pinski wrote:
On Fri, Nov 18, 2022 at 12:06 PM Jeff Law via Gcc-patches
wrote:
On 11/18/22 11:05, apinski--- via Gcc-patches wrote:
From: Andrew Pinski
Since we use C++11 by default now, we can
use constexpr for some const decls in tree-core.h.
This patch does t
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/format: Fix -Wsign-compare warnings.
---
libstdc++-v3/include/std/format | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/includ
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This fixes a Doxygen warning about a mismatched parameter name. The
standard uses 'r' here, like the Doxygen comment, so use '__r' instead
of '__e'.
libstdc++-v3/ChangeLog:
* include/bits/ptr_traits.h (pointer_traits::pointer_to): Rename
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/107649
* include/std/complex (__complex_proj): Fix requires-clause.
---
libstdc++-v3/include/std/complex | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/s
On Sat, 19 Nov 2022 at 13:03, François Dumont via Libstdc++
wrote:
>
> Without this qualification I have this in _GLIBCXX_INLINE_VERSION mode:
>
> /home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:2649:
> note: candidate: 'template bool std::__9::is
Without this qualification I have this in _GLIBCXX_INLINE_VERSION mode:
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:2649:
note: candidate: 'template bool std::__9::isxdigit(_CharT,
const locale&)'
/home/fdt/dev/gcc/build_versioned_ns/x86_64
在 2022-11-19 19:27, Jonathan Wakely 写道:
I rebased the patch and re-tested with those options, and all tests
passed again:
=== jit Summary ===
# of expected passes15081
The patch is OK for trunk if you have favorable answers for the above
two questions.
Thanks
On Sat, 19 Nov 2022 at 02:40, Jason Merrill wrote:
>
> Thanks, this is what I'm pushing:
>
Great.
I wonder if we should move the contents of libstdc++fs.a and
libstdc++_libbacktrace.a into libstdc++exp.a and make the former libraries
into linker scripts that point to libstdc++exp.a
It would be
Richard Biener writes:
>> +/* We don't use language_function. */
>
> well ...
oops, yes - I'll remove the comment!
>> +struct GTY (()) language_function
>> +{
>> +
>> + /* While we are parsing the function, this contains information about
>> + the statement-tree that we are building. */
>>
On Tue, 15 Nov 2022 at 19:01, Jonathan Wakely wrote:
>
> On Tue, 15 Nov 2022 at 18:50, David Malcolm wrote:
> >
> > [Fixing typo in the Subject ("git" -> "jit" ); CCing jit mailing list]
> >
> > On Fri, 2022-11-11 at 17:16 +, Jonathan Wakely wrote:
> > > On Mon, 7 Nov 2022 at 13:51, Jonathan
On 18.11.22 18:49, Andrew Stubbs wrote:
On 18/11/2022 17:20, Tobias Burnus wrote:
This looks wrong:
+/* stackbase = (stack_segment_decr & 0x)
++ stack_wave_offset);
+ seg_size = dispatch_ptr->private_segment_size;
+ stacklimit = stackbase + seg_size*
Hi Jason!
Possible test.
An existing test might be to equip the existing warning for
bool unsigned double meh(void) {return 0;}
with a fix-it hint instead of the brief
error: two or more data types in declaration of ‘meh’.
Likewise for
bool unsigned meh(void) {return 0;}
error: ‘unsigned’ speci
Hi!
As the following testcase shows, the swap_rtx_condition function
in reg-stack can result in different code generation between -g and -g0.
The function is doing the changes as it goes, so does analysis and
changes together, which makes it harder to deal with DEBUG_INSNs,
where normally analysis
On Sat, Nov 19, 2022 at 9:53 AM Jakub Jelinek wrote:
>
> On Fri, Oct 21, 2022 at 10:23:14AM +0200, Uros Bizjak wrote:
> > OK, but now we have two more copies of a function that effectively
> > extends BF to SF. Can you please split this utility function out and
> > use it here and in cbranchbf4/cs
On Fri, Oct 21, 2022 at 10:23:14AM +0200, Uros Bizjak wrote:
> OK, but now we have two more copies of a function that effectively
> extends BF to SF. Can you please split this utility function out and
> use it here and in cbranchbf4/cstorebf4? I'm talking about this part:
>
> + op = gen_lowpa
Hi!
While reporting PR107748 (where is a problem with non-uglified names,
but I've left it out because it needs fixing anyway), I've noticed
various spots where identifiers in *intrin.h headers weren't uglified.
The following patch fixed those that are related to unions (I've grepped
for [a-zA-Z]\
22 matches
Mail list logo
