On Fri, 2014-04-04 at 21:14 +0200, Samuel Thibault wrote:
> Hello,
>
> Thomas Schwinge, le Wed 26 Jun 2013 23:30:03 +0200, a écrit :
> > On Sat, 22 Jun 2013 08:15:46 -0700, Ian Lance Taylor
> > wrote:
> > > Go can work without split stack. In that case libgo will use much
> > > larger stacks fo
Hi!
On Wed, 9 Apr 2014 09:05:46 +0200, Svante Signell
wrote:
> On Fri, 2014-04-04 at 21:14 +0200, Samuel Thibault wrote:
> > Thomas Schwinge, le Wed 26 Jun 2013 23:30:03 +0200, a écrit :
> > > On Sat, 22 Jun 2013 08:15:46 -0700, Ian Lance Taylor
> > > wrote:
> > > > Go can work without split s
On 04.04.2014 14:44, Alexey Merzlyakov wrote:
Hi all,
Here is a patch, that fixes infinite backtraces in __cxa_end_cleanup().
The Bugzilla entry for
this:http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60758
The __cxa_end_cleanup() does not save/restore LR in function
header/footer and does not
On April 8, 2014 8:03:08 PM CEST, Jason Merrill wrote:
>On 04/08/2014 07:58 AM, Richard Biener wrote:
>> Jason, is good or shall I use sth else (do we annotate
>in-charge vs. not in-charge
>> constructors specially for example?).
>
>The names of the in-charge and not-in-charge constructor clones
Hi,
On Tue, Apr 08, 2014 at 01:58:06PM +0200, Richard Biener wrote:
>
> This fixes PR60761 by dumping decl context of function clones
> as origin with appended instead of that now
> appears after we (compared to 4.8) clear DECL_LANG_SPECIFIC.
>
> Thus for the testcase in PR60761 we now print
>
On Fri, Apr 04, 2014 at 10:38:49AM -0500, Bill Schmidt wrote:
> Thanks to everyone who helped with development, testing, and review of
> the patch set! I've committed the changes to 4.8 this morning. Note
> that patch 15/26 was rejected as not really germane to this series and
> has been submitte
> FYI, all other targets that have LRA optionally selectable or deselectable
> use -mno-lra for this (even when -mlra is the default), it would be better
> for consistency not to invent new switch names for that.
Agreed.
>> -return !strict_p || GET_MODE_SIZE (mode) == 4 || GET_MODE_SIZE (mode
On Wed, Apr 09, 2014 at 11:51:54AM +0200, Jakub Jelinek wrote:
> On Fri, Apr 04, 2014 at 10:38:49AM -0500, Bill Schmidt wrote:
> > Thanks to everyone who helped with development, testing, and review of
> > the patch set! I've committed the changes to 4.8 this morning. Note
> > that patch 15/26 wa
Hi Lin,
thanks for clarifying this.
If you say you can't sign the FSF copyright assignment,
we can't use your patch, I'm afraid.
Well, I was curious how to proceed, because these unaligned
stm instructions are also a problem under linux.
The test cases don't fail, because the exception handler
Hi Bernd,
Seem we are not talking the same problem.You should first make sure
what has been going wrong first.
And I will sign it.
--
Regards
lin zuojian
Hi Lin,
> Seem we are not talking the same problem.You should first make sure
> what has been going wrong first.
Maybe I misunderstood your point.
> And I will sign it.
> --
> Regards
> lin zuojian
Ok, then please do it.
Once you have signed it, and got the approval by a global GCC reviewer,
Hi Bernd,
I am asking them if they would accept a scaned image version.Post
station is so 90's
--
Regards
lin zuojian
On 04/09/14 09:07, Alexey Merzlyakov wrote:
On 04.04.2014 14:44, Alexey Merzlyakov wrote:
Hi all,
Here is a patch, that fixes infinite backtraces in __cxa_end_cleanup().
The Bugzilla entry for
this:http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60758
The __cxa_end_cleanup() does not save/restore
> The only changes I've found are: (in the previously attached patch)
> (the other commits refer to
> 2014-01-26: lynxos
> 2014-01-24: android
> 2014-01-20: linux
> 2013-01-29 : vms
> and they are not related to the patches needing a revert.
OK, thanks for the clarification. Let's try to find a m
ping..
2014-04-04 15:28 GMT+04:00 Alexander Ivchenko :
> 2014-04-04 14:19 GMT+04:00 Richard Biener :
>> On Fri, Apr 4, 2014 at 12:03 PM, Alexander Ivchenko
>> wrote:
>>> *ping*
>>
>> I wonder whether this is consistend between compilers (note GCC is not
>> upstream here?). So eventually all pla
On Wed, Apr 09, 2014 at 03:46:13PM +0400, Alexander Ivchenko wrote:
> ping..
I guess it really depends on whether the libcilkrts sources are going to be
(semi?)regularly imported from some upstream repository or not, and if the
upstream is willing to accept these changes.
The alternative is to mo
> What do you think, Arno? I think that the POSIX breakage (and its fallout for
> the other Unices) is ugly and worth the additional complication.
Yes, your patch looks good to me.
Arno
Hi!
I'd like to ping:
- http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01370.html
PR sanitizer/56781
fix --with-build-config=bootstrap-ubsan bootstrap of lto-plugin
- http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01433.html
PR sanitizer/56781
fix --with-build-config=bootstrap-asan bootstrap
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, April 9, 2014 8:06 AM
> To: Alexander Ivchenko
> Cc: Richard Biener; GCC Patches; Iyer, Balaji V
> Subject: Re: Fix PR60644
>
> On Wed, Apr 09, 2014 at 03:46:13PM +0400, Alexander Ivchenko wrote:
> >
On Wed, Apr 09, 2014 at 01:23:59PM +, Iyer, Balaji V wrote:
>
>
> > -Original Message-
> > From: Jakub Jelinek [mailto:ja...@redhat.com]
> > Sent: Wednesday, April 9, 2014 8:06 AM
> > To: Alexander Ivchenko
> > Cc: Richard Biener; GCC Patches; Iyer, Balaji V
> > Subject: Re: Fix PR606
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, April 9, 2014 9:29 AM
> To: Iyer, Balaji V
> Cc: Alexander Ivchenko; Richard Biener; GCC Patches
> Subject: Re: Fix PR60644
>
> On Wed, Apr 09, 2014 at 01:23:59PM +, Iyer, Balaji V wrote:
> >
> >
The changes are consistent with what is currently in upstream. So
there is no additional work required
2014-04-09 17:31 GMT+04:00 Iyer, Balaji V :
>
>
>> -Original Message-
>> From: Jakub Jelinek [mailto:ja...@redhat.com]
>> Sent: Wednesday, April 9, 2014 9:29 AM
>> To: Iyer, Balaji V
>> C
`q` will out of bound access if `*q` already reach the end of
multilib_options, so check it before increment to prevent condition
check part out of bound access.
btw, this bug is detected by address sanitizer.
2014-04-09 Kito Cheng
* gcc.c (used_arg): Prevent out of bound access for multi
On Wed, Apr 09, 2014 at 10:00:38PM +0800, Kito Cheng wrote:
> `q` will out of bound access if `*q` already reach the end of
> multilib_options, so check it before increment to prevent condition
> check part out of bound access.
>
> btw, this bug is detected by address sanitizer.
Can you please ex
On Wed, 2014-04-09 at 14:41 +0200, Arnaud Charlet wrote:
> > What do you think, Arno? I think that the POSIX breakage (and its fallout
> > for
> > the other Unices) is ugly and worth the additional complication.
>
> Yes, your patch looks good to me.
Would it be possible to have s-osinte-posix.a
for example: arm-elf-eabi in trunk, multilib_options = "marm/mthumb
mfloat-abi=hard"
and it's my configure options:
/home/kito/gcc/gcc-src/configure
--prefix=/home/kito/gcc-workspace/arm-eabi --target=arm-elf-eabi
CFLAGS="-fsanitize=address -g" CXXFLAGS="-fsanitize=address -g"
LDFLAGS="-fsanitize=
> Would it be possible to have s-osinte-posix.adb also for x32 and in
> s-osinte-x32.ads use the following construct:
> ...
>type timespec is private;
> ...
>type timespec is record
> tv_sec : time_t;
> tv_nsec : long log;
>end record;
>pragma Convention (C, timespec);
> Yes, your patch looks good to me.
Thanks, now applied. I'll make sure everything is resynced with it.
--
Eric Botcazou
On Wed, 2014-04-09 at 16:24 +0200, Eric Botcazou wrote:
> > Would it be possible to have s-osinte-posix.adb also for x32 and in
> > s-osinte-x32.ads use the following construct:
> > ...
> >type timespec is private;
> > ...
> >type timespec is record
> > tv_sec : time_t;
> > tv_
On Wed, 2014-04-09 at 11:51 +0200, Jakub Jelinek wrote:
> On Fri, Apr 04, 2014 at 10:38:49AM -0500, Bill Schmidt wrote:
> > Thanks to everyone who helped with development, testing, and review of
> > the patch set! I've committed the changes to 4.8 this morning. Note
> > that patch 15/26 was rejec
On Wed, 2014-04-09 at 12:03 +0200, Jakub Jelinek wrote:
> Another issue is bad toplevel ChangeLog entries.
> 2014-04-04 Bill Schmidt
>
> Backport from mainline
> 2013-11-22 Ulrich Weigand
>
> * libgo/config/libtool.m4: Update to mainline version.
> * libgo/configure:
On Wed, Apr 09, 2014 at 10:27:33AM -0500, Bill Schmidt wrote:
> Ah, right. I had meant to fix this before committing the patch set and
> dropped the ball.
Thanks.
> One question: Where are ChangeLog entries supposed to go for libgo?
> There doesn't seem to be any kind of ChangeLog file for that
On Wed, Apr 09, 2014 at 11:37:35AM +0200, Martin Jambor wrote:
> I think you should use DECL_ABSTRACT_ORIGIN instead of
> former_clone_of. Not only you avoid using cgraph stuff here but
> unlike this patch, it also works for IPA-CP clones of IPA-SRA clones
> (yeah, I know, but I bet I can cause th
On Wed, Apr 9, 2014 at 7:55 AM, Eric Botcazou wrote:
>> Yes, your patch looks good to me.
>
> Thanks, now applied. I'll make sure everything is resynced with it.
>
I got
/export/build/gnu/gcc-x32/build-x86_64-linux/./gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/./gcc/
-B/usr/gcc-4.9.
More detail for arm-elf-eabi :)
After first iteration at gcc.c:7493-7534, r = q = "mfloat-abi=hard"
at gcc.c:7498
then continue scan multilib_options at gcc.c:7499-7507,
and then `q` already reach the end of `multilib_options` which mean
`q` == multilib_options + strlen(multilib_options)
so the `
All,
It happens with all mulitilib configurations not just arm-elf
if we have reached the end of the multilib_options string there are
no more options to process so break from the loop.
This patch is an alternative fix.
=
Index: gcc.c
===
On Tue, 2014-04-08 at 13:39 -0500, Pat Haugen wrote:
> On 03/25/2014 11:20 AM, Pat Haugen wrote:
> > Power8 can use lq/stq instructions for TI mode atomic_load/store.
> > Bootstrap/regtest with no new failures. Ok for trunk and 4.8 (once
> > bootstrap/regtest finishes)?
> >
> > -Pat
> >
> >
> > 2
On 04/09/2014 04:21 AM, Richard Biener wrote:
The names of the in-charge and not-in-charge constructor clones are
complete_ctor_identifier and base_ctor_identifier (and dtor for
destructors); you could check for those.
I was more asking for how we present those To the user in diagnostics. I wan
Cleaned up as r209249.
On Wed, 2014-04-09 at 17:28 +0200, Jakub Jelinek wrote:
> On Wed, Apr 09, 2014 at 10:27:33AM -0500, Bill Schmidt wrote:
> > Ah, right. I had meant to fix this before committing the patch set and
> > dropped the ball.
>
> Thanks.
>
> > One question: Where are ChangeLog en
Cleaned up as r209250.
On Wed, 2014-04-09 at 11:51 +0200, Jakub Jelinek wrote:
> On Fri, Apr 04, 2014 at 10:38:49AM -0500, Bill Schmidt wrote:
> > Thanks to everyone who helped with development, testing, and review of
> > the patch set! I've committed the changes to 4.8 this morning. Note
> > th
Eric Botcazou writes:
> In order to avoid creating more x32-specific files, I think that we
> need to move the definition of 'struct timespec' and 'struct timeval'
> (both specified by POSIX) to s-linux.ads. This requires with'ing
> Interfaces.C, but I think that's OK since s-linux.ads is a spin-
I have reverted this on trunk and asked Bill to revert this on the 4.8
branch. This patch is too risky to apply this close to a freeze for
4.9.
Sorry for the problems.
- David
On Wed, Apr 9, 2014 at 2:56 PM, Bill Schmidt
wrote:
> On Tue, 2014-04-08 at 13:39 -0500, Pat Haugen wrote:
>> On 03/25
Value range propagation simplifies convergence in vrp_visit_phi_node by
setting minimum to TYPE_MIN when the computed minimum is smaller than
the previous minimum. This can however result in pessimistic value
ranges in some cases.
for example,
unsigned int i;
for (i = 0; i < 8; i+
On Wed, 2014-04-09 at 15:56 -0400, David Edelsohn wrote:
> I have reverted this on trunk and asked Bill to revert this on the 4.8
> branch. This patch is too risky to apply this close to a freeze for
> 4.9.
I've reverted this on 4.8 as r209254.
Thanks,
Bill
>
> Sorry for the problems.
>
> - Da
OK.
Jason
> I got
>
> /export/build/gnu/gcc-x32/build-x86_64-linux/./gcc/xgcc
> -B/export/build/gnu/gcc-x32/build-x86_64-linux/./gcc/
> -B/usr/gcc-4.9.0-x32/x86_64-unknown-linux-gnu/bin/
> -B/usr/gcc-4.9.0-x32/x86_64-unknown-linux-gnu/lib/ -isystem
> /usr/gcc-4.9.0-x32/x86_64-unknown-linux-gnu/include -isys
> In my worthless opinion, it is a mistake to declare POSIX data types in
> s-linux.ads, they should be in s-posix.ads or similar (don't worry if
> that's a new file; and it should not be a "leaf" package). Think of
> GNU/kFreeBSD and GNU/Hurd, which have nothing to do with Linux.
> Furthermore th
Hmm, I would expect the parameter numbering for attribute nonnull and
such to ignore the 'this' parameter.
Jason
Robert Suchanek writes:
>> FYI, all other targets that have LRA optionally selectable or deselectable
>> use -mno-lra for this (even when -mlra is the default), it would be better
>> for consistency not to invent new switch names for that.
>
> Agreed.
>
>>> -return !strict_p || GET_MODE_SIZE (
On Wed, 9 Apr 2014, Jason Merrill wrote:
Hmm, I would expect the parameter numbering for attribute nonnull and such to
ignore the 'this' parameter.
The doc for the "format" attribute says clearly:
"Since non-static C++ methods have an implicit this argument, the
arguments of such methods sho
On Wed, Apr 9, 2014 at 2:07 PM, Eric Botcazou wrote:
>> I got
>>
>> /export/build/gnu/gcc-x32/build-x86_64-linux/./gcc/xgcc
>> -B/export/build/gnu/gcc-x32/build-x86_64-linux/./gcc/
>> -B/usr/gcc-4.9.0-x32/x86_64-unknown-linux-gnu/bin/
>> -B/usr/gcc-4.9.0-x32/x86_64-unknown-linux-gnu/lib/ -isystem
Hi,
please, if at ever possible, consider this patch for 4.8.3:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00026.html
Thanks,
Daniel.
--
Daniel F. Gutson
Chief Engineering Officer, SPD
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888 / +54 351 421821
> Now I got
>
> /export/build/gnu/gcc-x32/build-x86_64-linux/./gcc/xgcc
> -B/export/build/gnu/gcc-x32/build-x86_64-linux/./gcc/
> -B/usr/gcc-4.9.0-x32/x86_64-unknown-linux-gnu/bin/
> -B/usr/gcc-4.9.0-x32/x86_64-unknown-linux-gnu/lib/ -isystem
> /usr/gcc-4.9.0-x32/x86_64-unknown-linux-gnu/include -
On Wed, Apr 9, 2014 at 2:59 PM, Eric Botcazou wrote:
>> Now I got
>>
>> /export/build/gnu/gcc-x32/build-x86_64-linux/./gcc/xgcc
>> -B/export/build/gnu/gcc-x32/build-x86_64-linux/./gcc/
>> -B/usr/gcc-4.9.0-x32/x86_64-unknown-linux-gnu/bin/
>> -B/usr/gcc-4.9.0-x32/x86_64-unknown-linux-gnu/lib/ -isys
> - http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01370.html
> PR sanitizer/56781
> fix --with-build-config=bootstrap-ubsan bootstrap of lto-plugin
I have no particular problem with this patch, although the build has
gotten beyond my full understanding these days...
However, does this fix a r
> It compiles. I will run GCC test.
Thanks. I installed the fixlets in the meantime.
--
Eric Botcazou
Merge the remainder of projects/web.html into about.html and
shorten the latter on the way. Set up and adjust redirects
accordingly.
Applied.
And that's it as far as this mini project goes. 4 of 3 is already
a bit much. ;-)
Gerald
Index: about.html
==
Hi,
For the testcase 1.c
#include
double a[1000];
__m128d foo1() {
__m128d res;
res = _mm_load_sd(&a[1]);
res = _mm_loadh_pd(res, &a[2]);
return res;
}
llvm will merge movsd/movhpd to movupd while gcc will not. The merge
is beneficial on x86 machines starting from Nehalem.
The patch
On Thu, Apr 10, 2014 at 8:18 AM, Wei Mi wrote:
> Hi,
>
> For the testcase 1.c
>
> #include
>
> double a[1000];
>
> __m128d foo1() {
> __m128d res;
> res = _mm_load_sd(&a[1]);
> res = _mm_loadh_pd(res, &a[2]);
> return res;
> }
>
> llvm will merge movsd/movhpd to movupd while gcc will not.
Hi Bin,
Yes, we have the same problem that if movsd and movhpd are separated,
peephole cannot merge them. The patch could solve the motivational
performance issue we saw to a good extent, but maybe there is still
space to improve if peephole misses some pairs. Glad to know you are
working on this
On 04/09/14 07:07, Jakub Jelinek wrote:
Hi!
I'd like to ping:
- http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01370.html
PR sanitizer/56781
fix --with-build-config=bootstrap-ubsan bootstrap of lto-plugin
- http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01433.html
PR sanitizer/56781
fi
On Wed, Apr 09, 2014 at 06:29:48PM -0400, DJ Delorie wrote:
>
> > - http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01370.html
> > PR sanitizer/56781
> > fix --with-build-config=bootstrap-ubsan bootstrap of lto-plugin
>
> I have no particular problem with this patch, although the build has
> got
62 matches
Mail list logo
