On 10/17/2015 08:57 AM, Mikhail Maltsev wrote:
On 10/06/2015 04:46 PM, Jason Merrill wrote:
Hi, sorry for the slow response. Please feel free to ping once a week.
On 08/27/2015 02:27 PM, Mikhail Maltsev wrote:
+ if (TREE_THIS_VOLATILE (t) && (!DECL_P (t) || want_rval))
Why the !DECL_P chec
Hi Andrew,
On 16 Oct 2015, at 20:49, Andrew MacLeod wrote:
> On 10/12/2015 04:04 AM, Jeff Law wrote:
>> On 10/08/2015 07:37 AM, Andrew MacLeod wrote:
>>> On 10/07/2015 06:02 PM, Jeff Law wrote:
>>
>> I'm slightly concerned about the darwin, windows and solaris bits. The
>> former primarily bec
Hi Steve,
Thanks - Committed as revision 228940.
I'll commit to 5 branch next Sunday.
Cheers
Paul
On 17 October 2015 at 22:51, Steve Kargl
wrote:
> On Sat, Oct 17, 2015 at 09:49:45PM +0200, Paul Richard Thomas wrote:
>>
>> I was moved by a report on clf of memory leaks in move_alloc to
>> in
On 8 Sep 2015, at 15:27, Ian Lance Taylor wrote:
> On Tue, Sep 8, 2015 at 7:20 AM, Iain Sandoe wrote:
>>
>>> This seems likely to break cross-compilers to Darwin that do not have
>>> the system libraries available. I guess I don't care about that if
>>> you don't.
>>
>> I do care about it, bu
> I was only tracking one isse I hit: Fortran/C interoperability nees LTO to
> produce same TYPE_CANONICAl for signed and unsigned version of size_t.
> Doing so broke useless_type_conversion because it used TYPE_CANONICAL. We
> discussed the topic on the GNU Cauldron and decided that it is cleaner
Le 15/10/2015 12:18, Andre Vehreschild a écrit :
Hi Mikael, hi all,
I have checked that the patch (my initial one for pr59678) does compile
and test fine. Given that the patch lives in trunk-6 for quite some
time now, without any major complaints, I approve to commit to gcc-5.
Thanks, I'll proc
Le 16/10/2015 10:08, Christophe Lyon a écrit :
Hi,
We have noticed a few random failures in gfortran tests in our validations.
Maxim investigated some of them and noticed a possible race condition
in the streamio tests, for which he'll post a patch.
I looked for other similar cases (checking w
On 13 Sep 2015, at 21:25, Mike Stump wrote:
>
> Ok with or without the warning.
So .. I removed the warning, and changed the string handling funcs to use those
from libiberty, since earlier Darwin don't have the strn*,
actual patch applied attached,
cheers
Iain
Index: gcc/ChangeLog
=
Hello,
> > I was only tracking one isse I hit: Fortran/C interoperability nees LTO to
> > produce same TYPE_CANONICAl for signed and unsigned version of size_t.
> > Doing so broke useless_type_conversion because it used TYPE_CANONICAL. We
> > discussed the topic on the GNU Cauldron and decided that
On October 18, 2015 6:06:51 PM GMT+02:00, Jan Hubicka wrote:
>Hello,
>> > I was only tracking one isse I hit: Fortran/C interoperability nees
>LTO to
>> > produce same TYPE_CANONICAl for signed and unsigned version of
>size_t.
>> > Doing so broke useless_type_conversion because it used
>TYPE_CANON
>
> Adding back the mode check is fine if all types with the same TYPE_CANONICAL
> have the same mode. Otherwise we'd regress here. I thought we do for
>
> Struct x { int i; };
> Typedef y x __attribute__((packed));
>
> And then doing
>
> X x;
> Y y;
> X = y;
Do you have any idea how to tur
Hi Uros,
> -Original Message-
> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> Sent: Tuesday, October 13, 2015 9:12 PM
> To: Kumar, Venkataramanan
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [Patch] [x86_64]: Add bdver4 for multi versioning and fix AMD
> cpu model detection.
>
> On Tue,
In preparing the next patch, I have to modify some expected diagnostics, and
move them from being checked early to later. That change in particular changed
how the errors interact, because the compiler doesn't offload loops that have
early-detected errors.
These particular tests are rather u
Dear All,
Somewhat belatedly, I have applied the patch to 5 branch and have
committed as revision 228952.
Closing the PR forthwith.
Paul
On 24 May 2015 at 09:51, Paul Richard Thomas
wrote:
> Dear Andre,
>
> I'll put both points right. Thanks for pointing them out.
>
> Cheers
>
> Paul
>
> On 23
> You remove
>
>
> @@ -5269,16 +5268,6 @@ expand_debug_locations (void)
>
> if (!val)
> val = gen_rtx_UNKNOWN_VAR_LOC ();
> - else
> - {
> - mode = GET_MODE (INSN_VAR_LOCATION (insn));
> -
> - gcc_assert (mode == GET_MODE (val)
> -
This fortran testcase was passing by not testing what it thought it was testing.
The loop over which the reduction is specified is not partitioned, and hence
the reduction was being elided.
Fixing that problem turns out to be more involved, and a distraction from
completing the patch series
On 10/16/2015 05:28 AM, Paolo Bonzini wrote:
On 08/10/2015 06:59, Richard Henderson wrote:
+/* Address space support.
+
+ This is not "far pointers" in the 16-bit sense, but an easy way
+ to use %fs and %gs segment prefixes. Therefore:
+
+(a) All address spaces have the same modes,
+
Hi!
gengtype has an option '-d' which allows to dump it's internal state. I planned
to use it in order to create some kind of list of all data which GCC stores in
garbage-collected memory.
Unfortunately this option was broken. The attached patch fixes it. Because it
only affects gengtype's intern
On 10/06/2015 03:56 PM, Richard Biener wrote:
> The generators should simply unconditionally check (not in generated
> files, of course).
> And the generated code parts should use flag_checking.
>
> Richard.
genautomata has some macros similar to tree checks, so I avoided changing them.
gencondit
On 10/06/2015 03:45 PM, Richard Biener wrote:
> On Tue, Oct 6, 2015 at 2:41 PM, Bernd Schmidt wrote:
>> On 10/06/2015 01:32 AM, Mikhail Maltsev wrote:
>>>
>>> gcc/ChangeLog:
>>>
>>> 2015-10-05 Mikhail Maltsev
>>>
>>> * alloc-pool.h (base_pool_allocator::initialize, ::allocate,
>>>
On 10/06/2015 03:59 PM, Richard Biener wrote:
> On Tue, Oct 6, 2015 at 2:46 PM, Bernd Schmidt wrote:
>> On 10/06/2015 01:39 AM, Mikhail Maltsev wrote:
>>>
>>> void verify_insn_chain (void);
>>> +static inline void checking_verify_insn_chain ();
>>> static void fixup_fallthru_exit_predecessor (
On 10/12/2015 11:57 PM, Jeff Law wrote:
> On 10/06/2015 06:40 AM, Bernd Schmidt wrote:
>> I'm not entirely sure what to make of this series. There seem to be good
>> bits in there but also some things I find questionable. I'll add some
>> comments on things that occur to me.
> Maybe we should start
I've committed this patch to gomp4, which completes the reorganization of moving
the loop partitioning machinery into the device compiler.
In the device compiler we traverse the openacc loop structures and pay attention
to the loop header marker information to assign appropriate parallelizatio
23 matches
Mail list logo
