jeevitha writes:
> Hi All,
>
> The following patch has been bootstrapped and regtested with default
> configuration
> [--enable-checking=yes] and with --enable-checking=release on
> powerpc64le-linux.
>
> This patch removes passing the -many assembler option for release builds. Now,
> GCC no lo
Hi All,
The following patch has been bootstrapped and regtested with default
configuration
[--enable-checking=yes] and with --enable-checking=release on powerpc64le-linux.
This patch removes passing the -many assembler option for release builds. Now,
GCC no longer passes -many under any conditio
Hi!
On Wed, May 22, 2024 at 09:29:13AM -0500, Peter Bergner wrote:
> On 5/21/24 8:27 AM, jeevitha wrote:
> > The following patch has been bootstrapped and regtested with default
> > configuration
> > [--enable-checking=yes] and with --enable-checking=release on
> > powerpc64le-linux.
> >
> > Th
On 5/21/24 8:27 AM, jeevitha wrote:
> The following patch has been bootstrapped and regtested with default
> configuration
> [--enable-checking=yes] and with --enable-checking=release on
> powerpc64le-linux.
>
> This patch removes passing the -many assembler option for release builds. Now,
> GCC
Hi All,
The following patch has been bootstrapped and regtested with default
configuration
[--enable-checking=yes] and with --enable-checking=release on powerpc64le-linux.
This patch removes passing the -many assembler option for release builds. Now,
GCC no longer passes -many under any condit
Hi!
On Mon, Apr 06, 2020 at 10:35:34PM +0200, Sebastian Huber wrote:
> What do you think about the attached patch?
(Please use a correct MIME type for attachments (x-* never is correct on
mailing lists. Just text/plain will do fine.)
> libgcc/
>
> * config/rs6000/crtresfpr.S: Disable all
Hello,
I am sorry to come back to this thread after such a long time. I
recently noticed that one of RTEMS multilibs is broken (for whatever
reason it didn't show up in my regular build):
/build/git-build/b-gcc-git-powerpc-rtems5/powerpc-rtems5/m8540/nof/libgcc
(master) > make
# If this is
On Wed, May 22, 2019 at 12:56:15PM +0930, Alan Modra wrote:
> On Tue, May 21, 2019 at 09:48:10AM -0500, Segher Boessenkool wrote:
> > (Is Power5 2.4? Not 2.2?)
>
> Yes, I think power5 was 2.02, but I haven't looked at cpu and arch
> books to verify exactly what power5 and power5+ was.
My notes s
On Tue, May 21, 2019 at 09:48:10AM -0500, Segher Boessenkool wrote:
> > +static const char *
> > +rs6000_machine_from_flags (void)
> > +{
> > + if ((rs6000_isa_flags & (ISA_3_0_MASKS_SERVER & ~ISA_2_7_MASKS_SERVER))
> > != 0)
> > +return "power9";
> > + if ((rs6000_isa_flags & (ISA_2_7_MASKS
Hi!
On Tue, May 21, 2019 at 10:22:26PM +0930, Alan Modra wrote:
> This is a repost of
> https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00911.html with a small
> tweak to rs6000_machine_from_flags (&~ instead of ^).
>
> Bootstrapped and regression tested powerpc64le-linux power8 and
> power9. OK t
This is a repost of
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00911.html with a small
tweak to rs6000_machine_from_flags (&~ instead of ^).
Bootstrapped and regression tested powerpc64le-linux power8 and
power9. OK to apply now that we're in stage1?
* config/rs6000/rs6000.h (ASM_OPT_
On Thu, Dec 13, 2018 at 5:26 AM Alan Modra wrote:
>
> On Wed, Nov 14, 2018 at 01:43:57PM +1030, Alan Modra wrote:
> > On Tue, Nov 13, 2018 at 05:17:41AM -0600, Segher Boessenkool wrote:
> > > On Tue, Nov 13, 2018 at 12:02:55PM +1030, Alan Modra wrote:
> > > > OK, fair enough. Another option is to
On Wed, Nov 14, 2018 at 01:43:57PM +1030, Alan Modra wrote:
> On Tue, Nov 13, 2018 at 05:17:41AM -0600, Segher Boessenkool wrote:
> > On Tue, Nov 13, 2018 at 12:02:55PM +1030, Alan Modra wrote:
> > > OK, fair enough. Another option is to just disable -many when gcc is
> > > in development, like we
On Nov 13, 2018, at 10:39 AM, Peter Bergner wrote:
>
> On 11/13/18 12:06 PM, Iain Sandoe wrote:
>> As far as I expect, Darwin should be untouched by this - we have a separate
>> assembler (which doesn’t even respond to -many), so unless there’s some
>> higher level translation done (it’s not me
On Tue, Nov 13, 2018 at 05:17:41AM -0600, Segher Boessenkool wrote:
> On Tue, Nov 13, 2018 at 12:02:55PM +1030, Alan Modra wrote:
> > OK, fair enough. Another option is to just disable -many when gcc is
> > in development, like we enable checking.
>
> That is a good plan for GCC 9 at least.
Here
On 11/13/18 12:06 PM, Iain Sandoe wrote:
> As far as I expect, Darwin should be untouched by this - we have a separate
> assembler (which doesn’t even respond to -many), so unless there’s some
> higher level translation done (it’s not mentioned in any Darwin specs), we
> should just carry on as
Hi Folks,
> On 13 Nov 2018, at 17:48, Peter Bergner wrote:
>
> On 11/13/18 5:17 AM, Segher Boessenkool wrote:
>> On Tue, Nov 13, 2018 at 12:02:55PM +1030, Alan Modra wrote:
>>> On Mon, Nov 12, 2018 at 04:34:34PM -0800, Mike Stump wrote:
On Nov 12, 2018, at 3:13 PM, Alan Modra wrote:
O
On 11/13/18 5:17 AM, Segher Boessenkool wrote:
> On Tue, Nov 13, 2018 at 12:02:55PM +1030, Alan Modra wrote:
>> On Mon, Nov 12, 2018 at 04:34:34PM -0800, Mike Stump wrote:
>>> On Nov 12, 2018, at 3:13 PM, Alan Modra wrote:
>>> On darwin, we (darwin, as a platform decision) like all instructions
>
On Tue, Nov 13, 2018 at 12:02:55PM +1030, Alan Modra wrote:
> On Mon, Nov 12, 2018 at 04:34:34PM -0800, Mike Stump wrote:
> > On Nov 12, 2018, at 3:13 PM, Alan Modra wrote:
> > >
> > > For people developing new code, it's the right way to go, and
> > > especially so for people working on gcc itse
On Mon, Nov 12, 2018 at 04:34:34PM -0800, Mike Stump wrote:
> On Nov 12, 2018, at 3:13 PM, Alan Modra wrote:
> >
> > For people developing new code, it's the right way to go, and
> > especially so for people working on gcc itself. For people just
> > wanting stuff to compile, not so much. I ful
> On 13 Nov 2018, at 00:34, Mike Stump wrote:
>
> On Nov 12, 2018, at 3:13 PM, Alan Modra wrote:
>>
>> For people developing new code, it's the right way to go, and
>> especially so for people working on gcc itself. For people just
>> wanting stuff to compile, not so much. I fully expect a
On Nov 12, 2018, at 3:13 PM, Alan Modra wrote:
>
> For people developing new code, it's the right way to go, and
> especially so for people working on gcc itself. For people just
> wanting stuff to compile, not so much. I fully expect a chorus of
> *MORON* or worse to come from the likes of the
On Mon, Nov 12, 2018 at 04:17:51PM +, Michael Matz wrote:
> Hi,
>
> On Mon, 12 Nov 2018, Segher Boessenkool wrote:
>
> > > > Wouldn't this also break compiling code that contains power9
> > > > instructions but guarded by runtime tests to only be executed on
> > > > power9 machines? That s
On 11/12/18 5:49 AM, Alan Modra wrote:
> I'd like to remove -many from the options passed by default to the
> assembler, on the grounds that a gcc bug in instruction selection (eg.
> emitting a power9 insn for -mcpu=power8) is better found at assembly
> time than run time.
>
> This might annoy peo
Hi,
On Mon, 12 Nov 2018, Segher Boessenkool wrote:
> > > Wouldn't this also break compiling code that contains power9
> > > instructions but guarded by runtime tests to only be executed on
> > > power9 machines? That seems a valid usecase, and it'd be bad if the
> > > assembler fails to compi
On Mon, Nov 12, 2018 at 03:52:29PM +0100, Andreas Schwab wrote:
> On Nov 12 2018, Michael Matz wrote:
>
> > Wouldn't this also break compiling code that contains power9 instructions
> > but guarded by runtime tests to only be executed on power9 machines? That
> > seems a valid usecase, and it'
On Nov 12 2018, Michael Matz wrote:
> Wouldn't this also break compiling code that contains power9 instructions
> but guarded by runtime tests to only be executed on power9 machines? That
> seems a valid usecase, and it'd be bad if the assembler fails to compile
> such. (You can't use -mcpu=
Hi,
On Mon, 12 Nov 2018, Alan Modra wrote:
> I'd like to remove -many from the options passed by default to the
> assembler, on the grounds that a gcc bug in instruction selection (eg.
> emitting a power9 insn for -mcpu=power8) is better found at assembly
> time than run time.
>
> This might
On Mon, Nov 12, 2018 at 10:19:04PM +1030, Alan Modra wrote:
> I'd like to remove -many from the options passed by default to the
> assembler, on the grounds that a gcc bug in instruction selection (eg.
> emitting a power9 insn for -mcpu=power8) is better found at assembly
> time than run time.
>
>
I'd like to remove -many from the options passed by default to the
assembler, on the grounds that a gcc bug in instruction selection (eg.
emitting a power9 insn for -mcpu=power8) is better found at assembly
time than run time.
This might annoy people for a while fixing user asm that we didn't
diag
30 matches
Mail list logo
