Re: Problem while executing a custom testcase inside testsuite
On Jun 22 2019, Akshat Garg wrote: > I believe I should be getting a warning like: > warning: initialization from incompatible pointer type > [-Wincompatible-pointer-types] > but in the gcc.log file, I found this: > error: initialization of '_Atomic struct rcutest *' from incompatible > pointer type 'struct rcutest *' [-Wincompatible-pointer-types] > > Can anyone please explain to me why this is considered as an error, not a > warning? Because it's a pedwarn, and you are passing -pedantic-errors. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Problem while executing a custom testcase inside testsuite
On Sat, Jun 22, 2019 at 1:10 PM Andreas Schwab wrote: > On Jun 22 2019, Akshat Garg wrote: > > > I believe I should be getting a warning like: > > warning: initialization from incompatible pointer type > > [-Wincompatible-pointer-types] > > but in the gcc.log file, I found this: > > error: initialization of '_Atomic struct rcutest *' from incompatible > > pointer type 'struct rcutest *' [-Wincompatible-pointer-types] > > > > Can anyone please explain to me why this is considered as an error, not a > > warning? > > Because it's a pedwarn, and you are passing -pedantic-errors. > So, can you tell me what should I pass for pedwarn. I tried with -pedwarn-errors, but it didn't work. > > Andreas. > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different." >
Re: Avoid stack references in inline assembly
On 18/06/2019 at 00:05, Jeff Law wrote: If you're going to insist on doing this with an ASM you're likely going to need to only use registers and constants for constraints since otherwise you run the risk of getting a stack address. Thanks for all your clarifications and suggestions. To optimally solve this issue, it might be useful to implement in GCC a pseudo "push" assembler opcode. It would be usable in the assembler template, and interpreted by GCC. So GCC could understand it and emit the real push instruction for the target processor. But as a side effect, it could also remember the number of bytes already pushed on the stack. So next references to stack variables could be adjusted with the proper offset. This way GCC would produce valid and optimal code. -- Vincent Rivière
if (x > ((2^x)-1)) optimization
I was starting at the assembly from some of the Python source, and
came across this (simplified) comparison:
if (x > 2305843009213693951) {...}
This is the same as:
if (x > 0x1fff) {...}
This is equivalent to:
if (x >> 61) {...}
More generally, we can rewrite
if ( x > ((1 << z) -1)) { ...}
as
if ( x >> z ) { ... }
This does not appear to currently be a gcc optimization. What is
involved in adding it?
Jason
Re: if (x > ((2^x)-1)) optimization
On 6/22/19 7:55 AM, Jason Duerstock wrote:
> I was starting at the assembly from some of the Python source, and
> came across this (simplified) comparison:
>
> if (x > 2305843009213693951) {...}
>
> This is the same as:
>
> if (x > 0x1fff) {...}
>
> This is equivalent to:
>
> if (x >> 61) {...}
>
> More generally, we can rewrite
>
> if ( x > ((1 << z) -1)) { ...}
>
> as
>
> if ( x >> z ) { ... }
>
> This does not appear to currently be a gcc optimization. What is
> involved in adding it?
So first, when discussing this kind of stuff it's usually best to
actually have a compilable example. Fragments usually are insufficient.
Adding it to the RTL optimizers would be painful because of the need for
type information (this is only valid when X is unsigned, right?)
Adding it to the gimple optimizers is painful because the optimized form
is actually de-optimized on some targets (say embedded targets with weak
shifters) and querying the target costs/capabilities is generally
frowned upon in the gimple optimizers.
I think the combination of those two factors would tend to argue for an
implementation in the gimple->rtl expanders. You've still got type
information and you can query the backend for costing and capabilities.
cfgexpand::expand_gimple_cond might be a good place to start.
Another place to poke around would be expr:expand_expr_real_2, case
COND_EXPR.
Jeff
Re: Expanding roundeven (Was: Re: About GSOC.)
Hello.
I have already sent a patch for expanding roundeven for i386 with
relevant doubts. I also was regression testing with
make -k check
after successful bootstrap build with reverting my patches. Turns out
do-check fails without any patches applied, Is it ok to do anyways for
applied patch? Also, /contrib/compare_tests returns with "no common
files to compare" but I see all as the same files (actually, I am
moving *.sum files in manual directory and comparing with build of
applied patch.)? Is it due to failed make check?
Thanks,
-Tejas
On Wed, 19 Jun 2019 at 19:07, Tejas Joshi wrote:
>
> Hello.
> I have made following changes to inspect inlining of roundeven with
> the following test code:
> double
> plusone (double d)
> {
> return __builtin_roundeven (d) + 1;
> }
>
> Running the program using -O2 foo.c gave internal compiler error which
> I believe is because gcc_unreachable() at:
>
> if (TARGET_SSE4_1)
> emit_insn (gen_sse4_1_round2
>(operands[0], operands[1], GEN_INT (ROUND_
>| ROUND_NO_EXC)));
> I think the following condition matches the criterion? :
> > I think the code will be much clearer if it explicitly says
> > ROUND_ROUNDEVEN | ROUND_NO_EXC,
>
> else if (TARGET_64BIT || (mode != DFmode))
> {
> if (ROUND_ == ROUND_FLOOR)
> ix86_expand_floorceil (operands[0], operands[1], true);
> else if (ROUND_ == ROUND_CEIL)
> ix86_expand_floorceil (operands[0], operands[1], false);
> else if (ROUND_ == ROUND_TRUNC)
> ix86_expand_trunc (operands[0], operands[1]);
> else
> gcc_unreachable ();
> }
> in:
> (define_expand "2"
> But with -mavx, generated the vroundsd insn. Does it mean ROUNDEVEN
> should have a condition in the else if, but comments above
> ix86_expand* functions in i386-expand.c says that those are for SSE2
> sequences?
>
> Thanks,
> --Tejas
>
>
> On Mon, 17 Jun 2019 at 22:45, Joseph Myers wrote:
> >
> > On Mon, 17 Jun 2019, Tejas Joshi wrote:
> >
> > > > existing ROUND_NO_EXC definition in GCC. A new definition will need
> > > > adding alongside ROUND_FLOOR, ROUND_CEIL and ROUND_TRUNC to correspond
> > > > to
> > > > rounding to nearest with ties to even, evaluating to 0.)
> > >
> > > So (ROUND_ROUNDEVEN 0x0) be declared for rounding towards nearest
> > > even for rounding mode argument? But reference says that RC field
> > > should end up as 00B for rounding ties to even? I am also much
> >
> > I think the code will be much clearer if it explicitly says
> > ROUND_ROUNDEVEN | ROUND_NO_EXC, than if it hardcodes implicit knowledge
> > that 0 is the value used for rounding to nearest with ties to even.
> >
> > --
> > Joseph S. Myers
> > jos...@codesourcery.com
diff --git a/gcc/config/i386/i386-builtin.def b/gcc/config/i386/i386-builtin.def
index e547dda80f1..40536d7929c 100644
--- a/gcc/config/i386/i386-builtin.def
+++ b/gcc/config/i386/i386-builtin.def
@@ -906,6 +906,7 @@ BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_floor
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_ceilpd", IX86_BUILTIN_CEILPD, (enum rtx_code) ROUND_CEIL, (int) V2DF_FTYPE_V2DF_ROUND)
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_truncpd", IX86_BUILTIN_TRUNCPD, (enum rtx_code) ROUND_TRUNC, (int) V2DF_FTYPE_V2DF_ROUND)
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_rintpd", IX86_BUILTIN_RINTPD, (enum rtx_code) ROUND_MXCSR, (int) V2DF_FTYPE_V2DF_ROUND)
+BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_roundevenpd", IX86_BUILTIN_ROUNDEVENPD, (enum rtx_code) ROUND_ROUNDEVEN, (int) V2DF_FTYPE_V2DF_ROUND)
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd_vec_pack_sfix, "__builtin_ia32_floorpd_vec_pack_sfix", IX86_BUILTIN_FLOORPD_VEC_PACK_SFIX, (enum rtx_code) ROUND_FLOOR, (int) V4SI_FTYPE_V2DF_V2DF_ROUND)
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd_vec_pack_sfix, "__builtin_ia32_ceilpd_vec_pack_sfix", IX86_BUILTIN_CEILPD_VEC_PACK_SFIX, (enum rtx_code) ROUND_CEIL, (int) V4SI_FTYPE_V2DF_V2DF_ROUND)
@@ -917,6 +918,7 @@ BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_floor
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_ceilps", IX86_BUILTIN_CEILPS, (enum rtx_code) ROUND_CEIL, (int) V4SF_FTYPE_V4SF_ROUND)
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_truncps", IX86_BUILTIN_TRUNCPS, (enum rtx_code) ROUND_TRUNC, (int) V4SF_FTYPE_V4SF_ROUND)
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_rintps", IX86_BUILTIN_RINTPS, (enum rtx_code) ROUND_MXCSR, (int) V4SF_FTYPE_V4SF_ROUND)
+BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_roundevenps", IX86_BUILTIN_ROUNDEVENPS, (enum rtx_code) ROUND_ROUNDEVEN, (int) V4SF_FTYPE_V4SF_ROUND)
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps_sfix, "__builtin_ia32_flo
Re: Expanding roundeven (Was: Re: About GSOC.)
> Hello.
> I have already sent a patch for expanding roundeven for i386 with
> relevant doubts. I also was regression testing with
> make -k check
> after successful bootstrap build with reverting my patches. Turns out
> do-check fails without any patches applied, Is it ok to do anyways for
> applied patch? Also, /contrib/compare_tests returns with "no common
> files to compare" but I see all as the same files (actually, I am
> moving *.sum files in manual directory and comparing with build of
> applied patch.)? Is it due to failed make check?
The usual procedure is to do make check on clean tree and use
contrib/test_summary to produce summary and then do the same
with patched tree and compare the outputs (by diff)
Honza
>
> Thanks,
> -Tejas
>
>
> On Wed, 19 Jun 2019 at 19:07, Tejas Joshi wrote:
> >
> > Hello.
> > I have made following changes to inspect inlining of roundeven with
> > the following test code:
> > double
> > plusone (double d)
> > {
> > return __builtin_roundeven (d) + 1;
> > }
> >
> > Running the program using -O2 foo.c gave internal compiler error which
> > I believe is because gcc_unreachable() at:
> >
> > if (TARGET_SSE4_1)
> > emit_insn (gen_sse4_1_round2
> >(operands[0], operands[1], GEN_INT (ROUND_
> >| ROUND_NO_EXC)));
> > I think the following condition matches the criterion? :
> > > I think the code will be much clearer if it explicitly says
> > > ROUND_ROUNDEVEN | ROUND_NO_EXC,
> >
> > else if (TARGET_64BIT || (mode != DFmode))
> > {
> > if (ROUND_ == ROUND_FLOOR)
> > ix86_expand_floorceil (operands[0], operands[1], true);
> > else if (ROUND_ == ROUND_CEIL)
> > ix86_expand_floorceil (operands[0], operands[1], false);
> > else if (ROUND_ == ROUND_TRUNC)
> > ix86_expand_trunc (operands[0], operands[1]);
> > else
> > gcc_unreachable ();
> > }
> > in:
> > (define_expand "2"
> > But with -mavx, generated the vroundsd insn. Does it mean ROUNDEVEN
> > should have a condition in the else if, but comments above
> > ix86_expand* functions in i386-expand.c says that those are for SSE2
> > sequences?
> >
> > Thanks,
> > --Tejas
> >
> >
> > On Mon, 17 Jun 2019 at 22:45, Joseph Myers wrote:
> > >
> > > On Mon, 17 Jun 2019, Tejas Joshi wrote:
> > >
> > > > > existing ROUND_NO_EXC definition in GCC. A new definition will need
> > > > > adding alongside ROUND_FLOOR, ROUND_CEIL and ROUND_TRUNC to
> > > > > correspond to
> > > > > rounding to nearest with ties to even, evaluating to 0.)
> > > >
> > > > So (ROUND_ROUNDEVEN 0x0) be declared for rounding towards nearest
> > > > even for rounding mode argument? But reference says that RC field
> > > > should end up as 00B for rounding ties to even? I am also much
> > >
> > > I think the code will be much clearer if it explicitly says
> > > ROUND_ROUNDEVEN | ROUND_NO_EXC, than if it hardcodes implicit knowledge
> > > that 0 is the value used for rounding to nearest with ties to even.
> > >
> > > --
> > > Joseph S. Myers
> > > jos...@codesourcery.com
Re: if (x > ((2^x)-1)) optimization
On Sat, Jun 22, 2019 at 09:46:52AM -0600, Jeff Law wrote:
> On 6/22/19 7:55 AM, Jason Duerstock wrote:
> > More generally, we can rewrite
> >
> > if ( x > ((1 << z) -1)) { ...}
> >
> > as
> >
> > if ( x >> z ) { ... }
> >
> > This does not appear to currently be a gcc optimization. What is
> > involved in adding it?
> So first, when discussing this kind of stuff it's usually best to
> actually have a compilable example. Fragments usually are insufficient.
>
> Adding it to the RTL optimizers would be painful because of the need for
> type information (this is only valid when X is unsigned, right?)
>
> Adding it to the gimple optimizers is painful because the optimized form
> is actually de-optimized on some targets (say embedded targets with weak
> shifters) and querying the target costs/capabilities is generally
> frowned upon in the gimple optimizers.
>
> I think the combination of those two factors would tend to argue for an
> implementation in the gimple->rtl expanders. You've still got type
> information and you can query the backend for costing and capabilities.
>
> cfgexpand::expand_gimple_cond might be a good place to start.
>
> Another place to poke around would be expr:expand_expr_real_2, case
> COND_EXPR.
This is target-specific, so should just be done in the machine description?
Segher
Re: if (x > ((2^x)-1)) optimization
On 6/22/19 12:44 PM, Segher Boessenkool wrote:
> On Sat, Jun 22, 2019 at 09:46:52AM -0600, Jeff Law wrote:
>> On 6/22/19 7:55 AM, Jason Duerstock wrote:
>>> More generally, we can rewrite
>>>
>>> if ( x > ((1 << z) -1)) { ...}
>>>
>>> as
>>>
>>> if ( x >> z ) { ... }
>>>
>>> This does not appear to currently be a gcc optimization. What is
>>> involved in adding it?
>> So first, when discussing this kind of stuff it's usually best to
>> actually have a compilable example. Fragments usually are insufficient.
>>
>> Adding it to the RTL optimizers would be painful because of the need for
>> type information (this is only valid when X is unsigned, right?)
>>
>> Adding it to the gimple optimizers is painful because the optimized form
>> is actually de-optimized on some targets (say embedded targets with weak
>> shifters) and querying the target costs/capabilities is generally
>> frowned upon in the gimple optimizers.
>>
>> I think the combination of those two factors would tend to argue for an
>> implementation in the gimple->rtl expanders. You've still got type
>> information and you can query the backend for costing and capabilities.
>>
>> cfgexpand::expand_gimple_cond might be a good place to start.
>>
>> Another place to poke around would be expr:expand_expr_real_2, case
>> COND_EXPR.
>
> This is target-specific, so should just be done in the machine description?
No because every target would have to reimplement it. Drive it with
target costing and capability querying and we do it just once in the
expanders rather than for every target individually.
jeff
Re: Problem while executing a custom testcase inside testsuite
On Sat, 22 Jun 2019 at 12:25, Akshat Garg wrote: > > On Sat, Jun 22, 2019 at 1:10 PM Andreas Schwab > wrote: > > > On Jun 22 2019, Akshat Garg wrote: > > > > > I believe I should be getting a warning like: > > > warning: initialization from incompatible pointer type > > > [-Wincompatible-pointer-types] > > > but in the gcc.log file, I found this: > > > error: initialization of '_Atomic struct rcutest *' from incompatible > > > pointer type 'struct rcutest *' [-Wincompatible-pointer-types] > > > > > > Can anyone please explain to me why this is considered as an error, not a > > > warning? > > > > Because it's a pedwarn, and you are passing -pedantic-errors. > > > So, can you tell me what should I pass for pedwarn. I tried with > -pedwarn-errors, but it didn't work. -pedantic of course. Try looking in the GCC manual, instead of just guessing at option names.
Re: Problem while executing a custom testcase inside testsuite
On Sun, Jun 23, 2019 at 3:27 AM Jonathan Wakely wrote: > On Sat, 22 Jun 2019 at 12:25, Akshat Garg wrote: > > > > On Sat, Jun 22, 2019 at 1:10 PM Andreas Schwab > > wrote: > > > > > On Jun 22 2019, Akshat Garg wrote: > > > > > > > I believe I should be getting a warning like: > > > > warning: initialization from incompatible pointer type > > > > [-Wincompatible-pointer-types] > > > > but in the gcc.log file, I found this: > > > > error: initialization of '_Atomic struct rcutest *' from incompatible > > > > pointer type 'struct rcutest *' [-Wincompatible-pointer-types] > > > > > > > > Can anyone please explain to me why this is considered as an error, > not a > > > > warning? > > > > > > Because it's a pedwarn, and you are passing -pedantic-errors. > > > > > So, can you tell me what should I pass for pedwarn. I tried with > > -pedwarn-errors, but it didn't work. > > -pedantic of course. Try looking in the GCC manual, instead of just > guessing at option names. > I found it earlier but forget to reply. Thanks anyway for your time.
gcc-9-20190622 is now available
Snapshot gcc-9-20190622 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/9-20190622/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-9-branch revision 272595 You'll find: gcc-9-20190622.tar.xzComplete GCC SHA256=ab795e75c188e38e5389f7f21a0b5b111710f672db8729bf3fd5391a27c1bc63 SHA1=9a94b4703a294555b7a9dcbd4bfaa587bace3649 Diffs from 9-20190615 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
