[patch, howto, gfortan] make check fix ppc64/darwin8
I came across a "gotcha" whilst trying to test the static
implementation of libgfortran on PPC64-apple-darwin8.
Thanks to Tobias B for pointing me at 99% of the solution.
Probably the number of affected systems is small ;) - but, FWIW,
here's HOWTO and a fix.
-
If you host on {powerpc, i686}-apple-darwin8 and you want to static
link (or check libgfortran) -m64 for PPC64 then this applies to you.
There is an incompatibility [presumably in ld64] between the default
debug symbol generation (stabs) and what's required
for linking/checking PPC64 on darwin8 ... this incompatibility "is
not going to be fixed".
The specific crunch is that every -O3 torture test is compiled with -g
=> in gfortran this causes every -O3 torture test to fail when
checking -m64.
The solution is to build the required code with -gdwarf-2,
unfortunately the "-g" flag is hard-coded in a couple of relevant
places:
(a) in "fortran-torture.exp" and in "gcc-dg.exp" (which is included
in gfortran-dg.exp)
[ the change to gcc-dg.exp makes this non-local to gfortran ]
(b) in the top level configure (as a default C/CXX/FLAGS_FOR_TARGET).
The minimum change work-around is this:
1/ configure/make gcc with CFLAGS_FOR_TARGET = "-02 -gdwarf-2 -
pipe" (and CXXFLAGS_FOR_TARGET the same)
2/ apply the following :
Index: gcc/testsuite/lib/gcc-dg.exp
===
--- gcc/testsuite/lib/gcc-dg.exp(revision 136861)
+++ gcc/testsuite/lib/gcc-dg.exp(working copy)
@@ -48,9 +48,15 @@
{ -O2 } \
{ -O3 -fomit-frame-pointer } \
{ -O3 -fomit-frame-pointer -funroll-loops } \
- { -O3 -fomit-frame-pointer -funroll-all-loops -finline-
functions } \
- { -O3 -g } \
- { -Os } ]
+ { -O3 -fomit-frame-pointer -funroll-all-loops -finline-
functions } ]
+
+ if { [istarget "*-*-darwin8"] } {
+ lappend DG_TORTURE_OPTIONS { -O3 -gdwarf-2 }
+ } else {
+ lappend DG_TORTURE_OPTIONS { -O3 -g }
+ }
+
+ lappend DG_TORTURE_OPTIONS { -Os }
}
global GCC_UNDER_TEST
Index: gcc/testsuite/lib/fortran-torture.exp
===
--- gcc/testsuite/lib/fortran-torture.exp (revision 136861)
+++ gcc/testsuite/lib/fortran-torture.exp (working copy)
@@ -73,9 +73,16 @@
{ -O2 } \
{ -O2 -fomit-frame-pointer -finline-functions } \
{ -O2 -fomit-frame-pointer -finline-functions -funroll-
loops } \
- { -O2 -fbounds-check } \
- { -O3 -g } \
- { -Os }
+ { -O2 -fbounds-check }
+
+ if { [istarget "*-*-darwin8"] } {
+ lappend options { -O3 -gdwarf-2 }
+ } else {
+ lappend options { -O3 -g }
+ }
+
+ lappend options { -Os }
+
if { $test_tree_vectorize } {
lappend options $vectorizer_options
}
*
COMPARISONs of make check-host with and without the changes
This is on darwin 8.11.0
*
make check-host (default, m32)
one extra pass, no regressions
*
g++
-
no change
gcc
-
one extra pass from using dwarf-2
FAIL: gcc.dg/pch/save-temps-1.c -O3 -g assembly comparison
PASS: gcc.dg/pch/save-temps-1.c -O3 -gdwarf-2 assembly comparison
gfortran
--
no change
obj-c++
--
no change
obj-c
--
no change
*
make check-host (m64) RUNTESTFLAGS="--target_board=unix/-m64"
69 extra passes, no regressions
*
g++
--
one extra pass from using dwarf-2
FAIL: g++.old-deja/g++.eh/badalloc1.C execution test (-g)
PASS: g++.old-deja/g++.eh/badalloc1.C execution test (-gdwarf-2)
gcc
-
one extra pass from using dwarf-2
FAIL: gcc.dg/pch/save-temps-1.c -O3 -g assembly comparison
PASS: gcc.dg/pch/save-temps-1.c -O3 -gdwarf-2 assembly comparison
gfortran (every test with -O3 -g fails )
--
67 extra passes using -gdwarf-2
=== gfortran Summary (-g) ===
# of expected passes26196
# of unexpected failures85
# of expected failures 46
# of unsupported tests 59
/Volumes/SwapScratch/OS-source/gcc-44-build/n2n/gcc/testsuite/
gfortran/../../gfortran version 4.4.0 20080612 (experimental) (GCC)
=== gfortran Summary (-gdwarf-2) ===
# of expected passes26263
# of unexpected failures18
# of expected failures 46
# of unsupported tests 59
/Volumes/SwapScratch/OS-source/gcc-44-build/n2n/gcc/testsuite/
gfortran/../../gfortran version 4.4.0 20080612 (experimental) (GCC)
obj-c++
--
no change
obj-c
--
no change
I guess, there's one residual puzzle to me; from the doc. I'd
understand that the -O3 optimizations are in the back end and therefore
common to all the tools. Ho
[patch V2 gfortran] make -static-libgfortran work on darwin.
Thanks for all the helpful suggestions made in response to :
http://gcc.gnu.org/ml/gcc/2008-06/msg00244.html
--
Here is version 2 of the patch.
This is now conditional on darwin* as the host.
(I guess, in principle, it should really depend on LD_FOR_TARGET, but
I couldn't see how to achieve that tidily).
to implement it requires:
a change to the gfortran driver.
a change to the build of libgfortran.
---
a. I've made the change to the driver such that any other host
requiring this only need to define a flag in its x-host.
b. this "USE_DISTINCT_STATIC_LIB_NAME" flag is also available for any
other front ends that want to cater for this darwin 'feature'.
---
change summary:
gcc/config/x-darwin : add a flag identifying this as a system
wanting separate static lib names
gcc/fortran/gfortranspec.c : provide for a distinct static library
name on -static-libgfortran
libgfortran/Makefile.am : generate differently named static/dynamic
libraries on darwin
libgfortran/configure.ac: likewise
*I have NOT attached the following generated file diffs (it made a
huge mail, and conveys no extra info):
Index: libgfortran/configure
Index: libgfortran/Makefile.in
Index: libgfortran/config.h.in
Index: libgfortran/aclocal.m4
if anyone wants them - I can email them g/b/zip.
otherwise, to replicate what I did run autoreconf in libgfortran with :
autoconf (GNU Autoconf) 2.61,
automake (GNU automake) 1.9.6,
ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.492 2008/01/30 06:40:56)
*
TESTS carried out;
This has been bootstrapped on:
powerpc-apple-darwin9
powerpc-apple-darwin8
i686-apple-darwin8
cross tools have also been built on those platforms.
it has been checked by comparing RUNTESTFLAGS="--target_board=unix/-
static-libgfortran" with the default on
powerpc-apple-darwin9 [m32, m64]
powerpc-apple-darwin8 [m32, m64 ***]
i686-apple-darwin8
*** note you need to do this : http://gcc.gnu.org/ml/gcc/2008-06/
msg00361.html for m64 tests
no regressions noted.
=
Missing tests:
1/ a non-darwin system (sorry, don't have one up at the moment).
2/ x86_64 darwin8
3/ i686/x86_64 darwin9
*
Index: gcc/config/x-darwin
===
--- gcc/config/x-darwin (revision 136861)
+++ gcc/config/x-darwin (working copy)
@@ -1,3 +1,5 @@
+# for static lib on gfortran
+T_CFLAGS += "-DUSE_DISTINCT_STATIC_LIB_NAME"
host-darwin.o : $(srcdir)/config/host-darwin.c $(CONFIG_H) $
(SYSTEM_H) \
coretypes.h toplev.h config/host-darwin.h
$(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $<
Index: gcc/fortran/gfortranspec.c
===
--- gcc/fortran/gfortranspec.c (revision 136861)
+++ gcc/fortran/gfortranspec.c (working copy)
@@ -62,21 +62,40 @@
#define FORTRAN_INIT "-lgfortranbegin"
#endif
-#ifndef FORTRAN_LIBRARY
-#define FORTRAN_LIBRARY "-lgfortran"
+#ifndef FORTRAN_SHARED_LIBRARY
+#define FORTRAN_SHARED_LIBRARY "-lgfortran"
#endif
+#ifdef USE_DISTINCT_STATIC_LIB_NAME
+# ifndef FORTRAN_STATIC_LIBRARY
+#define FORTRAN_STATIC_LIBRARY "-lgfortran-static"
+# endif
+#else
+# define FORTRAN_STATIC_LIBRARY FORTRAN_SHARED_LIBRARY
+#endif
+
#ifdef HAVE_LD_STATIC_DYNAMIC
-#define ADD_ARG_LIBGFORTRAN(arg) \
+#define ADD_ARG_LIBGFORTRAN \
{ \
-if (static_lib && !static_linking) \
- append_arg ("-Wl,-Bstatic"); \
-append_arg (arg); \
-if (static_lib && !static_linking) \
- append_arg ("-Wl,-Bdynamic"); \
+ if (static_lib) \
+ { \
+ if (!static_linking) append_arg ("-Wl,-Bstatic"); \
+ append_arg(FORTRAN_STATIC_LIBRARY) ; \
+ if (!static_linking) append_arg ("-Wl,-Bdynamic"); \
+ } \
+ else \
+ { \
+ append_arg(FORTRAN_SHARED_LIBRARY) ; \
+ } \
}
#else
-#define ADD_ARG_LIBGFORTRAN(arg) append_arg (arg);
+#define ADD_ARG_LIBGFORTRAN \
+ { \
+ if (static_lib) \
+ append_arg(FORTRAN_STATIC_LIBRARY) ; \
+ else \
+ append_arg(FORTRAN_SHARED_LIBRARY) ; \
+ }
#endif
@@ -265,9 +284,9 @@
int skip;
const char *arg;
- /* This will be NULL if we encounter a situation where we should not
- link in libf2c. */
- const char *library = FORTRAN_LIBRARY;
+ /* 0 => don't link libgfortran etc.
+ 1 => link libgfortran version as determined by static_lib */
+ int should_link_libs = 1;
/* 0 => -xnone in effect.
1 => -xfoo in effect. */
@@ -346,7 +365,7 @@
case OPTION_E:
/* These options disable linking entirely or linking of the
standard libraries. */
- library = 0;
+ should_link_libs = 0;
break;
case OPTION_static_libgfortran:
@@ -411,7 +430,7 @@
/* If there are no input files, no need for the library. */
if (n_infiles == 0)
Internal abort call optimization?
Hi, I reported a problem I have with abort to the glibc bug tracker at http://sourceware.org/bugzilla/show_bug.cgi?id=6522> which might provide some reading material. Anyway, it has been pointed out to me that the requested change would not accomplish much anyway since GCC has its own builtin notion of the abort function. So here is my beef with the current way abort calls get optimized: basically it boils down to the interaction of -fcrossjumping (enabled with -O2) and the noreturn attribute of abort. The combination of both optimizations means that usually only one abort call will actually get compiled into a compilation unit, and all calls will instead jump there without bothering to clean the stack (after all, it is a noreturn function). This is egregiously bad when using the generated coredump (abort triggers SIGABRT) for debugging failed assertions or other aborts: neither the call/return location is correctly associated with the source code, nor is the stack/register state interpretable using debugging info. Given that the distinguishing feature of abort over exit is the creation of a core dump, it would be good if this core dump would actually be useful. I know several people who have spent days debugging at the wrong place, including myself. Currently Emacs contains in etc/DEBUG the instructions ** When you are trying to analyze failed assertions, it will be essential to compile Emacs either completely without optimizations or at least (when using GCC) with the -fno-crossjumping option. Failure to do so may make the compiler recycle the same abort call for all assertions in a given function, rendering the stack backtrace useless for identifying the specific failed assertion. However, the problem is obviously not restricted to Emacs. If the "noreturn" attribute for the internal abort were removed, at least only abort calls with compatible stack frame and the same (tentative) followup code would get folded. That would avoid the worst head-scratchers when trying to figure out what went wrong. Probably better would be to just disable the crossjumping optimization for calls of abort. Maybe this would warrant a new attribute. Thanks for caring, -- David Kastrup
Stack Pointer/Size on GIMPLE?
Hi all,
my intention is to add a pass at the Gimple (maybe SSA) level. The
current problem is that I would like to generate code that saves the
contents of the stack to a different memory location. Is there a way
to access stack pointer and stack size (and the direction in which the
stack is growing) on the tree level?
I already found STACK_SIZE and FRAME_ADDRESS on the RTL level, but
would like to avoid adding an RTL pass.
The explanation why I want to save the stack contents is the following:
Code:
... use stack variables
__tm_atomic { /* begin transaction */
access shared locations in here
} /* may rollback */
In case of a rollback the original context of the thread must be
restored so that it may execute the transaction again. This will be
done using setjmp/longjmp. To prevent instrumenting all accesses to
stack variables inside the transaction with STM runtime calls, the
stack should be copied back from memory and the previous state of the
stack variables is restored.
Any suggestions are helpful, thank you very much.
Regards,
Martin
Re: Internal abort call optimization?
David Kastrup <[EMAIL PROTECTED]> writes: > > However, the problem is obviously not restricted to Emacs. If the > "noreturn" attribute for the internal abort were removed, at least only > abort calls with compatible stack frame and the same (tentative) > followup code would get folded. That would avoid the worst > head-scratchers when trying to figure out what went wrong. Without noreturn gcc wouldn't know there is no return needed after the abort(). Disabling cross jumping would be probably better. I know of a couple of more cases where such an attribute would be useful. -Andi
Re: Internal abort call optimization?
On Tue, Jun 17, 2008 at 11:33 AM, Andi Kleen <[EMAIL PROTECTED]> wrote: > David Kastrup <[EMAIL PROTECTED]> writes: >> >> However, the problem is obviously not restricted to Emacs. If the >> "noreturn" attribute for the internal abort were removed, at least only >> abort calls with compatible stack frame and the same (tentative) >> followup code would get folded. That would avoid the worst >> head-scratchers when trying to figure out what went wrong. > > Without noreturn gcc wouldn't know there is no return needed after > the abort(). Disabling cross jumping would be probably better. > I know of a couple of more cases where such an attribute would > be useful. You can also build with -fno-builtin-abort. Richard.
Re: Internal abort call optimization?
Richard Guenther wrote: > On Tue, Jun 17, 2008 at 11:33 AM, Andi Kleen <[EMAIL PROTECTED]> wrote: >> David Kastrup <[EMAIL PROTECTED]> writes: >>> However, the problem is obviously not restricted to Emacs. If the >>> "noreturn" attribute for the internal abort were removed, at least only >>> abort calls with compatible stack frame and the same (tentative) >>> followup code would get folded. That would avoid the worst >>> head-scratchers when trying to figure out what went wrong. >> Without noreturn gcc wouldn't know there is no return needed after >> the abort(). Disabling cross jumping would be probably better. >> I know of a couple of more cases where such an attribute would >> be useful. > > You can also build with -fno-builtin-abort. But it would still cross jump the call then wouldn't it? -Andi
Re: Internal abort call optimization?
On Tue, Jun 17, 2008 at 12:04 PM, Andi Kleen <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: >> On Tue, Jun 17, 2008 at 11:33 AM, Andi Kleen <[EMAIL PROTECTED]> wrote: >>> David Kastrup <[EMAIL PROTECTED]> writes: However, the problem is obviously not restricted to Emacs. If the "noreturn" attribute for the internal abort were removed, at least only abort calls with compatible stack frame and the same (tentative) followup code would get folded. That would avoid the worst head-scratchers when trying to figure out what went wrong. >>> Without noreturn gcc wouldn't know there is no return needed after >>> the abort(). Disabling cross jumping would be probably better. >>> I know of a couple of more cases where such an attribute would >>> be useful. >> >> You can also build with -fno-builtin-abort. > > But it would still cross jump the call then wouldn't it? In principle yes, but the situations cross jumping applies would be less, as the compiler no longer knows abort will not return (it'll also get you some extra warnings because of this). Richard.
Re: Internal abort call optimization?
On Tue, Jun 17, 2008 at 12:04 PM, Andi Kleen <[EMAIL PROTECTED]> wrote: > But it would still cross jump the call then wouldn't it? Depends if they return to the same basic block next ... -- Pinski
Re: Internal abort call optimization?
On Tue, Jun 17, 2008 at 3:58 PM, David Kastrup <[EMAIL PROTECTED]> wrote: > Probably better would be to just disable the crossjumping optimization > for calls of abort. Maybe this would warrant a new attribute. Read the long thread starting at http://gcc.gnu.org/ml/gcc/2005-03/msg00568.html and let it rest ;-) Gr. Steven
Re: Internal abort call optimization?
On Tue, Jun 17, 2008 at 9:58 AM, David Kastrup <[EMAIL PROTECTED]> wrote: > > Hi, I reported a problem I have with abort to the glibc bug tracker at > http://sourceware.org/bugzilla/show_bug.cgi?id=6522> which might > provide some reading material. > > Anyway, it has been pointed out to me that the requested change would > not accomplish much anyway since GCC has its own builtin notion of the > abort function. > > So here is my beef with the current way abort calls get optimized: > basically it boils down to the interaction of -fcrossjumping (enabled > with -O2) and the noreturn attribute of abort. The combination of both > optimizations means that usually only one abort call will actually get > compiled into a compilation unit, and all calls will instead jump there > without bothering to clean the stack (after all, it is a noreturn > function). You are about 3 years late to the party on this one :) http://gcc.gnu.org/ml/gcc/2005-03/msg00568.html Realistically, you are not going to be able to get good stacktraces with optimized code for *other* reasons, abort is just the first thing you hit. You are much better off making an abort that gives you more correct info (see, for example gcc's fancy_abort) than trying to take the info you get at some random point in an optimized program, and then trying to build it into something useful for the user (as abort does).
Re: Stack Pointer/Size on GIMPLE?
Is there a way to
access stack pointer and stack size (and the direction in which the
stack is growing) on the tree level?
The explanation why I want to save the stack contents is the following:
Code:
... use stack variables
__tm_atomic { /* begin transaction */
access shared locations in here
} /* may rollback */
In case of a rollback the original context of the thread must be
restored so that it may execute the transaction again. This will be done
using setjmp/longjmp. To prevent instrumenting all accesses to stack
variables inside the transaction with STM runtime calls, the stack
should be copied back from memory and the previous state of the stack
variables is restored.
Any suggestions are helpful, thank you very much.
Hi Martin,
I don't know anything about GIMPLE, but I can address this issue. It sounds
like you are proposing to checkpoint (via copying) the entire stack eagerly at
the time you enter a transaction, in order to avoid transactional
instrumentation of stack accesses.
This is probably a bad idea, as the overhead of the instrumentation is
probably much less than the overhead of copying and restoring the stack.
You're also relying on your ability to detect stack accesses statically (in
order not to instrument them). If you can do this, then you can probably just
implement a lightweight lazy checkpoint scheme rather than an eager, full copy.
I think, based on your first post
(http://gcc.gnu.org/ml/gcc/2008-06/msg00193.html), that you are attempting to
interface with TinySTM, which does lazy versioning (write-buffering) anyway if
I recall correctly, so writes are going to be buffered aren't going to be
written back on an abort anyway, which is what you want.
If you are thinking about an eager versioning system, then you should take a
look at how stack access is dealt with in "Code Generation and Optimization
for Transactional Memory Constructs in an Unmanaged Language"
(http://portal.acm.org/citation.cfm?id=1251974.1252529), as the real issue is
trying to "undo" accesses into stack space between the setjmp and the longjmp.
Hope this helps.
Luke
Re: configuring in-tree gmp/mpfr with "none"?
On Sun, Jun 15, 2008 at 12:49 PM, Jay <[EMAIL PROTECTED]> wrote:
>
> When gcc configures the in-tree gmp/mpfr, why
> does it use --host=none-${host_vendor}-${host_os}
> --target=none-${host_vendor}-${host_os}
>
> instead of --host=${host_alias} --target=${target_alias}
>
> This "breaks" config.cache if used across directories, because the platforms
> change.
The reason why it is configured with none is so that it can be
transfered to more computers than your own.
-- Pinski
auto const ints and pointer issue
Hi,
I have stumbled upon a quirk that appears to me to be
illogical. Maybe someone can help me to understand this:
sample code ~
#include
const int gic = 0;
const int * gcip;
int * gip;
int main(int argc, char * argv[]) {
const int ic = 0;
const int * cip;
int * ip;
cip =
ip = (int *)cip;
*ip = 5;
printf("const int ic = %d *cip = %d *ip = %d\n", ic, *cip, *ip);
printf("&ic = %pcip = %pip = %p\n", &ic, cip, ip);
gcip = &gic;
gip = (int *)gcip;
#if 0
*gip = 5;
printf("global const int gic = %d *gcip = %d *gip = %d\n",
gic, *gcip, *gip);
printf("&gic = %p gcip = %p gip = %p\n", &gic, gcip, gip);
#endif
return 0;
}
output ~~
$ const_ints
const int ic = 0 *cip = 5 *ip = 5
&ic = 0xbfbd72a0cip = 0xbfbd72a0ip = 0xbfbd72a0
~~~
The global variable code would segfault, as I expected. But the
auto variable code gives this illogical result. I would appreciate
comments. I am not on this list, so please ensure I am cc'd with
any responses. I'll be happy to file a bug, if it is a bug.
Thanks,
Karen
--
Karen Shaeffer
Neuralscape, Palo Alto, Ca. 94306
[EMAIL PROTECTED] http://www.neuralscape.com
Re: auto const ints and pointer issue
Karen Shaeffer <[EMAIL PROTECTED]> writes:
> int main(int argc, char * argv[]) {
> const int ic = 0;
> const int * cip;
> int * ip;
> cip =
> ip = (int *)cip;
> *ip = 5;
> printf("const int ic = %d *cip = %d *ip = %d\n", ic, *cip, *ip);
> printf("&ic = %pcip = %pip = %p\n", &ic, cip, ip);
> gcip = &gic;
> gip = (int *)gcip;
> #if 0
> *gip = 5;
> printf("global const int gic = %d *gcip = %d *gip = %d\n",
> gic, *gcip, *gip);
> printf("&gic = %p gcip = %p gip = %p\n", &gic, gcip, gip);
> #endif
> return 0;
> }
>
> output ~~
> $ const_ints
> const int ic = 0 *cip = 5 *ip = 5
> &ic = 0xbfbd72a0cip = 0xbfbd72a0ip = 0xbfbd72a0
> ~~~
>
> The global variable code would segfault, as I expected. But the
> auto variable code gives this illogical result. I would appreciate
> comments. I am not on this list, so please ensure I am cc'd with
> any responses. I'll be happy to file a bug, if it is a bug.
Modifying a variable which is declared const is undefined behaviour.
You can not predict what happens.
Ian
Re: Thread safety annotations and analysis in GCC
Tom, Thanks a lot for pointing us to the sparse annotations. We will take a look and see what its support looks like. Le-chun On Sun, Jun 15, 2008 at 2:43 PM, Tom Tromey <[EMAIL PROTECTED]> wrote: >> "Le-Chun" == Le-Chun Wu <[EMAIL PROTECTED]> writes: > > Le-Chun> Here is the design doc for the proposed annotations: > Le-Chun> http://docs.google.com/Doc?id=ddqtfwhb_0c49t6zgr > > I am curious to know how this compares to the kind of lock checking > implemented in sparse, and in particular whether sparse annotations > could easily be translated to this style. > > Tom >
Re: auto const ints and pointer issue
On Tue, Jun 17, 2008 at 11:01:31AM -0700, Ian Lance Taylor wrote: > > > > output ~~ > > $ const_ints > > const int ic = 0 *cip = 5 *ip = 5 > > &ic = 0xbfbd72a0cip = 0xbfbd72a0ip = 0xbfbd72a0 > > ~~~ > > > > The global variable code would segfault, as I expected. But the > > auto variable code gives this illogical result. I would appreciate > > comments. I am not on this list, so please ensure I am cc'd with > > any responses. I'll be happy to file a bug, if it is a bug. > > Modifying a variable which is declared const is undefined behaviour. > You can not predict what happens. > > Ian Hi Ian, I can live with that. My problem was that the addresses cannot be correct. In my opinion, the undefined behavior should be limited to the value in the address or in some form of error. But to let the buggy code execute with addresses that are not accurate is a liberty I would hope could have been avoided. It just looks bad. I do realize, no one should have a gripe, because the code is buggy to begin with. But addresses should always be reported accurately IMHO. Of course, I obviously know nothing about compilers. (smiles ;) Thanks for your comments. Karen -- Karen Shaeffer Neuralscape, Palo Alto, Ca. 94306 [EMAIL PROTECTED] http://www.neuralscape.com
Re: C++ warnings vs. errors
2008/6/12 Jonathan Wakely:
> 2008/6/11 Volker Reichelt:
>> * Scopes in for-loops:
>>
>> void foo()
>> {
>>for (int i=0; i<10; ++i) {}
>>i = 0;
>> }
>>
>> warn.cc: In function 'void foo()':
>> warn.cc:4: warning: name lookup of 'i' changed for new ISO 'for' scoping
>> warn.cc:3: warning: using obsolete binding at 'i'
>
> I suggest making this a permerror and changing the text slightly, see
> http://gcc.gnu.org/ml/gcc/2008-01/msg00192.html
>
>> * Declaration with no type:
>>
>> foo() {}
>>
>> warn.cc:1: warning: ISO C++ forbids declaration of 'foo' with no type
>
> See the part about special handling of 'main' in
> http://gcc.gnu.org/ml/gcc/2008-01/msg00189.html
>
>
>> * Invalid use of 'template':
>> * Using 'struct' for a union:
>
> These two can both be fixed by changes in cp/parser.c - all cases of
> pedwarn that are not guarded by testing 'pedantic' should be
> permerrors.
Could a C++ maintainer please review this patch to turn most pedwarns
into permerrors.
This restores the previous behaviour without any switches: most
diagnostics are errors. The permerrors can be relaxed with
-fpermissive. When a warning was guarded by a test for the 'pedantic'
flag I left it as a pedwarn.
The interesting cases are:
* when 'main' is declared without a return type. I split one case into
a permerror and pedwarn.
* 'for' scoping. I removed the "new" from "new ISO 'for' scoping"
since the ISO standard is not new, and when C++0x arrives it would be
misleading.
* Should it really be a hard error for a class to declare itself as a
friend? I don't think it's expressly forbidden
e.g. class A { friend class A; };
I changed this to a permerror, restoring the old behaviour.
* I don't think the pedwarn in joust() in cp/call.c should be a
permerror, is this a GNU extension?
if (warn)
{
pedwarn ("\
ISO C++ says that these are ambiguous, even \
though the worst conversion for the first is better than \
the worst conversion for the second:");
print_z_candidate (_("candidate 1:"), w);
print_z_candidate (_("candidate 2:"), l);
}
* I don't know if these in cp/typeck.c should be permerrors, DTRT
implies not, but should tf_error be changed to tf_warning?
/* DTRT if one side is an overloaded function, but complain about it. */
if (type_unknown_p (op0))
{
tree t = instantiate_type (TREE_TYPE (op1), op0, tf_none);
if (t != error_mark_node)
{
if (complain & tf_error)
pedwarn ("assuming cast to type %qT from overloaded function",
TREE_TYPE (t));
op0 = t;
}
}
if (type_unknown_p (op1))
{
tree t = instantiate_type (TREE_TYPE (op0), op1, tf_none);
if (t != error_mark_node)
{
if (complain & tf_error)
pedwarn ("assuming cast to type %qT from overloaded function",
TREE_TYPE (t));
op1 = t;
}
}
tested linux/x86-64
Jon
permerrors.patch
Description: Binary data
Re: Internal abort call optimization?
"Daniel Berlin" <[EMAIL PROTECTED]> writes: > You are about 3 years late to the party on this one :) > > http://gcc.gnu.org/ml/gcc/2005-03/msg00568.html Yup. > Realistically, you are not going to be able to get good stacktraces > with optimized code for *other* reasons, abort is just the first thing > you hit. Oh, we are not talking about "not good stacktraces" here. We are talking about "completely different location, possibly even in a different function, and debug info that has nothing to do with the actual state of the stack frame". "Not good" is expected with optimization. "Catastrophically misleading" is a different category. Since one of the main points of "abort" _is_ the stack trace, that's a particularly bad function call to optimize in this manner. Omitting either the -fcrossjumping _or_ the noreturn optimizations would get this back into the "expected consequence of optimization on debugging" scale. It is the combination of them that makes it impossible for the debugger to figure out the current call situation and temporary variable/register/stackframe assignments. > You are much better off making an abort that gives you more correct > info (see, for example gcc's fancy_abort) than trying to take the info > you get at some random point in an optimized program, and then trying > to build it into something useful for the user (as abort does). But fancy_abort does not help in examining variables: they may be sitting on the stack or in registers. Without noreturn optimizations, at least the compiler would only crossjump to abort calls with equal continuation and equal data locations, so examining variables is still possible in the debugger and one can get a good guess at where one is currently. And without crossjumping, the debugging info might tell the debugger just how garbled the current data locations are. But with both active, stack data and return addresses are garbage. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: auto const ints and pointer issue
On Tue, Jun 17, 2008 at 11:01:31AM -0700, Ian Lance Taylor wrote: > > output ~~ > > $ const_ints > > const int ic = 0 *cip = 5 *ip = 5 > > &ic = 0xbfbd72a0cip = 0xbfbd72a0ip = 0xbfbd72a0 > > ~~~ > > > > The global variable code would segfault, as I expected. But the > > auto variable code gives this illogical result. I would appreciate > > comments. I am not on this list, so please ensure I am cc'd with > > any responses. I'll be happy to file a bug, if it is a bug. > > Modifying a variable which is declared const is undefined behaviour. > You can not predict what happens. > > Ian Hi Ian, I can appreciate that. My point was the addresses are not valid here. In my opinion, it seems reasonable to limit the undefined behavior to the value of the variable, or to some form of failure and error, up to and including crashing the process. But to implement the code in such a way to let the process proceed without error, and to have incorrect addresses as we see here, seems to be beyond the common sense scope of the bounds of what this assignment's undefined behavior potential effects might be. It is interesting. Thank you for your comment. Thanks, Karen -- Karen Shaeffer Neuralscape, Palo Alto, Ca. 94306 [EMAIL PROTECTED] http://www.neuralscape.com
Re: auto const ints and pointer issue
On Tue, Jun 17, 2008 at 9:44 PM, Karen Shaeffer <[EMAIL PROTECTED]> wrote: > On Tue, Jun 17, 2008 at 11:01:31AM -0700, Ian Lance Taylor wrote: >> > output ~~ >> > $ const_ints >> > const int ic = 0 *cip = 5 *ip = 5 >> > &ic = 0xbfbd72a0cip = 0xbfbd72a0ip = 0xbfbd72a0 >> > ~~~> In my opinion, it seems reasonable to limit the undefined > behavior to the value of the variable, or to some form of > failure and error, up to and including crashing the process. > But to implement the code in such a way to let the process > proceed without error, and to have incorrect addresses as we > see here, seems to be beyond the common sense scope of the bounds > of what this assignment's undefined behavior potential effects > might be. It is interesting. Thank you for your comment. I don't see the issue with the pointers being the same. I don't see what you are asking to be different. Casting from one pointer type to another is ok. So we can go from: cip = ip = (int *)cip; cip = ip; And cip should be the same as &ic at the end of that code sequence. Thanks, Andrew Pinski
Re: auto const ints and pointer issue
On Tue, Jun 17, 2008 at 09:52:17PM -0400, Andrew Pinski wrote: > On Tue, Jun 17, 2008 at 9:44 PM, Karen Shaeffer > <[EMAIL PROTECTED]> wrote: > > On Tue, Jun 17, 2008 at 11:01:31AM -0700, Ian Lance Taylor wrote: > >> > output ~~ > >> > $ const_ints > >> > const int ic = 0 *cip = 5 *ip = 5 > >> > &ic = 0xbfbd72a0cip = 0xbfbd72a0ip = 0xbfbd72a0 > >> > ~~~> > In my opinion, it seems reasonable to limit the undefined > > behavior to the value of the variable, or to some form of > > failure and error, up to and including crashing the process. > > But to implement the code in such a way to let the process > > proceed without error, and to have incorrect addresses as we > > see here, seems to be beyond the common sense scope of the bounds > > of what this assignment's undefined behavior potential effects > > might be. It is interesting. Thank you for your comment. > > I don't see the issue with the pointers being the same. I don't see > what you are asking to be different. Casting from one pointer type to > another is ok. So we can go from: > cip = > ip = (int *)cip; > cip = ip; > > And cip should be the same as &ic at the end of that code sequence. > > Thanks, > Andrew Pinski Hi Andrew, I see your point. My sticking point is that the process is actually running on a physical machine. And the addresses, although virtual, do translate to a unique physical memory location. And, the value stored in that location cannot be 0 and 5 at the same time. And my comments were addressing that the undefined behavior of this illegal assignment should not violate the physical constraints of what is actually stored in that physical address. I would be OK with -1 being stored in there, or zero, or whatever, or the process crashing, but what I see is not congruent with my thinking about the limits of the compiled binary at run-time. Obviously I need to rethink those assumptions. Thanks, Karen -- Karen Shaeffer Neuralscape, Palo Alto, Ca. 94306 [EMAIL PROTECTED] http://www.neuralscape.com
Re: auto const ints and pointer issue
Karen Shaeffer <[EMAIL PROTECTED]> writes: > I see your point. My sticking point is that the process is actually > running on a physical machine. And the addresses, although virtual, > do translate to a unique physical memory location. And, the value > stored in that location cannot be 0 and 5 at the same time. And my > comments were addressing that the undefined behavior of this illegal > assignment should not violate the physical constraints of what is > actually stored in that physical address. I would be OK with -1 > being stored in there, or zero, or whatever, or the process crashing, > but what I see is not congruent with my thinking about the limits > of the compiled binary at run-time. Obviously I need to rethink those > assumptions. Undefined behaviour is undefined behaviour. You can not predict what the compiler do. > the value > stored in that location cannot be 0 and 5 at the same time. No, but in the presence of undefined behaviour the compiler is perfectly free to assume that that is in fact the case. This isn't intentional, of course; it just falls out of other optimizations. Ian
RE: configuring in-tree gmp/mpfr with "none"?
[again as plain text]
Ah, I didn't realize any C or C++ code could be configured for other than a
specific processor but I guess that makes sense -- it is Makefile, config.h,
and such that are being modified, not the .o files, and they might be the same
across many configurations, like if the compiler command lines and #defines can
be the same, like if there is no need to know the size of a pointer or the
endianness, etc.. I guess more code should work this way if possible. Thanks
Andrew.
(Obviously a lot of source code is independent of pointer size, endianness, but
I haven't seen such configure processor=none use.).
- Jay
> Date: Tue, 17 Jun 2008 13:39:42 -0400
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: configuring in-tree gmp/mpfr with "none"?
> CC: gcc@gcc.gnu.org
>
> On Sun, Jun 15, 2008 at 12:49 PM, Jay wrote:
>>
>> When gcc configures the in-tree gmp/mpfr, why
>> does it use --host=none-${host_vendor}-${host_os}
>> --target=none-${host_vendor}-${host_os}
>>
>> instead of --host=${host_alias} --target=${target_alias}
>>
>> This "breaks" config.cache if used across directories, because the platforms
>> change.
>
> The reason why it is configured with none is so that it can be
> transfered to more computers than your own.
>
> -- Pinski
gcc-in-cxx branch created
As I promised at the summit today, I have created the branch gcc-in-cxx (I originally said gcc-in-c++, but I decided that it was better to avoid possible meta-characters). The goal of this branch is to develop a version of gcc which is compiled with C++. Here are my presentation slides in PDF format: http://airs.com/ian/cxx-slides.pdf . I have not yet committed any patches to the branch--at present it is just a copy of the trunk. I will start committing patches soon, and anybody else may submit patches as well. The branch will follow the usual gcc maintainership rules, except that any non-algorithmic maintainer may additionally approve or commit patches which permit compilation with C++. I have committed the appended patch to htdocs/svn.html. Ian Index: svn.html === RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v retrieving revision 1.86 diff -u -r1.86 svn.html --- svn.html 12 Jun 2008 14:22:37 - 1.86 +++ svn.html 18 Jun 2008 06:00:13 - @@ -410,6 +410,14 @@ [function-specific] in the subject line. The branch is maintained by Michael Meissner. + gcc-in-cxx + This branch is for converting gcc to be written in C++. Patches + should be marked with the tag [gcc-in-cxx] in the + subject line. This branch operates under the general gcc + maintainership rules, except that any non-algorithmic maintainer is + additionally permitted to approve changes which permit compilation + with C++. The branch is maintained by Ian Lance Taylor. + Architecture-specific
Re[2]: auto const ints and pointer issue
Hello Karen,
Tuesday, June 17, 2008, 10:38:20 PM, you wrote:
> Hi Ian, I can live with that. My problem was that the addresses
> cannot be correct. In my opinion, the undefined behavior should be
> limited to the value in the address or in some form of error. But to
> let the buggy code execute with addresses that are not accurate is a
> liberty I would hope could have been avoided. It just looks bad. I
> do realize, no one should have a gripe, because the code is buggy to
> begin with. But addresses should always be reported accurately IMHO.
> Of course, I obviously know nothing about compilers. (smiles ;)
I don't see why the addresses are not correct. You should explore
compiler's assembler output to see what's really going there. But
let us check the case here for now.
int main(int argc, char * argv[]) {
const int ic = 0;
const int * cip;
int * ip;
cip =
ip = (int *)cip;
*ip = 5;
printf("const int ic = %d *cip = %d *ip = %d\n", ic, *cip, *ip);
printf("&ic = %pcip = %pip = %p\n", &ic, cip, ip);
}
As I see this case, gcc just puts `const int ic` value in register
(its ok since it is declared const and cannot be changed in runtime)
(you can even assume that it's reading it from its place in memory)
and that value from the register gets pushed on the stack for
printf() argument. Of course, it is not modified by your later
assignment because of compiler assumption that consts cannot change.
If you consider that this way, there's no problem in what gcc does
and what addresses/values are returned.
--
Best regards,
Dmitrymailto:[EMAIL PROTECTED]
