https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #37 from H. Peter Anvin ---
One would assume that there would be __foo__ aliases for the attribute names
like all the other ones.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
David Malcolm changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #34 from Tom Tromey tromey at gcc dot gnu.org ---
Created attachment 33277
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33277action=edit
initial patch
This is my current patch. I'm uploading it for safekeeping
as I probably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #33 from Tom Tromey tromey at gcc dot gnu.org ---
My current patch fails on some of the sparse validation tests.
E.g., attr-in-parameter.c:
attr_in_parameter.c:8:4: warning: assignment from pointer to different address
space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #31 from Tom Tromey tromey at gcc dot gnu.org ---
(In reply to Tom Tromey from comment #28)
Please let me know what I can do to help complete this branch. I'd be happy
to help write the documentation, for instance.
It's maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #32 from Tom Tromey tromey at gcc dot gnu.org ---
(In reply to Tom Tromey from comment #31)
force, adddress_space, and noderef are the final 5 commits on the branch.
Err, 8 commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #29 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Tom Tromey from comment #26)
2. __force itself presents a problem as its semantics isn't well defined and
only sparse knows how to model it. in gcc it cannot be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #30 from Andi Kleen andi-gcc at firstfloor dot org ---
Please don't invent your own syntax for this. Use the one that has been widely
deployed for years. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #26 from Tom Tromey tromey at gcc dot gnu.org ---
(In reply to PaX Team from comment #23)
some data points based on my experience with the 'checker' gcc plugin in PaX:
Hi. Thanks for your reply.
I didn't easily find a git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #27 from Josh Triplett josh at joshtriplett dot org ---
(In reply to Tom Tromey from comment #21)
(In reply to Tom Tromey from comment #20)
BTW if you want to try it out I have a branch:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #28 from Tom Tromey tromey at gcc dot gnu.org ---
Please let me know what I can do to help complete this branch. I'd be happy
to help write the documentation, for instance.
It's maybe not quite ready for testing. But if you want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #25 from Tom Tromey tromey at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #24)
There is a patch for GCC that was basically approved in January:
https://gcc.gnu.org/ml/gcc-patches/2014-01/msg01284.html
I am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #23 from PaX Team pageexec at gmail dot com ---
some data points based on my experience with the 'checker' gcc plugin in PaX:
1. the C address space infrastructure available since gcc 4.6 can be sort of
coerced into implementing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #24 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to PaX Team from comment #23)
3. designated_init is a tricky problem because by the time a plugin can
examine variable initializers, gcc will have lost the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #21 from Tom Tromey tromey at gcc dot gnu.org ---
(In reply to Tom Tromey from comment #20)
BTW if you want to try it out I have a branch:
https://github.com/tromey/gcc/tree/add-sparse-attributes
This still needs a bit of work.
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #20 from Tom Tromey tromey at gcc dot gnu.org ---
(In reply to Josh Triplett from comment #19)
I brought this exact case up on linux-sparse, and Christopher Li's (quite
reasonable) perspective was that it doesn't really make sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #17 from Tom Tromey tromey at gcc dot gnu.org ---
It seems that force works on function parameters and casts
but not direct assignments:
bapiya. nl -ba /tmp/q.c
1#define A(N) __attribute__((address_space (N)))
2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #18 from Tom Tromey tromey at gcc dot gnu.org ---
(In reply to Tom Tromey from comment #17)
It seems that force works on function parameters and casts
but not direct assignments:
It's also an error in conditional expressions and in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #19 from Josh Triplett josh at joshtriplett dot org ---
(In reply to Tom Tromey from comment #18)
(In reply to Tom Tromey from comment #17)
It seems that force works on function parameters and casts
but not direct assignments:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #6 from Tom Tromey tromey at gcc dot gnu.org ---
Null pointer constants are treated specially, which makes sense,
but only if they have type void * and are in address space 0.
That is, this works:
#define NULL ((__attribute__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #7 from Josh Triplett josh at joshtriplett dot org ---
(In reply to Tom Tromey from comment #6)
Null pointer constants are treated specially, which makes sense,
but only if they have type void * and are in address space 0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #8 from H. Peter Anvin hpa at zytor dot com ---
Arguably the *right* way to solve that would be to support __null for C as well
as for C++.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #9 from Tom Tromey tromey at gcc dot gnu.org ---
(In reply to Josh Triplett from comment #7)
I can't think of a legitimate reason to have a null pointer constant in a
non-zero address space; there's already a null pointer constant,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #10 from Tom Tromey tromey at gcc dot gnu.org ---
Relatedly, could you say what the option -Wcast-to-as provides
beyond the normal warnings about changing address spaces?
I wonder if this is something I should be pulling in as well.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #11 from Josh Triplett josh at joshtriplett dot org ---
(In reply to Tom Tromey from comment #10)
Relatedly, could you say what the option -Wcast-to-as provides
beyond the normal warnings about changing address spaces?
I wonder if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #12 from Josh Triplett josh at joshtriplett dot org ---
(In reply to Tom Tromey from comment #9)
(In reply to Josh Triplett from comment #7)
I can't think of a legitimate reason to have a null pointer constant in a
non-zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #13 from Josh Triplett josh at joshtriplett dot org ---
(In reply to H. Peter Anvin from comment #8)
Arguably the *right* way to solve that would be to support __null for C as
well as for C++.
__null or nullptr?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #14 from Tom Tromey tromey at gcc dot gnu.org ---
(In reply to Josh Triplett from comment #11)
Without -Wcast-to-as, you won't get a warning for unforced casts that add an
address space.
Thanks!
Personally, I'd actually suggest
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #15 from Josh Triplett josh at joshtriplett dot org ---
(In reply to Tom Tromey from comment #14)
(In reply to Josh Triplett from comment #11)
Personally, I'd actually suggest merging the two in GCC, and always issuing
both sets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #16 from H. Peter Anvin hpa at zytor dot com ---
Josh: nullptr pollutes the C user namespace, so it's not an option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #5 from Tom Tromey tromey at gcc dot gnu.org ---
(In reply to Josh Triplett from comment #4)
What version of sparse did you try that with? I can't seem to reproduce
that with the current version, nor with older versions.
The one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #4 from Josh Triplett josh at joshtriplett dot org ---
(In reply to Tom Tromey from comment #3)
I noticed this behavior and was wondering if it is intended:
bapiya. cat /tmp/q.c
__attribute__((force)) int *p;
int q = *p;
bapiya.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
Tom Tromey tromey at gcc dot gnu.org changed:
What|Removed |Added
CC||tromey at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
Josh Triplett josh at joshtriplett dot org changed:
What|Removed |Added
CC||josh at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #2 from Josh Triplett josh at joshtriplett dot org ---
Here's a test case from Sparse, demonstrating some tricky behavior of noderef:
# define __A__attribute__((noderef))
struct x {
int a;
int b;
};
struct y {
int
37 matches
Mail list logo
