> On 3/25/20 8:58 AM, Bernd Edlinger wrote:
>> On 3/25/20 8:32 AM, Jonathan Wakely wrote:
>>> On Wed, 25 Mar 2020 at 04:48, Bernd Edlinger wrote:
Hi,
I do not want to start a flame war.
I just am curious what was the reason why
the old system cannot be used any mo
> On Fri, Mar 27, 2020 at 07:00:59AM +0100, Bernd Edlinger wrote:
>>PS: I would CC you, Christopher Faylor, but your email address is
>>"cgf-use-the-mailinglist-ple...@gnu.org", so whatever I send there
>>would not reach you.
>
> Well duh? Not being cc'ed is the literal point of the email address.
Hi,
> The first release candidate for GCC 10.1 is available from
>
> https://gcc.gnu.org/pub/gcc/snapshots/10.1.0-RC-20200430/
> ftp://gcc.gnu.org/pub/gcc/snapshots/10.1.0-RC-20200430
>
> and shortly its mirrors. It has been generated from git revision
> r10-8080-g591d857164c37cd0bb96da2a29314
Hi,
>> https://gcc.gnu.org/pipermail/gcc/2020-February/232205.html
>> Looking around, the last two months of gcc now have very small
>> numbers, but e.g. on gcc-patches the mails have very high numbers like
>> 545238.html. Can pipermail provide stable URLs at all? We really
>> need those, we re
Hi,
>> https://gcc.gnu.org/pipermail/gcc/2020-February/232205.html
>> Looking around, the last two months of gcc now have very small
>> numbers, but e.g. on gcc-patches the mails have very high numbers like
>> 545238.html. Can pipermail provide stable URLs at all? We really
>> need those, we re
Hi,
over the course of two years that had passed since the deprecation of the
powerpcspe backend, and a year and a half since its removal from gcc, I've still
been speaking out several times against immediate closing of Bugzilla PRs
against that target[1,2]. IIRC, Andrew has been contemplating a r
> Hi!
>> But it is clearly obvious that the powerpcspe backend won't be revived. After
>> two years of development, rs6000 has diverged too much from the split point,
>> including LRA adoption.
>
> LRA has been supported by the rs6000 port since 2013 (01b1efaa1439),
> and made the default (and on
> Otherwise, I'm proposing to finally close all open PRs filed against
> powerpcspe. I've been able to identify the following ones:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19490
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30259
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37759
> http
Hi,
>> >> PRs from the second group were filed by me, so if there's consensus to
>> >> close all
>> >> of them, the ones from this second group I can close myself. I don't have
>> >> the
>> >> right permissions to modify PRs reported by someone else, so I'd like to
>> >> ask a
>> >> volunteer
> Hi,
>
>
> PRs from the second group were filed by me, so if there's consensus to
> close all
> of them, the ones from this second group I can close myself. I don't have
> the
> right permissions to modify PRs reported by someone else, so I'd like to
> ask a
> volunt
> This failure now appears for powerpc-aix. I do not know if it happens
> for ppc64-linux also.
>
> Bootstrap currently is broken on AIX.
>
> build/genmodes -h > tmp-modes.h
> build/genmodes: config/rs6000/rs6000-modes.def:23: (TF) field format
> must not be set
> build/genmodes: machmode.def:20
Hello,
I've recently faced an issue I'm afraid I currently unable to debug. When
building an arbitrary version of Linux kernel for powerpc-e500v2-linux-gnuspe
target, it seems gcc prior to 5 produces a good image which boots just fine, and
current gcc 5 snapshots (4.10.0-alpha20140810 for example)
Makrus, Andrew, thanks for your suggestions.
>> On Sep 9, 2014, at 2:57 AM, Markus Trippelsdorf
>> wrote:
>>
>>> On 2014.09.09 at 17:35 +0800, Arseny Solokha wrote:
>>> Hello,
>>>
>>> I've recently faced an issue I'm afraid I c
On 09/09/2014 06:05 PM, pins...@gmail.com wrote:
> I have a patch which I need to submit. Maybe by Friday I will do that. It
> fixes the kernel on arm64 but it is generic c front-end patch.
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01146.html fixed kernel
miscompilation for me. The second iss
> I was doing some benchmarking with SPEC 2017 fprate on aarch64
> (Thunderx2) and I am getting some segfaults from GCC while compiling.
>
> I am working with delta to try and cut down one of the test cases
> but I was wondering if anyone else has seen this problem. The
> three tests that segfault
Hi,
I've found recently that rs6000 and powerpcspe backends can easily trip over
various gcc_unreachable()'s and gcc_assert()'s in their respective copies of
print_operand() when provided with some invalid assembly (i.e. assembly written
for other architectures). For example, when feeding
gcc/te
> Hi Arseny,
>
> On Fri, Nov 23, 2018 at 06:15:47PM +0700, Arseny Solokha wrote:
>> I've found recently that rs6000 and powerpcspe backends can easily trip over
>> various gcc_unreachable()'s and gcc_assert()'s in their respective copies of
>> print
> First problem:
>
> The g++.dg/pr85039-2.C tests (I've looked in detail at -std=c++98, but
> -std=c++11 and -std=c++14 appear to follow the same pattern) see gcc
> garbage-collecting a live vector. A subsequent access to the vector with
> vec_quick_push causes a segmentation fault, as m_vecpfx.m
> On 02/09/2017 11:06 AM, Jakub Jelinek wrote:
>> On Thu, Feb 09, 2017 at 01:47:33PM -0500, David Edelsohn wrote:
>>> Freescale did not implement the POWER architecture. Again, POWER is a
>>> comment about the original IBM POWER architecture (RIOS processors)
>>> and used in RISC System/6000 compu
Hi,
> Snapshot gcc-11-20210425 is now available on
> https://gcc.gnu.org/pub/gcc/snapshots/11-20210425/
> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
>
> This snapshot has been generated from the GCC 11 git branch
> with the following options: git://gcc.gnu.org/git/g
20 matches
Mail list logo