| Hi dear customer,
Have a great day. My name is Peter.
We are the facotory in China, produce stone abrasive and diamond tools.
Our main products as below:
1. Cutting tools.
2. Grinding & polishing tools.
3. Other tools to process stone, concrete, ceramics etc.
We also can make tools as
I'd like to PING:
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01713.html
I've included the entire patch below, since I missed the test cases in
the original submission and Segher asked for some updated text for the
hook documentation which I've included below.
Peter
gcc/
On 7/5/18 2:36 PM, Jeff Law wrote:
> On 07/02/2018 03:50 PM, Peter Bergner wrote:
>> I'd like to PING:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01713.html
>>
>> I've included the entire patch below, since I missed the test cases in
>>
hes. Thank you! And thanks to Mike
> for the testing.
I've committed the back ports to the FSF 7, 8 and 9 branches now after
clean bootstraps and regtesting.
Peter
a valid insn. The fix below fixes the ICE reported in PR92090 by
modifying our input_operand predicate to allow MODE_PARTIAL_INT modes for
integer constant input operands.
This patch (preapproved by Segher) passed bootstrap and regtesting
with no errors. Committed.
Peter
gcc/
PR other
the updated test cases now pass on both BE and LE.
Ok for trunk?
Peter
PR target/92923
PR target/93136
* gcc.dg/vmx/ops.c: Add -flax-vector-conversions to dg-options.
* gcc.target/powerpc/vsx-vector-6.p7.c: Adjust scan-assembler-times
regex directives.
On 1/9/20 4:51 PM, Segher Boessenkool wrote:
> On Thu, Jan 09, 2020 at 01:44:59PM -0600, Peter Bergner wrote:
>> The other test cases just need a slight adjustment to some of their
>> counts.
>
> What were the changes? Or, I'll just trust you looked at it and it is
>
On 1/9/20 6:29 PM, Peter Bergner wrote:
> On 1/9/20 4:51 PM, Segher Boessenkool wrote:
>> Splitting out separate functions in the testcase shouldn't be so much
>> work? Or am I too optimistic :-)
>>
>> This should make the test a good deal less prone to random ch
ckets
on the above regex. Thanks.
Peter
on???
> Okay for trunk minus the changes to powerpc-dfp.exp (we can iterate on
> that). Thanks!
Ok, I committed that part of the patch. Thanks!
Peter
On 12/4/19 2:47 PM, Iain Sandoe wrote:
> Peter Bergner wrote:
>>
>> Why isn't just testing check_effective_target_dfp enough to disable the
>> tests on Darwin, --disable-decimal-float, etc.?
>
> … It should be a better solution - I will confirm this.
Thanks for
he effective target.
Right, if using the effective target test, any target that adds DFP support
in the future will automatically get these tests runs for it, which is what
we want.
Peter
On 12/5/19 2:44 AM, Iain Sandoe wrote:
> Segher Boessenkool wrote:
>> On Wed, Dec 04, 2019 at 03:53:30PM -0600, Peter Bergner wrote:
>>> Sure, I can add a test in gcc.target/powerpc/ that uses both a builtin
>>> and an overloaded builtin to make sure we don't ICE w
this target, ignored" >&5
$as_echo "$as_me: WARNING: decimal float is not supported for this target,
ignored" >&2;}
enable_decimal_float=no
;;
So I don't think there is anything to do wrt Darwin here.
Peter
On 12/4/19 5:03 PM, Segher Boessenkool wrote:
> On Wed, Dec 04, 2019 at 03:53:30PM -0600, Peter Bergner wrote:
>> Right. I'll come up with a patch and hopefully Iain and David can test
>> on Darwin and AIX and I can test on Linux with --enable-decimal-float
>> and --di
On 12/10/19 12:27 PM, Peter Bergner wrote:
> Ok, how about the patch below? If Iain and David could test this on Darwin
> and AIX respectively, that would be great. I'm currently testing this on
> powerpc64le-linux, with and without --disable-decimal-float.
So my --enable-decima
trunk?
This is a bug on the release branches too, but given how big this patch
ended up being, I don't think we want to backport this.
Peter
gcc/
PR target/92923
* config/rs6000/rs6000-builtin.def (VAND, VANDC, VNOR, VOR,
VXOR): Delete.
(EQV_V16QI_UNS, EQ
Looking closer, that dfp_hw is a runtime test and not
what we want. I'll change this to using "hard_dfp" which is a
compile time test.
> Nice cleanups! Please fix that dfp_hw thing, and then, okay for trunk,
> Thanks!
Will do, thanks. I'll commit this after making these changes and
rerunning the updated test cases.
Peter
t; That's scan-tree-dump-not.
Ahh, that is better. Fixed.
> Same comments for the p8 test of course. Okay with or without those
> adjusted (they aren't wrong, just weird style).
Fixed too.
Peter
On 12/20/19 12:20 PM, Peter Bergner wrote:
>> On what kind of system did you test?
>>
>> I'd like to see this tested on both BE and LE, and various processor
>> generations -- but we'll see if it regresses anyway, and it is still
>> stage 3. So, okay fo
On Sat, Nov 13, 2021 at 03:37:24PM -0500, David Malcolm wrote:
> This approach is much less expressive that the custom addres space
> approach; it would only cover the trust boundary aspect; it wouldn't
> cover any differences between generic pointers and __user, vs __iomem,
> __percpu, and __rcu
On Mon, Nov 15, 2021 at 12:33:16PM +0530, Prathamesh Kulkarni wrote:
> On Sun, 14 Nov 2021 at 02:07, David Malcolm via Gcc-patches
> > +/* Handle "returns_zero_on_failure" and "returns_zero_on_success"
> > attributes;
> > + arguments as in struct attribute_spec.handler. */
> > +
> > +static tr
we get an approval
to backport this to all the open release branches (GCC 13, 12, 11)?
Thanks.
Jeevitha, once we get approval, please perform the backports.
Peter
m rs6000_builtin_type_index): Add fields
>> to hold PTImode type.
>
> An enum does not have fields. What do you actually mean?
Yeah, as per your follow-on comment, I think a simple "Add RS6000_BTI_INTPTI."
should suffice.
Peter
ee RTL looks like after expand for these
unused hidden parameters? Is there a rtx we can return that isn't a NULL_RTX
which triggers the assumption of a parameter save area, but isn't a reg rtx
which might lead to some rtl being generated? Would a (const_int 0) or
something else work?
> + /* Actual parameter length ignoring hidden parameter.
> + This is done to C++ wrapper calling fortran procedures
> + which has hidden parameter that are not used. */
I think a simpler comment will suffice:
/* Actual parameter count ignoring unused hidden parameters. */
Peter
area is required
so what we return is unimportant other than to know it's not NULL_RTX.
I'm more concerned about the use of the target hook targetm.calls.function_arg
used in the generic parts of the compiler. What will that code do differently
now that we return a reg rtx rather than NULL_RTX? Might that code use
the reg rtx to emit something? I'd feel better if you could verify what
happens in that code when we return a reg rtx for that 9th hidden param which
isn't really being passed in a register.
Peter
this both in environments both with and without sh present, and
observed no issues.
Signed-off-by: Peter Damianov
---
gcc/lto-wrapper.cc | 35 ---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/gcc/lto-wrapper.cc b/gcc/lto-wrapper.cc
index 5186d04
;t use TLS in their IFUNC resolvers could still profile them?
Peter
On 4/3/24 10:45 AM, Andrew Pinski wrote:
> On Wed, Apr 3, 2024 at 8:32 AM Peter Bergner wrote:
> I think you misunderstood the patch/situtation. Most ifunc resolves
> don't use TLS at all; what is happening here is that the profiler
> (-fprofile-generate) is adding TLS usage to t
powerpc64le-linux with no regressions.
Ok for trunk?
Eventually we'll want to backport this along with the follow-on patch that
actually fixes PR101865.
Peter
gcc/
PR target/101865
* config/rs6000/rs6000.h (TARGET_DIRECT_MOVE): Define.
* config/rs6000/rs60
tecture) added,
so there's no other OPTION_MASK_*/TARGET_* we can use as a P8 base architecture
test.
I'll note I tried just a bare "Target Mask(POWER8) Var(rs6000_isa_flags)" with
no
option name mentioned at all, but that didn't work, as no OPTION_MASK_POWER8 was
created.
Peter
On 4/8/24 3:55 AM, Kewen.Lin wrote:
> on 2024/4/6 06:28, Peter Bergner wrote:
>> +mno-direct-move
>> +Target Undocumented WarnRemoved
>> +
>> mdirect-move
>> -Target Undocumented Mask(DIRECT_MOVE) Var(rs6000_isa_flags) WarnRemoved
>> +Target Undocume
On 4/8/24 9:37 PM, Kewen.Lin wrote:
> on 2024/4/8 21:21, Peter Bergner wrote:
> I prefer to remove it completely, that is:
>
>> -mdirect-move
>> -Target Undocumented Mask(DIRECT_MOVE) Var(rs6000_isa_flags) WarnRemoved
>
> The reason why you still kept it is to keep a
havior for GCC 14 (before removing in stage1), we want just:
mdirect-move
-Target Undocumented Mask(DIRECT_MOVE) Var(rs6000_isa_flags) WarnRemoved
+Target Undocumented WarnRemoved
which is what I'll commit and push after one last round of testing.
Thanks.
Peter
On 4/9/24 3:19 PM, Peter Bergner wrote:
> Ok, current trunk ignores -mno-direct-move and warns on -mdirect-move, so to
> keep the same behavior for GCC 14 (before removing in stage1), we want just:
>
> mdirect-move
> -Target Undocumented Mask(DIRECT_MOVE) Var(rs6000_isa_fla
so ok for backports after
some burn-in time on trunk?
Peter
2024-04-11 Will Schmidt
Peter Bergner
gcc/
PR target/101865
* config/rs6000/rs6000-builtin.cc (rs6000_builtin_is_supported): Use
TARGET_POWER8.
* config/rs6000/rs6000
omeone commit it for me? This is my
first patch for GCC, so apologies in advance if the commit message is
missing something.
Tested on x86_64-pc-linux-gnu.
The bug is present in gfortran back to 4.9, so should it also be backported?
Cheers,
Peter
PR fortran/105658
gcc/fortran
omponents), but in the general case with
a type with differently sized components, the stride wouldn't be a
multiple of the component's type's size. Is it possible in principle
to have an arbitrary stride?
Cheers,
Peter
>From 907a104facfc7f35f48ebcfa9ef5f8f5430d4d3c Mon Sep 17 00:00:00
-bit modes. Ok for trunk?
FYI, I will open a new bug to track the removing of the superfluous
insns detected in PR112103.
Peter
gcc/testsuite/
PR target/112103
* gcc.target/powerpc/rlwinm-0.c: Adjust expected instruction counts.
diff --git a/gcc/testsuite/gcc.target/powerpc
On 2/20/24 3:29 AM, Kewen.Lin wrote:
> on 2024/2/20 06:35, Peter Bergner wrote:
>> rs6000: Update instruction counts due to combine changes [PR112103]
>>
>> The PR91865 combine fix changed instruction counts slightly for rlwinm-0.c.
>> Adjust expected instruction cou
, correct? Ie, if the
user forces -mno-vsx in RUNTESTFLAGS, then we'll just skip the
test case as UNSUPPORTED rather than trying to compile some
vsx test case with vsx disabled via the options.
Peter
sure vsx support, for now it's
> powerpc_vsx_ok.
> ie: /* { dg-require-effective-target powerpc_vsx_ok } */
Agreed.
>> +/* { dg-options "-O1" } */
I think we should also use a -mcpu=XXX option to ensure VSX is enabled
when compiling these VSX built-in functions. I'm fine using any CPU
(power7 or later) where the ICE exists with an unpatched compiler.
Otherwise, testing will be limited to our server systems that have
VSX enabled by default.
Peter
On 2/26/24 7:55 PM, Kewen.Lin wrote:
> on 2024/2/26 23:07, Peter Bergner wrote:
>> so I think we should use both Jeevitha's predicate change and
>> your operands[1] change.
>
> Since either the original predicate change or operands[1] change
> can fix this issue, I
e splat_input_operand for the
vsx_splat_ expander or was input_operand a conscious decision?
If input_operand was used purposely, then we can just fall back to
the s/op1/operands[1]/ change which we already know fixes the bug.
Peter
On 2/28/24 8:31 AM, Segher Boessenkool wrote:
> On Tue, Feb 27, 2024 at 04:50:02PM -0600, Peter Bergner wrote:
>> So it seems you're not NAKing the use of splat_input_operand, but
>> just that it needs more explanation in the git log entry, correct?
>
> I NAK the patch
oc/md.texi (Modifiers): Mention %S can be used like %x.
>
> gcc/testsuite/
>
> PR target/112886
> * /gcc.target/powerpc/pr112886.c: New test.
This resolves my issue with the first patch, so LGTM.
Peter
In other words, the -mvsx option
doesn't help with anything.
All we need is the new powerpc_vsx_ok check and that will guard against the FAIL
in the case the user forces -mno-vsx. In that case, we'll just get an
UNSUPPORTED
and that is fine.
Peter
On 1/24/24 12:04 AM, Kewen.Lin wrote:
> on 2024/1/24 11:11, Peter Bergner wrote:
>> But not with this. The -mdejagnu-cpu=power10 option already enables -mvsx.
>> If the user explcitly forces -mno-vsx via RUNTESTFLAGS, then let them.
>> The options set in RUNTESTFLAGS come aft
On 12/13/23 2:05 AM, Jakub Jelinek wrote:
> On Wed, Dec 13, 2023 at 08:51:16AM +0100, Richard Biener wrote:
>> On Tue, 12 Dec 2023, Peter Bergner wrote:
>>
>>> On 12/12/23 8:36 PM, Jason Merrill wrote:
>>>> This test is failing for me below C++17, I think y
lize them with two vectors,
then mode1 being a vector mode could be accesible from an OOmode mode2
without copying, meaning we could access it directly from the registers
holding mode2.
Segher, your input to the above an the subreg portion of the patch in general?
Peter
d add it to the things to check for
non-ELFv2 compiles before the next release and possible disable it then if we
know/aren't sure whether it legal?
So I guessing I'm wondering, should Jeevitha push the above approved patch as
is, or should we modify it so r2 is only available for RA on ELFv2 and pcrel?
Peter
On 12/14/23 9:57 PM, Peter Bergner wrote:
> On 7/16/23 10:40 PM, P Jeevitha via Gcc-patches wrote:
>> + /* For non PC-relative code, GPR2 is unavailable for register allocation.
>> */
>> + if (FIXED_R2 && !rs6000_pcrel_p ())
>> +fixed_regs[2] = 1;
[sn
oid
test (__vector_pair *ptr)
{
register __vector_pair p asm ("vs10");
register __vector_pair q asm ("vs42");
register __vector_pair r asm ("vs44");
q = ptr[1];
r = ptr[2];
__asm__ ("xvadddp %x0,%x1,%x2\n\txvadddp %S0,%S1,%S2"
: "=wa" (p)
: "wa" (q), "wa" (r));
ptr[2] = p;
}
/* { dg-final { scan-assembler-times {\mxvadddp 10,42,44\M} 1 } } */
/* { dg-final { scan-assembler-times {\mxvadddp 11,43,45\M} 1 } } */
...
Peter
lla comments, -O3 -mcpu=power10 is not
required to hit the ICE. A simple -O2 on ppc64le is enough to hit the ICE.
Ok for trunk?
Peter
testsuite: Add testcase for already fixed PR [PR112822]
gcc/testsuite/
PR tree-optimization/112822
* g++.dg/pr112822.C: New test.
diff --git a/gcc
On 12/12/23 12:45 PM, Peter Bergner wrote:
> +/* PR target/112822 */
Oops, this should be:
/* PR tree-optimization/112822 */
It's fixed on my end.
Peter
On 12/12/23 1:26 PM, Richard Biener wrote:
>> Am 12.12.2023 um 19:51 schrieb Peter Bergner :
>>
>> On 12/12/23 12:45 PM, Peter Bergner wrote:
>>> +/* PR target/112822 */
>>
>> Oops, this should be:
>>
>> /* PR tree-optimization/112822 */
>>
s? ...or do we need to do both?
Peter
There's no reason to create this file if none of the serial configure
options are passed.
ChangeLog:
* configure: Regenerate.
* configure.ac: Only create serdep.tmp if needed
Signed-off-by: Peter Foley
---
configure| 2 ++
configure.ac | 2 ++
2 files changed, 4 inser
There's no reason to create this file if none of the serial configure
options are passed.
v2: Use test instead of [ to avoid running afoul of autoconf quoting.
ChangeLog:
* configure: Regenerate.
* configure.ac: Only create serdep.tmp if needed
Signed-off-by: Peter
Use the GNATMAKE variables consistently.
Avoids failures when bootstraping with a custom GNATMAKE value.
gcc/ada/ChangeLog:
* Make-generated.in: Use GNATMAKE.
* gcc-interface/Makefile.in: Ditto.
Signed-off-by: Peter Foley
---
gcc/ada/Make-generated.in | 6 +++---
gcc
yet pushed?
That was the use GPR2 for register allocation, correct? Note, you'll need
to update the patch to replace the rs6000_pcrel_p() usage with just
TARGET_PCREL, since this patch removes rs6000_pcrel_p().
If testing is clean and everyone is OK with the patch, I'll officially
submit it
er, it doesn't remove it from OTHER_POWER10_MASKS,
since that is used to set ISA_3_1_MASKS_SERVER and I didn't want
to change how rs6000_machine_from_flags() behaves, so instead, I
just explicitly mask it off when defining the power10 default flags.
Peter
invalid for this target", "-mpcrel");
I'll make that change, redo the bootstrap and regtesting and then
officially submit the patch. Thanks!
Peter
that
can affect the performance of all architectures needs some performance
testing to ensure we don't have unintended performance degradations.
I'll have someone on my team kick off some builds once I have a handle
on the testsuite FAILs.
Peter
The compile farm just went through with a domain name change, so the Power7 BE
gcc110.fsffrance.org system is now reachable via cfarm110.cfarm.net.
You are correct on the address for requesting a cfarm account.
That said, I posted results using your V3 patches for both LE and BE Power
in my other reply.
Peter
release branches after some burn-in on trunk?
Peter
gcc/
PR target/111045
* config/rs6000/linux64.h (PCREL_SUPPORTED_BY_OS): Only test the ABI.
* config/rs6000/rs6000-cpus.def (RS6000_CPU): Remove OPTION_MASK_PCREL
from power10.
* config/rs6000
100% /home
Segher, can you please send out an admin note for people to clean up
unneeded space on cfarm110? Thanks.
Peter
patch does improve code generation
for some unit tests and our AI libraries team has confirmed that performance
of their tests improved when using this patch.
This passed bootstrap and regtesting with no regressions on powerpc64le-linux
and powerpc64-linux. Ok for trunk?
Peter
gcc/
PR t
function.
gcc/ChangeLog:
PR diagnostics/102061
* langhooks.cc (lhd_decl_printable_name): Follow DECL_ABSTRACT_ORIGIN
links to the source
Signed-off-by: Peter Damianov
---
I would add a testcase but I'm not familiar with that process, and would need
some help. I also
gcc/ChangeLog:
PR diagnostics/102061
* langhooks.cc (lhd_decl_printable_name): Follow DECL_ORIGIN
link
Signed-off-by: Peter Damianov
---
v2: use DECL_ORIGIN instead of DECL_ABSTRACT_ORIGIN and remove loop
gcc/langhooks.cc | 1 +
1 file changed, 1 insertion(+)
diff --git
ollow-on patch will not only remove
the TARGET_* and the 2nd/3rd rs6000_rop_protect usage, but will also remove
the test and asserts of ELFv2...because we've already verified valid option
usage earlier in the normal options handling code.
Therefore, I'd like to keep this patch as simple as possible and limited to
the TARGET_POWER10 -> TARGET_POWER8 change and the cleanup of those tests is
coming in the next patch...which has already been tested.
Peter
Ping * 2. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
Segher, this resolves the issues you mentioned in your review.
Peter
On 6/18/24 5:59 PM, Peter Bergner wrote:
> Updated patch. This passed bootstrap and regtesting on powerpc64le-linux
> with no regr
Ping * 3. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
Segher, this resolves the issues you mentioned in your review.
Peter
On 6/18/24 5:59 PM, Peter Bergner wrote:
> Updated patch. This passed bootstrap and regtesting on powerpc64le-linux
> with no regr
case for unsupported ABIs, since I'll be
working on adding ROP support for powerpc-linux and powerpc64-linux next.
Peter
2024-06-26 Peter Bergner
gcc/
PR target/114759
* config/rs6000/rs6000.cc (rs6000_override_options_after_change):
Disallow CPUs and ABIs t
000_rop_protect to align with the handlings
> on other options?
I'm not sure I know what you mean? Why would we unset rs6000_rop_protect?
Either we've concluded the current target options allow ROP code gen or not
and for the cases where we don't/can't allow ROP, we want to give the user
and error to match clang's behavior and how we already handle unsupported
ABIs. So what is it you're trying to describe here?
Peter
ny Altivec instructions for those targets where
the ".machine cpu" is insufficient to enable Altivec. For example,
-mcpu=G5 emits a ".machine power4".
This passed bootstrap and regtesting on powrpc64-linux (running the testsuite
in both 32-bit and 64-bit modes) with no regressi
ly disable ROP as
there was in your case above. Therefore, I think the code as I showed it
is correct as is...other than the code snipit location, which I have moved
and am testing now.
Peter
Hi Kewen,
Here's the updated patch per your review comments, minus your suggestion
to disable the ROP mask which I mentioned isn't needed in my other reply.
This passed bootstrap and regtesting with no regressions on powerpc64le-linux.
Ok for trunk?
Peter
Changes from v1:
* Moved
On 7/15/24 5:43 PM, Carl Love wrote:
> -/* { dg-do run } */
> +/* { dg-do run { target { lp64 } && { int128 } } } */
Why isn't this just:
/* { dg-do run { target int128 } } */
??? The int128 test should disable this on 32-bit systems just fine.
Peter
On 7/15/24 9:19 PM, Kewen.Lin wrote:
> on 2024/7/16 04:30, Peter Bergner wrote:
>> On 7/11/24 1:24 AM, Kewen.Lin wrote:
>>> Sorry for the confusion, I meant for most target options when we emit some
>>> error
>>> message meanwhile we also unset it,
d?
...
use __int128 types that are not supported on all platforms. Update the
tests to check int128 effective target to avoid unsupported type errors
on unsupported platforms.
Peter
128, you've added
FLOAT128_IEEE_P (mode)).
> - "TARGET_HARD_FLOAT && TARGET_LONG_DOUBLE_128"
> + "TARGET_HARD_FLOAT
> + && (TARGET_LONG_DOUBLE_128 || FLOAT128_IEEE_P (mode))"
Peter
On 7/18/24 12:19 AM, Kewen.Lin wrote:
> I guess you meant "Remove" is expected to remove some code explicitly and
> can be misleading here, if so how about "Don't check TARGET_LONG_DOUBLE_128
> for FLOAT128_IEEE_P modes"?
Yeah, I think that is more clear. Thanks!
Peter
gt;> Ok for trunk and the release branches after some trunk burn-in time?
>
> OK for all with/without the below minor nit tweaked.
Great, thanks!
Peter
. Target selection might not work
> correctly currently on some other systems, but this is not a run test!
Agreed. Also, if the clones stuff really doesn't work for those
targets even in a compile test, then rather than diabling this way,
I think I'd like to see a target-supports clones_ok test or similar.
Peter
On 7/18/24 9:14 AM, Peter Bergner wrote:
> On 7/18/24 4:14 AM, Kewen.Lin wrote:
>>> +/* { dg-final { scan-assembler {\.\mmachine power4\M} } } */
>>> +/* { dg-final { scan-assembler {\.\mmachine altivec\M} } } */
>>
>> Nit: Both \m looks useless and can be rem
I'm not sure how my testing of the pr114759-3.c test case didn't see
the excess errors on BE, as I did test there. Anyway, the following
obvious patches fixes the problem Bill saw. Tested on LE and 32-bit
and 64-bit BE.
I'll push this tomorrow if there are no objections.
Peter
is ("power11") work efficiently, GLIBC stores
an integer representing each cpu AT_PLATFORM string in the TCB.
It is therefore GLIBC which "owns" the integer versions of the
platform values and yes, 16 is the correct value for Power11 and
that value exists in upstream GLIBC.
Peter
You are missing a ChangeLog entry for the target-supports.exp change plus
there is no mention of why it's needed in the git log entry.
Otherwise, the rest LGTM.
Peter
emit_insn (gen_xststdcp (operands[0], operands[1], GEN_INT (0x30)));
> + DONE;
> +})
Is there a reason not to use the vsx_register_operand predicate for op1
which matches the predicate for the operand of the xststdcp pattern
we're passing op1 to?
Ditto for the other optab patches you've submitted.
Peter
lem in the first place.
This behavior is never helpful or desired for gcc.
Signed-off-by: Peter Damianov
---
.gitattributes | 3 +++
1 file changed, 3 insertions(+)
diff --git a/.gitattributes b/.gitattributes
index e75bfc595bf..1e116987c98 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -8
libcpp/ChangeLog:
* lex.cc (do_peek_prev): Correct typo in argument to __builtin_expect()
Signed-off-by: Peter Damianov
---
libcpp/lex.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libcpp/lex.cc b/libcpp/lex.cc
index c9e44e6..de752bdc9c8 100644
--- a/libcpp
return
false on mingw hosts.
* diagnostic-color.cc (auto_enable_urls): Return true if console
supports ansi escape sequences.
Signed-off-by: Peter Damianov
---
v3: Fix minor comment formatting nit.
gcc/diagnostic-color.cc | 19 +++
1 file changed, 15 inser
Signed-off-by: Peter Damianov
---
Pinging these patches. The wine ordeal is a problem, but disabling the
diagnostics colors with the environment variable should be resolving that.
I don't want to intentionally make testing harder, but until wine fixes:
https://bugs.winehq.org/show_bug.cgi?id=
s
if
the console has ENABLE_VIRTUAL_TERMINAL_PROCESSING.
Signed-off-by: Peter Damianov
---
v3: fix minor comment formatting nit.
gcc/pretty-print.cc | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/pretty-print.cc b/gcc/pretty-print.cc
index eb59bf424b7..505230
so the internal compiler details
aren't exposed.
gcc/ChangeLog:
PR diagnostics/102061
* langhooks.cc (lhd_print_error_function): Follow DECL_ORIGIN
links.
* gcc.dg/pr102061.c: New testcase.
Signed-off-by: Peter Damianov
---
v3: also follow DECL_ORIGIN when emitt
sentence above. Thanks for fixing this!
Peter
oduce new
> stuff like it!
I'm fine with the TARGET_P10_* macro, since it's more readable than saying
TARGET_POWER10 && TARGET_ALTIVEC && TARGET_VSX, especially when we use the
negated version.
What we really wanted to get rid of, was having a separate OPTION_MASK_Pxxx_*
flag for things like this which we used to have. I agree that was bad.
This isn't that though. This is just a convenience macro to make the code
more (IMHO) readable.
Peter
itectures, she cannot possibly test everything.
That's why we have stage1 and our patch revert process.
Peter
so the internal compiler details
aren't exposed.
gcc/ChangeLog:
PR diagnostics/102061
* langhooks.cc (lhd_print_error_function): Follow DECL_ORIGIN
links.
* gcc.dg/pr102061.c: New testcase.
Signed-off-by: Peter Damianov
---
v4: Address formatting nits, add comme
1 - 100 of 1910 matches
Mail list logo
