Hi,
On Fri, 29 Nov 2013 12:28:15, Eric Botcazou wrote:
>
>> I think I see a small flaw in that patch:
>> + /* Make sure not to write past the end of the struct. */
>> + store_bit_field (dest,
>> + adj_bytelen * BITS_PER_UNIT, bytepos * BITS_PER_UNIT,
>> + bytepos * BITS_PER_UNIT, ssize * BITS_PER_
Richard Biener writes:
> Richard Sandiford wrote:
>>Richard Biener writes:
>>> On Fri, Nov 29, 2013 at 12:14 PM, Richard Sandiford
>>> wrote:
In the fold-const.ii testcase, well over half of the mul_internal
>>calls
were for multiplication by 0 (106038 out of 169355). This patch
>>ad
Paul Richard Thomas wrote:
This turned out to be a valid uninitialized variable warning.
Bootstrapped and regtested on FC17/x86_64 - OK from trunk and 4.8?
OK – thanks for the patch!
Tobias
2013-11-30 Paul Thomas
PR fortran/58410
* trans-array.c (gfc_alloc_allocatable_for_assig
At the moment we only use host divisions for precisions <=
HOST_BITS_PER_WIDE_INT. This patch extends it to any division in which
the inputs fit in HWIs. The easiest way seemed to be to construct
wide_int_refs for the numbers and reuse wi::fits_*hwi_p. This also
simplifies some of the other code
Paul Richard Thomas wrote:
This one is trivial. NULL(...) is simply out of context in a transfer
statement.
Bootstrapped and regtested on FC17/x86_64. OK for trunk and 4.8?
Looks good to me, except that I wonder whether the wording could be
improved:
"Invalid context for NULL () intrinsic
> Ok, committed as obvious, in both branches, after regression-testing.
Thanks for spotting and fixing it.
--
Eric Botcazou
Paul Richard Thomas wrote:
This is a partial fix for this problem
Well, it is a full fix for the wrong-code issue, even if a
missed-optimization issue remains ;-)
I will retain the PR and will have another go at suppressing
the reallocation in a few weeks time.
Thanks!
Bootstrapped and reg
Any compiler configured to target Windows with tree checking breaks on -g3:
eric@polaris:~/gnat/bugs/MB28-035> ~/build/gcc/i686-pc-mingw32/gcc/cc1 -quiet
-g3 t.c
t.c:1:0: internal compiler error: tree check: expected tree that contains
'decl common' structure, have 'identifier_node' in i386_pe_a
Richard Biener writes:
> Richard Sandiford wrote:
>>This started out as an another attempt to find places where we had
>>things like:
>>
>> offset_int x = wi::to_offset (...);
>> x = ...x...;
>>
>>and change them to:
>>
>> offset_int x = ...wi::to_offset (...)...;
>>
>>with the get_ref_base
Richard Sandiford wrote:
>Richard Biener writes:
>> Richard Sandiford wrote:
>>>This started out as an another attempt to find places where we had
>>>things like:
>>>
>>> offset_int x = wi::to_offset (...);
>>> x = ...x...;
>>>
>>>and change them to:
>>>
>>> offset_int x = ...wi::to_offset
On Thu, Nov 28, 2013 at 10:11:26PM +, Vladimir Makarov wrote:
> Committed as rev. 205498.
>
> 2013-11-28 Vladimir Makarov
>
> PR target/57293
> * ira.h (ira_setup_eliminable_regset): Remove parameter.
> * ira.c (ira_setup_eliminable_regset): Ditto. Add
> SUPPORTS_S
I noticed there wasn't an entry in the option index for -fuse-ld. If
OK, can someone apply? Thanks.
Regards,
Ryan Mansfield
2013-12-01 Ryan Mansfield
* doc/invoke.texi (-fuse-ld): Add index entry.
Index: gcc/doc/invoke.texi
===
Am 01.12.2013 18:13, schrieb Ryan Mansfield:
I noticed there wasn't an entry in the option index for -fuse-ld. If
OK, can someone apply? Thanks.
There are many more options which lack an optindex, cf. still unreviewed
and pinged patch at http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03082.html
On Sun, Dec 1, 2013 at 2:28 AM, Richard Sandiford
wrote:
>
> I followed Joseph's suggestion and reused longlong.h. I copied it from
> libgcc rather than glibc since it seemed better for GCC to have a single
> version across both gcc/ and libgcc/. I can put it in include/ if that
> seems better.
Hello!
Currently, gfortran.dg/erf_3.F90 FAILs on targets with 128bit
(quadruple) long double, since high-precision erfc_scaled_r16 gets
defined only for __float128 quadruple precision.
Attached patch defines this function also for 128bit long double targets.
[BTW: The patch really implements wha
Ian Lance Taylor writes:
> I've gotten a patch from Michael Hudson-Doyle to set GOARCH to arm64
> on an Aarch64 system (https://codereview.appspot.com/34830045/).
Haha, go us.
> I've gotten a patch from Matthias Klose to set GOARCH to aarch64 on
> such a system
> (http://gcc.gnu.org/ml/gcc-pa
> Currently, gfortran.dg/erf_3.F90 FAILs on targets with 128bit
> (quadruple) long double, since high-precision erfc_scaled_r16 gets
> defined only for __float128 quadruple precision.
I can’t approve it, but yes, it makes more sense than what I did earlier.
FX
FX wrote:
Uros Bizjak wrote:
Currently, gfortran.dg/erf_3.F90 FAILs on targets with 128bit
(quadruple) long double, since high-precision erfc_scaled_r16 gets
defined only for __float128 quadruple precision.
[...] yes, it makes more sense than what I did earlier.
Looks also good to me. Thanks
On 30/11/13 11:38, Eric Botcazou wrote:
2013-11-29 Paulo Matos
Eric Botcazou
* combine.c (reg_nonzero_bits_for_combine): Apply mask transformation
as applied to nonzero_sign_valid fixing bug when last_set_mode has
less precision than mode.
Applied, thank
Hi,
I have updated email address in MAINTAINERS, since j...@suse.cz is no longer
active.
Comitted as obvious,
Honza
Index: MAINTAINERS
===
--- MAINTAINERS (revision 205489)
+++ MAINTAINERS (working copy)
@@ -66,7 +66,7 @@ h8 port
On Sun, 24 Nov 2013, Tobias Burnus wrote:
> 2013-11-24 Tobias Burnus
> Manuel López-Ibáñez
>
>PR middle-end/59257
>* doc/invoke.texi: Add missing @opindex.
>(-fsanitize=): Use @gcctabopt instead of @itemize.
> OK for the trunk?
This looks fine to me, than
On Mon, Nov 18, 2013 at 5:25 AM, Richard Biener wrote:
> On Fri, 15 Nov 2013, Richard Biener wrote:
>
>> On Fri, 15 Nov 2013, Jakub Jelinek wrote:
>>
>> > On Fri, Nov 15, 2013 at 02:56:51PM +0100, Richard Biener wrote:
>> > > Now that there is (finally :() a wrong-code testcase for the
>> > > PR54
arm64 it is
Working on it. I hope to have a patch within the next 48 hours.
Gerald
On Sat, Nov 30, 2013 at 12:34 AM, Richard Earnshaw wrote:
> On 29/11/13 11:46, Yufeng Zhang wrote:
>> On 11/29/13 07:52, Bin.Cheng wrote:
>>> After thinking twice, I some kind of think we should not re-associate
>>> addresses during expanding, because of lacking of context information.
>>> Take
>>> I am checking in this as an obvious fix. Tested
>>> on Linux/x86.
>>>
>>> H.J.
>>
>> I think bootstrap-asan.mk should also be updated.
>>
>>> H.J.
>
> I checked in this as an obvious fix. Tested on Linux/x86-64.
>
> H.J.
Thanks HJ. I wonder how this managed to pass tests here without your
> This is causing all the tests being run on all targets,
> even if libsanitizer is not supported,
> most of them failing due to link errors.
Thanks for the info and sorry about this. I should probably check
non-sanitized platforms as well before commiting patches. Does the
attached patch make
Ping http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02793.html
--
Alan Modra
Australia Development Lab, IBM
Hi Richard,
Pinging for further comments.
regards,
Venkat.
On 27 November 2013 14:24, Venkataramanan Kumar
wrote:
> Hi Richard,
>
>> I don't think it's good to have long lists of targets on generic tests.
>> Can we factor this out into a target-supports option?
>
> I have updated the patch as
29 matches
Mail list logo
