Hi!
The GNU DW_AT_GNU_macros and .debug_macro* extensions were added to DWARF5,
so we should emit those even in -gstrict-dwarf -gdwarf-5 mode.
Bootstrapped/regtested on x86_64-linux and i686-linux on top of the
dwarf2.{def,h} patch, ok for trunk?
2016-10-14 Jakub Jelinek
* dwarf2out.
With --target_board=unix/-std=gnu++17 this test fails, because
std::sample is defined too.
* testsuite/experimental/algorithm/sample.cc: Qualify calls to
resolve ambiguity between std::sample and std::experimental::sample.
Tested x86_64-linux, committed to trunk.
commit 8129c87
On Thu, 2016-10-13 at 16:18 +0200, Bernd Schmidt wrote:
> On 10/13/2016 04:08 PM, David Malcolm wrote:
> > I thought it might be useful to brainstorm [1] some ideas on this,
> > so here are various possible ways it could be printed for this use
> > -case:
> >
> > * Offset by LAST_VIRTUAL_REGISTER
Hi!
Another set of GNU extensions that were accepted into DWARF5, so we should
emit them even for -gstrict-dwarf -gdwarf-5, and for -gdwarf-5 should use
the accepted standard opcodes instead of the corresponding GNU ones.
Bootstrapped/regtested on x86_64-linux and i686-linux on top of the
dwarf2.
On 02/09/16 20:53 +0200, Eelis wrote:
On 2016-09-02 20:20, Eelis van der Weegen wrote:
On 2016-08-31 14:45, Jonathan Wakely wrote:
Is this significantly faster than just using
uniform_int_distribution<_IntType>{0, __bound - 1}(__g) so we don't
need to duplicate the logic? (And people maintainin
On 10/14/16 15:17, David Malcolm wrote:
"Limits the maximum number of error messages to @var{n}, at which point
GCC bails out rather than attempting to continue processing the source
code. If @var{n} is 0 (the default), there is no limit on the number
of error messages produced. If @option{-Wf
On 10/14/2016 10:12 PM, David Malcolm wrote:
gcc/ChangeLog:
* print-rtl-function.c (print_edge): Omit "(flags)" when none are
set.
(print_rtx_function): Update example in comment for...
* print-rtl.c (print_rtx_operand_code_r): In compact mode, print
non-vi
On Thu, Oct 13, 2016 at 09:45:22AM -0600, Kelvin Nilsen wrote:
> 3. Replace magic number 74 with CR6_REGNO in vsx.md (2 occurrences)
>and vector.md (3 occurrences).
Some remain, see below.
> +moves bytes 16 - @code{len} to 15 of the corresponding vector. For the
> +the element to be extract
On Fri, 2016-10-14 at 15:50 -0400, Nathan Sidwell wrote:
> On 10/14/16 15:17, David Malcolm wrote:
>
> > "Limits the maximum number of error messages to @var{n}, at which
> > point
> > GCC bails out rather than attempting to continue processing the
> > source
> > code. If @var{n} is 0 (the defaul
On Fri, Oct 14, 2016 at 8:01 PM, Bernhard Reutner-Fischer
wrote:
> On 13 October 2016 22:08:21 CEST, Jerry DeLisle wrote:
>>On 10/13/2016 08:16 AM, Janne Blomqvist wrote:
>
>>>
>>> Regtested on x86_64-pc-linux-gnu. Ok for trunk?
>>>
>>
>>Yes, OK, clever! Thanks!
>
> Is 32 something a typical prog
On Fri, 2016-10-14 at 16:27 +0100, Pedro Alves wrote:
> On 10/12/2016 03:13 PM, Bernd Schmidt wrote:
> > On 10/12/2016 04:09 PM, Pedro Alves wrote:
> > >
> > > Thanks. Here's a follow up patch that I was just testing.
> > >
> > > Need this if building with "g++ -std=gnu++11", with gcc < 4.7.
> >
On 10/14/2016 10:28 PM, David Malcolm wrote:
> I propose that we update our coding conventions to mention the OVERRIDE
> and FINAL macros in the paragraph that discusses virtual funcs.
>
> The attached patch (to the website) does so.
>
Good idea, I like it.
GDB is following GCC's C++ coding co
Currently GFortran newer reuses unit numbers allocated with NEWUNIT=,
instead having a simple counter that is decremented each time such a
unit is opened. For a long running program which repeatedly opens
files with NEWUNIT= and closes them, the counter can wrap around and
cause an abort. This pa
Implementing this proposal was a pretty straightforward matter of
changing the definition of aggregate and treating artificial base
fields as initializable in aggregate initialization. For this to work
with empty bases, I needed to create base fields for them, which we
haven't done in the past. b
OK.
On Fri, Oct 14, 2016 at 1:29 PM, Jakub Jelinek wrote:
> Hi!
>
> Before early dwarf changes, if we wanted to note some decl property so that
> some corresponding DWARF attribute can be emitted, we had to use some
> generic IL bit for that. Now a langhook can be used instead (hopefully for
> 7
On Fri, Oct 14, 2016 at 02:37:42PM -0500, Bill Seurer wrote:
> [PATCH, rs6000] pr65479 Add option to fix failing asan test cases.
>
> This patch adds the -fasynchronous-unwind-tables option to several of the asan
> test cases. The option causes a full strack trace to be produced when the
> saniti
The attach patch fixes a number of shortcomings with
STOP codes in gfortran. The updated comment in the
code nicely summarizes the problem.
/* Match a number or character constant after an (ERROR) STOP or PAUSE
- statement. */
+ statement. The requirements for a stop-code differs in the st
This patch to the Go frontend and libgo copies the runtime package
time code from the Go 1.7 runtime.
This tweaks the frontend to fix the handling of function values for
-fgo-c-header to generate FuncVal*, not simply FuncVal.
While we're here change runtime.nanotime to use clock_gettime with
CLOC
On Fri, Oct 14, 2016 at 05:24:53PM -0700, Steve Kargl wrote:
> For the code
>
> program foo
> stop merge(667, 668, .true.)
> end
>
> gfortran with either -std=f95 or -std=f2003 should reject
> this code. My patch does not fix this issue, because it
> would (1) require a complete rewri
On 14 October 2016 22:41:25 CEST, Janne Blomqvist
wrote:
>On Fri, Oct 14, 2016 at 8:01 PM, Bernhard Reutner-Fischer
> wrote:
>> On 13 October 2016 22:08:21 CEST, Jerry DeLisle
> wrote:
>>>On 10/13/2016 08:16 AM, Janne Blomqvist wrote:
>>
Regtested on x86_64-pc-linux-gnu. Ok for trunk?
>
Hi Bin,
On 15/10/16 00:15, Bin Cheng wrote:
+/* Test for likely overcommitment of vector hardware resources. If a
+ loop iteration is relatively large, and too large a percentage of
+ instructions in the loop are vectorized, the cost model may not
+ adequately reflect delays from unavaila
All out-of-line register save routines need LR, so we cannot wrap the
LR component if there are out-of-line saves. This didn't show up for
testing on Linux because none of the tests there use out-of-line FPR
saves without also using out-of-line GPR saves, which we did handle.
This patch fixes it,
On Sat, Oct 15, 2016 at 03:00:20AM +, Segher Boessenkool wrote:
> 2016-10-15 Segher Boessenkool
>
> * config/rs6000/rs6000.c (rs6000_get_separate_components): Do not
> make LR a separately shrink-wrapped component if savres_strategy
> contains any of {SAVE,REST}_INLINE_{GP
On Thu, Sep 22, 2016 at 12:10 PM, Pat Haugen
wrote:
> I noticed the loop unroller peels an extra copy of the loop before it enters
> the switch block code to round the iteration count to a multiple of the
> unroll factor. This peeled copy is only needed for the case where the exit
> test is at
On Fri, Oct 14, 2016 at 8:28 PM, Andrew Pinski wrote:
> On Thu, Sep 22, 2016 at 12:10 PM, Pat Haugen
> wrote:
>> I noticed the loop unroller peels an extra copy of the loop before it enters
>> the switch block code to round the iteration count to a multiple of the
>> unroll factor. This peeled
101 - 125 of 125 matches
Mail list logo