Hi,
this patch fixes PR80855, an nvptx target bug where we generate invalid
ptx assembly when encountering label values.
Fixed by emitting "a sorry, unimplemented" message instead.
Tested on nvptx target.
Committed as obvious.
Thanks,
- Tom
Add "sorry, target cannot support label values" f
On June 9, 2017 10:07:36 PM GMT+02:00, Jason Merrill wrote:
>On Tue, May 23, 2017 at 5:52 PM, Jason Merrill
>wrote:
>> On Thu, May 18, 2017 at 11:03 PM, Martin Sebor
>wrote:
>>> On 05/18/2017 08:30 PM, Jason Merrill wrote:
I got tired of writing strcmp (IDENTIFIER_POINTER and decided t
Tested on Linux-x64.
2017-06-10 Ville Voutilainen
PR libstdc++/80675
PR libstdc++/80940
* include/std/istream:
(__is_convertible_to_basic_istream_test(basic_istream<_Ch, _Up>*)): New.
(__do_is_convertible_to_basic_istream_impl): Likewise.
(__is_convertible_to_basic_istr
On Thu, Jun 8, 2017 at 9:49 AM, Marek Polacek wrote:
> Jason - how about the C++ parts?
The C++ parts are OK.
Jason
My earlier patch for N4268 didn't implement the notion of converted
constant-expression, and as a result we weren't properly using
constexpr user-defined conversions to produce values for template
arguments.
Always performing these conversions led to some issues with
convert_nontype_argument getti
Hi again,
On Fri, Jun 09, 2017 at 04:12:25PM -0700, Carl E. Love wrote:
> On Fri, 2017-06-09 at 16:05 -0500, Segher Boessenkool wrote:
> > > +;; Mode iterator and attribute for vector floate and floato conversions
> > > +(define_mode_iterator VFC [V2DI V2DF])
> > > +(define_mode_attr VFC_inst [(V2
On 06/09/2017 01:47 PM, Thomas Koenig wrote:
Hello world,
the attached patch fixes the PR by not doing a replacement of
(a(i,i),i=1,3) by an array expression (which does not exist).
Regression-tested. OK for trunk?
OK, thanks
Regards
Thomas
2017-06-09 Thomas Koenig
PR
On 09/06/17 23:45, Christophe Lyon wrote:
> Hi Richard,
>
>
> On 9 June 2017 at 14:53, Richard Earnshaw wrote:
>>
>> During the ARM BoF at the Cauldron last year I mentioned that I wanted
>> to rework the way GCC on ARM handles the command line options. The
>> problem was that most users, and e
GCC Maintainers:
On Fri, 2017-06-09 at 16:05 -0500, Segher Boessenkool wrote:
Fixed the various formatting (spaces) issues. Been toying with how to
write a space checker for patches. Have to take some time to really
think about how to do that
> > +
> > + /* The vector merge instruction vm
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.
With that fixed, I needed to change cp_fully_fold to use
cp_fold_rvalue so that it would properly pull out constant values in
C++98 mode.
Tested x86
Hi Richard,
On 9 June 2017 at 14:53, Richard Earnshaw wrote:
>
> During the ARM BoF at the Cauldron last year I mentioned that I wanted
> to rework the way GCC on ARM handles the command line options. The
> problem was that most users, and even many experts, can't remember
> which FPU/SIMD unit
On Fri, 9 Jun 2017, Richard Earnshaw wrote:
> * doc/invoke.texi (ARM Options, -mcpu): Document supported
> extension options.
> (ARM Options, -mtune): Document that this accepts the same
> extension options as -mcpu.
> (ARM Options, -mfpu): Document addition of -mfpu=a
On Thu, 8 Jun 2017, David Malcolm wrote:
> How about:
>
> "Warn about unsafe multiple statement macros that appear to be guarded
> by a clause such as if, else, while, or for, in which only the first
> statement is actually guarded after the macro is expanded."
>
> or somesuch?
Yes, I like this.
Hi Carl,
A couple of issues, most small:
On Fri, Jun 09, 2017 at 11:20:43AM -0700, Carl E. Love wrote:
> +void
> +rs6000_generate_float2_code (bool signed_convert, rtx dst, rtx src1, rtx
> src2)
> +{
> + rtx rtx_tmp0, rtx_tmp1, rtx_tmp2, rtx_tmp3;
> +
> + rtx_tmp0 = gen_reg_rtx (V2DImode);
> +
This patch adds a method:
rich_location::fixits_cannot_be_auto_applied
for ensuring that mutually-incompatible fix-its hints don't
lead to insane output from -fdiagnostics-generate-patch.
Fix-it hints within such rich_location instances are printed
as normal by diagnostic_show_locus, but don't a
Hello world,
the attached patch fixes the PR by not doing a replacement of
(a(i,i),i=1,3) by an array expression (which does not exist).
Regression-tested. OK for trunk?
Regards
Thomas
2017-06-09 Thomas Koenig
PR fortran/80988
* frontend-passes.c (traverse_io_bloc
[temp.arg.nontype] talks about expressions of type nullptr_t, not
specifically the literal "nullptr".
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 8714be12f8ea82cc4efa0391a78e5ce9ccb067ad
Author: Jason Merrill
Date: Wed Jun 7 17:49:31 2017 -0700
Fix template argument of nullptr_t
> Eric, after some more testing it turns out that we need something
> more for gcc-5 and gcc-6 to cover all cases.
Hmm, yes, I should have thought of that...
> The problem is that before gcc-7, the compiler can emit return
> instructions directly without going through the epilogue expander.
That
On Tue, May 23, 2017 at 5:52 PM, Jason Merrill wrote:
> On Thu, May 18, 2017 at 11:03 PM, Martin Sebor wrote:
>> On 05/18/2017 08:30 PM, Jason Merrill wrote:
>>>
>>> I got tired of writing strcmp (IDENTIFIER_POINTER and decided to wrap
>>> it in an inline function. I decided to use "id_strcmp" i
Recent discussion on the C++ committee core language list pointed out
that we were wrongly rejecting use of an array variable as a template
argument for a pointer parameter, because we were asking whether the
array is constant. This patch corrects that check to consider the
address of the array ra
On Thu, May 25, 2017 at 2:25 AM, Richard Earnshaw (lists)
wrote:
> Having pondered this over night, I think the lowest risk thing to do,
> provided it applies cleanly to the gcc-7 branch, is just commit the
> entire patch on the branch and be done with it. The risk from removing
> this code is pr
If we're going to consider the noexcept-specifier for deduction, we
also need it to make the type dependent.
Tested x86_64-pc-linux-gnu, applying to trunk and 7.
commit c51759f129a602eeb835473e7c1480046757c12f
Author: Jason Merrill
Date: Wed May 31 17:39:50 2017 -0400
PR c++/80384
The constexpr code rejects uses of 'this' in a constant-expression,
but that shouldn't apply to a lambda 'this' capture proxy, which can
have a constant value.
Tested x86_64-pc-linux-gnu, applying to trunk and 7.
commit 1f69899dda31109c95ac4636eb66788449d6382e
Author: Jason Merrill
Date: Wed Ma
On Thu, Jun 8, 2017 at 12:30 PM, Jakub Jelinek wrote:
> Hi!
>
> cp_genericize_r now instruments INTEGER_CSTs that have REFERENCE_TYPE,
> so that we can diagnose binding references to NULL in some cases,
> see PR79572. As the following testcase shows, there is one exception
> when we do not want t
From: David Miller
Date: Tue, 06 Jun 2017 15:02:55 -0400 (EDT)
> From: David Miller
> Date: Mon, 05 Jun 2017 20:54:46 -0400 (EDT)
>
>> From: Eric Botcazou
>> Date: Tue, 06 Jun 2017 00:02:06 +0200
>>
That seems to work as well, following is going through a testsuite
run right now:
>>
On Fri, Jun 9, 2017 at 11:22 AM, Jan Hubicka wrote:
>> On Fri, Jun 9, 2017 at 3:16 AM, Jan Hubicka wrote:
>> >
>> >> code compiled with -fsplit-stack, if the cold partition calls a
>> >> function that is not compiled with -fsplit-stack (such as a C library
>> >> function). The problem is that wh
Hi,
this is patch I comitted.
Thanks!
Honza
* predict.c (unlikely_executed_stmt_p): Cleanup.
Index: predict.c
===
--- predict.c (revision 249057)
+++ predict.c (working copy)
@@ -780,7 +780,7 @@ unlikely_executed_stmt_p (g
> On Fri, Jun 9, 2017 at 3:16 AM, Jan Hubicka wrote:
> >
> >> code compiled with -fsplit-stack, if the cold partition calls a
> >> function that is not compiled with -fsplit-stack (such as a C library
> >> function). The problem is that when the linker sees a split-stack
> >> function call a non-
GCC Maintainers:
This patch adds support for the various vec_float, vec_float2,
vec_floate, vec_floate, builtins.
The patch has been tested on powerpc64le-unknown-linux-gnu (Power 8 LE)
and on powerpc64-unknown-linux-gnu (Power 8 BE) with no regressions.
Is the patch OK for gcc mainline?
2017-06-09 15:21 GMT+03:00 Alexander Ivchenko :
> Hi Ilya,
>
> I tried changing builtin call so it gets address of a decl instead of
> a decl, but it looked very unnatural and I hit some other problems
What is unnatural in passing a pointer to a function to get its bounds?
Please show your patch a
On 2017.06.09 at 14:17 +0200, Martin Liška wrote:
> Hello.
>
> I discussed with Honza possibility to speed-up instrumentation that we do for
> indirect call target tracking. By direct emission of:
>
> if (__gcov_indirect_call_callee != NULL)
>__gcov_indirect_call_profiler_v2 (profile
Hi,
this patch marks the obvious candidates for cold attribute and enables
cold auto-detection on some common coding patterns.
I have bootstrapped/regtested x86_64-linux and plan to commit it at
weekend once performance testers pick up this weeks changes if there
are no complains.
Honza
> On May 28, 2017, at 8:01 AM, Andrew Pinski wrote:
>
> On Tue, Feb 28, 2017 at 1:53 AM, Maxim Kuvyrkov
>>
...
>> Hi Kyrill,
>>
>> My hope was to push them in time for GCC 7, but it seems to late now. I'll
>> return to these patches at the beginning of Stage 1.
>
> Ping on this patch set as
> On Jun 8, 2017, at 7:32 PM, James Greenhalgh wrote:
>
> On Mon, Jan 30, 2017 at 03:08:04PM +0300, Maxim Kuvyrkov wrote:
>> This patch enables software prefetching at -O3 for Qualcomm's qdf24xx cores.
>>
>> Bootstrapped and regtested on x86_64-linux-gnu and aarch64-linux-gnu.
>
> This patch is
> On Jun 8, 2017, at 7:31 PM, James Greenhalgh wrote:
>
> On Fri, Feb 03, 2017 at 02:58:23PM +0300, Maxim Kuvyrkov wrote:
>>> On Jan 30, 2017, at 5:50 PM, Maxim Kuvyrkov
>>> wrote:
>>>
On Jan 30, 2017, at 3:23 PM, Kyrill Tkachov
wrote:
Hi Maxim,
On 30/01/17 12
> On Jun 9, 2017, at 1:04 PM, James Greenhalgh wrote:
>>>
...
>>> I disagree with having to write all these things out, but I do agree
>>> that we should be self-consistent within the port.
>>
>> I'm re-writing the patch with approach that James suggested, and instead of
>> AARCH64_PREFETCH_NOT_
> > + /* Optimize routines for MEM to REG copies. */ if (n < 8 &&
> > + !REG_P (XEXP (operands[0], 0)))
>
> This seems to be checking that the address of the original destination
> memory isn't a plain base register. Why's it important to reject that case
> but
> allow e.g. base+offset?
thi
On June 9, 2017 5:32:10 PM GMT+02:00, Christophe Lyon
wrote:
>On 8 June 2017 at 15:49, Richard Biener wrote:
>> On Thu, 8 Jun 2017, Richard Biener wrote:
>>
>>>
>>> The following fixes unsafe vectorization of reductions in outer loop
>>> vectorization. It combines it with a bit of cleanup in th
On 8 June 2017 at 15:49, Richard Biener wrote:
> On Thu, 8 Jun 2017, Richard Biener wrote:
>
>>
>> The following fixes unsafe vectorization of reductions in outer loop
>> vectorization. It combines it with a bit of cleanup in the affected
>> function.
>>
>> Bootstrap and regtest running on x86_64
On Jun 9, 2017, at 7:24 AM, Tom de Vries wrote:
> this patch adds effective target stack_size.
> OK for trunk if x86_64 and nvptx testing succeeds?
Ok.
The only last issue in this area that I know about is that there are a few more
test cases that need up to 48 MB to run, the problem is that t
On Jun 9, 2017, at 1:25 AM, Tom de Vries wrote:
>
> Atm, -DSIGNAL_SUPPRESS is defined at top-level in gcc_target_compile
> resulting in the macro being passed down to ~30k compilations. The macro is
> used in just 17 test cases.
> OK for trunk if x86_64 and nvptx testing succeeds?
Ok.
Hi,
this patch adds effective target stack_size.
Atm, -DSTACK_SIZE= is defined at top-level in gcc_target_compile
resulting in the macro being passed down to ~30k compilations. The macro
is used in just 37 testcases.
The patch defines an effective target stack_size, which is used in
indivi
On Wed, Apr 26, 2017 at 06:34:36AM +, Hurugalawadi, Naveen wrote:
> Hi Kyrill,
>
> Thanks for the review and your comments.
>
> >> It would be useful if you expanded a bit on the approach used to
> >> generate the improved codegen
>
> The patch creates a duplicate of most common element and
On Fri, Jun 9, 2017 at 3:16 AM, Jan Hubicka wrote:
>
>> code compiled with -fsplit-stack, if the cold partition calls a
>> function that is not compiled with -fsplit-stack (such as a C library
>> function). The problem is that when the linker sees a split-stack
>> function call a non-split-stack
On 21/02/17 16:54, charles.bay...@linaro.org wrote:
> From: Charles Baylis
>
> This patch adds support for modelling the varying costs of
> different addressing modes. The generic cost table treats
> all addressing modes as having equal cost. The cost table
> for Cortex-A57 is derived from
> htt
> gcc/ChangeLog:
>
> 2017-05-26 Martin Liska
>
> PR tree-optimization/79489
> * gimplify.c (maybe_add_early_return_predict_stmt): New
> function.
> (gimplify_return_expr): Call the function.
> * predict.c (tree_estimate_probability_bb): Remove handling
> of
> gcc/ChangeLog:
>
> 2017-05-26 Martin Liska
>
> * gimplify.c (gimplify_label_expr): Insert GIMPLE_PREDICT
> statements on cold and hot labels.
> * predict.c (tree_estimate_probability_bb): Remove the
> prediction from this place.
>
> gcc/testsuite/ChangeLog:
>
> 2017
On 21/02/17 16:54, charles.bay...@linaro.org wrote:
> From: Charles Baylis
>
> This patch moves the calculation of costs for MEM into a
> separate function, and reforms the calculation into two
> parts. Firstly any additional cost of the addressing mode
> is calculated, and then the cost of the m
This PR was raised because of a bootstrap failure on Darwin. The cause
was a mishandled exception raised by Rtsfind.Load_Fail while
processing g-exptty.adb. g-exptty.adb had been updated on 2017-04-25
(but so had a lot of other parts of GNAT). Since a lot of other
compilations had been performed su
On Fri, Jun 9, 2017 at 3:04 PM, Jakub Jelinek wrote:
> On Fri, Jun 09, 2017 at 02:35:45PM +0200, Richard Biener wrote:
>> +static bool
>> +gimple_fold_builtin_bcmp (gimple_stmt_iterator *gsi)
>> +{
>>
>> + /* Transform bcmp (a, b, len) into memcmp (a, b, len). */
>> +
>> + gimple *stmt = gsi_st
On Fri, Jun 9, 2017 at 2:51 PM, Martin Liška wrote:
> On 06/09/2017 02:27 PM, Richard Biener wrote:
>>
>> On Fri, Jun 9, 2017 at 2:08 PM, Martin Liška wrote:
>>>
>>> On 06/09/2017 01:05 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 12:49 PM, Martin Liška wrote:
>
>
On Thu, Jun 8, 2017 at 12:13 PM, Martin Sebor wrote:
> On 06/08/2017 11:00 AM, H.J. Lu wrote:
>>
>> On Wed, Jun 7, 2017 at 6:30 AM, H.J. Lu wrote:
>>>
>>> On Tue, Jun 6, 2017 at 5:11 PM, Martin Sebor wrote:
On 06/06/2017 04:57 PM, H.J. Lu wrote:
>
>
> On Tue, Jun 6, 2017 at
As required for C++17, this relaxes the requirements to allow
move-only deleters.
We can't pass them everywhere by rvalue reference, because the
constructor from std::unique_ptr can lead to construction from an
lvalue that won't bind to an rvalue reference. We could add another
_Sp_shared_deleter
Finally, we can make 'auto' the default choice for the FPU option. It's
still possible to override this during configure, but we will eventually
deprecate that, moving to the new cpu/architecture selection mechanism.
* config/arm/arm.h (FPUTYPE_AUTO): Define.
* config/arm/arm.c (
On Fri, Jun 09, 2017 at 02:35:45PM +0200, Richard Biener wrote:
> +static bool
> +gimple_fold_builtin_bcmp (gimple_stmt_iterator *gsi)
> +{
>
> + /* Transform bcmp (a, b, len) into memcmp (a, b, len). */
> +
> + gimple *stmt = gsi_stmt (*gsi);
> + tree a = gimple_call_arg (stmt, 0);
> + tree
Hello Richard,
thanks for updating the RTEMS multlib configuration. It looks fine to me.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP :
This patch uses the driver and some spec rewrite rules to generate a
canonicalized form of the -march= option. We want to do this for
several reasons, all relating to making multi-lib selection sane.
1) It can remove redundant extension options to produce a minimal
list.
2) The general syntax o
The standard arm-eabi configuration comes with a basic set of multilibs that
are suitable mostly for simple testing of the compiler in various
configurations. We try to keep the number of libraries build small so
that build times do not become too onerous.
Using the new auto-fp selection code we
A follow up patch to this one will start to canonicalize options to
simplify generating multilib fragments. This patch is enabling work
for that. If we have extension options that duplicate other options
(done principally for back-wards compatibility purposes) we need to
ensure that just one of
Currently if the user does not specify a default CPU or architecture
the compiler provieds no default values in the spec defaults. We can
try to work from TARGET_CPU_DEFAULT but pulling that into the driver
is a bit crufty and doesn't really work well with the general
spec-processing model. A be
Before this patch series it wasn't really possible to not have an FPU;
it was always there, even if the hardware didn't really support it.
Now that we have -mfpu=auto, the concept of not having an FPU becomes
real. Consequently, when the -mfloat-abi switch is set to softfp
doing the Right Thing i
This is the R- & M-profile equivalent of the previous A-profile
multilib rewrite. Additionally this patch adds some top-level rules
to help find suitable multilibs for general cases when certain
libraries are not built, or when building for legacy cores.
gcc:
* config/arm/t-aprofile (v7
The MULTILIB_REUSE mapping rules are built up using periods to
represent the placement of '=' signs in the command line syntax. This
presents a problem if the option contains an explicit period because
that is translated unconditionally. The result is that it is not
currently possible to write a
The driver really needs to handle some canonicalization of the new
-mcpu and -march options in order to make multilib selection
tractable. This will require moving much of the logic to parse the
new options into the common code file. However, the tuning data
definitely does not want to be there
This patch has no functional change. The code used for parsing -mcpu,
-mtune and -march options is simply moved from arm.c arm-common.c.
The list of FPU options is also moved. Subsequent patches will make
use of this within the driver.
Some small adjustments are needed as a consequence of movin
Symbianelf used to build multilib for armv5t with softfp, but that
architecture doesn't really support floating point instructions. This
patch reworks the multilib configuration to use armv5te as the base
when building for floating point.
I'm not sure just how useful the symbian port is these da
No real change, but for consistency reset all multilib related variables.
config/arm/t-linux-eabi (MULTILIB_EXCEPTIONS): Set to empty.
(MULTILIB_RESUE): Likewise.
(MULTILIB_MATCHES): Likewise.
(MULTLIB_REQUIRED): Likewise.
---
gcc/config/arm/t-linux-eabi | 4
Reviewing the list of options for the purposes of writing the
documentation revealed that a small number of options were missing.
Mostly these are aliases for existing options, but in a couple of
cases we lacked the ability to disable certain other options.
* config/arm/arm-cpus.in (armv7
It looks like the fuchsia port relied on inheriting the multilib rules from
the bare-metal port (the t-arm-elf makefile fragment), but that has now been
rewritten on the assuption that the base architecture is ARMv4t; fuchsia
has a base architecture of ARMv7-a.
To account for this, I've cloned th
Now that the default FPU is 'auto' we can finally rewrite (and
simplify) the rules for mapping compiler options to multilibs. We
no-longer need to know the specific CPU, since the driver will
construct a suitable -march flag for us; this greatly simplifies the
overall logic. This patch rewrites
This adds documentation for the new extension options to -march= on ARM.
I tried a number of different ways of formatting the information, but this
seems the best, given what can be achieved in texinfo format.
* doc/invoke.texi (ARM Options, -march=): Document new syntax and
permi
This patch adds the remainder of the main documentation changes. It
adds the changes for -mcpu, -mtune and -mfpu. I've chosen to document
the extension options under -mcpu rather than under -mtune because, while
they are permitted with -mtune, they do not affect the behaviour of the tuning
done
This is the main patch to provide the infrastructure for adding
feature extensions to CPU and architecture specifications. It does not,
however, add all the extensions that we intend to support (just a small
number to permit some basic testing). Now, instead of having specific
entries in the arc
NB. This configuration does not build in GCC-7 and doesn't build now either.
This patch resets a couple of multlib variables which previously were
not cleared.
It almost certainly needs further work to make it use the new option
framework correctly, but since the library configurations are alre
[This patch has only been fairly lightly tested (I've built a compiler
with all the relevant multilibs and smoke-tested a few combinations to
check that the tools still produce a sensible object file).]
This patch updates the RTEMS build to use the new option framework.
It tries as far as possibl
Now that the standard CPU and architecture option parsing code is
available in the driver we can use the main CPU and architecture data
tables for driving the automatic enabling of Thumb code.
Doing this requires that the driver script tell the parser whether or
not the target string is a CPU nam
Some tests explicitly test with -march=armv7-a and -mfloat-abi=hard.
However, with the new -mfpu=auto code, this architectural specifiction
lacks any floating-point capabilities. To rectify this, change the
architecture to armv7-a+fp.
gcc/testsuite:
* gcc.dg/pr59418.c: On ARM, change ar
This file is missing a .fpu directive and was relying on the compiler
driver passing through a -mfpu= command line option. When the FPU is
auto, that will not be passed through correctly, so set something
suitable within the file itself.
libgcc:
* config/arm/cmse_nonsecure_call.S: Expli
This patch extends support for the new extended-style architecture
strings to configure and the target default options. We validate any
options passed by the user to configure against the permitted
extensions for that CPU or architecture.
* config.gcc (arm*-*-fucshia*): Set target_cpu_cn
The ARM option parsing code uses sbitmap data structures to manage
features and upcoming patches will shortly need to use these bitmaps
within the driver. This patch moves sbitmap.o from OBJS to
OBJS-libcommon to facilitate this.
The patch has no impact on targets that don't need this functional
This patch adds the currently supported architecture options to the
individual architectures. For floating point and SIMD we only permit
variants that the relevant versions of the architecture permit. We also
add short-hand versions (+fp, +simd, etc) that allows the user to
describe using floati
This patch adds the default CPUs for each cpu and provides options for
changing the FPU variant when appropriate.
It turns out to be easier to describe removal options using general
mask operations that disable a concept rather than specific bits.
Sometimes the helper definitions for enabling a f
The assembler does not understand all the '+' options accepted by the
compiler. The best solution to this is to simply strip the extensions
and just pass the raw architecture or cpu name through to the
assembler. We will use .arch and .arch_extension directives anyway to
turn on or off individua
During the ARM BoF at the Cauldron last year I mentioned that I wanted
to rework the way GCC on ARM handles the command line options. The
problem was that most users, and even many experts, can't remember
which FPU/SIMD unit comes with which CPU and that consequently many
users were inadvertenly
In order to support more complex specifications for cpus and architectures
we need to move away from using enumerations to represent the set of
permitted options. This basic change just moves the option parsing
infrastructure over to that, but changes nothing more beyond generating
a hint when th
The assembler doesn't understand -mfpu=auto. The easiest way to handle this
is to surpress this value from being passed through, while still passing
through legacy values.
* config/arm/elf.h (ASM_SPEC): Only pass -mfpu through to the
assembler when it is not -mfpu=auto.
---
gcc/
On 06/09/2017 02:27 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 2:08 PM, Martin Liška wrote:
On 06/09/2017 01:05 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 12:49 PM, Martin Liška wrote:
On 06/09/2017 12:39 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 12:17 PM, Martin Lišk
On Thu, 8 Jun 2017, Yuri Gribov wrote:
> On Tue, May 30, 2017 at 7:25 AM, Richard Sandiford
> wrote:
> > Yuri Gribov writes:
> >> Added special case to build_range_check. Fixed couple of existing
> >> tests where it changed codegen.
> >>
> >> -I
> >>
> >> From b7819f341e2ffa0437be497024f61d0a4e1
On Thu, 8 Jun 2017, Yuri Gribov wrote:
> On Wed, May 31, 2017 at 12:19 PM, Richard Biener wrote:
> > On Mon, 29 May 2017, Yuri Gribov wrote:
> >
> >> This no longer fixes the PR but still works in some cases as
> >> demonstrated by the test. So I decided to keep it.
> >
> > As Richard noticed you
On Thu, Jun 8, 2017 at 6:29 PM, Martin Sebor wrote:
> On 06/08/2017 01:51 AM, Richard Biener wrote:
>>
>> On Thu, Jun 8, 2017 at 4:33 AM, Martin Sebor wrote:
>>>
>>> On 06/07/2017 02:12 PM, Martin Sebor wrote:
On 06/07/2017 02:01 PM, Marc Glisse wrote:
>
>
> On Wed, 7 J
On 07/06/17 16:42, Thomas Preudhomme wrote:
> Hi,
>
> The general arm_arch_*_ok procedures check architecture availability by
> substituting macros inside a defined preprocessor operator. This limits
> them to only check definition of only one macro and force ARMv7VE to be
> special cased.
>
> Th
On Fri, Jun 9, 2017 at 2:08 PM, Martin Liška wrote:
> On 06/09/2017 01:05 PM, Richard Biener wrote:
>>
>> On Fri, Jun 9, 2017 at 12:49 PM, Martin Liška wrote:
>>>
>>> On 06/09/2017 12:39 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 12:17 PM, Martin Liška wrote:
>
>
>>>
Hi Ilya,
I tried changing builtin call so it gets address of a decl instead of
a decl, but it looked very unnatural and I hit some other problems
implementing that. Keeping in mind the exposure of this problem, I
think it is not worth it. I propose to reconsider the first and the
simplest patch in
> Hello.
>
> I discussed with Honza possibility to speed-up instrumentation that we do for
> indirect call target tracking. By direct emission of:
>
> if (__gcov_indirect_call_callee != NULL)
>__gcov_indirect_call_profiler_v2 (profile_id, ¤t_function_decl);
>
> we can save reduce #
Hello.
I discussed with Honza possibility to speed-up instrumentation that we do for
indirect call target tracking. By direct emission of:
if (__gcov_indirect_call_callee != NULL)
__gcov_indirect_call_profiler_v2 (profile_id, ¤t_function_decl);
we can save reduce # of execution of _
On 06/09/2017 11:42 AM, Jakub Jelinek wrote:
On Fri, Jun 09, 2017 at 11:29:06AM +0200, Martin Liška wrote:
Having that inlined would be great, however we'll need to put it to tree.h
and thus we have to include "options.h" before tree.h in multiple source files.
Doesn't that mean that tree.h is
On 06/09/2017 01:05 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 12:49 PM, Martin Liška wrote:
On 06/09/2017 12:39 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 12:17 PM, Martin Liška wrote:
On 06/09/2017 12:12 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 11:29 AM, Martin Liš
Hi Tamar,
> I have reverted the patch in commit r 249050 until I can fix the late
> expansion
> and IBM long double issues.
thanks. Just for the record, Solaris/SPARC (also big-endian) was
affected as well:
https://gcc.gnu.org/ml/gcc-testresults/2017-06/msg00908.html
Rainer
-
On Fri, Jun 9, 2017 at 12:49 PM, Martin Liška wrote:
> On 06/09/2017 12:39 PM, Richard Biener wrote:
>>
>> On Fri, Jun 9, 2017 at 12:17 PM, Martin Liška wrote:
>>>
>>> On 06/09/2017 12:12 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 11:29 AM, Martin Liška wrote:
>
>
>>
More deduction guides for C++17.
* include/bits/forward_list.h (forward_list): Add deduction guide.
* include/bits/stl_deque.h (deque): Likewise.
* include/bits/stl_list.h (list): Likewise.
* include/bits/stl_vector.h (vector): Likewise.
* testsuite/23_cont
1 - 100 of 128 matches
Mail list logo
