Thanks a lot, Andrew
Seems the centos 7.x still use gcc 4.8.5
Does gcc has any plan to push this fix to rhel?
It is really a big bug for arm64
Cheers,
Justin
在 2017/9/21 14:58, Andrew Pinski 写道:
On Wed, Sep 20, 2017 at 11:51 PM, Jia He wrote:
转发的消息
主题: Possible gc
On Thu, Sep 21, 2017 at 03:22:28PM +0800, Jia He wrote:
> Thanks a lot, Andrew
>
> Seems the centos 7.x still use gcc 4.8.5
>
> Does gcc has any plan to push this fix to rhel?
This really doesn't belong to this ml, as gcc 4.8 isn't supported
upstream for years.
That said, it is fixed in RHEL 7.
Hi Andrew,
I tried centos 7.4 gcc 4.8.5-16, which seems to announce to fix this issue.
And I checked the source code, the patch had been included in.
But no luck, the bug is still there.
Could you please please any advice to me? eg. Is there any ways to
disable such
reload compilation procedure
Hello everyone,
I am trying to figure out which are the problems affecting a specific
version of GCC (4.4.2) from the information in the bug tracker
(https://gcc.gnu.org/bugzilla/).
So far I have been able to get a list of the bugs restricted to
standalone C components (c, inline-asm, ipa, prepro
On 21 September 2017 at 12:56, Vicent Brocal wrote:
> Hello everyone,
>
> I am trying to figure out which are the problems affecting a specific
> version of GCC (4.4.2) from the information in the bug tracker
> (https://gcc.gnu.org/bugzilla/).
>
> So far I have been able to get a list of the bugs r
Hi,
First let me say I am also a fan of buildbot. I use it for a couple of
projects and it is really flexible, low on resources, easy to add new
builders/workers and easily extensible if you like python.
On Thu, 2017-09-21 at 07:18 +0200, Markus Trippelsdorf wrote:
> And it has the basic problem
On 20 September 2017 at 17:01, Paulo Matos wrote:
> Hi all,
>
> I am internally running buildbot for a few projects, including one for a
> simple gcc setup for a private port. After some discussions with David
> Edelsohn at the last couple of Cauldrons, who told me this might be
> interesting for
For a C standalone application (no libs) I selected the following
components: c, inline-asm, ipa, preprocessor, regression,
rtl-optimization, target, tree-optimization.
Am I missing any that could be relevant?
A search only filtering for these components shows >4k results. I guess
that I need to
Hi Justin,
> I tried centos 7.4 gcc 4.8.5-16, which seems to announce to fix this issue.
> And I checked the source code, the patch had been included in.
> But no luck, the bug is still there.
>
> Could you please please any advice to me? eg. Is there any ways to disable
> such
> reload compilati
Hi Wilcon
The 4.8.5 is default gcc version for centos 7.x
Ok, I will consider to upgrade the gcc version.
Thanks for your advice.
Cheers,
Justin
在 9/21/2017 8:56 PM, Wilco Dijkstra Wrote:
Hi Justin,
I tried centos 7.4 gcc 4.8.5-16, which seems to announce to fix this issue.
And I checke
On 09/20/2017 11:18 PM, Markus Trippelsdorf wrote:
On 2017.09.20 at 18:01 -0500, Segher Boessenkool wrote:
Hi!
On Wed, Sep 20, 2017 at 05:01:55PM +0200, Paulo Matos wrote:
This mail's intention is to gauge the interest of having a buildbot for
GCC.
+1. Or no, +100.
- which machines we can
On 09/21/2017 06:22 AM, Vicent Brocal wrote:
For a C standalone application (no libs) I selected the following
components: c, inline-asm, ipa, preprocessor, regression,
rtl-optimization, target, tree-optimization.
Am I missing any that could be relevant?
A search only filtering for these compon
El 21 set 2017, a les 17:50, Martin Sebor va escriure:
>
> On 09/21/2017 06:22 AM, Vicent Brocal wrote:
>> For a C standalone application (no libs) I selected the following
>> components: c, inline-asm, ipa, preprocessor, regression,
>> rtl-optimization, target, tree-optimization.
>>
>> Am I mis
Hi Justin,
> The 4.8.5 is default gcc version for centos 7.x
If there is no newer version available you should talk to your distro.
It is worth reporting this bug to them as more of their users may be
affected by it.
Wilco
On Thu, 21 Sep 2017, Markus Trippelsdorf wrote:
> And it has the basic problem of all automatic testing: that in the long
> run everyone simply ignores it.
Hence, see my comments about the value of having someone who monitors the
results and files bugs / notifies patch authors / fixes issues.
I
Hi!
Sending this to the "main" GNU tools mailing lists. Of course, that's
not meant to exclude other tools.
Amongst other things ;-) at the GNU Tools Cauldron 2017 we discussed
whether having a "Reviewed-by" tag in the commit log might provide an
incentive for more people to invest time in patc
On 09/21/2017 10:50 AM, Thomas Schwinge wrote:
> So my question is, if I've gotten a patch reviewed by someone who is not
> yet ;-) familiar with that new process, and I nevertheless want to
> acknowledge their time invested in review by putting "Reviewed-by" into
> the commit log, is it fine to do
On September 21, 2017 7:38:29 PM GMT+02:00, Carlos O'Donell
wrote:
>On 09/21/2017 10:50 AM, Thomas Schwinge wrote:
>> So my question is, if I've gotten a patch reviewed by someone who is
>not
>> yet ;-) familiar with that new process, and I nevertheless want to
>> acknowledge their time invested
On 09/21/2017 11:56 AM, Richard Biener wrote:
>> Not yet.
>
> I think given an OK from an official reviewer entitles you to commit
> it indeed IS matching the formal statement. It better does...
Isn't it better to be explicit about this; rather than assuming?
>> All of this is nothing compared t
On September 21, 2017 8:18:39 PM GMT+02:00, Carlos O'Donell
wrote:
>On 09/21/2017 11:56 AM, Richard Biener wrote:
>>> Not yet.
>>
>> I think given an OK from an official reviewer entitles you to commit
>> it indeed IS matching the formal statement. It better does...
>
>Isn't it better to be expl
On 09/21/2017 12:38 PM, Richard Biener wrote:
> On September 21, 2017 8:18:39 PM GMT+02:00, Carlos O'Donell
> wrote:
>> On 09/21/2017 11:56 AM, Richard Biener wrote:
Not yet.
>>>
>>> I think given an OK from an official reviewer entitles you to commit
>>> it indeed IS matching the formal sta
On 20/09/17 19:14, Joseph Myers wrote:
> On Wed, 20 Sep 2017, Paulo Matos wrote:
>
>> - buildbot can notify people if the build fails or if there's a test
>> regression. Notification can be sent to IRC and email for example. What
>> would people prefer to have as the settings for notifications?
On 21/09/17 01:01, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Sep 20, 2017 at 05:01:55PM +0200, Paulo Matos wrote:
>> This mail's intention is to gauge the interest of having a buildbot for
>> GCC.
>
> +1. Or no, +100.
>
>> - which machines we can use as workers: we certainly need more worke
On 21/09/17 02:27, Joseph Myers wrote:
> On Wed, 20 Sep 2017, Segher Boessenkool wrote:
>
>>> - buildbot can notify people if the build fails or if there's a test
>>> regression. Notification can be sent to IRC and email for example. What
>>> would people prefer to have as the settings for notif
On 21/09/17 14:11, Mark Wielaard wrote:
> Hi,
>
> First let me say I am also a fan of buildbot. I use it for a couple of
> projects and it is really flexible, low on resources, easy to add new
> builders/workers and easily extensible if you like python.
>
> On Thu, 2017-09-21 at 07:18 +0200, Ma
On 21/09/17 16:41, Martin Sebor wrote:
>
> The regression and the testresults lists are useful but not nearly
> as much as they could be. For one, the presentation isn't user
> friendly (a matrix view would be much more informative). But even
> beyond it, rather than using the pull model (peop
On 21/09/17 14:18, Christophe Lyon wrote:
>>
>> If this is something of interest, then we will need to understand what
>> is required, among those:
>>
>> - which machines we can use as workers: we certainly need more worker
>> (previously known as slave) machines to test GCC in different
>> archs
Snapshot gcc-7-20170921 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170921/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
On Thu, 21 Sep 2017, Paulo Matos wrote:
> I totally agree that only if people get involved in checking if there
> were regressions and keeping an eye on what's going on are things going
> to improve. The framework can help a lot here by notifying the right
> people and the mailing list if somethin
On Thu, 21 Sep 2017, Paulo Matos wrote:
> Interesting suggestion. I haven't had the opportunity to look at the
> compile farm. However, it could be interesting to have a mix of workers:
> native compile farm ones and some x86_64 doing cross compilation and
> testing.
Note that even without a simu
在 9/21/2017 5:25 PM, Jia He Wrote:
Hi Andrew,
I tried centos 7.4 gcc 4.8.5-16, which seems to announce to fix this
issue.
And I checked the source code, the patch had been included in.
My fault. All the gcc related rpms are needed to upgrade to
4.8.5-16(only upgrading
gcc*.rpm is not enough
31 matches
Mail list logo
