Thank you for your suggestions. Looks like I have pasted the wrong test case.
I'm sorry for that.
I have modified accordingly and changed to use the correct test now in my new
patch.
I have carried a full test, no new failure witnessed. Newly added test fail
without the patch and pass aft
get_range_strlen() returns non-constant type sizes for VLAs that
the new get_range_strlen_dynamic() function isn't prepared to deal
with and ICEs. Extending the functions to deal with VLAs (and
other dynamically allocated objects) is on my list of things to
do for GCC 11. For GCC 10, the attache
On 3/14/20 8:05 PM, Alexey Neyman wrote:
+ if (debug_info_level > DINFO_LEVEL_TERSE) {
{ goes on the next line.
It looks like you don't have commit access, so I committed the patch
with that change.
Thanks,
Jason
The _Tgt and _TgtImpl types that implement type-erasure didn't agree on
the virtual interface, so failed as soon as they were instantiated. With
Clang they failed even sooner. The interface was also dependent on
whether RTTI was enabled or not.
This patch fixes the broken virtual functions and mak
> Hi.
>
> There's updated version of the patch.
> Changes from the previous version:
> - comment added to ld_plugin_symbol
> - new section renamed to ext_symtab
> - assert added for loop iterations in produce_symtab and
> produce_symtab_extension
Hi,
I hope this is last version of the patch.
>
>
On 3/17/20 9:46 AM, Martin Liška wrote:
Hi.
The patch is about better sanity check in option generation script.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed in stage1?
@@ -72,6 +72,19 @@ function opt_args(name, flags)
return flags
}
+
2020-03-17 Uroš Bizjak
* g++.dg/debug/dwarf2/const2b.C (dg-do): Fix target selector.
Tested on x86_64-linux-gnu {,-m32}.
Uros.
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/const2b.C
b/gcc/testsuite/g++.dg/debug/dwarf2/const2b.C
index 3ad1c080945..681ad721dd7 100644
--- a/gcc/testsuite/
On Fri, 28 Feb 2020, H.J. Lu wrote:
> > > > However that hack has been actually made to address this very problem
> > > > discussed with this submission, so why not simply sync our copy of
> > > > libffi
> > > > with the upstream version? Then we can decide if changing the hack into
> > > > som
On Tue, 18 Feb 2020, Kito Cheng wrote:
> - fmv.x.s/fmv.s.x renamed to fmv.x.w/fmv.w.x in the latest RISC-V ISA
>manual.
The new mnemonics have been supported by GAS for a little while now and
the old ones have been retained, however this is still a change that
breaks backwards compatibili
On 3/17/20 5:06 PM, Jakub Jelinek wrote:
On Tue, Mar 17, 2020 at 03:54:57PM -0400, Jason Merrill via Gcc-patches wrote:
How about always diagnosing this here, and moving the deduction guide code
in grokfndecl up above set_decl_namespace to avoid a duplicate diagnostic?
I've tried that as:
---
On Tue, 17 Mar 2020, Martin Liška wrote:
> Hi.
>
> The patch is about better sanity check in option generation script.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed in stage1?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, 17 Mar 2020, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The following testcases ICE, because they contain extern variable
> declarations with incomplete enum types that is later completed and after
> that those variables are accessed. The ICEs are because the vars then may
> have
>
On 3/16/20 1:39 PM, Patrick Palka wrote:
In this PR, we are performing constexpr evaluation of a CONSTRUCTOR of type
union U which looks like
{.a=foo (&)}.
Since the function foo takes a reference to the CONSTRUCTOR we're building, it
could potentially modify the CONSTRUCTOR from under us.
On Tue, Mar 17, 2020 at 03:54:57PM -0400, Jason Merrill via Gcc-patches wrote:
> How about always diagnosing this here, and moving the deduction guide code
> in grokfndecl up above set_decl_namespace to avoid a duplicate diagnostic?
I've tried that as:
--- gcc/cp/decl.c.jj2020-03-16 22:56:46.7
Hi Iain,
> When generating thunks in the D front-end, they need not necesarily be
> in the same compilation unit as the module where the target function is
> declared. When this happens, don't make the thunk public. Later on
> expand_thunk will be called with force_gimple_thunk=true, so the thun
Updated patch attached, addresses some minor issues I found after
sending the original version.
>From 0c677da72a058e37d0ea1975dc70e53c4308963c Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Thu, 12 Mar 2020 17:50:09 -0700
Subject: [PATCH] Add C++2a wait/notify_one/notify_all support to std::a
On 3/16/20 10:01 PM, Marek Polacek wrote:
On Mon, Mar 16, 2020 at 05:12:15PM -0400, Jason Merrill wrote:
On 3/16/20 10:57 AM, Marek Polacek wrote:
Now that convert_like creates an IMPLICIT_CONV_EXPR when it converts
something that involves a class in a template, we must be prepared to
handle it
On 3/17/20 4:28 AM, Jakub Jelinek wrote:
On Mon, Mar 16, 2020 at 06:01:25PM -0400, Jason Merrill wrote:
- type = NULL_TREE;
- goto out;
+ error_at (cp_lexer_peek_token (parser->lexer)->location,
+ "expected %<;%> or %<{%>");
+
On 3/17/20 4:49 AM, Jakub Jelinek wrote:
Hi!
The following testcase is accepts-invalid since r7-6608-ga56c0ac08242269b.
Before that change we had this
"deduction guide %qD must be declared in the same scope as %qT"
diagnostics for it, after the change it is expected to be diagnosed
in set_decl_n
On 3/17/20 11:25 AM, Ville Voutilainen wrote:
On Tue, 17 Mar 2020 at 16:52, Ville Voutilainen
wrote:
On Tue, 17 Mar 2020 at 16:42, Jason Merrill wrote:
On 3/17/20 9:04 AM, Jonathan Wakely wrote:
On 17/03/20 13:02 +, Jonathan Wakely wrote:
Shouldn't the test use { dg-do compile { targe
In g:2171a9207f51bc486ed9c502cb4da706f594615e I'd tried to fix
various ILP32 testsuite failures by restricting some tests to LP64.
Unfortunately, I messed up the check-function-bodies syntax and passed
the target selector as the "option" parameter, which had the effect of
disabling the tests for bo
Tested on aarch64-linux-gnu and aarch64_be-elf, pushed.
Richard
2020-03-17 Richard Sandiford
gcc/testsuite/
* gcc.target/aarch64/advsimd-intrinsics/bfcvt-nosimd.c: Skip for
-fno-fat-lto-objects. Use tabs rather than spaces in the
check-function-bodies code.
---
.../
gcc.target/aarch64/advsimd-intrinsics/bf16_vldn.c and
gcc.target/aarch64/advsimd-intrinsics/bf16_vstn.c were
failing for big-endian targets because the in
aarch64_be_ld1 and aarch64_be_st1 had no
expansion for the bfloat16 modes.
Tested on aarch64-linux-gnu and aarch64_be-elf, pushed.
Richard
Hi!
I've backported 14 commits from trunk to 9.3.1, bootstrapped/regtested
on x86_64-linux and i686-linux and committed to 9 branch.
Jakub
>From 5de0dc84c75a43f78a03c7cdb7e7c443c641a7fa Mon Sep 17 00:00:00 2001
From: Jakub Jelinek
Date: Wed, 4 Mar 2020 09:01:59 +0100
Subject: [PATCH] tai
t-seg-refs -mvzeroupper -mxsave -mxsavec -mxsaveopt -mxsaves
AFTER:
# GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
# GNU C17 10.0.1 20200317 (experimental) -march=znver1 -mmmx
-mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe
-maes -msha -mpclmul -mpopcnt
Hi all,
This patch introduces the scalar CDE (Custom Datapath Extension) intrinsics for
the arm backend.
There is nothing beyond the standard in this patch. We simply build upon what
has been done by Dennis for the vector intrinsics
(https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542008.
On 1/23/20 2:09 PM, Richard Biener wrote:
The other thing looks like sth for next stage1?
Hi.
I'm sending the second part for next stage1.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed in next stage1?
Thanks,
Martin
>From 6d2113da263d7a6a0bb0a
Hi,
As Bin noticed, invocations of the coro-torture.exp like
'coro-torture.exp=some-test.C’
were failing because DEFAULT_CXXFLAGS was undefined. Fixed by defining this
locally, if it has no pre-existing global value.
tested on x86_64-darwin, applied to mainline as obvious.
thanks
Iain
diff --g
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 16 March 2020 12:01
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][1/3x]: MVE intrinsics with ternary operands.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v1.
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 10 March 2020 18:23
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][5/2x]: MVE intrinsics with binary operands.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v1.
>
Hi.
The patch is about better sanity check in option generation script.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed in stage1?
Thanks,
Martin
gcc/ChangeLog:
2020-03-17 Martin Liska
* opt-functions.awk (opt_args_non_empty): New funct
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 10 March 2020 18:23
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][4/2x]: MVE intrinsics with binary operands.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v1.
>
Hello,
On Mon, 16 Mar 2020, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Mon, Mar 16, 2020 at 05:47:03PM +, Richard Sandiford wrote:
> >> Segher Boessenkool writes:
> >> >> we do delete "x = 1" for f1. I think that's the expected behaviour.
> >> >> We don't yet delete the
On Tue, 17 Mar 2020 at 16:52, Ville Voutilainen
wrote:
>
> On Tue, 17 Mar 2020 at 16:42, Jason Merrill wrote:
> >
> > On 3/17/20 9:04 AM, Jonathan Wakely wrote:
> > > On 17/03/20 13:02 +, Jonathan Wakely wrote:
> > >> Shouldn't the test use { dg-do compile { target c++11 } } instead of:
> > >
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 10 March 2020 18:23
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][3/2x]: MVE intrinsics with binary operands.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v1.
>
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 10 March 2020 18:22
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][2/2x]: MVE intrinsics with binary operands.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v1.
>
On 3/17/20 2:39 AM, Jakub Jelinek wrote:
Hi!
The gcc.dg/pr68785.c test which contains:
int
foo (void)
{
return *(int *) "";
}
has UB in the program if it is ever called, but causes UB in the compiler
as well as at least in theory non-reproduceable code generation.
The problem is that nbytes i
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 10 March 2020 18:22
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][1/2x]: MVE intrinsics with binary operands.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v1.
>
On 17/03/2020 12:34, Wilco Dijkstra wrote:
Hi Andrea,
I think the first part is fine when approved, but the 2nd part is problematic
like Szabolcs
already pointed out. We can't just change the ABI or semantics, and these
builtins are critical
for GLIBC performance. We would first need to change
On Tue, 17 Mar 2020 at 16:42, Jason Merrill wrote:
>
> On 3/17/20 9:04 AM, Jonathan Wakely wrote:
> > On 17/03/20 13:02 +, Jonathan Wakely wrote:
> >> Shouldn't the test use { dg-do compile { target c++11 } } instead of:
> >>
> >> +// { dg-do compile }
> >> +// { dg-options "-std=c++11" }
>
>
On 3/17/20 9:04 AM, Jonathan Wakely wrote:
On 17/03/20 13:02 +, Jonathan Wakely wrote:
Shouldn't the test use { dg-do compile { target c++11 } } instead of:
+// { dg-do compile }
+// { dg-options "-std=c++11" }
?
With that change I see:
UNSUPPORTED: g++.dg/ext/pr94197.C -std=c++98
PAS
This adds a missing type conversion to build_fold_addr_expr and adjusts
fallout - build_fold_addr_expr was used as a convenience to build an
ADDR_EXPR but some callers do not expect the result to be simplified
to something else.
Bootstrapped on x86_64-unknown-linux-gnu, testin in progress.
This
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 10 March 2020 18:21
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][4/1x]: MVE intrinsics with unary operand.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v1.
> (
stics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
# GNU C17 10.0.1 20200317 (experimental) -march=znver1 -mmmx -mno-3dnow -msse
-msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe -maes -msha -mpclmul
-mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx -mbmi2
-mno-pconfig
Hi Srinath,
Thanks, I've pushed this patch to master.
Kyrill
-Original Message-
From: Srinath Parvathaneni
Sent: 10 March 2020 18:21
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov
Subject: [PATCH v2][ARM][GCC][3/1x]: MVE intrinsics with unary operand.
Hello Kyrill,
Following patch i
On Mon, 16 Mar 2020 at 19:59, Richard Sandiford
wrote:
>
> Christophe Lyon via Gcc-patches writes:
> > On Wed, 11 Mar 2020 at 00:37, Joseph Myers wrote:
> >>
> >> On Tue, 10 Mar 2020, Christophe Lyon wrote:
> >>
> >> > sizeless-1.c and sizeless-2.c have the same code, but the latter is
> >> > co
On 17/03/20 13:02 +, Jonathan Wakely wrote:
Shouldn't the test use { dg-do compile { target c++11 } } instead of:
+// { dg-do compile }
+// { dg-options "-std=c++11" }
?
With that change I see:
UNSUPPORTED: g++.dg/ext/pr94197.C -std=c++98
PASS: g++.dg/ext/pr94197.C -std=c++14 (test fo
Shouldn't the test use { dg-do compile { target c++11 } } instead of:
+// { dg-do compile }
+// { dg-options "-std=c++11" }
?
On Tue, Mar 17, 2020 at 10:37 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> In the r10-7197-gbae7b38cf8a21e068ad5c0bab089dedb78af3346 commit I've
> noticed duplicated word in a message, which lead me to grep for those and
> we have a tons of them.
> I've used
> grep -v 'long long\|optab opta
Hi Andrea,
I think the first part is fine when approved, but the 2nd part is problematic
like Szabolcs
already pointed out. We can't just change the ABI or semantics, and these
builtins are critical
for GLIBC performance. We would first need to change GLIBC back to using inline
assembler
so it
On Tue, 17 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping this patch again:
OK.
Thanks,
Richard.
> On Tue, Mar 10, 2020 at 01:28:19PM +0100, Jakub Jelinek wrote:
> > I'd like to ping the
> > https://gcc.gnu.org/legacy-ml/gcc-patches/2020-03/msg00154.html
> > P1 PR94015
> > patch,
Hi!
I'd like to ping this patch again:
On Tue, Mar 10, 2020 at 01:28:19PM +0100, Jakub Jelinek wrote:
> I'd like to ping the
> https://gcc.gnu.org/legacy-ml/gcc-patches/2020-03/msg00154.html
> P1 PR94015
> patch, with the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94015#c5
> testcase instead
Hi Srinath,
Thanks, I've pushed this to master.
Kyrill
-Original Message-
From: Srinath Parvathaneni
Sent: 10 March 2020 18:21
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov
Subject: [PATCH v2][ARM][GCC][2/1x]: MVE intrinsics with unary operand.
Hello Kyrill,
Following patch is the
On Mon, 16 Mar 2020 at 18:41, Kyrylo Tkachov wrote:
>
> Hi Srinath,
>
> I've pushed the first three of the patches for you to master:
> [ARM][GCC][3/x]: MVE ACLE intrinsics framework patch.
> [ARM][GCC][2/x]: MVE ACLE intrinsics framework patch.
> [ARM][GCC][1/x]: MVE ACLE intrinsics framework pat
Hi Srinath,
Thanks, I've pushed this to master.
Kyrill
-Original Message-
From: Srinath Parvathaneni
Sent: 10 March 2020 18:21
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov
Subject: [PATCH v2][ARM][GCC][1/1x]: Patch to support MVE ACLE intrinsics with
unary operand.
Hello Kyrill,
Hi Srinath,
Thanks, I've pushed this to master.
Kyrill
-Original Message-
From: Srinath Parvathaneni
Sent: 10 March 2020 18:21
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov
Subject: [PATCH v2][ARM][GCC][1/1x]: Patch to support MVE ACLE intrinsics with
unary operand.
Hello Kyrill,
Lewis Hyatt writes:
> On Mon, Mar 16, 2020 at 06:11:08PM +, Richard Sandiford wrote:
>> Lewis Hyatt via Gcc-patches writes:
> ...
>> > FWIW there are three other options currently affected by this change
>> > (-Wimplicit-fallthrough, -fcf-protection, and -flive-patching). The change
>> > for
On 17/03/20 12:01 +0100, Christophe Lyon wrote:
Hi,
On Mon, 16 Mar 2020 at 23:54, Jonathan Wakely via Gcc-patches
wrote:
The service_already_exists exception type specified in the TS doesn't
have any constructors defined. Since its base class isn't default
constructible, that means has no us
Hi Srinath,
Thanks, I've pushed this to master.
Kyrill
-Original Message-
From: Srinath Parvathaneni
Sent: 10 March 2020 18:20
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov
Subject: [PATCH v2][ARM][GCC][4/x]: MVE ACLE vector interleaving store
intrinsics.
Hello Kyrill,
Following pa
Hi,
On Mon, 16 Mar 2020 at 23:54, Jonathan Wakely via Gcc-patches
wrote:
>
> The service_already_exists exception type specified in the TS doesn't
> have any constructors defined. Since its base class isn't default
> constructible, that means has no usable constructors. This may be a
> defect in
Andrea Corallo writes:
> Hi all,
>
> second and last patch of the two reworking FPCR and FPSR builtins.
>
> This rework __builtin_aarch64_set_fpcr (unsigned) and
> __builtin_aarch64_set_fpsr (unsigned) to emit a read-modify-sequences
> as:
>
> mrs x1, fpsr
> bfi x1, x0,
"duanbo (C)" writes:
> Hi
> The testcase pr78255.c triggers ice when testing GCC trunk on aarch64 with
> -mabi=ilp32 -fPIC.
> Case path: gcc/testsuite/gcc.target/aarch64/pr78255.c
>
> The ICE is caused by insufficient support for the tiny code model under ilp32
> mode with fPIC option, where a
Hi!
On Mon, Mar 16, 2020 at 04:47:05PM -0400, Vladimir Makarov via Gcc-patches
wrote:
> The following committed patch solves
I'm getting on i686-linux
FAIL: g++.target/i386/pr94185.C -std=gnu++98 (test for excess errors)
This is because of a diagnostic that 4294967295 is unsigned only in ISO
On Mon, 16 Mar 2020 at 19:59, Richard Sandiford
wrote:
>
> Christophe Lyon via Gcc-patches writes:
> > On Wed, 11 Mar 2020 at 00:37, Joseph Myers wrote:
> >>
> >> On Tue, 10 Mar 2020, Christophe Lyon wrote:
> >>
> >> > sizeless-1.c and sizeless-2.c have the same code, but the latter is
> >> > co
On Tue, Mar 17, 2020 at 10:40:00AM +0100, Uros Bizjak via Gcc-patches wrote:
> (define_split
> [(set (match_operand:DI 0 "memory_operand")
> (zero_extend:DI (match_operand:SI 1 "memory_operand")))]
> "reload_completed"
> [(set (match_dup 4) (const_int 0))]
> "split_double_mode (DIm
>The following committed patch solves
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94185
>
>The patch was successfully bootstrapped and tested on x86-64.
This patch creates unoptimal sequence in reload:
(insn 64 63 248 10 (set (reg:DI 0 ax [161])
(zero_extend:DI (mem/c:SI (plu
Hi!
In the r10-7197-gbae7b38cf8a21e068ad5c0bab089dedb78af3346 commit I've
noticed duplicated word in a message, which lead me to grep for those and
we have a tons of them.
I've used
grep -v 'long long\|optab optab\|template template\|double double' *.[chS]
*/*.[chS] *.def config/*/* 2>/dev/null |
On Tue, Mar 17, 2020 at 9:40 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> The gcc.dg/pr68785.c test which contains:
> int
> foo (void)
> {
> return *(int *) "";
> }
> has UB in the program if it is ever called, but causes UB in the compiler
> as well as at least in theory non-reproduceabl
On Tue, Mar 17, 2020 at 9:35 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> The following testcase FAILs with -O2 -fcompare-debug, but the reason isn't
> that we'd emit different code based on -g or non-debug, but rather that
> we emit different code depending on whether -w is used or not (or
Hi!
The following testcases ICE, because they contain extern variable
declarations with incomplete enum types that is later completed and after
that those variables are accessed. The ICEs are because the vars then may have
incorrect DECL_MODE etc., e.g. in the first case the var has SImode
DECL_M
Hi!
The following testcase is accepts-invalid since r7-6608-ga56c0ac08242269b.
Before that change we had this
"deduction guide %qD must be declared in the same scope as %qT"
diagnostics for it, after the change it is expected to be diagnosed
in set_decl_namespace at the not_found: label in there.
Seems to me obvious, installed as ecf2b69a629d4f79efe3c103fe54040437ea18a6.
Martin
Hi!
The gcc.dg/pr68785.c test which contains:
int
foo (void)
{
return *(int *) "";
}
has UB in the program if it is ever called, but causes UB in the compiler
as well as at least in theory non-reproduceable code generation.
The problem is that nbytes is in this case 4, prep is the
TREE_STRING_PO
Hi!
The following testcase FAILs with -O2 -fcompare-debug, but the reason isn't
that we'd emit different code based on -g or non-debug, but rather that
we emit different code depending on whether -w is used or not (or e.g.
-Wno-stringop-overflow or whether some other pass emitted some other warnin
On Mon, Mar 16, 2020 at 06:01:25PM -0400, Jason Merrill wrote:
> > - type = NULL_TREE;
> > - goto out;
> > + error_at (cp_lexer_peek_token (parser->lexer)->location,
> > + "expected %<;%> or %<{%>");
> > + return NULL_TREE;
>
> Hmm, what happens if
75 matches
Mail list logo
