se need conditionals in 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
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
64-bit 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.or
ter try to 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
ess we do need a clear
understanding 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.
--
fecting 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 o
uld 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 bod
earing the padding bits, but also having them in the right
> 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
mply to provide 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/majordom
different (for ports that started
out with 32-bit 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
ation supports objects large enough 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...@c
nless you have a new variant of the ioctl syscall itself. Logically 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
rnel uses a 64-bit type for nanoseconds on systems where
"long" is 32-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 6
ented
with newfstatat / 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/
folks?
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 conclusi
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
7;t know what dependencies 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 li
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&
omics (GCC 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 l
read-modify-write to a word containing 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 al
ven necessarily 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
e the case that Y' interoperates with X, X' interoperates with 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 ar
OW) | current->thread.spefscr_last;
__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.
fesetenv restores a saved value of spefscr 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
ca
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.kerne
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.kerne
aware 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;
curr
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->thread.fpexc_mode & PR_FP_EX
Z_high < 0, choose Z2 */
+ if (lo_inexact && s_lo) {
+ if (fp_result)
+ fgpr.wp[1]++; /* Z_low < 0, choose Z2 */
+ else
+ fgpr.wp[1]--; /* Z_low < 0, choos
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...@codesource
& s_lo)
+ 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 unsubs
teger 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. Myer
return 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
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 testsui
result)
+ fgpr.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/
ose Z2 */
+ 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&
mp; 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 the line "u
nd rounding mode attributes
from part 1, probably among 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/
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
42 matches
Mail list logo
