On 8/17/23 3:54 AM, Richard Biener wrote:
I think it needs a new category, 'inline' is probably the "closest" existing one
but that also tends to be noisy. Maybe 'call' would be a good name? We could
report things like tail-recursion optimization, tail-calling and sibling calling
optimizations
First, if this is no longer the appropriate group for this discussion,
please tell me where to send it.
I've been working to understand all the comments here. From them, I think:
1. It's OK to have gcc report back to the user whether each particular
call in tail position is optimized when
Thank you for your comments. I have a few questions.
I don't think this specific case qualifies for -Wdisabled-optimization.
The diagnostic is for cases the user can control and was invented
for limits we put up for compile-time and memory-usage issues
where there exist --param XYZ to adjust
On 8/5/23 5:53 PM, David Malcolm wrote:
...but the warning branch uses "warning", which implicitly uses the
input_location global variable. Is the warning reported at the correct
place? It's better to use warning_at and pass it the location at which
the warning should be emitted.
Thanks, I
On 8/5/23 4:58 PM, Prathamesh Kulkarni wrote:
I don't have comments on the patch, but a new warning will also
require a corresponding entry in doc/invoke.texi.
Thank you for your comment.
-Wdisabled-optimization is an established warning, it's just that I'd
like it to apply in another
The patch at the end adds a warning when a tail/sibling call cannot be
optimized for various reasons.
I built and tested GCC with and without the patch with configuration
Configured with: ../../gcc-mainline/configure --enable-languages=c
--disable-multilib --prefix=/pkgs/gcc-mainline
On 8/1/23 6:08 PM, David Malcolm wrote:
FWIW I added it to support Scheme from libgccjit;
Do you know of any Scheme using libgccjit?
BTW, I tried to build mainline with --enable-coverage to see which code
is executed with -foptimize-sibling-calls, but bootstrap fails with
On 8/1/23 6:08 PM, David Malcolm wrote:
Or from libgccjit. FWIW I added it to support Scheme from libgccjit;
see this patch kit:
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01287.html
Perhaps there's a case for a frontend attribute for this.
Dave
Thanks. I thought a front-end warning
On 8/1/23 12:51 PM, Paul Koning wrote:
How is it possible to write valid C that is correct only if some optimization
is done?
Perhaps "incorrect" was the wrong word. If sibling-call optimization is
not done, then perhaps the program will blow out the stack, which would
not happen if the
The Gambit Scheme->C compiler has an option to generate more efficient
code if it knows that all tail and sibling calls in the generated C code
will be optimized. If gcc does not, however, optimize a tail or sibling
call, the generated C code may be incorrect (depending on circumstances).
So
Perhaps this question is appropriate for the gcc mail list.
Converting a float/double to unsigned int is undefined if the result
would be negative when converted to a signed int.
x86-64 and arm treat this condition differently---x86-64 returns a value
whose bit pattern is the same as the bit
On 11/12/2015 12:08 PM, Bradley Lucier wrote:
On 11/12/2015 11:57 AM, Bernd Schmidt wrote:
The expanded warning allowed me to see how much memory really was needed
to apply gcse to some of my routines, and 128MB fixes my problem. The
limit has been 50MB for over 10 years, I think we can up
On 11/12/2015 11:57 AM, Bernd Schmidt wrote:
The expanded warning allowed me to see how much memory really was needed
to apply gcse to some of my routines, and 128MB fixes my problem. The
limit has been 50MB for over 10 years, I think we can up it a bit now.
{
+ unsigned int memory_request =
This patch (a) removes an exact copy of is_too_expensive from cprop.c,
(b) renames is_too_expensive in gcse.c to
gcse_or_cprop_is_too_expensive, (c) expands the warning in
gcse_or_cprop_is_too_expensive to say how much --param max-gcse-memory
needs to be increased, and (d) increases the
The routines declared as
static bool
is_too_expensive (const char *pass)
in both cprop.c and gcse.c are identical except for two comment lines.
I'd like to modify is_too_expensive, which implied to me that there
should be only one copy of the routine.
Would it be reasonable to add an extern
Marc Feeley, the author of the Gambit Scheme compiler and interpreter, has
measured the time to make the current version of Gambit, and then to run an
application in the Gambit interpreter, for every release of gcc since gcc-2.95.
For each version of gcc, Feeley built Gambit in each of two
On my codes, pre-RA instruction scheduling on X86-64 (a) improves run
times by roughly 10%, and (b) costs a lot of compile time.
The -fscheduling option didn't seem to be on in your time tests (I think
it's not on by default on that architecture at -O2).
Brad
I've never seen the answer to the following question: Why do some
versions of gcc that I build not have string substitutions in error
messages?
I get things like this:
[luc...@lambda-head lib]$ /pkgs/gcc-mainline/bin/gcc -mcpu=970 -m64 -
fschedule-insns -Wno-unused -O1 -fno-math-errno
On Wed, 2009-08-26 at 20:38 +0200, Paolo Bonzini wrote:
When I worked at AMD, I was starting to suspect that it may be more
beneficial
to re-enable the first schedule insns pass if you were compiling in 64-bit
mode, since you have more registers available, and the new registers do not
On Wed, 2009-08-26 at 17:12 -0700, Ian Lance Taylor wrote:
If you are getting that kind of speedup (which I personally did not
expect) then this is clearly worth pursuing. It should be possible to
make it work at least in 64-bit mode. I recommend that you file a bug
report or two for cases
On Jul 25, 2009, at 12:54 PM, Paolo Bonzini wrote:
Am i missing something?
No, it is a bug due to the build-with-C++ patches. Please file a
PR and, in the meanwhile, try --enable-stage1-languages=c,c++ or --
enable-build-with-cxx.
I filed PR40950 for this.
I also filed PR40968 for
Thanks for your reply.
On Jul 25, 2009, at 7:18 AM, Ralf Wildenhues wrote:
Does /home/lucier/programs/gcc/objdirs/mainline/./prev-gcc/g++ exist,
No.
and if yes, is it a functioning executable?
If it doesn't exist, that looks like the toplevel logic for which
languages to build still has a
On Jul 25, 2009, at 12:54 PM, Paolo Bonzini wrote:
Am i missing something?
No, it is a bug due to the build-with-C++ patches. Please file a
PR and, in the meanwhile, try --enable-stage1-languages=c,c++
That seemed to work, thanks, bootstrap has gotten past my old problem.
or
On Jul 25, 2009, at 2:16 PM, Bradley Lucier wrote:
On Jul 25, 2009, at 12:54 PM, Paolo Bonzini wrote:
Am i missing something?
No, it is a bug due to the build-with-C++ patches. Please file a
PR and, in the meanwhile, try --enable-stage1-languages=c,c++
That seemed to work, thanks
After configuring
Target: x86_64-unknown-linux-gnu
gcc version 4.5.0 20090715 (experimental) [trunk revision 149654] (GCC)
with
../../mainline/configure --enable-checking=release
--prefix=/pkgs/gcc-mainline-mem-stats --enable-languages=c
--enable-gather-detailed-mem-stats
I get the
I've put at
http://www.math.purdue.edu/~lucier/bugzilla/9/
some compile-time and run-time statistics related to PR 39157 and PR
33928 and compile times and run times for the programs in the Gambit
Scheme benchmark suite. The statistics are for 4.1.2 release, 4.2.4
release, 4.3.3 release, 4.4.1
On Thu, Nov 20, 2008 at 11:17:52AM +0100, Paolo Carlini wrote:
Hi,
Should this be XFAILed on powerpc64-apple-darwin9?
A patch doing that is essentially preapproved if you can confirm
that in
the meanwhile the malloc bug (Radar 3884894) has been fixed for
i386-apple-darwin and not for
There has been some discussion here of GCC's reputation and of how to
classify bugs.
This bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
has gradually morphed from a compile-time issue to a space issue; if
it's not fixed for 4.4 (and it appears that it will not be fixed in
that
I'm getting the following failure on powerpc64-apple-darwin9.5.0:
Setting LD_LIBRARY_PATH to :/Users/lucier/programs/gcc/objdirs/
mainline/gcc:/Users/lucier/programs/gcc/objdirs/mainline/powerpc64-
apple-darwin9.5.0/./libstdc++-v3/src/.libs::/Users/lucier/programs/gcc/
I'm just not having any luck bootstrapping this thing ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37639
Klaus:
Perhaps your problem is related to PR 26854:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
See in particular comment 70, which has some statistics.
If you're building your own gcc, configure gcc with --enable-gather-
detailed-mem-stats and compile your program with -ftime-report
The web page
http://gcc.gnu.org/gcc-4.3/changes.html
states that The -ftree-vectorize option is now on by default under -
O3., but on
http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Optimize-Options.html
-ftree-vectorize is not listed as one of the options enabled by -O3.
Is the first
On Jun 18, 2007, at 2:14 PM, Uros Bizjak wrote:
tbp wrote:
For example, when doing 1/x and sqrt(x) via reciprocal + NR, you
first
get an inf from said reciprocal which then turns to a NaN in the NR
stage but if you correct it by, say, doing a comparison to 0 and a
'and'.
That's what ICC
On Jun 18, 2007, at 2:27 PM, Bradley Lucier wrote:
But even if sqrt is corrected for 0.0 * inf, there would still be
a lot of problems with the combinations of NR-enhanced rsqrt and
rcp. Consider for example:
1.0/sqrt(a/b) alias rsqrt(a/b)
Having a=0, b != 0, the result is inf
On Apr 21, 2007, at 6:01 PM, Bradley Lucier wrote:
So I'm wondering whether certain options have to be included on the
command line to get the benefits of -fstrict-aliasing.
I've thought about this question a bit more, so maybe I can make it
less content-free.
The C code generated
On May 3, 2007, at 11:11 AM, Uros Bizjak wrote:
Could you please post a patch with suggested wording about this
option (I was trying to write something similar to the warning that
icc has in its documentation about precision settings).
How about this? It perhaps reflects my own biases,
On May 3, 2007, at 2:45 PM, Uros Bizjak wrote:
Bradley Lucier wrote:
On May 3, 2007, at 11:11 AM, Uros Bizjak wrote:
Could you please post a patch with suggested wording about this
option (I was trying to write something similar to the warning
that icc has in its documentation about
On May 3, 2007, at 3:29 PM, Uros Bizjak wrote:
Bradley Lucier wrote:
What about significant loss of accuracy as these options
probably won't cause a nuclear reactor meltdown ;)
Well, I did some googling, and the technical term I was thinking
of was catastrophic cancellation. So how
Richard Henderson wrote:
On Tue, Apr 03, 2007 at 10:56:42AM +0200, Uros Bizjak wrote:
... Note that a change of default precision control may
affect the results returned by some of the mathematical functions.
to the documentation to warn users about this fact.
Eh. It can seriously break
On Apr 29, 2007, at 1:01 PM, Tim Prince wrote:
[EMAIL PROTECTED] wrote:
I just (re-)discovered these tables giving maximum known errors in
some libm functions when extended precision is enabled:
http://people.inf.ethz.ch/gonnet/FPAccuracy/linux/summary.html
and when the precision of the
I've decided to try to contribute modifications to the the C code
that is generated by the Gambit Scheme-C compiler so that (a) it
doesn't have any aliasing violations and (b) more aliasing
distinctions can be made (the car and cdr of a pair don't overlap
with the entries of a vector,
If you try
../gcc-4.1.2/configure; make bootstrap
on a powerpc-darwin G4 system, then the bootstrap will fail because
the process builds 64-bit multilibs and tries to execute a program
with xgcc -m64'.
In May 2005, PR 21561 reported this same problem on 32-bit x86
solaris; the
On Apr 15, 2007, at 6:37 PM, Andrew Pinski wrote:
On 4/15/07, Bradley Lucier [EMAIL PROTECTED] wrote:
If you try
../gcc-4.1.2/configure; make bootstrap
on a powerpc-darwin G4 system, then the bootstrap will fail because
the process builds 64-bit multilibs and tries to execute a program
Robert Dewar wrote:
I have always been told that -ftrapv is nowhere near fully working or
reliable (I think Eric is the source of that advice).
Is this just a rumor, or are there data that backs this up. (That -
fwrapv doesn't work, not that Dewar was always told that it doesn't
work.)
On Dec 8, 2006, at 1:43 AM, Andrew Pinski wrote:
In case anyone does not know yet, the warning is the same as PR 29779.
I don't remember if this was mentioned or not.
Thank you very much for that info. That is indeed the problem with
these test cases, as can be seen if I specify a 64-bit
After
0. Making Jack's suggested changes to prune.exp (even though they
didn't catch any new linker messages);
1. Configuring and making with
/bin/rm -rf *; env CC=/pkgs/gcc-4.2.0-64/bin/gcc ../configure --
build=powerpc64-apple-darwin8.8.0 --host=powerpc64-apple-darwin8.8.0
I'm getting several thousand gfortran testsuite errors with messages
like:
FAIL: gfortran.dg/PR19754_2.f90 -O3 -fomit-frame-pointer -funroll-
all-loops -finline-functions (test for excess errors)
Excess errors:
/Users/gcc-test/programs/gcc/mainline/gcc/testsuite/gfortran.dg/
The gcc developers have been very cooperative over the years in
working to solve problems that I've had in compiling large machine-
generated programs. For example, when gcse was disabled for large
flow flow graphs in 2000, the warn_disabled_optimization flag was
added at my suggestion.
For many years, the default gcc compile options for C code generated
by Gambit, the Scheme-C compiler, were very simple (-O1 -fschedule-
insns2 -fno-math-errno -fno-trapping-math) and I didn't have problems
with gcc's space requirements to compile those files. (I often ran
into complexity
On Sep 22, 2006, at 9:20 PM, Eric Christopher wrote:
Bradley Lucier wrote:
Right now, it seems that one may not be able to build a 64-bit
version of the compiler itself
You may or may not have noticed that there are no 64-bit native
targets for darwin.
I just looked at
http
On Oct 4, 2006, at 1:57 PM, Eric Christopher wrote:
FWIW I think a 64-bit native version might be nice as a separate
target, but I've been told there's no real advantage there either
on ppc.
Perhaps I'm misunderstanding your comment, but with a 64-bit gcc you
can compile
On Aug 30, 2006, at 9:55 PM, Jack Howarth wrote:
Try building
some of the g++ testcases manually and see what the errors
are.
Perhaps this is a problem:
grep 'Symbol not found' g++.log | sort | uniq -c
1254 dyld: Symbol not found: ___dso_handle
After some discussion with Jack Howarth, I have found that the
gfortran and libgomp executable tests on powerpc-apple-darwin8.7.0
(at least) do not link the correct, just-built-using-make
bootstrap, libraries until those libraries have first been installed
in $prefix/lib/...
I filed a
When I run bootstrap and make check, I check the -m64 option
(only). Check gcc-testresults.
Currently, the results don't look very good. Maybe I'm doing
something wrong.
Brad
On Aug 28, 2006, at 12:10 PM, Jack Howarth wrote:
Why don't you try a normal multi-lib build without any
extra flags.
What extra flags? The configure command is
../configure --prefix=/pkgs/gcc-mainline --with-gmp=/opt/local/ --
with-mpfr=/opt/local/
which is totally generic (one
On May 3, 2006, at 7:50 PM, David Fang wrote:
Bradley Lucier writes:
Brad 4.2 hasn't bootstrapped on powerpc-apple-darwin G5 machine
for a very
Brad long time. I'm seeing the same problem as
Brad http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27121
Brad It would be nice if this were
On May 3, 2006, at 7:50 PM, David Fang wrote:
FWIW, the 20060415 mainline (4.2) snapshot bootstrapped for me, using
odcctools-20060413 (odcctools-590.36od13). This machine is a dual G5
(ppc970) using OS X 10.3.9, and Apple's gcc-3.3 (build 1640).
However, before building, I patched the
4.2 hasn't bootstrapped on powerpc-apple-darwin G5 machine for a very
long time. I'm seeing the same problem as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27121
It would be nice if this were remedied. I do try to test gcc
versions before release.
Brad
I'm trying to build a 64-bit mainline compiler on powerpc-darwin; I
want gcc to generate 32-bit binaries by default, I just want cc1,
etc., to be 64-bit binaries so I can compile large files.
This works in 4.1, but not on mainline. This is reported at
On Mar 21, 2006, at 11:39 PM, Shantonu Sen wrote:
On Mar 21, 2006, at 12:34 PM, Bradley Lucier wrote:
I'm curious about whether any of the changes recently proposed to
clean up the x86-darwin port can be applied to the 64-bit PowerPC
darwin compiler;
Like what? I haven't really seen
64-bit powerpc-darwin results be found here:
http://www.math.purdue.edu/~lucier/gcc/test-results/4_2-2006-03-20.gz
The mail-report-with-warnings.log file is again too large to be
accepted by the gcc-testresults mail list after quite a few weeks
when it was only about 125K long.
I'm
Please let us know ([EMAIL PROTECTED]) if there are any issues
with the new import. It has been tested on x86, x86-64 and ppc-32 on
GNU/Linux and sun-sparc-solaris8 multilib and darwin-pcc 32-bit. But
more testing is helpful (it also includes an update to the fdlibm
library).
I don't know if it
On Jan 23, 2006, at 8:07 PM, Shantonu Sen wrote:
I've posted a new version of odcctools (based on Apple's cctools
and ld64 source) which should fix a few thousand of the failures.
Instructions are at:
http://www.opendarwin.org/projects/odcctools/usingodcctools.html
This is based on
http://www.math.purdue.edu/~lucier/gcc/test-results/4_1-2006-01-17.gz
(Too large to be accepted here.)
So I have a question. I've installed the latest Xcode release, or,
at least I think I did:
[lindv2:gcc/4.1/objdir64] lucier% gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
On Jan 8, 2006, at 7:19 PM, Daniel Berlin wrote:
On Sun, 2006-01-08 at 18:05 -0600, Bradley Lucier wrote:
OK, here are some details. Our server is a dual UltraSparc running
Solaris 10 attached to the SAN.
Working client situation: subversion 1.3.0 on Sparc Solaris 9, not
using Berkeley DB
On Jan 8, 2006, at 9:04 AM, Andreas Schwab wrote:
Try removing the offending directory (gcc/testsuite/gcc.dg/special)
and
run svn cleanup again, updating the tree afterwards. If you didn't
have
any local changes in that directory you should not lose anything.
If the
problem persists
On Jan 8, 2006, at 9:12 AM, Daniel Berlin wrote:
Try removing the offending directory (gcc/testsuite/gcc.dg/
special) and
run svn cleanup again, updating the tree afterwards. If you
didn't have
any local changes in that directory you should not lose anything.
If the
problem persists
I'm having all kinds of trouble running svn on my RHEL 4.0 system. A
typical example of what's happening is:
euler-62% svn cleanup
svn: XML parser failed in 'gcc/testsuite/gcc.dg/special'
I first got that message when I tried contrib/gcc_update after doing
a svn checkout. Now I just get
On Dec 16, 2005, at 6:23 PM, Mike Stump wrote:
On Jun 20, 2005, at 2:41 PM, Bradley Lucier wrote:
I can't seem to build any 64-bit shared library on powerpc-apple-
darwin8.1.0, although I can now run the test suite more
effectively; see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110
On Dec 16, 2005, at 8:25 PM, Eric Christopher wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
Unfortunately, even with my Apple Developer account I can't seem
to figure out how to look up radar reports that I haven't submitted.
I took a look at the radar. Says, effectively, that
I bootstrapped and regtested 4.1 on powerpc-apple-darwin8.3.0 and
there were so many errors with -mcpu=970 -m64 that the gcc mail
daemon wouldn't accept the summary. So I put it at
http://www.math.purdue.edu/~lucier/gcc/test-results/4_1-12-06-2005.gz
The most serious problems seem to be in
Geoff Keating has made several changes to the darwin configuration
files recently; I was thinking that while people are looking at these
things, perhaps someone can say I'm doing something wrong in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
or whether further configuration changes are
After examining the source and documentation, it appears to me that in
4.0.* and on mainline one cannot turn off the warning generated by
overflow_warning, in, for example,
[descartes:~] lucier% cat test.c
#include stdio.h
int main() {
if (1048256 * 1048256 0)
printf(1);
else
On Jun 16, 2005, at 3:06 PM, Mike Stump wrote:
Actually, by try, I meant try your application. :-)
I can't seem to build any 64-bit shared library on powerpc-apple-
darwin8.1.0, although I can now run the test suite more effectively; see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110
On Jun 16, 2005, at 1:30 AM, Mike Stump wrote:
Please try something like:
...
and let me know if it works.
Thank you, I will try it today.
Last night I unconditionally allowed multilibs and configured with
Compiler version: 4.1.0 20050615 (experimental)
Platform: powerpc-apple-darwin8.1.0
It seems that the libtool command line may be wrong. Here's a simple
test.
[descartes:~/programs] lucier% cat conftest.c
int main2() { return 0;}
[descartes:~/programs] lucier% gcc -m64 -mcpu=970 -o conftest
-dynamiclib conftest.c -v -save-temps
Using built-in specs.
Target:
Mark:
I cannot build and use (link, etc.) 64-bit shared libraries on
powerpc-apple-darwin8.1.0 with gcc version 4.0.1 20050615
(prerelease). This is a regression from 4.0.0 on the same platform.
I couldn't come up with a short example, sorry, but it is easy to
reproduce if you have the
On Jun 15, 2005, at 1:26 PM, Andrew Pinski wrote:
On Jun 15, 2005, at 2:19 PM, Bradley Lucier wrote:
Mark:
I cannot build and use (link, etc.) 64-bit shared libraries on
powerpc-apple-darwin8.1.0 with gcc version 4.0.1 20050615
(prerelease). This is a regression from 4.0.0
On Jun 15, 2005, at 7:12 PM, Mike Stump wrote:
On Wednesday, June 15, 2005, at 11:19 AM, Bradley Lucier wrote:
I cannot build and use (link, etc.) 64-bit shared libraries on
powerpc-apple-darwin8.1.0 with gcc version 4.0.1 20050615
(prerelease).
If you remove the # that comment out
This is the wrong list to ask such a question, but I'll answer it
anyway since the answer might be of general interest.
There is a wonderful book Hacker's Delight by Henry S. Warren Jr.,
http://www.awprofessional.com/bookstore/product.asp?
isbn=0201914654redir=1rl=1
In some ways it can be
On Mar 25, 2005, at 1:22 PM, Tom Tromey wrote:
Brad == Bradley Lucier [EMAIL PROTECTED] writes:
Brad http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01559.html
I didn't see more recent results, but I suspect this problem has been
fixed.
It seems that the libjava tests have been turned off, so
With today's mainline I get
stage1/xgcc -Bstage1/
-B/export/users/lucier/local/gcc-mainline/sparc-sun-solaris2.9/bin/ -c
-g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Werror
On Feb 16, 2005, at 2:13 AM, Eric Botcazou wrote:
I tried this evening to install gmp-4.1.4 and mpfr-2.1.0 on my Solaris
machines and I failed on the first try. (I think the default install
for gmp on my machines is a 64-bit version, but the default for mpfr
and gcc is 32-bit, so I'm going to
On Feb 19, 2005, at 11:18 AM, Eric Botcazou wrote:
So now what? Not build shared libraries for gmp? Add /pkgs/gmp-4.1.4
to my LD_LIBRARY_PATH?
The latter.
Well, I can't really require people using the compiler to have
/pkgs/gcc-4.0/lib, /pkgs/gcc-4.0/lib/sparcv9, *and* /pkgs/gmp-4.1.4 in
their
84 matches
Mail list logo
