On 17.08.2009 12:00, Mikael Pettersson wrote:
On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klosed...@debian.org wrote:
On 12.08.2009 23:07, Martin Guy wrote:
On 8/12/09, Joel Sherrilljoel.sherr...@oarcorp.com wrote:
So any ACATS results from any other ARM target would be
appreciated.
On Thu, Aug 20, 2009 at 2:33 AM, Jeff Lawl...@redhat.com wrote:
On 08/19/09 17:46, Ian Lance Taylor wrote:
My understanding is that that scenario is supposed to not happen because
update_equiv_regs is only supposed to equate a register and a memory
location in the specific cases where that is
On Thu, Aug 20, 2009 at 3:19 AM, Albert Cohenalbert.co...@inria.fr wrote:
Richard Guenther wrote:
gfortran.dg/reassoc_4.f, the hottest loop from calculix.
Thanks.
This example is slightly different. Graphite should be able to handle it
with loop fusion rather than pre-unrolling + cse. But
Ian Lance Taylor writes:
Mikael Pettersson mi...@it.uu.se writes:
When browsing e.g. gcc-cvs via the web it used to be possible to click on a
newly added file and get a 'download raw' (I think it was called) option to
see the file without all that idiotic html formatting. That seems
IIRC another code that is improved by complete_unrolli is the polyhedron
test induct.f90. However it gives worse results for some variants
(see pr34265: induct_v2/3).
Can't we use graphite to re-roll loops? ...
Is doing and undoing always some kind of work?
Cheers
Dominique
On Thu, Aug 20, 2009 at 11:48 AM, Dominique Dhumieresdomi...@lps.ens.fr wrote:
IIRC another code that is improved by complete_unrolli is the polyhedron
test induct.f90. However it gives worse results for some variants
(see pr34265: induct_v2/3).
Can't we use graphite to re-roll loops? ...
Jerry Quinn wrote:
On Tue, 2009-08-18 at 08:43 -0700, Richard Henderson wrote:
On 08/17/2009 07:40 PM, Jerry Quinn wrote:
On Mon, 2009-08-17 at 16:16 -0400, Jason Merrill wrote:
I'm not sure why GCC sources would need to mangle function-local
structs, though.
Would it be helpful to reserve a
That depends a bit on the compiler version and optimization level,
but (in particular in the 3.x time frame) GCC may output assembler
code on a function-by-function basis, without necessarily reading
in the whole source file first.
Ok, actually it doesn't matter if it doesn't work all the
Matthias Klose wrote:
On 17.08.2009 12:00, Mikael Pettersson wrote:
On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klosed...@debian.org wrote:
On 12.08.2009 23:07, Martin Guy wrote:
On 8/12/09, Joel Sherrilljoel.sherr...@oarcorp.com wrote:
So any ACATS results
Richard Guenther wrote:
If this is not clear, I can write some pseudo-code to clarify :-).
Can't we use graphite to re-roll loops? That is, compress the
polyhedron by introducing a new parameter? But maybe I am
not good at guessing what your initial bloat issue looks like.
The reason
Jerry Quinn wrote:
On Thu, 2009-08-20 at 11:12 +0100, Dave Korn wrote:
Jerry Quinn wrote:
Apparently my change is too naive, because the assembler doesn't like a
name with '*' in it. Are there any chars that can pass muster with
assemblers but not be a valid namespace identifier?
Don't
On Thu, 2009-08-20 at 11:12 +0100, Dave Korn wrote:
Jerry Quinn wrote:
On Tue, 2009-08-18 at 08:43 -0700, Richard Henderson wrote:
On 08/17/2009 07:40 PM, Jerry Quinn wrote:
On Mon, 2009-08-17 at 16:16 -0400, Jason Merrill wrote:
I'm not sure why GCC sources would need to mangle
On 08/19/09 18:48, Ian Lance Taylor wrote:
Jeff Lawl...@redhat.com writes:
You're right. This should have been rejected by validate_equiv_mem,
but isn't because the two memory references are in different alias
sets.
You can see this in the mainline sources configured for
On Thu, 2009-08-20 at 14:05 +0100, Dave Korn wrote:
Jerry Quinn wrote:
On Thu, 2009-08-20 at 11:12 +0100, Dave Korn wrote:
Jerry Quinn wrote:
Apparently my change is too naive, because the assembler doesn't like a
name with '*' in it. Are there any chars that can pass muster with
On 08/20/09 02:45, Richard Guenther wrote:
It looks indeed bogus. Do you have a testcase at hand?
Compile the attached testcase with -O3 -mopenmp on i686-pc-linux-gnu.
Find MAIN__.omp_fn.2 in the .expand dump.
Within that function, you're looking for this sequence of insns:
;;
On Thu, Aug 20, 2009 at 3:37 PM, Jeff Lawl...@redhat.com wrote:
On 08/20/09 02:45, Richard Guenther wrote:
It looks indeed bogus. Do you have a testcase at hand?
Compile the attached testcase with -O3 -mopenmp on i686-pc-linux-gnu. Find
MAIN__.omp_fn.2 in the .expand dump.
Within that
Jerry Quinn wrote:
OK, I'm now confused. How does this dovetail with anonymous
namespaces?
We're talking about typeinfo strings. The namespace is part of the typeinfo
name string (the so-called NTBS name), and it's the random number in the
anonymous namespace name used for these local
Dave Korn wrote:
What I think you need to do is use an identifier for the
anonymous namespace without an asterisk, but prefix the asterisk when
generating the corresponding NTBS name string; then your changes to the name
comparison routines in libsupc++ should work, but the typeinfo name
Status
==
The 4.4 branch is open for commits under the usual release branch
rules. The timing of the 4.4.2 release (at least two months after the
4.4.1 release, at a point when there are no P1 regressions open for
the branch) has yet to be determined.
Quality Data
Priority
Paul Edwards wrote:
Hmm, it seems 3.2.x would *always* operate on a function-by-function
basis. The unit-at-a-time mode was only introduced with 3.4 (I don't
recall if it was already present in 3.3). I don't think there is any
way in 3.2.3 to check whether there is a main function in
-Original Message-
From: Lawrence Crowl [mailto:cr...@google.com]
The problem is that gcc does support 80386. It also supports
other processors that have less-than-complete support for
concurrency. Just in the x86 line, we get some additional
capability in many new layers.
Hmm, it seems 3.2.x would *always* operate on a function-by-function
basis. The unit-at-a-time mode was only introduced with 3.4 (I don't
recall if it was already present in 3.3). I don't think there is any
way in 3.2.3 to check whether there is a main function in the file
before it is
Snapshot gcc-4.5-20090820 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090820/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Hello,
After searching this list it appears that with recent gcc (I am using gcc
4.1), C++ exception handling has zero overhead (unless an exception actually
happens)
Where can I find more information on how exception handling is done and if
this zero overhead property is always true.
I
SD wrote:
Hello,
After searching this list it appears that with recent gcc (I am using gcc
4.1), C++ exception handling has zero overhead (unless an exception actually
happens)
Where can I find more information on how exception handling is done and if
this zero overhead property is
Dave Korn dave.korn.cyg...@googlemail.com writes:
The
DW2 version has zero overhead in terms of execution time when no exceptions
are thrown, but adds a noticeable amount of memory usage for the eh tables.
For the extremely picky (and who among us is not extremely picky) there
is still some
--- 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 =
--- 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%P.
--
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:
snip
// Get rid of those macros defined in stdio.h in lieu of real functions.
#undef clearerr
#undef fclose
--- 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
--
--- 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)
@@
--- 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
--- 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...
--- 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
--- 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=gccview=revrev=150957
Log:
2009-08-20 Janus Weil ja...@gcc.gnu.org
PR
--- 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=18403action=view)
Images display the contents of rx_tel_in_ptr before and after the assignment
This issue does not arise
--- 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 ja...@gcc.gnu.org
PR fortran/40877
This was r150823, which seems to be working for me.
However, I don't see why r150825 fails for Dominique
--- 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.
--
--- 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
--- 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
--- 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
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
--- 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
--- 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=18404action=view)
First shot implementation
Implements the .debug_gnu_index section. It fully implements the proposal,
modulo the
--
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
--- 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
--- 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=18405action=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
--- 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=18406action=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
--- 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
--- 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
--- 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=18407action=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 = 1 */ :: A
--- 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=gccview=revrev=150974
Log:
2009-08-20 Thomas Koenig tkoe...@gcc.gnu.org
PR
--- 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=gccview=revrev=150975
Log:
2009-08-20 Thomas Koenig tkoe...@gcc.gnu.org
PR
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
--- 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 typename int f() { return i; }
And still invokes the warning:
t4.cc:1:17: warning: 'unnamed::i'
--- 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
--- 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
--- 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
--- 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
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.arraydouble, 4::a[1] is used
--- 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=18408action=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
--- 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=revisionrevision=146627
http://gcc.gnu.org/viewcvs?view=revisionrevision=146869
These days libjava builds fine
--- Comment #1 from davek at gcc dot gnu dot org 2009-08-21 02:26 ---
Was fixed in
http://gcc.gnu.org/viewcvs?view=revisionrevision=147641
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
96 matches
Mail list logo
