On 16.07.21 20:22, Sandra Loosemore wrote:
So it seems to me rather surprising to take the position that we should
not be committing any new test cases that need to be XFAILed
It is what I was told in no uncertain terms some years ago, which
is where my current state of knowledge comes from.
S
On Friday, 16 July 2021 21:58:36 CEST Jonathan Wakely wrote:
> On Fri, 16 Jul 2021 at 20:26, Matthias Kretz wrote:
> > On Friday, 16 July 2021 18:54:30 CEST Jonathan Wakely wrote:
> > > On Fri, 16 Jul 2021 at 16:33, Jason Merrill wrote:
> > > > Adjusting them based on tuning would certainly simpli
On Sat, 17 Jul 2021, 09:15 Matthias Kretz, wrote:
> On Friday, 16 July 2021 21:58:36 CEST Jonathan Wakely wrote:
> > On Fri, 16 Jul 2021 at 20:26, Matthias Kretz wrote:
> > > On Friday, 16 July 2021 18:54:30 CEST Jonathan Wakely wrote:
> > > > On Fri, 16 Jul 2021 at 16:33, Jason Merrill wrote:
>
On Saturday, 17 July 2021 15:32:42 CEST Jonathan Wakely wrote:
> On Sat, 17 Jul 2021, 09:15 Matthias Kretz, wrote:
> > If somebody writes a library with `keep_apart` in the public API/ABI then
> > you're right.
>
> Yes, it's fine if those constants don't affect anything across module
> boundaries
Hello,
Thanks for your feedback on the previous RFC version of this proposal. This
patch set is a refined and tested version of the same.
- Added changes to tm.texi.in and regenerated tm.texi.
- Updated the dejagnu files for redundant checks on AIX platform.
Bootstrapped and reg tested on x86
gcc/Changelog:
* flags.h (ctf_debuginfo_p): New function declaration.
* opts.c (ctf_debuginfo_p): New function definition.
---
gcc/flags.h | 4
gcc/opts.c | 8
2 files changed, 12 insertions(+)
diff --git a/gcc/flags.h b/gcc/flags.h
index 85fd228..afedef0 100644
--
CTF/BTF debug formats can be safely enabled for all ELF-based targets by
default in GCC.
CTF/BTF debug formats now adopt a similar approach as taken for DWARF debug
format via the DWARF2_DEBUGGING_INFO.
- By default, CTF/BTF formats can be enabled for all ELF-based targets.
- By default, CTF/B
From: Andrew Pinski
So the problem is even though there was a csneg with
a zero_extend in the front, there was not one for csinv.
This fixes it by extending that pattern.
OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.
gcc/ChangeLog:
PR target/101205
* con
From: Andrew Pinski
So the problem is even though there was a csneg with
a zero_extend in the front, there was not one for csinv.
This fixes it by extending that pattern.
OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.
gcc/ChangeLog:
PR target/101205
* con
Hi Martin!
On Fri, 2021-06-04 15:27:04 -0600, Martin Sebor wrote:
> This is a revised patch series to add warning control by group and
> location, updated based on feedback on the initial series.
[...]
My automated checking (in this case: Using Debian's "gcc-snapshot"
package) indicates that bet
Hi!
On Fri, Jul 16, 2021 at 11:35:25AM -0700, apinski--- via Gcc-patches wrote:
> --- a/gcc/c-family/c-common.c
> +++ b/gcc/c-family/c-common.c
> @@ -5799,7 +5799,7 @@ parse_optimize_options (tree args, bool attr_p)
>
>if (TREE_CODE (value) == INTEGER_CST)
> {
> - char buffer
On Sat, Jul 17, 2021 at 6:55 AM Matthias Kretz wrote:
> On Saturday, 17 July 2021 15:32:42 CEST Jonathan Wakely wrote:
> > On Sat, 17 Jul 2021, 09:15 Matthias Kretz, wrote:
> > > If somebody writes a library with `keep_apart` in the public API/ABI
> then
> > > you're right.
> >
> > Yes, it's fin
On 7/16/21 1:44 PM, Marek Polacek wrote:
On Fri, Jul 16, 2021 at 12:53:05PM -0400, Jason Merrill wrote:
On 7/15/21 5:14 PM, Marek Polacek wrote:
The combination of DR 2481 and DR 2126 should allow us to do
void f()
{
constexpr const int &r = 42;
static_assert(r == 42);
On 7/16/21 6:34 PM, Jakub Jelinek wrote:
On Fri, Jul 16, 2021 at 05:36:13PM -0400, Marek Polacek via Gcc-patches wrote:
When implementing DR 1512 in r11-467 I neglected to reject ordered
comparison of two null pointers, like nullptr < nullptr. This patch
fixes that omission.
Bootstrapped/regte
On Sat, Jul 17, 2021 at 2:31 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Fri, Jul 16, 2021 at 11:35:25AM -0700, apinski--- via Gcc-patches wrote:
> > --- a/gcc/c-family/c-common.c
> > +++ b/gcc/c-family/c-common.c
> > @@ -5799,7 +5799,7 @@ parse_optimize_options (tree args, bool attr_p)
> >
> >
On 16/07/2021 18:42, Thomas Schwinge wrote:
Of course, we may simply re-work the libgomp/GCN code -- but don't we
first need to answer the question whether the current code is actually
"bad"? Aren't we going to get a lot of similar reports from
kernel/embedded/other low-level software developers
For -mgeneral-regs-only, enable the GPR only instructions which are
enabled implicitly by SSE ISAs unless they have been disabled explicitly.
gcc/
PR target/101492
* common/config/i386/i386-common.c (ix86_handle_option): For
-mgeneral-regs-only, enable the GPR only instruc
On Thu, Apr 22, 2021 at 7:30 AM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Apr 22, 2021 at 2:52 PM Richard Biener
> wrote:
> >
> > On Thu, Apr 22, 2021 at 2:22 PM Jakub Jelinek wrote:
> > >
> > > On Thu, Apr 22, 2021 at 01:23:20PM +0200, Richard Biener via Gcc-patches
> > > wrote:
> > >
This patch fixes bugs I observed in tests for the CFI_section function
-- it turns out both the function and test cases had bugs. :-(
The bugs in CFI_section itself had to do with incorrect computation of
the base address for the result descriptor, plus an ordering problem
that caused it not
19 matches
Mail list logo
