--- Comment #32 from pinskia at gcc dot gnu dot org 2007-01-21 07:00
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-21 06:51 ---
Subject: Bug 30479
Author: pinskia
Date: Sun Jan 21 06:51:07 2007
New Revision: 121024
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121024
Log:
2007-01-20 Andrew Pinski <[EMAIL PROTECTED]>
PR ob
--- Comment #2 from akihana at gmail dot com 2007-01-21 06:48 ---
This is not a gcc bug.
--
akihana at gmail dot com changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from akihana at gmail dot com 2007-01-21 06:41 ---
Created an attachment (id=12925)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12925&action=view)
Preprocessor output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30523
This is the command-line:
gcc -c -O2 -Wall -I../modes aesxam.c
This is the offending assembly:
read_tsc:
...
#APP
cpuid; read_tsc
#NO_APP
...
The error is:
Error: invalid character '_' in mnemonic
GCC:
Configured with: /var/tmp/portage/gcc-4.1.1-r1/work/gcc-4.1.1/configure
--prefix=/u
--- Comment #1 from bangerth at dealii dot org 2007-01-21 05:34 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #2 from bangerth at dealii dot org 2007-01-21 05:33 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #3 from bangerth at dealii dot org 2007-01-21 05:32 ---
In any case, I consider this a bug in gcc. The problem doesn't happen with
gcc 3.3 or 3.4 or 4.0, so it's a regression.
That said, there's a second problem: before 4.1.x, we warned:
g/x> /home/bangerth/bin/gcc-4.0.x/bin
--- Comment #2 from bangerth at dealii dot org 2007-01-21 05:29 ---
No, that's not the case. We can print the types:
-
#include
#include
#include
struct S
{
unsigned int long long a:33;
};
int main ()
{
struct S x = { -1 };
typeof(+x.a) z = x.a+10;
printf("%llx\
--- Comment #3 from bangerth at dealii dot org 2007-01-21 05:23 ---
*** Bug 30281 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
---
--- Comment #3 from bangerth at dealii dot org 2007-01-21 05:23 ---
Here's an even simpler testcase that shows the same problem (even if the
error message is different):
-
struct a
{
int g(void);
};
struct b : a { };
void test()
{
static_cast (&b::g);
}
--- Comment #1 from bangerth at dealii dot org 2007-01-21 05:16 ---
I only have the C99 standard, and there I read in 6.3.1.1 p2 that only
those variables are promoted to int that are of smaller size.
Similarly, in 6.3.1.8, integer promotion rules are specified, and they
specify that ty
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-01-21 04:35 ---
Tom, I tried your patch and now I get the following error. On line 14 in
AnnotationInvocationHandler.h, there is "namespace sun" and "sun" is defined to
1 on solaris. When I recompile with -ansi (which eliminates "su
--- Comment #12 from tromey at gcc dot gnu dot org 2007-01-21 03:23 ---
One odd thing here is that if -Werror is given, then an inaccessible
directory will cause a compilation failure.
I would prefer we not check this patch in. I don't think there is
any "obviously correct" behavior on
--- Comment #12 from levon at movementarian dot org 2007-01-21 03:15
---
It's been a cause of bugs time and time again, so yes, it's useful and
important.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7543
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-21 03:09 ---
I am testing a patch for this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-21 03:08 ---
I have a patch to document '#' and '@'.
I'll submit it shortly.
Currently gcc.c and invoke.texi are mostly kept in sync.
However I haven't audited to make sure they are fully in sync.
Adding support for \f is probab
--- Comment #2 from patchapp at dberlin dot org 2007-01-21 01:55 ---
Subject: Bug number PR30520
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/msg01703.html
--
http://gcc.gnu.org/bugzilla/sh
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29151
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28531
(This bug description assumes that the patch to PR30520 is already applied.)
gfortran currently permits the following redundant VOLATILE attributes:
module A
real :: vol
end module A
module B
use A
volatile :: vol
volatile :: vol ! WRONG, but accepted
end module B
gfortran wrongly rejects
Suppose that we have a function f that can be written in 2 ways with identical
result:
unsigned int f(unsigned int i, unsigned int n) {++i; if (i == n) ++i; return
i;}
unsigned int f(unsigned int i, unsigned int n) {++i; i += i == n; return i;}
g++ -O3 produces different code for the 2 versions:
--- Comment #1 from brooks at gcc dot gnu dot org 2007-01-21 00:23 ---
I would suggest that your comment about "No check_used needed" should reference
11.2.1 of the F2003 standard. The relevant language is towards the end (p252,
lines 30-34 of the page): "The local identifier of an enti
--- Comment #5 from fang at csl dot cornell dot edu 2007-01-20 23:11
---
Subject: Re: failed to build libgfortran in gcc-4.3-20070119
on OSX 10.3.9
> --- Comment #4 from dominiq at lps dot ens dot fr 2007-01-20 22:52
> ---
> Subject: Re: failed to build libgfortran in gcc-
--- Comment #4 from dominiq at lps dot ens dot fr 2007-01-20 22:52 ---
Subject: Re: failed to build libgfortran in gcc-4.3-20070119 on OSX 10.3.9
Thanks for the answers. I am not sure to fully understand them.
Am I correct if I summarize them by saying that I should
add a line
#includ
--
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
From
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/6ec0a526ea59aa94/
gfortran accepts in the three test cases in "1.", which violate C1232 (R1221)
and C1233 (R1221).
Fourth test case (should pass as dummy is pointer array, passes with gfortran)
subroutine s10()
implic
--- Comment #3 from fang at csl dot cornell dot edu 2007-01-20 22:05
---
Subject: Re: failed to build libgfortran in gcc-4.3-20070119
on OSX 10.3.9
> --- Comment #2 from fang at csl dot cornell dot edu 2007-01-20 22:00
> ---
> In (Darwin), near the beginning, you'll see so
--- Comment #2 from fang at csl dot cornell dot edu 2007-01-20 22:00
---
In (Darwin), near the beginning, you'll see some ifndef
business for struct timeval (the type of ru_utime and ru_stime). It looks to
be protected by the _TIMEVAL macro. Somehow that is evaluating the wrong way,
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
Keywords||build
gcc/../libdecnumber -I../../libdecnumber -o crtendS.o -MT crtendS.o -MD -MP -MF
crtendS.dep -fPIC \
-c ../../../gcc/libgcc/../gcc/crtstuff.c -DCRT_END -DCRTSTUFFS_O
# If the gcc directory specifies which extra parts to
# build for this target, and the libgcc configuration also
# specifies
--- Comment #1 from dominiq at lps dot ens dot fr 2007-01-20 20:42 ---
Created an attachment (id=12924)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12924&action=view)
preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30518
After using the patch of PR30511, gcc-4.3-20070119 failed to build
on OSX 10.3.9 with:
...
/sw/src/fink.build/gcc4-4.3.0-20070120/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc4-4.3.0-20070120/darwin_objdir/./gcc/
-B/sw/lib/gcc4/powerpc-apple-darwin7/bin/
-B/sw/lib/gcc4/powerpc-apple-darwin7
gcc version 4.3.0 20070120 (experimental)
This is svn r120997.
The attached file has three differently-coded but equivalent sets of array
accesses, none of which are compiled to the smallest possible form at -Os.
case '<':
--- Comment #14 from pcarlini at suse dot de 2007-01-20 19:13 ---
(In reply to comment #13)
> I am also interested in seeing if there are any (large signed) -> (small
> unsigned) and bring them to the discussion, where all positive values fit in
> the unsigned (so no warning) or there is
--- Comment #11 from manu at gcc dot gnu dot org 2007-01-20 18:06 ---
Any news on this? Is this an important warning?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-20 17:19
---
Looks fun! The following code even gets gfortran into an infinite loop:
integer :: i(2:0), j(1:0)
integer, parameter :: k(2:0) = 0, l(1:0) = 0
i = k
j = l
end
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-20 16:52 ---
Not sure if the summary is 100% correct but it is far better than the previous
one.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-20 16:30 ---
This is a duplicate of PR 23587.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29694
--- Comment #1 from schwab at suse dot de 2007-01-20 16:07 ---
> macro.c: In function ‘main’:
> macro.c:18: warning: format ‘%lu’ expects type ‘long
> unsigned int’, but
> argument 2 has type ‘long long unsigned int’
> macro.c:19: warning: format ‘%lu’ expects type ‘long
> unsigned int
--- Comment #34 from fxcoudert at gcc dot gnu dot org 2007-01-20 15:57
---
Fixed on mainline and 4.2.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-20 15:57
---
Fixed on mainline and 4.2.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #33 from fxcoudert at gcc dot gnu dot org 2007-01-20 15:55
---
Subject: Bug 26893
Author: fxcoudert
Date: Sat Jan 20 15:55:41 2007
New Revision: 121001
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121001
Log:
PR fortran/30446
* options.c (gfc_handl
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-01-20 15:55
---
Subject: Bug 30446
Author: fxcoudert
Date: Sat Jan 20 15:55:41 2007
New Revision: 121001
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121001
Log:
PR fortran/30446
* options.c (gfc_handle
Tried a simple program that left shifts the long long 33 times, the result
displayed is wrong and not what is expected of shifting 1 <<33
Sample code follows,
int main()
{
unsigned long long var=1;
long long m =1;
printf(" %lu ", (var <<33));
printf("\n %lu ", (m <<33));
return 0;
}
U
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-20 13:45 ---
I teached VRP to look for this idiom and during a C only bootstrap on i686 this
triggers 28921 times.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from dominiq at lps dot ens dot fr 2007-01-20 13:27 ---
On Mac OSX 10.3.9, after the same failure I have applied the patch of comment
#1. Now the build fails
with:
/sw/src/fink.build/gcc4-4.3.0-20070120/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc4-4.3.0-20070120
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-20 13:14
---
Aldy, can you comment on this bug? It's still present as of today, and it
prevents mainline from building a fair number of real-life Fortran codes.
--
fxcoudert at gcc dot gnu dot org changed:
What
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
Known to fail||4.2.0 4.1.2
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-20 13:01
---
Subject: Bug 30446
Author: fxcoudert
Date: Sat Jan 20 13:01:08 2007
New Revision: 121000
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121000
Log:
PR fortran/30446
* options.c (gfc_handle
--- Comment #2 from burnus at gcc dot gnu dot org 2007-01-20 12:46 ---
Non-library part of this fix.
This fixes the reported bug, but libgfortran/m4/* should be fixed as well.
m4/iparm.m4 contains:
define(atype_max, atype_name`_HUGE')dnl
define(atype_min, `-'atype_max)dnl
One would nee
--- Comment #1 from manu at gcc dot gnu dot org 2007-01-20 12:43 ---
Note: we emit a duplicated warning because this patch is not committed yet:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00799.html
(Not a single comment yet).
With the patch the output is just:
int g() T h() int
--- Comment #13 from manu at gcc dot gnu dot org 2007-01-20 12:32 ---
I am also interested in seeing if there are any (large signed) -> (small
unsigned) and bring them to the discussion, where all positive values fit in
the unsigned (so no warning) or there is a sign conversion.
About
--- Comment #12 from pcarlini at suse dot de 2007-01-20 11:58 ---
(In reply to comment #11)
> Paolo or Gerald, could you try to collect a list of the warnings produced by
> -Wconversion?
Hi. I will double check ASAP, but definitely most of them are about signed ->
unsigned, exactly lik
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-01-20 11:19 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-01-20 11:12 ---
Subject: Bug 30223
Author: rguenth
Date: Sat Jan 20 11:12:35 2007
New Revision: 120998
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120998
Log:
2007-01-20 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-01-20 10:37 ---
How did you configure the hpux compiler? I was told Linux/x86 works for you.
Can you verify that gthr-aix.h selected gthr-posix.h for compiling libgcc2 and
libstdc++-v3?
--
rguenth at gcc dot gnu dot org changed
gcj -s -O2 --main=HelloWorld HelloWorld.java World.class -o foobar.exe
Works with gcj 4.2 but fails with gcj 4.3:
C:\DOKUME~1\Marco\LOKALE~1\Temp/ccSkeaaa.o:ccoFcaaa.jar:(.text+0x66):
undefined reference to `java::lang::String* World::getWorld()'
collect2: ld returned 1 exit status
also:
gcj -s
--- Comment #4 from mtrudel at gmx dot ch 2007-01-20 10:16 ---
I thought this was already closed?
Well, Mohan fixed it. It is in the 4.2 branch and in the 4.3 mainline
(trunk)...
Thank you Mohan!
--
mtrudel at gmx dot ch changed:
What|Removed |Adde
--- Comment #11 from manu at gcc dot gnu dot org 2007-01-20 10:15 ---
Paolo or Gerald, could you try to collect a list of the warnings produced by
-Wconversion? I am only interested in the warning message, not where it was
instantiated, so please, filter it through "fgrep "warning: ".
Y
--- Comment #4 from mtrudel at gmx dot ch 2007-01-20 10:13 ---
Fixed in 4.3 mainline. The gcj specific serialization was replaced with the
classpath serialization (StackWalker or something). Thanks guys... minGW gets
better and better :-)
--
mtrudel at gmx dot ch changed:
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-20 09:37 ---
Vaguely related is:
trans-intrinsic.c's gfc_conv_intrinsic_minmaxval, which contains currently:
/* Most negative(-HUGE) for maxval, most positive (-HUGE) for minval. */
if (op == GT_EXPR)
tmp = fold_build1
--- Comment #7 from patchapp at dberlin dot org 2007-01-20 09:25 ---
Subject: Bug number PR c++/24745
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/msg01657.html
--
http://gcc.gnu.org/bugzil
integer(1) :: i(1:-1)
i = 5
end
gives:
hh1.f90: In function 'MAIN__':
hh1.f90:1: error: size of variable 'i' is too large
Expected:
No error as i is an array with no elements
--
Summary: zero-sized array wrongly rejected: integer :: i(1:-1)
Product: gcc
Version
64 matches
Mail list logo