https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101310
--- Comment #2 from sandra at gcc dot gnu.org ---
Patch posted here:
https://gcc.gnu.org/pipermail/fortran/2021-July/056251.html
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101493
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469
--- Comment #1 from Rin Okuyama ---
I've confirmed that the problem also occurs for sh3-none-elf:
$ sh3-none-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/pkg/cross-sh3-none-elf/bin/sh3-none-elf-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101495
Bug ID: 101495
Summary: Unnecessary vzeroupper
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101494
Bug ID: 101494
Summary: -Wmaybe-uninitialized false alarm with memrchr of size
0
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #252 from The Written Word
---
(In reply to Larkin Nickle from comment #249)
> Then, if libcpp's Makefile is patched so that charset.c is built with -O1, I
> eventually run into other errors:
>
>
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:
> > >
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101493
Bug ID: 101493
Summary: Error message for too deep include seems to be off by
one
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491
--- Comment #2 from David Malcolm ---
I wonder why this changed recently; as Dimitry notes, this has been done the
same since the initial merger of libgccjit into trunk.
I'm using $(includedir). What should I be using? Thanks
Snapshot gcc-11-20210717 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20210717/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101484
Andrew Stubbs changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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
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 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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101492
Bug ID: 101492
Summary: -msse4 -mgeneral-regs-only doesn't work
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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 = 42;
static_assert(r == 42);
}
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
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
Hi Joel,
On Sat, Jul 17, 2021 at 10:25:48PM +0800, The Other wrote:
> > - Full unicode/utf8 support in the lexer. Currently the lexer only
> > explicitly interprets the input as UTF8 for string parseing. It
> > should really treat all input as UTF-8. gnulib has some handy
> > modules we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491
Dimitry Andric changed:
What|Removed |Added
CC||dimitry at andric dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71741
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79741
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89702
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.3
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83150
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101310
--- Comment #1 from sandra at gcc dot gnu.org ---
Looks like 3 bugs for the price of 1!
First off the loop to fill in the result dimensions in CFI_section seemed to be
applying the base adjustment twice in different ways, or something like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491
Bug ID: 101491
Summary: [11 regression] /usr/local/include/libgccjit++.h
conflicts between different GCC installations
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83610
Andrew Pinski changed:
What|Removed |Added
CC||acahalan at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26367
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41910
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53485
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63789
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77953
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Keywords|
On July 17, 2021 8:54:38 PM GMT+02:00, Stefan Kanthak
wrote:
>Hi,
>
>GCC 10.2.0 (and GCC 8.3; other versions and targets except i386 and
>amd64 not tested) generate rather bad code for the following ternary
>expression:
>
>--- repro.c ---
>#define NULL (char *) 0
>
>char *dummy(char *string,
Hi,
GCC 10.2.0 (and GCC 8.3; other versions and targets except i386 and
amd64 not tested) generate rather bad code for the following ternary
expression:
--- repro.c ---
#define NULL (char *) 0
char *dummy(char *string, long count) {
return count == 0 ? NULL : string + 1;
}
--- EOF ---
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #251 from dave.anglin at bell dot net ---
On 2021-07-15 2:48 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #243 from The Written Word com> ---
> (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101205
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
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
*
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
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101490
Bug ID: 101490
Summary: ICE at convert_expr(tree_node*, Type*, Type*)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101479
--- Comment #5 from Andrew Pinski ---
(In reply to Simon Thornington from comment #4)
> I'll add that changing close_to_zero from
>
> fabs(x) < 0.5
>
> to
>
> x == 0.0 || fabs(x) < 0.5
>
> everything starts to work as I'd expect again...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101205
--- Comment #5 from Andrew Pinski ---
Created attachment 51169
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51169=edit
full patch
Patch which I sent but the company mail relay server looks broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #250 from Larkin Nickle ---
I should probably note that my PATH is set to the standard path, appended with
the PATH to whichever GCC's bin folder as well as a folder I have with some
utilities:
awk gawk make mksh sed tar
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #249 from Larkin Nickle ---
I am still unable to replicate a proper 11.1 build against 2.36 gas. Here's my
process:
HP GCC 4.7.1 -> GCC 4.7.4:
../../sources/gcc-4.7.4/configure --prefix=/usr/util/toolchain/gcc-4.7.4 --w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101489
Bug ID: 101489
Summary: Documentation gives wrong signatures for libgcc
float128 routines
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101206
--- Comment #1 from Andrew Pinski ---
It worked here:
https://gcc.gnu.org/pipermail/gcc-testresults/2021-June/700977.html
but failed here:
https://gcc.gnu.org/pipermail/gcc-testresults/2021-June/701197.html
Most likely canidate of introducing
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,
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101488
--- Comment #1 from Jakub Jelinek ---
I've tried a WIP (with just 0 && or commenting out parts of current code
instead of removing/cleaning up) that attempts to treat __VA_OPT__ ( ... ) with
## before __VA_OPT__ and/or after ) more similarly to
Sorry, pressed the wrong button. I meant to "reply all".
-- Forwarded message -
From: The Other
Date: Sat, Jul 17, 2021 at 10:20 PM
Subject: Re: New contributor tasks
To: Philip Herron
> The AST dump (--rust-dump-parse) was actually useful for checking the
> comment doc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101488
Bug ID: 101488
Summary: Implement p1042r1 __VA_OPT__ placemarker changes
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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
>
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101487
Bug ID: 101487
Summary: [GCOV] Wrong coverage of "switch" inside "while" loop
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101486
Bug ID: 101486
Summary: Rejects valid qualification conversion involving array
of unknown bound in function template argument [P0388]
Product: gcc
Version: 12.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101147
--- Comment #1 from Yang Wang ---
sorry,its(In reply to Yang Wang from comment #0)
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-
> wrapper
> Target:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
Bug ID: 101485
Summary: Calling std::equal with std::byte* does not use memcmp
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101484
Bug ID: 101484
Summary: [12 Regression] trunk 20210717 ftbfs for amdgcn-amdhsa
(gcn offload)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101205
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> The fix actually might be simplier than I had expected because csneg is
> already implement, just need to extend it to csinv also like so:
Yep that works. time
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101205
--- Comment #3 from Andrew Pinski ---
The fix actually might be simplier than I had expected because csneg is already
implement, just need to extend it to csinv also like so:
diff --git a/gcc/config/aarch64/aarch64.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101205
--- Comment #2 from Andrew Pinski ---
The problem is csinv3si_insn, csinv3_uxtw_insn2, nor csinv3_uxtw_insn3 would
match as those have the zero_extend inside the if/then/else rather on the
outside which is being matched here:
Trying 36 -> 19:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101483
Bug ID: 101483
Summary: join_view::iterator's constructor missing std::move
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96227
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
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.
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.
70 matches
Mail list logo
