Re: toolchain build error with eglibc on OpenWrt
On 17/07/2013, at 6:26 PM, lingw...@altaitechnologies.com wrote: > Hi developers, > > I'm encountered a problem when I build OpenWrt's toolchain for Cavium > Octeon,which is mips64 r2 architectural.the error message as follow: > My toolchain units version: > gcc: 4.7.x > binutils: 2.22 > eglibc: 2.17 (svn version 22243) It will be difficult to figure out how to fix it, sorry. The problem seems to be in libgcc (which is part of GCC) not providing helpers for floating-point arithmetic operations. The likely cause of this is that the compiler was configured for a hard-float target, but eglibc is being compiled for a soft-float target. [For hard-float targets there is no need for FP helpers in libgcc since processor is assumed to handle that in silicon.] Good luck, -- Maxim Kuvyrkov KugelWorks
Re: ARM/AAarch64: NEON intrinsics in the kernel
Hi Ard, I'd like to follow up this thread to move towards removing arm_neon.h's dependence on stdint.h. My comments inline below. From: Ard Biesheuvel Date: Tue, May 21, 2013 at 10:32 AM Subject: ARM/AAarch64: NEON intrinsics in the kernel To: gcc@gcc.gnu.org Cc: Christophe Lyon , Matthew Gretton-Dann , richard.earns...@arm.com, ramana.radhakrish...@arm.com, marcus.shawcr...@arm.com Hello all, I am currently exploring various ways of using NEON instructions in kernel mode. One of the ways of doing so is using NEON intrinsics, which we would like to support in the kernel, but unfortunately, at the moment we can't because the support header arm_neon.h assumes C99 conformance and includes . The kernel does not supply that header. As far as I can tell, the only dependency arm_neon.h has on the contents of that header are the [u]int[8|16|32|64]_t typedefs. The kernel does define those, only in a different header. There are also constant macros like UINT64_C etc that cause issues when compiled with C++. Also, defining __STDC_CONSTANT_MACROS to get around this issue is won't make the problem go away, I think. I would like to propose the following way to address this issue: as arm_neon.h is coupled very tightly with GCC's internals (__builtin_neon_* types and functions), could we not modify arm_neon.h to - drop the #include Removing arm_neon.h's dependency on stdint.h is probably a good idea. - replace every instance of [u]intxx_t with the builtin macro __[U]INTxx_TYPE__ (as we are already dependent on specific versions of GCC, this should not introduce any additional limitations) The choice we have to do this is replacing all the stdint types with the predefined macros int<8,16,32,64>_t with predefined __INT<8,16,32,64>_TYPE__ and UINT64_C from stdint.h with __UINT64_C etc. But it is recommended that these never be used directly - only via the header. If we use these directly in arm_neon.h, it introduces a dependency with the predefines implementation in gcc, but as you point out that arm_neon.h is already dependent on the specific versions of gcc, this maintainance overhead is probably unavoidable. We do need standard typedefs from somewhere... Thoughts? Thanks, Tejas Belagod. ARM. In this way, it is much easier to support NEON intrinsics in environments that we care about (like the kernel) but do not conform to the standards. Kind regards, Ard.
Re: ARM/AAarch64: NEON intrinsics in the kernel
On 18 July 2013 16:54, Tejas Belagod wrote: > I'd like to follow up this thread to move towards removing arm_neon.h's > dependence on stdint.h. My comments inline below. > >> As far as I can tell, the only dependency arm_neon.h has on the >> contents of that header are the [u]int[8|16|32|64]_t typedefs. The >> kernel does define those, only in a different header. >> > Hello Tejas, What I did not realize at the time is that those types are part of the visible interface of the NEON intrinsics. Just as an example, there is a function in arm_neon.h: uint8x8_t vset_lane_u8 (uint8_t __a, uint8x8_t __b, const int __c); which clearly needs a type definition for uint8_t. Changing the published and documented interface is unlikely to be a realistic option, I'm afraid, and simply dropping the #include will cause breakage for some existing users, which is also not very appealing. Conditionally including stdint.h in case those types have not been defined (yet) would be the only remaining option, I think, but I am not sure if that is feasible. In the kernel case, I have worked around it by having a separate compilation unit containing the wrapped NEON intrinsics code, and using plain old C types to interface with the wrapper functions. [...] Regards, Ard.
Re: ARM/AAarch64: NEON intrinsics in the kernel
On 18/07/13 17:22, Ard Biesheuvel wrote: > On 18 July 2013 16:54, Tejas Belagod wrote: >> I'd like to follow up this thread to move towards removing arm_neon.h's >> dependence on stdint.h. My comments inline below. >> >>> As far as I can tell, the only dependency arm_neon.h has on the >>> contents of that header are the [u]int[8|16|32|64]_t typedefs. The >>> kernel does define those, only in a different header. >>> >> > > Hello Tejas, > > What I did not realize at the time is that those types are part of the > visible interface of the NEON intrinsics. Just as an example, there is > a function in arm_neon.h: > > uint8x8_t vset_lane_u8 (uint8_t __a, uint8x8_t __b, const int __c); > > which clearly needs a type definition for uint8_t. Changing the > published and documented interface is unlikely to be a realistic > option, I'm afraid, and simply dropping the #include will cause > breakage for some existing users, which is also not very appealing. > > Conditionally including stdint.h in case those types have not been > defined (yet) would be the only remaining option, I think, but I am > not sure if that is feasible. > > In the kernel case, I have worked around it by having a separate > compilation unit containing the wrapped NEON intrinsics code, and > using plain old C types to interface with the wrapper functions. > > [...] > > Regards, > Ard. > Since you need definitions of uint8_t and friends, and they can come from either linux/types.h or stdint.h, why not check both? #ifdef _LINUX_TYPES_H // We have the types from #else #ifdef _STDINT_H // We have them from #else #include // or #include #endif #endif (I don't know which header is preferred for the default include).
Re: Fwd: [Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop
On 07/14/2013 01:24 AM, Sebastian Pop wrote: Hi Jeff, let's start with getting this bug fixed. So what do you need? Just making the tiling factor won't solve the problem AFAICT. As I've mentioned, I'm already over-booked on other things and don't have the time to do any significant development on the graphite bits. jeff
Re: Fwd: [Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop
For this testcase, it looks like the scop detection pass should be fixed: it currently discards the interesting loop nest. I can help figuring out what is needed to be fixed, though I cannot send patches to fix the problem. On Thu, Jul 18, 2013 at 11:31 AM, Jeff Law wrote: > On 07/14/2013 01:24 AM, Sebastian Pop wrote: >> >> Hi Jeff, >> >> let's start with getting this bug fixed. > > So what do you need? Just making the tiling factor won't solve the problem > AFAICT. As I've mentioned, I'm already over-booked on other things and > don't have the time to do any significant development on the graphite bits. > > jeff >
Re: ARM/AAarch64: NEON intrinsics in the kernel
Ard Biesheuvel wrote: On 18 July 2013 16:54, Tejas Belagod wrote: I'd like to follow up this thread to move towards removing arm_neon.h's dependence on stdint.h. My comments inline below. As far as I can tell, the only dependency arm_neon.h has on the contents of that header are the [u]int[8|16|32|64]_t typedefs. The kernel does define those, only in a different header. Hello Tejas, What I did not realize at the time is that those types are part of the visible interface of the NEON intrinsics. Just as an example, there is a function in arm_neon.h: uint8x8_t vset_lane_u8 (uint8_t __a, uint8x8_t __b, const int __c); which clearly needs a type definition for uint8_t. Changing the published and documented interface is unlikely to be a realistic option, I'm afraid, and simply dropping the #include will cause breakage for some existing users, which is also not very appealing. I was thinking more on the lines of #ifdef __INT8_TYPE__ typedef __INT8_TYPE__ int8_t; #endif and #ifdef __UINT64_C #define UINT64_C(c) __UINT64_C (c) #endif In other words this is perhaps reproducing a part of stdint-gcc.h. I don't know if there can be a situation when these are predefines are not defined ( eg. some -m option that turns them off?) Conditionally including stdint.h in case those types have not been defined (yet) would be the only remaining option, I think, but I am not sure if that is feasible. Are you proposing something like: /* arm_neon.h */ #ifndef __intxx_t_defined ... #define __STDC_CONSTANT_MACROS #include #endif ... /* Prevent __STDC_CONSTANT_MACROS from polluting the environment. */ #ifdef __STDC_CONSTANT_MACROS #undef __STDC_CONSTANT_MACROS #endif /* End of arm_neon.h */ Including all of stdint.h for only a few basic types/macros that we need seems to suggest to me that its too heavy a hammer, is it not? Thanks, Tejas. In the kernel case, I have worked around it by having a separate compilation unit containing the wrapped NEON intrinsics code, and using plain old C types to interface with the wrapper functions. [...] Regards, Ard.
Andes nds32 port accepted and maintainers appointed
I am pleased to announce that the GCC Steering Committee has accepted the Andes nds32 port for inclusion in GCC and appointed Chung-Ju Wu and Shiva Chen as port maintainers. The initial patch needs approval from a GCC GWP maintainer before it may be committed. Please join me in congratulating Chung-Ju and Shiva on their new roles. Please update your listing in the MAINTAINERS file. Happy hacking! David
note generating in case of type confliction
Hello, I'm mostly new to gcc, so I don't really have a real idea how notes are generated. More exactly I would like to know, how types are compared during compilation, and what makes the compiler decide to throw a message in case they aren't equal. There is this message "note: expected `type` but argument is type of `type`". Now I'm searching the gcc-4.4.5 source library for that particular message, in hopes of getting a direction towards what i causes this message to appear. But I'm lost now, and need some help - a direction or a hint, where to lookup (source,headers,binaries) , would be very appreciated. Many thanks! Alex
Re: Fwd: [Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop
+Albert Would there be somebody from your group Albert who could help maintaining and pushing patches to graphite? The focus is fixing graphite to get performance from the isl scheduler on benchmarks that the gcc community will help identify. Thanks, Sebastian On Thu, Jul 18, 2013 at 11:44 AM, Sebastian Pop wrote: > For this testcase, it looks like the scop detection pass should be fixed: > it currently discards the interesting loop nest. I can help figuring out what > is needed to be fixed, though I cannot send patches to fix the problem. > > On Thu, Jul 18, 2013 at 11:31 AM, Jeff Law wrote: >> On 07/14/2013 01:24 AM, Sebastian Pop wrote: >>> >>> Hi Jeff, >>> >>> let's start with getting this bug fixed. >> >> So what do you need? Just making the tiling factor won't solve the problem >> AFAICT. As I've mentioned, I'm already over-booked on other things and >> don't have the time to do any significant development on the graphite bits. >> >> jeff >>
gcc-4.8-20130718 is now available
Snapshot gcc-4.8-20130718 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130718/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 201041 You'll find: gcc-4.8-20130718.tar.bz2 Complete GCC MD5=facf091d360b9c27f51215f6e7fe24fb SHA1=0ee976ba5f71c5ae218fb471b6069c3c2953ac98 Diffs from 4.8-20130711 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: note generating in case of type confliction
On 18 July 2013 20:32, Klin Iop wrote: > Hello, > > I'm mostly new to gcc, so I don't really have a real idea how notes are > generated. More exactly I would like to know, how types are compared during > compilation, and what makes the compiler decide to throw a message in case > they aren't equal. There is this message "note: expected `type` but argument > is type of `type`". Are you sure that's what it says? In the current sources search for "but argument" in gcc/c-family/c-format.c, in the GCC 4.4 sources search in gcc/c-typeck.c
Re: [boost] lots of warning with gcc-4.8.1 + boost-1.54.0
Nathan Ridge writes: >> On 3 July 2013 02:41, Nathan Ridge wrote: ./boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally defined but not used [-Wunused-local-typedefs] >> >> It was new in GCC 4.7, http://gcc.gnu.org/gcc-4.7/changes.html > > I've seen spews of that warning for other large projects, such as > clang or wxWidgets, not just boost. > > Would GCC consider removing it from -Wall? GCC doesn't emit this warning if such typedefs are annotated with __attribute__((__unused__)). We just need to fix all instances of this problem. So far I identified these there: - https://svn.boost.org/trac/boost/ticket/8844 (Boost.Bind) - https://svn.boost.org/trac/boost/ticket/8847 (Boost.ConceptCheck) - https://svn.boost.org/trac/boost/ticket/8859 (Boost.Serialization) Thanks, PM
[RFC / musing] Scoped exception handling in Linux userspace?
Windows has a feature that I've wanted on Linux forever: stack-based
(i.e. scoped) exception handling. The upshot is that you can do,
roughly, this (pseudocode):
int callback(...)
{
/* Called if code_that_may_fault faults. May return "unwind to
landing pad", "propagate the fault", or "fixup and retry" */
}
void my_function()
{
__hideous_try_thing(callback) {
code_that_may_fault();
} blahblahblah {
landing_pad_code();
}
}
Windows calls it SEH (structured exception handling), and the
implementation on 32-bit Windows is rather gnarly. I don't really
know how it works on 64-bit windows, but I think it's saner.
This has two really nice properties:
1. It works in libraries!
2. It's localized. So you can mmap something, read from it *and
handle SIGBUS*, and unmap.
Could Linux support such a thing? Here's a sketch of a way:
- The kernel would need to have a fairly well-defined concept of
synchronous faults that can be handled with this mechanism. Calls to
force_sig_info are probably the right thing to hook in to.
- The userspace runtime optionally registers (via a new syscall or
prctl, say) a handler for synchronous faults.
- When a synchronous fault happens, if the process (struct
sighand_struct) has a synchronous fault handler registered, the signal
is delivered to that handler, on the thread that faulted, instead of
via the normal signal handling mechanism.
- The userspace runtime walks the chain of personality handlers and
gives them a chance to respond.
- If no handler claims the fault, then the user code somehow* causes
ordinary signal delivery to happen.
* This may need kernel help, too -- if the process is going to die, it
should die for the right reason, so perhaps there should be a syscall
to redeliver the signal. If the runtime wants to be fancy and a
signal handler is installed, then there could be a fast path. Maybe
if we got really fancy, it could live in the vdso.
Now everyone wins! After someone writes the libgcc support for this
(ugh!), then you can write CFI-based exception handlers in assembly!
Presumably you could write them in C++, too, if you don't care about
restarting, like this:
try {
code_that_may_fault();
} catch (cxxabi::synchronous_kernel_fault &) {
amazingly_dont_crash();
}
Is this worth persuing? I'm not touching the gcc part with a ten-foot
pole, but I could probably do some of the kernel work. I'm a bit
scared of libgcc, too.
It's worth noting that SIGBUS isn't the only interesting signal here.
SIGFPE could work, too. I'm not sure whether SIGPIPE would make
sense. SIGSEGV would clearly work, but anyone using this mechanism
for SIGSEGV is probably asking for trouble.
--Andy
P.S. Just because you can probably get away with throwing a C++
exception from a signal handler right now does not mean it's a good
idea. Especially in a library.
Re: [RFC / musing] Scoped exception handling in Linux userspace?
On 07/18/2013 05:26 PM, Andy Lutomirski wrote:
Windows has a feature that I've wanted on Linux forever: stack-based
(i.e. scoped) exception handling. The upshot is that you can do,
roughly, this (pseudocode):
int callback(...)
{
/* Called if code_that_may_fault faults. May return "unwind to
landing pad", "propagate the fault", or "fixup and retry" */
}
void my_function()
{
__hideous_try_thing(callback) {
code_that_may_fault();
} blahblahblah {
landing_pad_code();
}
}
How is this different than throwing exceptions from a signal handler?
GCC already supports this on many architectures running on the Linux kernel.
You can do it from C using incantations like those found in the GCC
testsuite's gcc/testsuite/gcc.dg/cleanup-9.c file.
From C++ it is even easier, it is just a normal exception.
David Daney
Windows calls it SEH (structured exception handling), and the
implementation on 32-bit Windows is rather gnarly. I don't really
know how it works on 64-bit windows, but I think it's saner.
This has two really nice properties:
1. It works in libraries!
2. It's localized. So you can mmap something, read from it *and
handle SIGBUS*, and unmap.
Could Linux support such a thing? Here's a sketch of a way:
- The kernel would need to have a fairly well-defined concept of
synchronous faults that can be handled with this mechanism. Calls to
force_sig_info are probably the right thing to hook in to.
- The userspace runtime optionally registers (via a new syscall or
prctl, say) a handler for synchronous faults.
- When a synchronous fault happens, if the process (struct
sighand_struct) has a synchronous fault handler registered, the signal
is delivered to that handler, on the thread that faulted, instead of
via the normal signal handling mechanism.
- The userspace runtime walks the chain of personality handlers and
gives them a chance to respond.
- If no handler claims the fault, then the user code somehow* causes
ordinary signal delivery to happen.
* This may need kernel help, too -- if the process is going to die, it
should die for the right reason, so perhaps there should be a syscall
to redeliver the signal. If the runtime wants to be fancy and a
signal handler is installed, then there could be a fast path. Maybe
if we got really fancy, it could live in the vdso.
Now everyone wins! After someone writes the libgcc support for this
(ugh!), then you can write CFI-based exception handlers in assembly!
Presumably you could write them in C++, too, if you don't care about
restarting, like this:
try {
code_that_may_fault();
} catch (cxxabi::synchronous_kernel_fault &) {
amazingly_dont_crash();
}
Is this worth persuing? I'm not touching the gcc part with a ten-foot
pole, but I could probably do some of the kernel work. I'm a bit
scared of libgcc, too.
It's worth noting that SIGBUS isn't the only interesting signal here.
SIGFPE could work, too. I'm not sure whether SIGPIPE would make
sense. SIGSEGV would clearly work, but anyone using this mechanism
for SIGSEGV is probably asking for trouble.
--Andy
P.S. Just because you can probably get away with throwing a C++
exception from a signal handler right now does not mean it's a good
idea. Especially in a library.
Re: [RFC / musing] Scoped exception handling in Linux userspace?
On Thu, Jul 18, 2013 at 5:40 PM, David Daney wrote:
> On 07/18/2013 05:26 PM, Andy Lutomirski wrote:
>>
>> Windows has a feature that I've wanted on Linux forever: stack-based
>> (i.e. scoped) exception handling. The upshot is that you can do,
>> roughly, this (pseudocode):
>>
>> int callback(...)
>> {
>>/* Called if code_that_may_fault faults. May return "unwind to
>> landing pad", "propagate the fault", or "fixup and retry" */
>> }
>>
>> void my_function()
>> {
>>__hideous_try_thing(callback) {
>> code_that_may_fault();
>>} blahblahblah {
>> landing_pad_code();
>>}
>> }
>
>
> How is this different than throwing exceptions from a signal handler?
Two ways. First, exceptions thrown from a signal handler can't be
retries. Second, and more importantly, installing a signal handler in
a library is a terrible idea.
--Andy
Re: [RFC / musing] Scoped exception handling in Linux userspace?
On 07/18/2013 05:50 PM, Andy Lutomirski wrote:
On Thu, Jul 18, 2013 at 5:40 PM, David Daney wrote:
On 07/18/2013 05:26 PM, Andy Lutomirski wrote:
Windows has a feature that I've wanted on Linux forever: stack-based
(i.e. scoped) exception handling. The upshot is that you can do,
roughly, this (pseudocode):
int callback(...)
{
/* Called if code_that_may_fault faults. May return "unwind to
landing pad", "propagate the fault", or "fixup and retry" */
}
void my_function()
{
__hideous_try_thing(callback) {
code_that_may_fault();
} blahblahblah {
landing_pad_code();
}
}
How is this different than throwing exceptions from a signal handler?
Two ways. First, exceptions thrown from a signal handler can't be
retries.
??
Second, and more importantly, installing a signal handler in
a library is a terrible idea.
The signal handler would be installed by main() before calling into the
library. You have to have a small amount of boiler plate code to set it
up, but the libraries wouldn't have to be modified if they were already
exception safe.
FWIW the libgcj java runtime environment uses this strategy for handling
NullPointerExceptions and DivideByZeroError(sp?). Since all that code
for the most part follows the standard C++ ABIs, it is an example of
this technique that has been deployed in many environments.
David Daney
resurrecting automatic dependencies
Today I started resurrecting my old automatic dependency patch. I decided, this time, to take a more incremental approach. Thanks to git, I made a patch series, rather than one monster patch. Now we can easily test various parts of the change to more easily notice if, or when, we trip across the GNU make bug again. I pushed the series to gcc.git tromey/auto-dependency-checking (which was supposed to be 'tracking', but which I mistyped completely unconsciously: the fingers have reasons which reason cannot know). Anyway.. The branch for now only implements automatic dependency tracking for host objects. This is the most useful case. The series on the branch is based on the observation that it is safe to leave explicit dependencies in the Makefile during the conversion. Conversions of various bits are done in separate patches. I've tested this a bit and it works ok. I tried clean builds with various -jN options to try to provoke missing dependencies, and caught a few bugs that way. Usually bugs are just a missing pre-dependency and are easy to fix. There may be more missing dependencies. Please try out this branch if you would. You can report bugs to me, just send the build log. There are still a few things that I haven't done yet: * Update the dependencies in files in config/ * Make auto dependency tracking work for build/*.o * Remove all the *_H macros from Makefile.in * Ada I suppose at least removing the dead macros would be good to have. The rest is nice but optional -- leaving them undone won't break anything. Tom
Re: [RFC / musing] Scoped exception handling in Linux userspace?
On Thu, Jul 18, 2013 at 6:17 PM, David Daney wrote: > On 07/18/2013 05:50 PM, Andy Lutomirski wrote: >> >> On Thu, Jul 18, 2013 at 5:40 PM, David Daney >> wrote: >>> >>> On 07/18/2013 05:26 PM, Andy Lutomirski wrote: >>> >>> >>> How is this different than throwing exceptions from a signal handler? >> >> >> Two ways. First, exceptions thrown from a signal handler can't be >> retries. > > > ?? s/retries/retried, by which I mean that you can't do things like implementing virtual memory in userspace by catching SIGSEGV, calling mmap, and resuming. > > >> Second, and more importantly, installing a signal handler in >> a library is a terrible idea. > > > The signal handler would be installed by main() before calling into the > library. You have to have a small amount of boiler plate code to set it up, > but the libraries wouldn't have to be modified if they were already > exception safe. > > FWIW the libgcj java runtime environment uses this strategy for handling > NullPointerExceptions and DivideByZeroError(sp?). Since all that code for > the most part follows the standard C++ ABIs, it is an example of this > technique that has been deployed in many environments. Other way around: a *library* that wants to use exception handling can't do so safely without the cooperation, or at least understanding, of the main program and every other library that wants to do something similar. Suppose my library installs a SIGFPE handler and throws my_sigfpe_exception and your library installs a SIGFPE handler and throws your_sigfpe_exception. The result: one wins and the other crashes due to an unhandled exception. In my particular usecase, I have code (known to the main program) that catches all kinds of fatal signals to log nice error messages before dying. That means that I can't use a library that handles signals for any other purpose. Right now I want to have a small snippet of code handle SIGBUS, but now I need to coordinate it with everything else. If this stuff were unified, then everything would just work. --Andy
Re: [RFC / musing] Scoped exception handling in Linux userspace?
On Jul 19, 2013, at 2:26 AM, Andy Lutomirski wrote: > Windows has a feature that I've wanted on Linux forever: stack-based > (i.e. scoped) exception handling. The upshot is that you can do, > roughly, this (pseudocode): [...] Indeed Windows and OpenVMS have such a mechanism. That's clean and library friendly, but please read: https://www.usenix.org/conference/wiess-2000/c-exception-handling-ia64 to understand how it hurts optimization. (And no, raising an exception from an handler doesn't always work, due to optimizations allowed by the gcc exception mechanism). Regards, Tristan.
