--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-17 07:09 ---
You can use gcc -E -P, then it doesn't print # lineno file
lines and puts the label and fn on the same line (as, without the line notes
locations aren't preserved anyway).
As Andrew wrote, gcc -E is a C/C++
--- Comment #5 from manu at gcc dot gnu dot org 2010-09-17 08:54 ---
I have seen this question/bug reported a couple of times in bugzilla and a few
more in gcc-help, so I added a FAQ:
http://gcc.gnu.org/wiki/FAQ#cpp_continuation_discarded
I suggest that it is rather more useful to
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-17
08:55 ---
Subject: Re: [4.6 regression] Reference to undefined label building libada on
Solaris 2/SPARC
--- Comment #6 from hubicka at gcc dot gnu dot org 2010-09-16 20:57
---
This is really strange
--- Comment #3 from nicola at gcc dot gnu dot org 2010-09-17 09:00 ---
@synchronized support is now available in the GNU runtime. :-)
Thanks
--
nicola at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from rguenth at gcc dot gnu dot org 2010-09-17 09:00
---
Subject: Bug 45678
Author: rguenth
Date: Fri Sep 17 09:00:23 2010
New Revision: 164356
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164356
Log:
2010-09-17 Richard Guenther rguent...@suse.de
PR
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-09-17 09:06
---
-combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 ---
-combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-09-17 09:06
---
-combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 ---
-combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 ---
-combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 ---
-combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-09-17 09:06
---
-combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 ---
-combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 ---
-combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 ---
-combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 ---
-combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 ---
-combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 ---
-combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 ---
-combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from rguenth at gcc dot gnu dot org 2010-09-17 09:09
---
(In reply to comment #28)
(In reply to comment #27)
Fixed for trunk sofar.
Is there an eta for 4.5 backport? We need this to switch Firefox to 4.5 on
Linux.
I just want to play safe and see if there is any
--- Comment #4 from nicola at gcc dot gnu dot org 2010-09-17 09:28 ---
This proposed enhancement seems to be a major change to the language! :-)
It basically would mean that every object has a customized class hierarchy.
So, when a message is sent to the object, the object's custom
On the trunk (and supposedly on 4.5 too) fold checking bootstrap fails e.g.
while building dyncast.cc in libsupc++ (and some ada compilations too).
I've debugged the dyncast.cc failure, the problem is that
fold_build3_loc on loc, COND_EXPR, type, EQ_EXPR, 1, 0 modifies the EQ_EXPR by
changing its
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Incorrect copy constructor |[4.6 Regression] Incorrect
|generated with -O
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-17 09:39 ---
Confirmed. Both variants are rejected when using the C frontend.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |rtl-optimization
Known to work|
--
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=45693
,%r11
cmpq%r10, %rdx
cmovne %r11, %r8
cmove %r9d, %ecx
movq%r8, (%rdi,%rdx,8)
addq$1, %rdx
addl%ecx, %eax
cmpq%rdx, %rsi
ja .L16
and gcc-4.6 20100917
.L15:
movq(%rdi,%rdx,8), %r8
testq %r8
--- Comment #5 from ubizjak at gmail dot com 2010-09-17 10:02 ---
Confirmed. Regression?
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from nicola at gcc dot gnu dot org 2010-09-17 10:14 ---
Ok ... I fixed the testcase in trunk. Please can you let me know if it works
fine now (I don't have a darwin machine to test). :-)
Thanks
--
nicola at gcc dot gnu dot org changed:
What|Removed
This was implemented in gcc-4.5, still works in gcc-4.5 branch.
2009-06-02 Richard Earnshaw rearn...@arm.com
* arm.c (arm_get_frame_offsets): Prefer using r3 for padding a
push/pop multiple to 8-byte alignment.
However, it doesn't work any longer on gcc-4.6 trunk. Reproduced on
--- Comment #1 from qiyao at gcc dot gnu dot org 2010-09-17 10:52 ---
Created an attachment (id=21816)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21816action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45701
--- Comment #5 from hubicka at gcc dot gnu dot org 2010-09-17 11:09 ---
Well, this is still something we should solve at LTO. Indirect inlining should
take away references that are fully resolved so function becomes unreachable.
Honza
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[regression 4.5] Fail to|[4.6 Regression] Fail to
|prefer using r3 for
--- Comment #2 from jakub at gcc dot gnu dot org 2010-09-17 12:05 ---
Created an attachment (id=21817)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21817action=view)
gcc46-pr45695.patch
Untested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45695
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-09-17 12:17 ---
Created an attachment (id=21818)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21818action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45621
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-09-17 12:19 ---
seems like streamer bug. We should not ever see any comdat groups here.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dominiq at lps dot ens dot fr 2010-09-17 12:42 ---
Ok ... I fixed the testcase in trunk.
Is there not a simpler way to fix the test with dejagnu directives?
Please can you let me know if it works fine now
With the new test the failures are gone. Thanks.
(I
--- Comment #37 from paolo dot carlini at oracle dot com 2010-09-17 12:42
---
Created an attachment (id=21819)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21819action=view)
Tested x86_64-linux, mainline
This is a carefully tested patch (tested in mainline, per the normal
On Linux/x86, revision 164357 gave
FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 (test for excess errors)
FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -O (test for excess errors)
FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -O3 (test for excess errors)
FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for
--- Comment #7 from jakub at gcc dot gnu dot org 2010-09-17 12:46 ---
You now set the location, but I believe the wrong one.
esra changes are:
foo (struct S * arg)
{
+ int SR.1;
+ int s$a;
struct S s;
struct S D.2694;
int D.2690;
@@ -72,10 +37,12 @@ foo (struct S * arg)
--- Comment #3 from hubicka at ucw dot cz 2010-09-17 12:48 ---
Subject: Re: ICE with -fwhopr/-flto when using strlen and
strcat without previous declaration
seems like streamer bug. We should not ever see any comdat groups here.
We stream the node twice for some reason (I can
--- Comment #1 from rguenther at suse dot de 2010-09-17 12:56 ---
Subject: Re: New: [4.6 Regression] New test failures
On Fri, 17 Sep 2010, hjl dot tools at gmail dot com wrote:
On Linux/x86, revision 164357 gave
FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 (test for excess errors)
--- Comment #6 from hjl dot tools at gmail dot com 2010-09-17 13:04 ---
(In reply to comment #4)
This all happens in IF conversion pass.
4.6 regresses in the sense that a branch is emitted instead of cmov for:
This is caused by revision 159106:
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-09-17 13:13 ---
OK, the problem is that we stream two cgraph nodes. One for strlen function
and other for __bulitin_strlen. Decl of __bulitin_strlen have same asm name as
strlen:
(gdb) p debug_tree (node-decl)
function_decl
--- Comment #5 from rguenther at suse dot de 2010-09-17 13:26 ---
Subject: Re: ICE with -fwhopr/-flto when using strlen and
strcat without previous declaration
On Fri, 17 Sep 2010, hubicka at gcc dot gnu dot org wrote:
--- Comment #4 from hubicka at gcc dot gnu dot org
--- Comment #3 from matz at gcc dot gnu dot org 2010-09-17 13:26 ---
Subject: Bug 43432
Author: matz
Date: Fri Sep 17 13:26:43 2010
New Revision: 164367
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164367
Log:
PR tree-optimization/43432
* tree-vect-data-refs.c
--- Comment #6 from hubicka at ucw dot cz 2010-09-17 13:30 ---
Subject: Re: ICE with -fwhopr/-flto when using strlen and
strcat without previous declaration
Richi: is that intended behaviour?
No, we shouldn't stream them at all. Why do we even bother? And yes,
Because
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-17 13:35 ---
I got
# /export/build/gnu/gcc-32bit/build-i686-linux/gcc/xgcc
-B/export/build/gnu/gcc-32bit/build-i686-linux/gcc/
/export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -flto -r -nostdlib
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-17 13:36 ---
-m32 works on Intel64 since gcc driver passes
/export/build/gnu/gcc/build-x86_64-linux/gcc/collect-ld --eh-frame-hdr -m
elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o pr28712.exe -r
--- Comment #7 from rguenther at suse dot de 2010-09-17 13:43 ---
Subject: Re: ICE with -fwhopr/-flto when using strlen and
strcat without previous declaration
On Fri, 17 Sep 2010, hubicka at ucw dot cz wrote:
--- Comment #6 from hubicka at ucw dot cz 2010-09-17 13:30
--- Comment #7 from matz at gcc dot gnu dot org 2010-09-17 13:45 ---
It might have been exposed by that revision, but that merely points out
a deficiency in RTL if conversion. The final gimple code doesn't have
explicit jumps in the inner loop, but uses cond_expr:
bb 3:
# s_22 = PHI
--- Comment #4 from rguenther at suse dot de 2010-09-17 13:48 ---
Subject: Re: [4.6 Regression] New LTO test failures
On Fri, 17 Sep 2010, hjl dot tools at gmail dot com wrote:
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-17 13:36
---
-m32 works on Intel64
--- Comment #5 from hjl dot tools at gmail dot com 2010-09-17 13:52 ---
Works fine in 64bit with -m32
[...@gnu-6 gcc]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -flto -r
--- Comment #23 from rguenth at gcc dot gnu dot org 2010-09-17 13:57
---
Subject: Bug 45678
Author: rguenth
Date: Fri Sep 17 13:57:04 2010
New Revision: 164369
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164369
Log:
2010-09-17 Richard Guenther rguent...@suse.de
PR
--- Comment #6 from jakub at gcc dot gnu dot org 2010-09-17 13:57 ---
With -r -nostdlib when -lm is mentioned on the command line, it is looking for
libm.a. Guess you have it installed on one box and not on the other one.
That said, the tests really shouldn't have -lm on their link
--- Comment #7 from rguenther at suse dot de 2010-09-17 13:58 ---
Subject: Re: [4.6 Regression] New LTO test failures
On Fri, 17 Sep 2010, hjl dot tools at gmail dot com wrote:
--- Comment #5 from hjl dot tools at gmail dot com 2010-09-17 13:52
---
Works fine in 64bit
--- Comment #14 from ktietz at gcc dot gnu dot org 2010-09-17 14:01 ---
Created an attachment (id=21820)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21820action=view)
testcase for problem
As this test need more then on header, please extract it and compile then
main.c to
--- Comment #8 from jakub at gcc dot gnu dot org 2010-09-17 14:04 ---
Dejagnu adds it always for dg-do link/run, and there doesn't seem to be a way
to bypass that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
--- Comment #9 from rguenther at suse dot de 2010-09-17 14:07 ---
Subject: Re: [4.6 Regression] New LTO test failures
On Fri, 17 Sep 2010, jakub at gcc dot gnu dot org wrote:
--- Comment #8 from jakub at gcc dot gnu dot org 2010-09-17 14:04 ---
Dejagnu adds it always for
--- Comment #10 from hjl dot tools at gmail dot com 2010-09-17 14:08
---
(In reply to comment #6)
With -r -nostdlib when -lm is mentioned on the command line, it is looking for
libm.a. Guess you have it installed on one box and not on the other one.
That said, the tests really
--- Comment #11 from hjl dot tools at gmail dot com 2010-09-17 14:11
---
(In reply to comment #9)
Subject: Re: [4.6 Regression] New LTO test failures
On Fri, 17 Sep 2010, jakub at gcc dot gnu dot org wrote:
--- Comment #8 from jakub at gcc dot gnu dot org 2010-09-17 14:04
--- Comment #12 from rguenther at suse dot de 2010-09-17 14:14 ---
Subject: Re: [4.6 Regression] New LTO test failures
On Fri, 17 Sep 2010, hjl dot tools at gmail dot com wrote:
--- Comment #11 from hjl dot tools at gmail dot com 2010-09-17 14:11
---
(In reply to comment
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-09-17
14:21 ---
Should we just XFAIL this on darwin then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-17 14:29 ---
It is caused by revision 159362:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00414.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
gcc --help -v no longer runs ld --help because collect2 handles --help itself
without running ld.
--
Summary: [4.6 regression] --help -v no longer shows linker help
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-09-17 14:39 ---
I'll have a look at it but please be patient, my bug queue is rather long at
the moment.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from jamborm at gcc dot gnu dot org 2010-09-17 14:46
---
Honza submitted a patch
(http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01369.html) so I guess it is his
PR now :-)
--
jamborm at gcc dot gnu dot org changed:
What|Removed
A cast to volatile int pointer is ignored on gcc 4.5 with this test case.
struct st {
int ptr;
};
int foo(struct st *st)
{
int v = *(volatile int *)st-ptr;
return v 0xff;
}
mipsel-linux-gcc-4.5.1 -O2 foo.c -S output:
lbu $2,0($4)
j $31
--- Comment #8 from jamborm at gcc dot gnu dot org 2010-09-17 15:08 ---
(In reply to comment #7)
The added MEM = SR.1_10 uses location_t of the stmt after it, as
sra_modify_expr
emits statements before gsi. I'm arguing that in this case the MEM[(struct S
*)D.2694] = SR.1_10; stmt
int x;
void
foo (void)
{
if (x == 0)
x = 0;
}
was optimized into empty routine with gcc 3.4 and 4.0, but isn't any longer in
4.1+. In 4.0 apparently the store went away in *.optimized, and with
-fno-tree-ter in ce1+combine removed it. This occurs quite a lot in
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-17 15:13 ---
(In reply to comment #5)
Should we just XFAIL this on darwin then?
You mean it still fails?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-17 15:18 ---
Eventually predicated value-numbering will fix this as part of the
redundant store removal eliminate() performs.
A similar thing can be added to DOM, which already can do the predication.
I'll give that a quick
--- Comment #7 from dominiq at lps dot ens dot fr 2010-09-17 15:18 ---
You mean it still fails?
Yes!-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-17 15:19 ---
ce1+combine removed it.
I think it still does on targets that don't have a direct to memory store of 0
like PPC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-17 15:39 ---
Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c (revision 164371)
+++ tree-ssa-dom.c (working copy)
@@ -1804,6 +1804,37 @@
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45705
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-17 15:45 ---
Confirmed. Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-09-17 15:46 ---
Reopen.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dominiq at lps dot ens dot fr 2010-09-17 15:57 ---
Apparently the problem is that when compiled with -fipa-matrix-reorg -O[123s]
-fwhole-program in 64 bit mode, the executable gives:
...
a.out(83070) malloc: *** error for object 0x1001000c0: pointer being freed was
On Linux/ia32, revision 164369 gave
FAIL: gcc.dg/vect/vect-114.c scan-tree-dump-times vect vectorized 0 loops 1
Revision 164366 is OK. It may be caused by revision 164367:
http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00661.html
--
Summary: [4.6 regression] gcc.dg/vect/vect-114.c
--- Comment #1 from matz at gcc dot gnu dot org 2010-09-17 16:12 ---
This passes for me, even in -m32 mode (if -msse is added, like vect.exp
does):
% ./cc1 -ftree-vectorize -fno-vect-cost-model -msse2 -O2 \
vect-114.c -ftree-vectorizer-verbose=2 21 | grep note:
vect-114.c:13: note:
#include stdio.h
int main()
{
int i;
while(1)
{
if(i0)
{
break;
}
i++;
}
return 0;
}
compiled with -O3
infinite loop:
.L5:
jmp .L5
--
Summary: infinite loop
Product: gcc
Version: 4.4.3
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-17 16:30 ---
(In reply to comment #1)
This passes for me, even in -m32 mode (if -msse is added, like vect.exp
does):
% ./cc1 -ftree-vectorize -fno-vect-cost-model -msse2 -O2 \
vect-114.c -ftree-vectorizer-verbose=2 21 |
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-17 16:30 ---
For some reason, it only fails with 32bit gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45706
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-17 16:32 ---
This code depends on two undefined behavior. First it depends on an
uninitialized value of i. If i is greater than 0 to begin with it depends on
signed integer overflow which is undefined.
--
pinskia at gcc
--- Comment #24 from hjl dot tools at gmail dot com 2010-09-17 16:35
---
Created an attachment (id=21821)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21821action=view)
A patch
The problem is we failed to update stack alignment when
we increase alignment of local variable. This
--- Comment #4 from nicola at gcc dot gnu dot org 2010-09-17 16:40 ---
Ok ... I fixed the testcase in trunk.
Is there not a simpler way to fix the test with dejagnu directives?
Probably. :-)
The fix in trunk does work and is consistent with other files in the same
directory.
--- Comment #1 from nicola at gcc dot gnu dot org 2010-09-17 16:53 ---
Thanks
well spotted :-)
Unfortunately, the list_remove_elem() function is obsolete (never used inside
the runtime itself, and deprecated for usage outside of it as of 4.6.0) so
there is not much point in working on
--- Comment #5 from iains at gcc dot gnu dot org 2010-09-17 17:05 ---
(In reply to comment #4)
Ok ... I fixed the testcase in trunk.
Is there not a simpler way to fix the test with dejagnu directives?
Probably. :-)
well that's why I added the /torture dir under objc.dg - if
--- Comment #25 from hjl dot tools at gmail dot com 2010-09-17 17:26
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01425.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #26 from hjl at gcc dot gnu dot org 2010-09-17 17:49 ---
Subject: Bug 45678
Author: hjl
Date: Fri Sep 17 17:49:30 2010
New Revision: 164375
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164375
Log:
Update stack alignment when increasing local variable alignment.
--- Comment #38 from potswa at mac dot com 2010-09-17 17:51 ---
Created an attachment (id=21822)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21822action=view)
Works with codecvt. Tested Tested x86_64-darwin, mainline
Ah, now I see the trick:
if (__off == 0 !(_M_mode
--- Comment #17 from hjl at gcc dot gnu dot org 2010-09-17 18:00 ---
Subject: Bug 45234
Author: hjl
Date: Fri Sep 17 18:00:40 2010
New Revision: 164377
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164377
Log:
Make sure that all variable sized adjustments are multiple of
--- Comment #39 from potswa at mac dot com 2010-09-17 18:04 ---
Oops, no, I'm on the 4.5.2 series, not mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-09-17 18:21 ---
The problem is a big one. In short, placement new operator changes
the type of an object to another, which re-sets up the VMT. Then there
is call of a virtual method of the latter type. CCP however happily
--- Comment #15 from ktietz at gcc dot gnu dot org 2010-09-17 18:37 ---
(In reply to comment #14)
Created an attachment (id=21820)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21820action=view) [edit]
testcase for problem
As this test need more then on header, please extract
--- Comment #40 from paolo dot carlini at oracle dot com 2010-09-17 18:53
---
In general, our users know that seeking allows to switch from reading to
writing, and viceversa (when the stream has been appropriately opened of
course). This assumption remained true for years and years.
basic_filebuf (and therefore fstream) does not allow you to put a write
operation directly after a read operation, or vice versa. Instead, the write
and the read must be separated by a seek or tell (tell being equivalent to a
seek-to-current-position).
As the Standard specifies behavior in terms
--- Comment #9 from spop at gcc dot gnu dot org 2010-09-17 19:01 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
1 - 100 of 148 matches
Mail list logo
