On Thu, 22 Nov 2018, Jakub Jelinek wrote:
> Hi!
>
> On the following testcases, we warn twice, once in the FE array bounds
> warning code and once later on.
> The FE array bounds warning code sets TREE_NO_WARNING on the corresponding
> MEM_REF, so it is easy to avoid the duplicate warning later.
I've checked in this patch for PR 53608. It's derived from the text
suggested in the issue.
-Sandra
2018-11-22 Sandra Loosemore
Alan Coopersmith
PR c/53608
gcc/
* doc/extend.texi (Designated Inits): Clarify handling of multiple
initializers for unions.
Index:
Hi!
On Thu, Nov 22, 2018 at 02:47:10PM -0500, Vladimir Makarov wrote:
> Today I committed a patch
>
> https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01945.html
>
> But it makes gcc.target/powerpc/pr70669.c to fail. Here is the patch
> to fix the failure. The expected code assumes that
On 11/22/18 11:43 AM, Jakub Jelinek wrote:
On Thu, Nov 22, 2018 at 11:00:13AM +0100, Jakub Jelinek wrote:
Ok for trunk if it passes bootstrap/regtest (so far just checked with
make check-gfortran RUNTESTFLAGS='dg.exp=pad_source*'
)?
Note, it passed bootstrap/regtest on x86_64-linux.
OK,
Mangling visits the base template function type, prior to template
resolution, and on such types, exception specifications may contain
unresolved noexcept expressions. nothrow_spec_p is called on them
even whe exception specifications are not part of function types, and
it rejects unresolved
The testcase is the work-around testcase for the PR; even that had
started failing. The problem was that, when unqualifying the type of
a TARGET_EXPR, we'd create a variant of the type, then request the
conversion of the TARGET_EXPR_INITIAL to that variant type. Though
the types are different
Hi,
this patch fixes ICE in ipa-devirt that was caused by simple typo, but I
also noticed that the comparsion machinery is way too active on type
varaints outputting main variants as mismatching when only variants
differs by quallifiers. Fixed thus.
Bootstrapped/regtested x86_64-linux, comitted.
Hi,
late in stage4 of GCC 8 Martin introduced code that sorts odr types so
they get registered independently on the hashing order since we was
getting different sets of warnings depending on the target in some of
testcases. This should be solved now by recursing to subtypes while
register ODR
On Thu, Nov 22, 2018 at 8:47 PM Jakub Jelinek wrote:
>
> Hi!
>
> While adjusting the PR85644 patch, I've noticed that while pretty much
> the whole ix86_option_override_internal works only with opts_set->x_
> and opts->x_, the stack protector guard code was accessing
> global_options_set.x_ or
On Thu, Nov 22, 2018 at 8:51 PM Jakub Jelinek wrote:
>
> Hi!
>
> And while working on the previously posted patch, I've noticed a ton of
> lines with = at the end of line rather than at the start of next one
> (I think = at the end of line is fine only for array initializers).
>
>
2018-11-22 Uros Bizjak
* config/i386/i386.c (ix86_check_avx_upper_register):
Return true for all SSE registers with mode bitsize > 128.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
Index: config/i386/i386.c
Hi,
the following testcase is supposed to check that "stream_me_once" is
streamed just once from WPA to ltrans and thus I want to scan dump
.000i.0.lto-stream-out
I think however that dejagnu is confused by the extra .0 in filename
(which distinguishes the partition number and is intended) and I
On Thu, Nov 22, 2018 at 02:53:11PM +0100, Richard Biener wrote:
> > the optimizer moving it around over function calls etc.?
> > The instrumentation should still be useful when the program
> > crashes, so we don't want to delay logging too much.
>
> You can't avoid moving it, yes. But it can be
Hi,
I have tweaked the testcases as follows. They now work with -O2
and additionally test better for locations of individual warnings.
The output is as follows:
../../gcc/testsuite/g++.dg/lto/odr-3_0.C:5:3: warning: type ‘struct YYSTYPE’
violates the C++ One Definition Rule [-Wodr]
5 | }
Hi!
On the following testcases, we warn twice, once in the FE array bounds
warning code and once later on.
The FE array bounds warning code sets TREE_NO_WARNING on the corresponding
MEM_REF, so it is easy to avoid the duplicate warning later.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
Hi!
This testcase has been fixed by the PR85793 fix r260317.
I've committed following test as obvious so that we can close the PR.
2018-11-22 Jakub Jelinek
PR tree-optimization/85794
* gcc.dg/vect/O3-pr85794.c: New test.
--- gcc/testsuite/gcc.dg/vect/O3-pr85794.c.jj
Hi!
This test apparently FAILs on s390x-linux, which is an effective target of
both logical_op_short_circuit and branch_cost.
The test has
/* { dg-additional-options "-mbranch-cost=2" { target branch_cost } } */
and that option effectively makes the target ! logical_op_short_circuit,
but the
Hi!
And while working on the previously posted patch, I've noticed a ton of
lines with = at the end of line rather than at the start of next one
(I think = at the end of line is fine only for array initializers).
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-11-22 Jakub Jelinek
Hi!
While adjusting the PR85644 patch, I've noticed that while pretty much
the whole ix86_option_override_internal works only with opts_set->x_
and opts->x_, the stack protector guard code was accessing
global_options_set.x_ or using the macros that expand to
global_options.x_ . While it is
Today I committed a patch
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01945.html
But it makes gcc.target/powerpc/pr70669.c to fail. Here is the patch
to fix the failure. The expected code assumes that variable r should
get a general reg. I suspect the expectation is wrong. There are
On Thu, Nov 22, 2018 at 11:00:13AM +0100, Jakub Jelinek wrote:
> Ok for trunk if it passes bootstrap/regtest (so far just checked with
> make check-gfortran RUNTESTFLAGS='dg.exp=pad_source*'
> )?
Note, it passed bootstrap/regtest on x86_64-linux.
> 2018-11-22 Jakub Jelinek
>
> *
On Thu, 22 Nov 2018 at 19:14, Jan Hubicka wrote:
>
> > On November 22, 2018 5:30:14 PM GMT+01:00, Jan Hubicka
> > wrote:
> > >>* g++.dg/lto/odr-2_0.C: Remove extra brace
> > >>
> > >> diff --git a/gcc/testsuite/g++.dg/lto/odr-2_0.C
> > >b/gcc/testsuite/g++.dg/lto/odr-2_0.C
> > >> index
On Thu, 22 Nov 2018, Jonathan Wakely wrote:
"For __relocate_a_1, I should also test if copying, ++ and != are noexcept,
but I wanted to ask first because there might be restrictions on what
iterators are allowed to do, even if I didn't see them."
I decided to postpone thinking about that :-)
Hi,
Sorry, but I am a little confused.
On Wed, Nov 14, 2018 at 11:28 AM Wilco Dijkstra wrote:
>
> Hi,
>
>
> > Indeed. After plotting the graph of both functions, it is very clear
> > that this check isn't required. Sorry about that.
>
> It wouldn't be clear from the graph, you need to check
On 22/11/18 19:10 +0100, Marc Glisse wrote:
On Thu, 22 Nov 2018, Jonathan Wakely wrote:
On 26/10/18 14:02 +0200, Marc Glisse wrote:
Index: libstdc++-v3/include/bits/stl_iterator.h
===
--- libstdc++-v3/include/bits/stl_iterator.h
On Thu, 22 Nov 2018, Tom de Vries wrote:
> Hi,
>
> If realloc is called with size 0, realloc can return NULL.
Note that, as of C17, realloc with size 0 is marked as an obsolescent
feature (because of inconsistencies between implementations regarding
whether the old object is deallocated). So
> On November 22, 2018 5:30:14 PM GMT+01:00, Jan Hubicka wrote:
> >>* g++.dg/lto/odr-2_0.C: Remove extra brace
> >>
> >> diff --git a/gcc/testsuite/g++.dg/lto/odr-2_0.C
> >b/gcc/testsuite/g++.dg/lto/odr-2_0.C
> >> index 222fa2c1db..3ebb49efa2 100644
> >> ---
On Thu, 22 Nov 2018, Jonathan Wakely wrote:
On 26/10/18 14:02 +0200, Marc Glisse wrote:
Index: libstdc++-v3/include/bits/stl_iterator.h
===
--- libstdc++-v3/include/bits/stl_iterator.h(revision 265522)
+++
On November 22, 2018 5:30:14 PM GMT+01:00, Jan Hubicka wrote:
>> * g++.dg/lto/odr-2_0.C: Remove extra brace
>>
>> diff --git a/gcc/testsuite/g++.dg/lto/odr-2_0.C
>b/gcc/testsuite/g++.dg/lto/odr-2_0.C
>> index 222fa2c1db..3ebb49efa2 100644
>> --- a/gcc/testsuite/g++.dg/lto/odr-2_0.C
>> +++
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87718
The patch adds a special treatment for moves with a hard register in
register cost and class calculation.
The patch was bootstrapped and tested on x86-64 and ppc64.
I found two testsuite regressions because
> > See the thread about the instrumentation pass which currently
> > is implemented on GIMPLE.
>
> What are the issues for instrumenting as an RTL pass?
It just needs to be completely rewritten and might be more complicated.
And it might be more difficult to avoid redundant instrumentation
On 11/12/18 6:24 PM, Sudakshina Das wrote:
> Hi Sam
>
> On 02/11/18 17:31, Sam Tebbs wrote:
>> Hi all,
>>
>> The -mbranch-protection option combines the functionality of
>> -msign-return-address and the BTI features new in Armv8.5 to better reflect
>> their relationship. This new option therefore
On Nov 22 2018, Jan Hubicka wrote:
>> * g++.dg/lto/odr-2_0.C: Remove extra brace
>>
>> diff --git a/gcc/testsuite/g++.dg/lto/odr-2_0.C
>> b/gcc/testsuite/g++.dg/lto/odr-2_0.C
>> index 222fa2c1db..3ebb49efa2 100644
>> --- a/gcc/testsuite/g++.dg/lto/odr-2_0.C
>> +++
> * g++.dg/lto/odr-2_0.C: Remove extra brace
>
> diff --git a/gcc/testsuite/g++.dg/lto/odr-2_0.C
> b/gcc/testsuite/g++.dg/lto/odr-2_0.C
> index 222fa2c1db..3ebb49efa2 100644
> --- a/gcc/testsuite/g++.dg/lto/odr-2_0.C
> +++ b/gcc/testsuite/g++.dg/lto/odr-2_0.C
> @@ -1,5 +1,5 @@
> // {
I'm talking about the PIC access to the guard's variable. See for
example the pr85434.c testcase contributed with this patch when
compiled for aarch64 with -Os -fpic -march=armv8-a
-fstack-protector-strong:
(insn 227 226 228 33 (set (reg:DI 90)
(high:DI (symbol_ref:DI
On 20 November 2018 22:54:49 CET, Julian Brown wrote:
>
>Previously posted upstream:
>https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00826.html
As said in https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00861.html
+ bool array_only_p = true;
+ /* Disallow duplicate bare variable
On Wed, Nov 21, 2018 at 9:26 AM Uros Bizjak wrote:
> Before vzeroupper gets emitted before function call, the compiler
> checks if if there are live call-saved SSE registers at the insertion
> point. This functionality is intended to handle Windows ABI, so we
> don't clear upper parts of the XMM
On 11/22/18 3:28 PM, Uros Bizjak wrote:
> On Thu, Nov 22, 2018 at 3:22 PM Martin Liška wrote:
>>
>> On 11/22/18 3:04 PM, Uros Bizjak wrote:
>>> On Thu, Nov 22, 2018 at 3:00 PM Martin Liška wrote:
On 11/22/18 2:51 PM, Uros Bizjak wrote:
> On Thu, Nov 22, 2018 at 2:43 PM Martin Liška
Thanks Kyrill. Committed the attached patch.
Best regards,
Thomas
On Wed, 21 Nov 2018 at 16:06, Kyrill Tkachov
wrote:
>
> Hi Thomas,
>
> Sorry for the delay.
>
> On 16/11/18 14:56, Thomas Preudhomme wrote:
> > Ping?
> >
> > Best regards,
> >
> > Thomas
> >
> > On Sat, 10 Nov 2018 at 15:07,
On Thu, 22 Nov 2018 at 14:09, Rainer Orth wrote:
>
> Hi Christophe,
>
> > On Sat, 10 Nov 2018 at 00:43, Martin Sebor wrote:
> >>
> >> On 11/09/2018 12:59 PM, Jeff Law wrote:
> >> > On 10/31/18 10:27 AM, Martin Sebor wrote:
> >> >> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01473.html
>
On Thu, Nov 22, 2018 at 5:24 AM Richard Biener
wrote:
>
> On Wed, Nov 21, 2018 at 4:38 PM H.J. Lu wrote:
> >
> > On Wed, Nov 21, 2018 at 6:48 AM Richard Biener
> > wrote:
> > >
> > > On Tue, Nov 20, 2018 at 7:36 PM Andi Kleen wrote:
> > > >
> > > > On Tue, Nov 20, 2018 at 11:53:15AM +0100,
On Thu, 22 Nov 2018, Martin Liška wrote:
> > (Multilib suffixes on include directories for C are more or less an
> > implementation detail of how fixed headers are arranged in the case where
> > sysroot headers suffixes are used; they aren't really expected to be a
> > stable interface such
On Thu, Nov 22, 2018 at 3:22 PM Martin Liška wrote:
>
> On 11/22/18 3:04 PM, Uros Bizjak wrote:
> > On Thu, Nov 22, 2018 at 3:00 PM Martin Liška wrote:
> >>
> >> On 11/22/18 2:51 PM, Uros Bizjak wrote:
> >>> On Thu, Nov 22, 2018 at 2:43 PM Martin Liška wrote:
> >>>
> The patch makes clear
On 11/22/18 3:04 PM, Uros Bizjak wrote:
> On Thu, Nov 22, 2018 at 3:00 PM Martin Liška wrote:
>>
>> On 11/22/18 2:51 PM, Uros Bizjak wrote:
>>> On Thu, Nov 22, 2018 at 2:43 PM Martin Liška wrote:
>>>
The patch makes clear we'll not diverge number of elements in
processor_names and the
The following fixes the missing VN elimination in loop->nb_iterations
which causes ICEs later on.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2018-11-22 Richard Biener
PR tree-optimization/88148
* tree-ssa-loop-niter.c
On Thu, Nov 22, 2018 at 3:00 PM Martin Liška wrote:
>
> On 11/22/18 2:51 PM, Uros Bizjak wrote:
> > On Thu, Nov 22, 2018 at 2:43 PM Martin Liška wrote:
> >
> >> The patch makes clear we'll not diverge number of elements in
> >> processor_names and the corresponding enum. Plus I fixed
> >>
On 11/22/18 2:51 PM, Uros Bizjak wrote:
> On Thu, Nov 22, 2018 at 2:43 PM Martin Liška wrote:
>
>> The patch makes clear we'll not diverge number of elements in
>> processor_names and the corresponding enum. Plus I fixed
>> -march=znver2 native as valid options that were not listed.
>>
>> Patch
On Thu, Nov 22, 2018 at 2:51 PM Uros Bizjak wrote:
> > The patch makes clear we'll not diverge number of elements in
> > processor_names and the corresponding enum. Plus I fixed
> > -march=znver2 native as valid options that were not listed.
> >
> > Patch survives tests and bootstrap on
On Thu, Nov 22, 2018 at 2:34 PM Jakub Jelinek wrote:
>
> On Thu, Nov 22, 2018 at 01:30:03PM +, Michael Matz wrote:
> > On Wed, 21 Nov 2018, Richard Biener wrote:
> >
> > > then this leads to wrong debug info showing a value for 'a' that never
> > > existed.
> >
> > var-tracking was
On Tue, Nov 20, 2018 at 7:27 PM Andi Kleen wrote:
>
> On Tue, Nov 20, 2018 at 01:04:19PM +0100, Richard Biener wrote:
> > Since your builtin clobbers memory
>
> Hmm, maybe we could get rid of that, but then how to avoid
> the optimizer moving it around over function calls etc.?
> The
On 11/21/18 1:43 AM, Martin Sebor wrote:
> On 11/20/2018 03:08 AM, Martin Liška wrote:
>> Hi.
>>
>> It's the script that I used to identify potentially resolvable bugs. That's
>> done
>> by parsing of comments and seeking for trunk/branch commits. Sample output
>> looks
>> as follows:
>>
>>
On Thu, Nov 22, 2018 at 2:43 PM Martin Liška wrote:
> The patch makes clear we'll not diverge number of elements in
> processor_names and the corresponding enum. Plus I fixed
> -march=znver2 native as valid options that were not listed.
>
> Patch survives tests and bootstrap on x86_64-linux-gnu.
Hi.
The patch makes clear we'll not diverge number of elements in
processor_names and the corresponding enum. Plus I fixed
-march=znver2 native as valid options that were not listed.
Patch survives tests and bootstrap on x86_64-linux-gnu.
Ready for trunk?
Martin
gcc/ChangeLog:
2018-11-22
The implementations of std::make_shared for -frtti and -fno-rtti are not
compatible, because they pass different arguments to
_Sp_counted_ptr_inplace::_M_get_deleter and so can't interoperate.
Either the argument doesn't match the expected value, and so the
shared_ptr::_M_ptr member is never set,
On Thu, Nov 22, 2018 at 01:30:03PM +, Michael Matz wrote:
> On Wed, 21 Nov 2018, Richard Biener wrote:
>
> > then this leads to wrong debug info showing a value for 'a' that never
> > existed.
>
> var-tracking was specifically created so that the base-vars of SSA names
> aren't necessary
Hi,
On Wed, 21 Nov 2018, Richard Biener wrote:
> then this leads to wrong debug info showing a value for 'a' that never
> existed.
var-tracking was specifically created so that the base-vars of SSA names
aren't necessary for debug info anymore ...
> when you build this with -O -g
On Wed, Nov 21, 2018 at 4:38 PM H.J. Lu wrote:
>
> On Wed, Nov 21, 2018 at 6:48 AM Richard Biener
> wrote:
> >
> > On Tue, Nov 20, 2018 at 7:36 PM Andi Kleen wrote:
> > >
> > > On Tue, Nov 20, 2018 at 11:53:15AM +0100, Richard Biener wrote:
> > > > On Fri, Nov 16, 2018 at 8:07 AM Uros Bizjak
On Tue, Nov 20, 2018 at 06:07:41PM +1030, Alan Modra wrote:
[snip]
> alternative. movdi_internal32 used "GHF" in an alternative (and
> always selected 64 byte insn length) so I replaced that with "F".
Huh, no, the insn didn't have length attributes.
> The FMOVE128 version of mov_softfloat also
Hi Christophe,
> On Sat, 10 Nov 2018 at 00:43, Martin Sebor wrote:
>>
>> On 11/09/2018 12:59 PM, Jeff Law wrote:
>> > On 10/31/18 10:27 AM, Martin Sebor wrote:
>> >> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01473.html
>> >>
>> >> With the C++ bits approved I'm still looking for a
Hi,
When backtrace_vector_release is called with vec.size == 0, it releases the
memory pointed at by vec.base.
In case of the backtrace_vector_release in alloc.c, vec.base may then be set
to NULL, but this is not guaranteed.
Set vec.base set to NULL if vec.size == 0 to ensure we don't point to
Hi,
If realloc is called with size 0, realloc can return NULL.
When this happens in the backtrace_vector_release in alloc.c, the error
callback is called, which should not be the case.
Fix this by testing for size == 0 before calling the error callback.
Build and tested on x86_64, with mmap.c
On Sat, 10 Nov 2018 at 00:43, Martin Sebor wrote:
>
> On 11/09/2018 12:59 PM, Jeff Law wrote:
> > On 10/31/18 10:27 AM, Martin Sebor wrote:
> >> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01473.html
> >>
> >> With the C++ bits approved I'm still looking for a review/approval
> >> of the
On Thu, Nov 22, 2018 at 1:03 PM Uros Bizjak wrote:
> > > Thanks for the comments!
> > > I have addressed them as attached.
> >
> > Hi.
> >
> > Can you please add the new march into:
> >
> > - gcc/doc/extend.texi:20530
> > - gcc/testsuite/gcc.target/i386/builtin_target.c - test it here
>
> IIRC,
On Thu, Nov 22, 2018 at 12:48 PM Martin Liška wrote:
>
> On 11/22/18 8:07 AM, Wei Xiao wrote:
> > Jakub,
> >
> > Thanks for the comments!
> > I have addressed them as attached.
>
> Hi.
>
> Can you please add the new march into:
>
> - gcc/doc/extend.texi:20530
> -
On 11/22/18 8:07 AM, Wei Xiao wrote:
> Jakub,
>
> Thanks for the comments!
> I have addressed them as attached.
Hi.
Can you please add the new march into:
- gcc/doc/extend.texi:20530
- gcc/testsuite/gcc.target/i386/builtin_target.c - test it here
Thanks,
Martin
On Mon, Nov 12, 2018 at 03:52:42PM -0500, Fritz Reese wrote:
> On Mon, Nov 12, 2018 at 3:42 PM Jakub Jelinek wrote:
> > Ok, so I'll ack it for trunk now, but please give the other Fortran
> > maintainers one day to disagree before committing.
> > For the release branches, I'd wait two weeks or so
* g++.dg/lto/odr-2_0.C: Remove extra brace
diff --git a/gcc/testsuite/g++.dg/lto/odr-2_0.C
b/gcc/testsuite/g++.dg/lto/odr-2_0.C
index 222fa2c1db..3ebb49efa2 100644
--- a/gcc/testsuite/g++.dg/lto/odr-2_0.C
+++ b/gcc/testsuite/g++.dg/lto/odr-2_0.C
@@ -1,5 +1,5 @@
// { dg-lto-do link }
-//
Hi!
In the -fdec-include thread, Mark raised privately that some compilers
(verified on fortran.godbolt.org for ifort only myself) do not pad
fixed-form lines to the line length like gfortran does. Usually it makes no
difference, but if a string constant is continued, it does (including when
it
On Wed, 21 Nov 2018, Richard Biener wrote:
>
> My previous fix for PR87229 was too aggressive. The following
> simply teaches the LTO streamer to deal with CALL_EXPRs, support
> for which was already in place. I've amended it with two
> missing pieces, streaming of CALL_EXPR_BY_DESCRIPTOR and
On Thu, Nov 22, 2018 at 10:21:53AM +0100, Andreas Schwab wrote:
> On Nov 22 2018, Jakub Jelinek wrote:
>
> > Is that with --enable-checking=release
>
> Yes.
Ok, reproduced myself, fixed thusly, committed to unbreak it.
cp_expr has
operator tree () const { return m_value; }
tree &
On 26/10/18 14:02 +0200, Marc Glisse wrote:
Index: libstdc++-v3/include/bits/stl_iterator.h
===
--- libstdc++-v3/include/bits/stl_iterator.h(revision 265522)
+++ libstdc++-v3/include/bits/stl_iterator.h(working copy)
@@
On Nov 22 2018, Jakub Jelinek wrote:
> Is that with --enable-checking=release
Yes.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On 20/11/18 17:58 -0500, Ed Smith-Rowland wrote:
On 11/19/18 6:13 AM, Jonathan Wakely wrote:
On 16/11/18 19:39 -0500, Ed Smith-Rowland wrote:
@@ -322,67 +323,43 @@
//@{
/// Return new complex value @a x plus @a y.
template
- inline complex<_Tp>
+ inline _GLIBCXX20_CONSTEXPR
>From backtrace.h for backtrace_create_state:
Calling this function allocates resources that can not be freed.
There is no backtrace_free_state function. The state is used to
cache information that is expensive to recompute. Programs are
expected to call this function at most once
On Thu, Nov 22, 2018 at 09:53:13AM +0100, Andreas Schwab wrote:
> In file included from ../../gcc/c-family/c-common.h:26:0,
> from ../../gcc/cp/cp-tree.h:40,
> from ../../gcc/cp/parser.c:25:
> ../../gcc/cp/parser.c: In function 'cp_expr
On 11/20/18 7:11 PM, Joseph Myers wrote:
> On Tue, 20 Nov 2018, Jakub Jelinek wrote:
>
>> hardcoding /usr/include looks just very wrong here. That should always be
>> dependent on the configured prefix or better be relative from the driver,
>> gcc should be relocatable. Or at least come from
In file included from ../../gcc/c-family/c-common.h:26:0,
from ../../gcc/cp/cp-tree.h:40,
from ../../gcc/cp/parser.c:25:
../../gcc/cp/parser.c: In function 'cp_expr cp_parser_operator(cp_parser*,
location_t)':
../../gcc/tree.h:383:33: error: invalid cast from
On Thu, Nov 22, 2018 at 8:08 AM Wei Xiao wrote:
>
> Jakub,
>
> Thanks for the comments!
> I have addressed them as attached.
>
> Wei
>
> gcc/
> * common/config/i386/i386-common.c (processor_names): Add cascadelake.
> (processor_alias_table): Add cascadelake.
> *
On Wed, Nov 21, 2018 at 11:21 PM Jakub Jelinek wrote:
>
> Hi!
>
> As I wrote in the PR, before PR81708 commits,
> while i386 defaulted to SSP_TLS rather than SSP_GLOBAL on everything but
> Android, the -mstack-protector-guard= switch controlled pretty much
> whether the i386.md special stack
On Tue, Nov 20, 2018 at 04:59:46PM -0500, Jason Merrill wrote:
> On 11/19/18 5:12 PM, Marek Polacek wrote:
>> > + /* Don't forget that the innermost namespace might have been
>> > + marked as inline. */
>> > + is_inline |= nested_inline_p;
>> This looks wrong: an inline namespace does not
On 11/22/18 8:54 AM, Andrew Pinski wrote:
> One small comment.
>
> On Tue, Nov 20, 2018 at 10:01 AM Christoph Muellner
> wrote:
>>
>> Tested with "make check" and no regressions found.
>>
>> This patch depends on the struct xgene1_prefetch_tune,
>> which has been acknowledged already:
>>
81 matches
Mail list logo
