[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC
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
[Bug target/111908] Port CheriBSD-specific compiler warnings to GCC
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 experience of it, and it's less mature than our decade-old Clang/LLVM, but it purports to both add CHERI C diagnostics and introduce Morello code generation. They are tied together, as they are in our Clang/LLVM, but there's no reason one couldn't port some of the diagnostics to non-CHERI and warn people that they're doing things outside of ISO (or even GNU) C, even if they happen to work on those architectures, though disambiguating intptr_t vs ((un)signed) long (long) (or even int on ILP32) may not be feasible given that *is* very much OK on ILP32/LP64/LLP64.
[Bug c/110910] New: weakref should allow incomplete array type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110910
Bug ID: 110910
Summary: weakref should allow incomplete array type
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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 be
allowed to have an incomplete type, and this is what GCC enforces today
("warning: array 'weak_foo' assumed to have one element" / "error: array size
missing in 'weak_foo'" depending on -pedantic). However, weakref is special,
and makes weak_foo not exist at all, but instead be an alias for foo, which can
legitimately have internal linkage. Therefore I believe this restriction,
namely C99 6.9.2p3, should be relaxed when weakref is used. This does mean the
diagnostic for something like:
static char weak_foo[];
...
static char weak_foo[] __attribute__((weakref("foo")));
needs to be delayed until the whole file has been parsed, but given GCC already
supports:
static char foo[];
...
static char foo[42];
as an extension that doesn't seem to be a problem.
[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512 Jessica Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #11 from Jessica Clarke --- Macros and __has_feature are equally expressive, sure, but why should Clang change what it’s been doing from the start because GCC doesn’t want to be compatible with how it’s always done it? It seems a bit rude to expect Clang to change when it was the one to define how these worked first and GCC took its implementation. It’s not like it’s a complicated thing for GCC to implement, and it should really have done so when it added sanitizer support in order to be fully compatible rather than do things differently and force users to support both ways in their code (which, to this day, isn’t reliably done, so there is code out there that only works with Clang’s sanitizers).
[Bug middle-end/107498] Wrong optimization leads to unaligned access when compiling OpenLDAP
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 pb_lower; /**< lower
bound of free space */
indx_t pb_upper; /**< upper
bound of free space */
} pb;
uint32_tpb_pages; /**< number of overflow pages
*/
} mp_pb;
That's the code. GCC is perfectly ok to optimise that to do a 32-bit load. If
it has an alignment fault that's OpenLDAP's problem, the uint32_t there means
it must be 32-bit aligned if you don't want UB.
[Bug target/105733] New: riscv: Poor codegen for large stack frames
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105733
Bug ID: 105733
Summary: riscv: Poor codegen for large stack frames
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: 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 generates:
foo:
li t0,-4096
addit0,t0,2016
li a4,4096
add sp,sp,t0
li a5,-4096
addia4,a4,-2032
add a4,a4,a5
addia5,sp,16
add a5,a4,a5
add a0,a5,a0
li t0,4096
sd a5,8(sp)
sb zero,2032(a0)
addit0,t0,-2016
add sp,sp,t0
jr ra
whereas Clang generates the much shorter:
foo:
lui a1, 1
addiw a1, a1, -2016
sub sp, sp, a1
addia1, sp, 16
add a0, a0, a1
sb zero, 0(a0)
lui a0, 1
addiw a0, a0, -2016
add sp, sp, a0
ret
The:
li a4,4096
...
li a5,-4096
addia4,a4,-2032
add a4,a4,a5
sequence in particular is rather surprising to see rather than just li a4,-2032
and constant-folding that would halve the instruction count difference between
GCC and Clang alone.
See: https://godbolt.org/z/8EGc85dsf
[Bug c/101645] -Wsign-conversion misses negation of unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101645 Jessica Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #1 from Jessica Clarke --- Correction: "x is negated but as an *unsigned* int", which is key here
[Bug target/97534] [10/11 Regression] ICE in decompose, at rtl.h:2280 (arm-linux-gnueabihf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97534 James Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com, ||rearnsha at arm dot com --- Comment #4 from James Clarke --- [Adding Richard to CC] Richard, I see you committed a big series of changes in Oct 2019 to gcc/config/arm that affected subtraction; is it possible one of those broke this test case?
[Bug target/93877] [9/10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
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
>
> ... what's in that specs file?
(sid-sh4-sbuild)root@sh4-gandi-02:~# cat /usr/share/dpkg/pie-compile.specs
*self_spec:
+
%{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:%{!fno-PIE:%{!no-pie:-fPIE
So, since -fPIC is provided on the command line already, it shouldn't be doing
anything.
[Bug c++/91979] New: Incorrect mangling for non-template-argument nullptr expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91979
Bug ID: 91979
Summary: Incorrect mangling for non-template-argument nullptr
expression
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
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
void foo(typename enable_if::type* = 0) {}
template void foo<(void *)0>(void *);
```
This is one way of exposing how the expression `nullptr` is mangled when of
type
nullptr_t. Currently, GCC produces:
_Z3fooILPv0EEvPN9enable_ifIXeqT_LDn0EEvE4typeE
whereas Clang produces:
_Z3fooILPv0EEvPN9enable_ifIXeqT_LDnEEvE4typeE
Note the difference between LDn0E and LDnE for representing the nullptr inside
the
boolean expression for the enable_if. Based on the specification in cxx-abi,
Clang is
correct:
> The pointer literal expression nullptr is encoded as "LDnE". In contrast, a
> template
> argument which happens to be a null pointer (an extension made standard in
> C++11) is
> mangled as if it were a literal 0 of the appropriate pointer type; for
> example,
> "LPi0E" or "LDn0E". This inconsistency is an unfortunate accident.
The bug is in cp/mangle.c write_expression:
```
/* Handle literals. */
else if (TREE_CODE_CLASS (code) == tcc_constant
|| code == CONST_DECL)
write_template_arg_literal (expr);
```
This is correct for literal expressions, which are mangled identically to
template
argument literals, with the exception of nullptr.
Note also that c++filt (and thus GCC's/libiberty's demangler) does not Clang's
compliant
mangling, only GCC's current incorrect mangling.
[Bug bootstrap/87338] gcc 8.2 fails to bootstrap on ia64
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 (the one with debug info enabled) > assembly for one of the differing files fixed the differences to the stage3 > file, so I'm confident this will fix it (assuming my change actually > compiles). Patch confirmed to work locally (also, stage2 and stage3 should be swapped in the above comment, since stage2 is the one that *disables* debug info). I will send it to the mailing list shortly.
[Bug bootstrap/87338] gcc 8.2 fails to bootstrap on ia64
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
[Bug bootstrap/87338] gcc 8.2 fails to bootstrap on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87338 James Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #6 from James Clarke --- Created attachment 46245 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46245=edit Proposed patch Currently performing a test build with this patch, but applying `s/^.LBI[0-9]*:$/[&]/g` to the stage2 (the one with debug info enabled) assembly for one of the differing files fixed the differences to the stage3 file, so I'm confident this will fix it (assuming my change actually compiles).
[Bug target/84010] problematic TLS code generation on 64-bit SPARC
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 had forgotten myself that a fix was never committed, probably because I remembered writing the patch, otherwise I would have pinged it long ago!
[Bug target/84010] problematic TLS code generation on 64-bit SPARC
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.
[Bug target/84010] problematic TLS code generation on 64-bit SPARC
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 > > defining module's block to load a signed 32-bit value, but since it's marked > > as SI I assume a spill/reload will truncate the top 32 bits and thus lose > > any sign extension if it's negative, breaking it even with linker relaxation > > disabled. > > It turns out that this sethi/xor pair cannot generate a negative value > according to the calculation formulas of R_SPARC_TLS_LDO_HIX22 & > R_SPARC_TLS_LDO_LOX10 available at > https://docs.oracle.com/cd/E37838_01/html/E36783/man-tlsam.html > > So, if the above formulas are [correct], relaxation is required in all cases. Yes, for Local Dynamic itself, the offset will always be positive, since it's the offset from the start of that module's TLS block. However, *all* TLS models, including Local Dynamic, can currently be relaxed to Local Exec on SPARC, which always generates negative offsets (Variant II, so static TLS blocks come just before TP). So, as far as I see it, we have two choices: 1. Disable all X -> LE relaxations in the linker. Works, but then gives suboptimal performance if some code linked into an executable is built with -fPIC rather than -fPIE (or nothing). 2. Apply this patch to GCC (assuming it still applies cleanly...). I'm struggling to understand what you meant by "relaxation is required in all cases"; did you mean *forbidden* in all cases (i.e. my point 1)?
[Bug target/84553] -rdynamic generates TEXTREL relocations on ia64
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, and hence the symbol is local. We can't assume that -rdynamic > will be used at compile time, and hence to make this work we must assume > that any local symbol might become global at link time. Ah I see, that explains it. > We can fix this my modifying the ia64_reloc_rw_mask function to return 3 > when non-pic, same as it does when pic, to indicate that local symbols with > relocs aren't read-only. > > I don't have access to ia64 hardware, so I don't have any easy way to test > this. > The symbol ends up in .data.rel.ro.local instead of .data.rel.ro, but > presumably that is OK. That's what happens on hppa which has similar function descriptor behaviour, so that should be fine.
[Bug target/84553] -rdynamic generates TEXTREL relocations on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84553 James Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #1 from James Clarke --- This is a GCC bug. The function "d" here is non-static and thus exported as a dynamic symbol. On ia64, function descriptors for dynamic symbols are always allocated by the dynamic linker at runtime for canonicalisation (yes, there are other things you could do, but this is what was chosen), and therefore are not link-time constants, even though the contents of this function descriptor can be determined at link-time (since this is linking an executable). GCC should instead be placing this in a relro section like you said.
[Bug target/84010] [sparc64] Problematic TLS code generation
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?
[Bug target/83368] alloca after setjmp breaks PIC base reg
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.
[Bug target/84010] [sparc64] Problematic TLS code generation
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, [%fp+1783] ! note this is %g2, i.e. just the hi22... callgen_new_label, 0 ldx[%g7+%g1], %i5 ... ldx [%fp+1783], %g1 ! reload the hi22 add %g1, %tie_lo10(tcg_ctx), %i5 ldx [%l7 + %i5], %i5, %tie_ldx(tcg_ctx) ldx [%g7+%i5], %g1 The code gen is something else; I don't understand why it spills the result of the hi22 and re-adds the lo10 (which takes the worst aspects of rematerialisation and spilling), but that's a whole other story.
[Bug target/84010] [sparc64] Bad TLS code generation
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 series of issues. This doesn't introduce rematerialization for them (or, if it's supposed to already, resolve whatever's stopping it), but that's a future optimisation. I'm surprised these are even being scheduled so far apart and spilled, but hey.
[Bug target/84010] [sparc64] Bad TLS code generation
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], %r2, %tie_ldx(foo) add %g7, %r2, %r2, %tie_add(foo) (if %l7 is the PIC base register), so %r1 ends up being a 32-bit GOT offset (where the GOT is storing the offset of the thread-local variable from the thread pointer, %g7). Note that %tie_ldx(foo) and %tie_add(foo) are not actual arguments for the instructions, but get converted into R_SPARC_TLS_IE_LDX/ADD relocations so the linker can identify the instructions in the sequence. However, a local exec sequence looks something like: sethi %tle_hix22(foo), %r1 xor %r1, %tle_lox10(foo), %r1 add %g7, %r1, %r1 and so %r1 is a signed 32-bit value. The linker can relax the initial exec sequence into the local exec sequence if it knows that foo is defined in the executable, and so gcc cannot assume that %r1 in the first case is a 32-bit quantity. 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 defining module's block to load a signed 32-bit value, but since it's marked as SI I assume a spill/reload will truncate the top 32 bits and thus lose any sign extension if it's negative, breaking it even with linker relaxation disabled.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
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 64-bit reg are undefined. So it does not appear to be correct for > SPARC either. Hence it appears that we need the same change for SPARC, and > that breaks the fix for PR59461. I think we need to revisit that. If you > have a paradoxical subreg of a reg, then it is only OK to use LOAD_EXTEND_OP > if you know the value in the reg came from a memory location. This check is > missing. > > If we are going to change the meaning of WORD_REGISTER_OPERATIONS, then we > need a change to the docs also. But I'm not convinced that this needs to > change. The difference is that SPARC has instructions to operate on 32-bit values in the 64-bit registers, like many other RISC architectures, including for things like shifts.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
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 disagree, WORD_REGISTER_OPERATIONS means that the (general) registers are > always modified as a whole by arithmetic operations. If that isn't the > case, then the macro should not be defined (e.g Aarch64 doesn't define it > although ARM does). Ok, fair enough, the docs are all I have to go on, as opposed to your existing knowledge of the codebase. > > This regression was introduced in r242326, which added the `&& !REG_P > > (SUBREG_REG (x))` to nonzero_bits1, thereby assuming that the high bits were > > defined, which is a target-specific assumption. > > No, see above, WORD_REGISTER_OPERATIONS means that the bits are defined. Well, yes and no, then. The regression on ia64 *was* introduced then, but only because of what you believe to be the existing incorrect use of WORD_REGISTER_OPERATIONS. I doubt there's much more I can contribute to this bug myself as I lack the knowledge of what is meant to happen deep inside GCC, but certainly I can confirm that the issue is with nonzero_bits returning only the lower 32 bits due to that if condition.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 James Clarke changed: What|Removed |Added Attachment #42961|0 |1 is obsolete|| --- Comment #13 from James Clarke --- Created attachment 42963 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42963=edit Higher bits of paradoxical subregs on ia64 are undefined 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. This regression was introduced in r242326, which added the `&& !REG_P (SUBREG_REG (x))` to nonzero_bits1, thereby assuming that the high bits were defined, which is a target-specific assumption. The attached patch therefore encodes this assumption in whether WORD_REGISTER_OPERATIONS is positive or negative; I haven't modified any documentation as there's no point doing that if people disagree with this approach.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
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.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 James Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #3 from James Clarke --- Created attachment 42960 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42960=edit rotate test case Jason (in Cc) sent me this example, which is similar. What's basically happening, as far as I understand, is that, since the source for the "extr.u" is being used for a 32-bit integer, it knows that the high 32 bits of the register should be 0, and thus it can always increase the length parameter to 32, but the earlier rotate (which is implemented with a mix4.r, i.e. copy lower 32 bits to upper 32 bits, and a shr.u) doesn't clear out the high 32 bits.
[Bug target/83368] alloca after setjmp breaks PIC base reg
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 > > arguments and just reciting that "setjmp must save call-saved registers", > > which would be nice if it were true, but that's not what actually happens, > > and GCC already tries to handle this; it just misses a case on SPARC. > > OK, let's see it the other way around: how does it work on other > architectures? Does GCC save and restore the PIC register or it is > preserved through the call to setjmp? It's true that, as far as I'm aware, no other architecture has this issue, as either the PIC register is caller-saved, or it gets saved by setjmp. However the original SPARC library authors clearly thought of this and decided it was the responsibility of the compiler to not rely on input or local registers being preserved given their explicit note in SCD, so whether or not you believe that this was a good idea, that's what they chose and what we currently have, and GCC is not adhering to that. Sure, it would be nice if the registers were saved by setjmp, but it's documented behaviour and thus not a bug as such in glibc nor Solaris's libc.
[Bug target/83368] alloca after setjmp breaks PIC base reg
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
> > > yours.
> >
> > Yes, I know that.
>
> OK, at least something we agree on. :-)
>
> > But GCC doesn't rely on that for *any other use* of the input and local
> > registers; they are spilled to the stack and reloaded after the setjmp when
> > needed.
>
> No, that's also wrong, try:
>
> int main(void)
> {
> register int i asm ("l0") = 1;
> setjmp(jb);
> printf("%d\n", i);
>
> if (c < 10)
> bar();
>
> return 0;
> }
>
> main:
> save%sp, -176, %sp
> mov 1, %l0
> sethi %hi(jb), %g1
> or %g1, %lo(jb), %o0
> call_setjmp, 0
> nop
> mov %l0, %g1
> sra %g1, 0, %g1
> mov %g1, %o1
> sethi %hi(.LC0), %g1
> or %g1, %lo(.LC0), %o0
> callprintf, 0
> nop
>
> GCC really expects all call-saved registers to be preserved.
That's a bad example; if you change "l0" to "o5", GCC will still let you do it,
and doesn't spill the value anywhere either. GCC assumes if you give a
register, you know that the register really won't be clobbered by any function
calls in between. Yes you might not be aware of the issue with setjmp in this
instance, but that's your problem if you write this code.
> > Also the fact that alloca clobbers the stack pointer
> > is an implementation detail; for example, LLVM allocates all the space up
> > front in the function prologue in this case, which means it would not run
> > into this issue (and in fact it also spills its PIC base register).
>
> This should also work with libc's alloca and it clobbers the stack pointer.
Ok, true.
[Bug target/83368] alloca after setjmp breaks PIC base reg
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 registers either, so it's not glibc-specific.
> >
> > 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
> > yours.
>
> Yes, I know that. But GCC doesn't rely on that for *any other use* of the
> input and local registers; they are spilled to the stack and reloaded after
> the setjmp when needed. Also the fact that alloca clobbers the stack pointer
> is an implementation detail; for example, LLVM allocates all the space up
> front in the function prologue in this case, which means it would not run
> into this issue (and in fact it also spills its PIC base register).
(In reply to Eric Botcazou from comment #8)
> > You already have code in sched-deps.c to deal with setjmp potentially not
> > saving registers it should across all architectures:
> >
> > if (find_reg_note (insn, REG_SETJMP, NULL))
> > {
> > /* This is setjmp. Assume that all registers, not just
> > hard registers, may be clobbered by this call. */
> > reg_pending_barrier = MOVE_BARRIER;
> > }
>
> GCC expects all call-saved registers to be preserved by setjmp/longjmp
> though and I think that's what is implemented in glibc for other
> architectures.
No, it doesn't. Try it yourself. Make a local variable live across a setjmp
call, and even under -O3 you will see it spilled to the stack and reloaded
after setjmp returns.
> > Why is it so hard to fix this bug? It's a very simple problem that only
> > affects %l7; all it needs is for it to be spilled and reloaded.
>
> Because it's a call-saved register.
Not for setjmp, but this is where we disagree.
> > This is breaking real-world code that works on every other architecture I
> > have
> > tried it on, and telling people to use non-portable built-in functions
> > isn't
> > going to necessarily be well-received.
>
> Then you need to convince someone to fix glibc and make setjmp/longjmp
> preserve call-saved registers even if the stack pointer is subsequently
> clobbered. Or maybe just the PIC register, but I think it's only the tip of
> the iceberg.
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
arguments and just reciting that "setjmp must save call-saved registers", which
would be nice if it were true, but that's not what actually happens, and GCC
already tries to handle this; it just misses a case on SPARC.
[Bug target/83368] alloca after setjmp breaks PIC base reg
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. > > 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 > yours. Yes, I know that. But GCC doesn't rely on that for *any other use* of the input and local registers; they are spilled to the stack and reloaded after the setjmp when needed. Also the fact that alloca clobbers the stack pointer is an implementation detail; for example, LLVM allocates all the space up front in the function prologue in this case, which means it would not run into this issue (and in fact it also spills its PIC base register).
[Bug target/83368] alloca after setjmp breaks PIC base reg
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.
[Bug target/83368] alloca after setjmp breaks PIC base reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83368
James Clarke changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFIX |---
--- Comment #5 from James Clarke ---
(In reply to Eric Botcazou from comment #4)
> > Therefore, I am of the view that this should be reopened as a bug in GCC.
> > GCC already spills local variables live across a setjmp to the stack (as it
> > can't use input or local registers due to the above note); it should be
> > doing the same for %l7.
>
> No, setjmp/longjmp must preserve the call-saved registers and it does in
> almost all cases, both on Linux and Solaris.
You already have code in sched-deps.c to deal with setjmp potentially not
saving registers it should across all architectures:
if (find_reg_note (insn, REG_SETJMP, NULL))
{
/* This is setjmp. Assume that all registers, not just
hard registers, may be clobbered by this call. */
reg_pending_barrier = MOVE_BARRIER;
}
Why is it so hard to fix this bug? It's a very simple problem that only affects
%l7; all it needs is for it to be spilled and reloaded. This is breaking
real-world code that works on every other architecture I have tried it on, and
telling people to use non-portable built-in functions isn't going to
necessarily be well-received.
[Bug target/83368] alloca after setjmp breaks PIC base reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83368 James Clarke changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #3 from James Clarke --- (In reply to Eric Botcazou from comment #2) > It's a glibc bug, setjmp doesn't preserve %l7. I filed [1], but having gone away and thought about this, I don't think it is. SPARC Compliance Definition 2.4.1 specifically calls this out (page 47 or 3P-11 in my PDF), with: "There are some routines, like setjmp(), sigsetjmp(), and vfork(), that require the caller assume the registers %l0 through %l7, and %i0 through %i5 are volatile across the call." Therefore, I am of the view that this should be reopened as a bug in GCC. GCC already spills local variables live across a setjmp to the stack (as it can't use input or local registers due to the above note); it should be doing the same for %l7. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=22604
[Bug go/83308] Missing platform definitions for SH in libgo
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 the header)
[Bug target/83368] New: alloca after setjmp breaks PIC base reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83368 Bug ID: 83368 Summary: alloca after setjmp breaks PIC base reg Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target 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=42837=edit Testcase If alloca is used after setjmp in the same function, upon longjmp'ing back, %l7 no longer has the correct value, but the generated code assumes it does, and things break, typically by segfaulting (as in the attached example). It seems this possibility is intended to be covered in sparc.md, as builtin_setjmp_receiver has a call to load_got_register if flag_pic is true. However, for whatever reason this doesn't seem to actually make a difference.
[Bug go/83314] gccgo: Compiled binaries panic with "mmap errno 9" on m68k
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: memstats.heap_live not aligned to 8 bytes heap_live is a uint64, which is only 2-byte aligned on m68k. Either m68k needs to force stronger alignment here, or the assertion needs dropping for m68k. > > goroutine 16 [running, locked to thread]: > runtime.dopanic > ../../../src/libgo/go/runtime/panic.go:832 > runtime.throw > ../../../src/libgo/go/runtime/panic.go:758 > futexwakeup addr=0xc111aa0e returned -1 Futexes must always be 4-byte aligned (kernel requirement), but on m68k ints only need 2-byte alignment. > fatal error: unexpected signal during runtime execution > panic during panic > [signal SIGSEGV: segmentation violation code=1 addr=4102 pc=3233247334] > futexwakeup addr=0xc111aa0e returned -1 > fatal error: unexpected signal during runtime execution > stack trace unavailable > root@elgar:~> > > On a sidenote: That's probably the first time Go is running on an Amiga!
[Bug go/83314] gccgo: Compiled binaries panic with "mmap errno 9" on m68k
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 error_callback in
libgo/runtime/go-caller{,s}.c, both of which call backtrace things.
[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'
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.
[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'
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 smaller if you let it do crazy enum-to-pointer casts and various other warning-inducing things, but this builds with -Wall -Werror.
[Bug target/83100] [8 Regression] powerpc: internal compiler error: in get_variable_section, at varasm.c:1150 with -fdata-sections
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 link the two together and > the value of the variable would be 5. But with the changes, that is no > longer the case (if it doesn't ICE), the variable is put into .rodata > section. Yes, and in fact I saw this behaviour and got pointed at that commit about a week ago, as I was seeing duplicate symbol errors when linking another piece of software. As it happens, the declaration in the header in that case should have been extern, but the change in GCC's behaviour still made me uneasy.
[Bug target/83100] [8 Regression] powerpc: internal compiler error: in get_variable_section, at varasm.c:1150 with -fdata-sections
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.
[Bug c/83100] [8 Regression] powerpc: internal compiler error: in get_variable_section, at varasm.c:1150 with -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100 James Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #1 from James Clarke --- This is due to the combination of `-O2`, `-fdata-sections` and constant implicitly-zeroed global variables (I assume as a result of https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01591.html): (experimental_powerpc-dchroot)jrtc27@partch:~$ cat pkix_errpaths.i const int a; (experimental_powerpc-dchroot)jrtc27@partch:~$ /usr/bin/powerpc-linux-gnu-gcc-8 -o pkix_errpaths.s -S -O2 -fdata-sections pkix_errpaths.i pkix_errpaths.i:1:1: internal compiler error: in get_variable_section, at varasm.c:1150 const int a; ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions.
[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010 James Clarke changed: What|Removed |Added CC||glaubitz at physik dot fu-berlin.d ||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 "8548". Seems like this bug should at least be confirmed. [0] https://buildd.debian.org/status/fetch.php?pkg=mptp=powerpcspe=0.2.2-1=1490178731=0
[Bug target/79353] [7 regression] ICE in curr_insn_transform, at lra-constraints.c:3773
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 found): /home/jrtc27/src/gcc/obj/./gcc/xgcc -B/home/jrtc27/src/gcc/obj/./gcc/ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -B/usr/local/sparc64-unknown-linux-gnu/lib/ -m32 -fPIC -O2 -c parfor.i -o /tmp/parfor.o
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
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?
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
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 fields.
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
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 aligned. This continues with "ncgocall" and "ncgo" being 2-byte aligned, and then the "park" field will also be 2-byte aligned only. Is there a way to tell gcngo that the "note" struct (and in theory the "mutex" struct too, since that will be a futex, and I don't know if anything embeds it incorrectly-aligned) should be 4-byte aligned, i.e. an equivalent of __attribute__((aligned(4)))?
[Bug sanitizer/78992] New: Incorrect sigaction definition on 32-bit sparc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78992 Bug ID: 78992 Summary: Incorrect sigaction definition on 32-bit sparc Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: 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 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40460=edit Patch forwarded upstream The attached patch is needed to fix the sanitizer build on 32-bit sparc. Forwarded upstream to https://reviews.llvm.org/D28309.
[Bug target/77759] New: internal compiler error: in function_arg_record_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77759
Bug ID: 77759
Summary: internal compiler error: in function_arg_record_value
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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, int slot4, int slot5,
struct pair_empty pair) {
}
int main(int argc, char **argv) {
struct pair_empty pair;
f(0, 0, 0, 0, 0, 0, pair);
return 0;
}
With g++ 6.2.0 in Debian unstable:
main.cpp: In function ‘void f(int, int, int, int, int, int, pair_empty)’:
main.cpp:8:6: internal compiler error: in function_arg_record_value, at
config/sparc/sparc.c:6729
void f(int slot0, int slot1, int slot2, int slot3, int slot4, int slot5,
struct pair_empty pair) {
^
0xa3bf7f function_arg_record_value
../../src/gcc/config/sparc/sparc.c:6729
0xa3c5bb sparc_function_arg_1
../../src/gcc/config/sparc/sparc.c:6879
0x58ea7b assign_parm_find_entry_rtl
../../src/gcc/function.c:2534
0x58ea7b assign_parms
../../src/gcc/function.c:3723
0x590537 expand_function_start(tree_node*)
../../src/gcc/function.c:5207
0x465243 execute
../../src/gcc/cfgexpand.c:6225
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
With g++ 7.0.0 20160927 from master (7469707ce8cf1d74002118cdca992650998d4acd):
main.cpp: In function ‘void f(int, int, int, int, int, int, pair_empty)’:
main.cpp:8:6: internal compiler error: in function_arg_record_value, at
config/sparc/sparc.c:6739
void f(int slot0, int slot1, int slot2, int slot3, int slot4, int slot5,
struct pair_empty pair) {
^
0xdd8f4f function_arg_record_value
../../upstream/gcc/config/sparc/sparc.c:6739
0xdd9dbb sparc_function_arg_1
../../upstream/gcc/config/sparc/sparc.c:6889
0x79fe93 assign_parm_find_entry_rtl
../../upstream/gcc/function.c:2532
0x79fe93 assign_parms
../../upstream/gcc/function.c:3725
0x7a2ae3 expand_function_start(tree_node*)
../../upstream/gcc/function.c:5209
0x61c5cf execute
../../upstream/gcc/cfgexpand.c:6256
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
function_arg_slotno gets to the MODE_RANDOM case, and follows the
`TARGET_ARCH64 && type` branch. traverse_record_type walks over the the
pair_empty type, but as there are no actual fields (only other records which
are traversed), classify_registers is never called, so data remains { false,
false, false }. Thus, neither of the conditions for returning -1 for records
are satisfied, and so slotno (which is 6) is returned.
Then, in function_arg_record_value, it takes the `nregs == 0` branch (since
traverse_record_type never calls count_registers for the same reason as above),
tries nregs = 1, but then hits the `nregs + slotno > SPARC_INT_ARG_MAX` branch,
and so nregs gets set to `SPARC_INT_ARG_MAX - slotno`, which is 0 in this case
(and would be negative if more ints were added to f to fill up the slots).
Then, the gcc_assert(nregs > 0) fails and gives the above backtrace.
The following patch fixes this; thoughts?
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -6450,10 +6450,9 @@ function_arg_slotno (const struct sparc_args *cum,
machine_mode mode,
&& slotno >= SPARC_FP_ARG_MAX - 1)
return -1;
- /* If there are only int args and all int slots are filled,
-then must pass on stack. */
+ /* If there are only int args or this is an empty record type,
+and all int slots are filled, then must pass on stack. */
if (!data.fp_regs
- && data.int_regs
&& slotno >= SPARC_INT_ARG_MAX)
return -1;
}
[Bug preprocessor/71183] [7 Regression] gcc -E always gives __DATE__ and __TIME__ as Jan 1 1970 00:00:00
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 for my comment. I'm sure there are valid technical reasons for why the SOURCE_DATE_EPOCH logic is outside of libcpp that I'm not aware of.
[Bug preprocessor/71183] [7 Regression] gcc -E always gives __DATE__ and __TIME__ as Jan 1 1970 00:00:00
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’:
:1:14: warning: implicit declaration of function ‘puts’
[-Wimplicit-function-declaration]
$ ./a.out
Jan 2 1970
$ echo 'int main() { puts(__DATE__); }' | SOURCE_DATE_EPOCH=86400 gcc -E -
# 1 ""
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 ""
int main() { puts("Jun 12 2016"); }
I guess I should file another bug report for this?
[Bug preprocessor/71183] [7 Regression] gcc -E always gives __DATE__ and __TIME__ as Jan 1 1970 00:00:00
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
[Bug preprocessor/71183] [7 Regression] gcc -E always gives __DATE__ and __TIME__ as Jan 1 1970 00:00:00
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/ > sys-root/usr/include/stdc-predef.h" 1 3 4 > # 32 "" 2 > # 1 "" > "May 18 2016" "14:38:12" My bad; Debian backported the commit to their gcc-6.
[Bug preprocessor/71183] New: gcc -E always gives __DATE__ and __TIME__ as Jan 1 1970 00:00:00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71183 Bug ID: 71183 Summary: gcc -E always gives __DATE__ and __TIME__ as Jan 1 1970 00:00:00 Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal 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 on its own, as pfile->source_date_epoch is only initialised in c_lex_with_flags, so pfile->source_date_epoch is 0 when _cpp_builtin_macro_text is called, rather than -1 (telling it to use the current time) or the true value of SOURCE_DATE_EPOCH. $ echo '__DATE__ __TIME__' | gcc -E - # 1 "" # 1 "" # 1 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "" 2 # 1 "" "Jan 1 1970" "00:00:00"
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
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… #if SANITIZER_MAC ( !defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T) and # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T rather than just… #if SANITIZER_MAC __DARWIN_64_BIT_INO_T and # if __DARWIN_64_BIT_INO_T in their patch for gcc49… https://trac.macports.org/browser/trunk/dports/lang/gcc49/files/patch-10.10. diff Should we be doing the same? That's because they're using my original patch from this bug report (https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180), which itself is based off Ilya Mikhaltsou's patch (https://gcc.gnu.org/bugzilla/attachment.cgi?id=32949, also from this bug report). I don't know why Ilya decided to default to a 64-bit dirent struct, as the documentation clearly states that it is only 64-bit when the _DARWIN_FEATURE_64_BIT_INODE macro is defined (https://developer.apple.com/library/mac/documentation/Darwin/Reference/ ManPages/man5/dir.5.html#//apple_ref/doc/man/5/dir). This is different from __DARWIN_64_BIT_INO_T, but you can see in sys/cdefs.h that _DARWIN_FEATURE_64_BIT_INODE is only defined (to 1) when __DARWIN_64_BIT_INO_T is true. Please note that I have updated my patch to use the public _DARWIN_FEATURE_64_BIT_INODE macro, and to check whether it is defined rather than its value (seeing as the documentation only refers to its definition, not its value). The updated patches are at https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02427.html. I wasn't doing much thinking on the topic, I've simply made the minimal necessary changes to a) compile on 10.10 and b) to work exactly the same as before on previous versions. If you think it is redundant, there are no objective reasons for keeping it that way. I thought that was probably the case. I believe how it is now in my patch is correct, but I'm open to being challenged on it!
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
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) can completely substitute for… # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T as sys/cdefs.h shows… /* * _DARWIN_FEATURE_64_BIT_INODE indicates that the ino_t type is 64-bit, and * structures modified for 64-bit inodes (like struct stat) will be used. */ #if __DARWIN_64_BIT_INO_T #define _DARWIN_FEATURE_64_BIT_INODE1 #endif which means that… # if defined(_DARWIN_FEATURE_64_BIT_INODE) is effectively only # if __DARWIN_64_BIT_INO_T as the definition of _DARWIN_FEATURE_64_BIT_INODE only checks if __DARWIN_64_BIT_INO_T is set and not if it is undefined as well. I was able to perform a complete clean bootstrap on my system, so I'm curious as to what error(s) you got? I agree, the two are not equivalent, but the first one (!defined(X) || X) is wrong in my opinion, as if the macro is not defined, the documentation for dir(5) states that the 32-bit versions are used.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
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
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
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) and # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T rather than just… #if SANITIZER_MAC __DARWIN_64_BIT_INO_T and # if __DARWIN_64_BIT_INO_T in their patch for gcc49… https://trac.macports.org/browser/trunk/dports/lang/gcc49/files/patch-10.10. diff Should we be doing the same? That's because they're using my original patch from this bug report (https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180), which itself is based off Ilya Mikhaltsou's patch (https://gcc.gnu.org/bugzilla/attachment.cgi?id=32949, also from this bug report). I don't know why Ilya decided to default to a 64-bit dirent struct, as the documentation clearly states that it is only 64-bit when the _DARWIN_FEATURE_64_BIT_INODE macro is defined (https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man5/dir.5.html#//apple_ref/doc/man/5/dir). This is different from __DARWIN_64_BIT_INO_T, but you can see in sys/cdefs.h that _DARWIN_FEATURE_64_BIT_INODE is only defined (to 1) when __DARWIN_64_BIT_INO_T is true. Please note that I have updated my patch to use the public _DARWIN_FEATURE_64_BIT_INODE macro, and to check whether it is defined rather than its value (seeing as the documentation only refers to its definition, not its value). The updated patches are at https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02427.html.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
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 on this. Could you possibly do that? Would massively appreciate it. More details are here: https://gcc.gnu.org/contribute.html Working on it now. Need to clean it up, separate the diffs, add relevant test cases and check it all still compiles and passes the tests before submitting though. And of course doing a full bootstrap (a required test) takes quite a while. Will post an update when I've submitted the patches.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
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.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
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/attachment.cgi?id=33180; sha1 def0cb036a255175db86f106e2bb9dd66d19b702 end But i don't know WHERE to add that in the formula when i use brew edit gcc... Any help? Thanks! I included the patch directly in the contents of the formula (see https://github.com/jrtc27/homebrew/commit/a94f371cb24fb68e2f55e701eb2a25a56253b726), but it should also work if you add the patch do ... end block just before the fails_with :gcc_4_0 line (though I haven't tried that).
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
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 for Availability.h which was only needed in DP 3 and below.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
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 dot com --- Comment #14 from James Clarke jrtc27 at jrtc27 dot com --- The issue with Availability.h has been fixed as of Developer Preview 4, however `all-stage1-target-libsanitizer` still fails with Error 2.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
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. I should note that I am building 4.8.3 with Homebrew.
