--- Additional Comments From sanjivkumargupta at yahoo dot com 2004-10-19 06:06
---
Anyways, Kaz's method of determining pressure on R0 looks
more correct than what I had written. So, I think we
should keep his patch besides waiting for a fix in lcm.c
Thanks
--Sanjiv
--
--- Additional Comments From bkoz at redhat dot com 2004-10-19 06:23 ---
Subject: Re: dependent expressions in attributes
Yes, but how do you force the compiler to ensure that the alignment of char foo
[] is sufficient to placement-allocate an object of type T into it?
...get
--
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2004-10-18 14:06:18 |2004-10-19 07:35:57
date|
--- Additional Comments From bonzini at gcc dot gnu dot org 2004-10-19 07:42
---
The fix is obvious, I misordered the two precedence in enum cp_parser_prec.
I'll commit it and add a testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18047
struct A
{
// ...
B* operator();
operator B() const;
};
__gnu_cxx::hash_setA stores values of B, the return type of operator(). It
should store values of A as the similar hash_mapA,bool does.
The following example shows the effect. hash_set doesn't use copy constructor
of A,
This no-op code fails to link when compiled with optimizations enabled.
Trivial code fails with -O3, a bit more complex code will fail with -O[12] .
(Both examples are given below)
$ cat tO3.cpp
#include sstream
int main()
{
std::stringstream name;
name std::endl;
}
$
--- Additional Comments From pcarlini at suse dot de 2004-10-19 09:10 ---
This problem is the same reported here:
http://gcc.gnu.org/ml/libstdc++/2004-09/msg00125.html
that nobody could reproduce on up to date setups (Jonathan included!). Could
you perhaps investigate further along
Environment : i686-pc-linux-gnu
Compiler Version: GCC 3.3.2
Kernel Version : 2.4.7-10
It seems, not possible to specialize a template member functions const. I got a
file(.impl) which got the following template functions( generalized and
specialized template functions ) and i got the
Environment : i686-pc-linux-gnu
Compiler Version: GCC 3.3.2
Kernel Version : 2.4.7-10
It seems, not possible to specialize a template member functions const. I got a
file(.impl) which got the following template functions( generalized and
specialized template functions ) and i got the
--- Additional Comments From uros at kss-loka dot si 2004-10-19 09:55 ---
Testcase from comment #9 and '-O2 -msse -fomit-frame-pointer' procduces code
that seems OK:
prepare:
pushl %ebp
pushl %edi
movl $hmag+512, %edi
pushl %esi
movl
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr 2004-10-19
10:03 ---
Subject: Re: [4.0 Regression] ICE with simple loop with VLA
Patch is here:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01592.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18005
--- Additional Comments From veksler at il dot ibm dot com 2004-10-19 11:01
---
Yes, I do get the same errors as reported in
http://gcc.gnu.org/ml/libstdc++/2004-09/msg00125.html
Here is the offending symbol:
$ nm --demangle /home/veksler/gcc-4.0-20041017/lib/libstdc++.so | grep
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-19 11:06
---
Same problem on amd64-*-* where the 32-bit libiberty.a is in $(PREFIX)/lib/32.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 11:27
---
*** Bug 18056 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18055
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 11:27
---
*** This bug has been marked as a duplicate of 18055 ***
*** This bug has been marked as a duplicate of 18055 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 11:27
---
Can you attach the preprocessed source?
--
What|Removed |Added
CC|
--
What|Removed |Added
Component|c++ |libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18053
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 11:35
---
$ ../gcc-4.0-20041017.src/configure --prefix=/home/veksler/gcc-4.0-20041017
--enable-languages=c++
Can you try with --enable-__cxa_atexit ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18054
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 11:37
---
Unsetting the target milestone as there is a stil opened DR about this.
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2004-10-19 11:42
---
So, Eric, it looks like that adding -fomit-frame-pointer to your Makefile is a
good workaround for the time being without losing any advanced optimization.
You were looking for one, IIRC.
--
--- Additional Comments From giovannibajo at libero dot it 2004-10-19 11:46
---
I fixed a similar bug in 4.0 already, but we can't really tell until either you
try for yourself or attacch a preprocessed file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18055
--- Additional Comments From pcarlini at suse dot de 2004-10-19 12:08 ---
More about this issue later, only two quick remarks:
1- Current mainline doesn't even compile the testcase, due to type mismatches
in the allocator caused by the overloaded operators.
2- In any case, it's unlikely
With the latest version bootstrapped on PC debian:
$ /home/etienne/projet/toolchain/bin/gcc -v
Reading specs from /home/etienne/projet/toolchain/lib/gcc/i686-pc-linux-
gnu/4.0.0/specs
Configured with: ../configure --prefix=/home/etienne/projet/toolchain --enable-
languages=c
Thread model: posix
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-19 12:40
---
Subject: Bug 18047
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-19 12:40:32
Modified files:
gcc/cp : ChangeLog parser.c
--- Additional Comments From bonzini at gcc dot gnu dot org 2004-10-19 12:43
---
Fixed by the above patch.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From etienne_lorrain at yahoo dot fr 2004-10-19 12:47
---
Well, sometimes you are sure the field is 8 bits wide,
limit_msb is only 4 bits unlike base_msb.
A value does not fit the size would be better, but ...
Sorry,
Etienne.
--
What
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 12:51
---
I also cannot reproduce it:
GNU C++ version 4.0.0 20041018 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.0.0 20041018 (experimental).
GNU assembler version 2.15.90.0.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 12:54
---
Here is how I configured my GCC:
Configured with: /home/gates/pinskia/src/gnu/gcc/src/configure
--target=i686-pc-linux-gnu --
host=i686-pc-linux-gnu --enable-__cxa_atexit --enable-languages=c++,objc,java
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 12:57
---
Removing the target milestone because the DR is questionable.
--
What|Removed |Added
The error message is:
cc -erroff -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC
-DHAVE_CONFIG_H -DGENERATOR_FILE-I. -Ibuild -I/home/eric/cvs/gcc/gcc
-I/home/eric/cvs/gcc/gcc/build -I/home/eric/cvs/gcc/gcc/../include -I./../intl
-I/home/eric/cvs/gcc/gcc/../libcpp/include
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 13:05
---
For the bitmap problem, the header comes in from basic-block.h via regs.h.
Maybe we should have #ifndef BUILD (or what ever is the macro).
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 13:06
---
The vec problem might be the same issue. I will look into it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18058
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 13:26
---
Created an attachment (id=7377)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7377action=view)
patch which should fix this
This works for me, at least with -fkeep-inline-functions.
Can you try it and
--- Additional Comments From veksler at il dot ibm dot com 2004-10-19 13:32
---
Subject: Re: Undefined reference to ~basic_iostream(), with -O[12]
To summarize the difference between our setups:
My setup (that fails):
- binutils-2.14.90.0.4-35
- No special configure --enable flags
--- Additional Comments From pcarlini at suse dot de 2004-10-19 13:39 ---
By the way, --enable-__cxa_atexit is most certainly *not* involved, since many
people test daily without passing it and everything is fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18054
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-19 13:53
---
Just for the record: I can reproduce the problem with gcc-4.0-20041019
on i686-pc-linux-gnu, configured with: --enable-threads --enable-checking
Enabling __cxa_atexit or not does not make a difference
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 13:58
---
Maybe this is a binutils bug:
tin:~nm --demangle ~/linux/lib/libstdc++.so.6.0.3 | grep 'char.*~basic_iostream' |
grep -v thunk
0005d090 W std::basic_iostreamchar, std::char_traitschar ::~basic_iostream()
I (may be being naive, but at least with good intensions ;-) )
would like to consider this as a problem (bug ?) - in two areas:
1) Gnu gcc area:
a) At best - Gnu ggc folks need to attempt to overall improve (minimize)
memory consumption
for 3.3.x and 3.4.x gcc builds
b) Less
--- Additional Comments From pcarlini at suse dot de 2004-10-19 14:03 ---
Yes, I'm also tempted to think it's a binutils bug (not so frequent on x86! ;)
People (libstdc++-v3 developers) using current binutils, 2.15 series, never report
it, apparently.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 14:05
---
Just a note, my binutils is from FC2:
tin:~/src/gnu/gcctestrpm -q binutils
binutils-2.15.90.0.3-5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18054
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-19 15:03
---
The file still takes a few minutes to compile but the situation has improved
since all the gnattools build for me as of today, both on sparc-sun-solaris2.8
and i586-mandrake-linux-gnu, whereas they
--- Additional Comments From coyote at coyotegulch dot com 2004-10-19 15:24
---
(In reply to comment #2)
gfortran is missing 87 non-standard intrinsic functions and subroutines
from g77 runtime library. I'll post the complete to fortran@ this weekend.
Was that list ever posted?
And
c-common.c contains
void c_parse_error (const char *msgid, enum cpp_ttype token, tree value)
which purports to format msgid, however, it contains things like,
error (%s at end of input, string);
thus any magic % in MSGID do not get munged. Resulting in,
error: expected %,% or %...% before
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 15:56
---
*** This bug has been marked as a duplicate of 17852 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 15:56
---
*** Bug 18059 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
I've read that you do not consider proper reporting bugs about rounding, but I
have a program compiled in a RH62 with egcs that works fine and the same program
compiled in RH73 with gcc making trouble.
Simple code line:
char aux[50];
char aux2[50];
sprintf(aux,%.0f,2068.5);
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 16:30
---
Not a GCC bug, if it is a bug, it is a bug in glibc and not gcc.
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-19 16:38
---
Really looks like a binutils bug.
I just installed plain 2.14 and 2.15 binutils and bootstrapped the compiler
with --enable-languages=c++.
With binutils 2.14 I get the linker failures.
With 2.15 the
--- Additional Comments From matz at suse dot de 2004-10-19 16:46 ---
Does this go away with --param iv-consider-all-candidates-bound=70 ?
(Or with a higher number like 100 or 1000)
--
What|Removed |Added
When I compile this sample (g++ main.cpp -o main)
g++ says that A_val is not defined !
It uses to work with g++ version 3.4
A.hpp
template typename Var
class A
{
public:
double getA() {return A_val;}
protected:
double
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 16:48
---
Invalid, did you read the release notes?
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-19 16:48
---
Reverting the parse.y changes doesn't help. The problem is that the inline
methods defined in java/lang/class.h are not emitted in natClass.o, despite the
presence of
#pragma implementation Class.h
at
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 16:51
---
That sounds like C++ bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17265
This is a sample of build command and its verbose output with GCC 4.0.0. There
is -I/home/4/wilx/include on the command line. Notice the ordering of include
paths int its output:
[EMAIL PROTECTED]:::~/tmp/gcc-head/objdir/gcc gcc -v -c -g -DENABLE_CHECKING
-DENABLE_ASSERT_CHECKING -DIN_GCC -W
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 16:57
---
Not a bug, since /home/4/wilx is a prefix , /home/4/wilx/include is always included
after the user
includes even though you aupply it on the command line. The bug was 2.8.x which
cannot be changed
and
The following code compiles and runs, but shouldn't, because the size of
structure a overflows size_t type. Overflowed size is checked for arrays, for
global and local variables, but not for structures.
struct a {
char x[0x7fff];
char b[0x7fff];
char c[3];
};
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-19 17:24
---
Subject: Bug 17885
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-19 17:24:48
Modified files:
gcc: ChangeLog tree.c
Log message:
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 17:25
---
On the mainline we warn:
t68.c:9: warning: integer overflow in expression
So maybe this can be considered fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18063
--- Additional Comments From jsm at polyomino dot org dot uk 2004-10-19 17:28
---
Subject: Re: Re: [Bug c/18059] New: bad diagnostic formatting
On Tue, 19 Oct 2004, nathan at gcc dot gnu dot org wrote:
c-common.c contains
void c_parse_error (const char *msgid, enum cpp_ttype
--- Additional Comments From mikulas at artax dot karlin dot mff dot cuni dot cz
2004-10-19 17:32 ---
Subject: Re: Gcc doesn't check overflowed size of structure
If you rewrite it to
int main(void)
{
size_t c = sizeof(struct a);
struct a *b = malloc(c);
return
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-19 18:03
---
Can you try it and see if it works for you?
Like a charm :-) Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18058
--- Additional Comments From davidm at hpl dot hp dot com 2004-10-19 18:08 ---
(In reply to comment #2)
Subject: Re: New: bad unwind info due to multiple
returns (missing epilogue)
On Fri, 2004-10-15 at 04:14, davidm at hpl dot hp dot com wrote:
To fix this bug, GCC should be
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 18:26
---
Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01615.html.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 18:30
---
Note if you make a global variable of the struct we do error out.
--
What|Removed |Added
--- Additional Comments From coyote at coyotegulch dot com 2004-10-19 18:49
---
Posted a slightly revised patch, ten months after the first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13490
--- Additional Comments From coyote at coyotegulch dot com 2004-10-19 18:54
---
I've posted an update to the original asymmetric integers patch, but it did
not address this specific PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17912
--- Additional Comments From pcarlini at suse dot de 2004-10-19 19:07 ---
In principle, requiring 2.15 and updating the docs seems ok: by the time 4.0.0
will be out, 2.15 (in its various incarnations) will we rather common. However,
I'm puzzled that nobody noticed this bug til now, I
--- Additional Comments From coyote at coyotegulch dot com 2004-10-19 19:06
---
Correction: My patch does fix this bug. See:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01613.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17912
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 19:15
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01613.html.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-19 19:15
---
Subject: Bug 17962
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-19 19:15:32
Modified files:
gcc: ChangeLog stor-layout.c
Log
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-19 19:21
---
Subject: Bug 17962
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-19 19:21:42
Added files:
gcc/testsuite/gcc.dg: align-2.c
Log message:
--- Additional Comments From rth at gcc dot gnu dot org 2004-10-19 19:22 ---
Fixed.
--
What|Removed |Added
Status|WAITING |RESOLVED
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-19 19:25
---
Yes, this fixes the problems. Thanks! Two-process fixincludes now builds.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991
We've been developing an app under gcc-3.4, and
were pleased with how strictly gcc-3.4 enforced
the C++ standard :-)
But in porting to another compiler, we discovered
that gcc had let us use a nonportable construct:
Types like void*, int*, and float* are not covariant,
but gcc happily lets
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 19:35
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From law at redhat dot com 2004-10-19 20:16 ---
Subject: Re: Missed jump threading
optimization
On Mon, 2004-10-18 at 16:50, stevenb at suse dot de wrote:
--- Additional Comments From stevenb at suse dot de 2004-10-18 22:50 ---
Subject: Re:
Overall, the major problem is that the lhs operand object type, or most
optimal compatible type in the case of immedite operands, is not being
used to correcly select builtin functions; which is fairly important for
a compiler for 8-bit target to get right; where (u)divmod(q/h)i4 signed and
--- Additional Comments From schlie at comcast dot net 2004-10-19 20:27 ---
Created an attachment (id=7378)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7378action=view)
main.c (with embedded commented out main.lss and makefile)
--
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-19 20:31
---
At least 2.14 is not uncommon, SuSE 9.0 is affected for example.
So there are lots of people out there who will run into trouble. :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18054
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 20:39
---
char ss = s % s ; //__divmodhi4 wrong, should be 8-bit __divmodqi4
This is not wrong as we sign extend the arguments as required by the C standard (to
int).
So this is just an missed-optimization.
--
--- Additional Comments From veksler at il dot ibm dot com 2004-10-19 20:53
---
Subject: Re: Undefined reference to ~basic_iostream(), with -O[12]
I also think that 2.14 is not uncommon. RHEL-3 is also affected.
If this is fixed, I'll continue my efforts to evaluate gcc-4.0 (and
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 20:59
---
Fixed on the mainline, the resulting code for the two functions are the same now.
--
What|Removed |Added
--- Additional Comments From schlie at comcast dot net 2004-10-19 21:18 ---
Subject: Re: wrong built-in functions selected
Nope, please look at the coded examples:
- they demonstrate that:
(signed char) % (signed char) = invokes (int) % (int), not correct.
- and the compiler
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-10-19 21:25
---
I see this too. Or rather, I see what Michael is describing. Should there be a
new bug for the problem as described by Michael? My test scenario was from
desire to build 64-bit biarch compiler that
--- Additional Comments From schlie at comcast dot net 2004-10-19 21:31 ---
Subject: Re: wrong built-in functions selected
As of course otherwise then, what's the purpose of s/u 8-bit / and %
built-in functions, if not to enable their use when all the operands are
type compatible,
Hello,
I recently installed Fedora Core 2 (everything), downloaded and attempted to
build GtkAda-2.2.1. The build fails during compilation of one of the ada files.
Here's the snippet of text from near the occurrence of error:
snip
gcc -c -I../ -O2 -gnatn -gnatws -fPIC -I- ../gtk-viewport.adb
gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 21:39
---
I don't know but as I said this is correct code and not a wrong code problem but just
a missed
optimization somewhere.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 21:41
---
*** This bug has been marked as a duplicate of 13016 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 21:41
---
*** Bug 18066 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From schlie at comcast dot net 2004-10-19 21:53 ---
Subject: Re: not using qi version of divmod
I agree that the missed optimizations won't produce incorrect results, just
very inefficient ones. As all rhs argument optimizations seem to be properly
identified,
--- Additional Comments From ericw at evcohs dot com 2004-10-19 22:08 ---
Bug #10733 is related.
--
What|Removed |Added
CC||ericw
--- Additional Comments From schlie at comcast dot net 2004-10-19 22:31 ---
Subject: Re: not using qi version of divmod
Hi Eric,
Out of curiosity, what exactly is the 10733 bug, is wrong result computed?
If so, that implies that divmodhi is broken; otherwise it's not a bug, as
the
While compiling snow.c from ffmpeg loc_descriptor_from_tree_1 segfaults.
Here is the stack trace:
#0 fancy_abort (file=0x1048ec30 /home/jim/cvs/gcc.head/gcc/gcc/dwarf2out.c,
line=9190, function=0x105e5e98 loc_descriptor_from_tree_1)
at /home/jim/cvs/gcc.head/gcc/gcc/diagnostic.c:556
#1
--- Additional Comments From phython at gcc dot gnu dot org 2004-10-19 23:05
---
Created an attachment (id=7379)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7379action=view)
preprocessed source for snow.c
Compile with -O1 -g
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 23:12
---
Might be related to PR 14900 or 17076 but I cannot reproduce this on powerpc-darwin
(even after
supplying -gdwarf-2 since dwarf-2 is not default).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18067
--- Additional Comments From ericw at evcohs dot com 2004-10-19 23:13 ---
Subject: Re: not using qi version of divmod
schlie at comcast dot net wrote:
--- Additional Comments From schlie at comcast dot net 2004-10-19 22:31 ---
Subject: Re: not using qi version of divmod
Hi
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 23:14
---
I can produce with a cross to i686-pc-linux, reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18067
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-10-19 23:30
---
Fixed in GCC 4.0.
Will not be fixed in GCC 3.4.x.
--
What|Removed |Added
--
What|Removed |Added
Target Milestone|3.4.3 |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14035
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-19 23:43
---
Here is the reduced testcase:
typedef unsigned int size_t;
extern void *memcpy (void *__restrict __dest,
__const void *__restrict __src, size_t __n) ;
int encode_q_branch(int level, unsigned char
1 - 100 of 115 matches
Mail list logo
