On Tue, 9 Jan 2018, Prathamesh Kulkarni wrote:
As Jakub pointed out for the case:
void *f()
{
return __builtin_malloc (0);
}
The malloc propagation would set f() to malloc.
However AFAIU, malloc(0) returns NULL (?) and the function shouldn't
be marked as malloc ?
Why not? Even for
void*f(){r
On Thu, 11 Jan 2018, Marc Glisse wrote:
On Thu, 11 Jan 2018, François Dumont wrote:
- void _M_swap_data(_Vector_impl& __x) _GLIBCXX_NOEXCEPT
+ void
+ _M_swap_data(_Vector_impl_data& __x) _GLIBCXX_NOEXCEPT
{
std::swap(_M_start, __x._M_start);
std::swap(
On Thu, 11 Jan 2018, François Dumont wrote:
- void _M_swap_data(_Vector_impl& __x) _GLIBCXX_NOEXCEPT
+ void
+ _M_swap_data(_Vector_impl_data& __x) _GLIBCXX_NOEXCEPT
{
std::swap(_M_start, __x._M_start);
std::swap(_M_finish, __x._M_finish);
st
Hi
Here is an updated patch.
Tested under Linux x86_64.
Ok to commit ?
François
On 21/08/2017 21:15, François Dumont wrote:
Following feedback on std::list patch this one had the same problem of
unused code being deleted. So here is a new version.
Ok to commit ?
François
On
On 11 January 2018 at 10:34, Prathamesh Kulkarni
wrote:
> On 11 January 2018 at 04:50, Jeff Law wrote:
>> On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
>>>
>>> As Jakub pointed out for the case:
>>> void *f()
>>> {
>>> return __builtin_malloc (0);
>>> }
>>>
>>> The malloc propagation would
On 01/10/2018 06:30 PM, H.J. Lu wrote:
On Sat, Jan 6, 2018 at 2:04 PM, Martin Sebor wrote:
Bug 83671 - Fix for false positive reported by -Wstringop-overflow
does not work at -O1, points out that the string length range
optimization implemented as a solution for bug 83373 doesn't help
at -O1.
On 11 January 2018 at 04:50, Jeff Law wrote:
> On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
>>
>> As Jakub pointed out for the case:
>> void *f()
>> {
>> return __builtin_malloc (0);
>> }
>>
>> The malloc propagation would set f() to malloc.
>> However AFAIU, malloc(0) returns NULL (?) and
This libgo patch fixes the handling of DW_FORM_strp when using 64-bit
DWARF. This is an early backport of https://golang.org/cl/84379,
which will be in Go 1.11.
Backporting now for AIX support in gccgo. Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index:
On Sat, Jan 6, 2018 at 2:04 PM, Martin Sebor wrote:
> Bug 83671 - Fix for false positive reported by -Wstringop-overflow
> does not work at -O1, points out that the string length range
> optimization implemented as a solution for bug 83373 doesn't help
> at -O1. The root cause is that the fix was
On 01/10/2018 06:14 AM, Jakub Jelinek wrote:
> On Wed, Jan 10, 2018 at 02:08:48PM +0100, Richard Biener wrote:
>> On Wed, Jan 10, 2018 at 11:18 AM, Eric Botcazou
>> wrote:
It's really just a couple of new primitives to emit a jump as a call and
one to slam in a new return address. Give
On 01/08/2018 07:23 AM, Alan Modra wrote:
> On Sun, Jan 07, 2018 at 04:36:20PM -0700, Jeff Law wrote:
>> On 01/07/2018 03:58 PM, H.J. Lu wrote:
>>> This set of patches for GCC 8 mitigates variant #2 of the speculative
>>> execution
>>> vulnerabilities on x86 processors identified by CVE-2017-5715,
On 01/09/2018 08:29 AM, Richard Earnshaw (lists) wrote:
> I'm in two minds about that. There are certainly cases where you might
> want to use the generic expansion as part of handling a case where you
> have a more standard speculation barrier; in those cases you might want
> to emit your barrier
Hi again,
thus the below is a rather "dull" solution at the level of
cplus_decl_attributes itself: cp_check_const_attributes is tweaked to
check for error_mark_node at each outer iteration and consistently
return a bool, which is then checked by the caller in order to possibly
bail out (this
On 01/09/2018 03:47 AM, Richard Earnshaw (lists) wrote:
> On 05/01/18 13:08, Alexander Monakov wrote:
>> On Fri, 5 Jan 2018, Richard Earnshaw (lists) wrote:
>>> This is quite tricky. For ARM we have to have a speculated load.
>>
>> Sorry, I don't follow. On ARM, it is surprising that CSEL-CSDB-LDR
On Wed, 10 Jan 2018, Michael Meissner wrote:
> This patch is next in my series of patches to enable us to configure the long
> double type on PowerPC systems. This patch is only about the configuration
> option. A future patch will contain the multilib support.
In general we expect configure op
On 01/08/2018 02:03 PM, Bill Schmidt wrote:
>
> I agree 100% with this approach. I just wanted to raise the point in case
> other architectures have different needs. Power can work around this
> by just ignoring 4 of the 5 arguments. As long as nobody else needs
> *additional* arguments, this s
The compiler aborts on the assignment to an array component if the component
type is an atomic type and the array is subject to a Component_Size clause
that is too large for atomic access on the target. A proper error message
must be issued instead.
Tested on x86-64/Linux, applied on the mainl
On 01/09/2018 10:11 AM, Bill Schmidt wrote:
> On Jan 9, 2018, at 4:21 AM, Richard Earnshaw (lists)
> wrote:
>>
>> On 08/01/18 16:01, Bill Schmidt wrote:
>>> On Jan 8, 2018, at 8:06 AM, Richard Earnshaw (lists)
>>> wrote:
On 08/01/18 02:20, Bill Schmidt wrote:
> Hi Richard,
>
>
Thomas Koenig approved the patch in the PR.
Regression tested on x86_64-*-freebsd
2018-01-10 Steven G. Kargl
PR fortran/82367
* resolve.c (resolve_allocate_expr): Check for NULL pointer.
2018-01-10 Steven G. Kargl
PR fortran/82367
* gfortran.dg/deferred_cha
On 01/08/2018 09:01 AM, Bill Schmidt wrote:
> On Jan 8, 2018, at 8:06 AM, Richard Earnshaw (lists)
> wrote:
>>
>> On 08/01/18 02:20, Bill Schmidt wrote:
>>> Hi Richard,
>>>
>>> Unfortunately, I don't see any way that this will be useful for the ppc
>>> targets. We don't
>>> have a way to force
On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
>
> As Jakub pointed out for the case:
> void *f()
> {
> return __builtin_malloc (0);
> }
>
> The malloc propagation would set f() to malloc.
> However AFAIU, malloc(0) returns NULL (?) and the function shouldn't
> be marked as malloc ?
This se
The -fdump-ada-spec currently generates invalid Ada for preprocessor macros
containing floating-point constants and string concatenations.
Tested on x86-64/Linux, applied on the mainline.
2018-01-10 Eric Botcazou
c-family/
* c-ada-spec.c (dump_number): Add FLOAT_P parameter.
This adds naked function support to the RISC-V port. The basic structure was
copied from other ports, so there should be nothing unexpected here.
This was tested with a riscv64-linux build and make check. There were no
regressions. I also hand checked the info docs to make sure the extend.texi
On 12/30/2017 12:46 PM, Daniel van Gerpen wrote:
>
>
> When the code interpolates the contents of response files, the
> argument vector is reallocated to the new size. This only works
> if it was dynamically allocated once before -- we do not want to
> mess with the argv memory given to us by the
On Wed, Jan 10, 2018 at 08:41:17AM +0200, Janne Blomqvist wrote:
> On Wed, Jan 10, 2018 at 3:18 AM, Steve Kargl
> wrote:
> > When parsing code and implicit typing is used, the
> > type of an entity used as a character length is not
> > known until after resolution. The attach patch
> > checks the
This patch is next in my series of patches to enable us to configure the long
double type on PowerPC systems. This patch is only about the configuration
option. A future patch will contain the multilib support.
This patch needs the previous patch I submitted today (January 10th, 2018)
applied be
On Wed, Jan 10, 2018 at 03:19:49PM -0500, Michael Meissner wrote:
> As I add support for making -mabi=ieeelongdouble default, I noticed some
> issues
> in building libstdc++ with the default for the code that supports the
> -mlong-double-64 option. These tests add checks for -mlong-double-128 bef
> OK.
>
> Sorry for mucking things up and making more work :(
>
Not at all. I didn't know PHIs were going to behave that way either ;-).
Thanks for the review. Committed to trunk.
Aldy
On 01/10/2018 11:42 AM, Prathamesh Kulkarni wrote:
> Hi,
> I have attached patch for PR81703 rebased on Martin's fix for PR83501
> posted here since both had considerable overlaps:
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00180.html
>
> The patch passes bootstrap+test on x86_64-unknown-linu
On 01/10/2018 10:45 AM, Aldy Hernandez wrote:
>>> @@ -671,11 +668,9 @@ convert_control_dep_chain_into_preds (vec
>>> *dep_chains,
>>> e = one_cd_chain[j];
>>> guard_bb = e->src;
>>> gsi = gsi_last_bb (guard_bb);
>>> + /* Ignore empty BBs as they're basically forwarder
On 01/10/2018 12:21 PM, Martin Sebor wrote:
> On 01/10/2018 12:01 PM, Prathamesh Kulkarni wrote:
>> Hi,
>> The attached patch tries to fix PR83775.
>> Validation in progress.
>> OK to commit if passes ?
>
> FWIW, the patch makes sense to me as it simplifies things for
> me when debugging using a c
On 1/10/18 2:38 PM, Segher Boessenkool wrote:
> They don't have that name (they don't have any name).
>
> I often say things like
>
> (8 unnamed splitters): Likewise.
Ok, committed with the following updated ChangeLog which we discussed offline.
Thanks!
gcc/
PR target/83399
On 01/10/2018 09:25 AM, Sudakshina Das wrote:
> Hi Jeff
>
> On 10/01/18 10:44, Sudakshina Das wrote:
>> Hi Jeff
>>
>> On 09/01/18 23:43, Jeff Law wrote:
>>> On 01/05/2018 12:25 PM, Sudakshina Das wrote:
Hi Jeff
On 05/01/18 18:44, Jeff Law wrote:
> On 01/04/2018 08:35 AM, Sudaksh
On 01/09/2018 02:13 PM, David Malcolm wrote:
> Whilst developing the location-wrapper patch kit, I accumulated various
> source files for which my work-in-progress patched-cc1plus had different
> behavior to an unpatched cc1plus: some of these were crashes, others
> were erroneous diagnostics.
>
>
Passing a null pointer as argument to formatting functions corresponding to
the %s specifier makes the libc choke on old versions of Solaris 10. The
attached patchlet fixes a recently added case and thus eliminates:
-FAIL: gcc.dg/debug/debug-7.c -gdwarf-2 -O (internal compiler error)
-FAIL: gcc
On 01/06/2018 11:58 PM, Prathamesh Kulkarni wrote:
[ Snip ]
>> I think with those changes we're probably in good shape. But please
>> repost for final approval.
> I have the updated the attached version with your suggestions.
> Does it look OK ?
> Bootstrap+test passes on x86_64-unknown-linux-gnu
On 01/09/2018 01:26 AM, Nathan Rossi wrote:
> On 18 November 2017 at 22:13, Nathan Rossi wrote:
>> On 18 November 2017 at 04:25, Jeff Law wrote:
>>> On 11/15/2017 11:58 PM, Nathan Rossi wrote:
Remove the MicroBlaze specific TARGET_ASM_OUTPUT_IDENT definition, and
use the default.
>
On Wed, Jan 10, 2018 at 08:17:08PM +, Joseph Myers wrote:
> On Wed, 10 Jan 2018, Bernhard Reutner-Fischer wrote:
>
> > > >+/* x <= +Inf is the same as x == x, i.e. !isnan(x), but this
> > > >loses
> > > >+ an "invalid" exception. */
> > > >+(if (!flag_trapping_math)
When a function call is removed, it may become a leaf function. But if
argument may be passed on stack, we need to align the stack frame when
there is no tail call.
Tested on Linux/i686 and Linux/x86-64.
OK for trunk?
H.J.
---
gcc/
PR target/83330
* config/i386/i386.c (ix86_com
Hi,
On Wed, Jan 10, 2018 at 01:55:34PM -0600, Peter Bergner wrote:
> >> @@ -570,7 +570,7 @@ (define_split
> >> ;; The post-reload split requires that we re-permute the source
> >> ;; register in case it is still live.
> >> (define_split
> >> - [(set (match_operand:VSX_D 0 "memory_operand" "")
Okay will put on my to-do list for post GCC 8.
-Original Message-
From: James Greenhalgh [mailto:james.greenha...@arm.com]
Sent: Wednesday, January 10, 2018 12:21 PM
To: Michael Collison
Cc: Richard Sandiford ; GCC Patches
; nd
Subject: Re: [PATCH 5/5][AArch64] fp16fml support
On Tue,
To avoid issuing duplicate warnings for the same function call
in the source code the -Wrestrict warning code makes sure
the no-warning bit is propagated between trees and GIMPLE and
tested before issuing a warning. But the warning also detects
some of the same problems as -Wstringop-overflow, an
On 1/10/18 2:14 PM, Segher Boessenkool wrote:
> On Tue, Jan 09, 2018 at 04:09:25PM -0600, Peter Bergner wrote:
>> The following patch changes the x86 intrinsic compat headers to use #error
>> instead of #warning. We do this for two reasons. Firstly, we want the user
>> to really be sure they want
As I add support for making -mabi=ieeelongdouble default, I noticed some issues
in building libstdc++ with the default for the code that supports the
-mlong-double-64 option. These tests add checks for -mlong-double-128 before
considering whether TFmode/TCmode are IEEE or IBM extended double.
I w
On Wed, 10 Jan 2018, Bernhard Reutner-Fischer wrote:
> > >+ /* x <= +Inf is the same as x == x, i.e. !isnan(x), but this loses
> > >+ an "invalid" exception. */
> > >+ (if (!flag_trapping_math)
> > >+ (eq @0 @0
> > >+ /* x == +Inf and x >= +Inf are always equal to x > DBL_MAX, bu
On Tue, Jan 09, 2018 at 04:09:25PM -0600, Peter Bergner wrote:
> The following patch changes the x86 intrinsic compat headers to use #error
> instead of #warning. We do this for two reasons. Firstly, we want the user
> to really be sure they want/need to use the x86 intrinsic compat support
> bef
Hi,
On 10/01/2018 17:58, Jason Merrill wrote:
On Wed, Jan 10, 2018 at 11:33 AM, Paolo Carlini
wrote:
Hi,
On 10/01/2018 16:32, Jason Merrill wrote:
On Fri, Dec 22, 2017 at 7:34 PM, Paolo Carlini
wrote:
in this error recovery issue cp_check_const_attributes and more generally
cplus_decl_attr
On 1/10/18 1:44 PM, Segher Boessenkool wrote:
> On Tue, Jan 09, 2018 at 12:22:38PM -0600, Peter Bergner wrote:
>> * config/rs6000/rs6000.c (print_operand): Use
>> VECTOR_MEM_ALTIVEC_OR_VSX_P.
>
> (print_operand) <'y'>: ...
Will fix.
>> * config/rs6000/vsx.md (*vsx_le_perm_load_)
Thanks for the review!
James Greenhalgh writes:
> On Fri, Jan 05, 2018 at 11:41:25AM +, Richard Sandiford wrote:
>> Here's the patch updated to apply on top of the v8.4 and
>> __builtin_load_no_speculate support. It also handles the new
>> vec_perm_indices and CONST_VECTOR encoding and uses
The AIX stat function apparently uses an _st_timespec type. This
libgo patch by Tony Reix handles that correctly. Bootstrapped on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofront
All of the various parts of this kit have now been approved; I've
committed it to trunk as r256448.
(The initial version of the kit was posted 2017-10-20, and
the followup on 2017-11-10, both in stage 1; the final patch
approval was 2018-01-09, towards the end of stage 3).
Successfully bootstrapp
On Tue, Jan 09, 2018 at 12:22:38PM -0600, Peter Bergner wrote:
> PR83399 shows a problem where we emit an altivec load using a builtin
> that forces us to use a specific altivec load pattern. The generated
> rtl pattern has a use of sfp (frame pointer) and during LRA, we eliminate
> it's use to th
On 01/06/2018 03:04 PM, Martin Sebor wrote:
> Bug 83671 - Fix for false positive reported by -Wstringop-overflow
> does not work at -O1, points out that the string length range
> optimization implemented as a solution for bug 83373 doesn't help
> at -O1. The root cause is that the fix was added to
Joseph,
On Sat, Jan 06, 2018 at 08:45:33AM +0100, Richard Biener wrote:
> On January 5, 2018 10:13:34 PM GMT+01:00, Joseph Myers
> wrote:
> >unrelated. OK to commit?
>
> OK.
>
> Richard.
> >Index: gcc/match.pd
> >===
> >--- g
On 01/10/2018 12:01 PM, Prathamesh Kulkarni wrote:
Hi,
The attached patch tries to fix PR83775.
Validation in progress.
OK to commit if passes ?
FWIW, the patch makes sense to me as it simplifies things for
me when debugging using a cross-compiler. I reported the same
ICE in bug 83775 and it w
On Tue, Jan 09, 2018 at 06:28:09PM +, Michael Collison wrote:
> Patch updated per Richard's comments. Ok for trunk?
This patch adds a lot of code, much of which looks like it ought to be
possible to common up using the iterators. I'm going to OK it as is, as I'd
like to see this make GCC 8, an
This libgo patch by John Paul Adrian Glaubitz adds SH support to
libgo. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu,
which I admit doesn't prove much. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gc
On Fri, Jan 05, 2018 at 11:41:25AM +, Richard Sandiford wrote:
> Here's the patch updated to apply on top of the v8.4 and
> __builtin_load_no_speculate support. It also handles the new
> vec_perm_indices and CONST_VECTOR encoding and uses VNx... names
> for the SVE modes.
>
> Richard Sandifor
On 01/10/2018 11:46 AM, Martin Jambor wrote:
> Hello,
>
> I would really like to ping the FMA transformation prevention patch that
> I sent here in December, which, after incorporating a suggestion from
> Richi, re-base and re-testing, I re-post below. I really think that it
> should make into gc
Hi,
The attached patch tries to fix PR83775.
Validation in progress.
OK to commit if passes ?
Thanks,
Prathamesh
2018-01-11 Prathamesh Kulkarni
PR target/83775
* config/arm/arm.c (arm_declare_function_name): Set arch_to_print if
targ_options->x_arm_arch_string is non NU
Hello,
I would really like to ping the FMA transformation prevention patch that
I sent here in December, which, after incorporating a suggestion from
Richi, re-base and re-testing, I re-post below. I really think that it
should make into gcc 8 in some form, because the performance wins are
really
Hi,
I have attached patch for PR81703 rebased on Martin's fix for PR83501
posted here since both had considerable overlaps:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00180.html
The patch passes bootstrap+test on x86_64-unknown-linux-gnu
and cross-tested on aarch64-*-*.
Currently it fails to pa
On Tue, Jan 09, 2018 at 09:13:23PM -0800, Andrew Pinski wrote:
> On Tue, Jan 9, 2018 at 6:54 AM, Segher Boessenkool
> wrote:
> > On Tue, Jan 09, 2018 at 12:23:42PM +, Wilco Dijkstra wrote:
> >> Segher Boessenkool wrote:
> >> > On Mon, Jan 08, 2018 at 0:25:47PM +, Wilco Dijkstra wrote:
> >>
On 01/10/2018 07:48 AM, Georg-Johann Lay wrote:
> This patch adds a bit more the the avr section of the v8 release notes.
>
> Ok?
OK.
jeff
On 01/10/2018 10:46 AM, Aaron Sawdey wrote:
> This brings it back not quite to where it was but a lot more reasonable
> than what I put into 256351.
>
> 2018-01-10 Aaron Sawdey
>
> * gcc.dg/memcmp-1.c: Reduce runtime to something reasonable.
>
> OK for trunk?
>
> Thanks,
>Aaron
>
On January 10, 2018 6:28:57 PM GMT+01:00, Jeff Law wrote:
>On 01/10/2018 03:05 AM, Richard Biener wrote:
>>
>> This joint work rewrites LTO debug section copying to not leave
>> discarded sections around as SHT_NULL but to really discard them
>> and deal with the fallout (remapping all remaining
On Wed, Jan 10, 2018 at 7:43 AM, Rainer Orth
wrote:
> Hi Ian,
>
>> On Wed, Jan 10, 2018 at 3:44 AM, Rainer Orth
>> wrote:
>>>
>>> thanks. Testing has now concluded as well. x86 results are good (no
>>> regressions except for cmd/internal/buildid which fails on Linux, too),
>>> as are 64-bit spa
>> @@ -671,11 +668,9 @@ convert_control_dep_chain_into_preds (vec
>> *dep_chains,
>> e = one_cd_chain[j];
>> guard_bb = e->src;
>> gsi = gsi_last_bb (guard_bb);
>> + /* Ignore empty BBs as they're basically forwarder blocks. */
>> if (gsi_end_p (gsi))
>> -
This brings it back not quite to where it was but a lot more reasonable
than what I put into 256351.
2018-01-10 Aaron Sawdey
* gcc.dg/memcmp-1.c: Reduce runtime to something reasonable.
OK for trunk?
Thanks,
Aaron
--
Aaron Sawdey, Ph.D. acsaw...@linux.vnet.ibm.com
050-2/C113
On 01/10/2018 03:05 AM, Richard Biener wrote:
>
> This joint work rewrites LTO debug section copying to not leave
> discarded sections around as SHT_NULL but to really discard them
> and deal with the fallout (remapping all remaining section references).
> This is to avoid diagnostics from the Sol
On Wed, Jan 10, 2018 at 11:56 AM, Jakub Jelinek wrote:
> On Wed, Jan 10, 2018 at 11:52:16AM -0500, Jason Merrill wrote:
>> On Fri, Jan 5, 2018 at 5:14 PM, Jakub Jelinek wrote:
>> > Jason's recent change removed a mark_rvalue_use call from constant_value_1,
>> > which unfortunately regressed quite
On Wed, Jan 10, 2018 at 11:33 AM, Paolo Carlini
wrote:
> Hi,
>
> On 10/01/2018 16:32, Jason Merrill wrote:
>>
>> On Fri, Dec 22, 2017 at 7:34 PM, Paolo Carlini
>> wrote:
>>>
>>> in this error recovery issue cp_check_const_attributes and more generally
>>> cplus_decl_attributes have lots of troubl
On Wed, Jan 10, 2018 at 11:25 AM, Jakub Jelinek wrote:
> On Wed, Jan 10, 2018 at 10:46:06AM -0500, Jason Merrill wrote:
>> >> This patch moves the warning tiny bit earlier (from build_cxx_call to the
>> >> caller) where we still have information about the original parsed
>> >> arguments before con
On Wed, Jan 10, 2018 at 11:52:16AM -0500, Jason Merrill wrote:
> On Fri, Jan 5, 2018 at 5:14 PM, Jakub Jelinek wrote:
> > Jason's recent change removed a mark_rvalue_use call from constant_value_1,
> > which unfortunately regressed quite a few cases where
> > -Wunused-but-set-variable now has fals
OK.
On Tue, Jan 2, 2018 at 9:51 AM, Marek Polacek wrote:
> This PR complains about a bogus -Wduplicated-branches warning with a non-type
> template argument. That can be easily fixed with a new sentinel. I also
> noticed a missing tf_warning warning check, so I added it for good measure.
>
> Bo
On Fri, Jan 5, 2018 at 5:14 PM, Jakub Jelinek wrote:
> Jason's recent change removed a mark_rvalue_use call from constant_value_1,
> which unfortunately regressed quite a few cases where
> -Wunused-but-set-variable now has false positives.
> The easiest fix seems to be just deal with the -Wunused
Hi,
On 10/01/2018 16:32, Jason Merrill wrote:
On Fri, Dec 22, 2017 at 7:34 PM, Paolo Carlini wrote:
in this error recovery issue cp_check_const_attributes and more generally
cplus_decl_attributes have lots of troubles handling the error_mark_node
returned by cp_parser_std_attribute_spec_seq, a
On Wed, Jan 10, 2018 at 10:46:06AM -0500, Jason Merrill wrote:
> >> This patch moves the warning tiny bit earlier (from build_cxx_call to the
> >> caller) where we still have information about the original parsed
> >> arguments before conversions to the builtin argument types.
>
> OK.
Is that an
Hi Jeff
On 10/01/18 10:44, Sudakshina Das wrote:
Hi Jeff
On 09/01/18 23:43, Jeff Law wrote:
On 01/05/2018 12:25 PM, Sudakshina Das wrote:
Hi Jeff
On 05/01/18 18:44, Jeff Law wrote:
On 01/04/2018 08:35 AM, Sudakshina Das wrote:
Hi
The bug reported a particular test di-longlong64-sync-1.c f
On Fri, Jan 5, 2018 at 6:37 PM, Martin Sebor wrote:
> On 01/05/2018 03:02 PM, Jakub Jelinek wrote:
>>
>> Hi!
>>
>> Apparently LLVM allows similar warning to -Wclass-memaccess (is it just
>> similar or same?; if the latter, perhaps we should use the same option for
>> that) to be disabled not just
Hi Ian,
> On Wed, Jan 10, 2018 at 3:44 AM, Rainer Orth
> wrote:
>>
>> thanks. Testing has now concluded as well. x86 results are good (no
>> regressions except for cmd/internal/buildid which fails on Linux, too),
>> as are 64-bit sparc results.
>
> The cmd/internal/buildid test does pass on my
On Thu, Jan 4, 2018 at 6:53 PM, Martin Sebor wrote:
>
> PR 82922 asks to enable -Wstrict-prototypes. The attached
> patch handles the errors in an x86_64 bootstrap. With it,
> GCC bootstraps successfully with --enable-languages=all,jit,
> but there are many FAILs in the test suite but I think th
On 01/10/2018 04:22 PM, Ian Lance Taylor wrote:
Ok, so basically we should end up having only two GOARCHes for SH,
being "sh" and "shbe", correct?
Yes, I would like to start there.
If, yes, I can rebase my patch, make the requested changes and resubmit
it to Gerrit.
Thanks!
Done: https://g
This libgo patch removes the exp/proxy and exp/terminal packages.
The exp/proxy package was removed from the master library in
https://golang.org/cl/6461056 (August, 2012).
The exp/terminal package was removed from the master library in
https://golang.org/cl/5970044 (March, 2012).
I'm not sure w
On Fri, Dec 22, 2017 at 7:34 PM, Paolo Carlini wrote:
> in this error recovery issue cp_check_const_attributes and more generally
> cplus_decl_attributes have lots of troubles handling the error_mark_node
> returned by cp_parser_std_attribute_spec_seq, as called by
> cp_parser_direct_declarator. I
On Wed, Jan 10, 2018 at 7:05 AM, John Paul Adrian Glaubitz
wrote:
> On 01/10/2018 03:51 PM, Ian Lance Taylor wrote:
>>
>> I suppose I shouldn't have said calling convention, as that cuts too
>> finely. There are similar issues with MIPS and even x86 has softfloat
>> variants. Those options are s
I'll check the runtime of that --- I added some test cases to memcmp-
1.c and probably it is now taking too long. I will revise it so it's no
longer than it was before.
Aaron
On Wed, 2018-01-10 at 14:25 +, Szabolcs Nagy wrote:
> On 08/01/18 19:37, Aaron Sawdey wrote:
> > On Tue, 2017-12-12
On Fri, Jun 09, 2017 at 03:46:41PM -0700, Jason Merrill wrote:
> Something that was missed previously in the delayed folding work:
> there's no good reason to be pulling values out of constants in
> convert_like_real.
Well, it breaks nontype10.C on 32-bit targets.
Or, let's use a modified version
On Wed, Jan 10, 2018 at 6:34 AM, Ian Lance Taylor wrote:
>
> Thanks. I think https://golang.org/cl/87137 will fix it.
Committed as follows.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 256431)
++
On 10 January 2018 at 15:44, Jakub Jelinek wrote:
> On Mon, Oct 23, 2017 at 02:30:24PM +0200, Christophe Lyon wrote:
>> After Jakub's suggestion in PR82120 and PR81184, the attached patch
>> adds the -mbranch-cost option to the ARM target. My understanding
>> is that it's intended to be used inter
OK.
On Thu, Dec 21, 2017 at 2:21 PM, Paolo Carlini wrote:
> Hi,
>
> On 21/12/2017 17:04, Jason Merrill wrote:
>>
>> On Wed, Dec 20, 2017 at 10:37 AM, Paolo Carlini
>> wrote:
>>>
>>> in this error recovery regression, after a sensible error produced by
>>> unqualified_name_lookup_error we ICE muc
On 01/10/2018 03:51 PM, Ian Lance Taylor wrote:
I suppose I shouldn't have said calling convention, as that cuts too
finely. There are similar issues with MIPS and even x86 has softfloat
variants. Those options are selectable via command line options in
GCC, and in the gc toolchain they are sel
On Wed, Jan 10, 2018 at 5:42 AM, Ian Lance Taylor wrote:
>
> Whoops, there's a bug on big-endian 32-bit systems. I'm testing
> https://golang.org/cl/87135.
Committed as follows.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gof
On 01/10/2018 02:13 PM, Richard Biener wrote:
> On Tue, Jan 9, 2018 at 7:29 PM, Jeff Law wrote:
>> On 01/09/2018 07:43 AM, Martin Liška wrote:
>>> On 09/20/2017 05:00 PM, Jeff Law wrote:
On 09/20/2017 01:24 AM, Martin Liška wrote:
>
> Hello.
>
> Thank you Jeff for very ve
On Wed, Jan 10, 2018 at 3:44 AM, Rainer Orth
wrote:
>
> thanks. Testing has now concluded as well. x86 results are good (no
> regressions except for cmd/internal/buildid which fails on Linux, too),
> as are 64-bit sparc results.
The cmd/internal/buildid test does pass on my system. What are yo
In various of our 32-bit load_toc patterns we take the difference of
two immediates (labels) as a term to something bigger; but this isn't
canonical RTL, it needs to be wrapped in CONST.
This fixes it. Tested on powerpc64-linux {-m32,-m64}. Committing.
Segher
2018-01-10 Segher Boessenkool
Applied.
Richard.
2018-01-10 Richard Biener
PR testsuite/78768
* gcc.dg/pr78768.c: Un-XFAIL.
Index: gcc/testsuite/gcc.dg/pr78768.c
===
--- gcc/testsuite/gcc.dg/pr78768.c (revision 256428)
+++ gcc/testsuite/
On Wed, Jan 10, 2018 at 6:30 AM, Oleg Endo wrote:
> On Wed, 2018-01-10 at 06:25 -0800, Ian Lance Taylor wrote:
>>
>> Thanks. I finally took a look at this. I don't know much about SH,
>> but I don't think we want to add each SH variant as a separate GOARCH
>> value. As you can see from the list
This patch adds a bit more the the avr section of the v8 release notes.
Ok?
Johann
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.25
diff -r1.25 changes.html
240a241,246
>
>
On 01/10/2018 03:40 PM, Ian Lance Taylor wrote:
The main purpose of a GOARCH value is to specify build targets, which
are the +build lines seen in files like
libgo/go/internal/syscall/unix/getrandom_linux_mipsx.go. They also
appear in file names. It seems to me unlikely that it will ever be
nec
1 - 100 of 138 matches
Mail list logo
