On Thu, Mar 15, 2018 at 04:08:10PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 15, 2018 at 07:10:26AM -0700, Steve Kargl wrote:
> > On Thu, Mar 15, 2018 at 01:35:23PM +0100, Richard Biener wrote:
> > > >
> > > > extern GFC_INTEGER_4 kill (GFC_INTEGER_4, GFC_INTEGER_4);
> > > > extern __typeof(kill) k
On Thu, Mar 15, 2018 at 3:54 PM, Jakub Jelinek wrote:
> On Thu, Mar 15, 2018 at 03:45:47PM +, Bin.Cheng wrote:
>> FYI, both your patches fix the compilation issue.
>
> It isn't just a compilation problem, it really can't work at all.
> Without the patch, if the function builds, it looks like:
On Thu, Mar 15, 2018 at 03:45:47PM +, Bin.Cheng wrote:
> FYI, both your patches fix the compilation issue.
It isn't just a compilation problem, it really can't work at all.
Without the patch, if the function builds, it looks like:
002308b0 <_gfortran_kill>:
2308b0: f3 0f 1e fa
On Thu, Mar 15, 2018 at 3:08 PM, Jakub Jelinek wrote:
> On Thu, Mar 15, 2018 at 07:10:26AM -0700, Steve Kargl wrote:
>> On Thu, Mar 15, 2018 at 01:35:23PM +0100, Richard Biener wrote:
>> > >
>> > > extern GFC_INTEGER_4 kill (GFC_INTEGER_4, GFC_INTEGER_4);
>> > > extern __typeof(kill) kill __asm__(
On Thu, Mar 15, 2018 at 07:10:26AM -0700, Steve Kargl wrote:
> On Thu, Mar 15, 2018 at 01:35:23PM +0100, Richard Biener wrote:
> > >
> > > extern GFC_INTEGER_4 kill (GFC_INTEGER_4, GFC_INTEGER_4);
> > > extern __typeof(kill) kill __asm__("" "_gfortran_kill");
> >
> > Why do you need to jump throug
On Thu, Mar 15, 2018 at 12:20:08PM +, Bin.Cheng wrote:
> >> -fdata-sections -O2 -mabi=ilp32 -MT kill.lo -MD -MP -MF .deps/kill.Tpo
> >> -c /.../gcc/libgfortran/intrinsics/kill.c -o kill.o
> >> /.../gcc/libgfortran/intrinsics/kill.c:54:22: error: conflicting types
> >> for 'kill'
> >> extern GF
On Thu, Mar 15, 2018 at 01:35:23PM +0100, Richard Biener wrote:
> >
> > extern GFC_INTEGER_4 kill (GFC_INTEGER_4, GFC_INTEGER_4);
> > extern __typeof(kill) kill __asm__("" "_gfortran_kill");
>
> Why do you need to jump through these hoops anyway? Just do ...
>
Not sure who the "you" refers to.
On Thu, Mar 15, 2018 at 1:11 PM, Bin.Cheng wrote:
> On Thu, Mar 15, 2018 at 10:18 AM, Bin.Cheng wrote:
>> On Wed, Mar 14, 2018 at 12:57 AM, Steve Kargl
>> wrote:
>>> On Tue, Mar 13, 2018 at 09:49:10PM +0200, Janne Blomqvist wrote:
int val = kill (pid, signal);
return (val == 0): 0
On Thu, Mar 15, 2018 at 12:11 PM, Bin.Cheng wrote:
> On Thu, Mar 15, 2018 at 10:18 AM, Bin.Cheng wrote:
>> On Wed, Mar 14, 2018 at 12:57 AM, Steve Kargl
>> wrote:
>>> On Tue, Mar 13, 2018 at 09:49:10PM +0200, Janne Blomqvist wrote:
int val = kill (pid, signal);
return (val == 0):
On Thu, Mar 15, 2018 at 10:18 AM, Bin.Cheng wrote:
> On Wed, Mar 14, 2018 at 12:57 AM, Steve Kargl
> wrote:
>> On Tue, Mar 13, 2018 at 09:49:10PM +0200, Janne Blomqvist wrote:
>>>
>>> int val = kill (pid, signal);
>>> return (val == 0): 0 ? errno;
>>>
>>> like it already does for the optional sta
On Wed, Mar 14, 2018 at 12:57 AM, Steve Kargl
wrote:
> On Tue, Mar 13, 2018 at 09:49:10PM +0200, Janne Blomqvist wrote:
>>
>> int val = kill (pid, signal);
>> return (val == 0): 0 ? errno;
>>
>> like it already does for the optional status argument for kill_sub.
>>
>
> Committed as r258511 with yo
On Tue, Mar 13, 2018 at 09:49:10PM +0200, Janne Blomqvist wrote:
>
> int val = kill (pid, signal);
> return (val == 0): 0 ? errno;
>
> like it already does for the optional status argument for kill_sub.
>
Committed as r258511 with your suggested change.
--
Steve
On Tue, Mar 13, 2018 at 6:08 AM, Steve Kargl
wrote:
> On Mon, Mar 12, 2018 at 09:05:09PM +0200, Janne Blomqvist wrote:
>>
>> Yes, I understand that -fdefault-integer-8 (or whatever the equivalent
>> option was called on g77) is the original motivation. Like I said, I
>> don't have any particular o
On Mon, Mar 12, 2018 at 09:05:09PM +0200, Janne Blomqvist wrote:
>
> Yes, I understand that -fdefault-integer-8 (or whatever the equivalent
> option was called on g77) is the original motivation. Like I said, I
> don't have any particular opinion on whether we should keep that
> restriction or not
On Mon, Mar 12, 2018 at 7:37 PM, Steve Kargl
wrote:
> On Mon, Mar 12, 2018 at 06:56:24PM +0200, Janne Blomqvist wrote:
>> On Sun, Mar 11, 2018 at 10:42 PM, Steve Kargl
>> > I suppose we could remove the restriction to INTEGER(4) and
>> > INTEGER(8), but I don't see any reason to do so. INTEGER(1)
On Mon, Mar 12, 2018 at 06:56:24PM +0200, Janne Blomqvist wrote:
> On Sun, Mar 11, 2018 at 10:42 PM, Steve Kargl
> > I suppose we could remove the restriction to INTEGER(4) and
> > INTEGER(8), but I don't see any reason to do so. INTEGER(1)
> > is too limited given that at least on FreeBSD the low
On Sun, Mar 11, 2018 at 10:42 PM, Steve Kargl
wrote:
> On Sun, Mar 11, 2018 at 10:16:01PM +0200, Janne Blomqvist wrote:
>> On Sun, Mar 11, 2018 at 6:52 PM, Steve Kargl
>> wrote:
>> > The attach patch cleans up KILL to match its
>> > documentation. In doing so, I have changed
>> > the argument ke
On Sun, Mar 11, 2018 at 10:16:01PM +0200, Janne Blomqvist wrote:
> On Sun, Mar 11, 2018 at 6:52 PM, Steve Kargl
> wrote:
> > The attach patch cleans up KILL to match its
> > documentation. In doing so, I have changed
> > the argument keywords to consistently use
> > pid and sig. If no one object
On Sun, Mar 11, 2018 at 6:52 PM, Steve Kargl
wrote:
> The attach patch cleans up KILL to match its
> documentation. In doing so, I have changed
> the argument keywords to consistently use
> pid and sig. If no one objects, I intend to
> commit this tomorrow.
>
> 2018-03-11 Steven G. Kargl
>
>
The attach patch cleans up KILL to match its
documentation. In doing so, I have changed
the argument keywords to consistently use
pid and sig. If no one objects, I intend to
commit this tomorrow.
2018-03-11 Steven G. Kargl
* check.c (gfc_check_kill): Check pid and sig are scalar.
20 matches
Mail list logo
