On 03/01/16 04:20, Ian Lance Taylor wrote:
On Sat, Jan 2, 2016 at 11:16 AM, Marcin Kościelnicki wrote:
The differences start in the __morestack calling convention. Basically,
since pushing things on stuck is unwieldy and there's only one free
register (%r0 could be used for static chain, %r2-
On 01/04/2016 03:04 AM, Sandra Loosemore wrote:
> No problem; I've checked in the patch. Thank you for spotting those
> mistakes.
Thank you, too!
> There may not be any technical need for it, but we do it anyway. ;-)
OK :-)
Vladimir
smime.p7s
Description: S/MIME Cryptographic Signature
> From: Gerald Pfeifer [mailto:ger...@pfeifer.com]
> Sent: Sunday, January 03, 2016 6:49 AM
>
> On Wed, 16 Dec 2015, Thomas Preud'homme wrote:
> > Currently, the documentation for --with-multilib-list in
> > gcc/doc/install.texi only mentions sh*-*-* and x86-64-*-linux* targets.
> > However, arm*-
This was committed to Rust's copy of libbacktrace in October by Carlos
Liam.
Thanks for your time,
Michael
diff --git a/src/libbacktrace/ChangeLog.jit b/src/libbacktrace/ChangeLog.jit
index 6b60e3b..5ab329c 100644
--- a/src/libbacktrace/ChangeLog.jit
+++ b/src/libbacktrace/ChangeLog.jit
@@ -6,7
On Sat, Jan 2, 2016 at 10:26 AM, H.J. Lu wrote:
> On Sat, Jan 2, 2016 at 3:58 AM, Richard Biener
> wrote:
>> On January 2, 2016 11:32:33 AM GMT+01:00, Uros Bizjak
>> wrote:
>>>On Thu, Dec 31, 2015 at 4:29 PM, H.J. Lu wrote:
On Thu, Dec 31, 2015 at 1:14 AM, Uros Bizjak
>>>wrote:
> On
...
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c(revision 231903)
+++ gcc/c-family/c-common.c(working copy)
@@ -7667,6 +7667,6 @@
if (error_operand_p (align))
return -1;
if (TREE_CODE (align)
While continuing to poke at PR 1078, I found some more attribute
documentation that was inserted into the wrong place. Fixed thusly.
-Sandra
2016-01-03 Sandra Loosemore
gcc/
* doc/extend.texi (Common Function Attributes): Move docs for
MSP430-specific attributes to
(MSP430 Function
On 01/03/2016 01:00 AM, Vladimír Čunát wrote:
On 01/03/2016 01:08 AM, Sandra Loosemore wrote:
If you don't want to bother with that, or don't have commit access to
the repository, I'll check in the patch on your behalf; just let me
know if you want me to do that.
I do *not* have commit access;
On Mon, Dec 14, 2015 at 7:16 AM, Richard Biener wrote:
>
> The following fixes PR68892, the BB vectorizer now happily creates
> a load of dead vector loads (we had a similar bug with loop
> single-element interleaving support in the past). Fixed as a side-effect
> of making the SLP load cost refl
On 03.01.2016 20:01, Mike Stump wrote:
On Jan 3, 2016, at 9:34 AM, Matthias Klose wrote:
On 03.01.2016 17:23, Andrew Haley wrote:
On 03/01/16 15:52, Matthias Klose wrote:
No, libgcj versions up to 4.9.3 didn't change the value for releases taken from
the same branch. All of 4.9.0, 4.9.1, 4.9.
Dear All,
Since I last looked at this PR, it seems to have fixed itself on
trunk. I just committed a testcase as revision 232042.
Cheers
Paul
2016-01-03 Paul Thomas
PR fortran/65045
* gfortran.dg/pr65045.f90: New test.
On 12/31/2015 08:40 AM, Patrick Palka wrote:
If we do create such an initializer, we end up with an error_mark_node
during gimplification, because in cp-gimplify.c we pass this
VEC_INIT_EXPR of the flexible array member to build_vec_init, for which
it spits on an error_mark_node. This happens in
On Jan 3, 2016, at 9:34 AM, Matthias Klose wrote:
> On 03.01.2016 17:23, Andrew Haley wrote:
>> On 03/01/16 15:52, Matthias Klose wrote:
>>> No, libgcj versions up to 4.9.3 didn't change the value for releases taken
>>> from
>>> the same branch. All of 4.9.0, 4.9.1, 4.9.2, 4.9.3 have the same
>>>
On 03.01.2016 17:23, Andrew Haley wrote:
On 03/01/16 15:52, Matthias Klose wrote:
No, libgcj versions up to 4.9.3 didn't change the value for releases taken from
the same branch. All of 4.9.0, 4.9.1, 4.9.2, 4.9.3 have the same
GCJ_CXX_ABI_VERSION. But 5.1, 5.2 and 5.3 have *different* GCJ_CXX_AB
On 03/01/16 15:52, Matthias Klose wrote:
> No, libgcj versions up to 4.9.3 didn't change the value for releases taken
> from
> the same branch. All of 4.9.0, 4.9.1, 4.9.2, 4.9.3 have the same
> GCJ_CXX_ABI_VERSION. But 5.1, 5.2 and 5.3 have *different*
> GCJ_CXX_ABI_VERSIONs.
>
>> > Why change
On 03.01.2016 15:17, Andrew Haley wrote:
On 03/01/16 11:38, Matthias Klose wrote:
On 02.01.2016 17:11, Andrew Haley wrote:
On 02/01/16 15:53, Matthias Klose wrote:
In any case, GCJ_CXX_ABI_VERSION should be changed to not include __GNUC_MINOR__
anymore. Maybe for the gcc-5-branch, set it unc
On 03/01/16 11:38, Matthias Klose wrote:
> On 02.01.2016 17:11, Andrew Haley wrote:
>> On 02/01/16 15:53, Matthias Klose wrote:
> In any case, GCJ_CXX_ABI_VERSION should be changed to not include
> __GNUC_MINOR__
>>> anymore. Maybe for the gcc-5-branch, set it unconditionally to 3 so
On 02.01.2016 17:11, Andrew Haley wrote:
On 02/01/16 15:53, Matthias Klose wrote:
In any case, GCJ_CXX_ABI_VERSION should be changed to not include __GNUC_MINOR__
anymore. Maybe for the gcc-5-branch, set it unconditionally to 3 so that it
won't change anymore with future releases from the gcc-
On 03/01/16 04:20, Ian Lance Taylor wrote:
On Sat, Jan 2, 2016 at 11:16 AM, Marcin Kościelnicki wrote:
The differences start in the __morestack calling convention. Basically,
since pushing things on stuck is unwieldy and there's only one free
register (%r0 could be used for static chain, %r2-
On 01/03/2016 01:08 AM, Sandra Loosemore wrote:
> If you don't want to bother with that, or don't have commit access to
> the repository, I'll check in the patch on your behalf; just let me
> know if you want me to do that.
I do *not* have commit access; I should've stressed that. I'll be glad
if
20 matches
Mail list logo
