Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

GCC 3.3 Released

michael posted more than 11 years ago | from the in-the-beginning-was-the-word dept.

GNU is Not Unix 441

devphil writes "The latest version of everyone's favorite compiler, GCC 3.3, was released today. New features, bugfixes, and whatnot, are all available off the linked-to page. (Mirrors already have the tarballs.) Let the second-guessing begin!"

cancel ×

441 comments

Sorry! There are no comments related to the filter you selected.

woo! (5, Funny)

KrON (2656) | more than 11 years ago | (#5962858)

mmm i'll install this one only cuz it rhymes ;)

OK.... (-1, Offtopic)

floydman (179924) | more than 11 years ago | (#5962861)

Well, fire up your computers gentelmen.....

gcc 3.3 fails on glibc 2.3.2 (4, Interesting)

Anonymous Coward | more than 11 years ago | (#5962863)

just for information re-compiling glibc 2.3.2 with gcc 3.3 fails. i don't see the point releasing a compiler or standard glibc which doesn't allow the existing compiler to be used to compile it.

Re:gcc 3.3 fails on glibc 2.3.2 (0)

Anonymous Coward | more than 11 years ago | (#5962931)

my bad, it has to be glibc 2.3.2 fails to compile with gcc 3.3

Re:gcc 3.3 fails on glibc 2.3.2 (5, Insightful)

bconway (63464) | more than 11 years ago | (#5963062)

I don't see the point in making changes to a compiler that shouldn't be made solely to satisfy a single piece of software. If the problem is with glibc, it should be fixed, not worked around. What if XFree86 failed to compile, should GCC work around that? How about Mozilla or OpenOffice.org?

Re:gcc 3.3 fails on glibc 2.3.2 (0)

Anonymous Coward | more than 11 years ago | (#5963143)

I think the problem here is that we're told that "Linux" is the kernel and that "GNU" is the OS toolkit. "GNU" includes GCC and glibc, but not XFree86, Mozilla, or OpenOffice(though they may be under the same license).

If this version of GCC is to be considered unstable, then fine. Cause bustage. If it's supposed to be production ready, though(and you would think it would be since it's on the FP of /.), then I'd want it to work with the rest of "GNU."

Re:gcc 3.3 fails on glibc 2.3.2 (2, Interesting)

Anonymous Coward | more than 11 years ago | (#5963155)

don't you think that a compiler should at least be able to deal with the last release of a core system component such as glibc ?

The compiler should at least be able to compile a) the Kernel b) the Glibc.

From the release timeframe a) is no problem. But b) usually takes half - one year to show up with a new release. They should at least release gcc and glibc at the same time or at least provide patches. Regardless to that the glibc and gcc people are almost the same persons so they should know best.

Re:gcc 3.3 fails on glibc 2.3.2 (0)

Anonymous Coward | more than 11 years ago | (#5963210)

Why hold back for linux when all the other OS's work just fine. It is only a problem with that steeming pile called glibc.

Re:gcc 3.3 fails on glibc 2.3.2 (2, Interesting)

rmathew (3745) | more than 11 years ago | (#5963311)

*Why* do you say that? I mean, can you point to some page that details the problems

GCC 3.3 (0, Interesting)

Anonymous Coward | more than 11 years ago | (#5962864)

Congratulations, so many bugs fixed, cool!
I wonder ow much slower than the last release is it...

slower than the last release.... (2, Interesting)

oliverthered (187439) | more than 11 years ago | (#5962936)

The optimiser has been vastly improved and ....

The following changes have been made to the IA-32/x86-64 port:
SSE2 and 3dNOW! intrinsics are now supported.
Support for thread local storage has been added to the IA-32 and x86-64 ports.
The x86-64 port has been significantly improved.

If you wan't compile time performance look at

Precompiled Headers [gnu.org]

Re:slower than the last release.... (4, Funny)

gazbo (517111) | more than 11 years ago | (#5962982)

Sir, as the chairman for The Society of Prevention of Apostrophe Abuse, I must herby report your post's heinous abuse in the "word" wan<deleted>t. Expect a letter from our solicitors very soon.

Re:slower than the last release.... (0)

Anonymous Coward | more than 11 years ago | (#5963045)

You Sir, bit.
Have a good day.

First post (-1, Offtopic)

philipx (521085) | more than 11 years ago | (#5962865)

Yooo hoooo.... I could post anything and be the first... All the beowulf cluster of those, soviet russia, and even start a flame war of GCC vs something else. Sorry, just trolling in here

Re:First post (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5962907)

IN SOVIET RUSSIA, GCC starts a beowulf cluster of flamewars about YOU!

oh joy (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5962866)

yay

SERVAR == TEH VARY SLWO (4, Informative)

Anonymous Coward | more than 11 years ago | (#5962874)

Caveats
The preprocessor no longer accepts multi-line string literals. They were deprecated in 3.0, 3.1, and 3.2.
The preprocessor no longer supports the -A- switch when appearing alone. -A- followed by an assertion is still supported.
Support for all the systems obsoleted in GCC 3.1 has been removed from GCC 3.3. See below for a list of systems which are obsoleted in this release.
Checking for null format arguments has been decoupled from the rest of the format checking mechanism. Programs which use the format attribute may regain this functionality by using the new nonnull function attribute. Note that all functions for which GCC has a built-in format attribute, an appropriate built-in nonnull attribute is also applied.
The DWARF (version 1) debugging format has been deprecated and will be removed in a future version of GCC. Version 2 of the DWARF debugging format will continue to be supported for the foreseeable future.
The C and Objective-C compilers no longer accept the "Naming Types" extension (typedef foo = bar); it was already unavailable in C++. Code which uses it will need to be changed to use the "typeof" extension instead: typedef typeof(bar) foo. (We have removed this extension without a period of deprecation because it has caused the compiler to crash since version 3.0 and no one noticed until very recently. Thus we conclude it is not in widespread use.)
The -traditional C compiler option has been removed. It was deprecated in 3.1 and 3.2. (Traditional preprocessing remains available.) The header, used for writing variadic functions in traditional C, still exists but will produce an error message if used.
General Optimizer Improvements
A new scheme for accurately describing processor pipelines, the DFA scheduler, has been added.
Pavel Nejedly, Charles University Prague, has contributed new file format used by the edge coverage profiler (-fprofile-arcs).

The new format is robust and diagnoses common mistakes where profiles from different versions (or compilations) of the program are combined resulting in nonsensical profiles and slow code to produced with profile feedback. Additionally this format allows extra data to be gathered. Currently, overall statistics are produced helping optimizers to identify hot spots of a program globally replacing the old intra-procedural scheme and resulting in better code. Note that the gcov tool from older GCC versions will not be able to parse the profiles generated by GCC 3.3 and vice versa.

Jan Hubicka, SuSE Labs, has contributed a new superblock formation pass enabled using -ftracer. This pass simplifies the control flow of functions allowing other optimizations to do better job.

He also contributed the function reordering pass (-freorder-functions) to optimize function placement using profile feedback.

New Languages and Language specific improvements
C/ObjC/C++
The preprocessor now accepts directives within macro arguments. It processes them just as if they had not been within macro arguments.
The separate ISO and traditional preprocessors have been completely removed. The front-end handles either type of preprocessed output if necessary.
In C99 mode preprocessor arithmetic is done in the precision of the target's intmax_t, as required by that standard.
The preprocessor can now copy comments inside macros to the output file when the macro is expanded. This feature, enabled using the -CC option, is intended for use by applications which place metadata or directives inside comments, such as lint.
The method of constructing the list of directories to be searched for header files has been revised. If a directory named by a -I option is a standard system include directory, the option is ignored to ensure that the default search order for system directories and the special treatment of system header files are not defeated.
A few more ISO C99 features now work correctly.
A new function attribute, nonnull, has been added which allows pointer arguments to functions to be specified as requiring a non-null value. The compiler currently uses this information to issue a warning when it detects a null value passed in such an argument slot.
A new type attribute, may_alias, has been added. Accesses to objects with types with this attribute are not subjected to type-based alias analysis, but are instead assumed to be able to alias any other type of objects, just like the char type.
C++
Type based alias analysis has been implemented for C++ aggregate types.
Objective-C
Generate an error if Objective-C objects are passed by value in function and method calls.
When -Wselector is used, check the whole list of selectors at the end of compilation, and emit a warning if a @selector() is not known.
Define __NEXT_RUNTIME__ when compiling for the NeXT runtime.
No longer need to include objc/objc-class.h to compile self calls in class methods (NeXT runtime only).
New -Wundeclared-selector option.
Removed selector bloating which was causing object files to be 10% bigger on average (GNU runtime only).
Using at run time @protocol() objects has been fixed in certain situations (GNU runtime only).
Type checking has been fixed and improved in many situations involving protocols.
Java
The java.sql and javax.sql packages now implement the JDBC 3.0 (JDK 1.4) API.
The JDK 1.4 assert facility has been implemented.
The bytecode interpreter is now direct threaded and thus faster.
Fortran
Fortran improvements are listed in the Fortran documentation.
Ada
Ada tasking now works with glibc 2.3.x threading libraries.
New Targets and Target Specific Improvements
The following changes have been made to the HP-PA port:
The port now defaults to scheduling for the PA8000 series of processors.
Scheduling support for the PA7300 processor has been added.
The 32-bit port now supports weak symbols under HP-UX 11.
The handling of initializers and finalizers has been improved under HP-UX 11. The 64-bit port no longer uses collect2.
Dwarf2 EH support has been added to the 32-bit linux port.
ABI fixes to correct the passing of small structures by value.
The SPARC, HP-PA, SH4, and x86/pentium ports have been converted to use the DFA processor pipeline description.
The following NetBSD configurations for the SuperH processor family have been added:
SH3, big-endian, sh-*-netbsdelf*
SH3, little-endian, shle-*-netbsdelf*
SH5, SHmedia, big-endian, 32-bit default, sh5-*-netbsd*
SH5, SHmedia, little-endian, 32-bit default, sh5le-*-netbsd*
SH5, SHmedia, big-endian, 64-bit default, sh64-*-netbsd*
SH5, SHmedia, little-endian, 64-bit default, sh64le-*-netbsd*
The following changes have been made to the IA-32/x86-64 port:
SSE2 and 3dNOW! intrinsics are now supported.
Support for thread local storage has been added to the IA-32 and x86-64 ports.
The x86-64 port has been significantly improved.
The following changes have been made to the MIPS port:
All configurations now accept the -mabi switch. Note that you will need appropriate multilibs for this option to work properly.
ELF configurations will always pass an ABI flag to the assembler, except when the MIPS EABI is selected.
-mabi=64 no longer selects MIPS IV code.
The -mcpu option, which was deprecated in 3.1 and 3.2, has been removed from this release.
-march now changes the core ISA level. In previous releases, it would change the use of processor-specific extensions, but would leave the core ISA unchanged. For example, mips64-elf -march=r8000 will now generate MIPS IV code.
Under most configurations, -mipsN now acts as a synonym for -march.
There are some new preprocessor macros to describe the -march and -mtune settings. See the documentation of those options for details.
Support for the NEC VR-Series processors has been added. This includes the 54xx, 5500, and 41xx series.
Support for the Sandcraft sr71k processor has been added.
The following changes have been made to the S/390 port:
Support to build the Java runtime libraries has been added. Java is now enabled by default on s390-*-linux* and s390x-*-linux* targets.
Multilib support for the s390x-*-linux* target has been added; this allows to build 31-bit binaries using the -m31 option.
Support for thread local storage has been added.
Inline assembler code may now use the 'Q' constraint to specify memory operands without index register.
Various platform-specific performance improvements have been implemented; in particular, the compiler now uses the BRANCH ON COUNT family of instructions and makes more frequent use of the TEST UNDER MASK family of instructions.
The following changes have been made to the PowerPC port:
Support for IBM Power4 processor added.
Support for Motorola e500 SPE added.
Support for AIX 5.2 added.
Function and Data sections now supported on AIX.
Sibcall optimizations added.
The support for H8 Tiny is added to the H8/300 port with -mn.
Obsolete Systems
Support for a number of older systems has been declared obsolete in GCC 3.3. Unless there is activity to revive them, the next release of GCC will have their sources permanently removed.

All configurations of the following processor architectures have been declared obsolete:

Matsushita MN10200, mn10200-*-*
Motorola 88000, m88k-*-*
IBM ROMP, romp-*-*
Also, some individual systems have been obsoleted:

Alpha
Interix, alpha*-*-interix*
Linux libc1, alpha*-*-linux*libc1*
Linux ECOFF, alpha*-*-linux*ecoff*
ARM
Generic a.out, arm*-*-aout*
Conix, arm*-*-conix*
"Old ABI," arm*-*-oabi
StrongARM/COFF, strongarm-*-coff*
HPPA (PA-RISC)
Generic OSF, hppa1.0-*-osf*
Generic BSD, hppa1.0-*-bsd*
HP/UX versions 7, 8, and 9, hppa1.[01]-*-hpux[789]*
HiUX, hppa*-*-hiux*
Mach Lites, hppa*-*-lites*
Intel 386 family
Windows NT 3.x, i?86-*-win32
MC68000 family
HP systems, m68000-hp-bsd* and m68k-hp-bsd*
Sun systems, m68000-sun-sunos*, m68k-sun-sunos*, and m68k-sun-mach*
AT&T systems, m68000-att-sysv*
Atari systems, m68k-atari-sysv*
Motorola systems, m68k-motorola-sysv*
NCR systems, m68k-ncr-sysv*
Plexus systems, m68k-plexus-sysv*
Commodore systems, m68k-cbm-sysv*
Citicorp TTI, m68k-tti-*
Unos, m68k-crds-unos*
Concurrent RTU, m68k-ccur-rtu*
Linux a.out, m68k-*-linux*aout*
Linux libc1, m68k-*-linux*libc1*
pSOS, m68k-*-psos*
MIPS
Generic ECOFF, mips*-*-ecoff*
SINIX, mips-sni-sysv4
Orion RTEMS, mips64orion-*-rtems*
National Semiconductor 32000
OpenBSD, ns32k-*-openbsd*
POWER (aka RS/6000) and PowerPC
AIX versions 1, 2, and 3, rs6000-ibm-aix[123]*
Bull BOSX, rs6000-bull-bosx
Generic Mach, rs6000-*-mach*
Generic SysV, powerpc*-*-sysv*
Linux libc1, powerpc*-*-linux*libc1*
Sun SPARC
Generic a.out, sparc-*-aout*, sparclet-*-aout*, sparclite-*-aout*, and sparc86x-*-aout*
NetBSD a.out, sparc-*-netbsd*aout*
Generic BSD, sparc-*-bsd*
ChorusOS, sparc-*-chorusos*
Linux a.out, sparc-*-linux*aout*
Linux libc1, sparc-*-linux*libc1*
LynxOS, sparc-*-lynxos*
Solaris on HAL hardware, sparc-hal-solaris2*
SunOS versions 3 and 4, sparc-*-sunos[34]*
NEC V850
RTEMS, v850-*-rtems*
VAX
VMS, vax-*-vms*
Documentation improvements
Other significant improvements
Almost all front-end dependencies in the compiler have been separated out into a set of language hooks. This should make adding a new front end clearer and easier.
One effect of removing the separate preprocessor is a small increase in the robustness of the compiler in general, and the maintainability of target descriptions. Previously target-specific built-in macros and others, such as __FAST_MATH__, had to be handled with so-called specs that were hard to maintain. Often they would fail to behave properly when conflicting options were supplied on the command line, and define macros in the user's namespace even when strict ISO compliance was requested. Integrating the preprocessor has cleanly solved these issues.
The Makefile suite now supports redirection of make install by means of the variable DESTDIR.

GCC 3.3
Detailed release notes for the GCC 3.3 release follow.

Bug Fixes
bootstrap failures
10140 cross compiler build failures: missing __mempcpy (DUP: 10198,10338)
Internal compiler errors (multi-platform)
3581 large string causes segmentation fault in cc1
4382 __builtin_{set,long}jmp with -O3 can crash the compiler
6387 -fpic -gdwarf-2 -g1 combination gives ICE in dwarf2out
6412 (c++) ICE in retrieve_specialization
6620 (c++) partial template specialization causes an ICE (segmentation fault)
6663 (c++) ICE with attribute aligned
7068 ICE with incomplete types
7647 (c++) ICE when data member has the name of the enclosing class
7675 ICE in fixup_var_refs_1
7718 'complex' template instantiation causes ICE
8116 (c++) ICE in member template function
8511 (c++) ICE: (hopefully) reproducible cc1plus segmentation fault
8564 (c++) ICE in find_function_data, in function.c
8660 (c++) template overloading ICE in tsubst_expr, in cp/pt.c
8766 (c++) ICE after failed initialization of static template variable
8803 ICE in instantiate_virtual_regs_1, in function.c
8846 (c++) ICE after diagnostic if fr_FR@euro locale is set
8906 (c++) ICE (Segmentation fault) when parsing nested-class definition
9216 (c++) ICE on missing template parameter
9261 (c++) ICE in arg_assoc, in cp/decl2.c
9263 (fortran) ICE caused by invalid PARAMETER in implied DO loop
9429 (c++) ICE in template instantiation with a pointered new operator
9516 Internal error when using a big array
9600 (c++) ICE with typedefs in template class
9629 (c++) virtual inheritance segfault
9672 (c++) ICE: Error reporting routines re-entered
9749 (c++) ICE in write_expression on invalid function prototype
9794 (fortran) ICE: floating point exception during constant folding
9829 (c++) Missing colon in nested namespace usage causes ICE
9916 (c++) ICE with noreturn function in ?: statement
9936 ICE with local function and variable-length 2d array
10262 (c++) cc1plus crashes with large generated code
10278 (c++) ICE in parser for invalid code
10446 (c++) ICE on definition of nonexistent member function of nested class in a class template
10451 (c++) ICE in grokdeclarator on spurious mutable declaration
10506 (c++) ICE in build_new at cp/init.c with -fkeep-inline-functions and multiple inheritance
10549 (c++) ICE in store_bit_field on bitfields that exceed the precision of the declared type
Optimization bugs
2001 Inordinately long compile times in reload CSE regs
2391 Exponential compilation time explosion in combine
2960 Duplicate loop conditions even with -Os
4046 redundant conditional branch
6405 Loop-unrolling related performance regressions
6798 very long compile time with large case-statement
6871 const objects shouldn't be moved to .bss
6909 problem w/ -Os on modified loop-2c.c test case
7189 gcc -O2 -Wall does not print ``control reaches end of non-void function'' warning
7642 optimization problem with signbit()
8634 incorrect code for inlining of memcpy under -O2
8750 Cygwin prolog generation erroneously emitting __alloca as regular function call
c front end
2161 long if-else cascade overflows parser stack
4319 short accepted on typedef'd char
8602 incorrect line numbers in warning messages when using inline functions
9177 -fdump-translation-unit: C front end deletes function_decl AST nodes and breaks debugging dumps
9853 miscompilation of non-constant structure initializer
c++ compiler and library
45 legal template specialization code is rejected (DUP: 3784)
764 lookup failure: friend operator and dereferencing a pointer and templates (DUP: 5116)
2862 gcc accepts invalid explicit instantiation syntax (DUP: 2863)
3663 G++ doesn't check access control during template instantiation
3797 gcc fails to emit explicit specialization of a template member
3948 Two destructors are called when no copy destructor is defined (ABI change)
4361 bogus ambiguity taking the address of a member template
4802 g++ accepts illegal template code (access to private member; DUP: 5387)
4803 inline function is used but never defined, and g++ does not object
5730 complex::norm() -- huge slowdown from egcs-2.91.66
6713 Regression wrt 3.0.4: g++ -O2 leads to seg fault at run time
7015 certain __asm__ constructs rejected
7086 compile time regression (quadratic behavior in fixup_var_refs)
7099 G++ doesn't set the noreturn attribute on std::exit and std::abort
7247 copy constructor missing when inlining enabled (invalid optimization?)
7441 string array initialization compilation time regression from seconds to minutes
7768 __PRETTY_FUNCTION__ for template destructor is wrong
7804 bad printing of floating point constant in warning message
8099 Friend classes and template specializations
8117 member function pointers and multiple inheritance
8205 using declaration and multiple inheritance
8645 unnecessary non-zero checks in stl_tree.h
8724 explicit destructor call for incomplete class allowed
8805 compile time regression with many member variables
8691 -O3 and -fno-implicit-templates are incompatible
8700 unhelpful error message for binding temp to reference
8724 explicit destructor call for incomplete class allowed
8949 numeric_limits::denorm_min() and is_iec559 problems
9016 Failure to consistently constant fold "constant" C++ objects
9053 g++ confused about ambiguity of overloaded function templates
9152 undefined virtual thunks
9182 basic_filebuf does not report errors in codecvt::out
9297 data corruption due to codegen bug (when copying.)
9318 i/ostream::operator>>/>/ and
9548 Incorrect results from setf(ios::fixed) and precision(-1) [DR231]
9555 ostream inserters fail to set badbit on exception
9561 ostream inserters rethrow exception of wrong type
9563 ostream::sentry returns true after a failed preparation
9582 one-definition rule violation in std::allocator
9622 __PRETTY_FUNCTION__ incorrect in template destructors
9683 bug in initialization chains for static const variables from template classes
9791 -Woverloaded-virtual reports hiding of destructor
9817 collate::compare doesn't handle nul characters
9825 filebuf::sputbackc breaks sbumpc
9826 operator>>(basic_istream, basic_string) fails to compile with custom traits
9924 Multiple using statements for builtin functions not allowed
9946 destructor is not called for temporary object
9964 filebuf::close() sometimes fails to close file
9988 filebuf::overflow writes EOF to file
10033 optimization breaks polymorphic references w/ typeid operator
10097 filebuf::underflow drops characters
10132 filebuf destructor can throw exceptions
10180 gcc fails to warn about non-inlined function
10199 method parametrized by template does not work everywhere
10300 use of array-new (nothrow) in segfaults on NULL return
10427 Stack corruption with variable-length automatic arrays and virtual destructors
10503 Compilation never stops in fixed_type_or_null
Objective-C
5956 selectors aren't matched properly when added to the selector table
Fortran compiler and library
1832 list directed i/o overflow hangs, -fbounds-check doesn't detect
3924 g77 generates code that is rejected by GAS if COFF debug info requested
5634 doc: explain that configure --prefix=~/... does not work
6367 multiple repeat counts confuse namelist read into array
6491 Logical operations error on logicals when using -fugly-logint
6742 Generation of C++ Prototype for FORTRAN and extern "C"
7113 Failure of g77.f-torture/execute/f90-intrinsic-bit.f -Os on irix6.5
7236 OPEN(...,RECL=nnn,...) without ACCESS='DIRECT' should assume a direct access file
7278 g77 "bug"; the executable misbehaves (with -O2 -fno-automatic)
7384 DATE_AND_TIME milliseconds field inactive on Windows
7388 Incorrect output with 0-based array of characters
8587 Double complex zero ** double precision number -> NaN instead of zero
9038 -ffixed-line-length-none -x f77-cpp-input gives: Warning: unknown register name line-length-none
10197 Direct access files not unformatted by default
Java compiler and library
6005 gcj fails to build rhug on alpha
6389 System.getProperty("") should always throw an IllegalArgumentException
6576 java.util.ResourceBundle.getResource ignores locale
6652 new java.io.File("").getCanonicalFile() throws exception
7060 getMethod() doesn't search super interface
7073 bytecode interpreter gives wrong answer for interface getSuperclass()
7180 possible bug in javax.naming.spi.NamingManager.getPlusPath()
7416 java.security startup refs "GNU libgcj.security"
7570 Runtime.exec with null envp: child doesn't inherit parent env (DUP: 7578)
7611 Internal error while compiling libjava with -O
7709 NullPointerException in _Jv_ResolvePoolEntry
7766 ZipInputStream.available returns 0 immediately after construction
7785 Calendar.getTimeInMillis/setTimeInMillis should be public
7786 TimeZone.getDSTSavings() from JDK1.4 not implemented
8142 '$' in class names vs. dlopen 'dynamic string tokens'
8234 ZipInputStream chokes when InputStream.read() returns small chunks
8415 reflection bug: exception info for Method
8481 java.Random.nextInt(int) may return negative
8593 Error reading GZIPped files with BufferedReader
8759 java.beans.Introspector has no flushCaches() or flushFromCaches() methods
8997 spin() calls Thread.sleep
9253 on win32, java.io.File.listFiles("C:\\") returns pwd instead of the root content of C:
9254 java::lang::Object::wait(), threads-win32.cc returns wrong return codes
9271 Severe bias in java.security.SecureRandom
preprocessor
7029 preprocessor should ignore #warning with -M
ARM-specific
2903 [arm] Optimization bug with long long arithmetic
7873 arm-linux-gcc fails when assigning address to a bit field
FreeBSD-specific
7680 float functions undefined in math.h/cmath with #define _XOPEN_SOURCE
HP-UX or HP-PA-specific
8705 [HP-PA] ICE in emit_move_insn_1, in expr.c
9986 [HP-UX] Incorrect transformation of fputs_unlocked to fputc_unlocked
10056 [HP-PA] ICE at -O2 when building c++ code from doxygen
m68hc11-specific
6744 Bad assembler code generated: reference to pseudo register z
7361 Internal compiler error in reload_cse_simplify_operands, in reload1.c
MIPS-specific
9496 [mips-linux] bug in optimizer?
PowerPC-specific
7067 -Os with -mcpu=powerpc optimizes for speed (?) instead of space
8480 reload ICEs for LAPACK code on powerpc64-linux
8784 [AIX] Internal compiler error in simplify_gen_subreg
10315 [powerpc] ICE: in extract_insn, in recog.c
Sparc-specific
10267 (documentation) Wrong build instructions for *-*-solaris2*
x86-specific (Intel/AMD)
7916 ICE in instantiate_virtual_register_1
7926 (c++) i486 instructions in header files make c++ programs crash on i386
8555 ICE in gen_split_1231
8994 ICE with -O -march=pentium4
9426 ICE with -fssa -funroll-loops -fprofile-arcs
9806 ICE in inline assembly with -fPIC flag
10077 gcc -msse2 generates movd to move dwords between xmm regs
10233 64-bit comparison only comparing bottom 32-bits
10286 type-punning doesn't work with __m64 and -O
10308 [x86] ICE with -O -fgcse or -O2

So, kids, don't try this at home (yet) (0)

Anonymous Coward | more than 11 years ago | (#5963018)

In other words, if you don't have some special reason (developer, tester, guru, itch up the arse) to try it, don't. The newbs often rush in to try a new sparkly piece of software just because. But when that particular piece of is a compiler, you're better off waiting a few months until software projects mantainers pick up on the changes.

What does it mean? (2, Interesting)

commanderfoxtrot (115784) | more than 11 years ago | (#5963095)

That's great... but can anyone tell us what a difference all that will make? I don't really care about compile times (too much)... but will mpeg2enc or ffmpeg run faster?

BTW, there is a preliminary ebuild in Gentoo.

Re:What does it mean? (5, Informative)

noda132 (531521) | more than 11 years ago | (#5963121)

Not many visible changes. Developers have better profiling, which means eventually if they care they can make software faster. Also, you're going to find a lot more compiler warnings, and perhaps the odd piece of software which doesn't compile at all. In the short run, nothing changes. In the long run, programs become better as they stick to better programming guidelines (since gcc doesn't support "bad" programming as well as the previous version).

I've been using gcc 3.3 for months from CVS, and have had no problems with it (except for compiling with -Werror).

Re:What does it mean? (0)

Anonymous Coward | more than 11 years ago | (#5963132)

"That's great... but can anyone tell us what a difference all that will make? I don't really care about compile times (too much)... but will mpeg2enc or ffmpeg run faster?"

Avoid it like the plague unless you are a developer dabbling in the black arts of GCC.

"BTW, there is a preliminary ebuild in Gentoo"

Is that asking for trouble or what?

Bliggy (-1, Offtopic)

smoothPorn (670652) | more than 11 years ago | (#5962882)

My favorite programming language is English.

Sigh (5, Interesting)

unixmaster (573907) | more than 11 years ago | (#5962885)

And "cant compile kernel with gcc 3.3" messages started to appear on lkml. Is it me or gcc team goes for quantity rather than quality that they even postponed many bugs ( like c++ compile time regression ) to gcc 3.4 to release 3.3...

Sigh, indeed... (3, Informative)

squarooticus (5092) | more than 11 years ago | (#5962941)

You DO realize that most of the problems compiling the Linux kernel with succeeding releases of gcc is due primarily to the kernel team making incorrect assumptions about the kernel output...

Right?

Re:Sigh (4, Informative)

Ed Avis (5917) | more than 11 years ago | (#5962974)

In the past, when a kernel has not compiled with a new gcc version it has been more often a bug in the kernel than one with gcc. The same goes for most apps. Looking at the list archives, the main problem seems to be with __inline__ which was a gcc extension to start with, so the problem is presumably that the meaning of that keyword has been deliverately changed.

Re:Sigh (1)

unixmaster (573907) | more than 11 years ago | (#5962979)

Maybe the kernel is buggy but what about increasing c++ compile time regressions since gcc 3.0 ?

Re:Sigh (2, Insightful)

norwoodites (226775) | more than 11 years ago | (#5963002)

Correctness is more important than compile time that is why it is being pushed back, most of the compile time regressions have to do with the inliner and its limits.

Re:Sigh (1)

r00zky (622648) | more than 11 years ago | (#5963244)

I bet that will be fixed in 3.4, with the inclusion of precompiled headers...

see gcc 3.4 projected changes here [gnu.org]

Re:Sigh (4, Informative)

norwoodites (226775) | more than 11 years ago | (#5962986)

Linux, the kernel, depends on old gcc extensions that are slowly being removed from gcc, extensions that were not documented. Also c++ compile time is a hard thing to fix if you want a full c++ compiler in a short period of time. 3.3 is very stable compiler, even 3.4 in the cvs is a stable compiler. The gcc team are all volunteers so why do you not help them and fix some problems, and/or report some problems to us (I am slowing helping out now).

Re:Sigh (1)

unixmaster (573907) | more than 11 years ago | (#5963023)

Well testing is helping too just got my gcc-3.2.3-gcc-3.3 patch. I have latest 2.5.x kernel so I can try and report any failures. Btw I did not mean to say gcc 3.3 does suck or anything like that its just they are postponing bugs to get a release done that hardly makes a user happy. I would wait for more if they promised to fix c++ compile time regression.

Re:Sigh (5, Informative)

Horny Smurf (590916) | more than 11 years ago | (#5963051)

gcc 3.4 is slated to include a hand-written (as oppsed to yacc-built) recursive descent parser (for c++ only). That should give a nice speed bump (and fixes over 100 bugs, too).

Bounds Checking (4, Interesting)

the-dude-man (629634) | more than 11 years ago | (#5962889)

I hear they have added in some more advanced, and aggressive bounds checking. Now when i screw up something i wont have to wait for a seg-v to tell me that pointer moved a little too far.

Although it dosnt seem to work with glibc....this is quite annyoing, although it probably will be fixed and re-released in a few days

Re:Bounds Checking (5, Informative)

asuffield (111848) | more than 11 years ago | (#5963222)

I hear they have added in some more advanced, and aggressive bounds checking. Now when i screw up something i wont have to wait for a seg-v to tell me that pointer moved a little too far.

Indeed, that SIGSEGV becomes a SIGABRT instead. This is dynamic bounds checking; it won't find anything until the bounds error occurs at runtime, so you won't find it any earlier. All it does is make sure that no bounds errors escape *without* crashing the process.

Although it dosnt seem to work with glibc....this is quite annyoing, although it probably will be fixed and re-released in a few days

I guess you didn't read the documentation. This is a "feature". It breaks the C ABI, forcing you to recompile all libraries used in the program, including glibc.

i want mine (-1, Offtopic)

Madcapjack (635982) | more than 11 years ago | (#5962899)

Just wanted to claim a little more of my own cyberspace, 'cause my society made me so.

Or as is said in "The Gold Coast", if you've got land and you've got money, you gotta build.

this is all well and good (-1, Funny)

Anonymous Coward | more than 11 years ago | (#5962901)

..but when will Linux get a decent IDE?

This is why I stick to coding for Win32 - Visual Studio is an absolute joy to use.

Windows - developer friendly. Linux - developer hostile.

Re:this is all well and good (2, Informative)

Anonymous Coward | more than 11 years ago | (#5962926)


There is one. Its called Visual SlickEdit, it costs $249 dollars.

Re:this is all well and good (1)

Lumpy (12016) | more than 11 years ago | (#5963194)

There is one. Its called Visual SlickEdit, it costs $249 dollars.

Oh man dont spend that money....

anjuta [sourceforge.net] is better and much more useable than visual slickedit as a linux based GCC ide for C and C++ and will create your project's Makefiles and everything else automatically.

I've used it for 6 months and it's easier than anything microsoft has ever written in their IDE and is certianly better than slickedit when you compare the costs.

I strongly reccomend that EVERY programmer download and try it right now... it's that good (except I WANT color highlighting to be printable! why is it that no programmer's editor cannot print the highlighting in color?)

as opposed to $249 pounds? (0)

thornfield (638897) | more than 11 years ago | (#5963284)

or maybe $249 yen, $249 francs?

Re:this is all well and good (1)

REBloomfield (550182) | more than 11 years ago | (#5962929)

erm... KDevelop? Amongst others, there's quite a few good ones now.

Re:this is all well and good (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5962956)

Flamebait? Nope.

Re:this is all well and good (0)

Anonymous Coward | more than 11 years ago | (#5962957)

Visual Studio will cost you $100-1000 depending on version and features. Windows is similarly, not free.

Some options:
CRiSP costs $150.
Look into what Borland has.
Develop Lisp apps using Emacs.
Develop Java apps using IntelliJ Idea (put's other IDE's to shame).

Re:this is all well and good (0)

Anonymous Coward | more than 11 years ago | (#5962966)

Get Borland's Kylix. Besides, having to use a specific tool to generate code and do your work for you doesn't make you a programmer, you're just another user of someone else's program. You have to see stuff in your head better than what Winblows visual does before you can call yourself a programmer, Bunky.

Re:this is all well and good (0)

Anonymous Coward | more than 11 years ago | (#5963180)

Yeah, I'm going to take advice from someone using the phrase "winblows".

Face it dork, Visual Studio is pretty nice. Thousands of MS Coders use it every day. Probably there are more Microsoft employees using visual studio than there are total users of any of the IDEs you mention. If there's a bug, it gets fixed. If there's a feature they want, it gets added.

Re:this is all well and good (0)

Anonymous Coward | more than 11 years ago | (#5963243)

Visual Studio is pretty nice...if there's a bug, it gets fixed. If there's a feature they want, it gets added.

I don't know about the rest of the Visual Studio products, but I can tell you with certainty that Visual SourceSafe 6.0 is a steaming pile of dog turd that needs to be exorcised, not bug fixed.

I expect Visual C++ or other Visual Studio products are a much better. I hope so, for the sakes of the developers who have to use them.

Re:this is all well and good (2, Interesting)

double_u_b (649587) | more than 11 years ago | (#5963030)

Visual Studio (v6) is a really bad IDE. I prefer Borland C++ Builder from far. And Visual C++ is really abject on some aspects: why does it compiles things differently if you are in debug mode? I used VC++ to code a file compression utility. Operator precedence is not the same between debug and release compiler mode. Debug had the same behaviour than GCC, Watcom or Borland. Release mode had a different behaviour. Not nice, since it took me hours to find wherethe bug was, since you can't easily debug a release executable... Moreover, speed-optimisation nearly always produces bad code. And debugging 'const' functions in C++ make the debugger go wild. Borland had neither of those problems. And the code looked cleaner when showed by BC++ Builder. Nevertheless, what I really like is the EclipseIDE, and the IDE of BeOS.

Re:this is all well and good (3, Insightful)

TrancePhreak (576593) | more than 11 years ago | (#5963187)

Sounds like you just don't have a lot of experience compiling. The first thing you do when something acts out of spec is to clean and then rebuild. This probably would have solved a lot of your troubles. The GNU make has this bug even worse, since it only checks file size most of the time. Speed optimization has _never_ in my 5 years of using VC++ produced bad code. Please stop with the trolling and get back to learning how to use the compilers properly.
Borland C++ was okay 6 years ago, but after VC6 came out it's easy to see why it's not so great any more. Two more IDE updates and the old BC is left far behind. I'd take many OpenSource IDE's over BC. Features such as auto-completion and code collapsing have saved me a good deal of time & typing.

Re:this is all well and good (1)

double_u_b (649587) | more than 11 years ago | (#5963292)

I know about the clean and rebuild all. I tried. But it didn't work. In fact, all the problems began when I asked people to use the const keyword to prevent some side effects at compile time. Borland C++ Builder, at the time I used it, had the code completion thing. I don't know what code collapsing is. I suspect you are talking about Borland C++, not Borland C++ Builder. I used Borland C++ 4.5 and 5, those were buggy IDEs. Worst was Watcom C++ IDE. The text editor could hang the computer 4 times a day. But you use the compiler and IDE your company owns. But VC++6 never had my preference in one aspect: it produces faster code than borland compiler.

Re:this is all well and good (1)

TrancePhreak (576593) | more than 11 years ago | (#5963334)

Well that's rather odd then. I've had const all over the place in a couple projects and everything seemed to work just fine. I wouldn't throw out the possibility of the compiler misbehaving at this point, but I'd still guess it to be something else. Code collapsing is like being able to fold a piece of paper so that you only see the parts you want to. A lot of newer IDE's have this.

Re:this is all well and good (1)

double_u_b (649587) | more than 11 years ago | (#5963399)

I must say that when I first saw the code, it was really messy... So the cleanup was long and difficult. I remember the problem occured in a private static const function that dealt with the serial port. Code collapsing sounds a cool feature, but the VC++ we used (VC6) didn't have this. Now, I don't code in C/C++ anymore, or just for fun. I use the worst IDE I know of (even if it feature some kind of "code collapsing"): Cool:GEN to produce COBOL

Re:this is all well and good (0)

Anonymous Coward | more than 11 years ago | (#5963237)

C++Builder is great if you don't need your IDE to be stable.

I've been using it professionally for almost 4 years.. I can tell you in no uncertain terms that it is junk. It's junk. See?

They can't write a solid GUI with their own GUI lib. That should tell ya something.

Thank god for vim and text .dfm files. I would have went insane long ago otherwise.

Re:this is all well and good (-1, Offtopic)

Call Me Black Cloud (616282) | more than 11 years ago | (#5963090)

Not flamebait, you kneejerk mods.

Re:this is all well and good (4, Funny)

BigBadBri (595126) | more than 11 years ago | (#5963149)

Flamebait?

Nah.

Funny as hell, though - Visual Studio is an absolute joy to use.

Compared to what?

Having your head nailed to a table?

Be careful (3, Funny)

swagr (244747) | more than 11 years ago | (#5962910)

I'm waiting for SCO to show it's copied code before I pick up any GNU software.

Stricter Checking - Programmers Check Your Stuff (1)

wol (10606) | more than 11 years ago | (#5962914)

I believe this version has stricter checking. It is probably a good idea for everyone with programs out there to do a quick recompile and see if there is something you can improve or error messages you can fix.

My problem with GCC (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5962919)

is that Fyodor is a wanker!

Oh no, is he going to savagely root my box and post gay porn that he says he got off my computer?

ABI? (3, Interesting)

42forty-two42 (532340) | more than 11 years ago | (#5962922)

Does this release break binary compatibility?

Re:ABI? (1, Informative)

Anonymous Coward | more than 11 years ago | (#5962951)

No.

Mostly compatible, but... (4, Informative)

r6144 (544027) | more than 11 years ago | (#5963099)

According to this [gnu.org] , if your program is multi-threaded, uses spinlocks in libstdc++, and runs on x86, then you'll have to configure gcc-3.3 for a i486+ target (instead of i386) in order to make it binary compatible with gcc-3.2.x configured for a i386 target. Otherwise when the code is mixed, the bus isn't locked when accessing the spinlock, which IMHO may cause concurrency problems on SMP boxes (?)

Re:Mostly compatible, but... (0)

Anonymous Coward | more than 11 years ago | (#5963363)

In plain english please - will this new GCC break any versions of RedHat, Mandrake, Suse, Slackware?

Re:Mostly compatible, but... (1)

DarkOx (621550) | more than 11 years ago | (#5963405)

I think the answer to your question in plain english is:
"Maybe, if those are being run on an SMP box"

Two things I don't understand. (5, Interesting)

torpor (458) | more than 11 years ago | (#5962938)

I don't understand these two points, maybe someone can explian:

The preprocessor no longer accepts multi-line string literals.

Why was this removed?

And:

The header, used for writing variadic functions in traditional C, still exists but will produce an error message if used.

This I don't understand at all. Does it mean we can't write void somefunc(int argc, ...) style funcs any more?

Someone, please explain...

Re:Two things I don't understand. (1)

TrancePhreak (576593) | more than 11 years ago | (#5963010)

according to http://www.itworld.com/nl/lnx_tip/02162001/
Varia dic functions are functions that take variable arguements... So unless they made it part of the compiler, then your guess is correct.

Re:Two things I don't understand. (5, Informative)

Anonymous Coward | more than 11 years ago | (#5963032)

The preprocessor no longer accepts multi-line string literals.

Why was this removed?


Link to GCC mail archive on this topic [gnu.org] . It seems like overkill, for sure.

The header, used for writing variadic functions in traditional C, still exists but will produce an error message if used.

This I don't understand at all. Does it mean we can't write void somefunc(int argc, ...) style funcs any more?


No. The funcionality is still there, it's just included via <stdarg.h> instead of <varargs.h>.

Re:Two things I don't understand. (0, Funny)

Anonymous Coward | more than 11 years ago | (#5963035)

It refers to varargs.h only. If you want variadic functions, you should use the standard header stdargs.h. If you're still using varargs.h you should be hit with a large boot.

Re:Two things I don't understand. (4, Informative)

spakka (606417) | more than 11 years ago | (#5963036)

The preprocessor no longer accepts multi-line string literals.

Standard C doesn't allow newline characters in strings. You can still put in '\n' escape characters to represent newlines.

Does it mean we can't write void somefunc(int argc, ...) style funcs any more?

You can, but in the implementation, you need to use the Standard C header stdarg.h instead of the traditional C header varags.h.

Re:Two things I don't understand. (1, Funny)

torpor (458) | more than 11 years ago | (#5963122)

Gotcha.

I guess I thought this meant I couldn't write code like this anymore:

#define BIGLONGSTRING "AAAAAAAA" \
"BBBBBBBBBB" \
"CCCCCCCC" \
"DDDDDDD"

But that seems to not be the case.

Thanks for the explanation.

Re:Two things I don't understand. (2, Informative)

norwoodites (226775) | more than 11 years ago | (#5963162)

You can write that code but not:

char *A="A
B";
char *B="B";
char *C="C";

Anymore see how much problems this can cause if you did not have the second quote on the thrid line?

Re:Two things I don't understand. (1)

norwoodites (226775) | more than 11 years ago | (#5963039)

The first one was removed because of the extension was causing more harm than good, so you have to change all the inline asm, not to have multi-line strings.

The second is taking about the `varargs.h' header, the orginal way of doing variadic functions.

Maybe it means varargs.h (2, Informative)

r6144 (544027) | more than 11 years ago | (#5963134)

If you use stdarg.h, nothing should break.

I think here "the header" means "varargs.h", which is the old way for writing variadic functions. Should not appear in any reasonably new (post 1995) code.

Re:Two things I don't understand. (1)

Fledsbo (11673) | more than 11 years ago | (#5963151)

The (historic) header varargs.h is removed. stdarg.h is still there. man stdarg.

Re:Two things I don't understand. (0)

Anonymous Coward | more than 11 years ago | (#5963229)

The keyword is "traditional C", which means the language that existed before C became an ANSI standard around 1989.

<vararg.h> was replaced by <stdarg.h> then, so it should not be used today. If you still have such old code, you can rewrite them to use <stdarg.h>.

I believe multi-line string literals were traditional C too, that has been replaced by string concatenation. (i.e. two quoted strings separated by whitespace (including eol) like "aaa" "bbb" is concatenated at compile (or is it preprocessing?) time.)

well... (-1, Offtopic)

borgdows (599861) | more than 11 years ago | (#5962943)

Linux is dying!! SCO confirms.

SuSE already uses it (5, Interesting)

red_dragon (1761) | more than 11 years ago | (#5962954)

I just got SuSE 8.2 installed this week, which includes GCC 3.3, and noticed that the kernel is also compiled with GCC 3.3. From 'dmesg':

Linux version 2.4.20-4GB (root@Pentium.suse.de) (gcc version 3.3 20030226 (prerelease) (SuSE Linux)) #1 Wed Apr 16 14:50:03 UTC 2003

Re:SuSE already uses it (2)

dizzy tunez (89390) | more than 11 years ago | (#5963056)

Read "PRERELEASE" , not "RELEASE".
Yes, there is a diffrence.

Re:SuSE already uses it (2, Insightful)

red_dragon (1761) | more than 11 years ago | (#5963098)

Yes, it does say 'prerelease', which I didn't miss (I did type that dmesg string in, y'know). The date isn't too far in the past, though, so differences between that and the release version shouldn't be that great.

Pre-release to compile a kernel? (0)

Anonymous Coward | more than 11 years ago | (#5963179)

No thanks.

Precompiled header support (1, Interesting)

Anonymous Coward | more than 11 years ago | (#5962961)

I have been wondering about this for more than half a decade now:

Why is it that GCC never seem to get precompiled header support added?

The compilation speed of GCC is one of its biggest weaknesses when you compare it to eg MSVC. All Windows compilers seem to have had this since the DOS days, but still GCC have never gotten this feature. How come?

Re:Precompiled header support (3, Informative)

oliverthered (187439) | more than 11 years ago | (#5962989)

look here [gnu.org]

Using Precompiled Headers
Often large projects have many header files that are included in every source file. The time the compiler takes to process these header files over and over again can account for nearly all of the time required to build the project. To make builds faster, GCC allows users to `precompile' a header file; then, if builds can use the precompiled header file they will be much faster.

Re:Precompiled header support (2, Informative)

norwoodites (226775) | more than 11 years ago | (#5963081)

look at http://gcc.gnu.org/ [gnu.org] and see under January 10, 2003:
Geoffrey Keating of Apple Computer, Inc., with support from Red Hat, Inc., has contributed a precompiled header implementation that can dramatically speed up compilation of some projects.

GCC will have it for 3.4.

Re:Precompiled header support (1, Informative)

Anonymous Coward | more than 11 years ago | (#5963182)

You might also like to try 'ccache'.

Re:Precompiled header support (2, Interesting)

Dionysus (12737) | more than 11 years ago | (#5963302)

Is precompiled header support even necessary?
If you follow the advice of any good programming book, you shouldn't be including unnecessary header files anyway.

One of the reason you need precompiled header support in Windows, is because to write any meaningful Windows program, you need to include <windows.h>, which include everything.

Re:Precompiled header support (2, Informative)

Anonymous Coward | more than 11 years ago | (#5963428)

Yes. Precompiled headers make much sense for projects that do not include everything.

Including everything into a precompiled header file will infact make the compilation much slower than if you didnt use precompiled headers at all.

<windows.h> is a very bad example on how to make an efficient precompiled header. Granted, it may been what started the entire precompiled header business, but the time won from precompiled headers in general is greater than what you'd think.

The key to create a good precompiled header is finding all those header files included in the majority of all source files, and precompile that. This saves considerable parsing time during compilation. Even despite not all source files use all the header data of your precompiled headers - as long as it uses a significant amount.

Even with your good programming book, you will still see yourself include the same headers in the majority of your source files. Its not unnecessary included headers, just commonly used data structures and functions for your application.

"RELEASED TODAY" (1)

Horny Smurf (590916) | more than 11 years ago | (#5962994)

Actually, it was released yesterday (5/13). OSNews reported it yesterday.


3/4 of "News" is "new", you know.

Stallman Calls Ballmer "Sick" (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5962999)

Proclaims Ballmer's love of goats, "unnatural".

Compile-time performance (5, Informative)

Hortensia Patel (101296) | more than 11 years ago | (#5963004)

Yes, this release (like all 3.x releases) is a lot slower than 2.9x was. This is particularly true for C++, to the point where the compile-time cost of standard features like iostreams or STL is prohibitive on older, slower machines. I've largely gone back to stdio.h and hand-rolled containers for writing non-production code, just to keep the edit-compile-test cycle ticking along at a decent pace.

The new support for precompiled headers will help to some extent but is by no means a panacea. There are a lot of restrictions and caveats. The good news is that the GCC team are very well aware of the compile-time issue and (according to extensive discussions on the mailing list a few weeks back) will be making it a high priority for the next (3.4) release.

Incidentally, for those wanting a nice free-beer-and-speech IDE to use with this, the first meaningful release of the Eclipse CDT is at release-candidate stage and is looking good.

insane (0)

Anonymous Coward | more than 11 years ago | (#5963064)

You write your own containers because STL compiles
too slow?! I guess you don't value your time AT ALL.

Re:insane (1)

Hortensia Patel (101296) | more than 11 years ago | (#5963114)

I think you missed the "for writing non-production code" qualifier.

For a small, non-critical app which only needs minimal functionality, hand-rolling is hardly a time sink. Writing a bare-bones string or list implementation takes about five minutes, and in terms of time, will "pay" for itself after a dozen or so compiles.

You need to do cost-benefit analysis of your time (0)

Anonymous Coward | more than 11 years ago | (#5963219)

If you're hand-rolling containers and avoiding STL or iostreams because your box is too slow you're whacked.

What's a 2.0 gig barebones box cost now? $400?

How cheap do you work for that you can't afford a $400 tool that would free you to use ANSI and ISO standard code that you don't have to develop and debug?!?!?

Re:Compile-time performance (1)

Ed Avis (5917) | more than 11 years ago | (#5963313)

I wonder, with the increase in CPU speeds since 2.9x was current, whether a $500 machine now can compile faster or slower than a $500 machine a few years back.

Of course it would be still nice for gcc not to get slower, or maybe even to get faster :-(.

gcc 3.x compilers have serious C++ perfs issues (5, Informative)

ondelette (253185) | more than 11 years ago | (#5963042)

The new breed of gcc compiler are anywhere from 3 %to 5% slower [gnu.org] with file processing using the C++ library. So, compiling the kernel with gcc 3.x is fine, but I suspect that something like KDE which is mostly written in C++ is impacted seriously. At least, all software using the C++ library for IO (fstream) will be much slower. On the other hand, the support for C++ standards is much better so what I do is that I compile using gcc 3.2.3 to validate my C++ and then I run the real thing with a pre 3.x compiler.

Re:gcc 3.x compilers have serious C++ perfs issues (3, Informative)

norwoodites (226775) | more than 11 years ago | (#5963118)

The changes that made C++ compiling slower were for correctness of the compiler so they are needed. I know 3.4 will be faster than 3.3 is(/was), and should be able to speed up even faster.

If you use fstreams you ain't into performance (0)

Anonymous Coward | more than 11 years ago | (#5963298)

Geez, why not use getc() and putc() and process the file byte-by-byte?

If performance is important, do this:


int fd;
struct stat sb;
void *data;

fd = open(...);
fstat( fd, &sb );
data = mmap( NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0 );
close( fd );

// data processing here on *data

munmap( data, sb.st_size );

This will out-perform damn near anything.

At last (0)

Anonymous Coward | more than 11 years ago | (#5963067)

Vax VMS has been obsoleted!

My opinion (-1, Flamebait)

Crusty Oldman (249835) | more than 11 years ago | (#5963119)

GCC is "everyone [sic] favorite compiler" just like Windows is everyone's favorite operating system.

Let me guess... (-1)

Anonymous Coward | more than 11 years ago | (#5963473)

Let me guess. The -1 flamebait moderator is a Windows fan, right?

Just as I thought... (0)

Anonymous Coward | more than 11 years ago | (#5963141)

...the Installsheild Windows binaries are nowhere to be found. Sigh....



Everyone loves GCC? (3, Informative)

Call Me Black Cloud (616282) | more than 11 years ago | (#5963166)

Not for me, thanks. I prefer the dynamic duo of Borland's C++ Builder/Kylix. Cross platform gui development? How you say...ah yes...w00t!

For Java, Sun One Studio (crappy name)/Netbeans (inaccurate name) floats my boat. There is a light C++ module for Netbeans but I haven't tried it...no need.

Give Kylix a try [borland.com] - there is a free version you know:

Borland® Kylix(TM) 3 Open Edition delivers an integrated ANSI/ISO C++ and Delphi(TM) language solution for building powerful open-source applications for Linux,® licensed under the GNU General Public License

Download it here [borland.com] .

Sun One install hangs on my dual-proc box (0)

Anonymous Coward | more than 11 years ago | (#5963339)

On a Slackware 9.0 box with dual processors the processes used to install the package wind up hanging on a wait4() call that's wait()'ing for a process that's already exited (confirmed with strace).

To install I had to boot a single-processor kernel.

Seems to be a kernel bug in the wait4() code. If I had the time to run down all the things kernel.org wants for a bug report I'd report it. But I'm using Sun One to generate paychecks right now...

Via C3 Ezra (1)

Simon Lyngshede (623138) | more than 11 years ago | (#5963216)

They don't really seem to care about not following the standard for i686. You still have to compile everything for i586 on the Via C3 Ezra chips. The specs. for i686 states that cmov is an optional feature in i686 chips but gcc still doesn't check if the cpu supports it. Of cause with the new C3 it doesn't matter, but I don't have one of those.

Not a big fault, but it would be nice not having to remember to set the cpu type to i586 everytime you compile stuff.

nonnull function attribute (4, Informative)

dimitri_k (106607) | more than 11 years ago | (#5963312)

If anyone else was curious to see an example of the new nonnull function attribute, the following is reformatted from the end of the relevant patch [gnu.org] , posted to gcc-patches by Marc Espie:

nonnull (arg-index,...)
nonull attribute
The nonnull attribute specifies that some function parameters should
be non null pointers. For instance, the declaration:

extern void *
my_memcpy (void *dest, const void *src, size_t len)
__attribute__ ((nonnull (1, 2)));

causes the compiler to check that, in calls to my_memcpy, arguments dest
and src are non null.

Using nonnull without parameters is a shorthand that means that all
non pointer [sic] arguments should be non null, to be used with a full
function prototype only. For instance, the example could be
abbreviated to:

extern void *
my_memcpy (void *dest, const void *src, size_t len)
__attribute__ ((nonnull));

Seems useful, though I suspect many derefernced pointers are set NULL at runtime, and so not spottable during build.

Note: I didn't change the wording above at the [sic], but I believe that this should read "all pointer arguments" instead.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>