--- Comment #1 from brooks at gcc dot gnu dot org 2006-12-17 08:34 ---
I think this patch fixes this; I'm testing it now:
Index: interface.c
===
--- interface.c (revision 119980)
+++ interface.c (working copy)
@@ -1446,6
--- Comment #3 from dcb314 at hotmail dot com 2006-12-17 09:05 ---
(In reply to comment #2)
I expect to try out 4.3-20061216.
I tried it out and it is still broken.
Is that three snapshots in a row
that fail on x86_64 ?
--
dcb314 at hotmail dot com changed:
What
Alternate-return arguments in argument lists are represented by a null symbol
or expression pointer. In intrinsic.c, remove_nullargs() simply removes
null-pointer symbols from the argument list handled by an intrinsic function or
subroutine. Ergo, an alternate-return actual argument in an
For non-array calls, the if is directly created in
trans-intrinsic.c's gfc_conv_associated.
As one can see below, gfortran currently only checks whether two pointers are
the same, it also should check whether they are NULL pointers.
Example:
integer, pointer :: a
nullify(a)
if(associated(a,a))
--- Comment #47 from doko at gcc dot gnu dot org 2006-12-17 13:47 ---
Subject: Bug 11953
Author: doko
Date: Sun Dec 17 13:46:58 2006
New Revision: 119986
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119986
Log:
2006-12-17 Matthias Klose [EMAIL PROTECTED]
PR
--- Comment #48 from doko at gcc dot gnu dot org 2006-12-17 13:53 ---
Subject: Bug 11953
Author: doko
Date: Sun Dec 17 13:53:07 2006
New Revision: 119987
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119987
Log:
2006-12-17 Matthias Klose [EMAIL PROTECTED]
PR
--- Comment #49 from doko at gcc dot gnu dot org 2006-12-17 13:57 ---
Subject: Bug 11953
Author: doko
Date: Sun Dec 17 13:57:31 2006
New Revision: 119988
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119988
Log:
2006-12-17 Matthias Klose [EMAIL PROTECTED]
PR
--- Comment #2 from nickols_k at mail dot ru 2006-12-17 14:18 ---
Created an attachment (id=12820)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12820action=view)
preprocessed source file as requires bugs.html
gcc's output on -v:
gcc4: warning: -pipe ignored because -save-temps
--- Comment #1 from pault at gcc dot gnu dot org 2006-12-17 14:23 ---
Brooks,
The standard has no problem with this, as you surmise.
The first segfault is in count_types_test, where an attempt is made to use the
non-existent formal symbol. This should be asy to fix - it's a matter of
--- Comment #2 from pault at gcc dot gnu dot org 2006-12-17 14:27 ---
(In reply to comment #1)
I think this patch fixes this; I'm testing it now:
If it doesn't work, I'll eat my protective cranial wear...
Good one!
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30235
--- Comment #35 from steven at gcc dot gnu dot org 2006-12-17 14:47 ---
This should be fixed when the dataflow branch is merged. There is a new pass
there dedicated to generating auto-inc/dec insns. If the pass in
auto-inc-dec.c on the dataflow branch does not fix this issue, a proper
--- Comment #4 from steven at gcc dot gnu dot org 2006-12-17 14:48 ---
There will be no more delete_trivially_dead_insns when the dataflow branch is
merged.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18995
--- Comment #4 from steven at gcc dot gnu dot org 2006-12-17 14:57 ---
That patch was already approved:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01982.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29858
--- Comment #2 from pault at gcc dot gnu dot org 2006-12-17 15:46 ---
Created an attachment (id=12821)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12821action=view)
Patch for PR
This produces code that works correctly and is halfway through a regtest.
I'll do the submit
The Intel Fortan Compiler issues an error on the code below
INTEGER FUNCTION foo()
INTEGER :: foo
foo = 0
END FUNCTION
gfortran takes it without further notice. Letting INTEGER :: foo be REAL ::
foo gives Error: Symbol 'foo' at (1) already has basic type of INTEGER on
gfortran as well.
$
The -f(no-)inline-functions option does not work. Its documented
effect is controlled by -f(no-)inline, both in gcc and g++.
(Don't ask me how that jibes with Bug #27881:-)
The doc says -finline-functions is only invoked by -O3. I suggest
you preserve -O's current functionality: Move
Hello,
i'm not sure this is the right place to report this. Please direct me elsewhere
if it's not.
I'm trying to build generic binaries for lilypond (lilypond.org), using a x86
pc targetting linux/ppc. I'm building a cross-compiler against the
Debian/stable libs/headers.
My problem is that
--- Comment #29 from pertusus at free dot fr 2006-12-17 18:21 ---
getarg intrinsic which was in g77 also seems to be unimplemented?
--
pertusus at free dot fr changed:
What|Removed |Added
--- Comment #6 from sayle at gcc dot gnu dot org 2006-12-17 18:28 ---
Subject: Bug 30207
Author: sayle
Date: Sun Dec 17 18:28:07 2006
New Revision: 119990
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119990
Log:
2006-12-17 Roger Sayle [EMAIL PROTECTED]
Steven G.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-17 19:02 ---
You want -fno-inline-functions-called-once which was added in 4.2.0 IIRC (it is
in 4.3.0 for sure).
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options
--
pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-17 19:04 ---
This symbol has differing versions across platforms (GLIB_2.1 on Fedora Core,
Yellow Dog Linux and GLIBC_PRIVATE on Debian/stable)
And this is not a GCC bug really because glibc changed so really either this is
a
--- Comment #1 from patchapp at dberlin dot org 2006-12-17 19:10 ---
Subject: Bug number PR30238
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01228.html
--
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
--- Comment #1 from burnus at gcc dot gnu dot org 2006-12-17 20:15 ---
This is because in symbol.c's gfc_add_type there is
const char *msg = Symbol '%s' at %L already has basic type of %s;
if (!(sym-ts.type == ts-typesym-ts.type == ts-type
(sym-attr.flavor ==
--- Comment #1 from tobi at gcc dot gnu dot org 2006-12-17 20:22 ---
From the comment preceding remove_nullargs() I wonder why it's called in the
beginning of sort_actual().
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tobi at gcc dot gnu dot org 2006-12-17 20:34 ---
I couldn't reproduce this, and Tobias Burnus thinks it coudl be an issue in his
tree.
tobias-schluters-computer:~/src/pr/30228 tobi$ cat t.f90
type pt
integer, pointer :: p(:)
end type pt
type(pt), pointer :: t(:)
--- Comment #3 from tobi at gcc dot gnu dot org 2006-12-17 20:37 ---
Maybe we should add a new expression type EXPR_LABEL_REF or whatever better
name you might come up with for the label references? This seems much less
error-prone than checking for magic NULLs all over the compiler.
--- Comment #1 from tobi at gcc dot gnu dot org 2006-12-17 20:56 ---
As long as the callee doesn't change the value it's probably valid, so this
would need some kind of interprocedural analysis to give a correct error. A
warning may be in place, though. This shouldn't be to hard, we
--- Comment #7 from deji_aking at yahoo dot ca 2006-12-17 21:10 ---
Thanks Rogers and Steve for the resolution of this bug. I hope you'll not
forget to commit it to the gcc-4.2 branch.
PS: I've applied the patch cleanly to the 4.2 branch but have not got the
opportunity to build and
--- Comment #2 from burnus at gcc dot gnu dot org 2006-12-17 21:20 ---
As long as the callee doesn't change the value it's probably valid, so this
would need some kind of interprocedural analysis to give a correct error.
I think it is formally seen invalid as you have INTENT([IN]OUT)
--- Comment #17 from burnus at gcc dot gnu dot org 2006-12-17 23:19 ---
Using the patch of PR 30223 (add cbrt, cexpi and sincos to Fortran), I don't
get any speed up (21.95s for fatigue).
Using additionally http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00958.html
(folding of cexp ()) I
--- Comment #5 from dfranke at gcc dot gnu dot org 2006-12-17 23:27 ---
Subject: Bug 29949
Author: dfranke
Date: Sun Dec 17 23:27:47 2006
New Revision: 119995
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119995
Log:
2006-12-18 Daniel Franke [EMAIL PROTECTED]
Backport
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-18 00:05 ---
Fixed for 4.1.2, this is a bug with -ftree-loop-linear which was known to be
broken for 4.1.1.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from patchapp at dberlin dot org 2006-12-18 00:20 ---
Subject: Bug number PR7651
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01244.html
--
--- Comment #2 from hubicka at gcc dot gnu dot org 2006-12-18 02:54 ---
Mine, working on fix.
Honza
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
gcc 4.3 current svn branch revision 120001
it's not possible to have -save-temps since the compiler
bombs while assembling cygwin.asm using gcc (uh?)
/d/Download/Devel/MinGW/gcc-source/build/./gcc/xgcc
-B/d/Download/Devel/MinGW/gcc-source/build/./gcc/
--- Comment #1 from sherpya at netfarm dot it 2006-12-18 03:31 ---
I forgot to attach the error:
cc1.exe: internal compiler error: in add_standard_paths, at c-incpath.c:173
so it's not in gcc but the preprocessor
I've bootstrapped from 4.1.1
--
sherpya at netfarm dot it changed:
avr-gcc (GCC) 4.1.1
Compilation of next program (-W -Wall -Os -S):
extern int signbit (double);
int foo (double x)
{
return signbit (x);
}
causes an compilation abort with message:
internal compiler error: in gen_lowpart_general, at rtlhooks.c:51
Older versions are
--- Comment #2 from pault at gcc dot gnu dot org 2006-12-18 06:01 ---
This was a fix for a PR about a year ago - the std=gnu is meant, obviously, to
enforce all versions of the standard on this. However, a number of other
compilers did/do permit this wrinkle on the standard and it even
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-18 06:28 ---
Use --disable-libmudflap while building the stage1 gcc for the cross
compiler.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-18 06:29 ---
No feedback in 3 months so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from patchapp at dberlin dot org 2006-12-18 07:10 ---
Subject: Bug number PR30236
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01254.html
--
--- Comment #3 from burnus at gcc dot gnu dot org 2006-12-18 07:49 ---
This was a fix for a PR about a year ago - the std=gnu is meant, obviously, to
enforce all versions of the standard on this. However, a number of other
compilers did/do permit this wrinkle on the standard and it
43 matches
Mail list logo
