--- 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 i
--- 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
--
http://gcc.gnu.org/bugzilla/sh
--- 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 #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 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
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 wo
--- 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:
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/
-L/d/Download/Devel/MinGW/gcc-source/build/mi
--- 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
--- 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
--
http://gcc.gnu.org/bugzilla/sho
--- 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 #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=gcc&view=rev&rev=119995
Log:
2006-12-18 Daniel Franke <[EMAIL PROTECTED]>
Backp
--- 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 g
--- 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 #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 tes
--- 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 chec
--- 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: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(:)
in
--- 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 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.fl
--
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 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
--
http://gcc.gnu.org/bugzilla/sh
--- 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 gl
--- 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 chang
--- 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=gcc&view=rev&rev=119990
Log:
2006-12-17 Roger Sayle <[EMAIL PROTECTED]>
Steven G
--- 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
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 lib
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 -finline-fu
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.
--- 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=12821&action=view)
Patch for PR
This produces code that works correctly and is halfway through a regtest.
I'll do the submit tonigh
--- 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 #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 #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 #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 #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
p
--- 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=12820&action=view)
preprocessed source file as requires bugs.html
gcc's output on -v:
gcc4: warning: -pipe ignored because -save-temps
--- 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=gcc&view=rev&rev=119988
Log:
2006-12-17 Matthias Klose <[EMAIL PROTECTED]>
PR libstd
--- 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=gcc&view=rev&rev=119987
Log:
2006-12-17 Matthias Klose <[EMAIL PROTECTED]>
PR libstd
--- 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=gcc&view=rev&rev=119986
Log:
2006-12-17 Matthias Klose <[EMAIL PROTECTED]>
PR libstd
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))
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 intrins
--- 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|R
--- 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 +1
43 matches
Mail list logo
