On 07/02/13 01:48, dw wrote:
I may apply the patch and let my cron jobs run it through Mozilla
sources over night if you like. In the past, those caught quite a few
problems with intrin.h.
That would be great. I've spent a bit more time on in today, and will
probably give it a final look in
On 06/30/13 09:06, dw wrote:
So, I have taken another shot at this (attached). It compiles and my
test programs are running, but I haven't finished testing it (so
please, don't anyone commit this change yet). I think I have included
everyone's feedback, but I have thought that before.
After
After a quick review, it seems good. I wonder why are you introducing
intrin-mac.h instead of putting its content in intrin-impl.h.
As I was experimenting to find a solution I liked, sometimes I needed
it, and sometimes I didn't. Since I just added the file a couple of
weeks ago (5876), I'm
On 06/28/13 01:39, dw wrote:
While I wasn't fun of adding new header in your previous patch (why
would we do that if it's included only from one file, intrin.h,
anyway?), we may add (yet another:/) new header for those shared intrins
and include it both from winnt.h and intrin.h.
I'm not
2013/6/28 Jacek Caban ja...@codeweavers.com:
On 06/28/13 01:39, dw wrote:
While I wasn't fun of adding new header in your previous patch (why
would we do that if it's included only from one file, intrin.h,
anyway?), we may add (yet another:/) new header for those shared intrins
and include it
On 06/26/13 23:57, dw wrote:
I still don't get, why we need those functions in crt.
The problem is that in MSVC it it perfectly legal to just copy/paste the
prototype for one of the intrinsics in your file and use it (see example
below). It is NOT necessary to include intrin.h. If we want
On 06/26/13 23:57, dw wrote:
I still don't get, why we need those functions in crt.
The problem is that in MSVC it it perfectly legal to just copy/paste the
prototype for one of the intrinsics in your file and use it (see example
below). It is NOT necessary to include intrin.h. If we want
Well, that won't work well (at least
this way), but I agree we have to support it one way or another. Maybe
placing them in (almost) always included file would do the trick, but
that has other problems. That said, I'm fine with your crt solution.
I agree it won't work particularly well. If
On 06/25/13 21:05, Kai Tietz wrote:
Ok, patch is ok. I would like that Jacek takes a closer look to it, too.
I still don't get, why we need those functions in crt. I retested and:
- -fno-inline is not a problem here. We use always_inline attribute and
it works fine, whatever compiler/linker
I still don't get, why we need those functions in crt.
The problem is that in MSVC it it perfectly legal to just copy/paste the
prototype for one of the intrinsics in your file and use it (see example
below). It is NOT necessary to include intrin.h. If we want to support
this (and I was
remove the #ifdef around the intrin-impl.h include in intrin.h.
Hmm, fair point.
I left it in because I thought either you or Jacek were asking for it.
But now that I look back thru the emails, I can't see what made me think
so. We'll see what Jacek has to say.
And while I'd *like* to
So, I have finished the changes I had in mind for this. I have tried to
be clear about how I intend things to work (IOW, there's lots of
comments). Changing headers/includes without breaking something
elsewhere can be challenging, but I'm pretty sure I've got this right.
On the plus side, if
2013/6/19 dw limegreenso...@yahoo.com:
So, having heard nothing back on this topic, I've decided to just try it and
see how it looks.
Thanks.
Below are the proposed contents of the new file intrin-impl.h, which gets
included at the bottom of intrin.h. It's still a little rough, but it
Code looks ok. I have no objections.
So far so good then. But I do have a question.
In Winnt.h, there is code like this:
#ifdef __CYGWIN__
# if defined(__cplusplus)
extern C {
# endif
# include x86intrin.h
# if defined(__cplusplus)
}
# endif
#else /* !__CYGWIN__ */
# include intrin.h
#endif
So, having heard nothing back on this topic, I've decided to just try it
and see how it looks.
Below are the proposed contents of the new file intrin-impl.h, which
gets included at the bottom of intrin.h. It's still a little rough, but
it should be enough to decide if I'm heading in the right
Eg. In file guard is for each function:
So, I see 2 cases for the code you sent:
1) In user code, they can just #include intrin.h. There are no
special defines they need to create. By default, it will create inline
definitions for all intrinsics.
2) In files like intrinsic\__stosb.c,
2013/6/15 dw limegreenso...@yahoo.com:
My responses:
- While I don't really see the benefit, I'm ok with putting the inline
implementations in their own .h file. And it's going to feel odd
putting an include at the *bottom* of a file.
Well, I see advantage exactly in the point of having the
we don't need to maintain implementation at two places, if we do
things right.
Are you talking about something like what I did with intrin-mac.h? While
that allows us to (mostly) write it once, you still need to have it in
two places (and test both). Or did you mean something else? If
2013/6/15 dw limegreenso...@yahoo.com:
we don't need to maintain implementation at two places, if we do
things right.
Are you talking about something like what I did with intrin-mac.h? While
that allows us to (mostly) write it once, you still need to have it in
two places (and test both).
I'd like to discuss the entire purpose of the intrin.h file in gcc.
In response to my recent proposed patch re __faststorefence, Kai
remarked that making changes to intrin.h is something we should be
minimizing/avoiding. Until this point, I hadn't been aware that this
was a point of
On 06/14/13 09:43, dw wrote:
I'd like to discuss the entire purpose of the intrin.h file in gcc.
In response to my recent proposed patch re __faststorefence, Kai
remarked that making changes to intrin.h is something we should be
minimizing/avoiding. Until this point, I hadn't been aware
I agree that intrin.h should receive some love. I have been doing some
work on it, but it was mostly fixing particular problems, I never had
a chance to do a big clean up.
The fact that it would be a big clean up should probably have been
listed in the cons. While I believe having all the
2013/6/14 dw limegreenso...@yahoo.com:
I agree that intrin.h should receive some love. I have been doing some work
on it, but it was mostly fixing particular problems, I never had a chance to
do a big clean up.
The fact that it would be a big clean up should probably have been listed
in the
23 matches
Mail list logo
