Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/75b797b2d4257f74
subroutine foo(c)
character*(*) c
namelist /abc/ c
end subroutine
is accepted by gfortran. Other compilers give the correct error:
fortcom: Error: aaa.f, line 3: A namelist-group-object must not
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221319
raises a question whether:
std::complexdouble (1.0, 1.0) / 0.0
and
std::complexdouble (1.0, 1.0) / std::complexdouble (0.0, 0.0)
can or can't be NaN. In C say:
#define I (__extension__ 1.0iF)
_Complex double d = 1.0 + 0.0 * I, e, f, z =
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-01-16 10:36 ---
If you rely on support and maintainance for gcc releases that have been
discontinued by the FSF you need to get to your system vendor providing the old
gcc or to an external contractor.
--
I was reworking an existing AVR application for C89 compatibility, and while
doing so, found an internal compiler error while dealing with inline assembly.
I have taken the offending function and trimmed the code to a minimum for a
test.
Output is as follows:
test.c: In function
--- Comment #1 from richard at vems dot co dot nz 2007-01-16 11:19 ---
Created an attachment (id=12910)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12910action=view)
Preprocessed source of test.c (test.i)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30483
--- Comment #8 from bugzilla at bennee dot com 2007-01-16 11:28 ---
(In reply to comment #7)
However if the -mno-80387 option is meant to disable x87 instructions then it
should be possible to build something without causing and x87 instructions
to
be emitted shouldn't it?
--- Comment #1 from patchapp at dberlin dot org 2007-01-16 14:51 ---
Subject: Bug number PR30476
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/2007-01/msg01324.html
--
The program below shows (at all the optimization levels) a miscompilation of
the remainder expression that causes INT_MIN % -1 to cause a SIGFPE on CPUs of
the i386 family.
#include limits.h
#include stdio.h
int minus_one(int n) {
return (n+1)*(n-1)-n*n;
}
void p(int x, int y) {
int z = x %
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |target
--- Comment #9 from tg at mirbsd dot org 2007-01-16 16:56 ---
Subject: Re: Integer Overflow detection code optimised away,
-fwrapv broken
rguenth at gcc dot gnu dot org dixit:
If you rely on support and maintainance for gcc releases that have been
discontinued by the FSF you need to
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-01-16 17:18
---
We do weight between cost and result which is a reason we keep branches in
active maintainance for a long time. But we need to focus on where the
majority of our users are, which is gcc 4.1 nowadays. We don't
--- Comment #11 from tg at mirbsd dot org 2007-01-16 17:34 ---
Subject: Re: Integer Overflow detection code optimised away,
-fwrapv broken
rguenth at gcc dot gnu dot org dixit:
But we need to focus on where the majority of our users are, which is
gcc 4.1 nowadays.
I highly doubt
--- Comment #12 from tg at mirbsd dot org 2007-01-16 17:49 ---
Reopening this bug because http://gcc.gnu.org/ml/gcc/2006-12/msg00749.html
states that:
For example, GCC itself assumes wrapv semantics internally,
This implies that gcc2 and gcc3 cannot compile gcc correctly,
unless using
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-01-16 18:00
---
(In reply to comment #12)
Reopening this bug because http://gcc.gnu.org/ml/gcc/2006-12/msg00749.html
states that:
For example, GCC itself assumes wrapv semantics internally,
And those places are getting fixed.
--- Comment #14 from gdr at cs dot tamu dot edu 2007-01-16 18:01 ---
Subject: Re: Integer Overflow detection code optimised away, -fwrapv broken
rguenth at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| We do weight between cost and result which is a reason we keep branches in
|
--- Comment #5 from sayle at gcc dot gnu dot org 2007-01-16 18:15 ---
Subject: Bug 30404
Author: sayle
Date: Tue Jan 16 18:15:19 2007
New Revision: 120829
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120829
Log:
2007-01-16 Roger Sayle [EMAIL PROTECTED]
PR
--- Comment #27 from patchapp at dberlin dot org 2007-01-16 19:45 ---
Subject: Bug number PR middle-end/18071
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/2007-01/msg01366.html
--
The tests pr23816-1.c and vect-111.c (from gcc.dg/vect) generate an ICE when
compiled with -fno-trapping-math for rs6000:
$ gcc pr23816-1.c -fno-trapping-math -ftree-vectorize -maltivec -O2
pr23816-1.c: In function 'foo':
pr23816-1.c:9: internal compiler error: in rs6000_emit_vector_compare, at
/scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2-final/./gcc/cc1
-E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v -I.
-I/scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/libgfortran -I.
Hi:
I noticed that whenever I use a math function (such as sqrt, cos, log) in a
forall all statement that further uses of that function caused gfortran to say
that the function has no implicit type. I've shown an example program below:
program test
implicit none
integer :: i
real :: a,
--- Comment #41 from dcb314 at hotmail dot com 2007-01-16 21:18 ---
(In reply to comment #40)
I've a patch, which is currently blocked by -fivopts bug
Still blocked ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-16 21:30 ---
Confirmed with gfortran 4.3.0 20070116.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from schnetter at aei dot mpg dot de 2007-01-16 21:45
---
This is what Apple thinks about tgmath.h. See
http://developer.apple.com/releasenotes/DeveloperTools/RN-GCC4/index.html:
Major bugs fixed in this release of GCC 4.0:
radar 2872232: Compiler should provide a
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-16 21:50 ---
Fortran 95:
Constraint:
A namelist-group-object shall not be an array dummy argument with a nonconstant
bound, a variable with nonconstant character length, an automatic object, a
pointer, a variable of a type that
--- Comment #7 from manu at gcc dot gnu dot org 2007-01-16 22:02 ---
(In reply to comment #5)
Created an attachment (id=7299)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7299action=view) [edit]
proposed patch
I've attached a more official-looking patch, with a testsuite
--- Comment #1 from vincent at vinc17 dot org 2007-01-16 22:03 ---
Is this specific to x86? On PowerPC (gcc 4.0.1 from Mac OS X), I get:
-2147483648 % -1 - -2147483648
Ditto with:
#include limits.h
#include stdio.h
int main (void)
{
volatile int i = INT_MIN, j = -1;
printf
--- Comment #2 from vincent at vinc17 dot org 2007-01-16 22:10 ---
-2147483648, this was on a G5, with gcc 4.0.1 under Mac OS X. On a G4 under
Linux, with gcc 4.1.2 prerelease (Debian), I get 2147483647.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-16 22:11 ---
(In reply to comment #1)
Is this specific to x86? On PowerPC (gcc 4.0.1 from Mac OS X), I get:
This is because the PPC ISA says for divide:
If an attempt is made to perform either of the divisions -- 0x8000_ /
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-16 22:15 ---
(In reply to comment #3)
So the ISA in fact even mentions this case :).
But the PPC compiler writers guide does not talk about that case, hmmm.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-16 22:35 ---
(In reply to comment #5)
Created an attachment (id=7299)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7299action=view) [edit]
proposed patch
I've attached a more official-looking patch, with a testsuite
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-01-16
23:04 ---
Subject: Re: [4.3 Regression]
classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: error: cannot find file for
class gnuRO
make -j 2 bootstrap
Error also occurs with make bootstrap.
Dave
--
--- Comment #13 from manu at gcc dot gnu dot org 2007-01-17 00:47 ---
#include cassert
template typename Int, Int D
void f(Int x) {
assert(0 = x and x = D);
}
int main() {
funsigned char, 2(5);
fsigned char, 2(5);
}
We don't emit a warning when instantiated as a signed char, so
--- Comment #14 from gdr at cs dot tamu dot edu 2007-01-17 00:59 ---
Subject: Re: unsigned warning in template
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| #include cassert
| template typename Int, Int D
| void f(Int x) {
| assert(0 = x and x = D);
| }
| int main() {
|
--- Comment #15 from manu at gcc dot gnu dot org 2007-01-17 01:11 ---
(In reply to comment #14)
| We don't emit a warning when instantiated as a signed char, so everything
boils
| down to having an option to disable the warning, doesn't it?
the logical inference escapes me.
Is
--- Comment #16 from gdr at cs dot tamu dot edu 2007-01-17 01:30 ---
Subject: Re: unsigned warning in template
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| (In reply to comment #14)
| | We don't emit a warning when instantiated as a signed char, so everything
| boils
|
--- Comment #17 from tromey at gcc dot gnu dot org 2007-01-17 01:32 ---
A flag to control the warning does not provide
fine enough granularity of control. That is, sometimes
the warning is appropriate, and disabling the warning
would let through code that you would prefer not to let
--- Comment #2 from kargl at gcc dot gnu dot org 2007-01-17 01:37 ---
A workaround for this problem is place parentheses around the
mask in the forall. The parentheses force evaluation of the
expression whereas gfortran is apparently taking a different
path through the compiler
--- Comment #2 from kargl at gcc dot gnu dot org 2007-01-17 01:37 ---
*** Bug 30487 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from gdr at cs dot tamu dot edu 2007-01-17 01:46 ---
Subject: Re: unsigned warning in template
tromey at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| A flag to control the warning does not provide
| fine enough granularity of control.
Indeed.
| That is,
--- Comment #19 from manu at gcc dot gnu dot org 2007-01-17 03:49 ---
(In reply to comment #16)
Subject: Re: unsigned warning in template
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| (In reply to comment #14)
| | We don't emit a warning when instantiated as a
--- Comment #1 from pcarlini at suse dot de 2007-01-17 04:20 ---
I'm marking this one as duplicate of the other: by now we know well it's really
the same issue and in any case an audit is necessary (assuming the warning
stays, of course)
*** This bug has been marked as a duplicate of
--- Comment #8 from pcarlini at suse dot de 2007-01-17 04:20 ---
*** Bug 30463 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
--- Comment #9 from pcarlini at suse dot de 2007-01-17 04:22 ---
Gaby, any news about the signed - unsigned warning itself? Are we going to
keep it or are we coming to the conclusion it's too noisy?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
--- Comment #1 from pcarlini at suse dot de 2007-01-17 04:48 ---
Jakub, a few observations: the first one, we have got other PRs about complex
math (e.g., 24581, 28408), I don't know if you are aware of that, it would be
great if you could have a unified look. Also, I don't think we
After make check-treelang, I have a treelang subdirectory within
build/gcc/testsuite, but no files end up in it, and treelang.log ends up in the
build/gcc/testsuite directory.
--
Summary: treelang.log ends up in main testsuite dir, not treelang
subdir.
--- Comment #9 from ubizjak at gmail dot com 2007-01-17 06:58 ---
(In reply to comment #4)
Testcase compiles OK with gcc version 4.3.0 20070115 (experimental).
Uh, I was compiling in 32bit mode. For x86_64 compilation fails as documented
in comment #3.
--
ubizjak at gmail dot com
--- Comment #5 from jv244 at cam dot ac dot uk 2007-01-17 07:14 ---
(In reply to comment #0)
The program below shows (at all the optimization levels) a miscompilation of
the remainder expression that causes INT_MIN % -1 to cause a SIGFPE on CPUs of
the i386 family.
notice that this
--- Comment #2 from avg07 at tid dot es 2007-01-17 07:23 ---
Created an attachment (id=12912)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12912action=view)
patch to rev 120440: make additional check on arglist
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30473
48 matches
Mail list logo
