https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #8 from Jessica Clarke ---
The clang/ subdirectory should be building itself with -fno-strict-aliasing on
GCC already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111908
--- Comment #1 from Jessica Clarke ---
NB: Arm have a vendor branch for Morello (intended to be generic across CHERI
with a Morello-specific backend, rather than overly tied to the Morello
prototype) at refs/vendors/ARM/heads/morello. I have no
Assignee: unassigned at gcc dot gnu.org
Reporter: jrtc27 at jrtc27 dot com
Target Milestone: ---
Consider:
extern char foo[];
static char weak_foo[] __attribute__((weakref("foo")));
Normally, being a tentative type with internal linkage, weak_foo would not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512
Jessica Clarke changed:
What|Removed |Added
CC||jrtc27 at jrtc27 dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107498
--- Comment #2 from Jessica Clarke ---
#define mp_lowermp_pb.pb.pb_lower
#define mp_uppermp_pb.pb.pb_upper
#define mp_pagesmp_pb.pb_pages
union {
struct {
indx_t
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jrtc27 at jrtc27 dot com
Target Milestone: ---
Target: riscv*-*-*
For the following test:
#define BUF_SIZE 2064
void
foo(unsigned long i)
{
volatile char buf[BUF_SIZE];
buf[i] = 0;
}
GCC currently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101645
Jessica Clarke changed:
What|Removed |Added
CC||jrtc27 at jrtc27 dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97534
James Clarke changed:
What|Removed |Added
CC||jrtc27 at jrtc27 dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
--- Comment #11 from James Clarke ---
(In reply to Oleg Endo from comment #10)
> I can't reproduce the first case with a standalone sh-elf compiler (GCC 9).
>
> The compile flags mention
>
> -specs=/usr/share/dpkg/pie-compile.specs
>
>
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jrtc27 at jrtc27 dot com
Target Milestone: ---
Consider the mangling for the following code:
```
template
struct enable_if {};
template
struct enable_if { typedef T type; };
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87338
--- Comment #9 from James Clarke ---
(In reply to James Clarke from comment #6)
> Created attachment 46245 [details]
> Proposed patch
>
> Currently performing a test build with this patch, but applying
> `s/^.LBI[0-9]*:$/[&]/g` to the stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87338
--- Comment #8 from James Clarke ---
Oh, and the reason it didn't show up with an older binutils is because it
didn't support dwarf2 debug_view:
> checking assembler for dwarf2 debug_view support... no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87338
James Clarke changed:
What|Removed |Added
CC||jrtc27 at jrtc27 dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #20 from James Clarke ---
(In reply to Eric Botcazou from comment #19)
> > Ah, great, thanks, that's indeed a nicer way of writing the patterns.
>
> You're welcome. Don't hesitate to ping next time I drop the ball for so
> long.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #17 from James Clarke ---
Ah, great, thanks, that's indeed a nicer way of writing the patterns.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #11 from James Clarke ---
(In reply to Eric Botcazou from comment #9)
> > There are similar problems for other TLS models which can be relaxed, but
> > even worse than this, local dynamic uses a sethi/xor for the offset from the
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84553
--- Comment #4 from James Clarke ---
(In reply to Jim Wilson from comment #2)
> rdynamic is a linker option that the compiler ignores, except to pass on to
> the linker. As far as the compiler knows, you are building a non-pic
> application,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84553
James Clarke changed:
What|Removed |Added
CC||jrtc27 at jrtc27 dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #7 from James Clarke ---
Eric, does the patch look fine to you? Do you want me to submit it to the
mailing list, or is here ok?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83368
--- Comment #19 from James Clarke ---
Thanks for the fix; is this a candidate for backporting to the gcc-7 branch? If
not we can just carry it in Debian, but it would be nicer to have it upstream.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #5 from James Clarke ---
My patch seems to work for this case:
sethi %tie_hi22(tcg_ctx), %g2
...
add %g2, %tie_lo10(tcg_ctx), %g1
ldx [%l7 + %g1], %g1, %tie_ldx(tcg_ctx)
stx %g2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #2 from James Clarke ---
Created attachment 43230
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43230=edit
0001-sparc-Fix-modes-for-TLS-offsets.patch
Here is a completely untested patch which should in theory resolve this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #1 from James Clarke ---
Elaborating slightly for those unfamiliar with SPARC TLS relocations:
Initial exec sequences normally look something like:
sethi %tie_hi22(foo), %r1
or%r1, %tie_lo10(foo), %r1
ldx [%l7+%r1],
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #19 from James Clarke ---
(In reply to Jim Wilson from comment #16)
> That referred patch was written by Eric Botcazou for PR59461 which is for
> SPARC, which operates same as Itanium, the upper 32-bits of a 32-bit value
> in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #17 from James Clarke ---
(In reply to Eric Botcazou from comment #15)
> > Thanks Jim, that makes sense. It seems to me that WORD_REGISTER_OPERATIONS
> > should still be true on ia64 given the description in the documentation.
>
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
James Clarke changed:
What|Removed |Added
Attachment #42961|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #4 from James Clarke ---
Created attachment 42961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42961=edit
Zero-out high 32 bits after a rotate
Please try the attached patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
James Clarke changed:
What|Removed |Added
CC||jrtc27 at jrtc27 dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83368
--- Comment #14 from James Clarke ---
(In reply to Eric Botcazou from comment #12)
> > Can't be done without an ABI break. But it is just the PIC register, and I'm
> > still of the view this is a GCC bug. You seem to not be listening to my
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83368
--- Comment #13 from James Clarke ---
(In reply to Eric Botcazou from comment #11)
> > > Again you're wrong, the call-saved registers are properly preserved if you
> > > don't clobber the stack pointer, just write a small test or simply tweak
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83368
--- Comment #10 from James Clarke ---
(In reply to James Clarke from comment #9)
> (In reply to Eric Botcazou from comment #7)
> > > And for what it's worth, 32-bit Solaris/SPARC's setjmp isn't saving any of
> > > the caller's input or local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83368
--- Comment #9 from James Clarke ---
(In reply to Eric Botcazou from comment #7)
> > And for what it's worth, 32-bit Solaris/SPARC's setjmp isn't saving any of
> > the caller's input or local registers either, so it's not glibc-specific.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83368
--- Comment #6 from James Clarke ---
And for what it's worth, 32-bit Solaris/SPARC's setjmp isn't saving any of the
caller's input or local registers either, so it's not glibc-specific.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83368
James Clarke changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83368
James Clarke changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
--- Comment #12 from James Clarke ---
> What is the value of TIOCGWINSZ on SH?
It's 0x80087468, which is the expansion of _IOR('t', 104, struct winsize) (sh4
uses the default encoding for _IOC; also for some reason the value is
hard-coded in
Assignee: unassigned at gcc dot gnu.org
Reporter: jrtc27 at jrtc27 dot com
CC: glaubitz at physik dot fu-berlin.de
Target Milestone: ---
Target: sparc64-linux-gnu
Created attachment 42837
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83314
--- Comment #5 from James Clarke ---
(In reply to John Paul Adrian Glaubitz from comment #4)
> Ok, I should have actually tested this on real hardware right away.
>
> Here's on my Amiga 4000:
>
> root@elgar:~> ./hello
> 5662
> fatal error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83314
--- Comment #2 from James Clarke ---
My guess is libbacktrace/mmapio.c (perhaps mmap.c), which calls mmap with
MAP_PRIVATE, and calls `error_callback (data, "mmap", errno)` on failure.
That's a function pointer, which I would assume is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
--- Comment #10 from James Clarke ---
(In reply to Segher Boessenkool from comment #9)
> What flags does it need? I can't get it to fail.
Just -O2 -fPIC, at least with 7.2.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
--- Comment #8 from James Clarke ---
Created attachment 42719
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42719=edit
Reduced reproduction.
This is a reduced version of the original reproduction. Creduce will happily
make it even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100
--- Comment #7 from James Clarke ---
(In reply to Jakub Jelinek from comment #4)
> That change looks wrong to me.
> Previously the variable was common and thus if you e.g. mixed it with some
> other TU that has const int a = 5; then you could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100
--- Comment #3 from James Clarke ---
With the same example, I can reproduce on aarch64, armel, powerpc, ppc64 and
ppc64el.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100
James Clarke changed:
What|Removed |Added
CC||jrtc27 at jrtc27 dot com
--- Comment #1
||e, jrtc27 at jrtc27 dot com
--- Comment #4 from James Clarke ---
Ping; I just ran into this today on powerpc-linux-gnuspe (a package in Debian
fails to build because of it[0]), and -mtune=native is trying to use "ppc8548"
rather than "85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79353
--- Comment #2 from James Clarke ---
Created attachment 40664
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40664=edit
Reduced Reproduction
This was reduced from parfor.c with the help of creduce. To reproduce (minimal
set of flags I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281
--- Comment #8 from James Clarke ---
Created attachment 40645
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40645=edit
Proposed fix
I believe this patch is what Adrian did; Adrian, can you please confirm?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281
--- Comment #4 from James Clarke ---
Ah, sorry, there's a separate C implementation of all this. I imagine it's the
bools in "struct M" in runtime.h messing it up, so "struct Note" and "struct
Lock" need __attribute__((aligned(4))) on their key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281
--- Comment #3 from James Clarke ---
I believe the problem is in the "m" type in runtime2.go. There are 4 bools in a
row, which is fine, as they will take up 4 bytes, but then "printlock" is an
int8, which means "fastrand" will only be 2-byte
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: jrtc27 at jrtc27 dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
Created attachment 40460
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jrtc27 at jrtc27 dot com
Target Milestone: ---
Source:
struct empty {};
struct pair_empty {
struct empty a;
struct empty b;
};
void f(int slot0, int slot1, int slot2, int slot3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71183
--- Comment #8 from James Clarke ---
(In reply to Jakub Jelinek from comment #7)
> Created attachment 38691 [details]
> gcc7-pr71183.patch
>
> Not fundamentally flawed, just one line omitted.
> Untested patch that should fix this.
Apologies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71183
--- Comment #6 from James Clarke ---
This approach is still fundamentally flawed; SOURCE_DATE_EPOCH is still not
honoured when preprocessing:
$ echo 'int main() { puts(__DATE__); }' | SOURCE_DATE_EPOCH=86400 gcc -x c -
: In function ‘main’:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71183
--- Comment #4 from James Clarke ---
Proposed patch: https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01487.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71183
--- Comment #2 from James Clarke ---
(In reply to Andrew Pinski from comment #1)
> Works on GCC 6.1.0 release:
> # 1 ""
> # 1 ""
> # 1 ""
> # 31 ""
> # 1
> "/data1/src/gcc-cavium/toolchain-6/thunderx-tools/aarch64-thunderx-linux-gnu/
>
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: jrtc27 at jrtc27 dot com
Target Milestone: ---
The inclusion of the SOURCE_DATE_EPOCH patch (SVN revision 235550) broke
__DATE__ and __TIME__ when running the preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #32 from James Clarke jrtc27 at jrtc27 dot com ---
(In reply to Ilya Mikhaltsou from comment #31)
(In reply to James Clarke from comment #29)
(In reply to Jack Howarth from comment #28)
I noticed that MacPorts is using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #33 from James Clarke jrtc27 at jrtc27 dot com ---
(In reply to Jack Howarth from comment #30)
The proposed changes in v4 of the patch aren't building here on 10.9. I
don't see how
# if defined(_DARWIN_FEATURE_64_BIT_INODE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #27 from James Clarke jrtc27 at jrtc27 dot com ---
Updated patches: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02415.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #29 from James Clarke jrtc27 at jrtc27 dot com ---
(In reply to Jack Howarth from comment #28)
I noticed that MacPorts is using…
#if SANITIZER_MAC ( !defined(__DARWIN_64_BIT_INO_T) ||
__DARWIN_64_BIT_INO_T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #25 from James Clarke jrtc27 at jrtc27 dot com ---
(In reply to Dominyk Tiller from comment #24)
It looks like gcc are gonna require someone to submit this patch to their
mailing list before we see any further activity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #26 from James Clarke jrtc27 at jrtc27 dot com ---
Patches have been sent to the mailing list -
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02344.html and
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02345.html.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #20 from James Clarke jrtc27 at jrtc27 dot com ---
(In reply to aggrostyle from comment #18)
Guys, a question... how can i apply the patch? I've read that i have to add:
patch do
url https://gcc.gnu.org/bugzilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #16 from James Clarke jrtc27 at jrtc27 dot com ---
Created attachment 33180
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180action=edit
Patch For GCC 4.9.1 On Yosemite
Requires DP 4 (or above), as I have also removed the fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
James Clarke jrtc27 at jrtc27 dot com changed:
What|Removed |Added
CC||jrtc27 at jrtc27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #15 from James Clarke jrtc27 at jrtc27 dot com ---
(In reply to James Clarke from comment #14)
The issue with Availability.h has been fixed as of Developer Preview 4,
however `all-stage1-target-libsanitizer` still fails with Error 2
66 matches
Mail list logo
