Hi again,
On 06/07/2014 11:42 AM, Marc Glisse wrote:
On Fri, 6 Jun 2014, Paolo Carlini wrote:
On 06/06/2014 04:16 PM, Marc Glisse wrote:
abi_check is broken before my patch (134 incompatible symbols).
Isn't broken for me, though. Likewise, AFAICS, on gcc-testresults. I
would recommend invest
On 06/06/2014 01:44 AM, Richard Biener wrote:
On Fri, 6 Jun 2014, Richard Sandiford wrote:
[snip]
How about initialising the DECL_ALIGN to:
(TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_pfn
? 2 * BITS_PER_UNIT : BITS_PER_UNIT)
instead of function_boundary (NULL)? That wa
On Sat, Jun 7, 2014 at 7:54 PM, Richard Sandiford wrote:
> The two parts of the loop condition are really handling two different
> kinds of block: ones like entry and exit that are completely empty
> and normal ones that have at least a block note. There's no real
> need to check for null INSNs in
> ... In this particular translation unit you mean?
Yes, in the translation unit being processed.
> That would be worthless information for decls also reachable from elsewhere.
It's the information: ADDR_EXPR of this DECL is taken somewhere in the IL,
it's no more or not less worthless than any
On 06/06/2014 11:41 PM, Ed Smith-Rowland wrote:
On 06/06/2014 10:27 AM, Jonathan Wakely wrote:
On 06/06/14 10:08 -0400, Ed Smith-Rowland wrote:
I'll look at rdbuf. Error in rdbuf? Do I need to do something?
No, just me being dumb. The ostream::operator<<(streambuf*) overload
behaves as an unf
On 06/06/2014 07:47 PM, Janne Blomqvist wrote:
> PING
>
> On Tue, May 27, 2014 at 11:50 PM, Janne Blomqvist
> wrote:
>> Hi,
>>
>> the attached patch implements the idea in
>> https://gcc.gnu.org/ml/fortran/2013-04/msg00258.html ; though it
>> turned out it was much simpler than what I envisaged b
On June 7, 2014 2:06:47 PM CEST, Eric Botcazou wrote:
>> An external variable is a VAR_DECL that cannot be in a register. It
>> can be loaded into a register (or stored into), and for that its
>> address is needed. So I would expect an external variable to be
>marked
>> addressable by default.
>
>
On June 7, 2014 1:54:06 PM CEST, Steven Bosscher wrote:
>On Sat, Jun 7, 2014 at 12:59 PM, Eric Botcazou wrote:
>>> >In Ada we don't mark (external) variables as addressable if we
>don't
>>> >see their address taken.
>>>
>>> You have to (now). The testing was of course to detect this...
>>
>> Well
> An external variable is a VAR_DECL that cannot be in a register. It
> can be loaded into a register (or stored into), and for that its
> address is needed. So I would expect an external variable to be marked
> addressable by default.
"address of this is needed" historically means ADDR_EXPR of th
This is a regression present on the mainline and 4.9 branch (at least): the
recently added tree-ssa-tail-merge.c pass totally disregards the static chain
of calls, so it can wrongly merge 2 calls to the same function with different
instances of a non-local frame object generated by inlining.
Te
On Sat, Jun 7, 2014 at 12:59 PM, Eric Botcazou wrote:
>> >In Ada we don't mark (external) variables as addressable if we don't
>> >see their address taken.
>>
>> You have to (now). The testing was of course to detect this...
>
> Well, you need to define what TREE_ADDRESSABLE means now, because acc
> The following adds the missing capability to sink loads to
> tree-ssa-sink.c. This enables sinking of loads and dependent
> expressions into code paths that uses them (thus performing
> partial dead code elimination on loads).
There is a much heavier implementation in tree-ssa-loop-im.c attache
> Hmm, I don't see this.
Usual scheduler-sensitive stuff I guess, here's the assembly I have:
movqaliasing3_pkg__pointer(%rip), %rax
testq %rax, %rax
je .L6
cmpl$5, aliasing3_pkg__block(%rip)
movl$5, (%rax)
insns #4 and #5 have been wron
Ping. Note that PR61219 is a duplicate of PR59833, so this patch
actually fix PR59833.
On Sun, May 18, 2014 at 11:23:38PM +0200, Aurelien Jarno wrote:
> On ARM soft-float, the float to double conversion doesn't convert a sNaN
> to qNaN as the IEEE Std 754 standard mandates:
>
> "Under default exc
Attached patch should fix compilation of libgfortran on hppa1.1-hp-hpux10.20
(see PR60468: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60468), by adding a
missing header to the configure checks.
I’ve tested that it doesn’t break bootstrap on x86_64-apple-darwin, but not on
hpux10. It seems sa
Hi,
On 07 giugno 2014 11:42:23 CEST, Marc Glisse wrote:
>On Fri, 6 Jun 2014, Paolo Carlini wrote:
>
>> On 06/06/2014 04:16 PM, Marc Glisse wrote:
>>> abi_check is broken before my patch (134 incompatible symbols).
>> Isn't broken for me, though. Likewise, AFAICS, on gcc-testresults. I
>would
>
On Fri, 6 Jun 2014, Paolo Carlini wrote:
On 06/06/2014 04:16 PM, Marc Glisse wrote:
abi_check is broken before my patch (134 incompatible symbols).
Isn't broken for me, though. Likewise, AFAICS, on gcc-testresults. I would
recommend investigating in some detail what's going on at your end...
Jakub Jelinek writes:
> I thought complex(kind=16) is normal double _Complex, isn't it?
No, that would be complex(kind=8).
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Sat, Jun 07, 2014 at 10:11:06AM +0200, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
> > --- gcc/testsuite/gfortran.dg/gomp/udr6.f90.jj 2014-06-02
> > 10:49:02.674337338 +0200
> > +++ gcc/testsuite/gfortran.dg/gomp/udr6.f90 2014-06-02 15:40:52.664740529
> > +0200
> > @@ -0,0 +1,205 @@
Jakub Jelinek writes:
> --- gcc/testsuite/gfortran.dg/gomp/udr6.f90.jj2014-06-02
> 10:49:02.674337338 +0200
> +++ gcc/testsuite/gfortran.dg/gomp/udr6.f90 2014-06-02 15:40:52.664740529
> +0200
> @@ -0,0 +1,205 @@
> +! { dg-do compile }
> +! { dg-options "-fmax-errors=1000 -fopenmp -ffr
20 matches
Mail list logo
