This version adds extra tests for HAVE_XCOFF_DWARF_EXTRAS. I placed
the default in dwarf2out.c instead of defaults.h.
Because eh_frame is internal to GCC with its own section, I emit the
length, but inhibit the length for AIX debug_frame section.
This allows DWARF debugging to work on older AIX
Tobias Burnus wrote:
I intent to install it for GCC 6, 5 and 4.9.
I have now committed it to the trunk and the two branches - including a
wording change (When setting it to -> When set to; plus adding a second
space after the end-of-sentence period.)
Tobias
On 09/25/2015 11:59 AM, David Edelsohn wrote:
> * dwarf2out.c (XCOFF_DEBUGGING_INFO): Default 0 definition.
> (HAVE_XCOFF_DWARF_EXTRAS): Default to 0 definition.
> (output_fde): Don't output length for debug_frame on AIX.
> (output_call_frame_info): Don't output leng
The follwoing patch has been built and regression
tested on x86_64-*-freebsd. There were no regression.
The patch removes an assert, which allows gfortran
to detect an invalid selector in SELECT TYPE statement.
2015-09-25 Steven G. Kargl
PR fortran/67525
* parse.c (match_def
This patch backports r228136 from trunk to Google/4_9. The only
difference is that I have added the option disabling to our
Google-specific routine for removing profile options when the
specified profile gcda file is not found.
Passes regression tests. Ok for google/4_9?
Thanks,
Teresa
2015-09-2
The attached patch has been built and regression tested on
x86_64-*-freebsd. There were no regression.
If the scalar-numeric-expr in an arithmetic-if is ar
reference to NULL(), this is an invalid expression.
By resolving the expression, then entity is correctly
identified by EXPR_NULL. Thus, the
On Fri, Sep 25, 2015 at 10:09:23AM -0600, Jeff Law wrote:
> >>So what that means is the presence or absence of debug information is
> >>causing a difference in
> > > the code you generate. That is (of course) bad and indicates a bug
> >of some kind in your code.
> >
> >>I haven't put your code und
Hello Paul,
Le 25/09/2015 14:21, Paul Richard Thomas a écrit :
Dear Mikael, dear all,
Please find attached a revised version of the patch that, I believe,
addresses all the comments. The patch is very much improved and these
improvements are verified by the two extra testcases. Thanks a
million
On 09/25/2015 01:18 PM, Segher Boessenkool wrote:
On Fri, Sep 25, 2015 at 10:09:23AM -0600, Jeff Law wrote:
So what that means is the presence or absence of debug information is
causing a difference in
the code you generate. That is (of course) bad and indicates a bug
of some kind in your code
Hi!
The latest spec proposals change the meaning of the ordered(n) clause
if collapse > 1 to count the number of source loops.
The ordered >= collapse requirement is something I'm pushing for even when
it is not in the spec (yet).
And, finally, another proposed change is that the + or - signs in t
On 09/25/2015 05:06 AM, Kyrill Tkachov wrote:
Hi Rainer,
On 25/09/15 11:57, Rainer Orth wrote:
Hi Kyrill,
Bootstrapped and tested on aarch64 and x86_64.
Rainer, could you please try this patch in combination with the one I
sent
earlier at:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00815.h
On Fri, 2015-09-25 at 10:51 +0200, Dodji Seketeli wrote:
> Hello David,
>
> I like this! Thank you very much for working on this.
Thanks for the review.
> I think this patch is in great shape, and once we agree on some of the
> nits I have commented on below, I think it should go in. Oh, it als
On 09/25/2015 12:13 PM, Steve Kargl wrote:
> The follwoing patch has been built and regression
> tested on x86_64-*-freebsd. There were no regression.
>
> The patch removes an assert, which allows gfortran
> to detect an invalid selector in SELECT TYPE statement.
>
OK, thanks for patch!
Jerry
On 25 September 2015 at 22:11, David Malcolm wrote:
>>
>> + if (0)
>> +show_ruler (context, line_width, m_x_offset);
>>
>> This should probably be removed from the final code to be committed.
>
> FWIW, the ruler is very helpful to me when debugging the locus-printing
> (e.g. when adding fix-i
Hello,
PR55603 seems to have been fixed at some point.
I have just committed the test and I'm about to close the PR.
Mikael
Index: gcc/testsuite/gfortran.dg/allocatable_function_9.f90
===
--- gcc/testsuite/gfortran.dg/allocatable_f
The patch makes the detection of scop parameters in parameter_index_in_region a
bit more conservative by discarding scalar variables defined in function of data
references defined in the scop.
2015-09-25 Aditya Kumar
Sebastian Pop
PR tree-optimization/67700
On 25 September 2015 at 22:18, Manuel López-Ibáñez
wrote:
> On 25 September 2015 at 22:11, David Malcolm wrote:
context->last_location = diagnostic_location (diagnostic, 0);
- expanded_location s0 = diagnostic_expand_location (diagnostic, 0);
- expanded_location s1 = { };
- /* Zero-initia
On 09/25/2015 12:18 PM, Steve Kargl wrote:
> The attached patch has been built and regression tested on
> x86_64-*-freebsd. There were no regression.
>
> If the scalar-numeric-expr in an arithmetic-if is ar
> reference to NULL(), this is an invalid expression.
> By resolving the expression, then
The following patch is for s390 regression introduced by the first patch
for PR61578:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
The patch was bootstrapped and tested on x86-64.
Committed as rev. 228154.
2015-09-25 Vladimir Makarov
PR target/61578
* lra-constarints
+ If SHOW_CARET_P is true, then the range should be rendered with
+ a caret at its starting location. This
+ is for use by the Fortran frontend, for implementing the
+ "%C" and "%L" format codes. */
+
+void
+rich_location::set_range (unsigned int idx, source_range src_range,
+
On Fri, 2015-09-25 at 22:39 +0200, Manuel López-Ibáñez wrote:
> On 25 September 2015 at 22:18, Manuel López-Ibáñez
> wrote:
> > On 25 September 2015 at 22:11, David Malcolm wrote:
>
>
>context->last_location = diagnostic_location (diagnostic, 0);
> - expanded_location s0 = diagnostic_expan
On Fri, 2015-09-25 at 23:13 +0200, Manuel López-Ibáñez wrote:
> + If SHOW_CARET_P is true, then the range should be rendered with
> + a caret at its starting location. This
> + is for use by the Fortran frontend, for implementing the
> + "%C" and "%L" format codes. */
> +
> +void
> +rich_
The attached patch has been built and regression
tested on x86_64-*-freebsd. No regression occurred.
The patch removes a conditional within an assert()
that triggers when a BLOCK construct is encountered.
OK to commit?
2015-09-25 Steven G. Kargl
PR fortran/67616
* primary.c
On 25 September 2015 at 23:24, David Malcolm wrote:
> On Fri, 2015-09-25 at 23:13 +0200, Manuel López-Ibáñez wrote:
>> + If SHOW_CARET_P is true, then the range should be rendered with
>> + a caret at its starting location. This
>> + is for use by the Fortran frontend, for implementing the
On 25 September 2015 at 23:15, David Malcolm wrote:
> My recollection is that I saw that the Fortran frontend has logic for
> calling into diagnostic_print_caret_line, noticed that the fortran
> testsuite has dg- assertions about finding specific messages, and I got
> worried that they embed assum
I have made the following changes in the estimate_reg_pressure_cost function
used
by the loop invariant and IVOPTS.
Earlier the estimate_reg_pressure cost uses the cost of n_new variables that
are generated by the Loop Invariant
and IVOPTS. These are not sufficient for register pressure calcu
On Thu, Sep 24, 2015 at 11:31:40AM +0200, Thomas Schwinge wrote:
> Hi!
>
> On Sat, 19 Sep 2015 20:55:35 -0400, Trevor Saunders
> wrote:
> > On Fri, Sep 18, 2015 at 09:32:37AM -0600, Jeff Law wrote:
> > > On 09/18/2015 07:32 AM, Trevor Saunders wrote:
> > > >On Wed, Sep 16, 2015 at 03:11:14PM -04
Hi,
this patch prevents adjacent loops in a kernels region to paralellized.
This fixes an ICE in the test-case.
Committed to gomp-4_0-branch.
Thanks,
- Tom
Don't parallelize oacc kernels region with adjacent loops
2015-09-26 Tom de Vries
* omp-low.c (mark_loops_in_oacc_kernels_region):
On Tue, Jul 28, 2015 at 6:12 AM, Jiong Wang wrote:
>
> The instruction sequences for preparing argument for TLS descriptor
> runtime resolver and the later function call to resolver can actually be
> hoisted out of the loop.
>
> Currently we can't because we have exposed the hard register X0 as
>
On Fri, Sep 25, 2015 at 11:40 PM, Andrew Pinski wrote:
> On Tue, Jul 28, 2015 at 6:12 AM, Jiong Wang wrote:
>>
>> The instruction sequences for preparing argument for TLS descriptor
>> runtime resolver and the later function call to resolver can actually be
>> hoisted out of the loop.
>>
>> Curre
101 - 130 of 130 matches
Mail list logo
