--- Comment #3 from jv244 at cam dot ac dot uk 2009-08-20 07:09 ---
the pointers are undefined and thus it is not standard conforming to ask for
their state. This is like asking if an uninitialized integer is 0 or not.
you can use
type S0
real, dimension(:), pointer :: P => NUL
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-20 07:12 ---
(In reply to comment #0)
> type S0
> real, dimension(:), pointer :: P ! NLEV
> end type S0
>
> type (S0) :: x0
> write (*,*) 'x0%P', associated(x0%P)
You have never initialized the pointer x0
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41121
--- Comment #8 from oliver at FreeBSD dot org 2009-08-20 07:31 ---
I fixed this on my AIX system by changing
/opt/pkg/gcc34/include/c++/3.4.6/cstdio.
I uncommented the undef's:
// Get rid of those macros defined in in lieu of real functions.
#undef clearerr
#undef fclose
#undef feof
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-20 07:45 ---
Curiously, this does not happen when using the IMPLICIT NONE statement, instead
of -fimplicit-none:
IMPLICIT NONE
INTRINSIC MIN
INTEGER :: I,J
print *,MIN(I,J)
END
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #3 from janus at gcc dot gnu dot org 2009-08-20 08:04 ---
Here's the fix:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 150933)
+++ gcc/fortran/resolve.c (working copy)
@@ -102
--- Comment #4 from jv244 at cam dot ac dot uk 2009-08-20 08:25 ---
(In reply to comment #3)
> Here's the fix:
does it fully fix the original, i.e. a1 and a2 shouldn't be warned for either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41121
--- Comment #18 from lessen42+gcc at gmail dot com 2009-08-20 08:49 ---
This still doesn't work on ARM either (tested with 4.4.0). The EABI only
mandates the stack be 8 byte aligned, and gcc silently clips any alignment
request above 8 bytes to 8 (so even if the stack were 16-byte aligne
--- Comment #10 from t7 at gmail dot com 2009-08-20 08:53 ---
Hi, I try to build a gcc-4.4.1 cross compiler target x86_64-w64-mingw32 from
slackware linux 12.2 (i486-slackware-linux) and is getting the same error as
this report.
Checking multilib configuration for libstdc++-v3...
Co
--- Comment #5 from janus at gcc dot gnu dot org 2009-08-20 08:59 ---
(In reply to comment #4)
> does it fully fix the original, i.e. a1 and a2 shouldn't be warned for either.
It does.
Btw these 'a1' and 'a2' don't appear anywhere in dgbmv.f. I think they are the
formal arguements of M
--- Comment #6 from janus at gcc dot gnu dot org 2009-08-20 09:33 ---
Subject: Bug 41121
Author: janus
Date: Thu Aug 20 09:33:01 2009
New Revision: 150957
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150957
Log:
2009-08-20 Janus Weil
PR fortran/41121
* reso
--- Comment #7 from janus at gcc dot gnu dot org 2009-08-20 09:36 ---
Fixed with r150957. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from anitha dot boyapati at atmel dot com 2009-08-20 09:46
---
Created an attachment (id=18403)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18403&action=view)
Images display the contents of rx_tel_in_ptr before and after the assignment
This issue does not arise w
--- Comment #4 from janus at gcc dot gnu dot org 2009-08-20 11:54 ---
(In reply to comment #1)
> guessing:
>
> 2009-08-17 Janus Weil
>
> PR fortran/40877
This was r150823, which seems to be working for me.
However, I don't see why r150825 fails for Dominique then (r150824
--- Comment #1 from ludovic at ludovic-brenta dot org 2009-08-20 12:02
---
At first glance: the makefile seems not to be calling awk at all; the first
word is BEGIN; obviously the command BEGIN is not found.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41122
--- Comment #3 from abnikant dot singh at atmel dot com 2009-08-20 12:03
---
No error observed in gcc-4.4.0,libgcc.S compiles fine for -mmcu=avr31 with the
same command line as reported in the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35936
--- Comment #2 from ludovic at ludovic-brenta dot org 2009-08-20 12:04
---
Actually, the whole awk program, which is presumably between single quotes in
the makefile, is the command which is not found. The command should be awk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41122
--- Comment #5 from jv244 at cam dot ac dot uk 2009-08-20 12:07 ---
I went checking my logs in more detail. I believe revision 150854 is fine (so
sorry, my previous guess was wrong), while 150940 fails for me. That would
leave three more revs from the FE:
r150856 | domob | 2009-08-17 20
--- Comment #6 from dominiq at lps dot ens dot fr 2009-08-20 12:15 ---
> However, I don't see why r150825 fails for Dominique then (r150824/25 are both
> Ada-related).
The revision numbers are those recorded when I did the update, they are only an
upper bound for the relevant changes (a
--- Comment #7 from janus at gcc dot gnu dot org 2009-08-20 12:23 ---
(In reply to comment #5)
> but I don't dare to guess this time :-)
Awww, come on, don't be shy ;)
Seriously, though, I'd bet that r150875 is not the culprit. Not because it's
mine, but because it is completely unrela
A somewhat detailed explanation of the needs and possible solution is available
at http://gcc.gnu.org/wiki/DebugGNUIndexSection .
It was posted for discussion to
http://sourceware.org/ml/archer/2009-q3/msg00105.html .
--
Summary: GCC should emit an index of publicly named entities
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reco
--- Comment #8 from janus at gcc dot gnu dot org 2009-08-20 12:53 ---
(In reply to comment #5)
> r150856 | domob | 2009-08-17 20:55:30 +0200 (Mon, 17 Aug 2009) | 14 lines
> r150858 | pault | 2009-08-17 22:17:12 +0200 (Mon, 17 Aug 2009) | 13 lines
> r150875 | janus | 2009-08-18 16:23:35 +
--- Comment #3 from joel at gcc dot gnu dot org 2009-08-20 13:00 ---
Does AWK need to be set in libada/Makefile.in? Since this works for C/C++, it
must be OK in other places.
In gcc/config/m68k/t-mlibs...
M68K_AWK = $(strip $(shell $(AWK) 'BEGIN { FS="[ \t]*[,()][ \t]*"; ORS=" " }; \
--- Comment #9 from janus at gcc dot gnu dot org 2009-08-20 13:11 ---
> Maybe r150934?
Indeed: I just verified that r150934 is the source of this regression.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
---
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org |
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41053
--- Comment #10 from matz at gcc dot gnu dot org 2009-08-20 13:48 ---
Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at g
--- Comment #4 from joel at gcc dot gnu dot org 2009-08-20 13:57 ---
Will you be applying it to 4.4 and the head?
And a thank you. If we ever manage to meet in person, I owe you a beer, wine
or a nice dessert. Your choice. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41122
--- Comment #1 from dodji at gcc dot gnu dot org 2009-08-20 14:42 ---
Created an attachment (id=18404)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18404&action=view)
First shot implementation
Implements the .debug_gnu_index section. It fully implements the proposal,
modulo the p
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41062
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
According to the iso 14882:1998 5.2.5 Class member access, the following code:
class X {
public:
enum enumX { a=100 };
};
int main(void)
{
X x;
(void) &x.a;// should not compile
return 1;
}
should not compile, but with the following version of g++:
g++ -v
Usin
--- Comment #11 from matz at gcc dot gnu dot org 2009-08-20 15:35 ---
Fixed in r150964.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASS
--- Comment #3 from gkandhakumar at gmail dot com 2009-08-20 15:40 ---
Created an attachment (id=18405)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18405&action=view)
it is a routine where i got the error
Thanks for considered my problem and sorry for late reply. while running
--- Comment #4 from dominiq at lps dot ens dot fr 2009-08-20 16:26 ---
You nee to provide all the *.h, *.incnc, and *.inc needed files also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41053
I cannot compile gdcm using gcc 4.1.0 (at least the one shipped in etch:
pentium-builder).
Step to reproduce (on debian testing system):
1. sudo apt-get install pentium-builder
2. Get GDCM source (SVN)
3. Compile line is:
/usr/bin/c++ -DgdcmDSED_EXPORTS -g -O0 -fprofile-arcs -ftest-coverage
-Wn
--- Comment #1 from mathieu dot malaterre at gmail dot com 2009-08-20
17:15 ---
Created an attachment (id=18406)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18406&action=view)
-save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41132
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-08-20 17:16 ---
I have a patch.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #2 from paolo dot carlini at oracle dot com 2009-08-20 17:32
---
This is a prerelease GCC delivered by Debian, as such problems should be
reported to Debian, in the first place. Moreover, FSF 4.1.x is not maintained
anymore.
--
paolo dot carlini at oracle dot com changed
--- Comment #1 from jakub at gcc dot gnu dot org 2009-08-20 19:07 ---
This got broken by
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02640.html
(the lvalue_p_1 change to handle CONST_DECL). Unfortunately the patch didn't
have any comments why has that been necessary.
--
jakub at gc
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-08-20 19:09 ---
(In reply to comment #1)
> This got broken by
> http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02640.html
> (the lvalue_p_1 change to handle CONST_DECL). Unfortunately the patch didn't
> have any comments why has that
--- Comment #3 from jakub at gcc dot gnu dot org 2009-08-20 19:26 ---
Created an attachment (id=18407)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18407&action=view)
gcc45-pr41131.patch
I guess objc_build_string_object is the reason, except for that function
CONST_DECLs are only
The documentation of the constraint A says:
"The a and d registers, as a pair (for instructions that return half the result
in one and half in the other)."
So I expect:
asm("/* dx = 0, ax = 1 */" :: "A" ((int32_t)1) );
asm("/* edx = 0, eax = 1 */" :: "A" ((int64_t)1) );
//asm("/* rdx = 0, rax =
--- Comment #7 from tkoenig at gcc dot gnu dot org 2009-08-20 20:16 ---
Subject: Bug 40962
Author: tkoenig
Date: Thu Aug 20 20:16:15 2009
New Revision: 150974
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150974
Log:
2009-08-20 Thomas Koenig
PR libfortran/40962
--- Comment #1 from bangerth at gmail dot com 2009-08-20 20:40 ---
Jason, might this be a result of your changes to used/unused variables?
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #1 from bangerth at gmail dot com 2009-08-20 20:41 ---
Jason, might this be a result of your changes to used/unused variables?
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #8 from tkoenig at gcc dot gnu dot org 2009-08-20 20:42 ---
Subject: Bug 40962
Author: tkoenig
Date: Thu Aug 20 20:42:38 2009
New Revision: 150975
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150975
Log:
2009-08-20 Thomas Koenig
PR libfortran/40962
Here's yet another case of a variable that is flagged as unused when it is
actually referenced. I agree that this is a corner case: the variable
really *is* unused, the template function is not instantiated after all.
That said, this is not an uncommon idiom, the code is extracted from the
Threadi
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-08-20 20:44 ---
Well this is invalid code that is accepted by GCC anyways
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41134
--- Comment #2 from bangerth at gmail dot com 2009-08-20 20:47 ---
(In reply to comment #1)
> Well this is invalid code that is accepted by GCC anyways
How so??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41134
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-08-20 20:49 ---
You cannot use a static variable in a template :).
Note the following is valid though:
namespace { int i; }
template int f() { return i; }
And still invokes the warning:
t4.cc:1:17: warning: '::i' defined but not u
--- Comment #4 from bangerth at gmail dot com 2009-08-20 20:54 ---
(In reply to comment #3)
> You cannot use a static variable in a template :).
I would be unaware of that restriction. It's true that you can't use objects
with internal linkage (such as static variables) as *template arg
--- Comment #9 from tkoenig at gcc dot gnu dot org 2009-08-20 20:56 ---
Fixed on trunk and 4.4, closing.
If anybody wants to backport the fix to 4.3, be my guest :-)
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-08-20 21:11 ---
Why is this a regression? Which compiler version didn't warn here?
The question is really whether we want unused variables just in the case
where we can remove it and without further changes the program is still
va
--- Comment #6 from bangerth at gmail dot com 2009-08-20 21:20 ---
(In reply to comment #5)
> Why is this a regression? Which compiler version didn't warn here?
4.3.2. Current mainline warns.
> The question is really whether we want unused variables just in the case
> where we can re
--- Comment #4 from jason at gcc dot gnu dot org 2009-08-20 22:03 ---
Pinski: You made TREE_STATIC CONST_DECLs? Why?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41131
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-08-20 22:04 ---
(In reply to comment #4)
> Pinski: You made TREE_STATIC CONST_DECLs? Why?
The Fortran front-end did that before I did it ... (RTH did that).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41131
--- Comment #9 from eric dot weddington at atmel dot com 2009-08-20 22:13
---
According to comment #8, the problem no longer exists in gcc 4.3.2. Closing bug
as WONTFIX.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #1 from rth at gcc dot gnu dot org 2009-08-20 22:28 ---
This is expected. The "A" constraint supposed to be used for a PAIR.
This means 64-bit values in 32-bit code or 128-bit values in 64-bit code.
--
rth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from eric dot weddington at atmel dot com 2009-08-20 22:33
---
Seems to be fixed now. Closing as WONTFIX.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
-
--- Comment #2 from eric dot weddington at atmel dot com 2009-08-20 22:40
---
Hi Torleif,
Please check more recent versions such as 4.3.2, 4.3.3, or 4.4.0. There are
.debug_frame sections in there, but I don't know if it contains the information
that you're looking for.
Thanks,
Eric W
Compiling the attached testcase should produce a warning, as it does with g++
4.3.2 (at least with -O or above),
$ g++-4.3 -Wall -Wextra -pedantic -ansi -O3 hi.cpp
/usr/include/bits/stdio2.h: In function int main():
/usr/include/bits/stdio2.h:105: warning: hi.array::a[1] is used
uninitialized
--- Comment #1 from bgamari at gmail dot com 2009-08-20 23:26 ---
Created an attachment (id=18408)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18408&action=view)
Warning test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41135
x86_64-w64-mingw32-gcc -fomit-frame-pointer -D__USE_MINGW_ACCESS -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CO
--- Comment #10 from davek at gcc dot gnu dot org 2009-08-21 02:20 ---
*** Bug 30570 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38892
--- Comment #9 from davek at gcc dot gnu dot org 2009-08-21 02:20 ---
*** This bug has been marked as a duplicate of 38892 ***
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from davek at gcc dot gnu dot org 2009-08-21 02:23 ---
This has been fixed now since these two revisions were applied:
http://gcc.gnu.org/viewcvs?view=revision&revision=146627
http://gcc.gnu.org/viewcvs?view=revision&revision=146869
These days libjava builds fin
--- Comment #1 from davek at gcc dot gnu dot org 2009-08-21 02:26 ---
Was fixed in
http://gcc.gnu.org/viewcvs?view=revision&revision=147641
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from jv244 at cam dot ac dot uk 2009-08-21 06:09 ---
(In reply to comment #2)
> which returns "false". It gets quite complicated if we want to handle:
>foo(1)%bar(1:1)%variable(:)(sub:string)
AFAICT this is already handled fine:
write(6,*) foo(1)%bar(1:1)%variable(:)(
triggered by some discussion in PR41113
SUBROUTINE S(a,n)
INTEGER :: n
REAL :: a(n,n,n,n)
a(:,:,:,:)=0.0
END SUBROUTINE
generates a four-fold look to do the zeroing, while it would be more efficient
to zero n**4 elements starting from a(1,1,1,1). I.e. since a is contiguous in
memory a memset or s
--- Comment #4 from jv244 at cam dot ac dot uk 2009-08-21 06:15 ---
(In reply to comment #3)
> I have another example, I will file it as a different PR, but make a
> 'cross-link'
PR 41137
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41113
73 matches
Mail list logo