I discovered a short coming in the patch I proposed to add
-mno-load-vector-pair and -mno-store-vector-pair tuning options. I will submit
a new patch shortly.
| Date: Fri, 13 Oct 2023 19:41:13 -0400
| From: Michael Meissner
| Subject: [PATCH] Power10: Add options to disable load and store vector
> I'm kind of torn on this one: this has been around for a while and
> dropping it would be an ABI break, but the feedback from distro folks is
> pretty consistently that multlib is broken on RISC-V. If it's really
> unusably broken then I could buy the argument that there's no binaries
> (and
On 2022-07-14, Palmer Dabbelt wrote:
On Mon, 20 Jun 2022 20:48:50 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On Mon, Jun 20, 2022 at 1:21 AM Kito Cheng wrote:
Generally I agree we should fix that by GCC driver rather than ld
emulation, but I think this should be reverted with the -L path fix
On Mon, 20 Jun 2022 20:48:50 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On Mon, Jun 20, 2022 at 1:21 AM Kito Cheng wrote:
Generally I agree we should fix that by GCC driver rather than ld
emulation, but I think this should be reverted with the -L path fix,
otherwise that will break multilib o
On Mon, Jun 20, 2022 at 1:21 AM Kito Cheng wrote:
>
> Generally I agree we should fix that by GCC driver rather than ld
> emulation, but I think this should be reverted with the -L path fix,
> otherwise that will break multilib on GNU toolchain for linux
> immediately?
Thanks for the good conside
Generally I agree we should fix that by GCC driver rather than ld
emulation, but I think this should be reverted with the -L path fix,
otherwise that will break multilib on GNU toolchain for linux
immediately?
On Wed, Jun 15, 2022 at 4:00 PM Fangrui Song via Gcc-patches
wrote:
>
> This reverts co
This reverts commit 37d57ac9a636f2235f9060e84fb8dd7968abd1dc.
The resolution to https://sourceware.org/bugzilla/show_bug.cgi?id=22962
let GCC pass -m emulation to ld and let the ld emulation configure
default library paths. This scheme is problematic:
* It's not ld's business to specify default
On 6/1/21 4:54 PM, Andrew MacLeod wrote:
On 6/1/21 10:51 AM, Aldy Hernandez wrote:
Andrew's last set of changes fixes the bootstrap problem on i686 when
global ranges are exported from evrp. The specific patch that fixes the
problem is 715914d3:
Author: Andrew MacLeod
Date: Mon May
On 6/1/21 10:51 AM, Aldy Hernandez wrote:
Andrew's last set of changes fixes the bootstrap problem on i686 when
global ranges are exported from evrp. The specific patch that fixes the
problem is 715914d3:
Author: Andrew MacLeod
Date: Mon May 31 12:13:50 2021 -0400
Andrew's last set of changes fixes the bootstrap problem on i686 when
global ranges are exported from evrp. The specific patch that fixes the
problem is 715914d3:
Author: Andrew MacLeod
Date: Mon May 31 12:13:50 2021 -0400
Do not calculate new values when evaluatin
Hi,
The attached patch reverts a previously attached patch.
2015-10-06 James Norris
* common.opt (OFFLOAD_ABI_PPC64): New enum.
* config/nvptx/mkoffload.c (compile_native): Handle new enum.
(main): Handle new option.
* config/rs6000/rs6000.c (rs6000_off
On 11/17/2011 02:29 PM, Steve Ellcey wrote:
Testing on IA64 HP-UX shows that this fixes the bootstrap failure and
it found no regressions. Presumably it does slow down the compilation
slightly since the point of fprint_w was to be faster then fprintf.
If someone (Dimitrios?) wants to fix fprint
The checkin r181279 which speeds up the printing of integer constants
caused PR 51144 and broke the IA64 and s390 bootstraps.
The problem is with fprint_w which takes a HOST_WIDE_INT value argument
and uses sprint_ul_rev to process it. But sprint_ul_rev takes a long
argument so if the argument t
I had to revert a minor change in the last patch. It didn't show any
problems in an incremental bootstrap, but once from scratch showed a
compile failure due to a duplicate definition.
I'll have to fix the lack of an atomic_thread_fence or
atomic_signal_fence a different way apparently.
Sor
14 matches
Mail list logo
