[GSoC] Google Summer of Code 2015: GCC got accepted
Dear all, GCC has been accepted as Google Summer of Code mentor organization, https://www.google-melange.com/gsoc/homepage/google/gsoc2015 Time line: * March 27: Deadline of Student applications (opens March 16) * Until May 25: Community bonding * May 25 to August 24: Coding time Suggestions for projects are listed at https://gcc.gnu.org/wiki/SummerOfCode Maintainers: Please check whether the list is up to date or some new fancy proposal is missing. Potential GSoC Students: Have a look at the list - but if you have a nice idea, feel also free to discuss other proposals at the GCC mailing lists (-> https://gcc.gnu.org/lists.html). Maintainers: Please register at GSoC 2015 as (potential) mentor. We will need you for ranking the proposals and for mentoring students. This year's GSoC is org-mentored by me and Maxim (as backup org maintainer). Cheers, Tobias
Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
On 28/02/2015 9:12 am, Manuel López-Ibáñez wrote: On 02/19/15 14:56, Chris Johns wrote: My main concern is not knowing the trap has been added to the code. If I could build an application and audit it somehow then I can manage it. We have a similar issue with the possible use of FP registers being used in general code (ISR save/restore trade off). Can the ELF be annotated in some GCC specific way that makes it to the final executable to flag this is happening ? We can then create tools to audit the executables. Simply ignore me if I'm misunderstanding the issue: Couldn't GCC generate, instead of a trap, a call to a noinline noreturn cold weak function __gcc_is_a_trap that by default calls the trap? Then, audit tools can inspect the code and see if such a function call appears and even override it with something else. Yes it could and this is a nice idea. Chris, wouldn't that be enough for your purposes? I think it does because we can scan an executable for the call locations and audit them. Chris
please document requirements on sphinx
Both gccjit and gnat now use sphinx to build the documentation. While not a direct part of the build process, it would be nice to document the requirements on sphinx, and agree on a common version used to generate that documentation. Coming from a distro background where I have to "build from source", I know that sphinx is a bit less stable than say doxygen and texinfo. So some kind of version information, about not using sphinx plugins, etc. would be appreciated. thanks, Matthias
Offloading GSOC 2015
Hi all, I finished my master at Barcelona Supercomputing Center and i started to do PhD. My master thesis code generation OpenMP 4.0 for GPU accelerators. And i am still working on it. Last year i presented my research compiler MACC at IWOMP'14 which is based on OmpSs runtime (http://pm.bsc.es/). You can check here my paper and related paper http://portais.fieb.org.br/senai/iwomp2014/presentations/Guray_Ozen.pptx http://link.springer.com/chapter/10.1007%2F978-3-319-11454-5_16 As far as i know, GCC 5 will come with OpenMP 4.0 and OpenACC offloading. I am wondering that are there a any project related code generation within gsoc 2015? Because when i checked todo list about offloading, i couldn't come accross. or what am i supposed to do? Güray Özen ~grypp
Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
On 02/20/2015 10:01 AM, Jeff Law wrote: On 02/20/15 05:10, Jakub Jelinek wrote: On Fri, Feb 20, 2015 at 12:06:28PM +0100, Florian Weimer wrote: On 02/19/2015 09:56 PM, Sandra Loosemore wrote: H, Passing the additional option in user code would be one thing, but what about library code? E.g., using memcpy (either explicitly or implicitly for a structure copy)? The memcpy problem isn't restricted to embedded architectures. size_t size; const unsigned char *source; std::vector vec; … vec.resize(size); memcpy(vec.data(), source, size); std::vector::data() can return a null pointer if the vector is empty, which means that this code is invalid for empty inputs. I think the C standard is wrong here. We should extend it, as a QoI matter, and support null pointers for variable-length inputs and outputs if the size is 0. But I suspect this is still a minority view. I disagree. If you want a function that will have that different property, don't call it memcpy. Right. If someone wants to take it up with the Austin group, that's fine. But until/unless the Austin group blesses, I don't think we should extend as a QoI matter. As a data point(*) it might be interesting to note that GCC itself relies on memcpy providing stronger guarantees than the C standard requires it to by emitting calls to the function for large structure self-assignments (which are strictly conforming, as discussed in bug 65029). Martin [*] IMO, one in favor of tightening up the memcpy specification to require implementations to provide the expected semantics.
Re: Restricting arguments to intrinsic functions
First off, I apologize for resurrecting such an old thread, but I feel
this needs a bit of clarity and to add my "two cents".
On 10/23/2014 12:52 PM, Charles Baylis wrote:
Hi
( tl;dr: How do I handle intrinsic or builtin functions where there
are restrictions on the arguments which can't be represented in a C
function prototype? Do other ports have this problem, how do they
solve it? Language extension for C++98 to provide static_assert?)
I'm trying to resolve some problems with error reporting for NEON (ARM
SIMD/vector) intrinsics.
eg https://bugs.linaro.org/show_bug.cgi?id=418
The NEON intrinsics are defined in a header file, arm_neon.h, which
includes type definitions and inline functions which implement the
intrinsics in terms of __builtin functions provided by gcc.
A number of these intrinsics (eg shift by a constant, set/get Nth lane
of vector) are defined to take a compile-time integer constant as one
of their arguments. For example:
The vshrn_n_s16 (narrowing vector shift right by a constant) intrinsic
is defined as:
__extension__ static __inline int8x8_t __attribute__ ((__always_inline__))
vshrn_n_s16 (int16x8_t __a, const int __b)
{
return (int8x8_t)__builtin_neon_vshrn_nv8hi (__a, __b, 1);
}
These examples demonstrate some valid and invalid use
int8x16_t v = vshrn_n_u16(v1, 5); // valid
int8x16_t v = vshrn_n_u16(v1, 20); // invalid, constant is out of range
int x = 5;
int8x16_t v = vshrn_n_u16(v1, x); // invalid, shift amount is not
a compile-time constant
We have a distinct (human) language problem here. Going by the C
standard, there's no such thing as a "compile-time constant". What you
appear to be referring to in your example is an "integer constant
expression" as per §6.6. In the real world, if you compile your example
with -O1 or better, gcc is going to replace that "x" with 5 because it
clearly will always be 5 when that line of code is reached and
__builtin_constant_p(x) will always return 1. This is what I generally
call a "compile-time constant" (exists in the real world in optimized
builds, but not yet in the C standard). So in fact, that last line
shouldn't be invalid per your specifications, unless it compiled w/o
optimizations, but again, it depends on what you mean by "compile-time
constant".
Presently, the ARM/Aarch64 backends include some checks, but this
doesn't work very well, as it allows invalid operations to persist too
long. By the time the error is raised, the original source position is
lost. Therefore, I would like to add some error checking at an earlier
stage, with various options coming to mind:
1. Somehow arrange for __builtin_neon_vshrn_nv8hi to require a
constant integer in the prescribed range as the 2nd argument.
2. Redefine the intrinsic function in arm_neon.h to include
_Static_assert(__b >= 1 && __b <=8, "Shift amount out of range");
3. Put a static assert into a macro
#define vshrn_n_s16(a,b) \
({ _Static_assert(__b >= 1 && __b <=8, "Shift amount out of
range"); _vshrn_n_s16(a,b); })
_Static_assert doesn't care about what the optimizer determines is
constant or not, so both options 2 and 3 here will enforce that b is an
"integer constant expression". If you were to use this in an inline (or
always_inline) function, the _Static_assert would always fail.
4. Some sort of language extension so that inline functions can
require compile-time constants for suitably annotated arguments.
eg
static __inline int8x8_t __attribute__ ((__always_inline__))
vshrn_n_s16 (int16x8_t __a, const int
__attribute((constant_range(1,8))) __b)
Pros/cons of each approach:
1. somewhat complex to implement, errors are reported in arm_neon.h,
rather than at the source line in the user's code.
2. Easy to implement. Can be adapted to support C++11 using
static_assert, but doesn't work for C++98 (maybe a language extension
is possible to provide the same functionality as __static_assert in
C++98?) . Errors are reported in arm_neon.h, rather than user's code.
3. Easy to implement, the compiler will indicate the source line where
the macro was used, so that the user can find the location of their
error easily. Can also be adapted to support C++11 using
static_assert, but doesn't work for C++98.
4. Results in high quality error messages, but is complex to implement.
In my view, options 1&4 are potentially complex to implement. I favour
one of 2 or 3, with an extension to C++98 to provide
static_assert-like functionality. This is not unprecedented, as
_Static_assert is provided in all C language dialects.
I am interested in views on the relative merits of these approaches.
Thanks
Charles
I'm working on a C metaprogramming library for (currently supporting
only gcc) and this is an everyday dilemma for me. I have a macros for
this (see
https://github.com/daniel-santos/gboing/blob/master/include/gboing/compiler.h#L62).
So if written as such(and compiled with optimizations):
Re: string constant of the constant pool entry..
Umesh Kalappa writes:
> Hi All,
>
> I'm trying to fetch the string constant from the constant pool entry
> for the symbol_ref rtx like
>
> c sample
>
> int i;
> int main()
> {
> printf("%d",i);
> }
>
> rtl is
>
> (gdb) p debug_rtx(val)
> (symbol_ref/f:SI ("*.LC0") [flags 0x2] )
The SYMBOL_REF_DECL is a VAR_DECL whose DECL_INITIAL is the constant. So:
> corresponding asm
>
>.section.rodata,code
> .align 2
> .LC0:
> .ascii "%d\000"
>
>
> sample code to fetch the string "%d"
>
> tree sym = SYMBOL_REF_DECL(rtx);
>
> if (!(sym && (TREE_CODE(sym)==STRING_CST) && STRING_CST_CHECK(sym)))
> sym = 0;
...I think you want:
if (TREE_CONSTANT_POOL_ADDRESS_P (symbol))
{
tree str = DECL_INITIAL (SYMBOL_REF_DECL (symbol));
if (TREE_CODE (str) == STRING_CST)
...
}
(STRING_CST_CHECK is really local to the tree.h macros, it shouldn't
be used elsewhere.)
Thanks,
Richard
Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
On 03/03/15 12:57, Martin Sebor wrote: As a data point(*) it might be interesting to note that GCC itself relies on memcpy providing stronger guarantees than the C standard requires it to by emitting calls to the function for large structure self-assignments (which are strictly conforming, as discussed in bug 65029). Right. I actually spent quite a bit of time struggling with this a while back in a different context. The only case I could come up with where GCC would generate an overlapping memcpy was self assignment, but even that was bad and while we ultimately punted, I've always considered it a wart. [*] IMO, one in favor of tightening up the memcpy specification to require implementations to provide the expected semantics. That works for me :-) The things done in glibc's memcpy are a bit on the absurd side and the pain caused by the changes over time is almost impossible to overstate. If the Austin group tightens memcpy to require fewer surprises I think most developers would ultimately be happy with the result -- a few would complain about the performance impacts for specific workloads, but I suspect they'd be in the minority. jeff
