n them
(based on whatever preprocessor macro is defined in userspace for the new
virtual architecture) to export the right ABI for each case.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please include linux-api on such discussions relating to the kernel /
userspace interface. I'm likely to pay more attention to them if I
receive them through linux-api than anything only received through direct
email.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from
Please include linux-api on such discussions relating to the kernel /
userspace interface. I'm likely to pay more attention to them if I
receive them through linux-api than anything only received through direct
email.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from
in userspace for the new
virtual architecture) to export the right ABI for each case.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
it gettimeofday / settimeofday would
need to use a combination of the syscalls if the tz pointer is non-NULL.)
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mor
/ settimeofday would
need to use a combination of the syscalls if the tz pointer is non-NULL.)
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
do things one syscall
> family at a time and actually get the kernel to handle them
> correctly internally?
I don't have any comments on that ordering question.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
anding of which filesystems have what timestamp limits and what
happens with timestamps beyond those limits, I think this is a separate
strand of the problem - one that applies to both 32-bit and 64-bit systems
- from the more general issue for 32-bit systems.
--
Joseph S. Myers
jos...@codesource
ecting the kernel/userspace
interface (as opposed to those relating to an individual filesystem)
should go to linux-api as well as other relevant lists.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
/userspace
interface (as opposed to those relating to an individual filesystem)
should go to linux-api as well as other relevant lists.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
with timestamps beyond those limits, I think this is a separate
strand of the problem - one that applies to both 32-bit and 64-bit systems
- from the more general issue for 32-bit systems.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux
the kernel to handle them
correctly internally?
I don't have any comments on that ordering question.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
II should be such an architecture
(Other variants may arise as well, e.g. architectures with existing kernel
support that only get glibc support later.)
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
ght
> place.
Yes, I see no problem with putting the padding bits in the right place so
that when the kernel is passing struct timespec values *to* userspace, it
can just fill in the native 64-bit structure and have it automatically be
correct when interpreted as a 32-bit structure with paddi
fill in the native 64-bit structure and have it automatically be
correct when interpreted as a 32-bit structure with padding (which the
kernel will have zeroed implicitly) on tv_nsec.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux
be such an architecture
(Other variants may arise as well, e.g. architectures with existing kernel
support that only get glibc support later.)
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
new versions of them all for 64-bit time_t.)
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please r
time_t, conversion code will be needed anyway to convert
to the 32-bit structure if the new syscalls are unavailable at runtime and
so the old syscalls need to be used, but if the kernel's structure with
64-bit time_t is different from that in userspace then both old and new
kernels need c
, but if the kernel's structure with
64-bit time_t is different from that in userspace then both old and new
kernels need conversion code). Given Rich Felker's bug reports, it seems
reasonable to suppose that musl will wish to do this as well as glibc.
--
Joseph S. Myers
jos...@codesourcery.com
time_t.)
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ugh to make this
necessary.").
If you were designing from scratch, no doubt a typedef such as snseconds_t
would be there, but with real-world APIs that have accumulated over time,
deviating from "long" now is a bad idea.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe f
that have accumulated over time,
deviating from long now is a bad idea.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
lly I
suppose _TIME_BITS=64 should then map the generic version of an ioctl to
the 64-bit time_t version so applications don't need to change beyond
defining _TIME_BITS=64, though I don't know if there's any precedent for
doing that sort of thing for definitions in kernel headers rather than
gl
-bit in userspace, either it needs to treat the high word as
padding or glibc needs to wrap all interfaces passing a struct timespec
into the kernel so they clear the padding field. There's even less need
for a 64-bit type for microseconds.)
--
Joseph S. Myers
jos...@codesourcery.com
--
To u
fstatat / fstatat64 rather than lots of separate syscalls.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
?
See what I said at
<https://sourceware.org/bugzilla/show_bug.cgi?id=9712#c4> (with references
to previous discussions). Someone needs to take the lead on pushing to
consensus the question of what syscalls should have wrappers in glibc, and
then implement the conclusions.
.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
a struct timespec
into the kernel so they clear the padding field. There's even less need
for a 64-bit type for microseconds.)
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
precedent for
doing that sort of thing for definitions in kernel headers rather than
glibc's headers.)
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Wed, 26 Feb 2014, Torvald Riegel wrote:
> On Fri, 2014-02-21 at 22:10 +0000, Joseph S. Myers wrote:
> > On Fri, 21 Feb 2014, Paul E. McKenney wrote:
> >
> > > This needs to be as follows:
> > >
> > > [[carries_dependency]] int getzero(int i [[carr
On Wed, 26 Feb 2014, Torvald Riegel wrote:
On Fri, 2014-02-21 at 22:10 +, Joseph S. Myers wrote:
On Fri, 21 Feb 2014, Paul E. McKenney wrote:
This needs to be as follows:
[[carries_dependency]] int getzero(int i [[carries_dependency]])
{
return i - i
encies might be
carried. "Note: The carries_dependency attribute does not change the
meaning of the program, but may result in generation of more efficient
code. - end note".
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe
: The carries_dependency attribute does not change the
meaning of the program, but may result in generation of more efficient
code. - end note.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On Mon, 17 Feb 2014, Torvald Riegel wrote:
> On Mon, 2014-02-17 at 18:59 +0000, Joseph S. Myers wrote:
> > On Sat, 15 Feb 2014, Torvald Riegel wrote:
> >
> > > glibc is a counterexample that comes to mind, although it's a smaller
> > > code base. (It'
builtins rather than _Atomic /
, but using __atomic_* with explicitly specified memory model
rather than the older __sync_*) on AArch64, plus in certain cases on ARM
and MIPS.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kerne
than _Atomic /
stdatomic.h, but using __atomic_* with explicitly specified memory model
rather than the older __sync_*) on AArch64, plus in certain cases on ARM
and MIPS.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Mon, 17 Feb 2014, Torvald Riegel wrote:
On Mon, 2014-02-17 at 18:59 +, Joseph S. Myers wrote:
On Sat, 15 Feb 2014, Torvald Riegel wrote:
glibc is a counterexample that comes to mind, although it's a smaller
code base. (It's currently not using C11 atomics, but transitioning
ning another field, for example) and I
think it's pretty obvious that glibc should do so as well.
(Of course, memset is not an atomic operation, and you need to allow for
that if you use it on an _Atomic object - which is I think valid, unless
the object is also volatile, but perhaps ill-advised.)
, for example) and I
think it's pretty obvious that glibc should do so as well.
(Of course, memset is not an atomic operation, and you need to allow for
that if you use it on an _Atomic object - which is I think valid, unless
the object is also volatile, but perhaps ill-advised.)
--
Joseph S
arily get compatibility for the alignment of
_Atomic types yet (and no ABI document I've seen discusses that issue).
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
h Y, but X'
and Y' don't interoperate with each other. I'd envisage something more
like mapping not to instructions, but to concepts within the
architecture's own memory model - but that requires the architecture's
memory model to be as well defined, and probably formalized, as the C11
one.)
--
Jo
, but to concepts within the
architecture's own memory model - but that requires the architecture's
memory model to be as well defined, and probably formalized, as the C11
one.)
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
compatibility for the alignment of
_Atomic types yet (and no ABI document I've seen discusses that issue).
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
__FPU_FPSCR |= (FP_CUR_EXCEPTIONS & FP_EX_MASK);
mtspr(SPRN_SPEFSCR, __FPU_FPSCR);
+ current->thread.spefscr_last = __FPU_FPSCR;
current->thread.evr[fc] = vc.wp[0];
regs->gpr[fc] = vc.wp[1];
--
Joseph S. Myers
jos...@codesourcer
-thread.spefscr_last = __FPU_FPSCR;
current-thread.evr[fc] = vc.wp[0];
regs-gpr[fc] = vc.wp[1];
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
which may both set and clear
bits (and then it calls prctl because it needs to do so anyway to restore
the saved state for which exceptions were enabled). fesetexceptflag
restores saved state of particular exceptions without a trap (so needs to
call prctl specially to inform the kernel of a
it needs to do so anyway to restore
the saved state for which exceptions were enabled). fesetexceptflag
restores saved state of particular exceptions without a trap (so needs to
call prctl specially to inform the kernel of a change).
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe
Ping^2. I still haven't seen any comments on any of these patches.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
Ping^2. I still haven't seen any comments on any of these patches.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
Ping. I haven't seen any comments on any of these patches.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
Ping. I haven't seen any comments on any of these patches.
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
e of it.
+*/
+ __FPU_FPSCR
+ &= ~(FP_EX_INVALID | FP_EX_UNDERFLOW) | current->thread.spefscr_last;
__FPU_FPSCR |= (FP_CUR_EXCEPTIONS & FP_EX_MASK);
mtspr(SPRN_SPEFSCR, __FPU_FPSCR);
+ current->thread.spefscr_last = __FPU_FPSCR;
current-
illegal:
@@ -867,6 +885,8 @@ int speround_handler(struct pt_regs *regs)
pr_debug(" to fgpr: %08x %08x\n", fgpr.wp[0], fgpr.wp[1]);
+ if (current->thread.fpexc_mode & PR_FP_EXC_SW_ENABLE)
+ return (current->thread.fpexc_mode & PR_FP_EXC_RES
if (lo_inexact && s_lo) {
+ if (fp_result)
+ fgpr.wp[1]++; /* Z_low < 0, choose Z2 */
+ else
+ fgpr.wp[1]--; /* Z_low < 0, choose Z2 */
+ }
+
signed != 2)
\
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-
ow detection. */
\
_FP_FRAC_SRL_##wc(X, _FP_WORKBITS);
\
_FP_FRAC_ASSEMBLE_##wc(r, X, rsize);
\
}
\
--
Joseph S. Myers
jos...@code
)
+ fgpr.wp[1]++; /* Z_low < 0, choose Z2 */
+ if (hi_inexact && s_hi)
+ fgpr.wp[0]++; /* Z_high < 0, choose Z2 */
}
break;
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from
and fixed-point conversions)
depends on patch 2 (fix e500 SPE float rounding inexactness
detection). Other than that, I think any subset of the patches can be
applied in any order, if some subset seems OK but there are concerns
about other patches in the series.
--
Joseph S. Myers
jos
and fixed-point conversions)
depends on patch 2 (fix e500 SPE float rounding inexactness
detection). Other than that, I think any subset of the patches can be
applied in any order, if some subset seems OK but there are concerns
about other patches in the series.
--
Joseph S. Myers
jos
)
+ fgpr.wp[0]++; /* Z_high 0, choose Z2 */
}
break;
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
);
\
}
\
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
;
\
}
\
else if (rsigned != 2)
\
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
*regs)
pr_debug( to fgpr: %08x %08x\n, fgpr.wp[0], fgpr.wp[1]);
+ if (current-thread.fpexc_mode PR_FP_EXC_SW_ENABLE)
+ return (current-thread.fpexc_mode PR_FP_EXC_RES) ? 1 : 0;
return 0;
}
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe
*/
+ }
}
break;
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
;
__FPU_FPSCR |= (FP_CUR_EXCEPTIONS FP_EX_MASK);
mtspr(SPRN_SPEFSCR, __FPU_FPSCR);
+ current-thread.spefscr_last = __FPU_FPSCR;
current-thread.evr[fc] = vc.wp[0];
regs-gpr[fc] = vc.wp[1];
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send
rn 1;
+ }
return 0;
illegal:
@@ -867,6 +885,8 @@ int speround_handler(struct pt_regs *regs)
pr_debug(" to fgpr: %08x %08x\n", fgpr.wp[0], fgpr.wp[1]);
+ if (current->thread.fpexc_mode & PR_FP_EXC_SW_ENABLE)
+ return (current->
pt_regs *regs)
pr_debug( to fgpr: %08x %08x\n, fgpr.wp[0], fgpr.wp[1]);
+ if (current-thread.fpexc_mode PR_FP_EXC_SW_ENABLE)
+ return (current-thread.fpexc_mode PR_FP_EXC_RES) ? 1 : 0;
return 0;
}
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, 8 Oct 2013, Joseph S. Myers wrote:
> I'll send as a followup the testcase I used for verifying that the
> instructions (other than the theoretical conversions to 64-bit
> integers) produce the correct results. In addition, this has been
> tested with the glibc testsuite (w
pr.wp[1]++; /* Z_low < 0, choose Z2 */
+ else
+ fgpr.wp[1]--; /* Z_low < 0, choose Z2 */
+ }
+ if (hi_inexact && s_hi) {
+ if (fp_result)
+ fgpr.wp[0]++; /* Z_high < 0, choose Z2
*/
+ else
+ fgpr.wp[0]--; /* Z_high < 0, choose Z2
*/
+ }
}
break;
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
LE_##wc(r, X, rsize);
\
}
\
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj
)
\
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
)
\
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
);
\
_FP_FRAC_ASSEMBLE_##wc(r, X, rsize);
\
}
\
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
, choose Z2
*/
+ else
+ fgpr.wp[0]--; /* Z_high 0, choose Z2
*/
+ }
}
break;
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line
On Tue, 8 Oct 2013, Joseph S. Myers wrote:
I'll send as a followup the testcase I used for verifying that the
instructions (other than the theoretical conversions to 64-bit
integers) produce the correct results. In addition, this has been
tested with the glibc testsuite (with the e500 port
+ if (hi_inexact && s_hi)
+ fgpr.wp[0]++; /* Z_high < 0, choose Z2 */
}
break;
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
_MASK);
mtspr(SPRN_SPEFSCR, __FPU_FPSCR);
+ current->thread.spefscr_last = __FPU_FPSCR;
current->thread.evr[fc] = vc.wp[0];
regs->gpr[fc] = vc.wp[1];
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubsc
-thread.evr[fc] = vc.wp[0];
regs-gpr[fc] = vc.wp[1];
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
*/
}
break;
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
g the larger pieces.)
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.)
--
Joseph S. Myers
jos...@codesourcery.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
tforms where unsigned 32-bit
values are zero-extended rather than sign-extended to 64 bits.
--
Joseph S. Myers
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kern
where unsigned 32-bit
values are zero-extended rather than sign-extended to 64 bits.
--
Joseph S. Myers
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
83 matches
Mail list logo
