--- 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
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 #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(:)(
--- 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 #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 #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 #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
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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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
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 #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
--- 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 #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 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 #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 #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
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 #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
--- 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 #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
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
--
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
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41062
--- 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
--- 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 #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
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41053
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org |
--- 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
---
--- 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 #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 +
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reco
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
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
--- 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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
--
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 #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
--- 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
73 matches
Mail list logo
