--- Comment #7 from burnus at gcc dot gnu dot org 2008-08-26 06:11 ---
Some initial patch: http://gcc.gnu.org/ml/fortran/2008-08/msg00238.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32049
--- Comment #26 from gdr at integrable-solutions dot net 2008-08-26 05:45
---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
On Sat, Aug 23, 2008 at 1:43 PM, paolo dot carlini at oracle dot com
<[EMAIL PROTECTED]> wrote:
> --- Comment #23 from paolo dot carlin
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-08-26 02:10
---
I read that response to the draft comment. I will take this one.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #54 from hp at gcc dot gnu dot org 2008-08-26 02:00 ---
Created an attachment (id=16146)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16146&action=view)
Patch, take 5.
Removing the "TREE_CODE (decl) == FUNCTION_DECL && ..." part helped to elide
the bogus weak declarat
--- Comment #8 from kargl at gcc dot gnu dot org 2008-08-25 22:32 ---
(In reply to comment #7)
> Whether it is the current standard or
> not, it was legal years ago, and tons of legacy code (like this one) have it.
It has never been legal. Yes, legacy codes abuse the dummy argument
s
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-25 22:10 ---
*** This bug has been marked as a duplicate of 37090 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-08-25 22:10 ---
*** Bug 37238 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
This code:
void byte_copy(void* out, size_t len, const void* in) {
char* s=out;
const char* t=in;
const char* u=t+len;
for (;;) {
if (t==u) break; *s=*t; ++s; ++t;
if (t==u) break; *s=*t; ++s; ++t;
if (t==u) break; *s=*t; ++s; ++t;
if (t==u) break; *s=*t; ++s; ++t;
}
}
g
--- Comment #11 from manu at gcc dot gnu dot org 2008-08-25 21:53 ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > However, the testcase is too big for the testsuite...
> > The C++ testcase I attached is small. See comment #4.
>
> I don't get
--- Comment #7 from ronis at ronispc dot chem dot mcgill dot ca 2008-08-25
21:45 ---
As per the suggestions, I replaced the all instances of array declarations like
X(1) to X(*) and the problem goes away. Whether it is the current standard or
not, it was legal years ago, and tons of le
--- Comment #53 from hp at gcc dot gnu dot org 2008-08-25 21:36 ---
(In reply to comment #52)
> While we are at the "weak" arcanes on Darwin, we have also the following since
> at least revision 136913 (revision 136903 seems the most likely candidate, the
> others being 136899, 136905, a
--- Comment #6 from dominiq at lps dot ens dot fr 2008-08-25 20:49 ---
> It's not a work around. It is the *Fix*.
It is not my coding style (I always pass the bounds of the arrays, unless they
have known bounds), but I have seen it a zillion time in f77 codes, so I think
it should work
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-25 20:41 ---
I think this is a great idea. A good error with a long explanation will save a
lot of time for a lot of people. I don't think you even need the configure
option to allow it. I cannot see why anyone would need to build i
--- Comment #5 from kargl at gcc dot gnu dot org 2008-08-25 20:40 ---
(In reply to comment #2)
> Work around: replace X(1) by X(*).
It's not a work around. It is the *Fix*.
The code as written is invalid.
--
kargl at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from burnus at gcc dot gnu dot org 2008-08-25 20:39 ---
Note: Using
COMPLEX*16 X(1)
defines a rank-one array with a single argument. Accessing then
X(2)
is invalid according to the Fortran standard - there is no such element. (I
know that several old Fortran programs u
--- Comment #3 from kargl at gcc dot gnu dot org 2008-08-25 20:37 ---
(In reply to comment #0)
> I've got some old fortran code that has compiled with dozens of gcc versions.
> I tried recompiling with 4.3.1 and I get an internal compiler error if I try
> to
> compile with my usual com
--- Comment #52 from dominiq at lps dot ens dot fr 2008-08-25 20:23 ---
While we are at the "weak" arcanes on Darwin, we have also the following since
at least revision 136913 (revision 136903 seems the most likely candidate, the
others being 136899, 136905, and 136912):
FAIL: g++.dg/ab
--- Comment #6 from janis at gcc dot gnu dot org 2008-08-25 20:19 ---
Subject: Bug 36756
Author: janis
Date: Mon Aug 25 20:18:08 2008
New Revision: 139572
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139572
Log:
PR target/36756
* config/rs6000/rs6000.c (optimiz
--- Comment #2 from dominiq at lps dot ens dot fr 2008-08-25 20:04 ---
Confirmed on i686-apple-darwin9. Works with 4.2.3, latest trunk (revision
139571) gives:
pr37236.f: In function 'fftrc':
pr37236.f:2: error: expected an SSA_NAME object
pr37236.f:2: error: in statement
# NMT.31 = VDE
--- Comment #1 from burnus at gcc dot gnu dot org 2008-08-25 19:57 ---
Using 4.4 I get the following:
aa.f: In function 'fftrc':
aa.f:2: error: expected an SSA_NAME object
aa.f:2: error: in statement
# NMT.31 = VDEF { NMT.31 }
IMAGPART_EXPR <(*x_29(D))[1]> = 0.0;
aa.f:2: internal compi
Compile a C++ file containing a class with a virtual destructor. Example from
gdb's class2.cc test:
struct A
{
virtual ~A ();
int a1;
};
A::~A()
{
a1 = 800;
}
>From the DWARF:
<2><270>: Abbrev Number: 10 (DW_TAG_subprogram)
<271> DW_AT_external: 1
<272> DW_AT_name
I've got some old fortran code that has compiled with dozens of gcc versions.
I tried recompiling with 4.3.1 and I get an internal compiler error if I try to
compile with my usual compiler flags for this project.
Building with -O1 works. I've also played around with removing various
combinations
--- Comment #51 from hp at gcc dot gnu dot org 2008-08-25 19:16 ---
(In reply to comment #50)
> I think the C++ failures are related to PR 37167.
Depends on how you define "related". Maybe the patch for this bug will include
the fix for it (see proposed varasm.c:assemble_external chang
--- Comment #10 from manu at gcc dot gnu dot org 2008-08-25 19:07 ---
(In reply to comment #9)
> (In reply to comment #8)
> > However, the testcase is too big for the testsuite...
> The C++ testcase I attached is small. See comment #4.
I don't get the ICE with that testcase in x86_64-u
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-08-25 18:59 ---
(In reply to comment #8)
> However, the testcase is too big for the testsuite...
The C++ testcase I attached is small. See comment #4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37217
--- Comment #50 from pinskia at gcc dot gnu dot org 2008-08-25 18:58
---
I think the C++ failures are related to PR 37167.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #2 from manu at gcc dot gnu dot org 2008-08-25 18:55 ---
I think this was fixed already in GCC 4.3.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #49 from hp at gcc dot gnu dot org 2008-08-25 18:35 ---
(In reply to comment #48)
> I get:
(many "X.s:unknown:Undefined symbol: Y can't be a weak_definition" elided)
Yes, those look sufficiently similar. (No C or C++ knowledge required. :)
Good to know that it's probably jus
--- Comment #48 from dominiq at lps dot ens dot fr 2008-08-25 18:17 ---
I get:
[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/abi/empty7.C
/var/tmp//ccCa6HmC.s:unknown:Undefined symbol: __ZTV2S3 can't be a
weak_definition
/var/tmp//ccCa6HmC.s:unknown:Undefined symb
--- Comment #47 from dominiq at lps dot ens dot fr 2008-08-25 18:12 ---
> To help shorten the number of iterations, can you please verify that the
> failures all look as above in the .log files?
You have to realize that I am C* illiterate. So I need more precise directives.
For instance
--- Comment #46 from hp at gcc dot gnu dot org 2008-08-25 17:58 ---
(In reply to comment #39)
> More good news, the weak gcc tests pass now for 32 and 64 bit modes.
>
> Also bad news, I have extra failures in the g++ tests (32-bit mode so far),
> /var/tmp//ccLGtbMk.s:unknown:Undefined
--- Comment #45 from dominiq at lps dot ens dot fr 2008-08-25 17:25 ---
> I have 2 less fails now on c++
On Darwin there is one test which now passes:
g++.dg/ext/weak2.C scan-assembler weak[^ \\t]*[ \\t]_?_Z3foov
but several new failures (comment #40).
--
http://gcc.gnu.org/bugzi
--- Comment #44 from eric dot weddington at atmel dot com 2008-08-25 17:20
---
(In reply to comment #43)
> > Patch #4 still fixes all "weak" test regressions on avr.
>
> Did you test g++?
>
Yes. I build and test for c, c++, ada, and objc (yes, it actually builds for
AVR). I have 2 le
--- Comment #1 from eric dot weddington at atmel dot com 2008-08-25 17:12
---
Seems to be fixed in latest HEAD.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--
--- Comment #1 from eric dot weddington at atmel dot com 2008-08-25 17:11
---
Seems to be fixed in latest HEAD.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--
--- Comment #1 from eric dot weddington at atmel dot com 2008-08-25 17:11
---
Seems to be fixed now in latest HEAD.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--
--- Comment #43 from dominiq at lps dot ens dot fr 2008-08-25 17:10 ---
> Patch #4 still fixes all "weak" test regressions on avr.
Did you test g++?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #42 from eric dot weddington at atmel dot com 2008-08-25 16:51
---
(In reply to comment #41)
> (In reply to comment #37)
> > Created an attachment (id=16141)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16141&action=view) [edit]
> > Patch, take 4.
>
> > Please, test
--- Comment #4 from hjl dot tools at gmail dot com 2008-08-25 16:33 ---
Fixed by revision 139532.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2008-08-25 16:32 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #41 from eric dot weddington at atmel dot com 2008-08-25 15:12
---
(In reply to comment #37)
> Created an attachment (id=16141)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16141&action=view) [edit]
> Patch, take 4.
> Please, test on darwin and avr.
Testing started
--- Comment #4 from tehila at il dot ibm dot com 2008-08-25 14:52 ---
(In reply to comment #2)
> Hopefully, if that loop would be unrolled, the SRA will have the opportunity
> to do the transformation we expect it to do.
I've tried it manually, and that indeed works.
i.e., if we'll be
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37235
--- Comment #5 from paolo dot carlini at oracle dot com 2008-08-25 13:55
---
*** Bug 37235 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2008-08-25 13:55
---
*** This bug has been marked as a duplicate of 36832 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
The method rope::copy(size_type __pos, size_type __n, _CharT* __buffer) const
is not working in libstdc++ 4.3.0
I include a simple example q.cc that shows the problem:
#include
int main() {
__gnu_cxx::rope r(128, ' ');
r.append("1234",4);
char buf[5];
r.copy(128,
--- Comment #40 from dominiq at lps dot ens dot fr 2008-08-25 13:35 ---
Here is the list of new g++ failures (32 and 64 bit modes, except
g++.dg/abi/empty7.C):
FAIL: g++.dg/abi/empty7.C (test for excess errors)<--- 32-bit mode only
FAIL: g++.dg/abi/layout2.C (test for excess err
--- Comment #3 from mkl at pengutronix dot de 2008-08-25 13:32 ---
works with 4.4-20080822, though
cheers Marc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37220
--- Comment #2 from mkl at pengutronix dot de 2008-08-25 13:26 ---
Fails too with the gcc-4.3.2-RC
[EMAIL PROTECTED]:~/pengutronix/toolchain/procps]$
/opt/OSELAS.Toolchain-trunk/arm-v4t-linux-gnueabi/gcc-4.3.2-RC-20080819-glibc-2.8-kernel-2.6.26-sanitized/bin/
arm-v4t-linux-gnueabi-gcc
--- Comment #8 from manu at gcc dot gnu dot org 2008-08-25 12:36 ---
The fix is trivial:
Index: gcc/c-common.c
===
--- gcc/c-common.c (revision 139373)
+++ gcc/c-common.c (working copy)
@@ -1566,11 +1566,11 @@ con
--- Comment #8 from eric dot weddington at atmel dot com 2008-08-25 12:26
---
> Eric,
> what platfrom are you running on ?
It's right there in the "Host" field: i686-pc-linux-gnu
Target is avr.
But I commonly build a toolchain distribution on mingw. Right now I'm using the
Linux host
This is about this problem report:
http://gcc.gnu.org/ml/gcc/2008-08/msg00394.html
--
Summary: [c++0x] =default definition outside template class fails
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P
--- Comment #3 from pluto at agmk dot net 2008-08-25 11:49 ---
works fine in 4.4.0 20080824.
--
pluto at agmk dot net changed:
What|Removed |Added
Status|UNCO
--- Comment #39 from dominiq at lps dot ens dot fr 2008-08-25 11:44 ---
More good news, the weak gcc tests pass now for 32 and 64 bit modes.
Also bad news, I have extra failures in the g++ tests (32-bit mode so far),
e.g.:
[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g
--- Comment #7 from burnus at gcc dot gnu dot org 2008-08-25 11:37 ---
Created an attachment (id=16144)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16144&action=view)
test2.i.gz
> I cannot reproduce this with any of the testcases in x86_64-unknow-linux-gnu
> and that is all I ha
--- Comment #2 from paolo dot carlini at oracle dot com 2008-08-25 11:35
---
The compiler is right, and, FWIW, EDG-based compilers also agree.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
I have noticed that optimization is lost when a 32-bit multiply with 64-bit
product is inlined. This also happens in 3.4 (Cygwin gcc).
The function:
uint64_t mul2(uint32_t a, uint32_t b) {
return a * (uint64_t)b;
}
is encoded 'properly' as a single mul instruction:
gcc -O3 -fomit-frame-pointer
--- Comment #1 from roman dot desyatov at gmail dot com 2008-08-25 11:23
---
Created an attachment (id=16143)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16143&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37232
When compiling code below, complier says it can't find suitable function:
-
void F( int* ){}
void F( float* ){}
template
void G( T * v)
{
F(v);
}
void F( double* ){}
int main(int, char**)
{
double a = 3.14;
G(&a);
return 0;
}
---
--- Comment #6 from manu at gcc dot gnu dot org 2008-08-25 11:16 ---
We should not warn for compiler-generated code anyway. We need to find where
this is generated and then we need to check before warning.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from manu at gcc dot gnu dot org 2008-08-25 11:12 ---
You (someone) should retest this with a recent revision. Wuninitialized now
uses an explicit location so this should be fixed, hopefully.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #23 from manu at gcc dot gnu dot org 2008-08-25 10:50 ---
(In reply to comment #22)
> there is currently no good way to detect if a block is dead during the VRP
> pass, as the VRP information is used for *determining* wether or not a block
> is
> dead.
I think in this case
--- Comment #1 from paolo dot carlini at oracle dot com 2008-08-25 10:43
---
I think the improved error message in mainline makes clear this is invalid (the
EDG front-end agrees, by the way):
37231.c:6: error: a label can only be part of a statement and a declaration is
not a statement
--- Comment #2 from jh at suse dot cz 2008-08-25 10:41 ---
Subject: Re: [4.4 Regression] gcc.dg/ipa/ipa-?.c
Sorry, apparently I tested the new cost model only with IPCP enabled by
default. Until this is done, we need -fipa-cp-clone for those
testcases.
I am testing the following.
In
--- Comment #6 from manu at gcc dot gnu dot org 2008-08-25 10:22 ---
(In reply to comment #5)
> Manuel, I think it was caused by your check in for:
>
> 2008-08-17 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
>
> PR c++/35602
> * c-common.c (conversion_warning): Do not want
/gcc/gcc4.4w/share/info
--build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java
--with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
Thread model: posix
gcc version 4.4.0 [revision 139556p5] 20080825
Hi,
The following simple code does not build using GCC 3.3 or 4.x:
## main.c
int
main(int argc, char *argv[])
{
goto out;
out:
int retv = 0;
return retv;
}
###
GCC tells me:
### GCC output
main.c: In function main:
main.c:7
--- Comment #5 from burnus at gcc dot gnu dot org 2008-08-25 09:31 ---
Manuel, I think it was caused by your check in for:
2008-08-17 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR c++/35602
* c-common.c (conversion_warning): Do not want for artificial
expressions
--- Comment #2 from dominiq at lps dot ens dot fr 2008-08-25 08:53 ---
Same thing on i686-apple-darwin9 for both 32 and 64 bit modes. I have in
addition:
Running target unix/-m64
WARNING: program timed out.
FAIL: gfortran.fortran-torture/compile/logical-1.f90, -O2 -fomit-frame-pointer
--- Comment #3 from tehila at il dot ibm dot com 2008-08-25 08:45 ---
(In reply to comment #2)
> Andrew, thanks for your response and ideas.
> From what we see, if -funroll-loops is on, the loops:
> for (j = 0; j < 4; j++)
> arr[j] = mat2[i][j];
> and
> for (k = 0; k < 3; k
--- Comment #4 from burnus at gcc dot gnu dot org 2008-08-25 08:26 ---
My PR 37230 is presumably a duplicate of this PR. There, valgrind shows for
"gcc -Wconcersion":
==26156== Invalid read of size 2
==26156==at 0x458558: conversion_warning (c-common.c:1571)
==26156==by 0x4593F7
--- Comment #1 from burnus at gcc dot gnu dot org 2008-08-25 08:21 ---
Presumably a duplicate of PR 37217 even though the reduced test case there does
not give an ICE here.
$ gcc -Wconversion regcomp.i
gives the ICE. I defer from attaching the rather large regcomp.i.gz, unless
someone
--- Comment #2 from tehila at il dot ibm dot com 2008-08-25 08:18 ---
Andrew, thanks for your response and ideas.
>From what we see, if -funroll-loops is on, the loops:
for (j = 0; j < 4; j++)
arr[j] = mat2[i][j];
and
for (k = 0; k < 3; k++)
point += (do
This is with GNU C (GCC) Version 4.4.0 20080824 (experimental) [trunk revision
139535] (x86_64-unknown-linux-gnu) when compiling GDB (trunk)'s
generic/regcomp.c:
../../../src/tcl/unix/../generic/regcomp.c: In Function »TclReComp«:
../../../src/tcl/unix/../generic/regcomp.c:340: internal compiler e
--- Comment #7 from razya at il dot ibm dot com 2008-08-25 08:09 ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > Patch in bug #37185, comment #3, does not fix this bug.
> >
> > Meh. Bad patching job by me. Retesting patch...
> >
> Confirmed: p
--- Comment #6 from razya at il dot ibm dot com 2008-08-25 08:08 ---
Subject: Re: [4.4 Regression] FAIL: gcc.dg/matrix/matrix-1.c
scan-ipa-dump-times matrix-reorg "Flattened 3 dimensions" 1
"eric dot weddington at atmel dot com" <[EMAIL PROTECTED]> wrote on
25/08/2008 03:09:29:
>
>
--- Comment #17 from htl10 at users dot sourceforge dot net 2008-08-25
08:07 ---
Am having problem with libstdc++-v3 during bootrap of gcc 4.3.1 on Tru64 V5.1.
gfortran and gcc built fine. (with --enable-languages=c,fortran to override the
default list of c,c++,fortran,objc). The last
--- Comment #22 from mueller at gcc dot gnu dot org 2008-08-25 07:59
---
there is currently no good way to detect if a block is dead during the VRP
pass, as the VRP information is used for *determining* wether or not a block is
dead.
Is there a general warning-queuing implementation t
--- Comment #2 from pluto at agmk dot net 2008-08-25 07:42 ---
$ gcc utils.i -c -O3 -g
utils.c: In function 'tr_deepLog':
utils.c:193: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
In function 'memset',
inlined from 'tr_malloc0' at utils.c:70
--- Comment #1 from pluto at agmk dot net 2008-08-25 07:41 ---
Created an attachment (id=16142)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16142&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37229
during build of the transmission package the gcc hangs:
(...)
x86_64-pld-linux-gcc -DPACKAGE_NAME=\"transmission\"
-DPACKAGE_TARNAME=\"transmission\" -DPACKAGE_VERSION=\"1.33\"
-DPACKAGE_STRING=\"transmission\ 1.33\"
-DPACKAGE_BUGREPORT=\"http://trac.transmissionbt.com/newticket\";
-DPACKAGE=\"tra
82 matches
Mail list logo
