On Fri, Mar 15, 2019 at 9:46 PM Jakub Jelinek wrote:
>
> Hi!
>
> As the enhanced testcase shows, ix86_expand_floorceildf_32 doesn't emit
> correct ceil when honoring signed zeros, because it performs copysign,
> then comparison and then based on the comparison an optional addition of 1.
> The comm
On Tue, Mar 12, 2019 at 12:43:29PM +0100, Jakub Jelinek wrote:
> On Mon, Mar 04, 2019 at 10:04:01AM +0100, Jakub Jelinek wrote:
> > The first one uses constraints and no C code in the output, I believe it is
> > actually more expensive for compile time, because if one just reads what
> > constrain_
On Mon, 18 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> For input arguments, we do:
> /* If we can't make copies, we can only accept memory. */
> if (TREE_ADDRESSABLE (TREE_TYPE (TREE_VALUE (link
> {
> if (allows_mem)
> allows_reg = 0;
> else
>
On Mon, 18 Mar 2019, Jan Hubicka wrote:
> Hi,
> these two PRs are about C++ destructors that are not virtual but have
> virtual alias. The devirtualization machinery walks from alias to symbol
> and is then confused by not knowing the class symbol belongs to.
>
> I think it would make more sense
Hi.
When calling set_even_probabilities, the function assumes that an edge
can't live in both sets ({un,}likely_edges). When such situation happens,
clear just the sets.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
On Mon, 18 Mar 2019, Michael Matz wrote:
> Hi,
>
> On Mon, 18 Mar 2019, Richard Biener wrote:
>
> > > Or, because an enum with these properties could be modelled as a struct
> > > containing one member of basetype you could also change
> > > record_component_aliases(), though that doesn't allo
On Mon, Mar 18, 2019 at 10:31 PM Jeff Law wrote:
>
> On 3/18/19 1:03 PM, Martin Sebor wrote:
> > I the -Warray-bounds enhancement committed at the beginning
> > of the GCC 9 window I tried to correctly handle offsets in
> > MEM_REFs in the [max, min] kind of a range after converting
> > from sizet
From: Mingli Yu
Initialize st_mode member to fix the below
build failure when -Og included in compiler flag.
|
./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:
In function 'elf_is_symlink':
|
../../../../../../../../../work-shared
Bernhard Reutner-Fischer writes:
> On 18 March 2019 10:58:53 CET, Richard Sandiford
> wrote:
>>This patch fixes a case in which we vectorised something with a
>>fully-predicated loop even after the cost model had rejected it.
>>E.g. the loop in the testcase has the costs:
>>
>> Vector inside of
On 3/19/19 3:46 AM, Alex Henrie wrote:
> Hello,
>
> I have received permission to contribute to GCC, but I do not have
> commit access. Could one of you please merge these patches for me?
Hi.
I can do it for you. But if I see correctly, Joseph M. had some concerns
and he should probably make fin
Hi,
On Tue, 19 Mar 2019, Richard Biener wrote:
> It doesn't really. Consider the following IMHO valid testcase:
>
> enum X { A, B };
> enum Y { C, D };
> void foo (int *p)
> {
> *(enum X *)p = A;
> *(enum Y *)p = D;
> return *(enum X *)p;
> }
>
> int main()
> {
> int storage;
> if (foo
* doc/xml/manual/allocator.xml: Link to table documenting evolution
of extension allocators.
* doc/xml/manual/evolution.xml: Use angle brackets for header names.
Document new headers in 7.2, 8.1 and 9.1 releases.
* doc/xml/manual/using.xml: Adjust link targe
On Mon, Mar 18, 2019 at 06:35:12PM -0600, James Hilliard wrote:
> On Mon, Mar 18, 2019 at 5:46 PM Jeff Law wrote:
> >
> > On 3/18/19 5:07 PM, James Hilliard wrote:
> > > On Mon, Mar 18, 2019 at 4:51 PM Jakub Jelinek wrote:
> > >>
> > >> On Mon, Mar 18, 2019 at 04:41:05PM -0600, James Hilliard wro
On 04/03/2019 09:04, Jakub Jelinek wrote:
> On Fri, Mar 01, 2019 at 03:41:33PM +, Wilco Dijkstra wrote:
>> > and regtest revealed two code size
>> > regressions because of that. Is -1 vs. 1 the only case of immediate
>> > valid for both "I" and "L" constraints where the former is longer than t
On Tue, Mar 19, 2019 at 3:56 AM Jakub Jelinek wrote:
>
> On Mon, Mar 18, 2019 at 06:35:12PM -0600, James Hilliard wrote:
> > On Mon, Mar 18, 2019 at 5:46 PM Jeff Law wrote:
> > >
> > > On 3/18/19 5:07 PM, James Hilliard wrote:
> > > > On Mon, Mar 18, 2019 at 4:51 PM Jakub Jelinek wrote:
> > > >>
The following ignores -gsplit-dwarf when doing LTO since its model
seems to be fundamentally incompatible, see my last comment in the
now suspended PR.
Bootstrap & regtest running on x86_64-unknown-linux-gnu, I'll apply
this to trunk and GCC 8 branch.
Richard.
2019-03-19 Richard Biener
On Tue, 19 Mar 2019, Michael Matz wrote:
> Hi,
>
> On Tue, 19 Mar 2019, Richard Biener wrote:
>
> > It doesn't really. Consider the following IMHO valid testcase:
> >
> > enum X { A, B };
> > enum Y { C, D };
> > void foo (int *p)
> > {
> > *(enum X *)p = A;
> > *(enum Y *)p = D;
> > return
On Tue, 19 Mar 2019 08:47:49 +
Richard Sandiford wrote:
> > ... this identical condition, AFAICS?
> > So this second conditions else arm should be dead, shouldn't it?
>
> Yeah, that's what:
>
> /* ??? The "if" arm is written to handle all cases; see below for what
> we would do for
Hi,
> Alignment is written to TypeInfo, I don't think it should ever be
> zero. That would mean that it isn't being generated by the compiler,
> or read by the library correctly, so something else is amiss.
it took me a while to see that in libphobos/libdruntime/object.d
override @property siz
On March 19, 2019 1:07:26 PM GMT+01:00, Robin Dapp wrote:
>Hi,
>
>> Alignment is written to TypeInfo, I don't think it should ever be
>> zero. That would mean that it isn't being generated by the compiler,
>> or read by the library correctly, so something else is amiss.
>
>it took me a while to s
On Tue, 19 Mar 2019 at 13:07, Robin Dapp wrote:
>
> Hi,
>
> > Alignment is written to TypeInfo, I don't think it should ever be
> > zero. That would mean that it isn't being generated by the compiler,
> > or read by the library correctly, so something else is amiss.
>
> it took me a while to see
Hi,
I'd like to ping for this patch:
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00438.html
Thanks
Bernd.
On 3/10/19 10:42 AM, Bernd Edlinger wrote:
> Hi,
>
> This patch is an update to the previous patch, which takes into account that
> the middle-end is not supposed to use the unaligned DI
This patch by Clément Chigot fixes the AIX support after the update to
Go 1.12. Bootstrapped and ran Go tests on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revi
A recently added test was observed to fail when compiled without the -mvsx
option. This patch adds -mvsx to the dg-options directive.
Was boostrapped and regression tested on powerpc-linux (P7 big-endian, both
-m32 and -m64).
Was preapproved by seg...@gcc.gnu.org and has been merged with trunk
On 3/11/19 8:27 PM, Martin Sebor wrote:
> The -Wstringop-truncation handling for strncpy/stpncpy neglects
> to consider that character arrays tracked by the strlen pass
> are not necessarily nul-terminated. It unconditionally adds
> one when computing the size of each sequence to account for
> the
On 3/8/19 5:34 AM, Martin Liška wrote:
> A small patch that deals with:
> gcc/config/i386/i386.c:39427:11:Semantic Issue: comparison of two values with
> different enumeration types in switch statement ('enum built_in_function' and
> 'ix86_builtins'): -Wenum-compare-switch
>
> Is it fine to inst
On 3/19/19 2:02 AM, Martin Liška wrote:
> Hi.
>
> When calling set_even_probabilities, the function assumes that an edge
> can't live in both sets ({un,}likely_edges). When such situation happens,
> clear just the sets.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
On 3/14/19 7:52 AM, Jakub Jelinek wrote:
> Hi!
>
> On the gcc.dg/vect/pr88598-3.c testcase, gen_vec_extract... is called with
> operands[1] that is already a subreg - (subreg:V4SF (reg:V4SI 201 [ _31 ]) 0)
> and wraps it in another SUBREG, which is invalid in RTL.
>
> In all the following 4 spots
On 3/14/19 4:43 AM, Richard Biener wrote:
> On Wed, 13 Mar 2019, Richard Biener wrote:
>
>> On Wed, 13 Mar 2019, Bin.Cheng wrote:
>>
>>> On Wed, Mar 13, 2019 at 3:58 AM Richard Biener wrote:
This makes an attempt at fixing the most annoying parts of the GIMPLE
FE unit testing
> On 3/19/19 2:02 AM, Martin Liška wrote:
> > Hi.
> >
> > When calling set_even_probabilities, the function assumes that an edge
> > can't live in both sets ({un,}likely_edges). When such situation happens,
> > clear just the sets.
> >
> > Patch can bootstrap on x86_64-linux-gnu and survives regr
On Tue, Mar 19, 2019 at 09:02:27AM +0100, Martin Liška wrote:
> 2019-03-18 Martin Liska
>
> PR middle-end/89737
> * predict.c (combine_predictions_for_bb): Empty likely_edges and
> unlikely_edges if there's an edge that belongs to both these sets.
I admit I don't know this co
On 3/18/19 10:31 PM, JonY wrote:
> On 3/3/19 10:41 AM, Johannes Pfau wrote:
>> We set __USE_MINGW_ACCESS for windows hosts to use MinGWs wrapper
>> for the access function. The wrapper ensures that access behaves
>> in the expected way (e.g. for special files, such as nul).
>> However, we now compi
On Tue, 19 Mar 2019, Martin Liška wrote:
> On 3/19/19 3:46 AM, Alex Henrie wrote:
> > Hello,
> >
> > I have received permission to contribute to GCC, but I do not have
> > commit access. Could one of you please merge these patches for me?
>
> Hi.
>
> I can do it for you. But if I see correctly,
* Florian Weimer:
> * Jeff Law:
>
>> On 03/29/2018 08:00 AM, Florian Weimer wrote:
>>> This patch performs lazy initialization of the relevant CPUID feature
>>> register value. It will needlessly invoke the CPUID determination code
>>> on architectures which lack CPUID support or support for the
> This would mean that StructFlags and ClassFlags will also both have a
> wrong value as well.
Yes, can confirm that m_flags = 0 (instead of 1) for a struct containing
a pointer.
> If there's a compiler/library discrepancy, the compiler should be
> adjusted to write out the value at the correct s
On Thu, Mar 14, 2019 at 04:22:41PM -0400, Jason Merrill wrote:
> On 3/7/19 4:52 PM, Marek Polacek wrote:
> > This was one of those PRs where the more you poke, the more ICEs turn up.
> > This patch fixes the ones I could find. The original problem was that
> > maybe_instantiate_noexcept got a TEMP
Ping?
> On 5 Mar 2019, at 20:43, Simon Wright wrote:
>
> Arno,
>
> OK.
>
> --S
>
>> On 5 Mar 2019, at 20:38, Arnaud Charlet wrote:
>>
>> Simon,
>>
>> Thanks for the patch.
>> We already have a fix pending for that in our tree that we will merge.
>>
>> Arno
>>
>>> On 4 Mar 2019, at 20:48,
The "classic" PowerPCs (6xx/7xx) are not STRICT_ALIGNMENT, but their
floating point units are. This is not normally a problem, the ABIs
make everything FP aligned. The RTL patterns converting FP to integer
however get a potentially unaligned destination, and we do not want to
do an stfiwx on that
On Tue, Mar 19, 2019 at 3:19 AM Martin Liška wrote:
>
> On 3/19/19 3:46 AM, Alex Henrie wrote:
> > Hello,
> >
> > I have received permission to contribute to GCC, but I do not have
> > commit access. Could one of you please merge these patches for me?
>
> Hi.
>
> I can do it for you. But if I see
On Tue, Mar 19, 2019 at 04:26:18PM +, Segher Boessenkool wrote:
> The "classic" PowerPCs (6xx/7xx) are not STRICT_ALIGNMENT, but their
> floating point units are. This is not normally a problem, the ABIs
> make everything FP aligned. The RTL patterns converting FP to integer
> however get a p
On 3/19/19 3:37 PM, Jeff Law wrote:
> On 3/8/19 5:34 AM, Martin Liška wrote:
>> A small patch that deals with:
>> gcc/config/i386/i386.c:39427:11:Semantic Issue: comparison of two values
>> with different enumeration types in switch statement ('enum
>> built_in_function' and 'ix86_builtins'): -We
On 3/19/19 5:35 PM, Alex Henrie wrote:
> On Tue, Mar 19, 2019 at 3:19 AM Martin Liška wrote:
>>
>> On 3/19/19 3:46 AM, Alex Henrie wrote:
>>> Hello,
>>>
>>> I have received permission to contribute to GCC, but I do not have
>>> commit access. Could one of you please merge these patches for me?
>>
On 3/19/19 3:52 PM, Jakub Jelinek wrote:
> On Tue, Mar 19, 2019 at 09:02:27AM +0100, Martin Liška wrote:
>> 2019-03-18 Martin Liska
>>
>> PR middle-end/89737
>> * predict.c (combine_predictions_for_bb): Empty likely_edges and
>> unlikely_edges if there's an edge that belongs to bo
On 3/18/19 8:46 PM, Alex Henrie wrote:
From: Manuel López-Ibáñez
* opts.c: Ignore -Wno-error= except if there are
other diagnostics.
---
gcc/opts-common.c | 2 ++
gcc/opts-global.c | 10 +++---
gcc/opts.c| 5 -
gcc/opts.h| 2 ++
4 files changed, 15 insertions(+)
On 2/25/19 2:07 AM, Eric Botcazou wrote:
> Hi,
>
> this is a regression present on the mainline and 8 branch, introduced by the
> new code in edge_info::derive_equivalences dealing with BIT_AND_EXPR for SSA
> names with boolean range:
>
> /* If either operand has a boolean range, th
Hi!
On the testcase in the PR we ICE because we create non-canonical CONST_INTs
(e.g. for HImode niter 0xfffe) and the compare_and_jump_seq code then ICEs
on that.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
Testcase not included, because it creates 48
Hi!
As mentioned in the PR, BLKmode operands (such as in the testcase C++
variables with TREE_ADDRESSABLE types) may only live in a MEM, trying to
reload those in a register will always ICE. process_alt_operands already
has if (mode == BLKmode) break; in it, so that it never claims a BLKmode
wins
On 3/19/19 8:33 AM, Jeff Law wrote:
On 3/11/19 8:27 PM, Martin Sebor wrote:
The -Wstringop-truncation handling for strncpy/stpncpy neglects
to consider that character arrays tracked by the strlen pass
are not necessarily nul-terminated. It unconditionally adds
one when computing the size of eac
Hi!
add_capture when parsing a lambda introducer uses the IDENTIFIER_MARKED
bit to detect duplicate captures.
I guess in strict C++11 that could have worked, if the introducer could
contain just identifiers, but in C++14 it has 2 problems:
1) lambda initializers can contain arbitrary expressions
On March 19, 2019 6:54:33 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>On the testcase in the PR we ICE because we create non-canonical
>CONST_INTs
>(e.g. for HImode niter 0xfffe) and the compare_and_jump_seq code then
>ICEs
>on that.
>
>Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-
On 2/22/19 9:42 AM, Marek Polacek wrote:
> On Thu, Feb 21, 2019 at 03:39:21PM -0700, Martin Sebor wrote:
>> On 2/21/19 1:27 PM, Jeff Law wrote:
>>> On 2/21/19 1:12 PM, Martin Sebor wrote:
On 2/21/19 12:08 PM, Jeff Law wrote:
> On 2/18/19 7:53 PM, Martin Sebor wrote:
>> Please let me kn
On 3/19/19 12:01 PM, Martin Sebor wrote:
On 3/19/19 8:33 AM, Jeff Law wrote:
On 3/11/19 8:27 PM, Martin Sebor wrote:
The -Wstringop-truncation handling for strncpy/stpncpy neglects
to consider that character arrays tracked by the strlen pass
are not necessarily nul-terminated. It unconditional
On 3/19/19 12:01 PM, Martin Sebor wrote:
> On 3/19/19 8:33 AM, Jeff Law wrote:
>> On 3/11/19 8:27 PM, Martin Sebor wrote:
>>> The -Wstringop-truncation handling for strncpy/stpncpy neglects
>>> to consider that character arrays tracked by the strlen pass
>>> are not necessarily nul-terminated. It
On 3/19/19 12:37 PM, Martin Sebor wrote:
> On 3/19/19 12:01 PM, Martin Sebor wrote:
>> On 3/19/19 8:33 AM, Jeff Law wrote:
>>> On 3/11/19 8:27 PM, Martin Sebor wrote:
The -Wstringop-truncation handling for strncpy/stpncpy neglects
to consider that character arrays tracked by the strlen pa
On 3/14/19 7:47 PM, Martin Sebor wrote:
> To copy type attributes from struct A, the copy attribute (new
> in GCC 9) accepts a pointer argument such as (struct A*)0, but
> it isn't prepared for anything much more complicated than that.
> So for example when it's passed something like (struct A*)(0,
This patch by Cherry Zhang changes the Go frontend and libgo to pass
the old slice's ptr/len/cap by value to growslice. In the C calling
convention, on AMD64, and probably a number of other architectures, a
3-word struct argument is passed on stack. This is less efficient
than passing in three re
On 3/19/19 2:00 PM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, BLKmode operands (such as in the testcase C++
variables with TREE_ADDRESSABLE types) may only live in a MEM, trying to
reload those in a register will always ICE. process_alt_operands already
has if (mode == BLKmode) break; in
On 3/13/19 8:17 PM, Martin Sebor wrote:
> PR 89688 points out a bogus warning about an unterminated
> character array argument to strlen. The root cause is
> an oversight in the transformation of braced initializer lists
> to STRING_CSTs where the solution implemented last summer only
> considers
On 3/19/19 11:54 AM, Jakub Jelinek wrote:
> Hi!
>
> On the testcase in the PR we ICE because we create non-canonical CONST_INTs
> (e.g. for HImode niter 0xfffe) and the compare_and_jump_seq code then ICEs
> on that.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
>
On 3/6/19 3:05 AM, Richard Biener wrote:
> On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote:
>>
>> On 3/5/19 7:44 AM, Richard Biener wrote:
>>
>>> So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
>>> the MAX_EXPR introduced by folding makes it somewhat ugly.
>>>
>>> Bootstrap
On 11/03/19 21:24 -0700, Thomas Rodgers wrote:
Let's try this patch -
The feature test macro should be 201603L (in and
):
+// Feature test macro for parallel algorithms
+# define __cpp_lib_parallel_algorithm 201703L
***
The new files have copyright dates of 2018, but it's taken so long to
On 2/28/19 5:26 AM, JiangNing OS wrote:
> To solve BZ89430 the followings are needed,
>
> (1) The code below in noce_try_cmove_arith needs to be fixed.
>
> /* ??? We could handle this if we knew that a load from A or B could
> not trap or fault. This is also true if we've already loaded
>
On 3/19/19 9:00 AM, Florian Weimer wrote:
> * Florian Weimer:
>
>> * Jeff Law:
>>
>>> On 03/29/2018 08:00 AM, Florian Weimer wrote:
This patch performs lazy initialization of the relevant CPUID feature
register value. It will needlessly invoke the CPUID determination code
on archit
On 3/5/19 3:40 PM, Jakub Jelinek wrote:
> On Tue, Mar 05, 2019 at 05:33:45PM -0500, Jason Merrill wrote:
>> The x86_64 psABI says that an empty class isn't passed or returned in memory
>> or registers, so we shouldn't set %eax in this function. This seems like a
>> missed case from the GCC 8 TYPE_
On 3/18/19 6:18 PM, Jonathan Wakely wrote:
On 17/03/19 22:54 -0400, Ed Smith-Rowland via libstdc++ wrote:
Greetings,
This patch implements C++20 p0202 - Add Constexpr Modifiers to
Functions in and Headers
and C++20 p1023 - constexpr comparison operators for std::array.
The patch is large
Hi Jan,
> these two PRs are about C++ destructors that are not virtual but have
> virtual alias. The devirtualization machinery walks from alias to symbol
> and is then confused by not knowing the class symbol belongs to.
>
> I think it would make more sense to avoid these walks but that require
>
On 3/19/19 12:30 PM, Jeff Law wrote:
On 2/22/19 9:42 AM, Marek Polacek wrote:
On Thu, Feb 21, 2019 at 03:39:21PM -0700, Martin Sebor wrote:
On 2/21/19 1:27 PM, Jeff Law wrote:
On 2/21/19 1:12 PM, Martin Sebor wrote:
On 2/21/19 12:08 PM, Jeff Law wrote:
On 2/18/19 7:53 PM, Martin Sebor wrote:
On 3/19/19 4:57 PM, Ed Smith-Rowland via libstdc++ wrote:
On 3/18/19 6:18 PM, Jonathan Wakely wrote:
On 17/03/19 22:54 -0400, Ed Smith-Rowland via libstdc++ wrote:
Greetings,
This patch implements C++20 p0202 - Add Constexpr Modifiers to
Functions in and Headers
and C++20 p1023 - constexp
On 3/19/19 12:42 PM, Jeff Law wrote:
On 3/14/19 7:47 PM, Martin Sebor wrote:
To copy type attributes from struct A, the copy attribute (new
in GCC 9) accepts a pointer argument such as (struct A*)0, but
it isn't prepared for anything much more complicated than that.
So for example when it's pass
This fixes the bug reported in PR 89411 where we accidentally generated a
%lo with an offset that overflowed at link time if the symbol was allocated
to an address just below the 2KB limit for %lo. This solves the problem
by checking for BLKmode references, pulling out the SYMBOL_REF_DECL, and
the
Hi all,
the attached one-line patch fixes an ICE-on-invalid regression with
abstract interfaces. Regtests cleanly on x86_64-linux-gnu. Ok for
trunk and the release branches (7 and 8)?
Cheers,
Janus
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 4dd35ec6030..cee2b2cfd15 100644
--
I have committed attached patch to aarch64/sve-acle-branch branch
which implements svbic.
Thanks,
Kugan
From 182bd15334874844bef5e317f55a6497f77e12ff Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah
Date: Thu, 24 Jan 2019 20:57:19 +1100
Subject: [PATCH 1/3] svbic
Change-Id: I819490ec63ee38b
On Tue, 19 Mar 2019, Jeff Law wrote:
> I'll note that our documentation clearly states that attributes can be
> applied to functions, variables, labels, enums, statements and types.
A key thing here is that they can be applied to fields - that is, they can
be properties of a FIELD_DECL. Referri
Hi,
Please refer to below link for previous threads.
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00348.html
Comparing to patch v2, I've moved up the vector operation target
check upward together with vector type target check. Besides, I
ran bootstrap and regtest on powerpc64-linux-gnu (BE), u
On 3/19/19 8:22 PM, Joseph Myers wrote:
> On Tue, 19 Mar 2019, Jeff Law wrote:
>
>> I'll note that our documentation clearly states that attributes can be
>> applied to functions, variables, labels, enums, statements and types.
>
> A key thing here is that they can be applied to fields - that is,
On Tue, Mar 19, 2019 at 11:26 AM Martin Sebor wrote:
>
> Please remember to quote the command line options in the message
> (same as in the error below):
I'll send a new version. Thanks for the feedback!
-Alex
---
gcc/testsuite/c-c++-common/pr65403-1.c | 10 ++
gcc/testsuite/c-c++-common/pr65403-2.c | 15 +++
2 files changed, 25 insertions(+)
create mode 100644 gcc/testsuite/c-c++-common/pr65403-1.c
create mode 100644 gcc/testsuite/c-c++-common/pr65403-2.c
diff --git a/gcc/testsui
From: Manuel López-Ibáñez
* opts.c: Ignore -Wno-error= except if there are
other diagnostics.
---
gcc/opts-common.c | 2 ++
gcc/opts-global.c | 10 +++---
gcc/opts.c| 5 -
gcc/opts.h| 2 ++
4 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/gcc/opts-common
On Tue, Mar 19, 2019 at 11:03 AM Martin Liška wrote:
>
> What's Joseph telling is that right now the patch can't be approved (and
> installed).
> It's due to fact that we are close to the release in stage4:
> https://www.gnu.org/software/gcc/develop.html#stage4
>
> So that a proper review will ha
79 matches
Mail list logo
