Re: Release notes for GCC 7?
On Tue, Aug 23, 2016 at 10:19 PM, Gerald Pfeifer wrote: > On Tue, 23 Aug 2016, Joseph Myers wrote: >> Is there a reason there's no changes.html for GCC 7 at this point? > > None, apart from me missing it and http://gcc.gnu.org/releasing.html > as well. We've been creating those lazily over the last decade. We can change that, an entry for releasing.html is appreciated then so we don't forget. Richard. > Segher beat me to it now (I was planning to do it tonight); let me > know whether there is anything else I can help with. > >> I'd presumed that when adding new features one should also write release >> notes for them (so, I should be writing release notes for _FloatN / >> _FloatNx) > > Yes, absolutely! That is the practice I always recommend. > > Gerald
Re: How do you emit RTL for a jump to a mem/symbol instead of an asm label?
On 08/21/2016 05:59 PM, Segher Boessenkool wrote:
On Sun, Aug 21, 2016 at 02:04:49PM -0500, Daniel Santos wrote:
Thanks for the response! Perhaps an UNSPEC insn is needed here because I
have work to do on other passes too. For example, when the debug info is
created, it's giving the wrong location (on the stack) for where some
registers were saved.
Don't worry about this until you have the basics working. It is fiddly
work but not really hard.
But my primary question is about how to generate a jump at the end of
You could have a look at the rs6000 patterns (in rs6000.md)
"*return_and_restore_gpregs__r11" and the function that creates
such patterns, "rs6000_emit_savres_rtx" in (rs6000.c). This does a whole
bunch more than you need, but maybe you'll get the idea. Some points:
- The pattern should describe all it does (restore what regs, etc.), not
just the jump;
- You should set a JUMP_LABEL (to ret_rtx) on the jump, and it should _be_
a jump_insn;
- You want a separate pattern in the machine description for this.
HTH,
Segher
OK, so i386 doesn't have a generic "any_parallel_operand" predicate and
I assume I might be shot if I tried to add one, so (just focusing on the
epilogue for now) I've added one called for
"restore_multiple_and_return" that snoops through the vector and
verifies that it's what is expected. Then I've added a pattern for it
and it's matching on the below RTL and emitting the jump I want! :) My
question now is can you see anything that I'm missing or doing wrong in
this? I'm telling what registers I'm restoring, where they are read from
and what changes I'm making to the stack pointer.
(jump_insn 27 26 28 2 (parallel [
(simple_return)
(use (symbol_ref:DI ("__msabi_restore_odd")))
(set (reg:DI 4 si)
(mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 0 [0])) [2 S8 A8]))
(set (reg:V4SF 27 xmm6)
(mem/c:V4SF (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [2 S16 A8]))
(set (reg:V4SF 28 xmm7)
(mem/c:V4SF (plus:DI (reg/f:DI 7 sp)
(const_int 24 [0x18])) [2 S16 A8]))
(set (reg:V4SF 45 xmm8)
(mem/c:V4SF (plus:DI (reg/f:DI 7 sp)
(const_int 40 [0x28])) [2 S16 A8]))
(set (reg:V4SF 46 xmm9)
(mem/c:V4SF (plus:DI (reg/f:DI 7 sp)
(const_int 56 [0x38])) [2 S16 A8]))
(set (reg:V4SF 47 xmm10)
(mem/c:V4SF (plus:DI (reg/f:DI 7 sp)
(const_int 72 [0x48])) [2 S16 A8]))
(set (reg:V4SF 48 xmm11)
(mem/c:V4SF (plus:DI (reg/f:DI 7 sp)
(const_int 88 [0x58])) [2 S16 A8]))
(set (reg:V4SF 49 xmm12)
(mem/c:V4SF (plus:DI (reg/f:DI 7 sp)
(const_int 104 [0x68])) [2 S16 A8]))
(set (reg:V4SF 50 xmm13)
(mem/c:V4SF (plus:DI (reg/f:DI 7 sp)
(const_int 120 [0x78])) [2 S16 A8]))
(set (reg:V4SF 51 xmm14)
(mem/c:V4SF (plus:DI (reg/f:DI 7 sp)
(const_int 136 [0x88])) [2 S16 A8]))
(set (reg:V4SF 52 xmm15)
(mem/c:V4SF (plus:DI (reg/f:DI 7 sp)
(const_int 152 [0x98])) [2 S16 A8]))
(set (reg:DI 5 di)
(mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 168 [0xa8])) [2 S8 A8]))
(set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int 176 [0xb0])))
]) ../a.c:9 -1
(expr_list:REG_CFA_ADJUST_CFA (set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int 176 [0xb0])))
(nil))
-> simple_return)
This is the actual asm of the stub:
__msabi_restore_odd:
pop%rsi
movaps (%rsp),%xmm6
movaps 0x10(%rsp),%xmm7
movaps 0x20(%rsp),%xmm8
movaps 0x30(%rsp),%xmm9
movaps 0x40(%rsp),%xmm10
movaps 0x50(%rsp),%xmm11
movaps 0x60(%rsp),%xmm12
movaps 0x70(%rsp),%xmm13
movaps 0x80(%rsp),%xmm14
movaps 0x90(%rsp),%xmm15
add$0xa0,%rsp
pop%rdi
ret
Thanks again for all your help!
Daniel
August 2016 GNU Toolchain Update
Hi Guys,
It has been a long time since my last post, so there is lots to tell
you about. First of all there have been major releases of most of
the tools:
GCC 6.2 is here. This is mostly a bug-fix release over gcc 6.1 of
course, but it does also include a few enhancements for the SPARC
target:
Support for --with-cpu-32 and --with-cpu-64 configure
options has been added on bi-architecture platforms.
Support for the SPARC M7 (Niagara 7) processor has
been added.
Support for the VIS 4.0 instruction set has been added.
Binutils 2.27 has now been released. In addition to enhancements
mentioned in previous postings, this release also includes:
A configure option --enable-relro={yes|no} to decide
whether -z relro should be the default behaviour for
the linker in ELF based targets. If this configure
option is not specified then relro will be enabled
automatically for all Linux based targets except FRV,
HPPA, IA64 and MIPS.
Linux/x86 targets now default to enabling the compression
of debug sections. This change can be reverted by using
the --enable-compressed-debug-sections=no configure option.
The assembler now supports a --no-pad-sections command
line option to prevent it from padding the end of each
section up to its alignment boundary. This can be useful
on systems with very tight memory constraints.
The ARC port of gas now accepts a --with-cpu=TYPE
configure option to specify the default cpu type.
GDB 7.12 is out. This release includes:
GDB and GDBserver are now built with a C++ compiler by default.
The configure option --disable-build-with-cxx can be used to
build with a C compiler instead, although this option will soon
be deprecated.
GDB now supports a negative repeat count in the 'x' command to
examine memory *backwards* from the given address.
GDB now supports a new mechanism that allows front-ends to provide
fully featured GDB console views, as a better alternative to
building such views on top of the "-interpreter-exec console"
command. Front-ends can now start GDB in the traditional
command-line mode running in an embedded terminal emulator
widget, and create a separate MI interpreter running on a
specified i/o device. In this way, GDB handles line editing,
history, tab completion, etc. in the console all by itself, and
the GUI uses the separate MI interpreter for its own control and
synchronization, invisible to the command line.
In addition the development versions of these tools continue to add
new features and abilities. For example:
G++ has a new command line option -fconstexpr-loop-limit= which
sets the maximum number of iterations for a loop in C++14
constexpr functions. A limit is needed to detect infinite loops
during constant expression evaluation.
G++ now also supports -fstrong-eval-order which forces the
evaluation of member access, array subscripting, and shift
expressions in left-to-right order, and assignments in
right-to-left order, as adopted for C++17. This option is enabled
by default when -std=c++1z is used.
The compiler now supports a new command line option:
-fdiagnostics-parseable-fixits
This option tells the compiler to extend the diagnostic messages
that it displays by adding an extra line. This line is intended
to be a machine parseable hint for consumption by an IDE. The
hint starts with the text "fix-it:" and the rest gives information
about the source code location involved. For example:
fix-it:"test.c":{45:3-45:21}:"function_foo"
The compiler now supports a new optimization: -fcode-hoisting
This tries to move the evaluation of expressions executed on all
paths to as early as possible in the function. This is especially
useful as a code size optimization, but it often helps for code
speed as well.
GCC now has support for the _Float and _Floatx types as
defined by the ISO/IEC TS 18661-3:2015 standard. The actual set
of types supported depends upon the target architecture however.
So for example the _Float128 type is supported on all systems
where __float128 is supported or where long double has the IEEE
binary128 format. The _Float64x type is supported on all systems
where __float128 is supported. The _Float32 type is supported on
all systems supporting IEEE binary32. The _Float64 and Float32x
types are supported on all systems supporting IEEE binary64.
Currently there are no target architectures that would support
the _Float16 or _Float128x types.
The ARM port of the toolchain now supports the ARMv8.2-A
architecture extensions. In addition revisions older than ARMv4t
are now deprecated.
The PowerPC port of the compiler now supports the use of built-in
functions that allo
https://gcc.gnu.org/gcc-6/
Dear GCC Web team I just wanted to let you know that on https://gcc.gnu.org/gcc-6/ the link to the gcc-6.2 documentation links to the gcc-6.1 documentation Cheers Jérôme -- Dr. Jérôme Kunegis Institute for Web Science and Technologies University of Koblenz-Landau http://userpages.uni-koblenz.de/~kunegis/
Re: https://gcc.gnu.org/gcc-6/
On Wed, Aug 24, 2016 at 1:31 PM, Jérôme Kunegis wrote: > Dear GCC Web team > > > I just wanted to let you know that on > > https://gcc.gnu.org/gcc-6/ > > the link to the gcc-6.2 documentation links to the gcc-6.1 documentation Thanks, fixed. Richard. > > Cheers > > Jérôme > > > -- > Dr. Jérôme Kunegis > Institute for Web Science and Technologies > University of Koblenz-Landau > http://userpages.uni-koblenz.de/~kunegis/ >
Re: Replacement for the .stabs directive
On 08/19/2016 12:55 PM, Umesh Kalappa via llvm-dev wrote:
We have the legacy code ,that uses the .stabs directive quiet often
in the source code like
.stabs "symbol_name", 100, 0, 0, 0 + .label_one f;
.label_one
stmt
and ,the above code is wrapped with the inline asm in the c source file .
Presumably the ".label_one f" is actually "1f" and the ".label_one" is
"1:". That would make more sense, as this is a use of the GNU as local
label feature.
Unfortunately, there is no easy to do this in dwarf, as dwarf debug info
is split across multiple sections and encoded. Maybe this could work if
you handled it like a comdat symbol, but that would be inconvenient, and
might not even work. This seems like a option not worth pursuing.
The fact that this worked for stabs is more accident by design. The
code never should have been written this way in the first place.
You can make the association between a symbol name and an address by
using an equivalence. E.g. you could do
asm ("symbol_name = 1f");
but this puts the symbol_name in the symbol table, which works only if
symbol_name is unique or maybe unique within its scope if function
local. If the name was unique, you probably wouldn't have used the ugly
stabs trick in the first place, so this might not work. If the symbol
names aren't unique, maybe you can change the code to make them unique?
Using an equivalence gives the same effective result as using
symbol_name: stmt
Jim
PS Cross posting like this is discouraged. I would suggest just asking
assembler questions on the binutils list.
GNU indirect functions vs. symbol visibility
Discussion started here: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01678.html On Wed, Aug 24, 2016 at 08:51:16PM +0300, Alexander Monakov wrote: > On Wed, 24 Aug 2016, Alan Modra wrote: > > Given a hidden visibility function declaration, the toolchain can say > > that the function is local to the module. This generally means that a > > call to the function can be direct, ie. doesn't need to go via the PLT > > even in a shared library. However, ifunc breaks this promise. GNU > > indirect functions may resolve non-locally, and are implemented by > > always using a PLT call. > > > > This causes trouble for targets like ppc32 where the -msecure-plt PIC > > PLT call stub needs a valid GOT pointer. Any call that potentially > > might be to an ifunc therefore requires a GOT pointer, and can't be a > > sibling call (because the GOT pointer on ppc32 is a caller saved reg). > > The same issue exists on 32-bit x86: PLT calls require that %ebx holds the > address of GOT (and the sibcall issue arises as well). I've just confirmed > using a simple testcase that the scenario you describe leads to a runtime > error > on i386, and even LD_BIND_NOW=1 doesn't help, as it doesn't trigger early > resolution of ifuncs. I'm happy to see that ppc32 isn't alone. ;-) > > So unless we require that all ifuncs are declared as ifunc, > > (note, that would be impossible with today's GCC because the ifunc attribute > requires designating the resolver, and the resolver cannot be extern -- so > ultimately you cannot declare an extern-ifunc symbol) > > > it seems that ppc32 can't assume extern or weak functions are local. > > It doesn't seem nice to penalize all normal calls due to this issue. I whole-heartedly agree. > I think a > solution without this cost is possible: have ld synthesize a forwarder > function > when it sees a non-plt call to an ifunc symbol. The forwarder can push the GOT > register, load the GOT address, call the ifunc symbol, pop the GOT register > and > return. Does this sound right? I'd considered this idea too. It should work, but isn't ideal. The resulting code will be slower than if the ifuncs were simply not declared hidden. The idea also isn't quite as simple to implement as it might seem, since frame unwinding must work through any such stub, and gdb probably would need to know about them too. I prefer to simply make ld error on seeing calls to ifuncs where it detects that such a stub would be needed. ppc32 GNU ld should do that reliably as of git commit 888a7fc3. glibc people: As the main user of ifuncs, how do you feel about not declaring functions hidden that are implemented in glibc by ifuncs? It's fine to make them hidden via a version script, or even define them as hidden (which requires just the rs6000_elf_encode_section_info part of my gcc patch to make ppc32 behave). -- Alan Modra Australia Development Lab, IBM
Re: Help with lra
On 10-Aug-16 08:41 PM, Vladimir N Makarov wrote: As for memory constraint you should not to return true for a pseudo. Reload/LRA can figure out how to match a spilled pseudo with memory (but this constraint should be define_memory_constraint, i saw mistakes when people used different forms of constraints for memory and had problems). For its own reasons, xtensa returns true for a pseudo during reload for a memory type constraint that shouldn't use the constant pool but doesn't mark it as a memory constraint. What will that architecture lose because of that and will it work for lra?
