Hi,
Thanks a lot,
My doubt has been cleared.
Could you please let me know the release date of gcc-4.1.
Thanks in advance.
Nitin Shah.
KPIT Cummins InfoSystems Ltd.
Pune, India
Free download of GNU based tool-chains for Renesas'
Bootstrapping on sparc linux fails for me (revision 108129M)
gcc -m32 -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -fno-common
-DHAVE_CONFIG_H -I. -I. -I../../gcc.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
ZengNan wrote:
> A tool developed by Indian Institute of Technology Kanpur, which takes
> architecture description
> represented using Sim-nML as input and generates GCC md as output. I have
> been searching for
> source code of this tool. Anyone who
Nitin Shah wrote:
Hi,
I am building toolchain for Renesas SH, H8300 and M32C targets for ELF
format (i.e. sh-elf, h8300-elf, m32c-elf respectively) using the below
mentioned sources,
Binutils-051107
GCC-4.1-20051107
Newlib-dated 051114 from CVS
Host: i686-pc-linux-gnu
I am getting the below me
> I am able to build gcc-4.0.0 successfully without making any changes in
> the source.
Right, but you're comparing a release to a snapshot. Snapshots are
cut straight from source control, releases are partially built so that
generated files don't have to be generated.
Hi,
bison has been already installed and once I give the command,
bison --version it shows,
bison (GNU Bison) 1.35
Copyright 1984, 1986, 1989, 1992, 2000, 2001, 2002
Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for
On Dec 6, 2005, at 5:25 PM, Andreas Killaitis wrote:
Obviously I've been expressing me not very clear. I don't care for
code size (well, at least not soo much), speed is what counts, and
speed is what I get. I was just wondering why the code size has
increased with the new gcc version. An in
A tool developed by Indian Institute of Technology Kanpur, which takes
architecture description
represented using Sim-nML as input and generates GCC md as output. I have been
searching for
source code of this tool. Anyone who has the source code, please send me a copy.
__
Am 07.12.2005 um 02:14 schrieb Mike Stump:
On Dec 6, 2005, at 4:35 PM, Andreas Killaitis wrote:
-finline-limit-10
This and wanting a small size are kinda incompatible. There might
be smaller values of n that will shrink the code, and yet still
give you the performance you seem to wa
On Dec 6, 2005, at 4:35 PM, Andreas Killaitis wrote:
-finline-limit-10
This and wanting a small size are kinda incompatible. There might be
smaller values of n that will shrink the code, and yet still give you
the performance you seem to want.
Andreas Killaitis <[EMAIL PROTECTED]> wrote:
> I was now astonished
> that my tests with gcc 4.1 showed that the library size has been
> grown by about 10%.
> The used compile options are:
>
> [...]
> -O3
Don't expect GCC to optimize code size at -O3. -O3 means -O2 *and* inline as
much as it ma
Hello list,
I have a question concerning the size of the code generated by gcc
4.0.2 and 4.1.
We talk about a C++ app with many smaller (30k) or larger (4M) C++
libraries.
Being happy the size of those libs decreased by about 20% when
switching from
gcc 3.4.4 to gcc 4.0.2 (introducing --vis
On Dec 6, 2005, at 4:35 PM, Rafael Ávila de Espíndola wrote:
On Tuesday 06 December 2005 19:19, Chris Lattner wrote:
This version of the patch has many bugs fixed and several rough
corners rounded off (for example, there are no more hard coded paths
in the makefiles anymore, and the llvm-indepen
On Tuesday 06 December 2005 19:19, Chris Lattner wrote:
> This version of the patch has many bugs fixed and several rough
> corners rounded off (for example, there are no more hard coded paths
> in the makefiles anymore, and the llvm-independent objc changes are
> now in the apple branch inst
When I compile this using gcc rev 3.4.5 (m68k-elf):
struct A { charB;
unsigned char & C; } __attribute__((packed));
unsigned char D;
A E = { 'F', D };
I get:
testpp.cpp:2: warning: ignoring packed attribute on unpacked non-POD
field `unsigned char&A::C'
sizeof( E ) == 6
Snapshot gcc-3.4-20051206 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20051206/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Mark Mitchell wrote:
That message contains an IEEE floating-point emulation library, like
fp-bit.c. Howeve, the performance is considerably better; Joseph
measured against fp-bit.c with a modern compiler, and ieeelib.c is about
10-15% better than the current code on EEMBC on a PowerPC 440.
For
Volker Reichelt <[EMAIL PROTECTED]> writes:
| The C++ parser contains the static function
| cp_parser_declarator_id (cp_parser* parser)
| which consists of a lot of comments and a single statement
|
| return cp_parser_id_expression (parser,
| /*template_keywo
> Date: Tue, 06 Dec 2005 18:02:51 +0100
> From: "Jan Beulich" <[EMAIL PROTECTED]>
> >2005-12-01 Hans-Peter Nilsson <[EMAIL PROTECTED]>
> >
> > * gcc.dg/20041106-1.c, gcc.dg/20030321-1.c, gcc.dg/pr17112-1.c,
> > gcc.dg/pr17112-1.c, g++.dg/other/packed1.C,
> > g++.dg/other/crash-4.C, g
The C++ parser contains the static function
cp_parser_declarator_id (cp_parser* parser)
which consists of a lot of comments and a single statement
return cp_parser_id_expression (parser,
/*template_keyword_p=*/false,
/*check_d
The best way to get noticed and the problem fixed is to open a PR in GCC
Bugzilla: http://gcc.gnu.org/bugzilla/
VH
signature.asc
Description: OpenPGP digital signature
Hi,
> > Any chances that the GCC Internals documentation will be updated any
> > time soon? http://gcc.gnu.org/onlinedocs/gccint/
> It looks pretty current to me.
Hmm... there're 30 FIXMEs and the section on C trees is missing:
Macros-and-Functions.html:57:This section is not here yet.
It would
FYI:
After the 4.1 branch was created there appears to be no way to navigate to:
http://gcc.gnu.org/gcc-4.1/changes.html
from the gcc.gnu.org home page. Navigation to changes.html for all
other versions (except 4.1) is possible.
David Daney.
> "Ranjit" == Ranjit Mathew <[EMAIL PROTECTED]> writes:
Ranjit> BTW Tom, the Red Hat bugzilla doesn't let me see the
Ranjit> bug #174912, even after logging in. It might probably be
Ranjit> a better idea to open a PR in GCC's bugzilla describing
Ranjit> the problem. That said, the testcase you
On Tuesday 06 December 2005 18:10, Diego Novillo wrote:
>
> Yes, they're collectively pretty clueless. However, in the midst of
> that /. interchange I did see one posting that made a relatively good
> point: If you go to gcc.gnu.org, you will see "Current release series:
> GCC 4.1.0".
>
> For the
Eric Fisher <[EMAIL PROTECTED]> writes:
> Firstly, shall I support it in the machine.md file, or just leave it to
> libgcc?
> Dose the libgcc support it if I don't implement in the machine.md file?
Yes, if you supply SImode operations, libgcc will give you some DImode
operations, and the others
> "Andreas" == Andreas Jaeger <[EMAIL PROTECTED]> writes:
Andreas>=== libjava Summary for unix ===
Andreas> # of expected passes1811
Andreas> # of unexpected failures1087
Andreas> # of expected failures 6
Andreas> # of untested testcases 109
This is just to let you know that the gcc-prs mailing list archives seem
to fail since June, 2004. Everything since then gives empty archives. If
the list is closed (probably subsumed by bugzilla), maybe the best is to
freeze the archive
http://gcc.gnu.org/ml/gcc-prs/
Theo.
On Tuesday 06 December 2005 13:00, Andrew Haley wrote:
> ... thereby maintaining the reputation for accuracy for which Slashdot
> is justly famous.
>
Yes, they're collectively pretty clueless. However, in the midst of
that /. interchange I did see one posting that made a relatively good
point:
Jim Wilson writes:
> Yes, it looks like fixing the combiner problem would make it possible to
> remove the mistaken mode checks.
Thanks very much, Jim. I will work toward removing these then.
Adam
Florian Weimer writes:
> * Richard Guenther:
>
> > What makes you think it is?
>
> I think there was some release announcement on Slashdot when the
> branch was created. 8-)
... thereby maintaining the reputation for accuracy for which Slashdot
is justly famous.
Andrew.
* Richard Guenther:
> What makes you think it is?
I think there was some release announcement on Slashdot when the
branch was created. 8-)
On 12/6/05, Jurij Rosenthal <[EMAIL PROTECTED]> wrote:
> Hi gcc team,
>
> please mention gcc 4.1 in News/Announcements
> at
> http://gcc.gnu.org/index.html
>
> if this is an official release.
What makes you think it is? 4.1.0 is not yet released.
Richard.
Hi gcc team,
please mention gcc 4.1 in News/Announcements
at
http://gcc.gnu.org/index.html
if this is an official release.
Thanks and regards
Jurij
>2005-12-01 Hans-Peter Nilsson <[EMAIL PROTECTED]>
>
> * gcc.dg/20041106-1.c, gcc.dg/20030321-1.c, gcc.dg/pr17112-1.c,
> gcc.dg/pr17112-1.c, g++.dg/other/packed1.C,
> g++.dg/other/crash-4.C, g++.dg/ext/packed8.C: Match "attribute
> ignored" warnings when "packing" is the s
Do you have bison installed? In my local build, that's a generated
file, not a source controlled file.
Hi,
gcc-4.0.1-4.fc4
gcc-4.0.2-8.fc4 (4.0.2 20051125 (Red Hat 4.0.2-8))
i386
gcc -W -Wall -Os test.c -o test -Werror && ./test
array: 1 2
array: 1 2
gcc -W -Wall -O2 test.c -o test -Werror && ./test
array: 1 2
array: 2 3
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173764
#include
voi
This test contains three invocations of Ref(), but only two of them are
considered ill. What I'd like to get an explanation for is why the third
(middle) instance is considered correct. After all, the u member of
Packed is packed, and hence all the members of Unpacked in that context
are, too. Name
Hi,
back in August I removed a call to fold after build_function_call_expr,
since build_function_call_expr already does the folding. In a follow-up
mail Richard Guenther raised the following point
( see http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01466.html ):
> Following precedence and to avoid
Hi,
I am building toolchain for Renesas SH, H8300 and M32C targets for ELF
format (i.e. sh-elf, h8300-elf, m32c-elf respectively) using the below
mentioned sources,
Binutils-051107
GCC-4.1-20051107
Newlib-dated 051114 from CVS
Host: i686-pc-linux-gnu
I am getting the below mentioned error at the
Hi!
Currently there are the following builtins available from the fortran
frontends:
/* We define these separately as the fortran versions have different
semantics (they return an integer type) */
gfc_define_builtin ("__builtin_roundl", mfunc_longdouble[0],
BUILT_IN
Steve Ellcey <[EMAIL PROTECTED]> writes:
| I also notice we have a "Releases" link under "About GCC" in the top
| left corner of the main GCC page that doesn't look like it has been
| updated in quite a while for any releases. Should this be updated or
| removed?
I think my previous answer to th
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
| > Steve Ellcey <[EMAIL PROTECTED]> writes:
| >
| > | Has GCC 3.4.5 been officially released?
| >
| > Yes, tarballs are on gcc.gnu.org and ftp.gnu.org since Dec 1st. Only
| > official announcement is missing.
|
| What are you waiting for?
Fi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andreas Jaeger wrote:
> Running the testsuite on the trunk, I get lots of failures:
>
>=== libjava Summary for unix ===
>
> # of expected passes1811
> # of unexpected failures1087
> # of expected failures
Hello,
I have two questions about long long type.
Firstly, shall I support it in the machine.md file, or just leave it to libgcc?
Dose the libgcc support it if I don't implement in the machine.md file?
Secondly, is the long long type equal to DImode in the 32bit machine?
Such as adddi3, subdi3.
T
Mathieu Lacage wrote:
> A path where different solutions for different problems are evolved
> independently and then merged where it makes sense seems better to me
> than a path where a single solution to two different problems is
> attempted from the start.
>
> Which is thus why I think that "t
Running the testsuite on the trunk, I get lots of failures:
=== libjava Summary for unix ===
# of expected passes1811
# of unexpected failures1087
# of expected failures 6
# of untested testcases 1097
This has been introduced in the last 24 ho
47 matches
Mail list logo
