--- Comment #4 from eyal at eyal dot emu dot id dot au 2007-10-29 07:46
---
(In reply to comment #3)
> I can reproduce this on powerpc64-linux with a compiler from 20070630 but not
> with anything after 30070731; can anyone else still reproduce the failure, or
> has it been fixed?
I st
--- Comment #4 from znmeb at cesmail dot net 2007-10-29 04:37 ---
(In reply to comment #1)
> well you need to provide more information really, like a testcase.
>
I uploaded the file that the second compile croaked on. It will take me a while
to come up with a simpler test case ... this
--- Comment #3 from znmeb at cesmail dot net 2007-10-29 04:35 ---
Created an attachment (id=14432)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14432&action=view)
source, gcov output, gcno and gcda files for the first routine
This is the source file that the second compile died o
--- Comment #2 from znmeb at cesmail dot net 2007-10-29 04:30 ---
Created an attachment (id=14431)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14431&action=view)
gcc --dumpspecs, --dumpversion, --dumpmachine
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33936
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-29 04:29 ---
well you need to provide more information really, like a testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
I'm running gcc 4.2.2 on Gentoo Linux.
I've compiled the Ruby interpreter using the flags "gcc -g -fprofile-generate
-frandom-seed=0 --coverage". Then I ran some tests and successfully ran "gcov".
Now I'm trying to re-compile Ruby with optimization hints from the profiles. It
crashes on the firs
--- Comment #15 from znmeb at cesmail dot net 2007-10-29 03:08 ---
(In reply to comment #14)
> I'm still getting this with gcc 4.2.2 ... can I re-open it?
>
BTW, the test case is the Ruby interpreter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20815
--- Comment #14 from znmeb at cesmail dot net 2007-10-29 03:07 ---
I'm still getting this with gcc 4.2.2 ... can I re-open it?
--
znmeb at cesmail dot net changed:
What|Removed |Added
--- Comment #6 from danglin at gcc dot gnu dot org 2007-10-29 01:41 ---
The warnings are expected. From pa64-hpux.h:
/* We don't want undefined weak references to __register_frame_info,
__deregister_frame_info, _Jv_RegisterClasses and __cxa_finalize
introduced by crtbegin.o. The
--- Comment #1 from pcarlini at suse dot de 2007-10-29 01:09 ---
Yes, in some sense the resolution of DR 456 doesn't consider strchr and co.
Some time ago I mentioned that in private email with Howard but then didn't
really pursue it. Will do, maybe at one of the next C++ meetings.
--
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-29
00:35 ---
Subject: Re: INIT_PRIORITY is broken
> I believe you're correct that my changes broke the handling of
> prioritized constructors in the case where we use collect2. I didn't
> realize that there were targe
The C++ standard defines the C headers such as and in
terms of their C++ versions such as and , which in turn are
defined in terms of the headers in the C standard.
Thus, and require the function overloads for functions
such as strchr and wcschr that are defined to be in and .
However, libs
--- Comment #6 from pcarlini at suse dot de 2007-10-29 00:18 ---
Fixed in mainline.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at
--- Comment #5 from paolo at gcc dot gnu dot org 2007-10-29 00:17 ---
Subject: Bug 30659
Author: paolo
Date: Mon Oct 29 00:17:10 2007
New Revision: 129710
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129710
Log:
cp/
2007-10-28 Paolo Carlini <[EMAIL PROTECTED]>
Ma
--- Comment #5 from gcc at magfr dot user dot lysator dot liu dot se
2007-10-29 00:04 ---
Created an attachment (id=14430)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14430&action=view)
Testcase demonstrating the problem
To reproduce, compile using
g++ S1.C S1.C
Yes - S1.C sh
--- Comment #10 from manu at gcc dot gnu dot org 2007-10-28 23:42 ---
I cannot reproduce the warning in trunk neither in GCC 4.1.2. I nobody can
reproduce this in a recent version, I will close it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26264
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-28
22:47 ---
Subject: Re: "error: array type has incomplete element type" in system header
> > In particular, the following DR was referenced as proof the above is
> > "not valid C":
> > http://www.open-std.org/jtc1/sc
--- Comment #6 from mark at codesourcery dot com 2007-10-28 22:46 ---
Subject: Re: INIT_PRIORITY is broken
danglin at gcc dot gnu dot org wrote:
> With respect to initpr1.c, it can be seen that only one "GLOBAL" constructor,
> _GLOBAL__I_0_c1, and one "GLOBAL" destructor, _GLOBAL__D_1
--- Comment #10 from steven at gcc dot gnu dot org 2007-10-28 21:38 ---
Re. #9 see http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01698.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33828
--- Comment #13 from reichelt at gcc dot gnu dot org 2007-10-28 21:31
---
This is a variant of PR24791 that was fixed on mainline by Jason.
*** This bug has been marked as a duplicate of 24791 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #14 from reichelt at gcc dot gnu dot org 2007-10-28 21:31
---
*** Bug 20133 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from steven at gcc dot gnu dot org 2007-10-28 21:30 ---
The computation of VBEIN and VBEOUT in gcse.c's code hoisting implementation
appears to be performed in the wrong order, if you ask me.
The code in gcse.c is a copy-and-paste of Muchnick, which presents the dataflow
--- Comment #13 from reichelt at gcc dot gnu dot org 2007-10-28 21:27
---
Fixed by Jason's patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-10-28 21:19
---
While PR33839 and PR33837 got fixed, this ICE still persists.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from joseph at codesourcery dot com 2007-10-28 21:13 ---
Subject: Re: New: "error: array type has incomplete element
type" in system header
On Sun, 28 Oct 2007, danglin at gcc dot gnu dot org wrote:
> This was discussed in this thread:
> http://gcc.gnu.org/ml/gcc/2005
--- Comment #20 from jakub at gcc dot gnu dot org 2007-10-28 21:11 ---
Actually, we don't probably need to write to rws_sum array at all when in
safe_group_barried_needed and then we wouldn't need to copy it around (save and
restore it) at all.
--- config/ia64/ia64.c~ 2007-10-28 22:00:2
In the program snippet given below, line number 14 and 20 should have identical
access privileges with respect to A::func(). But gcc 4.1.2 compiles line #14
just fine, whereas on line #20, it catches the error correctly. This bug is
similar to bug #24118.
1 class A
2 {
3 protected:
4
--- Comment #3 from debian-gcc at lists dot debian dot org 2007-10-28
20:53 ---
not since the initial report.
Matthias
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
--
--- Comment #19 from jakub at gcc dot gnu dot org 2007-10-28 20:42 ---
Another trivial patch that improves speed is:
--- ia64.c (revision 129700)
+++ ia64.c (working copy)
@@ -5310,11 +5310,11 @@ ia64_safe_type (rtx insn)
struct reg_write_state
{
- unsigned int write_count
--- Comment #1 from danglin at gcc dot gnu dot org 2007-10-28 20:37 ---
This avoids the problem:
#include
#include
#include
int
main ()
{
return 0;
}
The header "sys/sar.h" declares struct syswait. Thus, there is
a work around for the autoconf macro that uses this test.
However,
--- Comment #18 from jakub at gcc dot gnu dot org 2007-10-28 20:20 ---
Created an attachment (id=14429)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14429&action=view)
rws_insn.patch
Just a side note. Maintaining the rws_insn array seems to be horribly
expensive to me, and for e
--- Comment #17 from maxim at codesourcery dot com 2007-10-28 20:04 ---
Subject: Re: [4.3 Regression] slow compilation
on ia64 (postreload scheduling)
jakub at gcc dot gnu dot org wrote:
> --- Comment #15 from jakub at gcc dot gnu dot org 2007-10-28 19:10
> ---
> Compared to
--- Comment #4 from burnus at gcc dot gnu dot org 2007-10-28 19:57 ---
See also:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/2eea7b997482aa5e/
The answers decides whether
http://gcc.gnu.org/ml/fortran/2007-10/msg00362.html
or
http://gcc.gnu.org/ml/fortran/2
--- Comment #16 from jakub at gcc dot gnu dot org 2007-10-28 19:42 ---
Haven't analyzed why exactly there are so many more safe_group_barrier_needed
calls, but they are certainly much more common than direct group_barrier_needed
calls on this testcase (14579701 safe_group_barrier_needed
The following test program results in the following error:
#include
int
main ()
{
return 0;
}
-bash-3.2$ /opt/gnu/gcc/gcc-4.2.2/bin/gcc -S -O2 sinfo.c
In file included from sinfo.c:1:
/usr/include/sys/sysinfo.h:180: error: array type has incomplete element type
The offending line is:
extern
--- Comment #3 from stsp at users dot sourceforge dot net 2007-10-28 19:25
---
Ohh... thanks for taking a look.
But is it documented anywhere that the
inline asm _must_ specify the section?
I thought the asm code, as well as the
C code, will utilize the .text, unless
the opposite is spe
--- Comment #9 from hubicka at gcc dot gnu dot org 2007-10-28 19:17 ---
Mine
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #15 from jakub at gcc dot gnu dot org 2007-10-28 19:10 ---
Compared to 20070803 with -O3 -fno-tree-vectorize there are now 100 times more
calls to rtx_needs_barrier and 44 times more calls to
safe_group_barrier_needed.
E.g. the latter is horribly expensive, e.g. copying aroun
--- Comment #5 from hubicka at gcc dot gnu dot org 2007-10-28 19:09 ---
Mine, it is another example of EH updating problem. I will try to add "may" EH
edges pre-inlniing to avoid need to call mark_sym_for_renaming in inliner
completely.
--
hubicka at gcc dot gnu dot org changed:
--- Comment #14 from tobi at gcc dot gnu dot org 2007-10-28 19:08 ---
Closing. Wolfgang, if you still see similar problems please open a new PR and
CC me.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-28 18:59 ---
Your inline-asm is incorrect as you did not place the symbol in any section so
it just defaults to what ever section is currently there (which in the -g3 case
is the debugging section).
This corrects the issue:
asm
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-10-28 18:57 ---
mark_sym_for_renaming really needs some checking code for this. Or
mark_sym_for_renaming needs to properly go out-of-ssa for the symbol (in the
case of inlining separately so for the caller and the callee).
--
r
--- Comment #1 from stsp at users dot sourceforge dot net 2007-10-28 18:55
---
Created an attachment (id=14428)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14428&action=view)
the test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
--- Comment #13 from tobi at gcc dot gnu dot org 2007-10-28 18:53 ---
Subject: Bug 32147
Author: tobi
Date: Sun Oct 28 18:53:27 2007
New Revision: 129701
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129701
Log:
fortran/
PR fortran/32147
* module.c (write_symbol): Fix whitespac
The following test program will
print "OK" if compiled without -g3
(-g1, -g2 are fine), and Segfaults
with -g3.
---
#include
asm (
"__tst:\n"
"movl $1, %eax\n"
"ret\n");
int tst(void) asm ("__tst");
int main()
{
if (tst() == 1)
printf("OK\n");
else
printf("Segmentation f
--- Comment #4 from rguenther at suse dot de 2007-10-28 18:01 ---
Subject: Re: [4.3 Regression] ICE: tree check:
expected ssa_name, have struct_field_tag in is_old_name, at
tree-into-ssa.c:566
On Sun, 28 Oct 2007, pinskia at gcc dot gnu dot org wrote:
> --- Comment #3 from pinski
--- Comment #9 from rask at gcc dot gnu dot org 2007-10-28 17:48 ---
I just tried with only the alloca patch, and despite the unsplit insn-attrtab.c
file, process size tops at just 205 MB. It looks like GCC 4.3.0 is in a much
better shape than GCC 4.1.1, so I'm letting go of the bug.
Ju
--- Comment #7 from ubizjak at gmail dot com 2007-10-28 17:41 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-10-28 17:38 ---
Before PRE/may_alias:
# VUSE
D.1269_159 = *n_158(D);
After:
# VUSE { SFT.151 SFT.154 MPT.253 }
D.1269_159 = *n_158(D);
HUH *n cannot alias anything really as it is argument to the function.
We have the
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-10-28 17:01 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-10-28 17:01 ---
Subject: Bug 33589
Author: pinskia
Date: Sun Oct 28 17:00:54 2007
New Revision: 129700
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129700
Log:
2007-10-28 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- Comment #4 from hjl at lucon dot org 2007-10-28 16:48 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|UNCONFIRMED |
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-10-28 16:39
---
So, confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-10-28 16:38 ---
The main difference I see is that 4.2 avoids re-use of %eax as index register:
.L34:
movq%r11, %rdi
addq8(%r10), %rdi
movq8(%r10), %rsi
movq8(%r10), %rdx
movq
--- Comment #16 from mikulas at artax dot karlin dot mff dot cuni dot cz
2007-10-28 16:09 ---
Subject: Re: Gcc can't be compiled with -mregparm=3
> arguments the function receives. We have gen_* functions taking 0, 1, 2, 3,
> ...
> arguments and with GCC being designed the way it is,
--- Comment #8 from lucier at math dot purdue dot edu 2007-10-28 16:08
---
Subject: Re: 33% performance slowdown from 4.2.2 to 4.3.0 in floating-point
code
On Oct 28, 2007, at 8:05 AM, rguenth at gcc dot gnu dot org wrote:
> --- Comment #2 from rguenth at gcc dot gnu dot org 20
--- Comment #7 from lucier at math dot purdue dot edu 2007-10-28 16:05
---
time with -O2 instead of -O1:
with 4.2.2:
(time (direct-fft-recursive-4 a table))
426 ms real time
426 ms cpu time (425 user, 1 system)
no collections
64 bytes allocated
no minor faults
--- Comment #15 from rask at gcc dot gnu dot org 2007-10-28 15:54 ---
In reply to comment #14:
> is your patch supposed to help with testcase presented in comment #6?
No, it's aimed at the problem from the description. That is, GCC itself doesn't
work if compiled with a compiler where
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #1 from jakub at gcc dot gnu dot org 2007-10-28 15:47 ---
Created an attachment (id=14427)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14427&action=view)
gcc43-pr33765.patch
In this case (and e.g. also in case where you gcj -c package-info.java
from #297961) ecj1 cre
--- Comment #6 from lucier at math dot purdue dot edu 2007-10-28 15:45
---
Created an attachment (id=14426)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14426&action=view)
assembly after replacing -O1 with -O2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #5 from lucier at math dot purdue dot edu 2007-10-28 15:45
---
Created an attachment (id=14425)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14425&action=view)
assembly after replacing -O1 with -O2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #4 from lucier at math dot purdue dot edu 2007-10-28 15:42
---
Created an attachment (id=14424)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14424&action=view)
assembly from 4.3.0
I had to remove the "static" from the declaration of direct-fft-recursive to
get assemb
--- Comment #3 from lucier at math dot purdue dot edu 2007-10-28 15:41
---
Created an attachment (id=14423)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14423&action=view)
Assembly from 4.2.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #2 from pcarlini at suse dot de 2007-10-28 15:39 ---
Certainly can't be a regression. And certainly both overloads are present in
the most recent specifications (n2369). Doug, any chance you can comment on
this? I tend to consider this code invalid...
--
pcarlini at suse
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-28 15:38 ---
Failure appeared in the last two days.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-28 15:37 ---
Created an attachment (id=14422)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14422&action=view)
testcase
Auto-reduced testcase from 189.lucas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33931
./f951 -quiet -O3 lucas_distrib_spec.min.f90 -w
lucas_distrib_spec.min.f90: In function 'fft_square':
lucas_distrib_spec.min.f90:61: internal compiler error: tree check: expected
ssa_name, have struct_field_tag in is_old_name, at tree-into-ssa.c:566
Please submit a full bug report,
with preprocesse
--- Comment #4 from charlet at gcc dot gnu dot org 2007-10-28 15:34 ---
Marking this bug as fixed in 4.3
When you send a bug report, please try to reduce it to a simple gcc command
(and if possible with few sources showing the problem).
Having to deal with a large tarball and gnatmake
--- Comment #2 from pcarlini at suse dot de 2007-10-28 15:29 ---
Doesn't happen anymore, as expected.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from danglin at gcc dot gnu dot org 2007-10-28 15:28 ---
Changed my mind about my last comment. The new constructor priority
attribute breaks the previous C++ init_priority handling using collect2.
With respect to initpr1.c, it can be seen that only one "GLOBAL" construc
--- Comment #1 from a dot chavasse at gmail dot com 2007-10-28 15:22
---
(by --std=cxx0x I of course meant --std=c++0x)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33930
g++43 -v:
Using built-in specs.Target: x86_64-unknown-linux-gnuConfigured with:
../gcc/configure --program-suffix=43 --disable-multilib
--enable-languages=c,c++Thread model: posixgcc version 4.3.0 20071028
(experimental) (GCC)
(it was built from svn trunk, revision 129693)
Not sure whether it
--- Comment #6 from uros at gcc dot gnu dot org 2007-10-28 14:58 ---
Subject: Bug 33920
Author: uros
Date: Sun Oct 28 14:57:50 2007
New Revision: 129696
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129696
Log:
PR tree-optimization/33920
* tree-if-conv.c (tree_i
--- Comment #3 from dsauvage at altern dot org 2007-10-28 14:49 ---
Thanks for your rapid reply,
My first desire was to stick to my distrib Ubuntu/Debian packages, but those
bugs are blocking for me so i'm now working with GNAT GPL Edition 2007.
Is it useful for the GNAT packages maint
--- Comment #14 from sam at rfc1149 dot net 2007-10-28 14:42 ---
Rask,
is your patch supposed to help with testcase presented in comment #6? It looks
like I still get "f" waiting (as expected) for arguments in registers when I
use -mregparm=3 while the call through g still uses the stac
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-10-28 14:24
---
Some more COMMON problems here:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01685.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from rask at gcc dot gnu dot org 2007-10-28 14:02 ---
In reply to comment #7:
> I need it to build GCC with OpenWatcom, which wants parameters on the stack
> by default.
Er, that's in registers by default, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #12 from rask at gcc dot gnu dot org 2007-10-28 14:00 ---
In reply to comment #11:
> How many times do I have to say this is bad for most RISC targets (hosts)?
I don't particularily care how many times you say it. Show some code (which
works) and/or show some timings (of cod
--- Comment #8 from rask at gcc dot gnu dot org 2007-10-28 12:57 ---
Created an attachment (id=14421)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14421&action=view)
split insn-attrtab.c into three files
Here's the patch to split insn-attrtab.c into smaller pieces. The result:
$
--- Comment #7 from rask at gcc dot gnu dot org 2007-10-28 12:40 ---
Created an attachment (id=14420)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14420&action=view)
Reenable alloca() on non-GCC compilers
The memory fragmentation problem is to be caused by libiberty which disable
../../xgcc -B../../ -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -fno-common -gnatpg -gnata -I- -I../rts -I.
-I/home/sam/Dev/gcc/gcc/ada /home/sam/Dev/gcc/gcc/ada/uintp.adb -o uintp.o
/home/sam/Dev/gcc/gcc/ada/uintp.adb: In function Uintp.Ui_Div_Rem:
/home/sam/
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-28 12:05 ---
Can you attach assembler files? What happens if you use -O2? Why do you need
-fno-strict-aliasing? Does -fno-ivopts help?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #11 from pinskia at gmail dot com 2007-10-28 11:57 ---
Subject: Re: Gcc can't be compiled with -mregparm=3
On 28 Oct 2007 11:14:37 -, rask at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
How many times do I have to say this is bad for most RISC targets (hosts)?
Real
On 28 Oct 2007 11:14:37 -, rask at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
How many times do I have to say this is bad for most RISC targets (hosts)?
Really if the type being is used is wrong, they should be changed
rather than changing to use var-args.
-- Pinski
--- Comment #4 from rsandifo at gcc dot gnu dot org 2007-10-28 11:23
---
Sorry, my fault. The problem doesn't occur with recent binutils,
which is why David and I hadn't see it.
Fix now applied.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from rsandifo at gcc dot gnu dot org 2007-10-28 11:19
---
Subject: Bug 33895
Author: rsandifo
Date: Sun Oct 28 11:19:49 2007
New Revision: 129694
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129694
Log:
gcc/
PR target/33895
* config/mips/mips.c
--- Comment #10 from rask at gcc dot gnu dot org 2007-10-28 11:14 ---
Created an attachment (id=14419)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14419&action=view)
patch v2, i386 fix added
--
rask at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pcarlini at suse dot de 2007-10-28 09:53 ---
Cout & co by default aren't converting streams, they are synced char-by-char
with stdio, therefore cannot be expected to work with UTF-8 in any meaningful
way. If you call sync_with_stdio(false) at the beginning of your pro
90 matches
Mail list logo
