Re: GNU Pascal branch
Adriaan van Os writes: > Steven Bosscher wrote: > > > Ed Smith-Rowland <[EMAIL PROTECTED]> wrote: > >> All, > >> > >> FWIW, I would like to add my support for creating a branch for gpc > >> with > >> the eventual goal > >> of integrating Pascal into mainline. > > > > While I agree with most of the the points you make, the issue is not > > whether GCC should allow a gpc-branch to be created or not. I think > > that question would be just be a formality, if it were clear that the > > maintainers of GNU Pascal want integration with GCC. > > > > The fact is, that the GNU Pascal crew did not want integration with > > gcc the last time this was discussed. GCC, the project, can not just > > suck in every front end out there if the maintainers of that front end > > do not want that. > > Apparently, the GNU Pascal crew did not want integration with every > buggy back-end that sucks out there. So enable GNU Pascal only on those back-ends on which it works correctly. It's not difficult. > >> Thanks for your great cooperation. > > > > Perhaps you should go look for a mirror and say this again. > > At least, I don't need to look in the mirror to see someone barking. > > Can we have a normal discussion please ? Try to become a mature human > being. Is your juxtaposition of these two sentences intended to be ironic? Andrew.
[RFH] negate_expr_p bug?
negate_expr_p currently contains
switch (TREE_CODE (t))
{
case INTEGER_CST:
if (TYPE_UNSIGNED (type) || ! flag_trapv)
return true;
/* Check that -CST will not overflow type. */
return may_negate_without_overflow_p (t);
where it looks bogus to simply return true for signed types but
unset flag_trapv. This was introduced by Roger
@@ -822,8 +853,8 @@ negate_expr_p (tree t)
switch (TREE_CODE (t))
{
case INTEGER_CST:
- if (TREE_UNSIGNED (type))
- return false;
+ if (TREE_UNSIGNED (type) || ! flag_trapv)
+ return true;
/* Check that -CST will not overflow type. */
prec = TYPE_PRECISION (type);
with r72381
2003-10-11 Roger Sayle <[EMAIL PROTECTED]>
+ (negate_expr_p): We can always negate integer constants unless
+ we honor -ftrapv and the signed type would overflow.
which is bogus as it should read || (!flag_trapv && flag_wrapv) - no?
I hit this with a patch to fold A +- CST to A -+ CST for negative CST,
which tells me it is ok to negate -INT_MAX.
Fix outlined above ok for mainline?
Thanks,
Richard.
New test: Float_2.java
Rafael Espíndola writes:
> The attached patch removes the convert callback by
> 1) copying the c implementation of convert to convert2
> 2) changing all calls to convert in gcj and gfortran into calls to convert2
> 3) adding a lang prefix to the remaining implementations (cxx_, c_, gnat_)
> 4) renaming all convert calls in a front end to the corresponding
> implementation
> 5) coping convert_and_check and constant_fits_type_p into the c++
> front end so that it doesn't try to use convert2
> 6) renaming all the remaining calls to convert into convert2
> 7) removing the treelang, java and fortran implementation of convert
>
> This patch was bootstraped and regtested on a x86 without any regressions!
>
> I found a bit strange that there were no java regression since
> convert_ieee_real_to_integer is no longer used. Is a testcase missing?
There's one in mauve. I added this to the libgcj testsuite.
The libgcj testsuite isn't a complete test of the Java language, and I
don't think gcc developers would thank us if we made it one!
Andrew.
2006-04-03 Andrew Haley <[EMAIL PROTECTED]>
* testsuite/libjava.lang/Float_2.java: New file.
Index: testsuite/libjava.lang/Float_2.java
===
--- testsuite/libjava.lang/Float_2.java (revision 0)
+++ testsuite/libjava.lang/Float_2.java (revision 0)
@@ -0,0 +1,138 @@
+// Test floating-point to integer conversion. We do this twice, once
+// with literal conversions that can be optimized away and once using
+// a static field that can't.
+
+public class Float_2
+{
+ public static double zero = 0.0;
+
+ public static void main (String argv[])
+ {
+{
+ int itest = (int)(float)(0.0/0.0);
+ if (itest != 0)
+ System.err.println ("literal inf error 1: " + itest);
+}
+{
+ int itest = (int)(0.0/0.0);
+ if (itest != 0)
+ System.err.println ("literal inf error 2" + itest);
+}
+{
+ long ltest = (long)(0.0/0.0);
+ if (ltest != 0)
+ System.err.println ("literal inf error 3" + ltest);
+}
+{
+ long ltest = (long)(float)(0.0/0.0);
+ if (ltest != 0)
+ System.err.println ("literal inf error 4" + ltest);
+}
+
+{
+ int itest = (int)(float)(1.0/0.0);
+ if (itest != Integer.MAX_VALUE)
+ System.err.println ("literal max error 1: " + itest);
+}
+{
+ int itest = (int)(1.0/0.0);
+ if (itest != Integer.MAX_VALUE)
+ System.err.println ("literal max error 2" + itest);
+}
+{
+ long ltest = (long)(1.0/0.0);
+ if (ltest != Long.MAX_VALUE)
+ System.err.println ("literal max error 3" + ltest);
+}
+{
+ long ltest = (long)(float)(1.0/0.0);
+ if (ltest != Long.MAX_VALUE)
+ System.err.println ("literal max error 4" + ltest);
+}
+
+{
+ int itest = (int)(float)(-1.0/0.0);
+ if (itest != Integer.MIN_VALUE)
+ System.err.println ("literal min error 1: " + itest);
+}
+{
+ int itest = (int)(-1.0/0.0);
+ if (itest != Integer.MIN_VALUE)
+ System.err.println ("literal min error 2" + itest);
+}
+{
+ long ltest = (long)(-1.0/0.0);
+ if (ltest != Long.MIN_VALUE)
+ System.err.println ("literal min error 3" + ltest);
+}
+{
+ long ltest = (long)(float)(-1.0/0.0);
+ if (ltest != Long.MIN_VALUE)
+ System.err.println ("literal min error 4" + ltest);
+}
+
+{
+ int itest = (int)(float)(zero/zero);
+ if (itest != 0)
+ System.err.println ("calc inf error 1: " + itest);
+}
+{
+ int itest = (int)(zero/zero);
+ if (itest != 0)
+ System.err.println ("calc inf error 2" + itest);
+}
+{
+ long ltest = (long)(zero/zero);
+ if (ltest != 0)
+ System.err.println ("calc inf error 3" + ltest);
+}
+{
+ long ltest = (long)(float)(zero/zero);
+ if (ltest != 0)
+ System.err.println ("calc inf error 4" + ltest);
+}
+
+{
+ int itest = (int)(float)(1.0/zero);
+ if (itest != Integer.MAX_VALUE)
+ System.err.println ("calc max error 1: " + itest);
+}
+{
+ int itest = (int)(1.0/zero);
+ if (itest != Integer.MAX_VALUE)
+ System.err.println ("calc max error 2" + itest);
+}
+{
+ long ltest = (long)(1.0/zero);
+ if (ltest != Long.MAX_VALUE)
+ System.err.println ("calc max error 3" + ltest);
+}
+{
+ long ltest = (long)(float)(1.0/zero);
+ if (ltest != Long.MAX_VALUE)
+ System.err.println ("calc max error 4" + ltest);
+}
+
+{
+ int itest = (int)(float)(-1.0/zero);
+ if (itest != Integer.MIN_VALUE)
+ System.err.println ("calc min error 1: " + itest);
+}
+{
+ int itest = (int)(-1.0/zero);
+ if (itest != Integer.MIN_VALU
supporting finer grained -Wextra
hi there.
i just enabled -Wextra to catch broken if statements,
i.e. to enable warnings on:
* An empty body occurs in an if or else statement.
however this unfortunately triggers other warnings that i can't
reasonably get rid of. here's a test snippet:
== test.c ==
typedef enum { VAL0 = 0, VAL1 = 1, VAL2 = 2 } PositiveEnum;
int main (int argc, char *argv[])
{
PositiveEnum ev = VAL1;
unsigned int limit = VAL2;
if (ev >= 0)
{}
if (ev <= limit)
{}
if (1)
;
return 0;
}
== test.c ==
compiled as C code, this will produce (with a 4.2 snapshot):
$ gcc -Wall -Wextra -Wno-unused -x c test.c
test.c: In function 'main':
test.c:6: warning: comparison of unsigned expression >= 0 is always true
test.c:11: warning: empty body in an if-statement
and compiled as C++ code:
$ gcc -Wall -Wextra -Wno-unused -x c++ test.c
test.c: In function 'int main(int, char**)':
test.c:8: warning: comparison between signed and unsigned integer expressions
test.c:11: warning: empty body in an if-statement
that means, for a header file that is used for C and C++ code, i simply
can't avoid one of those enum signedness warnings. simply because the enum
is treated as unsigened in C and as signed in C++.
now, aparently the enum related signedness warnings are unconditionally
enabled by -Wextra, as is the if-related warnings, from the man-page:
-Wextra
[...] Print extra warning messages for these events:
* An unsigned value is compared against zero with < or >=.
* An empty body occurs in an if or else statement.
since the enum related signedness warnings are clearly bogus [1], i'd
like to request new warning options, that allow enabling/disabling of
the empty-body vs. unsigned-zero-cmp warnings independently. that way
i can preserve "empty body in an if-statement" while getting rid of the
useless enum comparison warnings.
[1] i'm aware that the enum signedness comparison warnings could be worked
around by explicit casts or by adding a negative enum value. this would
just create new problems though, because aside from worsen readability,
casts tend to "blinden" the compiler with regards to whole classes of
other bugs, and adding a dummy enum value would affect API and auto
generated documentation.
---
ciaoTJ
GCC 4.1.0 doesn't generate DWARF 2 output for function arguments?
I've just upgraded to Fedora Core 5 (kernel 2.6.15-1.2054_FC5) and with the
program below I get results which didn't occur before (Fedora Core 3). I
posted them to [EMAIL PROTECTED] but I think something is up with GCC
4.1.0. I no longer have Core 3 so I've compared output with Mandrake. These
results are with DWARF 2. GCC 4.1.0 with stabs worked as expected
Nick http://www.inet.net.nz/~nickrob
/* -*- compile-command: "cc -g -o simple simple.c"; -*- */
main(int argc, char **argv) {
int i;
i = 1;
}
After starting execution and breaking at main:
With gcc --version
gcc (GCC) 3.2 (Mandrake Linux 9.0 3.2-1mdk)
(gdb) info args
argc = 1
argv = (char **) 0xb7a4
With gcc --version
gcc (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3)
(gdb) info args
No arguments.
readelf -wi simple (for GCC 3.2) gives (about 1200 lines of output):
...
<2>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: (indirect string, offset: 0x98e): argc
DW_AT_decl_file : 1
DW_AT_decl_line : 3
DW_AT_type:
DW_AT_location: 2 byte block: 91 8 (DW_OP_fbreg: 8; )
<2>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: (indirect string, offset: 0x993): argv
DW_AT_decl_file : 1
DW_AT_decl_line : 3
DW_AT_type:
DW_AT_location: 2 byte block: 91 c (DW_OP_fbreg: 12; )
<2>: Abbrev Number: 4 (DW_TAG_variable)
DW_AT_name: i
DW_AT_decl_file : 1
DW_AT_decl_line : 4
DW_AT_type:
DW_AT_location: 2 byte block: 91 7c(DW_OP_fbreg: -4; )
...
readelf -wi simple (for GCC 4.1.0) gives (about 60 lines of output):
...
<2><75>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: argc
DW_AT_decl_file : 1
DW_AT_decl_line : 3
DW_AT_type: <9a>
<2><81>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: argv
DW_AT_decl_file : 1
DW_AT_decl_line : 3
DW_AT_type:
<2><8d>: Abbrev Number: 4 (DW_TAG_variable)
DW_AT_name: i
DW_AT_decl_file : 1
DW_AT_decl_line : 4
DW_AT_type: <9a>
DW_AT_location: 2 byte block: 91 70(DW_OP_fbreg: -16)
...
Re: GNU Pascal branch
I hope I am viewed as an impartial but interested third party. I would really like to see this happen. I did not know about gpc until a few weeks ago when I did a google search. I may be mistaken but I think the TeX community would be very interested in a GNU based Pascal. I am aware that GCC has an Ada front end because it is all over the GCC documentation. I think integrating gpc into gcc would increase its exposure. I don't know the history and I don't know the technical problems but I see a lot of animosity between various people and it raises my fear that this is not going to succeed. What is the next step that needs to happen to get the integration of gpc into gcc accomplished? Perry
[patch] duplicate convert_and_check in the c++ front end
The attached patch duplicates convert_and_check into the c++ front
end. I would like to include it to be able to remove the convert
callback latter on. Duplicating convert_and_check makes it is easy to
use cxx_convert in the c++ front end and c_convert in the c front end.
Thanks,
Rafael
2006-04-03 Rafael Ávila de Espíndola <[EMAIL PROTECTED]>
* gcc/cp/call.c (constant_fits_type_p): New function
(cxx_convert_and_check): New function
(convert_like_real): Use cxx_convert_and_check
instead of convert_and_check
Index: gcc/cp/call.c
===
--- gcc/cp/call.c (revision 112530)
+++ gcc/cp/call.c (working copy)
@@ -4141,7 +4141,57 @@
return expr;
}
+/* Nonzero if constant C has a value that is permissible
+ for type TYPE (an INTEGER_TYPE). */
+static int
+constant_fits_type_p (tree c, tree type)
+{
+ if (TREE_CODE (c) == INTEGER_CST)
+return int_fits_type_p (c, type);
+
+ c = convert (type, c);
+ return !TREE_OVERFLOW (c);
+}
+
+/* Convert EXPR to TYPE, warning about conversion problems with constants.
+ Invoke this function on every expression that is converted implicitly,
+ i.e. because of language rules and not because of an explicit cast. */
+
+static tree
+cxx_convert_and_check (tree type, tree expr)
+{
+ tree t = convert (type, expr);
+ if (TREE_CODE (t) == INTEGER_CST)
+{
+ if (TREE_OVERFLOW (t))
+ {
+ TREE_OVERFLOW (t) = 0;
+
+ /* Do not diagnose overflow in a constant expression merely
+ because a conversion overflowed. */
+ TREE_CONSTANT_OVERFLOW (t) = TREE_CONSTANT_OVERFLOW (expr);
+
+ /* No warning for converting 0x8000 to int. */
+ if (!(TYPE_UNSIGNED (type) < TYPE_UNSIGNED (TREE_TYPE (expr))
+ && TREE_CODE (TREE_TYPE (expr)) == INTEGER_TYPE
+ && TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (expr
+ /* If EXPR fits in the unsigned version of TYPE,
+ don't warn unless pedantic. */
+ if ((pedantic
+ || TYPE_UNSIGNED (type)
+ || !constant_fits_type_p (expr,
+ c_common_unsigned_type (type))
+ )
+ && skip_evaluation == 0)
+ warning (0, "overflow in implicit constant conversion");
+ }
+ else
+ unsigned_conversion_warning (t, expr);
+}
+ return t;
+}
+
/* Perform the conversions in CONVS on the expression EXPR. FN and
ARGNUM are used for diagnostics. ARGNUM is zero based, -1
indicates the `this' argument of a method. INNER is nonzero when
@@ -4413,7 +4463,7 @@
}
if (issue_conversion_warnings)
-expr = convert_and_check (totype, expr);
+expr = cxx_convert_and_check (totype, expr);
else
expr = convert (totype, expr);
Re: GNU Pascal branch
Steven Bosscher wrote: > The fact is, that the GNU Pascal crew did not want integration with > gcc the last time this was discussed. GCC, the project, can not just > suck in every front end out there if the maintainers of that front end > do not want that. Not "did not want integration". At leat I personally would support integration very much. But there are practical problems: 1) When gcc releases version n gcc development works with version n+1. At the same time gpc developers typically work with gcc version n-1. So, there is substantial work involved to update gpc from gcc version n-1 to gcc version n+1 2) Adjusting gpc development model. In particular, gpc uses rather short feedback loop: new features are released (as alphas) when they are ready. This is possible because gpc uses stable backend, so that users are exposed only to front end bugs. With development backends there is a danger that normal user will try new front end features only after full gcc release. 3) gcc develops in lockstep, which requires constant attention from maintainers. It is clear if such attention will be available. I must say that in last few years there were frequenty weeks in which I had no time for gpc work and even some such months. Also, I have problems with "all or nothing" attitude to integration. gpc is a mature front and to keep comunity alive it has to regularly deliver bug fixes and enhancements. Realistically, succesfull integration started when gcc development version is n+1 can deliver stable gpc first in version n+2 (n+1 version almost surely will contain serious bugs). Which means 2-3 years after starting integration. 2-3 years without a stable release may disintegrate the gpc comunity. Also, there is a risk that integration will just not work (if in tree gpc turns out to be too buggy gcc developers may just skip testing it resulting in even more bit-rot). So, please understand that I do not want to drop work on all-backend gpc before success of gpc tied to current backend is clear. And since I was multiple time assured that all-backend gpc is inacceptable in gcc tree I have tried to update out of tree gpc to support current development version of gcc. Since gcc is a moving target that turned out to require more effort that I can spent on gpc. Finally, coming to original topic: I do not know if Adrian's idea is a good one. But I think that his intention was to bring gcc and gpc development closer together with integration as an ultimate goal. -- Waldek Hebisch [EMAIL PROTECTED]
Re: GNU Pascal branch
On 4/3/06, Waldek Hebisch <[EMAIL PROTECTED]> wrote: > Steven Bosscher wrote: > > > The fact is, that the GNU Pascal crew did not want integration with > > gcc the last time this was discussed. GCC, the project, can not just > > suck in every front end out there if the maintainers of that front end > > do not want that. > > Not "did not want integration". At leat I personally would support > integration very much. But there are practical problems: > > 1) When gcc releases version n gcc development works with version n+1. >At the same time gpc developers typically work with gcc version n-1. >So, there is substantial work involved to update gpc from gcc version n-1 >to gcc version n+1 > 2) Adjusting gpc development model. In particular, gpc uses rather short >feedback loop: new features are released (as alphas) when they are ready. >This is possible because gpc uses stable backend, so that users are >exposed only to front end bugs. With development backends there is a >danger that normal user will try new front end features only after >full gcc release. There's already precedent of a "somewhat different" development model - the gfortran frontend, which usually backports a large number of non regression-fixes and features to gcc version n (where n+1 is current development mainline in your numbering). Gpc clearly would be in a similar position, same for a different model regarding maintainership and patch approval for the frontend parts, here again gfortran is special. Dot releases of stable gcc series (version n and sometimes n-1) are released regularly, roughly in a 3 month cycle, which should be an acceptable worst delay to get hands at some new nifty gpc frontend features that got backported. Richard.
Re: GCC 4.1.0 doesn't generate DWARF 2 output for function arguments?
On Mon, Apr 03, 2006 at 11:21:35PM +1200, Nick Roberts wrote: > > I've just upgraded to Fedora Core 5 (kernel 2.6.15-1.2054_FC5) and with the > program below I get results which didn't occur before (Fedora Core 3). I > posted them to [EMAIL PROTECTED] but I think something is up with GCC > 4.1.0. I no longer have Core 3 so I've compared output with Mandrake. These > results are with DWARF 2. GCC 4.1.0 with stabs worked as expected They've been optimized away. Not surprising, since they are unused, although slightly surprising that it happened with -O0. On x86, where they're on the stack on entry, we could probably have done better even with optimization. -- Daniel Jacobowitz CodeSourcery
gcc3.4.5: bug with inline on ppc405?
Hi,
I've run into a piece of code on ppc405 that does the wrong thing when a
function is automatically inlined. I don't really do ppc asm so I
haven't been able to isolate what exactly the problem is, but the code
blatantly takes the wrong branch.
The toolchain I'm using is a cross compiler from x86 to ppc. The target
is a 405gp. I built this gcc-3.4.5/binutils-2.15/glibc-2.3.6 compiler
using crosstools-0.42
Reading specs from
/home/mort/src/targa/powerpc-linux/gcc-3.4.5-glibc-2.3.6/powerpc-405-linux-gnu/bin/../lib/gcc/powerpc-405-linux-gnu/3.4.5/specs
Configured with:
/home/mort/src/crosstool-0.42/build/powerpc-405-linux-gnu/gcc-3.4.5-glibc-2.3.6/gcc-3.4.5/configure
--target=powerpc-405-linux-gnu --host=i686-host_pc-linux-gnu
--prefix=/opt/targa/local/powerpc-linux/gcc-3.4.5-glibc-2.3.6/powerpc-405-linux-gnu
--with-cpu=405 --enable-cxx-flags=-mcpu=405
--with-headers=/opt/targa/local/powerpc-linux/gcc-3.4.5-glibc-2.3.6/powerpc-405-linux-gnu/powerpc-405-linux-gnu/include
--with-local-prefix=/opt/targa/local/powerpc-linux/gcc-3.4.5-glibc-2.3.6/powerpc-405-linux-gnu/powerpc-405-linux-gnu
--disable-nls --enable-threads=posix --enable-symvers=gnu
--enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99
--enable-long-long
Thread model: posix
gcc version 3.4.5
The problem I'm having is when running the CPU post test on u-boot
1.1.4. Specifically, in the branch tests. While doing the first branch
conditional test the computer incorrectly takes the "if (link)" branch
in u-boot/post/cpu/b.c::cpu_post_test_bc()
--- a/post/cpu/b.c
+++ b/post/cpu/b.c
@@ -84,10 +84,14 @@ static int cpu_post_test_bc (ulong cmd,
}
if (ret == 0)
{
- if (link)
+printf("link = %d\n", link);
+if (link)
ret = lr == (ulong) code + 24 ? 0 : -1;
else
ret = lr == 0 ? 0 : -1;
+ if (ret)
+ printf("ret = %d, link = %lx, code = %p, lr = %lx\n",
+ ret, link, code, lr);
}
return ret;
---
Running with this small change, I get:
POST cpu link = 0
ret = -1, link = 0, code = 03fa5ab8, lr = 0
It looks clear to me that link == 0, so the test worked fine.
However, if I take away the "static" from the cpu_post_test_bc()
declaration then everything works fine. Everything also works fine if I
leave the static, but also add the 'noinline' function attribute.
I've posted "objdump -dS" output for post/cpu/b.o with and without
cpu_post_test_bc() declared as static at:
http://www.bork.org/~mort/ppcstatic/
Any hints appreciated. Let me know if any other info is required.
mh
--
Martin Hicks || [EMAIL PROTECTED] || PGP/GnuPG: 0x4C7F2BEE
signature.asc
Description: Digital signature
Re: [patch] duplicate convert_and_check in the c++ front end
On 4/3/06, Rafael Espíndola <[EMAIL PROTECTED]> wrote: > The attached patch duplicates convert_and_check into the c++ front > end. *cough* Non-normatively speaking, code duplication sucks :-) Is there a reason why you can't use c-common.* and c_dialect_cxx() instead? Gr. Steven
Re: [RFH] negate_expr_p bug?
On Mon, 3 Apr 2006, Richard Guenther wrote:
> negate_expr_p currently contains
> ...
> where it looks bogus to simply return true for signed types but
> unset flag_trapv.
> ...
> which is bogus as it should read || (!flag_trapv && flag_wrapv) - no?
> I hit this with a patch to fold A +- CST to A -+ CST for negative CST,
> which tells me it is ok to negate -INT_MAX.
I suspect the problem is in the use of negate_expr_p. This predicate
is designed for integer constants to check whether it is reasonable to
evaluate NEG_EXPR at compile-time.
Hence, fold will/can convert:
int foo()
{
return -INT_MIN;
}
into "return INT_MIN;" during tree-ssa, provided that we don't rely
on trapping math. i.e. we take advantage of the undefined behaviour
of signed types, with or without flag_wrapv.
The real question is whether your new transformation is using
negate_expr_p correctly. It sounds as though you may be introducing
an overflow that wasn't there before, in which case you need to be
testing flag_wrapv && !flag_trapv in the calling clause.
negate_expr_p (t) is simply an efficient version of
temp = fold_build1 (NEGATE_EXPR, type, t);
return TREE_CODE (temp) != NEGATE_EXPR;
and its logic precisely mirrors the equivalent code in negate_expr.
Perhaps some of the logic in fold_negate_const is more appropriate:
temp = fold_negate_const (arg0, type);
return !TREE_OVERFLOW (temp);
I hope this helps.
Roger
--
Re: [RFH] negate_expr_p bug?
On Mon, 3 Apr 2006, Roger Sayle wrote:
>
> On Mon, 3 Apr 2006, Richard Guenther wrote:
> > negate_expr_p currently contains
> > ...
> > where it looks bogus to simply return true for signed types but
> > unset flag_trapv.
> > ...
> > which is bogus as it should read || (!flag_trapv && flag_wrapv) - no?
> > I hit this with a patch to fold A +- CST to A -+ CST for negative CST,
> > which tells me it is ok to negate -INT_MAX.
>
> I suspect the problem is in the use of negate_expr_p. This predicate
> is designed for integer constants to check whether it is reasonable to
> evaluate NEG_EXPR at compile-time.
>
> Hence, fold will/can convert:
>
> int foo()
> {
> return -INT_MIN;
> }
>
> into "return INT_MIN;" during tree-ssa, provided that we don't rely
> on trapping math. i.e. we take advantage of the undefined behaviour
> of signed types, with or without flag_wrapv.
Hmm, but then, we would be allowed to transform A - -INT_MIN to
A + INT_MIN, correct?
Now, I'm trying to teach fold_binary to transform i - -1 to i + 1 by
adjusting
/* A - B -> A + (-B) if B is easily negatable. */
if (negate_expr_p (arg1)
&& ((FLOAT_TYPE_P (type)
/* Avoid this transformation if B is a positive REAL_CST.
*/
&& (TREE_CODE (arg1) != REAL_CST
|| REAL_VALUE_NEGATIVE (TREE_REAL_CST (arg1
|| (INTEGRAL_TYPE_P (type) && flag_wrapv && !flag_trapv)))
return fold_build2 (PLUS_EXPR, type,
fold_convert (type, arg0),
fold_convert (type, negate_expr (arg1)));
which at the moment does not do that if flag_wrapv is not set. If your
reasoning is correct, we can simply replace the last line in the condition
with
|| (TREE_CODE (type) == INTEGER_TYPE
&& (TREE_CODE (arg1) == INTEGER_CST
|| TYPE_UNSIGNED (type)
|| (flag_wrapv && !flag_trapv)))
(only do it for INTEGER_TYPE to avoid negating pointer constants)
Now for constants this is always valid due to your reasoning, for unsigned
types anyway and else if flag_wrapv and no trapping v is in effect.
Does this sound reasonable?
Thanks,
Richard.
Re: [RFH] negate_expr_p bug?
On Mon, 3 Apr 2006, Richard Guenther wrote: > > || (TREE_CODE (type) == INTEGER_TYPE >&& (TREE_CODE (arg1) == INTEGER_CST >|| TYPE_UNSIGNED (type) >|| (flag_wrapv && !flag_trapv))) > > Does this sound reasonable? Yes, this sounds reasonable. It was not the negate_expr_p call that's causing your problems but the overly restrictive guard on this transformation. Let me know the results of a bootstrap and regression test in case that points out something I've missed. Roger --
Re: GNU Pascal branch
On Apr 3, 2006, at 09:34, Waldek Hebisch wrote: 2) Adjusting gpc development model. In particular, gpc uses rather short feedback loop: new features are released (as alphas) when they are ready. This is possible because gpc uses stable backend, so that users are exposed only to front end bugs. With development backends there is a danger that normal user will try new front end features only after full gcc release. For Ada, we use the same front end sources with different back end versions. Typically, the only changes are in the few files that convert Ada trees to GCC trees. So, every day you build your latest gpc with all cool new features. One build uses the latest GCC back end and the other one uses a stable release series. -Geert
unwind-dw2.c gthread_once SNAFU (Was: Re: RFA: generic threads support)
Mark Mitchell wrote:
You also need documentation for this feature, discussing both the new
configure switch, and what you have to do to replace the generic
functions, and what the semantics of those functions are, so that people
know how to replace them.
The semantics of these functions are exactly that of the internal gthreads
interface of gcc. Of course, such a description is not very useful for
a prospective
implementor. I started to look at the sources to come up with
descriptions, and
found that this interface is not even self-consistent.
gthr.h states that a number of functions can -1 for unimplemented
operations,
and various stub implementations do just that.
The logic in uw_init_context_1:unwind-dw2.c is garbled so that when
__GTHREADS
is defined but __gthread_once is unimplemented,
init_dwarf_reg_size_table is
called all the time:
#if __GTHREADS
{
static __gthread_once_t once_regsizes = __GTHREAD_nit_dwONCE_INIT;
if (__gthread_once (&once_regsizes, init_dwarf_reg_size_table) != 0
|| dwarf_reg_size_table[0] == 0)
init_dwarf_reg_size_table ();
}
#else
if (dwarf_reg_size_table[0] == 0)
init_dwarf_reg_size_table ();
#endif
That '||' should rather be an '&&'.
Or maybe we should make __gthread_once also succeed in the non-threading
case?
That should be simple enough, and should also allow to simplify
libstdc++-v3/include/ext/mt_allocator.h .
Re: GCC 4.1.0 doesn't generate DWARF 2 output for function arguments?
> They've been optimized away. Not surprising, since they are unused, > although slightly surprising that it happened with -O0. The manual says: `-O0' Do not optimize. This is the default. so that seems to be a documentation bug at least. More generally, it seems odd to force an optimization on a user that he might not want. Its interesting that a quote on Bugzilla says that debugging is twice as hard as writing code. If thats the case, theres no point in making it any harder. It also causes GDB to generate errors on the output of other commands: (gdb) info locals argc = Cannot access memory at address 0x0 as well as the GDB/MI equivalent -stack-list-locals. This breaks the front end that I'm writing fo Emacs. I'm sure that GDB can be rewritten to overcome this but what other optimizations do/will GCC developers decide users must have? The above optimization seems just to save a few bytes unless a program is deeply nested. Why not reserve it for -O1 and higher? Nick http://www.inet.net.nz/~nickrob
Re: GCC 4.1.0 doesn't generate DWARF 2 output for function arguments?
On Tue, Apr 04, 2006 at 09:05:28AM +1200, Nick Roberts wrote: > It also causes GDB to generate errors on the output of other commands: > > (gdb) info locals > argc = Cannot access memory at address 0x0 > > as well as the GDB/MI equivalent -stack-list-locals. This breaks the front > end that I'm writing fo Emacs. That's a bug in GDB, and not hard to fix. You're welcome to do it, or to file it in GNATS :-) > I'm sure that GDB can be rewritten to overcome this but what other > optimizations do/will GCC developers decide users must have? The above > optimization seems just to save a few bytes unless a program is deeply nested. > Why not reserve it for -O1 and higher? This is not how compiler optimization works. It is probably an accident resulting from the compiler's internal representation. You may want to file it in the GCC bug tracking system, if there is not already an equivalent bug. -- Daniel Jacobowitz CodeSourcery
Re: GNU Pascal branch
On Apr 1, 2006, at 7:26 AM, Ed Smith-Rowland wrote: 3. GPC would get much wider exposure. It would probably eventually ship along with the rest of gcc in OS distributions including *ahem* MacOSX. The GNU project doesn't set what is or becomes product for Apple. Or, put another way, we'll include C/C++/ObjC/ObjC++ but unlikely any other language including java,Ada,Fortran or Scheme. That said, it would (most likely) become product for the FSF gcc releases and projects like fink and opendarwin.
Re: GNU Pascal branch
On Apr 3, 2006, at 6:34 AM, Waldek Hebisch wrote: 2) Adjusting gpc development model. In particular, gpc uses rather short feedback loop: new features are released (as alphas) when they are ready. This is possible because gpc uses stable backend, so that users are exposed only to front end bugs. With development backends there is a danger that normal user will try new front end features only after full gcc release. You can backport enhancements (SC buy in) to the last release branch (or two, if you want to do the extra work) and `vend' snapshots off of that if you want. You could have a new version everyday if you wanted, with a max to-to-delivery measures in minutes, if you wanted. I'd encourage the SC to let you `add features' to suit your users. What you'd have a harder time doing is adding lots of new code or destabilizing code to the main part of the compiler on a release branch. 3) gcc develops in lockstep, which requires constant attention from maintainers. It is clear if such attention will be available. I must say that in last few years there were frequenty weeks in which I had no time for gpc work and even some such months. I wouldn't worry about this a whole lot, just mark Pascal as disabled by default and let everyone know that time-to-respond can be measures in months. Though, I'd guess that some people (Hi Andrew) would build it anyway and submit fixes to get it working/keep it working.
Re: GNU Pascal branch
On Apr 2, 2006, at 3:20 AM, Steven Bosscher wrote: The fact is, that the GNU Pascal crew did not want integration with gcc the last time this was discussed. GCC, the project, can not just suck in every front end out there if the maintainers of that front end do not want that. Actually, it can if certain conditions are met. :-) Roughly, copyright has to be clear and assigned to the FSF, and someone has to be willing to step forward and argue for it and do the grunt work of integrating it and hopefully volunteer to step forward and maintain it. This person need not be the original author(s). Wasn't Fortran an existence proof?
Re: GCC 4.1.0 doesn't generate DWARF 2 output for function arguments?
Nick Roberts wrote: Its interesting that a quote on Bugzilla says that debugging is twice as hard as writing code. This need not be the case, if you adopt sufficient discipline to write correct code the first time, debugging can be a minor part of the development process. Far too many people are in the habit these days of writing sloppy code and then spending ages bashing it into shape with the debugger :-( Well, off topic, I know, but the above quote irritated me! I'm sure that GDB can be rewritten to overcome this but what other optimizations do/will GCC developers decide users must have? The above optimization seems just to save a few bytes unless a program is deeply nested. Why not reserve it for -O1 and higher? In fact I agree that -O0 should not do any optimizations visible to the user of the debugger at the source level (I wish it would do a bit better job of generating reasonable code, subject to this criterion!)
Re: GCC 4.1.0 doesn't generate DWARF 2 output for function arguments?
On Mon, Apr 03, 2006 at 08:09:05PM -0400, Robert Dewar wrote: > In fact I agree that -O0 should not do any optimizations visible to > the user of the debugger at the source level (I wish it would do a > bit better job of generating reasonable code, subject to this criterion!) Let's be careful to distinguish code optimizations, and optimizations that avoid the generation of unnecessary debug information. It used to be that every once in a while, in response to a bug report, a GCC developer would make a change that doubles or triples the size of a debug executable. For C++, where the size can already be massive, this can be a killer.
Re: GCC 4.1.0 doesn't generate DWARF 2 output for function arguments?
Joe Buck wrote: Let's be careful to distinguish code optimizations, and optimizations that avoid the generation of unnecessary debug information. It used to be that every once in a while, in response to a bug report, a GCC developer would make a change that doubles or triples the size of a debug executable. For C++, where the size can already be massive, this can be a killer. Well makes sense, but of course the key word is "unnecessary" in the above para, that's what makes this not quite so straightforward :-)
Re: Darwin long doubles and controlled rounding
Roberto Bagnara <[EMAIL PROTECTED]> writes: > Hi there, > > I have read the files darwin-ldouble* in GCC 4.1.0. > What I would like do know is whether I can expect > long doubles on Darwin to comply with ISO C99 7.6 > (Floating-point environment). They can be made compliant with that section, but it requires cooperation from the project providing fenv.h. > I am particularly interested in the possibility > of setting the rounding mode with fesetround(). > Is this supported? This implementation only supports one rounding mode, FE_TONEAREST, so it's not useful to call fesetround().
libgomp -> MAINTAINERS
This is something I should have announced several weeks ago; to make up for this delay, I went ahead and took care of the patch to the MAINTAINERS file right away. I guess it's not a real surprise for those on this list, but let's thank Richard for contributing and agreeing to maintain libgomp! Gerald 2006-04-04 Gerald Pfeifer <[EMAIL PROTECTED]> * MAINTAINERS: Add Richard Henderson as libgomp maintainer. Rearrange the entries of other libraries to have them in one place. Index: MAINTAINERS === --- MAINTAINERS (revision 112646) +++ MAINTAINERS (working copy) @@ -143,6 +143,10 @@ libdecnumber Ben Elliston[EMAIL PROTECTED] libgcj Tom Tromey [EMAIL PROTECTED] libgcj Bryce McKinlay [EMAIL PROTECTED] +libgomp Richard Henderson [EMAIL PROTECTED] +libiberty DJ Delorie [EMAIL PROTECTED] +libiberty Ian Lance Taylorian@airs.com +libffi testsuite Andreas Tobler [EMAIL PROTECTED] libobjcNicola Pero [EMAIL PROTECTED] libobjcAndrew Pinski [EMAIL PROTECTED] loop discovery Michael Hayes [EMAIL PROTECTED] @@ -174,8 +178,6 @@ i18n Philipp Thomas [EMAIL PROTECTED] i18n Joseph Myers[EMAIL PROTECTED] diagnostic messagesGabriel Dos Reis[EMAIL PROTECTED] -libiberty DJ Delorie [EMAIL PROTECTED] -libiberty Ian Lance Taylorian@airs.com build machinery (*.in) DJ Delorie [EMAIL PROTECTED] build machinery (*.in) Nathanael Nerode[EMAIL PROTECTED] build machinery (*.in) Alexandre Oliva [EMAIL PROTECTED] @@ -186,7 +188,6 @@ gcov Jan Hubicka [EMAIL PROTECTED] gcov Nathan Sidwell [EMAIL PROTECTED] option handlingNeil Booth [EMAIL PROTECTED] -libffi testsuite Andreas Tobler [EMAIL PROTECTED] testsuite Janis Johnson [EMAIL PROTECTED] middle-end Roger Sayle [EMAIL PROTECTED] middle-end Ian Lance Taylorian@airs.com
Re: GCC SC request about ecj
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Tromey wrote: > > In particular we would like to import a copy of the ecj sources into > the GCC source tree, so that we can continue to deliver a complete > compiler system in a single download. > > So, could the SC please discuss the ecj plan and let us know whether > it is acceptable? It would also be helpful to have some idea of how > long the discussion might take. Did the SC get to deliberate on this issue? Was this message: http://gcc.gnu.org/ml/gcc/2006-03/msg00558.html on inclusion of source code from other projects in GCC a direct result of these discussions or a mere coincidence? Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEMhb/Yb1hx2wRS48RAuUIAJ9OoRzBhdt80k0uKP5eQELOZslQRACeJKfU yeVIfT7VJ00VFVmHgbrSz0U= =5n9c -END PGP SIGNATURE-
