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:
> 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
>
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,
> When fixing up the template specialization hasher I was confused by the
> control flow through template_args_equal. This reorders the category
> checking, so it is clearer as to what kind of node can reach which point.
>
> nathan
>
> 2020-05-13 Nathan Sidwell
>
> * pt.c
> 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
>
> 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
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
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
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
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
>
> 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
> 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
> 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
> 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_operand() when
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
> 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
> 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
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
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
Makrus, Andrew, thanks for your suggestions.
On Sep 9, 2014, at 2:57 AM, Markus Trippelsdorf mar...@trippelsdorf.de
wrote:
On 2014.09.09 at 17:35 +0800, Arseny Solokha wrote:
Hello,
I've recently faced an issue I'm afraid I currently unable to debug. When
building an arbitrary version
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:203: (DF)
Recent changes in GetPcSpBp() (libsanitizer/asan/asan_linux.cc) made it
impossible to build 4.10.0-alpha20140525 snapshot for powerpc targets. The
proposed patch disables building libsanitizer for powerpc*-*-linux* in addition
to already disabled powerpc*le-*-linux* until the smarter solution will
22 matches
Mail list logo
