Re: About GSOC.
Hello.
I can't figure out from the documentation how to add test cases in the
testsuite and inspect the results. How can I do that? Although, Taking
the mentioned conditions under consideration, I have made another
patch, attached.
Thanks,
-Tejas
On Wed, 8 May 2019 at 09:01, Tejas Joshi wrote:
>
> I should have taken all the test cases into consideration. Fool of me. I will
> try to make changes taking all the test cases into consideration along with
> the testsuite.
> Thanks.
>
> On Wed, 8 May 2019 at 02:31, Joseph Myers wrote:
>>
>> On Wed, 8 May 2019, Tejas Joshi wrote:
>>
>> > Hello.
>> > As per my understanding, 3.5 would be represented in GCC as follows :
>> > r->uexp = 2
>> > and
>> > r->sig[2] = 11100 in binary 64 bit. (first 2 bits being 3 and
>> > following 10000 being 0.5, which later only happens for halfway cases)
>> > So, if we clear out the significand part and the immediate bit to the right
>> > which represent 0.5, the entire significand would become 0 due to bit-wise
>> > ANDing.
>> >
>> > > + tempsig[w] &= (((unsigned long)1 << ((n % HOST_BITS_PER_LONG) - 1)) -
>> > > 1);
>> > >
>> >
>> > That is what the following line intend to do. The clearing part would
>> > change the significand, that's why significand was copied to a temporary
>>
>> That much is fine. My issues are two other things:
>>
>> * The function would wrongly return true for 3, not just for 3.5, because
>> it never checks the bit representing 0.5. (If you don't care what it
>> returns for 3, see my previous point about every function needing a
>> comment defining its semantics. Without such a comment, I have to guess,
>> and my guess here is that the function should return true for 3.5 but
>> false for 3 and for 3.5000...0001.)
>>
>> * The function would wrongly return true for 3.5000...0001, if there are
>> enough 0s that all those low bits in sig[2] are 0, but some low bits in
>> sig[1] or sig[0] are not 0.
>>
>> And also:
>>
>> * You should never need to modify parts of (a copy of) the significand in
>> place. Compare low parts of the significand (masked as needed) with 0.
>> If not 0, just return false. Likewise for comparing the 0.5 bit with 1.
>> It's not that copying and modifying in place results in incorrect logic,
>> it's simply excessively convoluted compared to things like:
>>
>> if ((something & mask) != 0)
>> return false
>>
>> (the function is probably twice as long as necessary because of that
>> copying).
>>
>> > array for checking. This logic is inspired by the clear_significand_below
>> > function. Or isn't this the way it was meant to be implemented? Also, why
>> > unsigned long sig[SIGSZ] has to be an array?
>>
>> What would it be other than an array? It can't be a single scalar because
>> floating-point significands may be longer than any supported integer type
>> on the host (remember the IEEE binary128 case). And if you made it a
>> sequence of individually named fields, a load of loops would need to be
>> manually unrolled, which would be much more error prone and hard to read.
>>
>> --
>> Joseph S. Myers
>> jos...@codesourcery.com
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..0b2d6bf82f9 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2067,6 +2067,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
CASE_MATHFN (REMQUO)
CASE_MATHFN_FLOATN (RINT)
CASE_MATHFN_FLOATN (ROUND)
+CASE_MATHFN (ROUNDEVEN)
CASE_MATHFN (SCALB)
CASE_MATHFN (SCALBLN)
CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..e1d593a8765 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -542,6 +542,9 @@ DEF_C99_BUILTIN(BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
#define RINT_TYPE(F) BT_FN_##F##_##F
DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
#undef RINT_TYPE
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_C99_BUILTIN(BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_C99_BUILTIN(BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_C99_BUILTIN(BUILT_IN_ROUNDL, "roundl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 06a420601c0..7eafd91e9a2 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -792,6 +792,14 @@ fold_const_call_ss (real_value *result, combined_fn fn,
}
return false;
+case CFN_BUILT_IN_ROUNDEVEN:
+ if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
+ {
+real_roundeven (result, format, arg);
+return true;
+ }
+ return false;
+
Dejagnu output size limit and flaky test ( c-c++-common/builtins.c -Wc++-compat )
Hello,
During testing we've noticed the "test for excess errors" check on the
"c-c++-common/builtins.c -Wc++-compat" sometimes passes and sometimes
doesn't.
The cause seems to be a restriction in dejagnu where it stops reading
after a given read if its output buffer is greater than 512000 bytes.
(see the below snippet copied from the "local_exec" procedure in
$DEJAGNU_INSTALL/remote.exp)
# Wait for either $timeout seconds to elapse, or for the program to
# exit.
expect {
-i $spawn_id -timeout $timeout -re ".+" {
append output $expect_out(buffer)
if { [string length $output] < 512000 } {
exp_continue -continue_timer
}
}
timeout {
warning "program timed out."
}
eof {
set got_eof 1
}
}
If the last read before the output is truncated happened to get part of
a line so that the "warning" isn't there, and hence so the {
dg-prune-output "warning" } directive doesn't apply, then the testcase
fails.
This can only happen when the full pathname of the test file is 73
characters long (or more), since each warning line includes the full
pathname the length has a huge affect.
I'm mainly mentioning it to see if anyone else was having this problem,
so I can tell how important it is to try and handle this more thoroughly.
Regards,
MM
Re: GSoC'19 Thanks for acceptance
Hello Ray, On Wed, May 08 2019, 김규래 wrote: > Hi everyone, > Thanks for accepting my proposal Implementing OpenMP Work Stealing > Scheduling for GSoC 2019. I'll do my best to accomplish the proposed > goals. Ii is a pleasure, we are looking forward to your contributions. > Right now the semester hasn't ended so progress would be limited. > However, I'll start working on the project as soon as the semester > ends. We are in the community bonding period right now so that should not be any problem. If your availability will be limited after May 28th, please talk to Jakub so that he knows about it and you agree how to handle/compensate for it. > During the time being, any basic guidance related to contributing to > GCC and the project would be much appreciated. Please request a copyright assignment as described in https://gcc.gnu.org/ml/gcc/2019-05/msg00067.html Thank you, Martin
GCC GSoC 2019 projects: announcement and a mandatory first step
[Sorry for a re-post, I forgot to write a subject and as a consequence the email did not make it through to the mailing list] Hello, I am pleased to announce that six students will be working on GCC or GCC-related Google Summer of Code (GSoC) projects: - JeanHeyd Meneide will be working on improving libstdc++, focusing on vector and related algorithms and data structures (see https://gcc.gnu.org/ml/libstdc++/2019-02/msg4.html and the ensuing thread for more details), - Tejas Joshi will be working on adding new builtins for math functions introduced in IEC 18661 and thus exposing them to optimizations, - Akshat Garg will be making sure that gcc/g++ do not automatically promote memory_order_consume to memory_order_acquire, - Giuliano Belinassi will be parallelizing GCC with Threads, - Khurai Kim will be working on implementing OpenMP Work Stealing Scheduling scheduling options, and - Shubham Narlawar will be working on enabling generation of GCC extensions by the CSmith fuzzer. I'd like to congratulate all of them for putting together very solid proposals and wish them best of luck with their projects. The GSoC program has now entered its "community bonding period" which lasts until May 27th. One of the most important things all accepted students who are expected to contribute directly to GCC code base should do in this time is to request a copyright assignment[1] as soon as you can (i.e. everybody but Shubham who is however also invited to do so). Please email the following information to ass...@gnu.org, and they will send you the assignment form for your past and future changes. Use your full legal name (in ASCII characters) as the subject line of the message. -- REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES [What is the name of the program or package you're contributing to?] [Did you copy any files or text written by someone else in these changes? Even if that material is free software, we need to know about it.] [Do you have an employer who might have a basis to claim to own your changes? Do you attend a school which might make such a claim?] [For the copyright registration, what country are you a citizen of?] [What year were you born?] [Please write your email address here.] [Please write your postal address here.] [Which files have you changed so far, and which new files have you written so far?] -- Please report back to me when you have completed the process or if you encounter any issues and/or unreasonably long delays. Because GCC targets many computer platforms, you may also find it very useful to get an account on the compile farm[2] so that you can test your code on a variety of architectures. Of course, you should get in touch with your mentors unless you have already done so. Last but not least feel free to raise any question you might have on an appropriate mailing list[3] or say hi to us on the gcc development IRC channel [4]. If you have any concerns or questions regarding the organizational part of GSoC 2019, feel free to contact me throughout the duration of the program. Once more, congratulations and good luck! Martin [1] https://gcc.gnu.org/contribute.html#legal [2] https://gcc.gnu.org/wiki/CompileFarm [3] https://gcc.gnu.org/lists.html [4] https://gcc.gnu.org/wiki/GCConIRC
Re: About GSOC.
Hello.
I have added a test case in the testsuite referring to an existing one
as "builtin-rounding-1.c" in the /testsuite/gcc.dg/torture directory.
As follows :
/* { dg-do link } */
extern int link_error (int);
#define TEST(FN, VALUE, RESULT) \
if (__builtin_##FN (VALUE) != RESULT) link_error (__LINE__);
int
main (void)
{
TEST(roundeven, 0, 0);
TEST(roundeven, 0.5, 0);
TEST(roundeven, -0.5, 0);
TEST(roundeven, 6, 6);
TEST(roundeven, -8, -8);
TEST(roundeven, 2.5, 2);
TEST(roundeven, 3.5, 4);
TEST(roundeven, -1.5, -2);
TEST(roundeven, 3.499, 3);
TEST(roundeven, 3.501, 4);
return 0;
}
After checking for test case in the build directory using :
$ make check-gcc RUNTESTFLAGS="dg-torture.exp=builtin-round-roundeven.c"
test does not FAIL. Though, it FAILs for intentionally giving wrong RESULT.
Ex : TEST(roundeven, 3.501, 3);
Should fail I believe and thus giving output as:
FAIL: gcc.dg/torture/builtin-round-roundeven.c -O0 (test for excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c -O1 (test for excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c -O2 (test for excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c -O3 -g (test for
excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c -Os (test for excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none (test for excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects (test for excess errors)
Is this the way test cases should be added and checked?
Thanks.
On Wed, 8 May 2019 at 13:05, Tejas Joshi wrote:
>
> Hello.
> I can't figure out from the documentation how to add test cases in the
> testsuite and inspect the results. How can I do that? Although, Taking
> the mentioned conditions under consideration, I have made another
> patch, attached.
>
> Thanks,
> -Tejas
>
>
> On Wed, 8 May 2019 at 09:01, Tejas Joshi wrote:
> >
> > I should have taken all the test cases into consideration. Fool of me. I
> > will try to make changes taking all the test cases into consideration along
> > with the testsuite.
> > Thanks.
> >
> > On Wed, 8 May 2019 at 02:31, Joseph Myers wrote:
> >>
> >> On Wed, 8 May 2019, Tejas Joshi wrote:
> >>
> >> > Hello.
> >> > As per my understanding, 3.5 would be represented in GCC as follows :
> >> > r->uexp = 2
> >> > and
> >> > r->sig[2] = 11100 in binary 64 bit. (first 2 bits being 3 and
> >> > following 10000 being 0.5, which later only happens for halfway
> >> > cases)
> >> > So, if we clear out the significand part and the immediate bit to the
> >> > right
> >> > which represent 0.5, the entire significand would become 0 due to
> >> > bit-wise
> >> > ANDing.
> >> >
> >> > > + tempsig[w] &= (((unsigned long)1 << ((n % HOST_BITS_PER_LONG) - 1))
> >> > > -
> >> > > 1);
> >> > >
> >> >
> >> > That is what the following line intend to do. The clearing part would
> >> > change the significand, that's why significand was copied to a temporary
> >>
> >> That much is fine. My issues are two other things:
> >>
> >> * The function would wrongly return true for 3, not just for 3.5, because
> >> it never checks the bit representing 0.5. (If you don't care what it
> >> returns for 3, see my previous point about every function needing a
> >> comment defining its semantics. Without such a comment, I have to guess,
> >> and my guess here is that the function should return true for 3.5 but
> >> false for 3 and for 3.5000...0001.)
> >>
> >> * The function would wrongly return true for 3.5000...0001, if there are
> >> enough 0s that all those low bits in sig[2] are 0, but some low bits in
> >> sig[1] or sig[0] are not 0.
> >>
> >> And also:
> >>
> >> * You should never need to modify parts of (a copy of) the significand in
> >> place. Compare low parts of the significand (masked as needed) with 0.
> >> If not 0, just return false. Likewise for comparing the 0.5 bit with 1.
> >> It's not that copying and modifying in place results in incorrect logic,
> >> it's simply excessively convoluted compared to things like:
> >>
> >> if ((something & mask) != 0)
> >> return false
> >>
> >> (the function is probably twice as long as necessary because of that
> >> copying).
> >>
> >> > array for checking. This logic is inspired by the clear_significand_below
> >> > function. Or isn't this the way it was meant to be implemented? Also, why
> >> > unsigned long sig[SIGSZ] has to be an array?
> >>
> >> What would it be other than an array? It can't be a single scalar because
> >> floating-point significands may be longer than any supported integer type
> >> on the host (remember the IEEE binary128 case). And if you made it a
> >> sequence of individually named fields, a load of loops would need to be
> >> manually unrolled, which would be much more error prone and hard to read.
> >>
> >> --
> >> Joseph S. Myers
> >> jos...@codesou
Re: Dejagnu output size limit and flaky test ( c-c++-common/builtins.c -Wc++-compat )
On 5/8/19 3:34 AM, Matthew Malcomson wrote: The cause seems to be a restriction in dejagnu where it stops reading after a given read if its output buffer is greater than 512000 bytes. This dejagnu restriction was removed in 2016. Try using a newer dejagnu release. 2016-03-27 Ben Elliston * lib/remote.exp (standard_wait): Append any trailing characters to $output that may be still in $expect_out(buffer) when eof is matched. Remove arbitrary limitation in the ".+" matching case, similar to the change to local_exec on 2016-02-17. Jim
Threads Support Documentation
Greetings All, I was unable to find in the official gcc internals manual but what layers have threaded support in terms of functions to use them. I'm not asking about implemented but at least a start to being implemented. Thanks, Nick
