On Tue, May 03, 2022 at 05:46:50PM -0700, Palmer Dabbelt wrote:
> This test was relying on undefined behavior, with -Wundef I get
>
> gcc/testsuite/gcc.dg/pr102892-1.c: In function 'main':
> cc/testsuite/gcc.dg/pr102892-1.c:14:18: warning: 'a' is used
> uninitialized [-Wuninitialized]
>
On Wed, May 4, 2022 at 2:47 AM Palmer Dabbelt wrote:
>
> This test was relying on undefined behavior, with -Wundef I get
>
> gcc/testsuite/gcc.dg/pr102892-1.c: In function 'main':
> cc/testsuite/gcc.dg/pr102892-1.c:14:18: warning: 'a' is used
> uninitialized [-Wuninitialized]
>14
This test was relying on undefined behavior, with -Wundef I get
gcc/testsuite/gcc.dg/pr102892-1.c: In function 'main':
cc/testsuite/gcc.dg/pr102892-1.c:14:18: warning: 'a' is used uninitialized
[-Wuninitialized]
14 | for (long a; a < 1; ++a)
|~~^~~
g
The test cases in analyzer/pr104308.c use uninitialized values in a way
that doesn't plumb through to the return value of the function. This
allows the accesses to be deleted, which can result in the diagnostic
not firing.
gcc/testsuite/ChangeLog
* gcc.dg/analyzer/pr104308.c (test_memmov
Similar to 37e65643d3e ("testsuite/101269: fix testcase when used with
-m32"), RISC-V needs to be told not to put symbols in the
sdata/srodata/sbss sections.
gcc/testsuite/ChangeLog
* debug/btf/btf-datasec-1.c: Don't use small data on RISC-V.
---
gcc/testsuite/gcc.dg/debug/btf/btf-datase
On Mon, 2 May 2022, David Faust via Gcc-patches wrote:
> Consider the following example:
>
>#define __typetag1 __attribute__((btf_type_tag("tag1")))
>#define __typetag2 __attribute__((btf_type_tag("tag2")))
>#define __typetag3 __attribute__((btf_type_tag("tag3")))
>
>int __typeta
On 4/27/22 16:30, Marek Polacek wrote:
On Wed, Apr 27, 2022 at 11:00:46AM -0400, Patrick Palka wrote:
On Tue, 26 Apr 2022, Marek Polacek wrote:
Consider
struct A {
int x;
int y = x;
};
struct B {
int x = 0;
int y = A{x}.y; // #1
};
where for #1 we end up with
On 5/2/22 07:11, Jakub Jelinek wrote:
Hi!
On the following testcase, we emit deprecated warnings or unavailable errors
even on merge declarations of those lambdas (the dg-bogus directives), while
IMHO we should emit them only when something actually calls those lambdas.
The following patch temp
On 5/3/22 16:43, Jakub Jelinek wrote:
On Tue, May 03, 2022 at 04:26:51PM -0400, Jason Merrill wrote:
On 5/2/22 12:19, Marek Polacek wrote:
This patch fixes an oversight whereby we treated >= as the end of
a template argument. This causes problems in C++14, because in
cp_parser_template_argumen
On Tue, May 03, 2022 at 04:26:51PM -0400, Jason Merrill wrote:
> On 5/2/22 12:19, Marek Polacek wrote:
> > This patch fixes an oversight whereby we treated >= as the end of
> > a template argument. This causes problems in C++14, because in
> > cp_parser_template_argument we go different ways for C
On 5/2/22 12:18, Marek Polacek wrote:
Consider
struct F {
F(int) {}
F operator()(int) const { return *this; }
};
and
F(i)(0)(0);
where we're supposed to first call the constructor and then invoke
the operator() twice. However, we parse this as an init-declarator:
"(i)" loo
On 5/2/22 12:19, Marek Polacek wrote:
This patch fixes an oversight whereby we treated >= as the end of
a template argument. This causes problems in C++14, because in
cp_parser_template_argument we go different ways for C++14 and C++17:
/* It must be a non-type argument. In C++17 any consta
On 5/2/22 14:50, Patrick Palka wrote:
Currently when checking the constraints of a class template, we do so in
the context of the template, not the specialized type. This is the best
we can do for a primary template since the specialized type is valid
only if the primary template's constraints a
Update the match rules to accommodate the non-standard libgcc function
names for PRU backend. The C6x target also seems to be affected, and
should be fixed with this change, but there is no free simulator for me
to check.
Sanity checked that there are no new failures on x86_64-pc-linux-gnu.
gcc/
The memchr test cases expect padding to be present in structures. But
this is not true for targets which pack by default. Skip these test
cases in order to avoid static assert errors when checking field offsets.
The following asserts are triggered due to assumptions for structure
field alignment
Place markers in test case to handle targets which pack structures by
default. Validated on pru-none-elf.
Committed as obvious.
gcc/testsuite/ChangeLog:
* gcc.dg/Wattributes-8.c: Add annotations for default_packed
targets.
Signed-off-by: Dimitar Dimitrov
---
gcc/testsuite/gcc.
PRU target defines DI patterns for logical ALU operations.
gcc/testsuite/ChangeLog:
* gcc.dg/lower-subreg-1.c: Skip for PRU.
Signed-off-by: Dimitar Dimitrov
---
gcc/testsuite/gcc.dg/lower-subreg-1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.d
Access to arbitrary stack frames is not supported on PRU.
gcc/testsuite/ChangeLog:
* gcc.dg/Wno-frame-address.c: Skip for PRU target.
Signed-off-by: Dimitar Dimitrov
---
gcc/testsuite/gcc.dg/Wno-frame-address.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/tes
On 5/3/22 13:40, Patrick Palka wrote:
Here, since finish_non_static_data_member isn't SFINAE friendly, we
incorrectly emit an error during overload resolution:
sfinae33.C: In substitution of ‘template A f() [with T = B]’:
sfinae33.C:11:7: required from here
sfinae33.C:5:31: error: invalid use
Current host tools mark some additional symbols as 'no dead strip' and also
expose one additional group to the linker. This does not affect older Darwin
versions or x86_64, but omitting these changes results in link errors for
aarch64.
Tested on i686, x86_64 and a cross to aarch64 Darwin.
pushed
On Tue, 3 May 2022, 18:26 Alexandre Oliva, wrote:
> On May 3, 2022, Jonathan Wakely wrote:
>
> > That macro should start with two underscores.
>
> Doh! Wow, eagle eyes! :-) Good catch, thanks!
>
> Here's the corrected patch I'm installing, trunk for now, 12 and 11 once
> it's allowed in 12.
Here, since finish_non_static_data_member isn't SFINAE friendly, we
incorrectly emit an error during overload resolution:
sfinae33.C: In substitution of ‘template A f() [with T = B]’:
sfinae33.C:11:7: required from here
sfinae33.C:5:31: error: invalid use of non-static data member ‘B::value’
Hi,
This patches merges the D front-end with upstream dmd 081d61e15, and the
the standard library with druntime 9c0d4f91 and phobos dba1bbe27.
Synchronizing the latest bug fixes in the upcoming v2.100 release.
D front-end changes:
- Import dmd v2.100.0-rc.1.
D runtime changes:
- Impor
On May 3, 2022, Jonathan Wakely wrote:
> That macro should start with two underscores.
Doh! Wow, eagle eyes! :-) Good catch, thanks!
Here's the corrected patch I'm installing, trunk for now, 12 and 11 once
it's allowed in 12.
> OK for trunk and gcc-11 with that change.
> gcc-12 branch nee
Optimize _mm_storeu_si16 to use MOVD from a SSE to an integer register
instead of PEXTRW from a low word of the SSE register to an integer reg.
Avoid the transformation when optimizing for size for targets without
TARGET_INTER_UNIT_MOVES_FROM_VEC capability, where the transformation
results in two
Hi Sebastian,
> Please find attached the patch amended following your recommendations.
> The number of new functions for _sync is reduced by 3x.
> I tested the patch on Graviton2 aarch64-linux.
> I also checked by hand that the outline functions in libgcc look similar to
> what GCC produces for t
On 4/29/2022 5:44 PM, Palmer Dabbelt wrote:
Some tests check for fenv and then proceed to use fesetround() directly,
but some platforms (at least RISC-V soft-float) have fenv but don't
support rounding modes. This adds a DG check that fesetround() actually
functions, which is then used by all
On 5/3/2022 9:11 AM, Jeff Law wrote:
On 1/5/2022 6:23 AM, Martin Liška wrote:
Hi.
The second patch brings us closer to C++. I used some libiberty macros
and changed signed/unsigned integer types.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed
On 5/3/2022 8:04 AM, Martin Liška wrote:
This is a follow up patch of something I sent last stage1.
I'm not planning moving to C++, but I would like to see this patch
go in.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
include/
On 1/5/2022 6:23 AM, Martin Liška wrote:
Hi.
The second patch brings us closer to C++. I used some libiberty macros
and changed signed/unsigned integer types.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
OK. And I think similar patches elsew
This is a follow up patch of something I sent last stage1.
I'm not planning moving to C++, but I would like to see this patch
go in.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
include/ChangeLog:
* plugin-api.h (enum ld_pl
On Tue, May 3, 2022 at 2:29 PM Thomas Schwinge wrote:
>
> Hi Richard!
>
> On 2022-05-03T12:53:50+0200, Richard Biener
> wrote:
> > On Tue, May 3, 2022 at 10:16 AM Thomas Schwinge
> > wrote:
> >> On 2022-05-03T09:17:52+0200, Richard Biener
> >> wrote:
> >> > On Mon, May 2, 2022 at 4:01 PM Tho
Prathamesh Kulkarni writes:
> On Tue, 4 Jan 2022 at 19:12, Richard Sandiford
> wrote:
>>
>> Richard Biener writes:
>> > On Tue, 4 Jan 2022, Richard Sandiford wrote:
>> >
>> >> Richard Biener writes:
>> >> > On Fri, 17 Dec 2021, Richard Sandiford wrote:
>> >> >
>> >> >> Prathamesh Kulkarni writ
On 5/3/2022 6:42 AM, Christophe Lyon via Gcc-patches wrote:
It seems the license header was omitted when dfp.m4 was originally
contributed in 2010 (commit 3c39bca6bbb5, r0-102573 or svn r163815.
This copies the license from libdecnumber/configure.ac since dfp.m4
was originally extracted from
It seems the license header was omitted when dfp.m4 was originally
contributed in 2010 (commit 3c39bca6bbb5, r0-102573 or svn r163815.
This copies the license from libdecnumber/configure.ac since dfp.m4
was originally extracted from that file.
2022-04-29 Christophe Lyon
config/
Hi Richard!
On 2022-05-03T12:53:50+0200, Richard Biener wrote:
> On Tue, May 3, 2022 at 10:16 AM Thomas Schwinge
> wrote:
>> On 2022-05-03T09:17:52+0200, Richard Biener
>> wrote:
>> > On Mon, May 2, 2022 at 4:01 PM Thomas Schwinge
>> > wrote:
>> >> On 2022-05-01T11:02:29+0100, Iain Sandoe v
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-05-03 Richard Biener
PR middle-end/105083
* tree-scalar-evolution.cc (scev_initialize): Verify we
have appropriate loop state.
* tree-ssa-dce.cc (perform_tree_ssa_dce): Re-order SCEV and
With inline atomics it should no longer be necessary to link -latomic
with -pthread.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On Tue, May 3, 2022 at 10:16 AM Thomas Schwinge wrote:
>
> Hi Richard!
>
> On 2022-05-03T09:17:52+0200, Richard Biener
> wrote:
> > On Mon, May 2, 2022 at 4:01 PM Thomas Schwinge
> > wrote:
> >> On 2022-05-01T11:02:29+0100, Iain Sandoe via Gcc wrote:
> >> >> On 29 Apr 2022, at 15:34, Jakub Je
On Tue, 4 Jan 2022 at 19:12, Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, 4 Jan 2022, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> > On Fri, 17 Dec 2021, Richard Sandiford wrote:
> >> >
> >> >> Prathamesh Kulkarni writes:
> >> >> > Hi,
> >> >> > The attached
On Mon, 27 Dec 2021 at 15:54, Prathamesh Kulkarni
wrote:
>
> On Fri, 17 Dec 2021 at 17:03, Richard Sandiford
> wrote:
> >
> > Prathamesh Kulkarni writes:
> > > Hi,
> > > The patch folds:
> > > lhs = svld1rq ({-1, -1, -1, ...}, &v[0])
> > > into:
> > > lhs = vec_perm_expr
> > > and expands above
Here are gmake check-gfortran results requested by FX.
Before patching:
=== gfortran Summary ===
# of expected passes65106
# of unexpected failures6
# of expected failures 262
# of unsupported tests 367
After patching:
=== gfo
The flag_var_tracking reset in finish_options doesn't match the
condition in process_options, in particular we fail to reset it
when the option was specified on the command line. The following
fixes this and also alters the debug info level guard to match
the one in process_options.
Bootstrapped
From: Piotr Kubaj
FreeBSD/powerpc* has feenableexcept() defined in fenv.h header.
Signed-off-by: Piotr Kubaj
---
libgfortran/configure| 41 +++-
libgfortran/configure.ac | 17 -
2 files changed, 56 insertions(+), 2 deletions(-)
diff --gi
When some code was moved from process_options to finish_options,
uses of OPTION_SET_P were not replaced with references to the
opts_set option set. The following fixes this.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
2022-05-03 Richard Biener
* opts.cc: #undef OPT
Hi Richard!
On 2022-05-03T09:17:52+0200, Richard Biener wrote:
> On Mon, May 2, 2022 at 4:01 PM Thomas Schwinge
> wrote:
>> On 2022-05-01T11:02:29+0100, Iain Sandoe via Gcc wrote:
>> >> On 29 Apr 2022, at 15:34, Jakub Jelinek via Gcc wrote:
>> >>
>> >> The first release candidate for GCC 12.1
On Sun, May 1, 2022 at 4:20 PM Sören Tempel wrote:
>
> Pinging this again. This time with i386 port maintainers in CC.
>
> Summary: The macro guards for TARGET_CAN_SPLIT_STACK on i386 are not
> aligned with the implementation of ix86_supports_split_stack. That is,
> on systems using musl libc ix86
On Mon, May 2, 2022 at 4:01 PM Thomas Schwinge wrote:
>
> Hi!
>
> On 2022-05-01T11:02:29+0100, Iain Sandoe via Gcc wrote:
> >> On 29 Apr 2022, at 15:34, Jakub Jelinek via Gcc wrote:
> >>
> >> The first release candidate for GCC 12.1 is available from
> >>
> >> https://gcc.gnu.org/pub/gcc/snapsho
On Tue, 3 May 2022, 06:39 Alexandre Oliva via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
>
> The floating-point overloads of from_char are only declared if
> _GLIBCXX_HAVE_USELOCALE is #defined as nonzero. That's exposed from
> charconv as _cpp_lib_to_chars >= 201611L, so guard the test body with
49 matches
Mail list logo
