Hi!
As the testcase shows, if we have a clause with reference to dependent type,
during the processing_template_decl finish_omp_clauses we would reject it
rather than deferring checking of that until instantiation.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to
Hi!
The following patch adds exclusive scan support for simd, it is similar to
the inclusive scan, just we need to swap the input and scan phases and
use slightly different pattern at the start of the scan phase, so that it
computes what we need.
Bootstrapped/regtested on x86_64-linux and
The following fixes the case where we're vectorizing the inner loop
of an if-converted scalar version of a outer loop. In this case
we cannot re-use the if-conversion version because the not vectorized
path would fall into the code intended for outer loop vectorization.
Bootstrapped and tested
Hi.
The patch is about a new ELF section that will contain information
about LTO version. And for the future, used compression will be stored
here. The patch removes streaming of the version into each section.
Disadvantage is a format change that will lead to following errors when
LTO bytecode
Hi,
The attached patch tries to fix PR88833.
For the following test-case:
subroutine foo(x)
real :: x(100)
x = x + 10
end subroutine foo
Assembly with -O3 -march=armv8.2-a+sve:
foo_:
.LFB0:
.cfi_startproc
mov w2, 100
mov w3, w2
mov x1, 0
Hi!
The following testcase which I wrote in order to test ncopies > 1
handling of the inclusive scan vectorization reveals we don't vectorize
that, because we required MULT_EXPR on the DR_OFFSET, but obviously for
1 byte elements there is none.
Fixed thusly, bootstrapped/regtested on
On Fri, Jun 21, 2019 at 1:56 PM Uros Bizjak wrote:
>
> On Fri, Jun 21, 2019 at 4:21 AM Hongtao Liu wrote:
> >
> > On Thu, Jun 20, 2019 at 10:58 PM H.J. Lu wrote:
> > >
> > > On Thu, Jun 20, 2019 at 3:54 AM Hongtao Liu wrote:
> > > >
> > > > On Thu, Jun 20, 2019 at 2:13 PM Uros Bizjak wrote:
>
On Thu, Jun 20, 2019 at 4:58 PM H.J. Lu wrote:
> > > > > >> > > +/* Register pair. */
> > > > > >> > > +VECTOR_MODES_WITH_PREFIX (P, INT, 2); /* P2QI */
> > > > > >> > > +VECTOR_MODES_WITH_PREFIX (P, INT, 4); /* P2HI P4QI */
> > > > > >> > >
> > > > > >> > > I think
> > > > > >> > >
> > > > >
Hi!
On Wed, 05 Jun 2019 11:25:07 +0200, I wrote:
> I [...] had a look at what OpenMP 5.0
> is saying about Fortran 'allocatable' in 'map' clauses [...]
Will you (Jakub, and/or Fortran guys), please have a look at the attached
test case.
If I disable the '!$omp declare target (ar)', then this
On 6/21/19 1:47 PM, Jonathan Wakely wrote:
> On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote:
>> Yes, I would be fine to deprecate that for GCC 10.1
>
> Would it be appropriate to issue a warning in GCC 10.x if the option is used?
Sure. With the patch attached one will see:
$ gcc -frepo
On Thu, Jun 20, 2019 at 4:16 PM Jan Hubicka wrote:
>
> Hi,
> as discussed earlier this patch drops ref2_is_decl from
> aliasing_component_refs. This parameter makes it to assume that all
> access path may not continue by reference to DECL which is not true
> because in gimple memory model we
On Fri, Jun 21, 2019 at 1:13 AM Jeff Law wrote:
> On 6/20/19 3:53 AM, JiangNing OS wrote:
> > Hi Jeff,
> >
> > Appreciate your effort to review my patch! I've updated my patch as
> attached. See my answers below.
> >
> >> in current function, so the store speculation can be avoided.
> >> So at a
add_insn_allocno_copies and its subroutines used HARD_REG_SET to
represent a bitmask of alternatives. There's not really any connection
between the number of registers and the maximum number of alternatives,
so this patch uses alternative_mask instead (which wasn't around when
this code was
The following fixes PR90914, we cannot keep local exten declarations
unmarked since they will be re-created when instantiating the function
BLOCKs later. And that causes issues if by that means new types get
materialized which should not happen at that point.
Bootstrapped / tested on
On 6/21/19 2:57 PM, Jan Hubicka wrote:
> This looks like good step (and please stream it in host independent
> way). I suppose all these issues can be done one-by-one.
So there's a working patch for that. However one will see following errors
when using an older compiler or older LTO bytecode:
$
Hi!
On Fri, 21 Jun 2019 13:46:09 +0200, I wrote:
> On Wed, 05 Jun 2019 11:25:07 +0200, I wrote:
> > I [...] had a look at what OpenMP 5.0
> > is saying about Fortran 'allocatable' in 'map' clauses [...]
>
> Will you (Jakub, and/or Fortran guys), please have a look at the attached
> test case.
>
This Go patch by Cherry Zhang open codes string slice expressions.
Currently a string slice expression is implemented with a runtime call
__go_string_slice. Change it to open code it, which is more
efficient, and allows the backend to further optimize it. Also omit
the write barrier for
This Go frontend patch by Cherry Zhang omits write barriers for
assignments to *(convert()). Assignments to local variables
don't need a write barrier. But currently the compiler inserts a
write barrier if the LHS is a local variable with type converted, as
*(convert()). Let the compiler
Hi Richard. Hi folks.
In order to unify the APIs for value_range and irange, we'd like to make
some minor changes to value_range. We believe most of these changes
could go in now, and would prefer so, to get broader testing and
minimize the plethora of changes we drag around on our branch.
On Fri, Jun 21, 2019 at 12:24 AM Jeff Law wrote:
>
> As outlined in the BZ, our alias analysis code is context insensitive.
> So when we copy-propagate pointers, we can can and do copy PTA
> information from members to the representative pointer in the copy-of
> chain (we do this when the
On Fri, Jun 21, 2019 at 12:20 PM Martin Liška wrote:
>
> Hi.
>
> The patch is about a new ELF section that will contain information
> about LTO version. And for the future, used compression will be stored
> here. The patch removes streaming of the version into each section.
I'd like each section
> On 6/21/19 2:34 PM, Richard Biener wrote:
> > On Fri, Jun 21, 2019 at 12:20 PM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> The patch is about a new ELF section that will contain information
> >> about LTO version. And for the future, used compression will be stored
> >> here. The patch removes
Currently variables with the AUTOMATIC attribute can not appear in an
EQUIVALENCE statement. However its counterpart, STATIC, can be used in
an EQUIVALENCE statement.
Where there is a clear conflict in the attributes of variables in an
EQUIVALENCE statement an error message will be issued as
SVE has a prefix instruction (MOVPRFX) that acts as a move but is
designed to be easily fusible with the following instruction. The SVE
port therefore has lots of patterns with constraints of the form:
A: operand 0: =w,?w
...
operand n: 0, w
where the first alternative is a single
make_early_clobber_and_input_conflicts records allocno conflicts
between inputs and earlyclobber outputs. It (rightly) avoids
doing this for inputs that are explicitly allowed to match the
output due to matching constraints.
The problem is that whether this matching is allowed varies
between
ira_get_dup_out_num punted on operands that are matched to
earlyclobber outputs:
/* It is better ignore an alternative with early clobber. */
else if (*str == '&')
goto fail;
But I'm not sure why this is the right thing to do. At this stage
we've
These functions are using TREE_PURPOSE to get the attribute name,
which is breaking now that we preserve the C++11-style attribute
format past decl_attributes. So use get_attribute_name which can
handle both formats of attributes.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-06-21
On Fri, Jun 21, 2019 at 02:31:51PM +0100, Mark Eggleston wrote:
> Currently variables with the AUTOMATIC attribute can not appear in an
> EQUIVALENCE statement. However its counterpart, STATIC, can be used in
> an EQUIVALENCE statement.
>
> Where there is a clear conflict in the attributes of
On 6/21/19 8:09 AM, Marek Polacek wrote:
> These functions are using TREE_PURPOSE to get the attribute name,
> which is breaking now that we preserve the C++11-style attribute
> format past decl_attributes. So use get_attribute_name which can
> handle both formats of attributes.
>
>
ira_setup_alts has its own code to calculate the start of the
constraint string for each operand/alternative combination,
but preprocess_constraints now provides that information in (almost)
constant time for non-asm instructions. Using it here should speed
up the common case at the cost of
On 6/21/19 1:58 PM, Jakub Jelinek wrote:
> On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
>> On 6/21/19 1:47 PM, Jonathan Wakely wrote:
>>> On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote:
Yes, I would be fine to deprecate that for GCC 10.1
>>>
>>> Would it be appropriate to
On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> On 6/21/19 1:58 PM, Jakub Jelinek wrote:
> > On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> >> On 6/21/19 1:47 PM, Jonathan Wakely wrote:
> >>> On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote:
> Yes, I would be
This series of patches tweaks the IRA handling of matched constraints
and earlyclobbers. The main explanations are in the individual patches.
Tested on aarch64-linux-gnu (with and without SVE) and x86_64-linux-gnu.
I also tried building at least one target per CPU directory and
comparing the
The following fixes a quadraticness in reassoc.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2019-06-21 Richard Biener
PR tree-optimization/90930
* tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited
flag on new stmts to avoid
On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
>
> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> > On 6/21/19 1:58 PM, Jakub Jelinek wrote:
> > > On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> > >> On 6/21/19 1:47 PM, Jonathan Wakely wrote:
> > >>> On Fri,
On 6/21/19 6:28 AM, Richard Biener wrote:
> On Fri, Jun 21, 2019 at 12:24 AM Jeff Law wrote:
>>
>> As outlined in the BZ, our alias analysis code is context insensitive.
>> So when we copy-propagate pointers, we can can and do copy PTA
>> information from members to the representative pointer in
On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> On 6/21/19 1:47 PM, Jonathan Wakely wrote:
> > On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote:
> >> Yes, I would be fine to deprecate that for GCC 10.1
> >
> > Would it be appropriate to issue a warning in GCC 10.x if the option is
On 6/21/19 2:34 PM, Richard Biener wrote:
> On Fri, Jun 21, 2019 at 12:20 PM Martin Liška wrote:
>>
>> Hi.
>>
>> The patch is about a new ELF section that will contain information
>> about LTO version. And for the future, used compression will be stored
>> here. The patch removes streaming of the
On 6/20/19 8:09 PM, Martin Sebor wrote:
> On 6/20/19 4:23 PM, Jeff Law wrote:
>> As outlined in the BZ, our alias analysis code is context insensitive.
>> So when we copy-propagate pointers, we can can and do copy PTA
>> information from members to the representative pointer in the copy-of
>>
On June 21, 2019 4:43:10 PM GMT+02:00, Jeff Law wrote:
>On 6/21/19 6:28 AM, Richard Biener wrote:
>> On Fri, Jun 21, 2019 at 12:24 AM Jeff Law wrote:
>>>
>>> As outlined in the BZ, our alias analysis code is context
>insensitive.
>>> So when we copy-propagate pointers, we can can and do copy PTA
On Fri, Jun 21, 2019 at 04:17:13PM +0200, Richard Biener wrote:
>
> The following fixes a quadraticness in reassoc.
>
> Bootstrap / regtest running on x86_64-unknown-linux-gnu.
build_and_add_sum has several other callers, don't they need a similar
change (or better do the gimple_set_visited
Hi!
Now that the inclusive/exclusive scan support is pretty much done in simd,
it is time to implement it also in the OpenMP worksharing-loop and in
the combined worksharing-loop SIMD constructs, so that the scan computation
is not just vectorized, but also parallelized.
There are some parallel
This PR was submitted on 2012-01-25. It seems that I
posted a patch in comment #9 on 2012-01-25. But the
patch was never submitted to fortran@ and patches@. The
patch is straight forward in that it suppresses a bogus
error message which then allows gfortran to issue a
more suitable error
On 6/21/19 12:01 PM, Jonathan Wakely wrote:
Nathan noticed that the 'static inline' functions in
cause ODR violations when used from inline functions or templates (see
[basic.def.odr] p12 bullet (12.2)). His modules branch now diagnoses
those violations, so we need a fix.
Looking at the
On Fri, Jun 21, 2019 at 06:20:35PM +0200, Richard Biener wrote:
> On June 21, 2019 5:50:45 PM GMT+02:00, Jakub Jelinek wrote:
> >On Fri, Jun 21, 2019 at 04:17:13PM +0200, Richard Biener wrote:
> >>
> >> The following fixes a quadraticness in reassoc.
> >>
> >> Bootstrap / regtest running on
On 6/21/19 6:23 AM, Richard Biener wrote:
>
> That looks like a pretty easy form to analyze. I'd suggest looking
> through tree-ssa-phiopt.c closely. There's several transformations
> in there that share similarities with yours.
>
>
> More specifically there is the conditional store
On June 21, 2019 5:50:45 PM GMT+02:00, Jakub Jelinek wrote:
>On Fri, Jun 21, 2019 at 04:17:13PM +0200, Richard Biener wrote:
>>
>> The following fixes a quadraticness in reassoc.
>>
>> Bootstrap / regtest running on x86_64-unknown-linux-gnu.
>
>build_and_add_sum has several other callers, don't
On 21/06/19 13:01 -0400, Nathan Sidwell wrote:
On 6/21/19 12:01 PM, Jonathan Wakely wrote:
Nathan noticed that the 'static inline' functions in
cause ODR violations when used from inline functions or templates (see
[basic.def.odr] p12 bullet (12.2)). His modules branch now diagnoses
those
On 21/06/19 18:08 +0100, Jonathan Wakely wrote:
On 21/06/19 13:01 -0400, Nathan Sidwell wrote:
On 6/21/19 12:01 PM, Jonathan Wakely wrote:
Nathan noticed that the 'static inline' functions in
cause ODR violations when used from inline functions or templates (see
[basic.def.odr] p12 bullet
On 13/06/19 17:09 +0100, Jonathan Wakely wrote:
The C++17 library was rebased on C11 by https://wg21.link/p0063r3 so
these nine macros are needed for C++17 conformance.
gcc:
* ginclude/float.h (FLT_DECIMAL_DIG, DBL_DECIMAL_DIG, LDBL_DECIMAL_DIG)
(FLT_HAS_SUBNORM,
On 20/06/19 00:00 +0100, Jonathan Wakely wrote:
The change in r263433 broke the contract of the __rotate functions, by no
longer accepting empty ranges. That means that callers which inlined the
old version of std::rotate (without checks) that end up linking to a new
definition of std::__rotate
On Thu, Jun 20, 2019 at 05:24:15PM -0400, Matthew Beliveau wrote:
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2019-06-20 Matthew Beliveau
>
> PR c++/90875 - added -Wswitch-outside-range option
> * doc/invoke.texi (Wswitch-outside-range): Document.
>
> *
Nathan noticed that the 'static inline' functions in
cause ODR violations when used from inline functions or templates (see
[basic.def.odr] p12 bullet (12.2)). His modules branch now diagnoses
those violations, so we need a fix.
Looking at the history (r114044 by Paolo) I believe the idea was
On 6/21/19 6:28 AM, Richard Biener wrote:
> On Fri, Jun 21, 2019 at 12:24 AM Jeff Law wrote:
>>
>> As outlined in the BZ, our alias analysis code is context insensitive.
>> So when we copy-propagate pointers, we can can and do copy PTA
>> information from members to the representative pointer in
Richard Sandiford writes:
> This series of patches tweaks the IRA handling of matched constraints
> and earlyclobbers. The main explanations are in the individual patches.
>
> Tested on aarch64-linux-gnu (with and without SVE) and x86_64-linux-gnu.
>
> I also tried building at least one target
On 6/20/19 12:24 AM, Paolo Carlini wrote:
Hi,
this bug notices that the more aggressive de-virtualization check that
we have now in place (fixed c++/67184) doesn't work correctly for the
below reproducer, which involves a pure virtual: we de-virtualize and
the build fails at link-time. To
Hi,
On 21/06/19 21:27, Paolo Carlini wrote:
Hi,
On 21/06/19 20:50, Jason Merrill wrote:
On 6/20/19 12:24 AM, Paolo Carlini wrote:
Hi,
this bug notices that the more aggressive de-virtualization check
that we have now in place (fixed c++/67184) doesn't work correctly
for the below
On 6/20/19 10:46 AM, Marek Polacek wrote:
The first test is rejected because build_noexcept_spec first converts
a TARGET_EXPR using a user-defined conversion, creating
R::operator bool (_EXPR )
which then fails when instantiating ("taking address of rvalue").
The second test ICEs in
On Fri, Jun 21, 2019 at 04:06:50PM -0400, Jason Merrill wrote:
> On 6/20/19 10:46 AM, Marek Polacek wrote:
> > The first test is rejected because build_noexcept_spec first converts
> > a TARGET_EXPR using a user-defined conversion, creating
> >
> >R::operator bool (_EXPR )
> >
> > which then
On 6/18/19 11:54 AM, Marek Polacek wrote:
Here we ICE on
template // #1
struct A {};
template void foo(A) {}
void bar() { foo(A()); }
when deducing T in the non-type template parameter, because unify didn't
expect a CONSTRUCTOR:
default:
/* An unresolved overload is
On 6/19/19 8:18 PM, Marek Polacek wrote:
We are wrongly accepting invalid code like:
struct alignas(16 S2 { }; // missing )
The reason is that cp_parser_type_specifier uses tentative parsing to see if
we're dealing with a class-specifier, and if that doesn't work, it looks for
an
On 6/17/19 5:43 PM, Marek Polacek wrote:
[class.friend]/6 says that when we define a function in a friend declaration,
the function name must be unqualified. But we never made sure that's so.
For good measure, I'm also improving the location of the related diagnostic.
Bootstrapped/regtested
On 6/17/19 1:44 PM, Marek Polacek wrote:
+// { dg-options "-Wno-pedantic -Wno-switch-outside-range" }
(You can also use __extension__ so that you don't need -Wno-pedantic.)
Using dg-options overrides the default -pedantic-errors, so you don't
need __extension__ either.
If you don't mean
and...
By the way, if S1:.f is not pure virtual, just a virtual declaration -
all the rest being the same - the code doesn't link: undefined
references to vtable and typeinfo for S1. The same happens with
current clang and icc. I don't know if this detail helps us in the
short term
...
I've committed the attached patch. Read the test case
for an explanation.
2019-06-21 Steven G. Kargl
PR fortran/67884
* resolve.c (deferred_requirements) : Check only the result variable.
(resolve_fl_procedure): Check deferred requirements on functions.
2019-06-21
On 6/14/19 4:54 PM, Marek Polacek wrote:
On Tue, Jun 11, 2019 at 11:46:05PM -0400, Jason Merrill wrote:
On 6/3/19 9:01 PM, Marek Polacek wrote:
I sort of ended up going down a rathole, but then I realized we don't need to
delay parsing of noexcept-specifiers of member friend function
OK.
On Fri, Jun 21, 2019 at 1:24 PM Jonathan Wakely wrote:
>
> On 13/06/19 17:09 +0100, Jonathan Wakely wrote:
> >The C++17 library was rebased on C11 by https://wg21.link/p0063r3 so
> >these nine macros are needed for C++17 conformance.
> >
> >gcc:
> >
> > * ginclude/float.h
On Thu, Jun 20, 2019 at 11:51 PM Hongtao Liu wrote:
>
> On Fri, Jun 21, 2019 at 1:56 PM Uros Bizjak wrote:
> >
> > On Fri, Jun 21, 2019 at 4:21 AM Hongtao Liu wrote:
> > >
> > > On Thu, Jun 20, 2019 at 10:58 PM H.J. Lu wrote:
> > > >
> > > > On Thu, Jun 20, 2019 at 3:54 AM Hongtao Liu wrote:
Hi,
On 21/06/19 20:50, Jason Merrill wrote:
On 6/20/19 12:24 AM, Paolo Carlini wrote:
Hi,
this bug notices that the more aggressive de-virtualization check
that we have now in place (fixed c++/67184) doesn't work correctly
for the below reproducer, which involves a pure virtual: we
Darwin has had long long functions for some considerable time and these are
exposed in Darwin8 and Darwin11+ headers. However, for some reason it was
elected to hide them behind __STRICT_ANSI__ and __STDC_VERSION__ on
Darwin9/10. This is a problem for g++/libstdc++ that expects the functions to
On Fri, 21 Jun 2019, Jakub Jelinek wrote:
> On Fri, Jun 21, 2019 at 06:20:35PM +0200, Richard Biener wrote:
> > On June 21, 2019 5:50:45 PM GMT+02:00, Jakub Jelinek
> > wrote:
> > >On Fri, Jun 21, 2019 at 04:17:13PM +0200, Richard Biener wrote:
> > >>
> > >> The following fixes a quadraticness
There are two issues with the Darwin14 (SDK) headers in which unguarded
advanced syntax elements causes any code including these headers to fail.
tested on several Darwin versions and x86-64-linux-gnu.
applied to mainline,
thanks
Iain
2019-06-21 Iain Sandoe
* inclhack.def: Guard
On Fri, Jun 21, 2019 at 04:47:46PM -0400, Jason Merrill wrote:
> On 6/14/19 4:54 PM, Marek Polacek wrote:
> > On Tue, Jun 11, 2019 at 11:46:05PM -0400, Jason Merrill wrote:
> > > On 6/3/19 9:01 PM, Marek Polacek wrote:
> > >
> > > > I sort of ended up going down a rathole, but then I realized we
... so, now that I see the issue more clearly, I'm adding to the
testsuite the below too.
Thanks, Paolo.
Index: final7.C
===
--- final7.C(nonexistent)
+++ final7.C(working copy)
@@ -0,0 +1,11 @@
Hi!
Now that GCC supports inclusive/exclusive scans (like ICC 19.0 so far in
simd constructs only), we can enable it in PSTL as well.
Bootstrapped/regtested on x86_64-linux and i686-linux, additionally tested
with
#include
#include
auto
foo (std::vector , std::vector )
{
return
Hi!
The following testcases weren't vectorized, because the simd lane accesses
weren't recognized there.
Usually SIMD lane accesses look like:
_22 = .GOMP_SIMD_LANE (simduid.0_14(D), ??);
...
MEM [(struct S *)][_22].s = _25;
but on these two testcases we ended up with:
_18 =
This Go patch by Cherry Zhang open codes some type assertions. Now
that type equality is just simple pointer equality, we can open code
some type assertions instead of making runtime calls. Bootstrapped
and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index:
On Wed, Jun 19, 2019 at 12:49 PM Martin Sebor wrote:
>
>
> gcc-wformat-diag-checker.diff
>
> gcc/c-family/ChangeLog:
>
> * c-format.c (function_format_info::format_type): Adjust type.
> (function_format_info::is_raw): New member.
>
This libgo patch by Cherry Zhang inlines and remove eqtype. Now that
type equality is just a pointer equality, inline and remove the eqtype
function. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
This Go patch by Cherry Zhang lets the Go frontend recognize some
math/bits functions and turn them into intrinsics. Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
2019-06-21 Cherry Zhang
* go-gcc.cc (Gcc_backend::Gcc_backend): Define math/bits
On 6/21/19 4:16 PM, Ian Lance Taylor wrote:
On Wed, Jun 19, 2019 at 12:49 PM Martin Sebor wrote:
gcc-wformat-diag-checker.diff
gcc/c-family/ChangeLog:
* c-format.c (function_format_info::format_type): Adjust type.
(function_format_info::is_raw): New member.
The solution we implemented in GCC 9 to get the mangling of
non-type template arguments of class types containing array
members consistent regardless of the form of their
initialization introduced a couple of bugs. One of these
is the subject of this patch. The bug results in stripping
trailing
On 6/21/19 5:29 PM, Marek Polacek wrote:
On Fri, Jun 21, 2019 at 04:47:46PM -0400, Jason Merrill wrote:
On 6/14/19 4:54 PM, Marek Polacek wrote:
On Tue, Jun 11, 2019 at 11:46:05PM -0400, Jason Merrill wrote:
On 6/3/19 9:01 PM, Marek Polacek wrote:
I sort of ended up going down a rathole,
On 6/13/19 9:21 PM, Marek Polacek wrote:
As Jon points out in the PR, emitting -Wunused warnings in unevaluated contexts
doesn't make a whole lot of sense, because in such contexts, we're not reading
the values in any case. Disabling this particular warning is trivial. There
are likely other
On 6/13/19 8:12 PM, Paolo Carlini wrote:
Hi,
should all be rather straightforward but I spent quite a bit of time on
the testsuite changes... Tested x86_64-linux, as usual.
OK.
PS: at some point we should start talking about all the error, error_at,
etc, which are *never* exercised by our
85 matches
Mail list logo
