Re: toplevel Makefile.tpl hacking
You can use make check-target-libgfortran, which is what I thought you were using to test. There's no testsuite for libgfortran (the command you mentionned does not test anything). The only way I'm aware of to run the gfortran testsuite is make check-fortran inside $builddir/gcc. I think I will soon have a patch ready to fix that last problem. FX
Build using --with-gmp and shared libraries
Here is a patch to fix PR libfortran/21547: when building with
--with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
$(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
correctly when using the freshly built gfortran to build libgfortran.
The same thing happens for the gfortran testsuite, and the fix is also
included in this patch.
Basic testing done on i686-linux (built with --languages=c,fortran and
a shared libgmp in /foo/bar, and regtested). Extended testing (which
takes ages on my computer) in progress.
OK for mainline? OK for 4.0?
:ADDPATCH build:
Index: Makefile.tpl
===
--- Makefile.tpl (revision 106019)
+++ Makefile.tpl (working copy)
@@ -157,6 +157,7 @@
OBJDUMP=$(OBJDUMP); export OBJDUMP; \
TOPLEVEL_CONFIGURE_ARGUMENTS=$(TOPLEVEL_CONFIGURE_ARGUMENTS); export TOPLEVEL_CONFIGURE_ARGUMENTS; \
GMPLIBS=$(HOST_GMPLIBS); export GMPLIBS; \
+ GMPLIBSDIR=$(HOST_GMPLIBSDIR); export GMPLIBSDIR; \
GMPINC=$(HOST_GMPINC); export GMPINC; \
@if gcc-bootstrap
$(RPATH_ENVVAR)=`echo $(TARGET_LIB_PATH)$$$(RPATH_ENVVAR) | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \
@@ -216,6 +217,7 @@
# Where to find GMP
HOST_GMPLIBS = @gmplibs@
+HOST_GMPLIBSDIR = @gmplibsdir@
HOST_GMPINC = @gmpinc@
# --
@@ -615,7 +617,7 @@
# Define HOST_LIB_PATH_gcc here, for the sake of TARGET_LIB_PATH, ouch
@if gcc
-HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/gcc:$$r/$(HOST_SUBDIR)/prev-gcc:
+HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/gcc:$$r/$(HOST_SUBDIR)/prev-gcc:$(HOST_GMPLIBSDIR):
@endif gcc
[+ FOR host_modules +][+ IF lib_path +]
Index: configure.in
===
--- configure.in (revision 106019)
+++ configure.in (working copy)
@@ -1058,6 +1058,7 @@
# Check for GMP and MPFR
gmplibs=
gmpinc=
+gmplibsdir=
have_gmp=yes
# Specify a location for mpfr
# check for this first so it ends up on the link line before gmp.
@@ -1075,6 +1076,7 @@
if test x$with_mpfr != x; then
gmplibs=-L$with_mpfr/lib $gmplibs
gmpinc=-I$with_mpfr/include
+ gmplibsdir=$with_mpfr/lib
fi
# Specify a location for gmp
@@ -1097,6 +1099,11 @@
if test x$with_gmp != x; then
gmplibs=-L$with_gmp/lib $gmplibs
gmpinc=-I$with_gmp/include $gmpinc
+ if test x$gmplibsdir != x; then
+gmplibsdir=$gmplibsdir:$with_gmp/lib
+ else
+gmplibsdir=$with_gmp/lib
+ fi
fi
saved_CFLAGS=$CFLAGS
@@ -1125,6 +1132,7 @@
# Flags needed for both GMP and/or MPFR
AC_SUBST(gmplibs)
AC_SUBST(gmpinc)
+AC_SUBST(gmplibsdir)
# By default, C is the only stage 1 language.
stage1_languages=c
Index: gcc/configure.ac
===
--- gcc/configure.ac (revision 106019)
+++ gcc/configure.ac (working copy)
@@ -3402,6 +3402,8 @@
AC_ARG_VAR(GMPLIBS,[How to link GMP])
AC_ARG_VAR(GMPINC,[How to find GMP include files])
+AC_ARG_VAR(GMPLIBSDIR,[Where to find the GMP library])
+AC_ARG_VAR(RPATH_ENVVAR,[How the systems locates libraries])
# Configure the subdirectories
# AC_CONFIG_SUBDIRS($subdirs)
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 106019)
+++ gcc/Makefile.in (working copy)
@@ -294,6 +294,8 @@
# How to find GMP
GMPLIBS = @GMPLIBS@
GMPINC = @GMPINC@
+GMPLIBSDIR = @GMPLIBSDIR@
+RPATH_ENVVAR = @RPATH_ENVVAR@
CPPLIB = ../libcpp/libcpp.a
CPPINC = -I$(srcdir)/../libcpp/include
@@ -3906,6 +3908,7 @@
srcdir=`cd ${srcdir}; ${PWD_COMMAND}` ; export srcdir ; \
cd $(TESTSUITEDIR); \
EXPECT=${EXPECT} ; export EXPECT ; \
+ $(RPATH_ENVVAR)=`echo $(GMPLIBSDIR):$$$(RPATH_ENVVAR) | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'` ; export $(RPATH_ENVVAR) ; \
if [ -f $${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWD_COMMAND}` ; \
export TCL_LIBRARY ; fi ; \
libgmp.ChangeLog
Description: Binary data
RE: diffing directories with merged-as-deleted files?
Phil Edwards wrote: On Fri, Nov 04, 2005 at 12:58:11AM +0100, Giovanni Bajo wrote: Joern RENNECKE [EMAIL PROTECTED] wrote: P.S.: When I use a diff-cmd with -N, I not only get a diff for the 44 files that are different, but also a header for each of the 752 files that are identical, i.e. two lines for each file like: Index: gcc/tree-ssa-operands.c === cvs would never do such nonsense. Ever seen the output from cvs diff -wBb? :) Absolutely! It would just print all the directory names in the middle of the diffs. I call that nonsense as well. Somewhere I have a tiny awk script to remove all that garbage, ping me if I should hunt it up. You do know that stuff comes out on stderr and can be piped separately from the rest of the output that comes on stdout, yeh? Or there's always cvs -q cmd. Either way a script seems overkill - even a tiny one. cheers, DaveK -- Can't think of a witty .sigline today
Re: GCC-generated code and i386 condition codes behavior
Hi Richard, On Wednesday 26 October 2005 00:30, Richard Henderson wrote: On Mon, Oct 24, 2005 at 03:39:53PM -0500, Bryan Ford wrote: My question: does GCC-generated code ever actually depend on this aspect of the x86 architecture - i.e., on instructions that architecturally change some but not all condition codes _not_ changing those bits that they're not supposed to change? No. Excellent - thanks very much for responding! Bryan
ref_contains_indirect_ref always false?
Hi!
it seems that
static inline bool
ref_contains_indirect_ref (tree ref)
{
while (handled_component_p (ref))
{
if (TREE_CODE (ref) == INDIRECT_REF)
return true;
ref = TREE_OPERAND (ref, 0);
}
return false;
}
always returns false, because handled_component_p (ref) returns
false for INDIRECT_REF:
int
handled_component_p (tree t)
{
switch (TREE_CODE (t))
{
case BIT_FIELD_REF:
case COMPONENT_REF:
case ARRAY_REF:
case ARRAY_RANGE_REF:
case VIEW_CONVERT_EXPR:
case REALPART_EXPR:
case IMAGPART_EXPR:
return 1;
default:
return 0;
}
}
am I missing something?
Richard.
Re: timezone of svn server for -r?
On 2005-11-03 22:58:17 +0100, Andreas Schwab wrote:
Joern RENNECKE [EMAIL PROTECTED] writes:
What timezone does the svn server use when I specify time date with -r?
The date is relative to your local timezone (the one of the client).
The server doesn't use a particular timezone.
From the subversion book:
Here are examples of the date formats that Subversion accepts.
Remember to use quotes around any date that contains spaces.
$ svn checkout --revision {2002-02-17}
$ svn checkout --revision {15:30}
$ svn checkout --revision {15:30:00.20}
$ svn checkout --revision {2002-02-17 15:30}
$ svn checkout --revision {2002-02-17 15:30 +0230}
$ svn checkout --revision {2002-02-17T15:30}
$ svn checkout --revision {2002-02-17T15:30Z}
$ svn checkout --revision {2002-02-17T15:30-04:00}
$ svn checkout --revision {20020217T1530}
$ svn checkout --revision {20020217T1530Z}
$ svn checkout --revision {20020217T1530-0500}
Use Z or + for the timezone.
Or if you want to always use UTC, you can set the TZ environment
variable to UTC, possibly via a shell alias if you do not want
that globally.
--
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Re: svn url shortcuts
On 2005-11-03 18:43:56 -0500, DJ Delorie wrote: This is crude, but it lets you use tag:foo/bar/grill as a repository, and it replaces the tag:foo with a matching entry in ~/.svnrc like this: tag foo svn://gcc.gnu.org/svn/gcc/trunk/whatever So, with a .svnrc like this: tag trunk svn://gcc.gnu.org/svn/gcc/trunk tag 4.0 svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch You could just svn co tag:4.0/gcc/config/i386 It probably screams for lots more prettying up, but at least I did something about it ;-) If you want it shorter, I could rewrite this so that the tag name goes before the colon, like 4.0:gcc/config/i386 This would be better, but then, you should say prefix instead of tag (which could be mixed up with tags), and the colon should be part of the prefix, e.g. in your ~/.subversion/config file: prefix 4.0: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/ (note the trailing slash). So, users could use other prefixes if they wish, not necessarily with a colon. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / SPACES project at LORIA
[PATCH] Re: ref_contains_indirect_ref always false?
On Fri, 4 Nov 2005, Richard Guenther wrote:
Hi!
it seems that
static inline bool
ref_contains_indirect_ref (tree ref)
{
while (handled_component_p (ref))
{
if (TREE_CODE (ref) == INDIRECT_REF)
return true;
ref = TREE_OPERAND (ref, 0);
}
return false;
}
always returns false, because handled_component_p (ref) returns
false for INDIRECT_REF.
The following patch fixes this by imitating ref_contains_array_ref
semantics. Bootstrapped on x86_64-unknonw-linux-gnu, regtest in
progress, ok for mainline if it succeeds?
Thanks,
Richard.
2005-11-04 Richard Guenther [EMAIL PROTECTED]
* tree-flow-inline.h (ref_contains_indirect_ref): Deal
with INDIRECT_REF not in handled_component_p.
Index: tree-flow-inline.h
===
--- tree-flow-inline.h (revision 106485)
+++ tree-flow-inline.h (working copy)
@@ -1413,11 +1413,13 @@
static inline bool
ref_contains_indirect_ref (tree ref)
{
+ if (TREE_CODE (ref) == INDIRECT_REF)
+return true;
while (handled_component_p (ref))
{
+ ref = TREE_OPERAND (ref, 0);
if (TREE_CODE (ref) == INDIRECT_REF)
return true;
- ref = TREE_OPERAND (ref, 0);
}
return false;
}
Re: [PATCH] Re: ref_contains_indirect_ref always false?
On Friday 04 November 2005 08:34, Richard Guenther wrote: * tree-flow-inline.h (ref_contains_indirect_ref): Deal with INDIRECT_REF not in handled_component_p. If you handle INDIRECT_REF directly, then you are seemingly changing the semantics of the predicate. The predicate says that it's expecting an ARRAY_REF as input. Point me to the bug you are trying to fix? There wasn't enough context in your message.
Re: [PATCH] Re: ref_contains_indirect_ref always false?
If you handle INDIRECT_REF directly, then you are seemingly changing the semantics of the predicate. The predicate says that it's expecting an ARRAY_REF as input. The way it's documented, the input *must* be an ARRAY_REF. If that's not what's meant, the comment should be changed. But if the comment is right, then the behavior is undefined if the input is *not* an ARRAY_REF, so there's no change to its documented semantics. Point me to the bug you are trying to fix? The bug I see is that the code doesn't agree with its comment ...
Re: [PATCH] Re: ref_contains_indirect_ref always false?
On Fri, 4 Nov 2005, Richard Kenner wrote:
The following patch fixes this by imitating ref_contains_array_ref
semantics. Bootstrapped on x86_64-unknonw-linux-gnu, regtest in
progress, ok for mainline if it succeeds?
Wouldn't this be simpler:
static inline bool
ref_contains_indirect_ref (tree ref)
{
while (handled_component_p (ref))
ref = TREE_OPERAND (ref, 0);
return TREE_CODE (ref) == INDIRECT_REF;
}
Yes, this would work, if INDIRECT_REF can be only innermost, i.e. we are
applying the predicate to GIMPLE trees only.
Richard.
Re: [PATCH] Re: ref_contains_indirect_ref always false?
On Fri, 2005-11-04 at 15:45 +0100, Richard Guenther wrote: On Fri, 4 Nov 2005, Diego Novillo wrote: On Friday 04 November 2005 08:34, Richard Guenther wrote: * tree-flow-inline.h (ref_contains_indirect_ref): Deal with INDIRECT_REF not in handled_component_p. If you handle INDIRECT_REF directly, then you are seemingly changing the semantics of the predicate. The predicate says that it's expecting an ARRAY_REF as input. Point me to the bug you are trying to fix? There wasn't enough context in your message. The bug is that as present, ref_contains_indirect_ref returns always false, regardless of input. Because handled_component_p returns false for TREE_CODE (arg) == INDIRECT_REF. Can you remove the tree-ssa-structalias use of this predicate at the same time please? It's not actually not necessary there (the loop-niter uses are still needed). --Dan Richard.
Re: [PATCH] Re: ref_contains_indirect_ref always false?
On Friday 04 November 2005 09:45, Richard Guenther wrote: On Fri, 4 Nov 2005, Diego Novillo wrote: On Friday 04 November 2005 08:34, Richard Guenther wrote: * tree-flow-inline.h (ref_contains_indirect_ref): Deal with INDIRECT_REF not in handled_component_p. If you handle INDIRECT_REF directly, then you are seemingly changing the semantics of the predicate. The predicate says that it's expecting an ARRAY_REF as input. Point me to the bug you are trying to fix? There wasn't enough context in your message. The bug is that as present, ref_contains_indirect_ref returns always false, regardless of input. Because handled_component_p returns false for TREE_CODE (arg) == INDIRECT_REF. OK. In that case, let's use Kenner's version and add #if defined ENABLE_CHECKING gcc_assert (handled_component_p (ref)) #endif at the start of both ref_contains_indirect_ref and ref_contains_array_ref. The comment will need fixing, too. Both predicates are supposed to handle aggregates in general. Thanks.
Re: [PATCH] Re: ref_contains_indirect_ref always false?
#if defined ENABLE_CHECKING gcc_assert (handled_component_p (ref)) #endif If the comment says it has to be an ARRAY_REF, why not just check for that?
Re: diffing directories with merged-as-deleted files?
Daniel Berlin wrote: I did svn co svn+ssh://gcc.gnu.org/svn/gcc/branches/sh-elf-4_1-branch cd sh-elf-4_1-branch svn merge -r106276:106279 svn+ssh://gcc.gnu.org/svn/gcc/trunk . (rev 106276:106279 contains the change that will remove .cvsignore) [EMAIL PROTECTED]:/mnt/gccstuff/sh-elf-4_1-branch svn diff -N It's not the diff against the pristine copy that's the problem, but the diff against mainline. I've renamed the toplevel dir to gcc (for compatibility with my symlink-building scripts), then changed current directory to it. Then I did: svn diff --old svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk/gcc --new gcc |less
Re: Build using --with-gmp and shared libraries
On Fri, Nov 04, 2005 at 01:32:06PM +0100, Fran?ois-Xavier Coudert wrote: Here is a patch to fix PR libfortran/21547: when building with --with-gmp=/foo/bar and a shared libgmp in /foo/bar, the $(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set correctly when using the freshly built gfortran to build libgfortran. The same thing happens for the gfortran testsuite, and the fix is also included in this patch. Why wouldn't mpfr have the same problem? Sorry not to mention that. It can (although it usually doesn't, because the default for libmpfr is to build only a static library), and this is fix by the same patch. In fact, in the gcc configury, all occurences of GMPLIBS, GMPINCS always take care of both gmp and mpfr. I followed this lead, and GMPLIBSDIR points to the directories where gmp and mpfr are installed, if different. All this is done in the toplevel configure. The newest version of mpfr will build a shared library. In fact, we should move to using the newest version, but I think some/many people would object to having two external library dependencies. -- Steve
RE: [PATCH] Re: ref_contains_indirect_ref always false?
Richard Kenner wrote:
#if defined ENABLE_CHECKING
gcc_assert (handled_component_p (ref))
#endif
If the comment says it has to be an ARRAY_REF, why not just check for
that?
Given that we're supposed to be passing in an ARRAY_REF and we don't want it
to return true if passed in an INDIRECT_REF, why not just reverse the order of
the two statements in the body of the original while loop?
Before:
static inline bool
ref_contains_indirect_ref (tree ref)
{
while (handled_component_p (ref))
{
if (TREE_CODE (ref) == INDIRECT_REF)
return true;
ref = TREE_OPERAND (ref, 0);
}
return false;
}
After:
static inline bool
ref_contains_indirect_ref (tree ref)
{
while (handled_component_p (ref))
{
ref = TREE_OPERAND (ref, 0);
if (TREE_CODE (ref) == INDIRECT_REF)
return true;
}
return false;
}
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: [PATCH] Re: ref_contains_indirect_ref always false?
On Fri, 4 Nov 2005, Diego Novillo wrote:
On Friday 04 November 2005 09:45, Richard Guenther wrote:
On Fri, 4 Nov 2005, Diego Novillo wrote:
On Friday 04 November 2005 08:34, Richard Guenther wrote:
* tree-flow-inline.h (ref_contains_indirect_ref): Deal
with INDIRECT_REF not in handled_component_p.
If you handle INDIRECT_REF directly, then you are seemingly changing
the semantics of the predicate. The predicate says that it's
expecting an ARRAY_REF as input.
Point me to the bug you are trying to fix? There wasn't enough
context in your message.
The bug is that as present, ref_contains_indirect_ref returns always
false, regardless of input. Because handled_component_p returns false
for TREE_CODE (arg) == INDIRECT_REF.
OK. In that case, let's use Kenner's version and add
#if defined ENABLE_CHECKING
gcc_assert (handled_component_p (ref))
#endif
at the start of both ref_contains_indirect_ref and ref_contains_array_ref.
The comment will need fixing, too. Both predicates are supposed to handle
aggregates in general.
This is what I'm currently re-checking.
Richard.
2005-11-04 Richard Guenther [EMAIL PROTECTED]
* tree-flow-inline.h (ref_contains_indirect_ref): Make comment
match the code and vice-versa.
(ref_contains_array_ref): Likewise.
* tree-ssa-structalias.c (find_func_aliases): Remove call to
ref_contains_indirect_ref.
Index: tree-flow-inline.h
===
--- tree-flow-inline.h (revision 106485)
+++ tree-flow-inline.h (working copy)
@@ -1407,32 +1407,35 @@
return TREE_READONLY (var) (TREE_STATIC (var) || DECL_EXTERNAL (var));
}
-/* Return true if REF, an ARRAY_REF, has an INDIRECT_REF somewhere in
- it. */
+/* Return true if REF, a handled component reference, has an INDIRECT_REF
+ somewhere in it. */
static inline bool
ref_contains_indirect_ref (tree ref)
{
- while (handled_component_p (ref))
-{
- if (TREE_CODE (ref) == INDIRECT_REF)
- return true;
- ref = TREE_OPERAND (ref, 0);
-}
- return false;
+ gcc_assert (handled_component_p (ref));
+
+ do {
+ref = TREE_OPERAND (ref, 0);
+ } while (handled_component_p (ref));
+
+ return TREE_CODE (ref) == INDIRECT_REF;
}
-/* Return true if REF, a COMPONENT_REF, has an ARRAY_REF somewhere in it. */
+/* Return true if REF, a handled component reference, has an ARRAY_REF
+ somewhere in it. */
static inline bool
ref_contains_array_ref (tree ref)
{
- while (handled_component_p (ref))
-{
- if (TREE_CODE (ref) == ARRAY_REF)
- return true;
- ref = TREE_OPERAND (ref, 0);
-}
+ gcc_assert (handled_component_p (ref));
+
+ do {
+if (TREE_CODE (ref) == ARRAY_REF)
+ return true;
+ref = TREE_OPERAND (ref, 0);
+ } while (handled_component_p (ref));
+
return false;
}
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c (revision 106485)
+++ tree-ssa-structalias.c (working copy)
@@ -2865,7 +2865,6 @@
containing pointers, dereferences, and call expressions. */
if (POINTER_TYPE_P (TREE_TYPE (lhsop))
|| AGGREGATE_TYPE_P (TREE_TYPE (lhsop))
- || ref_contains_indirect_ref (lhsop)
|| TREE_CODE (rhsop) == CALL_EXPR)
{
lhs = get_constraint_for (lhsop, NULL);
Re: [PATCH] Re: ref_contains_indirect_ref always false?
On Friday 04 November 2005 10:07, Richard Kenner wrote: #if defined ENABLE_CHECKING gcc_assert (handled_component_p (ref)) #endif If the comment says it has to be an ARRAY_REF, why not just check for that? The comment is out of sync with the code. It's used in code that may be sending an arbitrary aggregate. Given that Dan asked to remove the call from tree-ssa-structalias.c, then we can take advantage and tighten the two predicates more. In ref_contains_indirect_ref: Rename to array_ref_contains_indirect_ref Add gcc_assert (TREE_CODE (ref) == ARRAY_REF) at the start. In ref_contains_array_ref: Leave the gcc_assert I proposed. That predicate is used for more than COMPONENT_REFs. The comment needs to be updated.
Re: Build using --with-gmp and shared libraries
The newest version of mpfr will build a shared library. In fact, we should move to using the newest version, but I think some/many people would object to having two external library dependencies. What advantages have the newest version? And (sorry for the obvious question) why isn't it kept in sync with gmp? FX
F77 code under gcc
Dear developers, I have recently upgraded my PC to Suse Linux 10 (from 9.3). The distribution comes with gcc 4.0.2. The problem that arrised after the upgrade is that I cannot compile f77 codes anymore. More precisely when I try to compile a Fortran file (*.f) I am getting the error: gcc: installation problem, cannot exec 'f951': No such file or directory This is rather confusing since Novell claims that the provided rpm has been created with support of F77. Assuming the problem could come from formated input I tried -ffree-form -x f77 but nothing works. Do you have any clue about that? How I can compile F77 code or should I downgrade to gcc 2.95 or 3.0.x? Thank you Alexander -- Alexander Tzanov Scientific Computing and Visualization New York University, WWH 251 Mercer Street phone: 212 998 3159 fax: 212 995 4120 e-mail: [EMAIL PROTECTED]
Re: F77 code under gcc
On 11/4/05, Alex Tzanov [EMAIL PROTECTED] wrote: Dear developers, I have recently upgraded my PC to Suse Linux 10 (from 9.3). The distribution comes with gcc 4.0.2. The problem that arrised after the upgrade is that I cannot compile f77 codes anymore. More precisely when I try to compile a Fortran file (*.f) I am getting the error: gcc: installation problem, cannot exec 'f951': No such file or directory First of all, you should report installation problems of vendor packages to the vendor, i.e. SUSE or NOVELL in this case. Second, this list is for development _of_ gcc, not with, for such kind of questions please refer to [EMAIL PROTECTED] You are probably missing an installed rpm, like gcc-fortran or whatever it is called. Thanks, Richard. This is rather confusing since Novell claims that the provided rpm has been created with support of F77. Assuming the problem could come from formated input I tried -ffree-form -x f77 but nothing works. Do you have any clue about that? How I can compile F77 code or should I downgrade to gcc 2.95 or 3.0.x? Thank you Alexander -- Alexander Tzanov Scientific Computing and Visualization New York University, WWH 251 Mercer Street phone: 212 998 3159 fax: 212 995 4120 e-mail: [EMAIL PROTECTED]
Re: diffing directories with merged-as-deleted files?
On Fri, 2005-11-04 at 15:05 +, Joern RENNECKE wrote: Daniel Berlin wrote: I did svn co svn+ssh://gcc.gnu.org/svn/gcc/branches/sh-elf-4_1-branch cd sh-elf-4_1-branch svn merge -r106276:106279 svn+ssh://gcc.gnu.org/svn/gcc/trunk . (rev 106276:106279 contains the change that will remove .cvsignore) [EMAIL PROTECTED]:/mnt/gccstuff/sh-elf-4_1-branch svn diff -N It's not the diff against the pristine copy that's the problem, but the diff against mainline. Uh, but a diff against the pristine copy is the same as a diff against mainline at that point, since your only differences come from merging the mainline. I've renamed the toplevel dir to gcc (for compatibility with my symlink-building scripts), then changed current directory to it. Then I did: svn diff --old svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk/gcc --new gcc |less This i can reproduce. I imagine nobody noticed because, as i've pointed out above, this is a very roundabout way of doing the same thing regular svn diff will tell you at that point. I'm committing a fix now and nominating it for 1.3.x Thanks!
Re: [PATCH] Re: ref_contains_indirect_ref always false?
On Fri, 2005-11-04 at 10:17 -0500, Diego Novillo wrote:
On Friday 04 November 2005 10:07, Richard Kenner wrote:
#if defined ENABLE_CHECKING
gcc_assert (handled_component_p (ref))
#endif
If the comment says it has to be an ARRAY_REF, why not just check for
that?
The comment is out of sync with the code. It's used in code that may be
sending an arbitrary aggregate.
Given that Dan asked to remove the call from tree-ssa-structalias.c, then
we can take advantage and tighten the two predicates more.
In ref_contains_indirect_ref:
Rename to array_ref_contains_indirect_ref
Add gcc_assert (TREE_CODE (ref) == ARRAY_REF) at the start.
This would be fine.
The use in tree-ssa-loop-niter.c is really trying to skip out on
inferring loop bounds from pointer to structure accesses in the case of
things like:
struct a
{
char foo[1];
};
struct a *b = malloc (sizeof (struct a) + 100);
b-foo = I like candy!
Since we have to keep this working:)
Thus, it should *always* be handed an ARRAY_REF.
Re: diffing directories with merged-as-deleted files?
Daniel Berlin wrote: Uh, but a diff against the pristine copy is the same as a diff against mainline at that point, since your only differences come from merging the mainline. No, the pristine copy is the pristine copy of the branch. I want to diff my working copy of the branch against the head of trunk. This i can reproduce. I imagine nobody noticed because, as i've pointed out above, this is a very roundabout way of doing the same thing regular svn diff will tell you at that point. I'm committing a fix now and nominating it for 1.3.x Thanks!
RE: [PATCH] Re: ref_contains_indirect_ref always false?
Daniel Berlin wrote:
The use in tree-ssa-loop-niter.c is really trying to skip out on
inferring loop bounds from pointer to structure accesses in the case of
things like:
struct a
{
char foo[1];
};
struct a *b = malloc (sizeof (struct a) + 100);
b-foo = I like candy!
Since we have to keep this working:)
We do?! Storing a pointer value to a char variable has never worked very
well so far!
;)
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: [PATCH] Re: ref_contains_indirect_ref always false?
On Fri, 2005-11-04 at 16:23 +, Dave Korn wrote:
Daniel Berlin wrote:
The use in tree-ssa-loop-niter.c is really trying to skip out on
inferring loop bounds from pointer to structure accesses in the case of
things like:
struct a
{
char foo[1];
};
struct a *b = malloc (sizeof (struct a) + 100);
b-foo = I like candy!
Since we have to keep this working:)
We do?! Storing a pointer value to a char variable has never worked very
well so far!
I was shorthanding it, you know what i meant :)
Re: [PATCH] Re: ref_contains_indirect_ref always false?
On Fri, 4 Nov 2005, Diego Novillo wrote:
On Friday 04 November 2005 10:07, Richard Kenner wrote:
#if defined ENABLE_CHECKING
gcc_assert (handled_component_p (ref))
#endif
If the comment says it has to be an ARRAY_REF, why not just check for
that?
The comment is out of sync with the code. It's used in code that may be
sending an arbitrary aggregate.
Given that Dan asked to remove the call from tree-ssa-structalias.c, then
we can take advantage and tighten the two predicates more.
In ref_contains_indirect_ref:
Rename to array_ref_contains_indirect_ref
Add gcc_assert (TREE_CODE (ref) == ARRAY_REF) at the start.
In ref_contains_array_ref:
Leave the gcc_assert I proposed. That predicate is used for more than
COMPONENT_REFs.
The comment needs to be updated.
I bootstrapped and regtested the following on x86_64-unknown-linux-gnu.
Ok for mainline?
Thanks,
Richard.
2005-11-04 Richard Guenther [EMAIL PROTECTED]
* tree-flow.h (ref_contains_indirect_ref): Rename to
array_ref_contains_indirect_ref.
* tree-flow-inline.h (ref_contains_indirect_ref): Likewise.
(array_ref_contains_indirect_ref): Make comment match the code
and vice-versa.
(ref_contains_array_ref): Likewise.
* tree-ssa-structalias.c (find_func_aliases): Remove call to
ref_contains_indirect_ref.
* tree-ssa-loop-niter.c (infer_loop_bounds_from_undefined):
Rename calls to ref_contains_indirect_ref.
Index: tree-flow-inline.h
===
--- tree-flow-inline.h (revision 106485)
+++ tree-flow-inline.h (working copy)
@@ -1407,32 +1407,34 @@
return TREE_READONLY (var) (TREE_STATIC (var) || DECL_EXTERNAL (var));
}
-/* Return true if REF, an ARRAY_REF, has an INDIRECT_REF somewhere in
- it. */
+/* Return true if REF, an ARRAY_REF, has an INDIRECT_REF somewhere in it. */
static inline bool
-ref_contains_indirect_ref (tree ref)
+array_ref_contains_indirect_ref (tree ref)
{
- while (handled_component_p (ref))
-{
- if (TREE_CODE (ref) == INDIRECT_REF)
- return true;
- ref = TREE_OPERAND (ref, 0);
-}
- return false;
+ gcc_assert (TREE_CODE (ref) == ARRAY_REF);
+
+ do {
+ref = TREE_OPERAND (ref, 0);
+ } while (handled_component_p (ref));
+
+ return TREE_CODE (ref) == INDIRECT_REF;
}
-/* Return true if REF, a COMPONENT_REF, has an ARRAY_REF somewhere in it. */
+/* Return true if REF, a handled component reference, has an ARRAY_REF
+ somewhere in it. */
static inline bool
ref_contains_array_ref (tree ref)
{
- while (handled_component_p (ref))
-{
- if (TREE_CODE (ref) == ARRAY_REF)
- return true;
- ref = TREE_OPERAND (ref, 0);
-}
+ gcc_assert (handled_component_p (ref));
+
+ do {
+if (TREE_CODE (ref) == ARRAY_REF)
+ return true;
+ref = TREE_OPERAND (ref, 0);
+ } while (handled_component_p (ref));
+
return false;
}
Index: tree-flow.h
===
--- tree-flow.h (revision 106485)
+++ tree-flow.h (working copy)
@@ -614,7 +614,7 @@
static inline subvar_t get_subvars_for_var (tree);
static inline tree get_subvar_at (tree, unsigned HOST_WIDE_INT);
static inline bool ref_contains_array_ref (tree);
-static inline bool ref_contains_indirect_ref (tree);
+static inline bool array_ref_contains_indirect_ref (tree);
extern tree okay_component_ref_for_subvars (tree, unsigned HOST_WIDE_INT *,
unsigned HOST_WIDE_INT *);
static inline bool var_can_have_subvars (tree);
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c (revision 106485)
+++ tree-ssa-structalias.c (working copy)
@@ -2865,7 +2865,6 @@
containing pointers, dereferences, and call expressions. */
if (POINTER_TYPE_P (TREE_TYPE (lhsop))
|| AGGREGATE_TYPE_P (TREE_TYPE (lhsop))
- || ref_contains_indirect_ref (lhsop)
|| TREE_CODE (rhsop) == CALL_EXPR)
{
lhs = get_constraint_for (lhsop, NULL);
Index: tree-ssa-loop-niter.c
===
--- tree-ssa-loop-niter.c (revision 106485)
+++ tree-ssa-loop-niter.c (working copy)
@@ -1438,11 +1438,11 @@
/* For each array access, analyze its access function
and record a bound on the loop iteration domain. */
if (TREE_CODE (op1) == ARRAY_REF
-!ref_contains_indirect_ref (op1))
+!array_ref_contains_indirect_ref (op1))
estimate_iters_using_array (stmt, op1);
if (TREE_CODE (op0) == ARRAY_REF
-!ref_contains_indirect_ref (op0))
+!array_ref_contains_indirect_ref (op0))
RE: [PATCH] Re: ref_contains_indirect_ref always false?
Daniel Berlin wrote:
[cc list trimmed because it's just one of those silly friday afternoon things]
On Fri, 2005-11-04 at 16:23 +, Dave Korn wrote:
Daniel Berlin wrote:
The use in tree-ssa-loop-niter.c is really trying to skip out on
inferring loop bounds from pointer to structure accesses in the case of
things like:
struct a
{
char foo[1];
};
struct a *b = malloc (sizeof (struct a) + 100);
b-foo = I like candy!
Since we have to keep this working:)
We do?! Storing a pointer value to a char variable has never worked
very well so far!
I was shorthanding it, you know what i meant :)
heh, yeh, I knew.
But I see so many lines like that in C programs written by people who
_think_ they're writing in C++ [*]
cheers,
DaveK
[*] Or BASIC, even more likely!
--
Can't think of a witty .sigline today
*-rtems status on head was Re: cross newlib builds on svn head
Thanks to Paolo Bonzini's patch, I can get much further and now have
more to report. :)
The Good
h8300-rtems4.7 - C, C++ build OK (Ada not tried)
i386-rtems4.7 - C, C++, Ada build OK
m68k-rtems4.7 - C, C++, Ada build OK
sh-rtems4.7 - C, C++ build OK (Ada not tried)
sparc-rtems4.7 - C, C++, Ada build OK.
The Bad
===
avr-rtems4.7 - ICE on C
arm-rtems4.7 - ada/rts/raise.c does not compile
mips-rtems4.7 - GNAT bug box at a-calend.adb:480:24
mips64-rtems4.7 - GNAT bug box at a-calend.adb:480:24
powerpc-rtems4.7 - GNAT bug box at a-calend.adb:480:24
The Details
===
arm-rtems4.7 - C, C++ OK. Ada fails with this:
../../xgcc -B../../ -c -DCROSS_COMPILE -DIN_GCC `echo -g -O2
-Dinhibit_libc -fno-inline -fexceptions -DIN_RTS |sed -e
's/-pedantic//g' -e 's/-Wtraditional//g'` \
-I. -I.. -I../..
-I/home/joel/gcc-work/head/gcc-head-test/gcc/ada
-I/home/joel/gcc-work/head/gcc-head-test/gcc/ada/../config
-I/home/joel/gcc-work/head/gcc-head-test/gcc/ada/../../include
-I/home/joel/gcc-work/head/gcc-head-test/gcc/ada/.. -I./../.. raise.c -o
raise.o
raise.c: In function 'db':
raise.c:233: error: 'va_list' undeclared (first use in this function)
raise.c:233: error: (Each undeclared identifier is reported only once
raise.c:233: error: for each function it appears in.)
raise.c:233: error: expected ';' before 'msg_args'
raise.c:237: error: 'msg_args' undeclared (first use in this function)
raise.c: In function 'get_region_description_for':
raise.c:595: warning: pointer targets in assignment differ in signedness
I haven't had a chance to investigate why this doesn't compile.
avr-rtems4.7 - C dies with an ICE
./../../../../../gcc-head-test/newlib/libc/misc/init.c: In function
'__libc_fini_array':
../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: error:
unable to find a register to spill in class 'BASE_POINTER_REGS'
../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: error: this
is the insn:
(insn 65 32 33 2
../../../../../../gcc-head-test/newlib/libc/misc/init.c:56 (set
(mem/c:HI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [5 S2 A8])
(reg:HI 24 r24)) 12 {*movhi} (nil)
(nil))
../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: internal
compiler error: in spill_failure, at reload1.c:1890
mips64-rtems4.7, mips-rtems4.7, and powerpc-rtems4.7 all die in Ada at
the same spot.
../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg a-calend.adb -o
a-calend.o
+===GNAT BUG DETECTED===+
| 4.1.0 20051102 (experimental) (mips-unknown-rtems4.7) GCC error: |
| tree check: expected class |
| Error detected at a-calend.adb:480:24
Advice, patches always appreciated.
--
Joel Sherrill, Ph.D. Director of Research Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Re: GCC-generated code and i386 condition codes behavior
I must say I am a bit surprised that gcc never takes advantage of the fact that inc and dec do not destroy the carry flag, this is quite significant for some loops. And which is extremely bad on Pentium II and newer. Paolo, who made the first paid computer work on Realia COBOL
Re: GCC-generated code and i386 condition codes behavior
Andi Kleen wrote: Robert Dewar [EMAIL PROTECTED] writes: I must say I am a bit surprised that gcc never takes advantage of the fact that inc and dec do not destroy the carry flag, this is quite significant for some loops. A lot of this old wisdom is no longer true. inc and dec are to be generally avoided these days, because the partial changing of EFLAGS causes too strict dependencies on Intel P4 cores and threefore slower execution. It's better to use add/sub $1,... instead, except if you're optimizing for code size. actually as Geert points out, probably LEA is the right choice when you don't want to affect the flags, though in this case I guess you need some otherway to test for loop termination. Not clear how you do that without destroying the carry flag. I will do some benchmarks in this area to see how the old wisdom holds :-) -Andi
Unwinding through signal handlers on IA-64/Linux
Hi, It works if the unwind library is HP's libunwind (aka system libunwind) but doesn't if the unwind library is the bundled one (config/ia64/unwind-ia64.c). That's with a 3.4.5pre-based compiler on SLES 9, but the problem is very likely present on all branches. The bottom line is that the CFM register is incorrectly restored: it is loaded with the value of the AR.PFS register when the signal is raised. Breakpoint 3, 0x40003300 in _ada_p () (gdb) info reg cfm cfm0x287647 (gdb) info reg pfs pfs0xc388 -4611686018427387000 (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0x40003300 in _ada_p () (gdb) Continuing. Breakpoint 1, 0x400033f2 in _ada_p () (gdb) info reg cfm cfm0x388904 Debug session with the same executable using HP's libunwind: Breakpoint 3, 0x40003300 in _ada_p () (gdb) info reg cfm cfm0x287647 (gdb) info reg pfs pfs0xc388 -4611686018427387000 (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0x40003300 in _ada_p () (gdb) Continuing. Breakpoint 1, 0x400033f2 in _ada_p () (gdb) info reg cfm cfm0x287647 Now the unwinder gets it almost right, that is fs-curr.reg[UNW_REG_PFS] holds the right values (val = 224, where = UNW_WHERE_SPREL, when = -1). But there are these lines in ia64_handle_unwabi: /* pfs_loc already set above. Without this pfs_loc would point incorrectly to sc_cfm instead of sc_ar_pfs. */ fs-curr.reg[UNW_REG_PFS].where = UNW_WHERE_NONE; The problem is that we want pfs_loc to essentially[1] point to sc_cfm, which is the saved CFM in the signal context, because we use the target AR.PFS to restore the CFM with the help of br.ret; we certainly don't want it to point to the saved AR.PFS in the signal context, which is a dead value if a register frame has been allocated[2]. These lines look very questionable to me; if they are removed, all works fine for the attached testcase (compile with -gnatp). Maybe some confusion comes from context-pfs_loc = (sc-sc_ar_pfs); a few lines above, which is a dead statement if considered alone. Can anyone shed some light on this? Thanks in advance. [1] essentially because we probably would want pfs_loc to point to a CFM+EC value. But I skimmed through HP's libunwind and I didn't find any attempt to put together a full AR.PFS value from saved CFM and EC. [2] if a register frame has not been allocated then AR.PFS is live in the procedure and would need to be restored too. Incidentally, the current code probably works in that case, but I think it cannot happen in practice. -- Eric Botcazou with Ada.Text_IO; procedure P is type Int_Ptr is access all Integer; Data : Int_Ptr := null; begin Data.all := 0; exception when others = Ada.Text_IO.Put_Line (Exception handled); end P;
The new gcc_release script hasn't been pushed to production
Snapshots haven't been created since 10/29. Looks like the version of gcc_release running on gcc.gnu.org is still the old CVS based one. gcc_release: Tagging sources as gcc-ss-4_0-20051103 cvs [export aborted]: no such tag gcc-ss-4_0-20051103 cvs [rtag aborted]: could not open lock file `/cvs/gcc/gcc/,.cvsignore,': Permission denied gcc_release: error: Could not tag sources
Re: The new gcc_release script hasn't been pushed to production
On Fri, 4 Nov 2005, Kelley Cook wrote: Snapshots haven't been created since 10/29. I updated the one gccadmin uses yesterday. look in /home/gccadmin/scripts Looks like the version of gcc_release running on gcc.gnu.org is still the old CVS based one. gcc_release: Tagging sources as gcc-ss-4_0-20051103 cvs [export aborted]: no such tag gcc-ss-4_0-20051103 cvs [rtag aborted]: could not open lock file `/cvs/gcc/gcc/,.cvsignore,': Permission denied gcc_release: error: Could not tag sources Yes, this was a few hours before i updated the script. I didn't want to rerun it and screw up the dates.
Re: The new gcc_release script hasn't been pushed to production
On Fri, 4 Nov 2005, Daniel Berlin wrote: On Fri, 4 Nov 2005, Kelley Cook wrote: Snapshots haven't been created since 10/29. I updated the one gccadmin uses yesterday. look in /home/gccadmin/scripts I haven't seen the changes on gcc-patches yet. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: The new gcc_release script hasn't been pushed to production
On Sat, 2005-11-05 at 01:07 +, Joseph S. Myers wrote: On Fri, 4 Nov 2005, Daniel Berlin wrote: On Fri, 4 Nov 2005, Kelley Cook wrote: Snapshots haven't been created since 10/29. I updated the one gccadmin uses yesterday. look in /home/gccadmin/scripts I haven't seen the changes on gcc-patches yet. They were posted sometime yesterday, and committed in rev 106476 and 106478. I only tested them for snapshot creation, without the announcement part running. I'm sure there is still work they need.
[Bug target/24623] [4.1 Regression] internal compiler error: in propagate_one_insn, at flow.c:1702
--- Comment #5 from krebbel1 at de dot ibm dot com 2005-11-04 08:02 --- The problem occurs when a landing pad is optimized away but the special code in s390_regs_ever_clobbered insists on saving all eh registers. The special code in that function exists because the eh regs may be read in a function (inside the landing pad) without beeing set before. In that case s390_regs_ever_clobbered would not consider them to be saved. With the attached patch the eh regs for a landing pad are only saved if regs_ever_live is true for them. I will not post the patch until I have decided how to fix PR 24624. It is possible that 24624 can only be fixed by reverting my patch introducing regs_ever_clobbered. If that patch gets reverted this fix is obsolete of course. That fixes the testcase in the PR. Bootstrapped on s390 and s390x - no testsuite regressions. OK for mainline? Bye, -Andreas- 2005-11-03 Andreas Krebbel [EMAIL PROTECTED] * config/s390/s390.c (s390_regs_ever_clobbered): Only save LIVE eh regs for a function containing a landing pad. Index: gcc/config/s390/s390.c === RCS file: /cvs/gcc/gcc/gcc/config/s390/s390.c,v retrieving revision 1.257 diff -p -c -r1.257 s390.c *** gcc/config/s390/s390.c 30 Sep 2005 15:36:15 - 1.257 --- gcc/config/s390/s390.c 3 Nov 2005 12:56:06 - *** s390_regs_ever_clobbered (int *regs_ever *** 5874,5880 deal with this automatically. */ if (current_function_calls_eh_return || cfun-machine-has_landing_pad_p) for (i = 0; EH_RETURN_DATA_REGNO (i) != INVALID_REGNUM ; i++) ! regs_ever_clobbered[EH_RETURN_DATA_REGNO (i)] = 1; /* For nonlocal gotos all call-saved registers have to be saved. This flag is also set for the unwinding code in libgcc. --- 5874,5883 deal with this automatically. */ if (current_function_calls_eh_return || cfun-machine-has_landing_pad_p) for (i = 0; EH_RETURN_DATA_REGNO (i) != INVALID_REGNUM ; i++) ! if (current_function_calls_eh_return ! || (cfun-machine-has_landing_pad_p ! regs_ever_live [EH_RETURN_DATA_REGNO (i)])) ! regs_ever_clobbered[EH_RETURN_DATA_REGNO (i)] = 1; /* For nonlocal gotos all call-saved registers have to be saved. This flag is also set for the unwinding code in libgcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24623
[Bug fortran/18452] Fortran options induces warning for fortran that needs preprocessing
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2005-11-04 08:29 --- Subject: Bug 18452 Author: fxcoudert Date: Fri Nov 4 08:29:16 2005 New Revision: 106483 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106483 Log: PR fortran/18452 * gcc/fortran/lang-specs.h: Pass -lang-fortran to the preprocessor. * gcc/c.opt: Add a -lang-fortran option. * gcc/c-opts.c: Add a lang_fortran flag. (c_common_init_options): Handling the -lang-fortran option. (c_common_handle_option): Add a case for Fortran options in preprocessing. Remove cases for -ffixed-form and -ffixed-line-length. Add a case for -lang-fortran. Modified: trunk/gcc/ChangeLog trunk/gcc/c-opts.c trunk/gcc/c.opt trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/lang-specs.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
[Bug fortran/18452] Fortran options induces warning for fortran that needs preprocessing
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2005-11-04 08:31 --- Hurray, hurray, this bug is fixed! Now, could we get libgfortran building with -Werror? :) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED GCC host triplet|i686-gnu-linux | Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
[Bug libfortran/22298] libgfortran init() constructor isn't called if executable is statically linked
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-11-04 08:44 --- Subject: Bug 22298 Author: fxcoudert Date: Fri Nov 4 08:44:29 2005 New Revision: 106484 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106484 Log: PR libfortran/22298 * runtime/main.c (stupid_function_name_for_static_linking): New function. * runtime/error.c (internal_error): Call stupid_function_name_for_static_linking. * libgfortran.h: Add prototype for stupid_function_name_for_static_linking. * gcc/testsuite/lib/target-supports.exp (check_effective_target_static_libgfortran): New static_libgfortran effective target. * gcc/testsuite/gfortran.dg/static_linking_1.f: New test. * gcc/testsuite/gfortran.dg/static_linking_1.c: New file. Added: trunk/gcc/testsuite/gfortran.dg/static_linking_1.c trunk/gcc/testsuite/gfortran.dg/static_linking_1.f Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp trunk/libgfortran/ChangeLog trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/error.c trunk/libgfortran/runtime/main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22298
[Bug libfortran/22298] libgfortran init() constructor isn't called if executable is statically linked
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-04 08:49 --- Subject: Bug 22298 Author: fxcoudert Date: Fri Nov 4 08:49:18 2005 New Revision: 106485 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106485 Log: PR libfortran/22298 * runtime/main.c (stupid_function_name_for_static_linking): New function. * runtime/error.c (internal_error): Call stupid_function_name_for_static_linking. * libgfortran.h: Add prototype for stupid_function_name_for_static_linking. * gcc/testsuite/lib/target-supports.exp (check_effective_target_static_libgfortran): New static_libgfortran effective target. * gcc/testsuite/gfortran.dg/static_linking_1.f: New test. * gcc/testsuite/gfortran.dg/static_linking_1.c: New file. Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/static_linking_1.c - copied unchanged from r106484, trunk/gcc/testsuite/gfortran.dg/static_linking_1.c branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/static_linking_1.f - copied unchanged from r106484, trunk/gcc/testsuite/gfortran.dg/static_linking_1.f Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/lib/target-supports.exp branches/gcc-4_0-branch/libgfortran/ChangeLog branches/gcc-4_0-branch/libgfortran/libgfortran.h branches/gcc-4_0-branch/libgfortran/runtime/error.c branches/gcc-4_0-branch/libgfortran/runtime/main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22298
[Bug libfortran/22298] libgfortran init() constructor isn't called if executable is statically linked
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2005-11-04 08:50 --- Fixed on both 4.0 and 4.1. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22298
[Bug debug/24634] DW_AT_high_pc and DW_AT_low_pc zero in DWARF-2 debug info in object file in 64bit world
--- Comment #5 from mlynarik at decef dot elf dot stuba dot sk 2005-11-04 09:03 --- Created an attachment (id=10141) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10141action=view) Assembler source of comiled example2-32.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24634
[Bug debug/24634] DW_AT_high_pc and DW_AT_low_pc zero in DWARF-2 debug info in object file in 64bit world
--- Comment #6 from mlynarik at decef dot elf dot stuba dot sk 2005-11-04 09:04 --- Created an attachment (id=10142) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10142action=view) Assembler source from compilation of example2-64.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24634
[Bug tree-optimization/24669] New: Loop index variable has offset of 1
A simple loop:
void foo (int *a, int *b)
{
int i;
for (i = 0; i 4; i++)
b[i] = a[i];
}
gets compiled to (gcc -O2 -fomit-frame-pointer):
pushl %ebx
movl$1, %edx index starts with 1
movl8(%esp), %ebx
movl12(%esp), %ecx
.p2align 4,,15
.L2:
movl-4(%ebx,%edx,4), %eax it is compensated by -4 here
movl%eax, -4(%ecx,%edx,4) and here
incl%edx
cmpl$5, %edxcompare with N+1
jne .L2
popl%ebx
ret
The problem is, that index variable has offset of 1 and it has to be
compensated by appropriate negative offset in the address.
The optimized tree dump shows:
bb 0:
ivtmp.33 = 1;
L0:;
D.1347 = (int *) ivtmp.33;
MEM[base: b, index: D.1347, step: 4B, offset: -4B] = MEM[base: a, index:
D.1347, step: 4B, offset
: -4B];
ivtmp.33 = ivtmp.33 + 1;
if (ivtmp.33 != 5) goto L0; else goto L2;
L2:;
return;
One would expect the index to start with 0 as this enables use of xor for
initialization. Perhaps non-zero address offset also disables some
optimizations.
--
Summary: Loop index variable has offset of 1
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24669
[Bug libfortran/21547] Unable to build libfortran library
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-04 09:11 --- Patch proposed: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00244.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg00244.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2005-05-31 16:52:32 |2005-11-04 09:11:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21547
[Bug debug/24634] DW_AT_high_pc and DW_AT_low_pc zero in DWARF-2 debug info in object file in 64bit world
--- Comment #7 from mlynarik at decef dot elf dot stuba dot sk 2005-11-04 09:12 --- We have created the assembler sources with the parameters -dA. You can see that there are no differences between the 32bit and 64bit versions except the length of the fields (4bytes and 8bytes). So I think there souldn't be a difference between these two versions concerning these attributes in the .o files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24634
[Bug libfortran/23138] [mingw32] real values are printed incorrectly
--- Comment #9 from dannysmith at users dot sourceforge dot net 2005-11-04 09:15 --- Hello, mingw has an implementation of _IO_ldtoa() and _IO_ldtostr(), based on Stephen Moshier's ioldoubl package, that could be used. Currently, the ldtoa function is not exposed, but there is no reason why it couldn't be. newlib provides a ldtoa() )also based on S Moshier's package that could be used on cygwin and other newlib targets. Would a ldtoa alternative to sprintf be acceptable? Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23138
[Bug tree-optimization/24669] Loop index variable has offset of 1
--- Comment #1 from uros at kss-loka dot si 2005-11-04 09:20 --- -fno-ivopts produces: movl16(%esp), %edi movl20(%esp), %esi xorl%ebx, %ebx movl$4, %ecx index starts with 1 .L2: leal(%ebx,%ebx), %edx movl(%edi,%edx,2), %eax movl%eax, (%esi,%edx,2) addl$1, %ebx subl$1, %ecx no compare! jne .L2 Hm, why isn't produced something like: movl8(%esp), %ebx movl12(%esp), %ecx movl$4, %edx .L2: movl(%ebx,%edx,4), %eax movl%eax, (%ecx,%edx,4) dec %edx jne .L2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24669
[Bug target/22209] [4.1 regression] libgfortran unresolvable symbols on irix6.5
--- Comment #4 from rsandifo at gcc dot gnu dot org 2005-11-04 09:22 --- I think TImode has to be a workable mode for IRIX 6. Long double is TFmode, and it would certainly seem odd to support TImode and not TFmode. (I seem to remember the s390 folks having to add TImode support exactly because they had TFmode support. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22209
[Bug libfortran/23138] [mingw32] real values are printed incorrectly
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2005-11-04 09:27 --- (In reply to comment #9) Would a ldtoa alternative to sprintf be acceptable? Yes, it would be very nice to have and we could use it in gfortran. Please keep us (bugzilla) posted of new developments on this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23138
[Bug c++/22487] C++ front-end produces mis-match types in EQ_EXPR (array constructor)
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-11-04 09:46 --- Subject: Bug 22487 Author: rguenth Date: Fri Nov 4 09:46:43 2005 New Revision: 106487 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106487 Log: 2005-11-04 Richard Guenther [EMAIL PROTECTED] PR c++/22487 * init.c (build_vec_init): Build comparison of matching types. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22487
[Bug c++/22487] C++ front-end produces mis-match types in EQ_EXPR (array constructor)
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-11-04 09:47 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22487
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
--- Comment #20 from rakdver at gcc dot gnu dot org 2005-11-04 10:04 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00246.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug tree-optimization/24669] Loop index variable has offset of 1
--- Comment #2 from rakdver at gcc dot gnu dot org 2005-11-04 10:35 ---
There are two reasons we do not produce the code as in the comment #1:
1) This would require reversing the loop, which is currently implemented in
mainline only in old loop optimizer, in a very weak fashion. More powerful
implementation is in killloop branch and should appear in 4.2.
2) Nevertheless, in this particular example we cannot reverse the loop at all
(i.e., the proposed code is incorrect) -- it would cause misscompilations for
example if foo is called as foo(p + 1, p). If p = {1,2,3,4,5}, the original
code sets it to {1,1,1,1,1}, while the new one to {1,1,2,3,4}.
The fact that the index variable is chosen to start with 1 instead of zero is
more interesting. It does not really matter that much, since both
possibilities have exactly the same cost. But the reason is that target
description pretends that the more complicated addressing mode is in fact
cheaper, thus misguiding ivopts to prefer it to the simpler one, if everything
else is equal.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24669
[Bug rtl-optimization/23567] [3.4/4.0/4.1 regression] if-conversion causes wrong code
--- Comment #8 from jakub at gcc dot gnu dot org 2005-11-04 10:52 --- Sorry, haven't touched this for a while. Testing a new patch, there have been other problems in noce_process_if_block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23567
[Bug target/23775] [4.1 Regression] wrong code in argument passing
-- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23775
[Bug tree-optimization/24670] New: VRP ICE in compare_name_with_value
This ICE occured during a compile of libfloat with mainline.
Attached is a delta reduced test that produces the ICE when compiled with -O2.
softfloat/bits64/softfloat.c: In function float128_rem:
softfloat/bits64/softfloat.c:4483: internal compiler error: in
compare_name_with_value, at tree-vrp.c:3064
__inline__ void
shift128Right (int count, long long int *z1Ptr)
{
long long int z1;
if (count == 0);
else if (count 64);
else
z1 = (count 64) ? count : 0;
*z1Ptr = z1;
}
float128_rem ()
{
signed int expDiff;
long long int aSig1;
long long int sigMean1;
if (-64 expDiff)
shift128Right (-expDiff, aSig1);
add128 (sigMean1);
}
--
Summary: VRP ICE in compare_name_with_value
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot pop at cri dot ensmp dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24670
[Bug c++/24668] visibility attributes on namespaces
--- Comment #1 from pluto at agmk dot net 2005-11-04 11:06 --- what about PR21764 (linked in PR19664)? duplication? -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24668
[Bug ada/20753] ACATS ce3810b segfaults at runtime
--- Comment #8 from christian dot joensson at gmail dot com 2005-11-04 11:24 --- Just a ping here... are there any progress on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20753
[Bug c++/24671] New: [4.0/4.1 regression] ICE with zero-sized arrays
The following testcase causes an ICE:
==
templatetypename struct A
{
typedef int X;
static const int i = 0;
};
templatetypename struct B
{
typedef typename Achar[AB::i]::X Y;
templatetypename T B(T, Y);
};
Bint b(0,0);
==
dPR19208B.cc:10: internal compiler error: in push_access_scope, at cp/pt.c:176
Please submit a full bug report, [etc.]
The testcase crashed since at least gcc 2.95.3, but was fixed with the
patch for PR19208. The problem reappeared on the 3.4 branch and mainline
with Josh's patch for PR 19989.
I think the code should be accepted at least with -fpermissive,
but rejected with -pedantic.
--
Summary: [4.0/4.1 regression] ICE with zero-sized arrays
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Keywords: ice-on-valid-code, ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
BugsThisDependsOn: 19208,19989
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24671
[Bug target/24672] New: ICE on missing parentheses for constructor
The following invalid code snippet (which is similar to PR 22257)
causes an ICE on x86-64:
=
struct A
{
int i, j;
A : i(), j() {}
};
=
bug.cc:4: error: 'A::i' cannot appear in a constant-expression
bug.cc:4: error: a function call cannot appear in a constant-expression
bug.cc:4: error: name 'A' has incomplete type
bug.cc:4: error: declaration of 'A A::j()'
bug.cc:3: error: conflicts with previous declaration 'int A::j'
bug.cc: In member function 'A A::j()':
bug.cc:4: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in classify_argument, at config/i386/i386.c:2653
Please submit a full bug report, [etc.]
Since classify_argument is a x86_64-specific function, the ICE doesn't
appear on i686. So it's target dependent.
OTOH it might be a frontend bug that we end up in classify_argument at all
with invalid data.
--
Summary: ICE on missing parentheses for constructor
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
BugsThisDependsOn: 19964,22257
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24672
[Bug middle-end/24635] Wrong statement reordering
--- Comment #3 from worm at arrakis dot es 2005-11-04 12:13 --- Created an attachment (id=10143) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10143action=view) This one triggers the bug The new file definitely triggers the problem with statement reordering if compiled with (-O2), but after a second read of the standard, I am not sure whether arguments of a function are implicitely declared volatile or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug tree-optimization/24669] Loop index variable has offset of 1
--- Comment #3 from uros at kss-loka dot si 2005-11-04 12:19 --- Following patch to ix86_address_cost: --- i386.c (revision 106482) +++ i386.c (working copy) @@ -5396,8 +5396,12 @@ if (parts.index GET_CODE (parts.index) == SUBREG) parts.index = SUBREG_REG (parts.index); + /* Penalize displacements a bit. */ + if (parts.disp parts.disp != const0_rtx) +cost++; + /* More complex memory references are better. */ - if (parts.disp parts.disp != const0_rtx) + if (parts.scale) cost--; if (parts.seg != SEG_DEFAULT) cost--; generates: pushl %ebx movl8(%esp), %ebx movl12(%esp), %ecx xorl%edx, %edx .L2: movl(%ebx,%edx,4), %eax movl%eax, (%ecx,%edx,4) addl$1, %edx cmpl$4, %edx jne .L2 popl%ebx ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24669
[Bug c++/24668] visibility attributes on namespaces
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-04 13:05 --- This is a dup of bug 21764 as far as I can see. *** This bug has been marked as a duplicate of 21764 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24668
[Bug c++/21764] visibility attributes on namespace scope
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-04 13:05 --- *** Bug 24668 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764
[Bug debug/24634] DW_AT_high_pc and DW_AT_low_pc zero in DWARF-2 debug info in object file in 64bit world
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-04 13:10 --- What you are seing is either an assmebler bug or just dwarfdump not supporting relocations for 64bit. I want to say the latter. This is not a GCC bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24634
[Bug tree-optimization/24670] [4.1 Regression] VRP ICE in compare_name_with_value
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Keywords||ice-on-valid-code Summary|VRP ICE in |[4.1 Regression] VRP ICE in |compare_name_with_value |compare_name_with_value Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24670
[Bug tree-optimization/24670] [4.1 Regression] VRP ICE in compare_name_with_value
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 13:16 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-04 13:16:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24670
[Bug c++/24671] [4.0/4.1 regression] ICE with zero-sized arrays
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 13:19 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-04 13:19:06 date|| Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24671
[Bug middle-end/24635] Wrong statement reordering
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-04 13:25 --- I still cannot reproduce it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug tree-optimization/24670] [4.1 Regression] VRP ICE in compare_name_with_value
-- dnovillo at gcc dot gnu dot org changed: What|Removed |Added CC|dnovillo at redhat dot com | AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24670
[Bug target/24672] ICE on missing parentheses for constructor
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 13:28 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||error-recovery Last reconfirmed|-00-00 00:00:00 |2005-11-04 13:28:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24672
[Bug middle-end/24635] Wrong statement reordering
--- Comment #5 from worm at arrakis dot es 2005-11-04 13:35 --- Sorry for my stupidity -- the jet-lag after a long trip seems to affect me --. Remove the volatile statement from the arguments list of L1foo. Then the assignments to the variable V1 are moved after the call to cl_throw() and are never executed. I am not sure whether this conforms to the standard or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug tree-optimization/24599] [4.0 regression] segv after overflow detection
--- Comment #4 from rakdver at gcc dot gnu dot org 2005-11-04 13:39 --- Nevertheless, the fact that boolean_true_node has overflow flag set is wrong, this should not happen -- shared constants should not be modified. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599
[Bug tree-optimization/24599] [4.0 regression] segv after overflow detection
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-11-04 14:02 ---
This happens in c-typeck.c:build_c_cast:
value = convert (type, value);
/* Ignore any integer overflow caused by the cast. */
if (TREE_CODE (value) == INTEGER_CST)
{
/* If OVALUE had overflow set, then so will VALUE, so it
is safe to overwrite. */
if (CONSTANT_CLASS_P (ovalue))
{
TREE_OVERFLOW (value) = TREE_OVERFLOW (ovalue);
/* Similarly, constant_overflow cannot have become cleared. */
TREE_CONSTANT_OVERFLOW (value) = TREE_CONSTANT_OVERFLOW (ovalue);
}
build_c_cast assumes that convert will not return non-overflowed constant if it
received an overflowed one. This however is not true, since
convert (boolean_type_node, ...) will sometimes return shared
boolean_{true,false}_node constants.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599
[Bug middle-end/24635] Wrong statement reordering
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-04 14:05 --- Removing volatile will change the semantics of the program and therefor not a bug. GCC docs mention with (I cannot find right now as I am at a Kiosk and it is hard to find anything) longjmp, volatile is required. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug fortran/24673] New: internal compiler error in fold_convert, at fold-const.c:2028
Hi, This bug seems not very different from bug #20244 but happens at a different line in the same function. during compilation of my code I get the following error mesage: [EMAIL PROTECTED] 5common]$ /usr/local/bin/gfortran -c ../../../src/5common/funcofrho_tfw.F90 ../../../src/5common/funcofrho_tfw.F90: In function init_eneofrho_tfw: ../../../src/5common/funcofrho_tfw.F90:82: internal compiler error: in fold_convert, at fold-const.c:2028 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Sorry but I can't reduce the code more than that. It's in three files of which onlys the first result in an error: FUNCOFRHO_TFW.F90: module funcofrho_tfw use defs_basis use defs_datatypes implicit none !! common variables copied from input integer :: ngfft(18),nfftf real(dp):: ucvol type(MPI_type) :: mpi_enreg real(dp),allocatable::deltaW(:,:) real(dp),allocatable::lavnlfft(:,:) real(dp),allocatable::vtrial(:,:) !! common variables computed logical :: ok=.false. integer :: nfftot real(dp):: alpha !! initialisation routine contains !!---!! !! initialisation subroutine !!---!! subroutine init_eneofrho_tfw(ngfft_in,nfftf_in,mpi_enreg_in,ucvol_in,deltaW_in, lavnlfft_in,vtrial_in ) use defs_basis use defs_datatypes implicit none !Arguments integer,intent(in) :: ngfft_in(18),nfftf_in type(MPI_type),intent(in) :: mpi_enreg_in real(dp),intent(in):: ucvol_in real(dp),dimension(:,:),intent(in)::deltaW_in(:,:) real(dp),dimension(:,:),intent(in)::lavnlfft_in(:,:) real(dp),dimension(:,:),intent(in)::vtrial_in(:,:) !Local variables--- !!allocation and array transfer allocate(deltaW(size(deltaW_in,1),size(deltaW_in,2)), lavnlfft(size(lavnlfft_in,1),size(lavnlfft_in,2)), vtrial(size(vtrial_in,1),size(vtrial_in,2))) deltaW=deltaW_in lavnlfft=lavnlfft_in vtrial=vtrial_in ngfft=ngfft_in nfftf=nfftf_in ucvol=ucvol_in mpi_enreg=mpi_enreg_in !! set ok to 1 which allow using eneofrho_tfw ok = .true. !! alpha is a constant factor used many times in the tfw calculation of energy alpha=(3._dp*pi*pi)**two_thirds !!total number of grid point (from energy.F90) nfftot=ngfft(1)*ngfft(2)*ngfft(3) end subroutine init_eneofrho_tfw end module funcofrho_tfw DEFS_BASIS.F90 module defs_basis implicit none integer, parameter :: i1b=selected_int_kind(2) integer, parameter :: i2b=selected_int_kind(4) integer, parameter :: i4b=selected_int_kind(9) integer, parameter :: dp=kind(1.0d0) integer, parameter :: dpc=kind((1.0d0,1.0d0)) integer, parameter :: lgt=kind(.true.) integer, parameter :: fnlen=132! maximum length of file name variables integer, parameter :: strlen=32000 ! maximum length of input string integer, parameter :: integer_not_used=0 logical, parameter :: logical_not_used=.true. integer, parameter :: std_in=5,ab_in=5 integer, parameter :: std_out=6 integer, parameter :: ab_out=7 integer, parameter :: tmp_unit=9,tmp_unit2=10 real(dp), parameter :: zero=0._dp real(dp), parameter :: one=1._dp real(dp), parameter :: two=2._dp real(dp), parameter :: three=3._dp real(dp), parameter :: four=4._dp real(dp), parameter :: five=5._dp real(dp), parameter :: six=6._dp real(dp), parameter :: seven=7._dp real(dp), parameter :: eight=8._dp real(dp), parameter :: nine=9._dp real(dp), parameter :: ten=10._dp !Fractionary real constants real(dp), parameter :: half=0.50_dp real(dp), parameter :: third=one/three real(dp), parameter :: quarter=0.25_dp real(dp), parameter :: fifth=0.20_dp real(dp), parameter :: sixth=one/six real(dp), parameter :: seventh=one/seven real(dp), parameter :: eighth=0.125_dp real(dp), parameter :: ninth=one/nine real(dp), parameter :: two_thirds=two*third real(dp), parameter :: four_thirds=four*third real(dp), parameter :: five_thirds=five*third real(dp), parameter :: three_quarters=0.75_dp real(dp), parameter :: three_fifth=three/five !Real constants derived from pi real(dp), parameter :: gold=1.618033988749894848204586834365638117720309179_dp real(dp), parameter :: goldenratio=two-gold real(dp), parameter :: pi=3.141592653589793238462643383279502884197_dp real(dp), parameter :: two_pi=two*pi real(dp), parameter :: four_pi=four*pi real(dp), parameter :: piinv=one/pi end module defs_basis DEFS_DATATYPES.F90 module defs_datatypes use defs_basis #if defined MPIO include 'mpif.h' #endif implicit none !-- !!t* defs_datatypes/MPI_type !! NAME !! MPI_type !! !! FUNCTION !! The MPI_type structured datatype gather different information !! about the MPI
[Bug tree-optimization/24670] [4.1 Regression] VRP ICE in compare_name_with_value
--- Comment #2 from dnovillo at gcc dot gnu dot org 2005-11-04 14:19 --- testing fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24670
[Bug fortran/24673] internal compiler error in fold_convert, at fold-const.c:2028
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 14:26 --- It is the same as PR 20244, the line number changed because fold-const.c has changed and addded code. *** This bug has been marked as a duplicate of 20244 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24673
[Bug fortran/20244] internal compiler error: in fold_convert, at fold-const.c:2003
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-04 14:26 --- *** Bug 24673 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||anglade at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20244
[Bug ada/20753] ACATS ce3810b segfaults at runtime
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-04 14:27 --- Subject: Re: ACATS ce3810b segfaults at runtime --- Comment #8 from christian dot joensson at gmail dot com 2005-11-04 11:24 --- Just a ping here... are there any progress on this? No, I haven't had time to investigate further. The status is still the same. See http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00124.html. The majority of the Ada failures are caused by this problem. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20753
[Bug c++/24667] [4.0/4.1 Regression] -Wcast-qual fails to reject offending cast for a old style cast
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-04 14:33 --- Hmm, old (C) style casts are weird, IIRC they act as either a static_cast, a reinterpret_cast, or a const_cast. In this case they are acting like a const_cast which is what is normally goes and gets rid of a qualifier. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Summary|-Wcast-qual fails to reject |[4.0/4.1 Regression] -Wcast- |offending cast |qual fails to reject ||offending cast for a old ||style cast Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24667
[Bug libstdc++/21072] base allocator change shared object issues
--- Comment #5 from matz at suse dot de 2005-11-04 14:45 --- While 4.0 had this fixed, trunk still uses the 'mt' allocator by default on linux, and hence is incompatible with 3.4 and 4.0 by default. Is that really intended, or shouldn't also trunk default back to the 'new' allocator? -- matz at suse dot de changed: What|Removed |Added CC||matz at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072
Re: arm-elf-nm --print-size fails on static variables
2005/11/3, Daniel Jacobowitz [EMAIL PROTECTED]: On Thu, Nov 03, 2005 at 02:15:27PM -0700, Shaun Jackman wrote: When an object file is compiled by arm-elf-gcc 4.0.2, nm -S 2.16.* isn't printing the size of static variables. I'd very much appreciate a fix or workaround, if one is out there. Check what the file really says, using readelf. If the sizes are unset, check a CVS version of GCC or report the bug to GCC's bugzilla. That's more likely than an nm bug. It certainly appears to be a GCC bug. Cheers, Shaun $ cat foo.c int foo; static int static_foo; $ arm-elf-gcc -c foo.c $ arm-elf-readelf -s foo.o | grep foo 1: 0 FILELOCAL DEFAULT ABS foo.c 6: 0 NOTYPE LOCAL DEFAULT3 static_foo 8: 0004 4 OBJECT GLOBAL DEFAULT COM foo $ gcc -c foo.c $ readelf -s foo.o | grep foo 1: 0 FILELOCAL DEFAULT ABS foo.c 5: 4 OBJECT LOCAL DEFAULT3 static_foo 8: 0004 4 OBJECT GLOBAL DEFAULT COM foo $ arm-elf-gcc --version | head -1 arm-elf-gcc (GCC) 4.0.2 $ arm-elf-readelf --version | head -1 GNU readelf 2.16.91 20051103 $ gcc --version | head -1 gcc (GCC) 4.0.2 (Debian 4.0.2-2) $ readelf --version | head -1 GNU readelf 2.16.1-multiarch Debian GNU/Linux
[Bug fortran/20244] internal compiler error: in fold_convert, at fold-const.c:2003
--- Comment #4 from anglade at gmail dot com 2005-11-04 14:54 --- Hi all, Looking at the examples of failure due to this bug, I've observed that they are due to user defined datatype. The function fold_convert seems to handle only intrinsic datatypes while the examples were using user defined one. If user-defined datatypes are removed, the compilation just go through fine. This feeling about datatype is confirmed by a meer look at fold-const.c. Which is switch/casing the datatypes. Unfortunately I'm not a gcc expert and really don't know how this should be bug-fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20244
[Bug fortran/20244] internal compiler error: in fold_convert, at fold-const.c:2003
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-04 14:58 --- (In reply to comment #4) Unfortunately I'm not a gcc expert and really don't know how this should be bug-fixed. The way this bug needs to be fixed is one of the following: 1. the types generated need to be in the exact location 2. The types need to be declared as TYPE variants of one another. 3. The fortran front-end needs to say that these types are compatible. All of the above need to be fixed in the front-end and not in the middle-end where fold_convert resides. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20244
[Bug fortran/20244] internal compiler error: in fold_convert, at fold-const.c:2003
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-04 14:59 --- (In reply to comment #5) Oh and one more thing, the use of fold_convert is not the incorrect thing to do here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20244
[Bug c/24675] New: Stack corruption in ARM arch. if 64bit variable is passed to a function of which the low 32 use the register and the up 32 use the stack
Reproducable: Very easy to reproduce with the sample code
application provided. PLEASE COMPILE the code with -O2 option.
Product: GCC for ARMV5L
Component: C
Version: 3.2.1. (Reported also in ARM Linux community to
be see with gcc 3.3.4, gcc 3.4.2)
Host Platform: x86 Linux 2.4.x
Target Platform: Intel Xscale 80315 (ARMV5L) running Linux 2.4.28.
Issue should be seen with most of the ARM target.
Description:
Stack corruption is seen in ARM arch. when many variables
are passed to a function AND
if one of the variable is long long AND
if that long long variable is passed by its lower-32 use the
register and the upper-32 use the stack (a case when r0, r1,
r2 is already used by other passed variables)
Values are not correctly passed to the function.
Sample Code (PLEASE COMPILE with -O2 option):
#include stdio.h
typedef unsigned char u8;
typedef unsigned int u32;
typedef unsigned long long u64;
void testfunction (void *buffer1, void *buffer2, u8 count, u64 startsector);
void calledfunction1(void *buffer, u64 startsector, u32 count, u8
opcode, u32 sign);
main()
{
testfunction (NULL, NULL, 8, 0x700ULL);
}
void testfunction (void *buffer1, void *buffer2, u8 count, u64 startsector)
{
calledfunction1 (NULL, startsector, 0x55, 0x20, 0x3a3a3a3a);
}
void calledfunction1 (void *buffer, u64 startsector, u32 count,
u8 opcode, u32 sign)
{
if(opcode == 0x3a)
printf( opcode now is 0x3a\n);
printf (opcode: %x, , opcode);
printf( sign:%x\n,sign);
return;
}
Output of the Sample Code:
opcode now is 0x3a
opcode: 3a, sign:40039420
Expected Output of the Sample Code:
opcode: 20, sign:3a3a3a3a
--
Summary: Stack corruption in ARM arch. if 64bit variable is
passed to a function of which the low 32 use the
register and the up 32 use the stack
Product: gcc
Version: 3.2.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bill dot thompsons at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24675
[Bug target/24675] Stack corruption in ARM arch. if 64bit variable is passed to a function of which the low 32 use the register and the up 32 use the stack
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 15:08 --- 3.2.1 is an old compiler and the 3.2 series is no longer being updated, can you try either a 3.3.6 (note the 3.3 series is not being updated either) or a 3.4.4 or a 4.0.2 GCC? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24675
[Bug libgcj/14358] Selection of default encoding is not sufficient with EUC-JP on FreeBSD
--- Comment #5 from tromey at gcc dot gnu dot org 2005-11-04 15:08 --- Subject: Bug 14358 Author: tromey Date: Fri Nov 4 15:08:18 2005 New Revision: 106490 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106490 Log: PR libgcj/14358, libgcj/24552: * gnu/gcj/convert/IOConverter.java: Regenerate aliases. Add aliases for 'euc_jp' and 'eucjp'. * scripts/encodings.pl: Recognize 'none', not 'NONE'. Include canonical names in output. (%map): Added UnicodeLittle and UnicodeBig. Modified: trunk/libjava/ChangeLog trunk/libjava/gnu/gcj/convert/IOConverter.java trunk/libjava/scripts/encodings.pl -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14358
[Bug libgcj/14358] Selection of default encoding is not sufficient with EUC-JP on FreeBSD
--- Comment #6 from tromey at gcc dot gnu dot org 2005-11-04 15:09 --- Fix is on 4.0 branch and trunk. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14358
[Bug libgcj/24552] Encoding alias EUC_JP missing
--- Comment #5 from tromey at gcc dot gnu dot org 2005-11-04 15:09 --- Fix is on 4.0 branch and trunk. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24552
[Bug middle-end/24635] Wrong statement reordering
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-04 15:24 --- Woops, that should have been ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2005-11-04 15:24:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug middle-end/24635] Wrong statement reordering
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-04 15:24 --- Woops, that should have been ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug middle-end/24635] Wrong statement reordering
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-04 15:25 --- Closed as invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug c/24599] [4.0/4.1 regression] Overflow for true value
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-04 15:28 ---
Here is a testcase which is better representive of the issue (compile with
-std=c99 -pedantic-errors):
#include stdbool.h
int
main (int argc, char **argv)
{
if ((bool)((1527719483 + 1477819644))) {
}
return 0;
}
bool t1 = true;
--
t.c: In function main:
t.c:6: warning: integer overflow in expression
t.c: At top level:
t.c:12: error: overflow in constant expression
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|tree-optimization |c
Keywords||diagnostic, rejects-valid
Known to fail|4.0.3 |4.0.3 4.1.0
Known to work|4.1.0 3.4.0 |3.4.0
Summary|[4.0 regression] segv after |[4.0/4.1 regression]
|overflow detection |Overflow for true value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599
[Bug fortran/20244] internal compiler error: in fold_convert, at fold-const.c:2003
--- Comment #7 from anglade at gmail dot com 2005-11-04 15:31 --- I've simplified to it's (almost) simplest expression the test case: module mtyp type t1 integer::a end type t1 end module mtyp module atest use mtyp type(t1)::ze contains subroutine test(ze_in ) use mtyp implicit none type(t1)::ze_in ze=ze_in end subroutine test end module atest I've try to backtrace the call up to the front-end. But I'm not able to do that since I really don't know the structure of gcc (and since ddd/gdb keeps busying me with stupid error message). I'd be glade to fix the bug if someone can introduce me a little bit more to the code. (any link for gcc beginners??) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20244
[Bug target/19340] Compilation SEGFAULTs with -O1 -fschedule-insns2 -fsched2-use-traces on an x86 architecture.
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-04 15:32 --- Fails on the mainline for me. t.c: In function g: t.c:23: internal compiler error: in move_for_stack_reg, at reg-stack.c:1062 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.1.0 | Last reconfirmed|2005-01-08 23:59:22 |2005-11-04 15:32:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19340
