Woo hoo!
Looks like I forgot to add the details of -mcall-ms2sysv-xlogues to the
changes (https://gcc.gnu.org/gcc-8/changes.html). Is it too late to
change that? At least this only really affects one project (that I'm
aware of). I've got some improvements to it for GCC 9 that I'll get
together
On 08/15/2017 06:18 AM, Richard Biener wrote:
> On Mon, Aug 14, 2017 at 5:23 PM, H.J. Lu wrote:
>> For GCC 8, when --enable-checking=yes,rtl is used with x32 GCC,
>> I got
>>
>> cc1plus: out of memory allocating 56137200 bytes after a total of
>> 3139436544 bytes
>> make[5]: *** [Makefile:1104: in
On 08/14/2017 08:09 AM, H.J. Lu wrote:
> Yes, I got the same error with --enable-checking=yes,rtl:
>
> cc1plus: out of memory allocating 56137200 bytes after a total of
> 3139436544 bytes
> make[5]: *** [Makefile:1104: insn-extract.o] Error 1
Thanks for the confirmation. I have a successful x32 b
On 08/13/2017 07:05 PM, H.J. Lu wrote:
> On Sun, Aug 13, 2017 at 3:52 PM, Daniel Santos
> wrote:
>> I've setup an x32 test environment using Gentoo in hopes of being able
>> to both compile and run x32 tests, but I'm having problems getting a
>> successful boots
On 08/13/2017 05:52 PM, Daniel Santos wrote:
> cc1plus: out of memory allocating 56137200 bytes after a total of
> 314880 bytes
> make[3]: *** [Makefile:1104: insn-extract.o] Error 1
> make[3]: *** Waiting for unfinished jobs
I apparently misunderstood the "after a total
I've setup an x32 test environment using Gentoo in hopes of being able
to both compile and run x32 tests, but I'm having problems getting a
successful bootstrap. I'm guessing this is due to something currently
broken with x32, but I want to make sure it's not something I'm doing
wrong, and if it i
On 08/03/2017 05:07 PM, Mike Stump wrote:
> On Aug 2, 2017, at 10:34 PM, Daniel Santos wrote:
>> I'm working on a patch to modify the testsuite to obey the
>> --load-average value if one is passed to make.
> The code seems like a reasonable approach. Love to see numbers a
On 08/03/2017 11:45 AM, Jeff Law wrote:
> On 08/02/2017 11:34 PM, Daniel Santos wrote:
> So does this perform better than make -j X -l X? I use that with good
> success.
>
> jeff
Sorry for my slow response!
For a short answer, if you have 8 CPU cores and you run make -j8
I'm working on a patch to modify the testsuite to obey the
--load-average value if one is passed to make. It seems to work pretty
well, except for libstdc++ which doesn't load gcc/libs/gcc-defs.exp
since it defines it's own ${tool}_functions. I haven't dug too deeply
into libstdc++'s testsuite ye
On 05/12/2017 10:49 AM, Martin Sebor wrote:
On 05/10/2017 04:14 PM, Daniel Santos wrote:
Well my primary goal is programming with values that are constant in the
compiler. There is no language in any C specification (that I'm aware
of) for a "compile-time constant", but the
Sorry for my delayed response.
On 05/11/2017 09:35 AM, Joseph Myers wrote:
On Thu, 11 May 2017, Jonathan Wakely wrote:
On 10 May 2017 at 23:14, Daniel Santos wrote:
Well my primary goal is programming with values that are constant in the
compiler. There is no language in any C specification
On 05/10/2017 04:24 AM, Jonathan Wakely wrote:
Just because there's already one way to do something doesn't mean
better ways to do it are bad.
I'm only speaking out of jealousy being that most of my recent work has
been in C.
hadn't gone so far as to investigate using this new attribute on
Thanks for your feedback!
On 05/09/2017 08:29 AM, Allan Sandfeld Jensen wrote:
On Tuesday 09 May 2017, Daniel Santos wrote:
The primary aim is to facilitate high-performance generic C
libraries for software where C++ is not suitable, but the cost of
run-time abstraction is unacceptable. A good
Thanks for your feedback!
On 05/09/2017 04:36 AM, Florian Weimer wrote:
On 05/09/2017 01:36 AM, Daniel Santos wrote:
To further the usefulness of such techniques, I propose the addition
of a c-family attribute to declare a parameter, variable (and
possibly other declarations) as "cons
I would like to make some changes in GCC 8, so I thought that formal
proposal and RFC would be the best path. I'm still relatively new to the
GCC project.
I began experimenting with C metaprogramming techniques back in 2012, in
order to implement more efficient generic libraries in C. The code
On 05/05/2017 08:53 AM, Richard Biener wrote:
On May 5, 2017 3:03:43 PM GMT+02:00, Jan Hubicka wrote:
Aha, --enable-checking=no. I will check what effect it have.
It does reproduce for me. Time estimates are very slightly different
between
checking and non-checking build. I am investigati
Thanks for the help, Martin!
On 05/03/2017 03:42 AM, Martin Jambor wrote:
Hi,
On Sat, Apr 29, 2017 at 06:28:31AM -0500, Daniel Santos wrote:
Brievity is not my forte, so let me start with the questions. Can somebody
please point me to the pass and/or function where gcc
1.) decides rather or
Anybody else getting bootstrap failures from the head?
gcc/tree-outof-ssa.o differs
gcc/insn-output.o differs
gcc/tree-chrec.o differs
gcc/cp/semantics.o differs
gcc/lto-cgraph.o differs
gcc/builtins.o differs
gcc/i386.o differs
gcc/dwarf2out.o differs
I built from this commit:
commit 8d05cc6f3
1.) decides rather or not to inline a function,
2.) decides rather or not to make a .constprop version of a function,
3.) a good pass (when all constant propagation is done) to search for
fn parameters and variables (marked with an attribute) that were not
constproped away, and finally
4.) wha
Brievity is not my forte, so let me start with the questions. Can
somebody please point me to the pass and/or function where gcc
1.) decides rather or not to inline a function,
2.) decides rather or not to make a .constprop version of a function,
3.) a good pass (when all constant propagation i
tsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.exp
@@ -0,0 +1,133 @@
+# Tests for ms_abi to sysv_abi calls.
+# Copyright (C) 2016-2017 Free Software Foundation, Inc.
+# Contributed by Daniel Santos
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it un
After careful thought, I'm renaming -moutline-msabi-xlogues to
-mcall-ms2sysv-xlogues and would appreciate some feedback or any objections.
This is a new gcc8 feature that emits prologues and epilogues that call
or tail-call stubs in libgcc when 64-bit ms_abi function calls a
sysv_abi function
On 03/10/2017 11:23 AM, Joseph Myers wrote:
On Fri, 10 Mar 2017, Daniel Santos wrote:
3. Wouldn't it be better to move this logic up into DejaGnu and restrict gcc
to using a black-box interface for modifying the environment?
GCC is meant to work with a wide range of different DejaGnu ver
On 02/24/2017 11:55 AM, NightStrike wrote:
Currently, to build natively on cygwin, this patch is required to zlib:
https://github.com/Alexpux/MSYS2-packages/blob/master/zlib/1.2.11-cygwin-no-widechar.patch
Thank you for this. Unfortunately, I didn't see this message prior to
filing my bug re
Hello,
I've been trying to get some clean test results on Cygwin and have
encountered a number of problems. I've opened a report for the one I'm
most concerned with
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79867). When an executable
is being loaded, Windows searches for dlls based upon
ff-by: Daniel Santos
---
gcc/config/i386/i386.c | 281 +++--
1 file changed, 272 insertions(+), 9 deletions(-)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index b3d48ac2e78..f9a02bedbee 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config
Adds HARD_REG_SET stub_managed_regs to track registers that will be
managed by the pro/epilogue stubs for the function.
Adds a third parameter bool ignore_outlined to ix86_save_reg to specify
rather or not the count should include registers marked in
stub_managed_regs.
Signed-off-by: Daniel
Adds the option to i386.opt and i386.c and adds documentation to
invoke.texi.
Signed-off-by: Daniel Santos
---
gcc/config/i386/i386.c | 3 ++-
gcc/config/i386/i386.opt | 5 +
gcc/doc/invoke.texi | 11 ++-
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/gcc
ix86_compute_frame_layout will now populate fields added to structs
machine_function and ix86_frame, which are used by xlogue_layout::get_instance
to determine the correct instance to return.
Signed-off-by: Daniel Santos
---
gcc/config/i386/i386.c | 105
msabi --> sysv scenario)
[f] Variant for hard frame pointer (and stack realignment)
[x] Tail-call variant (is the return from function)
Signed-off-by: Daniel Santos
---
libgcc/config.host | 2 +-
libgcc/config/i386/i386-asm.h |
For the sake of clarity, I've separated out these minor refactoring
changes from the rest of the patches.
Signed-off-by: Daniel Santos
---
gcc/config/i386/i386.c | 21 ++---
gcc/config/i386/i386.h | 4 +++-
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git
yout cannot be used until stack realign flags are finalized and
ix86_compute_frame_layout is called, at which point
xlouge_layout::get_instance may be used to retrieve the appropriate
(constant) instance of xlouge_layout.
Signed-off-by: Daniel Santos
---
gcc/config/i386/i386.c |
typically offer better
optimization than the restore stub as the tail call)
* restore_multiple_and_return - a jump_insn that returns from the
function as a tail-call.
* restore_multiple_leave_return - like the above, but restores the frame
pointer before returning.
Signed-off-by: Daniel Santos
/i386/resms64x.S | 59
libgcc/config/i386/savms64.S | 57
libgcc/config/i386/savms64f.S | 55
libgcc/config/i386/t-msabi | 7 +
15 files changed, 1314 insertions(+), 38 deletions(-)
Daniel Santos
arget/i386/msabi/gen.cc| 788
++
gcc/testsuite/gcc.target/i386/msabi/msabi.c | 379 +++++
gcc/testsuite/gcc.target/i386/msabi/msabi.exp | 125
5 files changed, 1456 insertions(+)
Daniel Santos
>From 2e9fa543e1923c7acc705e06bba006fc5887d805 Mon Sep 17 00:00:00 2001
Sorry for my delayed response. I've been a bit under the weather lately.
On 01/11/2017 10:46 AM, Mike Stump wrote:
After running using DG_TORTURE_OPTIONS,
But why? I think you missed what you're testing. You aren't creating or
looking for bugs in the optimizer. Your test case isn't for an
On 01/11/2017 12:25 PM, Joseph Myers wrote:
A test [istarget x86_64-*-gnu] is wrong; i?86-* -m64 should always be
handled exactly the same as x86_64-* -m64.
You need to work out which ABIs (-m32, -mx32, -m64) this testing is
meaningful for. Then, allow both x86_64- and i?86- targets, together w
Thanks again for help getting started with this Mike!
I've gotten rid of the Makefile and everything is run now from
msabi.exp. I've also gotten rid of the header file, now that I know how
to define a "_noinfo" fn pointer, so it's down to just 4 files:
msabi.exp, gen.cc, msabi.c and do_test.S
On 12/31/2016 02:53 PM, Mike Stump wrote:
Also, I can't have the two generated .c files in the same translation unit (at
least in their current form) because gcc's too smart with optimizations. :)
You can inform the optimizer to stop doing that. volatile is but one way.
This informs it that
First of all, thank you for your thoughtful response!
On 12/30/2016 06:01 PM, Mike Stump wrote:
On Dec 30, 2016, at 11:58 AM, Daniel Santos wrote:
Still being pretty new to GCC and having never used dejagnu, expect or Tcl, I'm
trying to determine how to best integrate my test program
c's Makefile.in. Integrating with dejagnu seems to be the most
intuitive and simple, but I don't properly understand how this would
affect a cross-compiler build. Any advice?
Thanks!
Daniel
>From d38bc80fc793224fb0fbd586824786f5ec178f65 Mon Sep 17 00:00:00 2001
From: Daniel Santos
Date: Sat
So the core problem was my "restore multiple" insn contained a CALL insn
and was a call_insn. The symbol it called is in the static section of
libgcc. However, during peephole2 pass, get_call_reg_set_usage in
final.c didn't find a function declaration attached to the symbol and so
defaulted to
It would probably be useful to post the actual code. The below function
emit_msabi_outlined_restore() is is called from ix86_expand_epilogue()
to emit the RTL to call the restore stub. Like ix86_expand_epilogue, it
uses style == 0 to indicate that there will be a sibling call following
the epil
I think I've finally found the problem. It would appear that if you do
not explicitly add a note of type REG_CALL_DECL that specifies the
function declaration then it will ignore whatever you've supplied with
add_function_usage_to(). Instead, it will replace it with the target's
default regist
On 10/16/2016 05:27 PM, Segher Boessenkool wrote:
Oddly enough, I had forgotten to call add_function_usage_to() on my save
stub (which I didn't post), but not the restore stub. So thanks for that
psychic intervention. :) But if you look carefully, it's there, although
it's hard to read because
On 10/15/2016 08:41 PM, Segher Boessenkool wrote:
Hi Daniel,
On Sat, Oct 15, 2016 at 01:45:12AM -0500, Daniel Santos wrote:
The insn that's getting deleted is 75, where RCX is set. I'm starting
to think that maybe df_analyze() presumes that my call (to the stub) is
invalidating RCX
I'm working on my -foutline-masbi-xlouges optimization (targeting 64 bit
Wine) and I've run into a snag with sibling calls. When
-foutline-masbi-xlouges is disabled, the sibling call generates just
fine. But when enabled the call to df_analyze() in the peephole2 pass
deletes the insn that initi
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
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
On 08/20/2016 09:53 AM, Jeff Law wrote:
On 08/20/2016 06:01 AM, Daniel Santos wrote:
I have been unable to figure out how to (correctly) generate RTL (in
expand the pro/epilogue pass) to jump to a stub defined in libgcc for
the out-of-lined epilogue. If I write it as a function call, but then
I have been unable to figure out how to (correctly) generate RTL (in
expand the pro/epilogue pass) to jump to a stub defined in libgcc for
the out-of-lined epilogue. If I write it as a function call, but then
set the insn's jump field to true it emits the correct jump asm, but
then it thinks it
I'm stuck on generating a jmp to the epilogue as I can't find any
examples of this. This is the summarized version of what I'm doing:
rtx msabi_restore_fn, jump_insn;
msabi_restore_fn = gen_rtx_SYMBOL_REF (Pmode, "__msabi_restore");
SYMBOL_REF_FLAGS (msabi_restore_fn) |= SYMBOL_FLAG_LOCAL;
jump
On 08/15/2016 05:46 AM, Florian Weimer wrote:
On 08/14/2016 08:23 AM, Daniel Santos wrote:
ms_abi_push_regs:
pop%rax
push %rdi
push %rsi
sub$0xa8,%rsp
movaps %xmm6,(%rsp)
movaps %xmm7,0x10(%rsp)
movaps %xmm8,0x20(%rsp)
movaps %xmm9,0x30(%rsp
On 08/15/2016 05:56 AM, Richard Biener wrote:
On Mon, Aug 15, 2016 at 2:16 AM, Jeff Law wrote:
On 08/14/2016 01:57 AM, Trevor Saunders wrote:
On Sun, Aug 14, 2016 at 01:23:16AM -0500, Daniel Santos wrote:
I'm experimenting with ways to optimize wine (x86 target only) and I
believe
On 08/15/2016 06:35 AM, André Hentschel wrote:
Hi,
Thanks for working on this, but I haven't seen some discussion on wine-devel
recently.
I'm also not an expert on that area, but isn't this risking to break copy
protections and hotpatching.
Just wanted to remind you about those two things, so t
Just an update. I did discover how the pass functions call back into the
target-specific code, it's generated from gcc/config/i386/i386.md. So
thread_prologue_and_epilogue_insns() --> gen_prologue() -->
ix86_expand_prologue(), which is implemented in i386.c. So that problem
is solved, but still
I'm experimenting with ways to optimize wine (x86 target only) and I
believe I can shrink wine's total text size by around 7% by outlining
the lengthy pro- and epilogues required for ms_abi functions making
sysv_abi calls. Theoretically, fewer instruction cache misses will
offset the extra 4 in
rested in views on the relative merits of these approaches.
Thanks
Charles
I'm working on a C metaprogramming library for (currently supporting
only gcc) and this is an everyday dilemma for me. I have a macros for
this (see
https://github.com/daniel-santos/gboing/blob/master/include/gb
On 07/18/2014 04:55 AM, Martin Jambor wrote:
Hi,
On Thu, Jul 17, 2014 at 12:26:43PM -0500, Daniel Santos wrote:
I've recently discovered that a function marked always_inline but
called by pointer won't always be inlined. What would it take to
assure that this either always
On 07/18/2014 04:55 AM, Martin Jambor wrote:
Hi,
On Thu, Jul 17, 2014 at 12:26:43PM -0500, Daniel Santos wrote:
I've recently discovered that a function marked always_inline but
called by pointer won't always be inlined. What would it take to
assure that this either always
I've recently discovered that a function marked always_inline but called
by pointer won't always be inlined. What would it take to assure that
this either always happens or generates an error? Unfortunately, it's
breaking (well, failing to properly optimize) some code where I need the
optimizer
Well I'm certainly interested! I would like a venti, tripple-shot, cafe
mocha, go easy on the syrup and one of those cute little birthday pops.
Also, I want one of those drink carriers because my dog likes to play
with them.
On 06/26/2013 01:15 PM, Paolo Carlini wrote:
> Are you also a barman
Thanks for your response!
On 06/19/2012 08:40 AM, Richard Guenther wrote:
> On Tue, Jun 19, 2012 at 4:41 AM, Daniel Santos wrote:
>> So before filing any feature request bugs, I figured I should bring my
>> discussion here first, as I believe some enhancements to gcc can better
Yes, my topic sounds crazy huh? But you guys made it possible when you
started optimizing out constant function pointers. (Thank you!!) This
didn't mature to "full power" until 4.6.? (works in 4.6.2, not sure
about earlier 4.6). Now that you can populate a struct with const
pointers to inline fun
64 matches
Mail list logo
