On 03/02/2018 09:44 AM, David Malcolm wrote:
> The comment at the top of cp-demangle.c lists:
> http://www.codesourcery.com/cxx-abi/abi.html#mangling
> which redirects to:
> https://mentorembedded.github.io/cxx-abi/abi.html#mangling
> but this is a 404: the latter site is empty.
>
> I looked
On 03/02/2018 01:17 AM, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping 2 patches:
>
> http://gcc.gnu.org/ml/gcc-patches/2018-02/msg01340.html
> - PR target/84524 avx512* wrong-code bug
Hoping Kirill will chime in here.
>
> http://gcc.gnu.org/ml/gcc-patches/2018-02/msg01337.html
> - fix
On 03/01/2018 08:19 AM, Kyrill Tkachov wrote:
> Ping.
>
> Thanks,
> Kyrill
>
> On 19/02/18 11:35, Kyrill Tkachov wrote:
>> Ping.
>>
>> https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00649.html
>>
>> CC'ing Eric and Jeff as the patch contains a simplify-rtx.c component
>> that I'll need midend
On March 2, 2018 6:11:40 PM GMT+01:00, Jeff Law wrote:
>On 03/01/2018 06:57 AM, Richard Biener wrote:
>>
>> This fixes another testcase that shows that our ANTIC iteration can
>> fail to converge. The fix continues what we did with previous fixes,
>> avoid spuriously removing
On Fri, Mar 02, 2018 at 01:17:55PM -0500, Jason Merrill wrote:
> Actually, this is redundant; an expression can only be dependent if
> processing_template_decl. I'll fix.
Ah, that makes a lot of sense. Thanks,
Marek
Hello Michael,
I tried running the whole GCC test suite on the current head (without my
patch) along with 'microblaze-qemu' but I have the following problems:
1) The test is hanging at 'gcc.c-torture/string-large-1.c' , the gcc is
making a 100% CPU usage and the machine stucks.
I tried compiling
On 03/02/2018 09:36 AM, Thomas Schwinge wrote:
> Hi!
>
> On Thu, 16 Nov 2017 15:33:40 +, "Koval, Julia"
> wrote:
>> Hi, this patch removes cilkplus.
>
> I noticed a few remaining bits, that I convinced myself are obvious
> enough; committed to trunk in r258141:
>
>
This patch updates the release notes to mention SVE. OK to install?
Thanks,
Richard
Index: wwwdocs/htdocs/gcc-8/changes.html
===
--- wwwdocs.orig/htdocs/gcc-8/changes.html
+++ wwwdocs/htdocs/gcc-8/changes.html
@@ -243,7 +243,18 @@
Hi!
branch_predictor::probability has int type, so using -1U produces
-Wnarrowing warning.
Fixed thusly, committed as obvious to trunk.
2018-03-02 Jakub Jelinek
* predict.c (test_prediction_value_range): Use PROB_UNINITIALIZED
instead of -1U in last
On 03/02/2018 09:38 AM, Thomas Schwinge wrote:
> Hi!
>
> On Fri, 26 Jan 2018 16:24:48 +0100, Martin Liška wrote:
>> This fixes detection of ifunc target capability.
>> I'm going to install the patch.
>
> You could also just have approved the patch I had sent two months before:
>
Hi all,
I'm pinging this patch
(https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00444.html)
now that Jeff has approved the prerequisite simplify-rtx.c change
(https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00143.html) (thanks!)
Thanks,
Kyrill
On 08/02/18 17:10, Kyrill Tkachov wrote:
Hi all,
We ICE in cxx_eval_vec_init_1 whereby we try to initialize a flexible array
member, because the code computing the number of elements of ATYPE wasn't
prepared to handle arrays with no bounds. Fixed by using
get_array_or_vector_nelts, broken out of existing code.
Martin suggested to reject this
Hi,
This is a backport of the relevant pieces to fix pr84371 (builtins-3.c
fails on Power9) in the gcc-7 branch.
sniff-tested OK on p7,p8,p9.
OK for backport to gcc-7 ?
Thanks,
-Will
[testsuite]
2018-03-02 Will Schmidt
Backport from trunk.
PR
Jason, Jakub,
I've simplified the testcase Padraig provided and attached it to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84497
Notice that 'Base::Base ()' is not a constexpr ctor, because the integer
member is not initialized. That means 10.1.4/4.5 is unsatisfied. So
struct Base gets
Hi!
On Mon, 20 Nov 2017 09:11:19 -0500, Jason Merrill wrote:
> On Sun, Nov 19, 2017 at 7:56 AM, Thomas Schwinge
> wrote:
> > OK to fix the first four issues as follows?
>
> OK.
>
> Reviewed-by: Jason Merrill
Better late than
Hi!
On Thu, 16 Nov 2017 15:33:40 +, "Koval, Julia"
wrote:
> Hi, this patch removes cilkplus.
I noticed a few remaining bits, that I convinced myself are obvious
enough; committed to trunk in r258141:
commit bd571ec47012c4ee50ef028024276ab02f5c15ec
Author: tschwinge
On Fri, Mar 2, 2018 at 8:55 AM, Jeff Law wrote:
> On 03/02/2018 09:38 AM, Thomas Schwinge wrote:
>> Hi!
>>
>> On Fri, 26 Jan 2018 16:24:48 +0100, Martin Liška wrote:
>>> This fixes detection of ifunc target capability.
>>> I'm going to install the patch.
>>
>>
OK.
On Fri, Mar 2, 2018 at 12:39 PM, Marek Polacek wrote:
> Let's beef up warn_for_sign_compare checks; we'd folded the operands
> and they could've become garbage.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-03-02 Marek Polacek
>
OK.
On Fri, Mar 2, 2018 at 12:37 PM, Marek Polacek wrote:
> This patch fixes an ICE-on-invalid by checking the result of mark_rvalue_use,
> similarly to perform_implicit_conversion_flags.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-03-02 Marek Polacek
OK.
On Fri, Mar 2, 2018 at 12:38 PM, Marek Polacek wrote:
> Another ICE-on-invalid where we should check for error_mark_node otherwise
> we're toast.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-03-02 Marek Polacek
>
> PR
On 03/02/2018 08:04 AM, Jakub Jelinek wrote:
> Hi!
>
> GCC predefines __SIZEOF_*__ macros for the types it provides, so that
> 1) one can easily test if those types are available
> 2) can use it even in places where sizeof is not usable, like preprocessor
>conditionals
> Unfortunately, this
On 03/02/2018 08:07 AM, Jakub Jelinek wrote:
> Hi!
>
> Similarly to the ia64 patch, on hppa __float128 seems to be conditionally
> provided (guarded with HPUX_LONG_DOUBLE_LIBRARY), so this patch also
> conditionally predefines __SIZEOF_FLOAT128__.
>
> Ok for trunk?
>
> 2018-03-02 Jakub Jelinek
On 03/01/2018 04:13 PM, Jakub Jelinek wrote:
> Hi!
>
> prev_real_insn doesn't skip over DEBUG_INSNs, on aarch64 on this
> testcase we get both -fcompare-debug failure and wrong-code with -g.
>
> Instead of adding yet another two:
> do
> insn = prev_real_insn (insn);
> while
On 03/01/2018 06:57 AM, Richard Biener wrote:
>
> This fixes another testcase that shows that our ANTIC iteration can
> fail to converge. The fix continues what we did with previous fixes,
> avoid spuriously removing stuff from the expression side of the sets.
> This time going full-in and
On 03/02/2018 11:25 AM, Jakub Jelinek wrote:
Hi!
Various spots in the FE don't really like if error_mark_node is deeply
embedded in expression operands, in this case tsubst_copy_and_build
creates CONVERT_EXPR on which
is_bitfield_expr_with_lowered_type ICEs.
Fixed
This patch teaches the nvptx BE how to process vector reductions with
large vector lengths. The original vector reduction finalizer won't work
because it uses a warp shuffle operations. Now that vectors may contain
multiple warps, they need to store the partial reductions into
shared-memory like
Hi!
Various spots in the FE don't really like if error_mark_node is deeply
embedded in expression operands, in this case tsubst_copy_and_build
creates CONVERT_EXPR on which
is_bitfield_expr_with_lowered_type ICEs.
Fixed by just returning error_mark_node (various
The attached patch generalizes the worker state propagation and
synchronization code to handle large vectors. When the vector_length is
larger than a CUDA warp, the nvptx BE will now use shared-memory to
spill-and-fill vector state when transitioning from vector-single mode
to vector partitioned.
On 03/02/2018 10:00 AM, Jakub Jelinek wrote:
> On Fri, Mar 02, 2018 at 09:55:22AM -0700, Jeff Law wrote:
>> On 03/02/2018 09:38 AM, Thomas Schwinge wrote:
>>> Hi!
>>>
>>> On Fri, 26 Jan 2018 16:24:48 +0100, Martin Liška wrote:
This fixes detection of ifunc target capability.
Let's beef up warn_for_sign_compare checks; we'd folded the operands
and they could've become garbage.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-03-02 Marek Polacek
PR c++/84171
* c-warn.c (warn_for_sign_compare): Bail out if any of the
On Fri, Mar 02, 2018 at 08:42:22AM +0100, Jakub Jelinek wrote:
> I've verified generated gcc.pot is the same between previous and this
> patch, except for line numbers in the comments, and if I comment out
> the (int) casts from dir.len in both one of fmtwarn and one of fmtwarn_n
> calls, gcc
The comment at the top of cp-demangle.c lists:
http://www.codesourcery.com/cxx-abi/abi.html#mangling
which redirects to:
https://mentorembedded.github.io/cxx-abi/abi.html#mangling
but this is a 404: the latter site is empty.
I looked on archive.org; the final version before the redirect
seems
Hi!
On Fri, 26 Jan 2018 16:24:48 +0100, Martin Liška wrote:
> This fixes detection of ifunc target capability.
> I'm going to install the patch.
You could also just have approved the patch I had sent two months before:
On 03/02/2018 09:49 AM, Richard Sandiford wrote:
> This patch updates the release notes to mention SVE. OK to install?
OK.
jeff
On 03/01/2018 06:57 AM, Richard Biener wrote:
>
> This fixes another testcase that shows that our ANTIC iteration can
> fail to converge. The fix continues what we did with previous fixes,
> avoid spuriously removing stuff from the expression side of the sets.
> This time going full-in and
On Mar 1, 2018 4:57 PM, "Jason Merrill" wrote:
> Ok.
>
> On Mar 1, 2018 4:40 PM, "Marek Polacek" wrote:
>
>> On Thu, Mar 01, 2018 at 01:56:50PM -0500, Jason Merrill wrote:
>> > On Thu, Mar 1, 2018 at 8:17 AM, Marek Polacek
>> wrote:
>>
As I mentioned in the PR, the problem here is that we're replacing a
constructor with a dispatcher function which doesn't look much like a
constructor. This patch adjusts make_dispatcher_decl to make it look
more like the functions it dispatches to, but other things are certain
to break for
On Fri, Mar 2, 2018 at 8:25 AM, Matthew Fortune wrote:
> Jason Merrill writes:
>> On Thu, Mar 1, 2018 at 7:02 AM, Matthew Fortune
>> wrote:
>> > Hi,
>> >
>> > It seems we have had a bug for some time that causes an ICE and
>> prevents
On Fri, Mar 2, 2018 at 2:57 AM, Alexandre Oliva wrote:
> On Feb 28, 2018, Jason Merrill wrote:
>
>> On Wed, Feb 28, 2018 at 12:24 AM, Alexandre Oliva wrote:
>>> + if (processing_template_decl)
>>> +result_type =
On 03/02/2018 12:42 AM, Jakub Jelinek wrote:
> On Thu, Mar 01, 2018 at 06:05:30PM -0700, Martin Sebor wrote:
>>> --- gcc/gimple-ssa-sprintf.c.jj 2018-02-27 23:16:19.747948912 +0100
>>> +++ gcc/gimple-ssa-sprintf.c2018-03-01 21:26:37.728861287 +0100
>>> @@ -592,14 +592,12 @@
This patch fixes an ICE-on-invalid by checking the result of mark_rvalue_use,
similarly to perform_implicit_conversion_flags.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-03-02 Marek Polacek
PR c++/84664
* typeck.c
Another ICE-on-invalid where we should check for error_mark_node otherwise
we're toast.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-03-02 Marek Polacek
PR c++/84663
* decl.c (cp_complete_array_type): Check error_mark_node.
*
On Fri, Mar 2, 2018 at 11:07 AM, Nathan Sidwell wrote:
> Jason, Jakub,
> I've simplified the testcase Padraig provided and attached it to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84497
>
> Notice that 'Base::Base ()' is not a constexpr ctor, because the integer
> member is
OK.
On Fri, Mar 2, 2018 at 2:57 AM, Alexandre Oliva wrote:
> On Feb 28, 2018, Jason Merrill wrote:
>
>> On Wed, Feb 28, 2018 at 7:06 AM, Alexandre Oliva wrote:
>>> We ICEd when returning a stmt expr that ends with an overloaded
>>>
On Fri, Mar 2, 2018 at 2:57 AM, Alexandre Oliva wrote:
> On Feb 28, 2018, Jason Merrill wrote:
>
>> On Wed, Feb 28, 2018 at 7:08 AM, Alexandre Oliva wrote:
>>> Don't allow the initializer expr to be NULL in a ctor initializer
>>> list,
OK.
On Fri, Mar 2, 2018 at 12:36 PM, Marek Polacek wrote:
> We ICE in cxx_eval_vec_init_1 whereby we try to initialize a flexible array
> member, because the code computing the number of elements of ATYPE wasn't
> prepared to handle arrays with no bounds. Fixed by using
>
The fix to the PR probably counts as obvious, but here it is, along
with a testcase. Changelogs below.
Regtested on i686-pc-linux-gnu.
Whoever reviews this, please feel free to commit.
Thanks,
Harald
2018-03-02 Harald Anlauf
PR fortran/71085
* trans-expr.c
On Fri, Mar 02, 2018 at 09:55:22AM -0700, Jeff Law wrote:
> On 03/02/2018 09:38 AM, Thomas Schwinge wrote:
> > Hi!
> >
> > On Fri, 26 Jan 2018 16:24:48 +0100, Martin Liška wrote:
> >> This fixes detection of ifunc target capability.
> >> I'm going to install the patch.
> >
> >
Hi,
this error recovery ICE happens only with -Os and is just a P5 - on the
other hand I would argue the reproducer isn't that exotic! - but seems
fixable easily and safely: cdtor_comdat_group immediately calls
DECL_ASSEMBLER_NAME on both arguments and of course crashes if they are
null.
The attached patch adjusts the existing goacc validate_dims target hook
and introduces a new goacc adjust_parallelism target hook. Now that
vector length is no longer hard-coded to 32, there are four different
ways to set it:
1) compiler default
2) explicitly via the vector_length clause
3)
On Fri, Mar 02, 2018 at 12:33:25PM -0600, Will Schmidt wrote:
> Hi,
> This is a backport of the relevant pieces to fix pr84371 (builtins-3.c
> fails on Power9) in the gcc-7 branch.
>
> sniff-tested OK on p7,p8,p9.
> OK for backport to gcc-7 ?
Okay. Thanks!
> 2018-03-02 Will Schmidt
The attached patch is the last one in the vector length extension
series. It consists of some tweaks to the libgomp nvptx plugin to
accommodate larger vectors along with two test cases.
I only added two test cases because there's really not much interesting
going on with longer vector lengths. We
All,
I would like to commit the attach patch, which fixes
a number of ICE's when simplification runs into a
size zero array. gfortran does not have a nice
easy way to determine if an array is size zero. Thus,
the new function is_size_zero_array was written after
staring at several gdb sessions.
On Fri, Mar 2, 2018 at 4:02 PM, Paolo Carlini wrote:
> this error recovery ICE happens only with -Os and is just a P5 - on the
> other hand I would argue the reproducer isn't that exotic! - but seems
> fixable easily and safely: cdtor_comdat_group immediately calls
>
The kernel builds with -fno-var-tracking-assignments. For MIPS (and
likely other delay slot targets) this results in DEBUG_INSNs appearing
in the IL and neither reorg.c nor resource.c is prepared for that.
I don't doubt there's more of these problems lurking, but this patch is
enough to get the
On Fri, Mar 02, 2018 at 03:18:05PM -0700, Jeff Law wrote:
> On 02/28/2018 03:43 AM, Richard Biener wrote:
> [ More snipping ]
>
> >
> >> It's actually pretty easy to fix the CFG. We just need to recognize
> >> that a "returns twice" function returns not to the call, but to the
> >> point
On 03/02/2018 04:07 PM, Jakub Jelinek wrote:
> On Fri, Mar 02, 2018 at 03:18:05PM -0700, Jeff Law wrote:
>> On 02/28/2018 03:43 AM, Richard Biener wrote:
>> [ More snipping ]
>>
>>>
It's actually pretty easy to fix the CFG. We just need to recognize
that a "returns twice" function
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators. The file is available at:
http://translationproject.org/latest/gcc/es.po
(This file, 'gcc-8.1-b20180128.es.po',
On 03/01/2018 01:26 PM, Palmer Dabbelt wrote:
+@item -mrelax
+@itemx -mno-relax
+Take advantage of linker relaxations to reduce the number of instructions
+required to materalize symbol addresses.
materalize->materialize
This is not just number of instructions, it is also code size, since
On 02/28/2018 03:43 AM, Richard Biener wrote:
[ More snipping ]
>
>> It's actually pretty easy to fix the CFG. We just need to recognize
>> that a "returns twice" function returns not to the call, but to the
>> point immediately after the call. So if we have a call to a returns
>> twice
Hi Christophe,
I was not aware. Thanks for letting me know.
It's wierd that there is no error message or an ICE. Previously, an
ICE would occur instead of the intended error message.
I do not have access to either targets. Would you be so kind as to run
coarray_47.f90 separately to see what
Hi!
On Tue, 27 Feb 2018 15:12:47 +0100, Richard Biener wrote:
> On Tue, 27 Feb 2018, Thomas Schwinge wrote:
> > Given that several users have run into this, is this (trunk r256891) OK
> > to commit to open release branches, too.
>
> Sure.
Committed to gcc-7-branch in
By golly you are right!
Je vous en remercie :-)
Paul
On 2 March 2018 at 08:41, Christophe Lyon wrote:
> On 2 March 2018 at 09:38, Paul Richard Thomas
> wrote:
>> Hi Christophe,
>>
>> I was not aware. Thanks for letting me know.
>>
>>
Hi,
this PR reports the failure of g++.dg/lto/pr83121 on multiple platforms.
There are 2 differents issues and this message is about the missing warning on
Aarch64 and SPARC. On these platforms the LTO compiler issues:
/home/ebotcazou/src/gcc/testsuite/g++.dg/lto/pr83121_0.C:6:8: warning:
On Thu, Mar 01, 2018 at 06:05:30PM -0700, Martin Sebor wrote:
> > --- gcc/gimple-ssa-sprintf.c.jj 2018-02-27 23:16:19.747948912 +0100
> > +++ gcc/gimple-ssa-sprintf.c2018-03-01 21:26:37.728861287 +0100
> > @@ -592,14 +592,12 @@ get_format_string (tree format, location
> > /* The
Hi!
I'd like to ping 2 patches:
http://gcc.gnu.org/ml/gcc-patches/2018-02/msg01340.html
- PR target/84524 avx512* wrong-code bug
http://gcc.gnu.org/ml/gcc-patches/2018-02/msg01337.html
- fix c-c++-common/Warray-bounds-2.c testcase for -fpic
Thanks
Jakub
On 1 March 2018 at 14:28, Paul Richard Thomas
wrote:
> Committed as 'obvious' in revision 258098.
>
> Paul
>
> 2018-03-01 Paul Thomas
>
> PR fortran/84219
> * target-memory.c (gfc_interpret_derived): Assert that BT_VOID
> components are caf
On 2 March 2018 at 09:38, Paul Richard Thomas
wrote:
> Hi Christophe,
>
> I was not aware. Thanks for letting me know.
>
> It's wierd that there is no error message or an ICE. Previously, an
> ICE would occur instead of the intended error message.
>
> I do not have
Hi Christophe,
I committed the wrong test :-( Corrected r258128.
Many thanks
Paul
On 2 March 2018 at 08:38, Paul Richard Thomas
wrote:
> Hi Christophe,
>
> I was not aware. Thanks for letting me know.
>
> It's wierd that there is no error message or an ICE.
On Fri, 2 Mar 2018, Jakub Jelinek wrote:
> On Fri, Mar 02, 2018 at 09:15:07AM +0100, Richard Biener wrote:
> > You probably need a virtual return thunk as otherwise we expand them
> > directly to asm?
>
> I was trying x86_64 -m32 -fpic regparm (3) method with thunks so that
> the asm isn't
On Fri, Mar 2, 2018 at 9:49 AM, Eric Botcazou wrote:
> Hi,
>
> this PR reports the failure of g++.dg/lto/pr83121 on multiple platforms.
>
> There are 2 differents issues and this message is about the missing warning on
> Aarch64 and SPARC. On these platforms the LTO
On Thu, Mar 1, 2018 at 7:20 PM, Richard Sandiford
wrote:
> ...since the latter doesn't guarantee independence by itself.
>
> Tested on aarch64-linux-gnu. OK to install?
Ok.
Richard.
> Richard
>
>
> 2018-03-01 Richard Sandiford
>
>
On Fri, Mar 02, 2018 at 09:15:07AM +0100, Richard Biener wrote:
> You probably need a virtual return thunk as otherwise we expand them
> directly to asm?
I was trying x86_64 -m32 -fpic regparm (3) method with thunks so that
the asm isn't emitted. But the thunk was still using call to .LTHUNKN
On Thu, 1 Mar 2018, Martin Sebor wrote:
> While testing my recent changes to the handling of attributes
> on C++ templates I noticed that the -finline-limit=N option
> is not recognized in attribute or pragma optimize. In response
> to the bug I raised, Richard you said the option is deprecated,
On Fri, 2 Mar 2018, Jakub Jelinek wrote:
> On Fri, Mar 02, 2018 at 08:58:34AM +0100, Richard Biener wrote:
> > On Fri, 2 Mar 2018, Jakub Jelinek wrote:
> >
> > > Hi!
> > >
> > > If we need to use thunks for ICF to functions with warning or error
> > > attribute, their expansion will warn or
On Thu, Mar 1, 2018 at 7:30 PM, Richard Sandiford
wrote:
> We were computing _VINFO_MASKS even for bb vectorisation,
> which is UB.
>
> Tested on aarch64-linux-gnu. OK to install?
Ok.
Richard.
> Richard
>
>
> 2018-03-01 Richard Sandiford
Hi!
Similarly to the ia64 patch, on hppa __float128 seems to be conditionally
provided (guarded with HPUX_LONG_DOUBLE_LIBRARY), so this patch also
conditionally predefines __SIZEOF_FLOAT128__.
Ok for trunk?
2018-03-02 Jakub Jelinek
PR target/56540
*
On Fri, Mar 02, 2018 at 08:58:34AM +0100, Richard Biener wrote:
> On Fri, 2 Mar 2018, Jakub Jelinek wrote:
>
> > Hi!
> >
> > If we need to use thunks for ICF to functions with warning or error
> > attribute, their expansion will warn or error. This patch just punts
> > in those cases instead.
>
On Fri, 2 Mar 2018, Jakub Jelinek wrote:
> Hi!
>
> On Fri, Mar 02, 2018 at 10:54:36AM +0100, Jakub Jelinek wrote:
> > On Fri, Mar 02, 2018 at 09:31:16AM +0100, Richard Biener wrote:
> > > On Fri, 2 Mar 2018, Jakub Jelinek wrote:
> > >
> > > > On Fri, Mar 02, 2018 at 09:15:07AM +0100, Richard
On Fri, Mar 02, 2018 at 09:31:16AM +0100, Richard Biener wrote:
> On Fri, 2 Mar 2018, Jakub Jelinek wrote:
>
> > On Fri, Mar 02, 2018 at 09:15:07AM +0100, Richard Biener wrote:
> > > You probably need a virtual return thunk as otherwise we expand them
> > > directly to asm?
> >
> > I was trying
Richard Biener writes:
> On Thu, Mar 1, 2018 at 12:38 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Wed, Feb 28, 2018 at 3:20 PM, Richard Sandiford
>>> wrote:
Hi,
I have made changes to this patch.
I attached a new version.
02.03.2018 Olga Makhotina
gcc/
* common/config/i386/i386-common.c (OPTION_MASK_ISA_PCONFIG_SET,
OPTION_MASK_ISA_PCONFIG_UNSET, OPTION_MASK_ISA_WBNOINVD_SET,
Jason Merrill writes:
> On Thu, Mar 1, 2018 at 7:02 AM, Matthew Fortune
> wrote:
> > Hi,
> >
> > It seems we have had a bug for some time that causes an ICE and
> prevents the
> > MIPS16 library builds from completing but is likely unrelated to
> MIPS16.
> >
Hi!
On Fri, Mar 02, 2018 at 10:54:36AM +0100, Jakub Jelinek wrote:
> On Fri, Mar 02, 2018 at 09:31:16AM +0100, Richard Biener wrote:
> > On Fri, 2 Mar 2018, Jakub Jelinek wrote:
> >
> > > On Fri, Mar 02, 2018 at 09:15:07AM +0100, Richard Biener wrote:
> > > > You probably need a virtual return
Hi!
GCC predefines __SIZEOF_*__ macros for the types it provides, so that
1) one can easily test if those types are available
2) can use it even in places where sizeof is not usable, like preprocessor
conditionals
Unfortunately, this isn't done for target types that the middle-end doesn't
know
85 matches
Mail list logo