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 s
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
> > > followi
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 an
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 proje
> 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 = gf
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 i
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
> 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 so
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 (derived->attr.
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 initializa
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 cor
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 | = debug
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
"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 -Wold-styl
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" :-).
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, almos
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 H.J
> > > 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 [-Werror=stringop-truncatio
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 s
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 bui
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 ve
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 the
23 matches
Mail list logo
