Re: Problems with changing the type of an ssa name

On July 25, 2020 7:30:48 AM GMT+02:00, Gary Oblock via Gcc wrote: >If you've followed what I've been up to via my questions >on the mailing list, I finally traced my latest big problem >back to to my own code. In a nut shell here is what >I'm doing. > >I'm creating a new type exaactly like this:

Problems with changing the type of an ssa name

If you've followed what I've been up to via my questions on the mailing list, I finally traced my latest big problem back to to my own code. In a nut shell here is what I'm doing. I'm creating a new type exaactly like this: tree pointer_rep = make_signed_type ( TYPE_PRECISION ( pointer_

gcc-9-20200724 is now available

Snapshot gcc-9-20200724 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20200724/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

LTO Dead Field Elimination

This patchset brings back struct reorg to GCC. We’ve been working on improving cache utilization recently and would like to share our current implementation to receive some feedback on it. Essentially, we’ve implemented the following components: Type-based escape analysis to determine if

TImode for BITS_PER_WORD=32 targets

Hi all, I want amdgcn to be able to support int128 types, partly because they might come up in code offloaded from x86_64 code, and partly because libgomp now requires at least some support (amdgcn builds have been failing since yesterday). But, amdgcn has 32-bit registers, and therefore def

Bountysource campaign for AVR backend now at $7,150

Hello! I just got a notification that the Bountysource campaign I created to modernize the AVR backend - primarily converting it to MODE_CC - has been bumped to $7,150 by Microchip [1]. I hope this will finally convince someone to complete the task :-). Adrian > [1] > https://www.bountysource

Project Ranger Status

We originally intended to start pushing ranger code into trunk shortly after the start of stage 1, but of course.. delays, delays :-) So here is the latest status/changes since last fall and our proposed time-line going forward.  I'll do the executive summary here, and more details at each sub

Re: Versions of Perl on GCC Prerequisites page

Thomas Koenig via Gcc wrote: now I remember, it was PR82856 which prompted this change (and I put in the wrong version number :-) Looking back at that PR, the uppper level of Perl as reqirement can probably be lifted. I would still prefer a test with --enable-maintainer-mode, to test that the

Re: Versions of Perl on GCC Prerequisites page

Jonathan, now I remember, it was PR82856 which prompted this change (and I put in the wrong version number :-) Looking back at that PR, the uppper level of Perl as reqirement can probably be lifted. I would still prefer a test with --enable-maintainer-mode, to test that the orginal bug has actu