I have gcc source code, stage1-build and test directories as siblings
and I've been trying to compile test.c in test/ using:
../stage1-build/gcc/cc1 test.c
but getting error as:
In file included from test.c:1:
/usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No
such file or dir
Hello.
I reached asking about GCC GSoC project about adding and
folding functions
like roundeven. I could not apply for the idea this year but
interested in the peoject and
really hoping it would be carry forwarded. Since I've been studying
source code and about the project, I think working on this
About roundeven, there might be need to add case to
expand_builtin_int_roundingfn similar to
ceil, for expansion.
But how is round() expanded since there's no
entry for it in expand_builtin_int_roundingfn ?
Also, is it right to have an added case for roundeven in convert.c
along CASE_FLT_FN (BUILT
codesourcery.com";
target="_blank">jos...@codesourcery.com>
wrote:On Fri, 16 Nov 2018, Tejas Joshi wrote:
> About roundeven, there might be need to add case to
> expand_builtin_int_roundingfn similar to
> ceil, for expansion.
> But how is round() expanded since there&
urther as told in <https://gcc.gnu.org/wiki/DebuggingGCC>
make STAGE1_CXXFLAGS="-g -O0" all-stage1
but instead of -g to use -g3 is suggested for making macros debuggable
and then use GDB.
May I proceed the same?
On Tue, 22 Jan 2019 at 04:33, Joseph Myers wrote:
>
>
, Tejas Joshi wrote:
>
> > differ. (It's the unoptimized, stage1 cc1 that should be run under a
> > debugger. See <https://gcc.gnu.org/wiki/DebuggingGCC> for more details.)
>
> Hello.
> I normally configure GCC by (as you told)
>
> /configure --enable-lang
nal representations?
Thanks.
-Tejas
On Wed, 23 Jan 2019 at 23:06, Joseph Myers wrote:
>
> On Wed, 23 Jan 2019, Tejas Joshi wrote:
>
> > But I really dont know how to inspect a file like real.h
> > (real_value)/real.c?
>
> Use cc1 to build a test program with selected floating
ntf (stderr, "\n i = %ld\n", i);
if (i % 2)
do_add (r, &z, &dconstm1, 0);
else
*r = z;
}
Thanks.
-Tejas
On Sat, 26 Jan 2019 at 03:02, Joseph Myers wrote:
>
> On Sat, 26 Jan 2019, Tejas Joshi wrote:
>
> > function with byte-byte comparison which
dependencies through other files. I tried to
track them down by inspecting real_ceil function, but it also includes
other optimization procedures like folding. How do I know enough
declarations to be made in respective files?
Thanks.
-Tejas
On Mon, 28 Jan 2019 at 22:33, Tejas Joshi wrote:
>
>
20:36, Prathamesh Kulkarni
wrote:
>
> On Mon, 4 Feb 2019 at 20:10, Tejas Joshi wrote:
> >
> > Hello.
> > I have implemented roundeven function in real.c as follows: (and
> > respective changes in real.h)
> It's a better idea to include all changes in patch i
2019 at 22:14, Prathamesh Kulkarni
wrote:
>
> On Mon, 4 Feb 2019 at 21:27, Tejas Joshi wrote:
> >
> > Thanks.
> > > Did you add an entry for roundeven in builtins.def ?
> > Yes, I did.
> >
> > Find here the attached patch.diff for which I did the chang
DEVEN) has no associated built-in functions
Here is the .diff flie.
Thanks,
-Tejas
On Mon, 4 Feb 2019 at 22:55, Tejas Joshi wrote:
>
> Hi.
> Although now, I am unable to build the compiler.
> The build exited returning status as:
>
> DEF_INTERNAL_FLT_FN (ROUNDEVEN) has
also writing the proposal and make draft ready in couple of days
for community review.
Do roundeven have to be added in internals-fn.def to be called internal?
Thanks,
-Tejas
On Sun, 24 Feb 2019 at 17:39, Tejas Joshi wrote:
>
> Hello.
> I had a little pause on roundeven due to semin
Hello.
Here is the proposal draft for the idea. Please review and suggest
changes or modifications.
https://docs.google.com/document/d/15DEXa5NZL6Q_X_zlME3NNJw2zVimFWzi16x7cgIDqL0/edit?usp=sharing
Thanks,
-Tejas
On Tue, 2 Apr 2019 at 01:23, Joseph Myers wrote:
>
> On Sat, 30 Mar 2019,
Hello.
Taking the notes from Joseph under consideration, I have developed a
fairly working patch for roundeven, attached herewith.
I have done bit-wise calculations to check for halfway cases, though
HOST_WIDE_INT is only used to check for even and odd numbers (or is it
necessary to do bit-wise for
er is even or odd bit-wise and
add test cases in the test suite as soon as possible.
Thanks.
Regards,
-Tejas
On Tue, 7 May 2019 at 22:47, Joseph Myers wrote:
> On Sat, 4 May 2019, Tejas Joshi wrote:
>
> > Hello.
> > Taking the notes from Joseph under consideration, I have dev
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.
&
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
in-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 ca
Hello.
My exams are finally over and I have started to address these points now. I
intend to give my most of the time cause of holidays and will try to
consider most of the cases for the patch this time .
Thanks,
-Tejas
On Tue, 21 May 2019 at 03:18, Joseph Myers wrote:
> On Mon, 20 May 2019, Ma
);
}
The lower words of significand (sig[1] and sig[0] for 64-bit system)
are still being zero. I haven't included the roundevenf128 yet but
inspecting this on real_round function.
Am I missing something here?
Thanks.
On Wed, 29 May 2019 at 16:56, Tejas Joshi wrote:
>
> Hello.
>
Hello.
The f128 suffix worked. Based on all the corrections you all pointed
out, I have created another patch. I think I took most of the things
under consideration but please mention if I missed anything. The
following test cases were inspected with this patch. I am not sure if
the second test cas
Hello.
I have already sent a patch for roundeven implementation but I do not
know how do I commit my changes to GCC. Am I supposed to create a
branch or anything etc?
Also I have been trying to do folding for constant arguments and
inspecting for only func (func (x)) -> func (x) right now. I made s
false;
+}
Thanks.
On Mon, 3 Jun 2019 at 22:08, Joseph Myers wrote:
>
> On Fri, 31 May 2019, Tejas Joshi wrote:
>
> > +/* Return true if integer part of R is even, else return false. */
> > +
> > +bool
> > +is_even (REAL_VALUE_TYPE *r)
> > +{
> > +
.C39A5653p1f128), (0x1p2f128))
// the hex number is 3.5000...01 which would fail for roundeven
but not for f128
return 0;
}
Thanks,
-Tejas
On Tue, 4 Jun 2019 at 12:38, Tejas Joshi wrote:
>
> Hello.
>
> > NaN, and you should make sure it behaves accordingly. (If
rd spaces is occupied by
integer part?
Also, why would the least significant bit will have value 1 if
REAL_EXP (r) == SIGNIFICAND_BITS, as it only concerns with 2^0th
position (even or odd)?
Thanks,
-Tejas
On Thu, 6 Jun 2019 at 22:13, Joseph Myers wrote:
>
> On Tue, 4 Jun 2019, Tejas Joshi
Thu, 6 Jun 2019 at 22:26, Martin Jambor wrote:
>
> Hi,
>
> On Mon, Jun 03 2019, Tejas Joshi wrote:
> > Hello.
> > I have already sent a patch for roundeven implementation but I do not
> > know how do I commit my changes to GCC. Am I supposed to create a
> > b
.
How do I collect and inspect these *.sum files?
Thanks,
-Tejas
On Thu, 6 Jun 2019 at 22:26, Martin Jambor wrote:
>
> Hi,
>
> On Mon, Jun 03 2019, Tejas Joshi wrote:
> > Hello.
> > I have already sent a patch for roundeven implementation but I do not
> > know how do
ll reach return false.
> Suppose REAL_EXP (r) > SIGNIFICAND_BITS. Then the number is definitely
> even, so you should return true, not false.
for this condition, else if can be modified to just else and return true.
PATCH:
gcc/ChangeLog:
2019-06-12 Tejas Joshi
* builtins.c (math
s
On Thu, 13 Jun 2019 at 00:27, Tejas Joshi wrote:
>
> Hello.
>
> > I don't think you should have the unreachable "return false;" in is_even.
> > The last "else if" can just be "else".
>
> I don't think return false in is_even i
--Tejas
On Thu, 13 Jun 2019 at 22:49, Martin Jambor wrote:
>
> Hi Tejas,
>
> On Thu, Jun 13 2019, Tejas Joshi wrote:
> > Hello.
> > As further part of implementing roundeven is inlining, I was studying
> > machine descriptions and I have a few questions.
> >
&
does it depends on exceptions and
conditions described in the reference? Also, do ROUNDEVEN needs to be
defined as (how):
(define_int_attr rounding_insn
[(UNSPEC_FRNDINT_FLOOR "floor")
Thanks,
--Tejas
On Fri, 14 Jun 2019 at 23:02, Martin Jambor wrote:
>
> Hi,
>
> On Fri
s 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,
? 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 Jo
Hello.
This was a mail in thread Re: Expanding roundeven on 19th June but as
its gone far inside the thread, I thought of having a fresh one. The
following patch expands roundeven with instruction vroundsd using
-mavx option but without it is giving internal compiler error which I
believe is due t
Hello.
Functions like fadd, faddl take two arguments, do the addition and
return the answer in narrower precision than the argument type. The
thing that might be helpful is using the do_add function directly, if
appropriate?
The thing to consider about narrowed down return type is how it can be
ach
function should not have faddf variant, but is introduced
only for the sake.
Thanks,
-Tejas
On Wed, 3 Jul 2019 at 18:29, Tejas Joshi wrote:
>
> Hello.
> Functions like fadd, faddl take two arguments, do the addition and
> return the answer in narrower precision than the argument type. The
which is already
defined in builtin-types.def means I need not to introduce it. Why
fadd and faddl are not getting called in this patch? I don't find any
other place where these function types needs to be added.
Thanks,
-Tejas
On Sat, 6 Jul 2019 at 18:29, Tejas Joshi wrote:
>
> Hello.
&g
patch is what I have tried so far.
Thanks,
Tejas
On Wed, 10 Jul 2019 at 18:03, Richard Sandiford
wrote:
>
> Tejas Joshi writes:
> > Hello.
> > I have added fadd variants in builtins.def. For fadd and faddl
> > variants, I had to introduce builtin function types
ts zero? If yes, having functions like
double_to_float would then be useful or such functions already exist
to do the conversion?
Thanks,
Tejas
On Fri, 26 Jul 2019 at 22:49, Martin Jambor wrote:
>
> Hello Tejas,
>
> On Tue, Jul 23 2019, Tejas Joshi wrote:
> > Hi all,
> > I have
converting to return type. Its still unclear to me but its good if it
does convert to return type like it seems. I am working on these
conditions now and will try to come up with testcases.
Thanks,
Tejas
On Mon, 29 Jul 2019 at 22:47, Martin Jambor wrote:
>
> Hi,
>
> On Sat, Jul
Hi,
> In GCC (in rs6000.md) we have the "*add3_fpr" and similar insns,
> which could be extended to allow DF inputs with an SF output; it doesn't
> yet allow it.
Thanks for the inputs, I will try to address these points now. I have
built GCC on gcc112 and will apply patch and test testcases there
ossible and send another patch with them and after regression
testing. Apart from that, am I missing something in this patch?
Thanks,
Tejas
On Wed, 31 Jul 2019 at 12:06, Tejas Joshi wrote:
>
> Hello.
>
> > fold_const_fadd), for example I am not sure what the return values are
&
:10, Tejas Joshi wrote:
>
> Hello.
> I have made this patch strictly considering the following points
> Joseph mentioned in his initial email :
>
> > * The narrowing functions, e.g. fadd, faddl, daddl, are a bit different
> > from most other built-in math.h functions
te:
>
> On Wed, Jul 31, 2019 at 12:23:18PM +0530, Tejas Joshi wrote:
> > > In GCC (in rs6000.md) we have the "*add3_fpr" and similar insns,
> > > which could be extended to allow DF inputs with an SF output; it doesn't
> > > yet allow it.
> >
&g
Hello.
I have been trying to write a basic pattern taking all the suggestions
you both have mentioned. The same patch is attached here, but I cannot
see call to :
float
foo (double x, double y)
{
return __builtin_fadd (x, y);
}
being expanded to any instruction, at least a simple one, using
-f
o if the result
involves overflow / underflow).
Thanks,
Tejas
On Sat, 10 Aug 2019 at 22:16, Segher Boessenkool
wrote:
>
> Hi!
>
> On Sat, Aug 10, 2019 at 04:00:53PM +0530, Tejas Joshi wrote:
> > I have been trying to write a basic pattern taking all the suggestions
> > you bo
>
> On Sun, Aug 11, 2019 at 10:34:26AM +0530, Tejas Joshi wrote:
> > > As far as I understand that flag should set the behaviour of the fadd
> > > function, not the __builtin_fadd one. So I don't know.
> >
> > According to ISO/IEC TS 18661, I am supposed to
CD(fadd_optab, "add_trunc$b$a3") (what is the
difference between $b$a and $a$b?)
I have also tried adding fadd, add_truncdfsf3 in rs6000-builtin.def,
examined rtl dumps multiple times but couldn't get fadd to be
exapanded. What am I missing here?
Thanks,
Tejas
On Sun, 11 A
> The RTL needs to be something that
> does *not* match the combination of separate operations (just as fma has
> its own RTL, and a separate pass is responsible for converting separate
So do I need to introduce fadd's own RTL just as fma which would emit
a fused instruction while -ffp-contract is
Hello.
I just wanted to make sure that I am looking at the correct code here.
Except for rtl.def where I should be introducing something like
float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints
set on functions around expr.c, cfgexpand.c where I grep for
float_truncate/FLOAT_TRUN
15 Aug 2019 at 18:17, Richard Sandiford
wrote:
>
> Tejas Joshi writes:
> > Hello.
> > I just wanted to make sure that I am looking at the correct code here.
> > Except for rtl.def where I should be introducing something like
> > float_contract (or float_narrow?)
15:53, Richard Sandiford
wrote:
>
> Segher Boessenkool writes:
> > On Thu, Aug 15, 2019 at 01:47:47PM +0100, Richard Sandiford wrote:
> >> Tejas Joshi writes:
> >> > Hello.
> >> > I just wanted to make sure that I am looking at the correct code he
> but an unspec is of course easiest for now.
So, at this point, should I proceed with UNSPEC considering the
complications that might arise as Richard points out?
On Sat, 17 Aug 2019 at 13:51, Richard Sandiford
wrote:
>
> Tejas Joshi writes:
> > Hi,
> >
> >&
Hello.
The fromfp/fromfpx variants round to integers with a specified number
of bits, to a specified rounding mode. They come with their own
complications as Joseph had stated in an initial mail and expected to
expand them in AArch64 :
> The fromfp / fromfpx / ufromfp / ufromfpx functions (round t
Hello.
The deadline for final evaluations is 26th of August and there are
certain things that I need to submit along with the code.
A link has to be submitted of the codes that I have written and I am
thinking of doing it as a github gist along with links to commits to
my gcc fork. I know that the
Hello.
I have the following code which uses unspec but I am really missing
something here. Does unspec not work encapsulating plus? Or I have
some more places to make changes to?
(define_insn "add_truncdfsf3"
[(set (match_operand:SF 0 "gpc_reg_operand" "=,wa")
(unspec:SF
[(plus:DF
> This does almost exactly the same as what the proposed float_narrow
> would do. Instead, write it as
>
> (define_insn "add_truncdfsf3"
> [(set (match_operand:SF 0 "gpc_reg_operand" "=,wa")
> (unspec:SF [(match_operand:DF 1 "gpc_reg_operand" "%,wa")
> (match_operand:
gt; Hi Tejas,
>
> [ Please do not top-post. ]
>
> On Thu, Aug 22, 2019 at 09:09:37AM +0530, Tejas Joshi wrote:
> > Yes, I tried basically every combination I could think of, just not
> > with the "isa attr". Now, I have the following code and it is still
> &g
> I'm concerned that this would produce +0.0 for an argument of -0.5 (via
> -0.5 - 0.5 - -1.0 producing +0.0) when it needs to produce -0.0.
Would the following overhaul be acceptable as the condition is
specialized for -0.5 and +0.5 only. This seems to solve the problem. I
did test the roundeven
builtin_roundeven (0.25)) != 1)
link_error (__LINE__);
return 0;
}
Thanks,
Tejas
On Thu, 22 Aug 2019 at 22:05, Joseph Myers wrote:
>
> On Thu, 22 Aug 2019, Tejas Joshi wrote:
>
> > > I'm concerned that this would produce +0.0 for an argument of -0.5 (via
> >
ke these optimizations for sure.
Thanks,
Tejas
On Sat, 24 Aug 2019 at 02:08, Joseph Myers wrote:
>
> On Fri, 23 Aug 2019, Tejas Joshi wrote:
>
> > diff --git a/gcc/builtins.c b/gcc/builtins.c
> > index 9a766e4ad63..5149d901a96 100644
> > --- a/gcc/built
Aug 22 2019, Segher Boessenkool wrote:
> >>> > Hi Tejas,
> >>> >
> >>> > [ Please do not top-post. ]
> >>
> >> On Thu, Aug 22, 2019 at 01:27:06PM +0530, Tejas Joshi wrote:
> >>> > What happens then? "It does not
ferent? all for ISA 2.07. (for
ISA 3.0, I might use IEEE128/FLOAT128 round-to-odd instructions like
add_odd followed by conversion to narrower?)
Thanks,
Tejas
On Sun, 25 Aug 2019 at 22:17, Segher Boessenkool
wrote:
>
> [ Please don't top-post ]
>
> On Sun, Aug 25, 2019 at 07:32:0
Hello.
As deadline of GSoC has ended and regardless of what it results into,
I would like to sincerely thanks GCC for giving me this opportunity to
contribute in and learn GCC which helped me to get to know open source
community.
Working on this project has helped me to not only elevate my knowledg
]
>
> On Mon, Aug 26, 2019 at 12:43:44PM +0530, Tejas Joshi wrote:
> > Sorry for not being clear. I am confused about some modes here. I
> > meant, just as we expanded fadd (which narrows down from double to
> > float) with add_truncdfsf3, how can I expand faddl (which narro
On Sat, 31 Aug 2019 at 02:05, Segher Boessenkool
wrote:
>
> > > > > [ Please don't top-post ]
>
> (I delete everything under your signature, without looking, assuming you
> just forgot to).
Oh sorry, I didn't know the reply button does evil things. :-)
> If long double is double, faddl is the sa
d
the narrowing functions on IA64 and POWER8, for example)".
The above Project Idea is made available on 'Summer of Code' wiki of
GNU GCC Website. I wanted to have some more details about above idea
regarding to what is expected for implementation and expected output
for the same.
-Tejas Joshi
ving interest in this idea I already asked about but forgot to
introduce myself.
I, Tejas Joshi, studying undergraduate Computer Engineering, Pune
University, India.
I've worked and still working in interested C,C++ and always had keen
interest in Languages and processing. I am a member o
On 6 March 2018 at 22:25, Martin Jambor wrote:
> > You might have figured this out already but just in case something is
> > not clear:
> >
> > 1. How to check out our sources using svn and git is described at
> > https://gcc.gnu.org/svn.html and https://gcc.gnu.org/wiki/GitMirror
> > r
> * roundeven is similar to existing functions round / ceil / floor / trunc.
> So you'd define built-in functions (roundeven / roundevenf / roundevenl
> and _FloatN and _FloatNx variants) similar to those for the older rounding
> functions, in builtins.def.
Hello,
Thanks to all for your inputs t
> * roundeven is similar to existing functions round / ceil / floor / trunc.
> So you'd define built-in functions (roundeven / roundevenf / roundevenl
> and _FloatN and _FloatNx variants) similar to those for the older rounding
> functions, in builtins.def.
Hello,
Thanks to all for your inputs t
72 matches
Mail list logo
