--- Comment #6 from jason at gcc dot gnu dot org 2010-08-23 06:40 ---
Subject: Bug 45315
Author: jason
Date: Mon Aug 23 06:39:42 2010
New Revision: 163466
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163466
Log:
PR c++/45315
* init.c (build_new_1): Don't use
--- Comment #10 from nathan at gcc dot gnu dot org 2010-08-23 07:42 ---
Thanks Uros!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45361
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2010-08-23 08:37
---
(In reply to comment #1)
That's the lines:
1472char cup;
1467size_t dim_i;
1504cup = toupper (base_name[dim_i]);
1511cup = toupper (obj-var_name[dim_i]);
and
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2010-08-23 08:39
---
Index: io/unix.c
===
--- io/unix.c (revision 163225)
+++ io/unix.c (working copy)
@@ -151,11 +151,15 @@
static int
fallback_access (const char
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-23 09:09 ---
Couldn't reproduce with r163403, can you still reproduce it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45072
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44913
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-23 10:09 ---
Smaller testcase:
templateclass T, unsigned long l
inline unsigned long foo (T ()[l]) { return l; }
struct S { char *s[4]; S (); };
S::S () { typedef int T[foo (s) == 4 ? 1 : -1]; }
--
jakub at gcc dot gnu dot
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-23 10:16 ---
As can be seen in
inline unsigned long foo () { return 4; }
struct S { S (); };
void bar () { typedef int T[foo () == 4 ? 1 : -1]; }
S::S () { typedef int T[foo () == 4 ? 1 : -1]; }
the problem only happens in cdtors,
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-23 11:22 ---
this report isn't much help - does the warning occur when building the library,
or using it?
and I doubt it makes any difference, but you've reported it against 4.5.1 and
then said you're using 4.5.0
The warning
--- Comment #2 from jay dot krell at cornell dot edu 2010-08-23 11:26
---
This is building libstdc++ 4.5.1.
You can sort of tell from the path.
I build in obj. I don't install to obj.
The bootstrap compiler might have been 4.5.0.
I can do it again with 4.5.1 as bootstrap.
I
--- Comment #3 from redi at gcc dot gnu dot org 2010-08-23 11:35 ---
(In reply to comment #2)
This is building libstdc++ 4.5.1.
You can sort of tell from the path.
I build in obj. I don't install to obj.
Ah yeah - the report would have been more useful with that info though, so
--- Comment #1 from dominiq at lps dot ens dot fr 2010-08-23 12:20 ---
Reduced test
!
MODULE kinds
INTEGER, PARAMETER :: RK8 = SELECTED_REAL_KIND(15, 300)
END MODULE kinds
!
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-23 12:26 ---
Subject: Bug 45366
Author: janus
Date: Mon Aug 23 12:26:42 2010
New Revision: 163468
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163468
Log:
2010-08-23 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-23 12:29 ---
Fixed with r163468. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2010-08-23 12:39 ---
Subject: Bug 45323
Author: burnus
Date: Mon Aug 23 12:39:20 2010
New Revision: 163469
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163469
Log:
2010-08-23 Tobias Burnus bur...@net-b.de
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2010-08-23 12:43 ---
Jay: thanks for again for the report! It would be useful if you could confirm
that the patch fixes the warning for you. (It should.)
Committed to the trunk, http://gcc.gnu.org/ml/fortran/2010-08/msg00317.html
(By
Consider this code:
#include iostream
struct null {
null() {}
templateclass T
operator T*() const {
return 0;
}
templateclass C, class T
operator T C::*() const {
return 0;
}
private:
null(const null);
null operator=(const
--- Comment #7 from anitha dot boyapati at atmel dot com 2010-08-23 13:08
---
Created an attachment (id=21547)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21547action=view)
Reduced testcase
Reduced testcase to reproduce the bug.
--
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-23 13:17 ---
The summary seems backwards: the conversion shouldn't generate operator==,
instead using operator== should trigger the conversion, but fails to when the
conversion operator is a template.
Strangely, adding a
--- Comment #8 from anitha dot boyapati at atmel dot com 2010-08-23 13:25
---
When -O2 is enabled result is 0xFF (255) which is incorrect. The code generated
for the following shift operation:
13: return (left right);
+00AB: C004RJMP PC+0x0005
--- Comment #27 from janus at gcc dot gnu dot org 2010-08-23 13:25 ---
(In reply to comment #24)
Here is a somewhat modified version of comment #14, which compiles but
produces
wrong code:
The example in comment #24 contains a statically-resolved TBP call (the pass
object is
--- Comment #28 from janus at gcc dot gnu dot org 2010-08-23 13:32 ---
Comment #27 can be fixed by:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 163468)
+++ gcc/fortran/resolve.c
--- Comment #9 from wvangulik at xs4all dot nl 2010-08-23 13:36 ---
I already generated a simple testcase (although different)in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39635. The comments from Andy in
the linked report might be worth reproducing here
--
.ident GCC: (GNU) 4.6.0 20100823 (experimental) [trunk revision
163469]
This was fixed by the fix to PR44999. Hence fixed.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from zsojka at seznam dot cz 2010-08-23 14:37 ---
The testcase no longer crashes in r162940, r163261 and 163468 for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45072
=c,c++,fortran
Thread model: posix
gcc version 4.6.0 20100823 (experimental) (GCC)
[sfili...@localhost bug20]$ gfortran -o bug20 bug20.f90
[sfili...@localhost bug20]$ ./bug20
NV = 10
*** glibc detected *** ./bug20: double free or corruption (fasttop):
0x018d8ae0
--- Comment #1 from sfilippone at uniroma2 dot it 2010-08-23 14:44 ---
Created an attachment (id=21548)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21548action=view)
test-case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45384
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-23 14:55 ---
Worksforme then.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dominiq at lps dot ens dot fr 2010-08-23 14:58 ---
Confirmed. Valgrind gives
==89074== Invalid free() / delete / delete[]
==89074==at 0x10001079F: free (vg_replace_malloc.c:366)
==89074==by 0x10D15: MAIN__ (in ./a.out)
==89074==by 0x10D55: main
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-23 15:36 ---
Reduced test case:
program bug20
type :: d_base_sparse_mat
integer :: v(10) = 0.
end type d_base_sparse_mat
class(d_base_sparse_mat),allocatable :: a
allocate (d_base_sparse_mat :: a)
select type(aa
--- Comment #8 from hpa at zytor dot com 2010-08-23 16:00 ---
Created an attachment (id=21549)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21549action=view)
Potential test cases
These are the four modules which this change seem to affect, from *my* build...
please note that I do
--- Comment #4 from gordon dot magnusson at gmail dot com 2010-08-23 16:00
---
gcc-4.6-20100821 exhibits the same problem, with the same error messages.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45343
Hi,
compiling the following code with -Wconversion doesn't give a warning while
with compiler version 4.3.2 does. As you can verify the posted code has a real
conversion loss at runtime giving:
expected: 80
obtained: 3705032704
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-23 16:29 ---
ICC people say
--
In my opinion, FP multiplication and addition should be considered commutative
at both the C and intrinsic level. The only case where the underlying
instructions behave in a non-commutative
--- Comment #54 from howarth at nitro dot med dot uc dot edu 2010-08-23
16:32 ---
http://llvm.org/svn/llvm-project/lldb/trunk/source/Plugins/Process/Utility/libunwind/src/UnwindLevel1-gcc-ext.c
contains the sources for the libunwind in darwin10 (which shows the aborting
and
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-23 16:35 ---
It is caused by revision 155415:
http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00559.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-23 17:04 ---
Can't reproduce on x86_64-linux. Please try to pinpoint the codegen difference
that causes the slowdown.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dominiq at lps dot ens dot fr 2010-08-23 17:24 ---
Can't reproduce on x86_64-linux.
My timings were on an Intel Core2Duo 2.53Ghz.
Please try to pinpoint the codegen difference that causes the slowdown.
I don't know if this what you ask for, but comparing
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-08-23 17:46 ---
Can you try
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c (revision 163472)
+++ gcc/emit-rtl.c (working copy)
@@ -1788,6 +1788,7 @@
testcase.c
int i;
Actually, it seems any C file will suffice to reproduce.
Valgrind output:
$ valgrind -q --trace-children=yes gcc testcase.c -c
==10251== Invalid read of size 8
==10251==at 0xFEE4F3: search_line_sse2 (lex.c:372)
==10251==by 0xFEE6E9:
In some conditions on mips/mipsel, when compiling with -g, ld fails to link the
resulting objects (see attached testcase):
| gcc -O2 -g -fPIC -shared -o libb.so yb.c
| gcc -O2 -g -o ya.o -c ya.c
| gcc -O2 -g -o y ya.o -L. -lb
| /usr/bin/ld: non-dynamic relocations refer to dynamic symbol
--- Comment #1 from aurelien at aurel32 dot net 2010-08-23 18:15 ---
Created an attachment (id=21550)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21550action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45387
--- Comment #4 from mikael at gcc dot gnu dot org 2010-08-23 18:42 ---
Subject: Bug 45380
Author: mikael
Date: Mon Aug 23 18:42:21 2010
New Revision: 163484
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163484
Log:
2010-08-23 Mikael Morin mik...@gcc.gnu.org
PR
--- Comment #6 from changpeng dot fang at amd dot com 2010-08-23 18:59
---
Committed to trunk as Revision: 163475:
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00688.html
Committed to 4.5 branch as Revision: 163483
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00696.html
--
--- Comment #5 from dominiq at lps dot ens dot fr 2010-08-23 19:01 ---
Can you try ...
This does not change the timing for test_fpu.f90 and the reduced test in
comment #1.
AFAICT the problem is within the loop
DO j = 1, n
c = b(k,j)*d
do i = 1, n
b(i,j) =
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-23 19:12 ---
jne .L6
jmp .L7
.L8:
#APP
# 18 t.c 1
#mem
# 0 2
#NO_APP
.L6:
--- CUT ---
I added #mem inside the inline-asm which is empty and got the above code.
Which means that the inline-asm
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-23 20:05 ---
I think that's by design (it won't cross page boundary though).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45383
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.5.2 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45382
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45381
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-23 20:12 ---
*** This bug has been marked as a duplicate of 44562 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-08-23 20:12 ---
*** Bug 45368 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.4.4
Summary|libgcc fails to configure: |[4.5
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-23 20:17 ---
Why do you think it's a poor choice?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-23 20:18 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45355
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-23 20:20 ---
Can you possibly reduce one testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45351
--- Comment #75 from sje at cup dot hp dot com 2010-08-23 20:49 ---
Paolo, are you looking at this? The hppa64-*-* bootstrap is still broken.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/test/gnu/
gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/abi/c
ovariant3.C -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-
v3/include/hppa2.0w-hp-hpux11.11
--- Comment #1 from danglin at gcc dot gnu dot org 2010-08-23 20:58 ---
Constructor is no longer global:
.PARAM _GLOBAL__I__ZN2c12f6Ev,PRIV_LEV=3
L$FB0035:
_GLOBAL__I__ZN2c12f6Ev:
As a result, collect2 does not find the constructor.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-23 21:09 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dwood at sybase dot com 2010-08-23 21:13 ---
I believe this is a bug or a serious oversite in understanding the need for
support of USER thread local storage. There are two kinds of software
threads; a) kernel threads(AKA LWP's on Solaris) scheduled by the OS; and
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-08-23 21:19 ---
I think you should read:
http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/C99-Thread_002dLocal-Edits.html#C99-Thread_002dLocal-Edits
--- CUT ---
In GCC's case the thread is only can be created via pthread.
Note C++0x
On a AMD amdfam10 system, gcc 4.5 (892s) is 15% faster than gcc 4.6 (1026s)
With the following settings:
4.6: gcc version 4.6.0 20100812 (experimental) (GCC)
COPTIMIZE = -Ofast -funroll-all-loops -fno-tree-pre --param
prefetch-latency=700 -mveclibabi=acml -m64 -march=amdfam10
FOPTIMIZE
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-23 21:25 ---
(In reply to comment #2)
Created an attachment (id=21536)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21536action=view) [edit]
Potential fix
Can you try this?
It works. Thanks.
--
On an AMD amdfam10 system, gcc 4.5 (713s) is 7% faster than gcc 4.6 (763s)
With the following settings:
4.6: gcc version 4.6.0 20100812 (experimental) (GCC)
FOPTIMIZE = -Ofast -funroll-all-loops -fno-tree-pre -mveclibabi=acml
-m64 -march=amdfam10
EXTRA_LDFLAGS = -L$(ACML_DIR) -lacml_mv
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45387
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
Keywords||build
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-23 21:42 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-23 21:46 ---
Looks related to PR 11814.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45374
--- Comment #2 from dpovey at gmail dot com 2010-08-23 21:51 ---
(In reply to comment #1)
Yes you are right, but it is more than that bug, because I created an example
where gcc wrongly *rejects* code that it should accept, as well as one where it
wrongly accepts code that it should
--- Comment #3 from redi at gcc dot gnu dot org 2010-08-23 22:01 ---
(In reply to comment #2)
BTW, Visual Studio (2010) has different behavior -- it accepts both of the
statements in main(), even though they require different parse trees.
EDG (Comeau) also accepts them both.
--
With gcc-4.6 -Ofast -funroll-all-loops -fno-tree-pre -mveclibabi=acml -m64
-march=amdfam10
sphnix3 runs 5% slower than with
gcc-4.6 -Ofast -funroll-all-loops -fno-prefetch-loop-arrays -fno-tree-pre
-mveclibabi=acml -m64 -march=amdfam10
prefetching will not cause any slowdown if the vectorizer is
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-23 23:43 ---
This might be related to PR 45021.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45391
--- Comment #2 from changpeng dot fang at amd dot com 2010-08-24 00:03
---
float f (float *x, float *y, float *z, unsigned n)
{
float ret = 0.0;
unsigned i;
for (i = 0; i n; i++)
{
float diff = x[i] - y[i];
ret -= diff * diff * z[i];
}
return ret;
}
NO,
--- Comment #3 from changpeng dot fang at amd dot com 2010-08-24 00:22
---
I checked with open64 and did not find any regression. And for the above
testcase, open64 generated 3 non-temporal prefetches. As a result, I am
guessing that we are just unlucky that the prefetch kicks out
--- Comment #4 from changpeng dot fang at amd dot com 2010-08-24 00:46
---
Ooops, the open64 generated code posted in last comment is for non-vectorized
loop, the vectorized one is similar:
.LBB23_f:
.loc1 7 0
movups 0(%r10),%xmm3# [0] id:65
jcsample.i: In function 'int_downsample':
jcsample.i:1437:1: internal compiler error: in get_alias_set, at alias.c:701
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
gcc -r -nostdlib jcsample.i -c -O2
--- Comment #1 from t7 at gmail dot com 2010-08-24 01:45 ---
Created an attachment (id=21551)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21551action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45392
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-08-24 02:02 ---
*** This bug has been marked as a duplicate of 44562 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-08-24 02:02 ---
*** Bug 45392 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from t7 at gmail dot com 2010-08-24 02:48 ---
Can not re-produce 44562 problem on Windows 7 x64 native gcc-trunk compiler
target=x86_64-w64-mingw32
Compiled fine.
gcc -O1 -flto -fstrict-aliasing -fgraphite-identity pr44562.c
Can't compile on Windows 7 gcc-trunk
--- Comment #4 from t7 at gmail dot com 2010-08-24 02:55 ---
Both test from pr44562 compiled fine on Windows 7 x64 Native Win64
x86_64-w64-mingw32 Multi-lib 32/64 Bits capable GCC Compiler.
gcc -O1 -flto -fstrict-aliasing -fgraphite-identity -c pr44562.c
gcc -O3 -g -fwhopr -c
--- Comment #10 from dwood at sybase dot com 2010-08-24 03:31 ---
(In reply to comment #9)
I don't disagree with the thread local writeup however it is lacking in
clarity. A flow of control must be associated with an execution context.
The existance of getcontext/setcontext allows
--- Comment #5 from socketpair at gmail dot com 2010-08-24 03:35 ---
There is nothing the compiler can do really.
Why ?
I compared assembler listings with likely() swapped with unlikely(). As I
suggest, it helps to choose between je and jne in each case, and other
circumstances are not
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2010-08-24
05:07 ---
Fixed as r159700.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
88 matches
Mail list logo
