https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95420
--- Comment #1 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #0)
> Configuring with --target=arm-wrs-vxworks7 --with-cpu=arm8 and the selftests
> pass.
>
I was going to ignore that you need to set VSB_DIR in order for the
During the cc0 transition work I had disabled most, if not all, of the optional
patterns in the H8 backend. Then I converted the critical patterns to get a
baseline state. Then I could re-add the disabled patterns as they were
converted
and verify we weren't going backwards from a correctness
On Fri, 2020-05-29 at 22:03 +0200, Jakub Jelinek wrote:
> On Fri, May 15, 2020 at 10:32:00AM -0600, Jeff Law via Gcc-patches wrote:
> > > I wasn't sure if it wouldn't be safer to add some bool flag set to true by
> > > the new code and then add gcc_assert in all the other paths, like
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95446
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=95439
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95151
Bug 95151 depends on bug 95439, which changed state.
Bug 95439 Summary: Incorrect zero count check in cmpstrnsi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95439
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95448
Bug ID: 95448
Summary: Missing optimization: pointer untag, re-tag should be
no-op
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95447
Bug ID: 95447
Summary: cmpstrn peepholes are out of date
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
This is potentially a sequence of 3 shifts, we which optimize to a sequence
of 2 shifts. This can happen when unsigned int is used for array indexing.
Tested with cross toolchain build and check for riscv32-elf and riscv64-linux.
There were no regressions. The new test fails without the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
--- Comment #1 from Andrew Pinski ---
Can you provide a full testcase?
>From the sound of it, this might be a LLVM bug.
As mentioned you can't extend a final class which means base object constructor
can't be called. If LLVM is producing a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95402
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95446
Bug ID: 95446
Summary: False positive for optional arguments of elemental
procedure
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Snapshot gcc-10-20200530 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20200530/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95445
Martin Sebor changed:
What|Removed |Added
Blocks||87403
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95445
Bug ID: 95445
Summary: diagnose incompatible calls to functions declared
without prototype
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95444
Bug ID: 95444
Summary: Incorrect constraints on length operand in cmpstrnqi
patterns
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95443
Bug ID: 95443
Summary: cmpstrnqi patterns update string length
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95442
Bug ID: 95442
Summary: LRA inserts a reload insn for REG_DEAD register
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On Sat, May 30, 2020 at 09:35:05PM +0100, Jonathan Wakely via Gcc wrote:
> On Sat, 30 May 2020 at 21:09, Harald Anlauf wrote:
> >
> > Dear experts,
> >
> > let's assume I need to backport a series of commits on master to a release
> > branch.
> > In the release branch, this series of commits
On Sat, 30 May 2020 at 21:09, Harald Anlauf wrote:
>
> Dear experts,
>
> let's assume I need to backport a series of commits on master to a release
> branch.
> In the release branch, this series of commits should become a single commit.
>
> With bare git, there is "cherry-pick -n" that seems to
This change adds project files to provide the ability to rebuild the
runtime with gprbuild after setup-rts is called.
Tested on x86_64-linux-gnu, committed on master
gcc/ada/
* Makefile.rtl (ADA_INCLUDE_SRCS): Replace Makefile.adalib by
libada.gpr and associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95441
Bug ID: 95441
Summary: Failure to reuse flag from float compare
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
> Thanks. Though, see Andreas' mail, I think he is right that there is really
> no reason to have that dt_name local buffer at all, just changing
> dt_name from an array to const char *dt_name; and changing the strcpy to
> dt_name = "STAR";
> and the former strncpy (dt_name, ...) to
> dt_name =
On Sat, May 30, 2020 at 09:11:23PM +0200, Jakub Jelinek via Gcc-patches wrote:
> There is a possible buffer overflow in the string with or without that
> change but to fix that I think it would be desirable to pass not just the
> string buffer to the function but also the length of the buffer and
On Sat, May 30, 2020 at 08:57:46PM +0200, Harald Anlauf wrote:
> > That is detecting it after the buffer overflow has happened already, that is
> > too late, after UB anything can happen.
> > +{
> > + const char *upper = gfc_dt_upper_string (derived->name);
> > + size_t len = strnlen
Dear experts,
let's assume I need to backport a series of commits on master to a release
branch.
In the release branch, this series of commits should become a single commit.
With bare git, there is "cherry-pick -n" that seems to be applicable.
What is the right way to do it for gcc?
Thanks,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373
--- Comment #10 from anlauf at gcc dot gnu.org ---
Master should be fixed now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373
--- Comment #9 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:dd38c765a04d06c775134a135f68b18c3b7c9c78
commit r11-743-gdd38c765a04d06c775134a135f68b18c3b7c9c78
Author: Harald Anlauf
Date:
> That is detecting it after the buffer overflow has happened already, that is
> too late, after UB anything can happen.
> +{
> + const char *upper = gfc_dt_upper_string (derived->name);
> + size_t len = strnlen (upper, sizeof (dt_name));
> + gcc_assert (len < sizeof (dt_name));
On Sat, May 30, 2020 at 5:06 PM David Malcolm wrote:
> On Sat, 2020-05-30 at 13:40 +, Pip Cet via Gcc-patches wrote:
> > I think we should just omit the triangle inequality test from the
> > self-test, as in the attached patch.
>
> I like the idea,
Thanks!
> but can you update the comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090
--- Comment #13 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:bf5fbbbd8c9a3385c1083cc80683bdb0195b1ffc
commit r11-742-gbf5fbbbd8c9a3385c1083cc80683bdb0195b1ffc
Author: Harald Anlauf
Date:
On Mai 30 2020, Harald Anlauf wrote:
> diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
> index db395624a16..6d0924da2b8 100644
> --- a/gcc/fortran/class.c
> +++ b/gcc/fortran/class.c
> @@ -484,7 +484,12 @@ get_unique_type_string (char *string, gfc_symbol
> *derived)
>if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64794
--- Comment #2 from Atul Sharma ---
Is there any update on the issue
I am facing this issue on the newer version of gcc(10.1.) as well
Added the details of compilation failure as attachement
I have been facing issue for the following mention
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64794
Atul Sharma changed:
What|Removed |Added
CC||atulsharma406 at gmail dot com
---
Hi,
This fixes up the zero-initialization of the coro frame pointer
to avoid an unused assigned value, spotted by Martin Liska with
static analysis.
checked on x86-64-darwin,
pushed to master as obvious,
thanks
Iain
gcc/cp/ChangeLog:
* coroutines.cc (morph_fn_to_coro): Revise
On Sat, 2020-05-30 at 13:40 +, Pip Cet via Gcc-patches wrote:
> On Fri, May 29, 2020 at 6:21 PM Pip Cet wrote:
> > IIRC, minimum string alignment does not satisfy the triangle
> > inequality anyway, so test_metric_conditions should probably not
> > pretend to test it...
>
> I did remember
On Fri, 2020-05-29 at 10:54 -0600, Tom Tromey wrote:
> I got this error message when editing gcc and recompiling:
>
> ../../gcc/gcc/ada/gcc-interface/decl.c:7714:39: error:
> ‘DWARF_GNAT_ENCODINGS_all’ was not declared in this scope; did you
> mean ‘DWARF_GNAT_ENCODINGS_GDB’?
> 7714 | =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95440
Bug ID: 95440
Summary: [coroutines] ICE with static members in promise_type
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95389
--- Comment #3 from Ulrich Teichert ---
BTW, I can reproduce the same strange reflect.Type.PkgPath issue on AMD64/Linux
with gccgo 10.1.0
Hi Harald,
That looks good to me for all three branches.
Cheers
Paul
On Fri, 29 May 2020 at 23:00, Harald Anlauf wrote:
> The initial attempt to fix this PR unfortunately produced a regression
> in the testsuite that was overlooked. The real fix is to apply this
> check in the appropriate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
--- Comment #14 from Luc Van Oostenryck ---
(In reply to Tom Tromey from comment #7)
> The feature was added specifically to mimic what sparse does.
> If sparse changes, I think changing gcc would be appropriate.
Sparse warnings issued when
"Yangfei (Felix)" writes:
> Turns out that this ICE triggers under x86 -m32.
>
> Command to reproduce:
> ~/build-gcc/x86_64-pc-linux-gnu/32/libgcc$ gcc -g -O2 -m32 -O2 -g -O2
> -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
> -Wstrict-prototypes -Wmissing-prototypes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95437
--- Comment #1 from Pedro Alves ---
> This "missing template parameters info" issue also prevents setting
> breakpoints > using the alias template with GCC-built binaries.
This GDB commit adds a testcase exercising this issue:
On Fri, May 29, 2020 at 6:21 PM Pip Cet wrote:
> IIRC, minimum string alignment does not satisfy the triangle
> inequality anyway, so test_metric_conditions should probably not
> pretend to test it...
I did remember correctly, though of course that should have been
"optimal string alignment"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95438
--- Comment #1 from bouanto at zoho dot com ---
The opposite does not work as well:
libgccjit.so: error: gcc_jit_context_new_cast: cannot cast (long long)(unsigned
long long)* from type: long long to type: unsigned char * *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95439
Bug ID: 95439
Summary: Incorrect zero count check in cmpstrnsi
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95438
Bug ID: 95438
Summary: Cannot cast pointer to int
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95437
Bug ID: 95437
Summary: DW_TAG_typedef for template alias missing template
type parameters
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Hi!
On Sat, May 30, 2020 at 08:15:55AM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> >> Sure. But the point is that FAILing isn't “explicitly allowed” for vcond*.
> >> In fact it's the opposite.
I disagree btw, and no one else has noticed for 16 years either.
In general,
On Sat, May 30, 2020 at 02:48:32PM +0200, Harald Anlauf wrote:
> I'ld like to detect the situation that when somebody modifies name-mangling in
> a way that generates a buffer overrun during regtesting so that the
> temporaries
> to adjust are easier to find.
>
> After thinking about your and
> > > This breaks bootstrap:
> > >
> > > https://gcc.gnu.org/pipermail/gcc-regression/2020-May/072642.html
> > >
> > > ../../src-master/gcc/fortran/class.c:487:13: error: ‘char*
> > > strncpy(char*, const char*, size_t)’ specified bound 67 equals
> > > destination size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95151
--- Comment #2 from H.J. Lu ---
Initial attempt failed on
[hjl@gnu-cfl-2 pr95151]$ cat saved.c
#include
#include
#include
#include
unsigned char *buf1, *buf2;
int ret;
size_t page_size;
static void
do_one_test (char *dst, char *src,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92455
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #7
Hi!
The language committee decided that there is no reason to follow malloc
size 0 behavior and we can just offer a single choice of what will be done.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2020-05-30 Jakub Jelinek
* allocator.c (omp_alloc): For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95436
--- Comment #1 from Jakub Jelinek ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546851.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95436
Bug ID: 95436
Summary: [11 Regression] ICE in store_expr, at expr.c:5845
since
r11-711-g43a4fc095e30188392cc42299c4081297e321104
Product: gcc
Version: 11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95436
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
Hi Jeff,
Le 21/05/2020 à 19:41, Jeff Law a écrit :
> On Thu, 2020-05-21 at 19:31 +0200, Richard Biener via Gcc-patches wrote:
>> On May 21, 2020 5:35:19 PM GMT+02:00, Romain Naour via Gcc-patches <
>> gcc-patches@gcc.gnu.org> wrote:
>>> As reported by several Buildroot users [1][2][3], the gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435
--- Comment #4 from Jan ---
Sorry bad wording on my site. I meant the code is getting slower with znver2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435
Marc Glisse changed:
What|Removed |Added
Target||x86-*-*
--- Comment #3 from Marc Glisse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435
--- Comment #2 from Jan ---
Created attachment 48643
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48643=edit
source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435
--- Comment #1 from Jan ---
Created attachment 48642
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48642=edit
gcc -g -m32 -march=skylake -O1 -s testmem_modified.c -o tm32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435
Bug ID: 95435
Summary: bad builtin memcpy performance with znver1/znver2 and
32bit
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Hi,
> -Original Message-
> From: Yangfei (Felix)
> Sent: Friday, May 29, 2020 2:56 PM
> To: 'Hongtao Liu' ; H.J. Lu
> Cc: gcc-patches@gcc.gnu.org; Uros Bizjak ; Jakub
> Jelinek ; Richard Sandiford
>
> Subject: RE: [PATCH PR95254] aarch64: gcc generate inefficient code with
> fixed sve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95241
Mateusz Tabaka changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #6 from Mateusz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #16 from Martin Liška ---
> For our application, all processes generating profiling feedback data to a
> single directory seems is not a choice.
Why is it problem? You need to provide reasoning for that.
> We chose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95429
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Segher Boessenkool writes:
> On Fri, May 29, 2020 at 06:26:55PM +0100, Richard Sandiford wrote:
>> Segher Boessenkool writes:
>> > Most patterns *do* FAIL on some target. We cannot rewind time.
>>
>> Sure. But the point is that FAILing isn't “explicitly allowed” for vcond*.
>> In fact it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95433
Marc Glisse changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
71 matches
Mail list logo
