Re: What does coding-style tells about integer types for pointers ?
Just really ! The array arr has the type void ***, the cast happens on the
first derefencing of arr. So the result remains a void **, which is for
sure a pointer. This leads to a pointer truncation,
therefore to a warning and a build failure. It is clear, that the first
element of the array arr is in fact the integer value of a type with
sizeof(void *).
Wouldn't is better to have for this cast monster a structure. Something
like
struct sFieldArray {
size_t count;
void *arr[1];
}
?
Regards,
i.A. Kai Tietz
Richard Henderson [EMAIL PROTECTED]
08.03.2007 19:08
To
Kai Tietz [EMAIL PROTECTED]
cc
Ian Lance Taylor [EMAIL PROTECTED], gcc@gcc.gnu.org
Subject
Re: What does coding-style tells about integer types for pointers ?
On Thu, Mar 08, 2007 at 06:06:57PM +0100, Kai Tietz wrote:
In gcc the file emutls.c assumes that a long has sizeof void * in
function
emutls_destroy.
Not really. It assumes you can store the size of the array
in min(sizeof(long), sizeof(void*)) bytes.
r~
Re: Updating libtool in GCC and srctree
Joseph S. Myers [EMAIL PROTECTED] writes: We should use current CVS HEAD libtool. We definitely can't use 1.5 releases without *a lot* of auditing of local changes: we've allowed local changes into GCC's libtool on the basis that there are equivalents in CVS HEAD (this is the policy in codingconventions.html), to use 1.5 while avoiding regressions would require auditing every local change since libtool 1.5 branched to see if it's in 1.5.22. From what I can see almost all of the local changes in GCC are from before the 1.5 branch was created. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: What does coding-style tells about integer types for pointers ?
Please stop top-posting.
Kai Tietz writes:
Richard Henderson [EMAIL PROTECTED]
08.03.2007 19:08
On Thu, Mar 08, 2007 at 06:06:57PM +0100, Kai Tietz wrote:
In gcc the file emutls.c assumes that a long has sizeof void * in
function
emutls_destroy.
Not really. It assumes you can store the size of the array
in min(sizeof(long), sizeof(void*)) bytes.
Just really ! The array arr has the type void ***, the cast happens on the
first derefencing of arr. So the result remains a void **, which is for
sure a pointer. This leads to a pointer truncation,
RTH is right. It isn't a pointer, it's an integer that has been
stored in a pointer. The pointer is not truncated, since it was never
a pointer in the first place. There is certainly no assumption that
long has sizeof void*, just that void* is large enough to hold the
length.
therefore to a warning and a build failure. It is clear, that the first
element of the array arr is in fact the integer value of a type with
sizeof(void *).
Wouldn't is better to have for this cast monster a structure. Something
like
struct sFieldArray {
size_t count;
void *arr[1];
}
?
Andrew.
[sparc] A few gcc testsuite failures....
Aurora SPARC Linux release 2.90 (Aurora Corona)/TI UltraSparc IIi (Sabre) sun4u: binutils-2.17.50.0.3-6.sparc.sparc bison-2.3-2.1.sparc dejagnu-1.4.4-5.1.noarch expect-5.43.0-5.1.sparc gcc-4.1.1-30.1.sparc glibc-2.5-3.1.sparcv9 glibc-2.5-3.1.sparc64 glibc-devel-2.5-3.1.sparc glibc-devel-2.5-3.1.sparc64 glibc-headers-2.5-3.1.sparc gmp-2.4.1 (local build from gcc's infrastructure) mpfr-2.2.1 (local build from gcc's infrastructure) kernel-2.6.18-1.2798.al3.1.sparc64 libgcc-4.1.1-30.1.sparc libgcc-4.1.1-30.1.sparc64 libgcj-4.1.1-30.1.sparc libgcj-4.1.1-30.1.sparc64 libgcj-devel-4.1.1-30.1.sparc libgcj-devel-4.1.1-30.1.sparc64 libstdc++-4.1.1-30.1.sparc libstdc++-4.1.1-30.1.sparc64 libstdc++-devel-4.1.1-30.1.sparc libstdc++-devel-4.1.1-30.1.sparc64 make-3.81-1.1.sparc tcl-8.4.13-3.al3.sparc LAST_UPDATED: Wed Mar 7 11:15:23 UTC 2007 (revision 122655) Compiler version: 4.3.0 20070307 (experimental) Platform: sparc64-unknown-linux-gnu configure flags: --enable-__cxa_atexit --enable-shared --with-cpu=v7 --with-gmp=/usr/local/gmp-mpfr --with-mpfr=/usr/local/gmp-mpfr --enable-languages=c,c++,fortran,java,objc,obj-c++,treelang I get a few sparc target failures in the gcc testsuite, for example Running /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/sparc.exp ... Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc/ /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/align.c -mcpu=ultrasparc -mvis -fno-show-column -S -o align.s(timeout = 1200) /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/align.c: In function 'foo3': /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/align.c:18: note: use -flax-vector-conversions to permit conversions between vectors with differing element types or numbers of subparts /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/align.c:18: error: incompatible type for argument 1 of '__builtin_vis_faligndatav8qi' /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/align.c:18: error: incompatible type for argument 2 of '__builtin_vis_faligndatav8qi' /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/align.c:18: error: incompatible types in return compiler exited with status 1 output is: /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/align.c: In function 'foo3': /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/align.c:18: note: use -flax-vector-conversions to permit conversions between vectors with differing element types or numbers of subparts /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/align.c:18: error: incompatible type for argument 1 of '__builtin_vis_faligndatav8qi' /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/align.c:18: error: incompatible type for argument 2 of '__builtin_vis_faligndatav8qi' /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/align.c:18: error: incompatible types in return FAIL: gcc.target/sparc/align.c (test for excess errors) Excess errors: /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/align.c:18: note: use -flax-vector-conversions to permit conversions between vectors with differing element types or numbers of subparts /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/align.c:18: error: incompatible type for argument 1 of '__builtin_vis_faligndatav8qi' /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/align.c:18: error: incompatible type for argument 2 of '__builtin_vis_faligndatav8qi' /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/align.c:18: error: incompatible types in return ERROR: gcc.target/sparc/align.c: error executing dg-final: couldn't open align.s: no such file or directory UNRESOLVED: gcc.target/sparc/align.c: error executing dg-final: couldn't open align.s: no such file or directory and the next example being Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc/ /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/combined-2.c -O2 -mcpu=ultrasparc -mvis -fno-show-column -S -o combined-2.s (timeout = 1200) /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/combined-2.c: In function 'foo': /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/combined-2.c:8: note: use -flax-vector-conversions to permit conversions between vectors with differing element types or numbers of subparts /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/combined-2.c:8: error: incompatible type for argument 1 of '__builtin_vis_fpmerge' /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/combined-2.c:8: error: incompatible type for argument 2 of '__builtin_vis_fpmerge' /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/combined-2.c:8: error: incompatible types in initialization /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/combined-2.c:10: error: incompatible type for argument 1 of '__builtin_vis_fmul8x16' /usr/local/src/trunk/gcc/gcc/testsuite/gcc.target/sparc/combined-2.c: In function
PATCH: Fix integrt/pointer size mismatch in splay-tree.h
Hallo, There is another point in libiberty, which has a problem with integer-values and pointer sizes. This small patch should fix. ChangeLog: 2007-03-06 Kai Tietz [EMAIL PROTECTED] * splay-tree.h (splay_tree_key): type declared as ptrdiff_t (splay_tree_value): Ditto Patch Regards, i.A. Kai Tietz Kai Tietz - Software engineering OneVision Software Entwicklungs GmbH Co KG Dr.-Leo-Ritter-Str. 9, 93049 Regensburg, Germany Phone: +49-941-78004-0 FAX: +49-941-78004-489 WWW: http://www.OneVision.comIndex: splay-tree.h === --- splay-tree.h(revision 122691) +++ splay-tree.h(working copy) @@ -44,8 +44,8 @@ these types, if necessary. These types should be sufficiently wide that any pointer or scalar can be cast to these types, and then cast back, without loss of precision. */ -typedef unsigned long int splay_tree_key; -typedef unsigned long int splay_tree_value; +typedef ptrdiff_t splay_tree_key; +typedef ptrdiff_t splay_tree_value; /* Forward declaration for a node in the tree. */ typedef struct splay_tree_node_s *splay_tree_node; =
PATCH: Fix integrt/pointer size mismatch in splay-tree.h
Hallo, I detected, that ptrdiff_t is not declared in all places, therefore the use of size_t seems to be more correct. Regards, i.A. Kai Tietz
Re: Looking for specific pages from Muchnick's book
jimmy wrote: Steven Bosscher wrote: Hi, I found this old patch (http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01669.html) that refers to pages 202-214 of Muchnick's Advanced Compiler Design and Implementation book. That book still is not in my own compiler books collection because of its price. Since you've mentioned it, could you also suggest a few books worth buying (for the benefit of the not-so-compiler-savvy-but-want-to-be :). I think it would be very much appreciated! This is my personal point of view about some not too old books about compilers which I read and believe to worth to look at if you are interested in compilers. Please, I don't want to argue if somebody is not agree with me. o Muchnik book is a fat one. Muchnick's book is rather encyclopedia of optimizations and can be considered as collection of articles with many details (sometimes too many). But some themes (like RA and scheduling) are described not deep. o Robert Morgan. Building an Optimizing compiler. Although the book volume is small, this is not an appetizer. This is practically description of Morgan's integral approach for building optimizing compilers. The book contains very detail algorithms of all passes of the proposed compiler back-end. A very interesting book to read about RA but his proposed complicated approach (combined global/local/FAT RA) is doubtful. I've tried it and found not working well for gcc. Scheduling and software pipelining description is weak too. o Cooper and Torczon. Engineering a compiler. It is close to their course in Rice University. A good book to start study compiler from parsing to code generation and basic optimizations. But if you are familiar with the compilers, you probably don't find interesting thoughts and approaches. o Appel. Modern Compiler implementation in C/Java/ML. Another good book to start to study compilers from parser to code generation and basic optimizations. I especially like the version in ML (Modern compiler implementation in ML). o Aho/Lam/Sethi/Ulman. Compilers: Principles, Techniques, and Tools. 2nd edition. Personally I don't like it because it is based on outdated (although classical) book. I attached a review of this book which I wrote more than year ago (when the book was not ready). o Allen and Kennedy. Optimizing compilers for modern architectures. It is book to study more advanced (not basic) optimizations like dependence analysis, loop optimizations, inter-procedural optimizations. o I am waiting for Fischer's book (crafting compiler) which will be published soon. I like his lectures but I am afraid using Java for this book can hurt the book. If you don't want to be compiler savvy but want to understand the compiler, I'd recommend Appel's, Cooper's, Morgan's book in the same priority. There are a lot of other books about compilers but some of them are too specialized or too trivial. Review of the second addition of the Dragon Book. Originally the book was to be called 21st century compilers. But probably it is too ambitious name. Currently Amazon is selling the 1st edition plus online chapters from the 2nd edition. There is an additional author Monica Lam, a professor of Standford University (knowing her track of the researches I can guess that she probably wrote the two best chapters about parallelism and locality). Chapters 5-11 were accessible starting Nov. 15 till Dec. 31 2005 online through flash to prevent copying the book. It was hard to read it online and flash permitted to print one page of very bad quality at a time. Reading the chapters, I can guess that chapters prior 5 will be without changes taken from the 1st edition of the Dragon book. Chapter 5, Syntax directed translation, is pretty the same chapter as in the 1st edition describing different attribute grammars to make syntax trees, expression DAGs (with collapsed sub-expression) and other translation. I did not find considerable changes in the chapter. It is not the rocket science but probably it is the most abstract and general description of the translation pass in compiler books. Chapter 6, Intermediate code generation, is actually more compact and modern version of two chapters 6 (type checking) and 8 (intermediate code generation) from the 1st edition. Some obsolete parts are removed and new concepts are added. It makes this chapter is better than in the two ones in the 1st edition. Big drawback is just mentioning SSA. IMHO It needs a deeper introduction in algorithms of conversion to/from SSA. So Morgan's book (Building an optimizing compiler) and Cooper's and Torczon's book (Engineering a compiler) are much better description of SSA. This is the first edition where GCC is mentioned (as an example of compiler using the same IR for implementation of many languages). Chapter 7, Runtime environment, is mainly more compact version of the one in the 1st edition but it uses C++ and ML as example instead of
call_value pattern
Dear GCC Developers,
I have a rather simple piece of a call_value instruction pattern in my
machine description:
---snip---
(define_insn call_value
[(set (match_operand 0 )
(call (match_operand:QI 1 )
(match_operand:SI 2 )))]
jal\\t%S0%(
[(set_attr type jump)
(set_attr mode none)])
---snap---
However when I try to compile the following example I get a Internal
Compiler Error message.
---snip---
int odd(int i)
{
return i 0x1;
}
int foo(int i, int j)
{
int a;
a=odd(i+j);
return a;
}
---snap---
If simply omit the a=odd(i+j)-line everything works fine so it has
something to do with this call.
What am I doing wrong? It seems so simple but I can't figure out what's
wrong with my pattern.
Regards,
Markus Franke
Re: Looking for specific pages from Muchnick's book
Hi, If you like maths, a short book Scheduling and Automatic Parallelization by Alain Darte, Yves Robert, and Frederic Vivien, not publicized as much as the books proposed by Vladimir, provides more formal background than what you can find in classical compiler literature. I would also recommend for a math audience classical books that strangely don't get outdated. The classical Milne and Strachey's A theory of programming language semantics, The Formal Semantics of Programming Languages by Glynn Winskel, Theory of Linear and Integer Programming by Alexander Schrijver, etc. Sebastian On 3/9/07, jimmy [EMAIL PROTECTED] wrote: Steven Bosscher wrote: Hi, I found this old patch (http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01669.html) that refers to pages 202-214 of Muchnick's Advanced Compiler Design and Implementation book. That book still is not in my own compiler books collection because of its price. Since you've mentioned it, could you also suggest a few books worth buying (for the benefit of the not-so-compiler-savvy-but-want-to-be :). I think it would be very much appreciated! thnx, -jb -- mathematician, n.: Some one who believes imaginary things appear right before your i's.
Re: call_value pattern
Markus Franke [EMAIL PROTECTED] writes: What am I doing wrong? It seems so simple but I can't figure out what's wrong with my pattern. Run the compiler under gdb and do a backtrace to see where the ICE is coming from. Ian
Re: Looking for specific pages from Muchnick's book
Vladimir, you forgot a good book: o Y.N. Srikant P.Shankar. The Compiler Design Handbook: Optimizations and Machine Code Generation. CRC Press 2003. Upto page 916. Good topics: 9. Scalar Compiler Optimizations on the Static Single Assignment (SSA) Form and the Flow Graph by Y.N. Srikant. Pages 99 .. 140. 13. Register Allocation (RA) by K. Gopinath. Pages 461 .. 529. 15. Instruction Selection Using Tree Parsing by Priti Shankar. Pages 565 .. 599. 17. Instruction Scheduling by R. Govindarajan. Pages 631 .. 678. 6. Optimizations for Object-Oriented Languages by Andreas Krall and Nigel Horspool. Pages 219 ..244. 8. Program Slicing by G.B. Mund, D. Goswami and Rajib Mall. Pages 269 ..291. 2. Automatic Generation of Code Optimizers from Formal Specifications by Vineeth Kumar Paleri. Pages 61 .. 97. 1. Data Flow Analysis by Uday. P. Khedker. Pages 1 .. 59. ;)
Re: Looking for specific pages from Muchnick's book
J.C. wrote: Vladimir, you forgot a good book: o Y.N. Srikant P.Shankar. The Compiler Design Handbook: Optimizations and Machine Code Generation. CRC Press 2003. Upto page 916. Thanks for reminding. I know about this book but I did not read it. It looks very interesting but it is expensive one. I think about buying it because it looks promising for deeper study but I have some doubts because it looks like some articles from the book are available on Internet (like software pipelining algorithms overview by Vicki Alan etc). http://books.google.com/books?vid=ISBN084931240Xid=S6LoBz8te_sCpg=RA1-PA61lpg=RA1-PA61ots=J380wtpULNdq=%27automatic+generation+of+code+optimizers+from+formal+specifications%27sig=yJm-JZi7KBWki4mPQq3iZpSs0hk#PPP1,M1
Re: symbol names are not created with stdcall syntax: MINGW, (GCC) 4.3.0 20061021
It might be considered a backend issue, but in general it is a binutils (so OP is in the wrong list!). I beg to disagree with the in general it is a binutils issue part. One of the posters explained why the information needed for name decoration can't be determined at link-time (nor at assembly-time, from what I understood). I think it's completely a compiler issue: if there's a switch (-mrtd) to change the calling convention of the generated code, there should probably be another one to also change the naming convention accordingly. On a related note, I found in gcc/config/i386/i386.c the following comment: The attribute stdcall is equivalent to RTD on a per module basis. I think it's not true wrt to naming convention. I otherwise perfectly agree with you about not adding yet another extension to the Fortran front-end. FX
Re: Looking for specific pages from Muchnick's book
On Fri, Mar 09, 2007 at 08:36:25AM -0500, Vladimir N. Makarov wrote: o Muchnik book is a fat one. Muchnick's book is rather encyclopedia of optimizations and can be considered as collection of articles with many details (sometimes too many). But some themes (like RA and scheduling) are described not deep. Also, as has been mentioned, many of his algorithms are buggy (I think it came from describing them all in his own artificial language that he had no compiler for). I suppose that if you *really* understand his text, you can debug his algorithms.
Re: Looking for specific pages from Muchnick's book
On 3/9/07, Vladimir N. Makarov [EMAIL PROTECTED] wrote: o Muchnik book is a fat one. Muchnick's book is rather encyclopedia of optimizations and can be considered as collection of articles with many details (sometimes too many). But some themes (like RA and scheduling) are described not deep. Muchnick is also famous for its 150 A4 pages of errata, especially the 1st and 2nd print. I really wouldn't recommend it to you unless you're looking for a compiler algorithms cook book. o Robert Morgan. Building an Optimizing compiler. This is my favorite book. If you've read the Dragon book and this one, you're well under way to being a compiler expert. I agree with Vlad about the contents of the book, but it is the only fairly comprehensive introduction text I know of that deals with LCM and SSA at a level that even I can understand ;-) o Appel. Modern Compiler implementation in C/Java/ML. Another good book to start to study compilers from parser to code generation and basic optimizations. I especially like the version in ML (Modern compiler implementation in ML). The version in ML is the best of the three. The other two look too much like had to do this-books where algorithms are translated from ML, which makes them look very unnatural in C/Java. o Aho/Lam/Sethi/Ulman. Compilers: Principles, Techniques, and Tools. 2nd edition. Personally I don't like it because it is based on outdated (although classical) book. I attached a review of this book which I wrote more than year ago (when the book was not ready). This one is old, but it is a classic. The 1st edition should be on every compiler engineer's book shelf, just because. I have never seen the 2nd edition myself. Grune et. al. Modern Compiler Design is another good introduction text, especially if you're interested in various parsing techniques. Gr. Steven
Re: Improvements of the haifa scheduler
Maxim Kuvyrkov [EMAIL PROTECTED] wrote on 04/03/2007 11:53:47:
Hi.
I want to share some of my thoughts and doings on improving / cleaning
up current GCC instruction scheduler (Haifa) - most of them are just
small obvious improvements.
I have semi-ready patches for about a half of them and would appreciate
any early suggestion or comments on the following draft plan:
1. Remove compute_forward_dependencies (). [Done]
Since new representation of dependencies lists was checked in, we don't
longer need to compute forward dependencies separately. It would be
natural to add forward links at the same time as we generate backward
ones.
2. Use alloc_pools instead of obstacks for dep_nodes and deps_lists.
[In progress]
As pointed out by Jan Hubicka scheduler peaks +100M on a testcase for
PR28071 after my patch for new dependencies lists was checked in.
Though alloc_pools should have been my first choice while writing that
patch, I decided to mimic as close as possible the original rtx
instruction lists with their scheme of deallocation at the very end. So
the next step would be to define proper lifetime of dependency lists
and use alloc_pools to reuse nodes and lists from the previous regions.
It might be possible to shrink such large DDG's by removing edges that are
redundant wrt schduling, due to transitivity. Not sure how much we'll gain
by such a (non-trivial, dangerous) effort.
Which brings us to ...
3. Define clear interface for manipulating dependencies. [In progress]
This one popped up when I began to debug 2 and understood that the
scheduler uses and changes dependencies lists the way it shouldn't.
Lists are being copied, edited and deleted directly without interaction
with sched-deps.c . What the scheduler really needs is the following
set of primitives:
o FOR_EACH_DEP (insn, which_list, iterator, dep) - walk through
insn's which_list (one of {backward, resolved_backward, forward,
resolved_forward}) and provide the user with the dep. Ayal Zaks
suggested this type of macro weeks ago but at that time I didn't agree
with him.
o dep_t find_dep_between (producer, consumer) - find dependency
between two instructions. Currently we walk through the list looking
for what we need. A better way would be to first check dependency
caches and then, if we can't determine that there is no dependency, walk
through the shorter list given the choice of two: producer's forward
list and consumer's backward list.
o void add_dep (dep_t) - Add a dependency.
o void remove_dep (iterator) - Remove dependency pointed out by
iterator.
o void resolve_dep (iterator) - Resolve dependency pointed out by
iterator.
o int get_list_size (insn, which_list) - Get the size of the insn's
which_list.
o bool list_has_only_speculative_deps (insn, which_list) - Return
true if all insn's dependencies can be overcome with some sort of
speculation.
It would probably be cleaner to somehow seperate or designate the
speculative part from the core DDG part (in terms of data and interfaces).
o void {create, delete}_dependency_lists (insn) - Create / delete
dependency lists for insn.
As you can see, the scheduler doesn't need to know the internal
representation of the deps_list / dep_node.
4. Support speculative loads into subregs. [Planned]
As noted by Jim Wilson current support for ia64 speculation doesn't
handle subregs though that would be easy to fix.
5. Make sched-deps.c mark only those dependencies as speculative which
can actually be overcame with speculation types currently in use.
[Planned]
At the moment we first generate speculative dependencies and only at the
moment of adding instruction to the ready list we check if we can (or it
worth to) overcome every of its dependencies.
6. Make ds_t a structure. [Planned]
ds_t is type for representing status of a dependency. It contains
information about types of the dependency (true, output, anti) and
probabilities of speculation success (begin_data, be_in_data,
begin_control, be_in_control) - that makes three bits and for integers
coded in a single int. Historical reasons forced this inelegant
approach but now the reasons are inexistent and the problem can be
solved in a natural way.
7. Use cse_lib in sched-rgn.c . [In progress]
At the moment cse_lib works to improve alias analysis only during
sched-ebb scheduling. It is trivial that we can also enable it when
scheduling single block regions in sched-rgn. The patch for this is
a one-liner which was tested on a bootstrap but not on SPECs.
It is also possible to use cse_lib on sequential basic_blocks of the
region thus handling them as an extended basic block.
If it is possible to save cse_lib states, then we'll be able to process
trees and merging capabilities are required for DAGs. Don't know if
this can be done.
8. Don't generate a memory barrier on simplejump. [Done]
sched-deps.c handles every jump in the
gcc-4.3-20070309 is now available
Snapshot gcc-4.3-20070309 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070309/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 122765 You'll find: gcc-4.3-20070309.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070309.tar.bz2 C front end and core compiler gcc-ada-4.3-20070309.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070309.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070309.tar.bz2 C++ front end and runtime gcc-java-4.3-20070309.tar.bz2 Java front end and runtime gcc-objc-4.3-20070309.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070309.tar.bz2The GCC testsuite Diffs from 4.3-20070302 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Updating libtool in GCC and srctree
I have made some progress in updating libtool in the src (binutils) tree
and I have attached the various changes (but not the actual new libtool
files) to this email in case anyone wants to see what I am doing.
I am having more trouble with the GCC tree. I put the new libtool in
the toplevel directory, just like I did in the binutils src tree and
then I went to the boehm-gc (and libffi) directories to try and rerun
autoconf. If I just run autoconf I get errors because I am not
including the new ltoptions.m4, ltsugar.m4, and ltversion.m4 files. Now
in the binutils tree the acinclude.m4 files had explicit includes of
libtool.m4 and I added includes of ltoptions.m4, ltsugar.m4, and
ltversion.m4. But boehm-gc has no acinclude.m4 file and while libffi
has an acinclude.m4 file, it doesn't have an include of libtool.m4. So
my question is, how is the include of libtool.m4 getting into
aclocal.m4? Is it by running aclocal? I tried to run aclocal but I get
errors when I run it:
$ aclocal
autom4te: unknown language: Autoconf-without-aclocal-m4
aclocal: autom4te failed with exit status: 1
This is aclocal 1.9.6. Any idea on what I need to do here to fix this
error? Why do some acinclude.m4 files have explicit includes for
libtool files (libgfortran, libgomp, etc) but other's don't (libffi,
gcc).
Steve Ellcey
[EMAIL PROTECTED]
Here is what I have done so far in the src/binutils tree:
Top level src tree ChangeLog:
2007-03-09 Steve Ellcey [EMAIL PROTECTED]
* ltmain.sh: Update from libtool ToT.
* libtool.m4: Update from libtool ToT.
* ltsugar.m4: New. Update from libtool ToT.
* ltversion.m4: New. Update from libtool ToT.
* ltoptions.m4: New. Update from libtool ToT.
* ltconfig: Remove.
* ltcf-c.sh: Remove.
* ltcf-cxx.sh: Remove.
* ltcf-gcj.sh: Remove.
* src-release: Update with new libtool file list.
Index: src-release
===
RCS file: /cvs/src/src/src-release,v
retrieving revision 1.22
diff -u -r1.22 src-release
--- src-release 9 Feb 2007 15:15:38 - 1.22
+++ src-release 9 Mar 2007 23:37:34 -
@@ -49,8 +49,8 @@
DEVO_SUPPORT= README Makefile.in configure configure.ac \
config.guess config.sub config move-if-change \
COPYING COPYING.LIB install-sh config-ml.in symlink-tree \
- mkinstalldirs ltconfig ltmain.sh missing ylwrap \
- libtool.m4 ltcf-c.sh ltcf-cxx.sh ltcf-gcj.sh \
+ mkinstalldirs ltmain.sh missing ylwrap \
+ libtool.m4 ltsugar.m4, ltversion.m4, ltoptions.m4 \
Makefile.def Makefile.tpl src-release config.rpath
# Files in devo/etc used in any net release.
bfd/ChangeLog
2007-03-09 Steve Ellcey [EMAIL PROTECTED]
* acinclude.m4: Add new includes.
* configure.in: Change macro call order.
* configure: Regenerate.
Index: acinclude.m4
===
RCS file: /cvs/src/src/bfd/acinclude.m4,v
retrieving revision 1.16
diff -u -r1.16 acinclude.m4
--- acinclude.m431 May 2006 15:14:35 - 1.16
+++ acinclude.m49 Mar 2007 23:36:49 -
@@ -49,6 +49,9 @@
fi
AC_SUBST(EXEEXT_FOR_BUILD)])dnl
+sinclude(../ltsugar.m4)
+sinclude(../ltversion.m4)
+sinclude(../ltoptions.m4)
sinclude(../libtool.m4)
dnl The lines below arrange for aclocal not to bring libtool.m4
dnl AM_PROG_LIBTOOL into aclocal.m4, while still arranging for automake
Index: configure.in
===
RCS file: /cvs/src/src/bfd/configure.in,v
retrieving revision 1.222
diff -u -r1.222 configure.in
--- configure.in1 Mar 2007 15:48:36 - 1.222
+++ configure.in9 Mar 2007 23:37:07 -
@@ -19,7 +19,10 @@
dnl configure option --enable-shared.
AM_DISABLE_SHARED
-AM_PROG_LIBTOOL
+AC_PROG_CC
+AC_GNU_SOURCE
+
+AC_PROG_LIBTOOL
AC_ARG_ENABLE(64-bit-bfd,
[ --enable-64-bit-bfd 64-bit support (on hosts with narrower word sizes)],
@@ -95,9 +98,6 @@
# host stuff:
-AC_PROG_CC
-AC_GNU_SOURCE
-
ALL_LINGUAS=fr tr ja es sv da zh_CN ro rw vi
ZW_GNU_GETTEXT_SISTER_DIR
AM_PO_SUBDIRS
binutils/ChangeLog
2007-03-09 Steve Ellcey [EMAIL PROTECTED]
* configure.in: Change macro call order.
* configure: Regenerate.
Index: configure.in
===
RCS file: /cvs/src/src/binutils/configure.in,v
retrieving revision 1.75
diff -u -r1.75 configure.in
--- configure.in28 Feb 2007 01:29:32 - 1.75
+++ configure.in9 Mar 2007 23:36:12 -
@@ -11,7 +11,9 @@
changequote([,])dnl
AM_INIT_AUTOMAKE(binutils, ${BFD_VERSION})
-AM_PROG_LIBTOOL
+AC_PROG_CC
+AC_GNU_SOURCE
+AC_PROG_LIBTOOL
AC_ARG_ENABLE(targets,
[ --enable-targetsalternative target configurations],
@@ -53,9 +55,6 @@
AC_MSG_ERROR(Unrecognized host system type; please check config.sub.)
fi
-AC_PROG_CC
Re: Updating libtool in GCC and srctree
Steve Ellcey [EMAIL PROTECTED] writes: $ aclocal autom4te: unknown language: Autoconf-without-aclocal-m4 aclocal: autom4te failed with exit status: 1 Looks like you have an out-of-date autom4te.cache. Andreas. I removed autom4te.cache and reran aclocal. Same results. Steve Ellcey [EMAIL PROTECTED]
Re: GCC 4.2.0 Status Report (2007-03-04)
Andrew MacLeod wrote: There are a handful I've been involved with which are labeled as 4.0/4.1/4.2/4.3 regressions which I don't see ever being fixed in 4.0 through 4.2. There is perhaps some hope for 4.3, but 4.4 is the more likely case. They require new development work that I think is unlikely to ever be backported to these releases for just these testcases. Thank you very much for this email. I apologize for not acknowledging this earlier. The PRs are - 21596 I made a simple attempt at this one, but the simple approach isn't going to work. - 23200 fixed in 4.3 by the new version of TER. Unlikely to port the entire TER rewrite back to 4.2 at this stage (it could be done tho :-). This was still marked as a bug in 4.3 in the Summary section of the bug. Given that this fixed, I've removed the 4.3 marker there. In future, when you fix a bug, please remove the release from the Summary section, if you remember. (I forget too...) - 27986 This is in fact a variation of the issue in 21596, except this one crosses basic blocks. It will require all new work to get this case. - 27877 Mark Shinwell applied a patch for this to 4.3. I pinged him about applying it to 4.2. If I haven't heard from him by thursday, I will apply it friday. I think you meant 29877? In any case, thank you! I would say you can mark the first 3 as 'will not fix', or whatever you do to indicate they aren't going to be resolved in 4.2. I'm going to leave them open, but I've added a link to your message to the audit trails. Optimistically, someone might miraculously fix them, but it's very helpful to know that that's going to be unlikley. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RE: symbol names are not created with stdcall syntax: MINGW, (GCC) 4.3.0 20061021
On mingw, I get the following:
$ cat a.c
int foo(int x) { return x+1; }
$ gcc.exe -mrtd a.c -shared -o a.dll
$ nm a.dll | grep foo
100011c0 T _foo
$ cat b.c
int __stdcall foo(int x) { return x+1; }
$ gcc.exe b.c -shared -o b.dll
$ nm b.dll | grep foo
100011c0 T [EMAIL PROTECTED]
$ gcc.exe b.c -shared -o b.dll -mrtd
$ nm b.dll | grep foo
100011c0 T [EMAIL PROTECTED]
I think -mrtd doesn't change the name.
Correct.
Maybe GCC needs another option
to add the name decoration automatically? CCing the GCC list and Danny
S. for this question.
IMO, anybody who uses -mrtd (with or without decorations) is asking for
trouble.
Unless you are planning to use a gfortran dll in a VisualBasic app, I
can see little reason to change from the default C calling convention.
Danny
FX
Re: Updating libtool in GCC and srctree
On Fri, Mar 09, 2007 at 03:58:40PM -0800, Steve Ellcey wrote: I am having more trouble with the GCC tree. I put the new libtool in the toplevel directory, just like I did in the binutils src tree and then I went to the boehm-gc (and libffi) directories to try and rerun autoconf. If I just run autoconf I get errors because I am not including the new ltoptions.m4, ltsugar.m4, and ltversion.m4 files. Now in the binutils tree the acinclude.m4 files had explicit includes of libtool.m4 and I added includes of ltoptions.m4, ltsugar.m4, and ltversion.m4. But boehm-gc has no acinclude.m4 file and while libffi has an acinclude.m4 file, it doesn't have an include of libtool.m4. So my question is, how is the include of libtool.m4 getting into aclocal.m4? Is it by running aclocal? I tried to run aclocal but I get errors when I run it: $ aclocal autom4te: unknown language: Autoconf-without-aclocal-m4 aclocal: autom4te failed with exit status: 1 This is aclocal 1.9.6. Any idea on what I need to do here to fix this error? Why do some acinclude.m4 files have explicit includes for libtool files (libgfortran, libgomp, etc) but other's don't (libffi, gcc). I just pulled HEAD and if you look at the tail end of boehm-gc/aclocal.m4, you'll find: m4_include([../config/acx.m4]) m4_include([../config/depstand.m4]) m4_include([../config/lead-dot.m4]) m4_include([../config/multi.m4]) m4_include([../config/no-executables.m4]) m4_include([../libtool.m4]) So, you need to run aclocal with: $ aclocal -I ../config -I .. -- albert chin ([EMAIL PROTECTED])
[Bug tree-optimization/31095] New: [4.3 Regression] ICE in expand_expr_real_1, at expr.c:8786
I get the following ICE on IA-64: [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O libnasl-capture_packet.c libnasl-capture_packet.c: In function 'capture_next_packet': libnasl-capture_packet.c:19: internal compiler error: in expand_expr_real_1, at expr.c:8786 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c libnasl-capture_packet.c [EMAIL PROTECTED]:~$ gcc-4.1 -c -O2 libnasl-capture_packet.c [EMAIL PROTECTED]:~$ -- Summary: [4.3 Regression] ICE in expand_expr_real_1, at expr.c:8786 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC target triplet: ia64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31095
[Bug tree-optimization/31095] [4.3 Regression] ICE in expand_expr_real_1, at expr.c:8786
--- Comment #1 from tbm at cyrius dot com 2007-03-09 08:30 ---
Testcase:
typedef long unsigned int size_t;
__extension__ typedef long int __time_t;
__extension__ typedef long int __suseconds_t;
typedef struct
{
}
__sigset_t;
struct timeval
{
__time_t tv_sec;
__suseconds_t tv_usec;
};
extern void bcopy (__const void *__src, void *__dest, size_t __n)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1, 2)));
capture_next_packet (int bpf, int timeout, int *sz)
{
struct timeval past, now, then;
{
bcopy (then, past, sizeof (then));
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31095
[Bug rtl-optimization/30643] [4.1/4.2/4.3 regression] CSE pessimization
--- Comment #9 from bonzini at gnu dot org 2007-03-09 08:44 --- Zdenek, any chance that your aliasing oracle can be used to fix these? -- bonzini at gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30643
[Bug middle-end/31095] [4.3 Regression] ICE in expand_expr_real_1, at expr.c:8786
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |middle-end Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31095
[Bug rtl-optimization/30643] [4.1/4.2/4.3 regression] CSE pessimization
--- Comment #10 from rakdver at gcc dot gnu dot org 2007-03-09 08:54 --- Alias oracle could be used for this; but my patch only uses it in loop optimizers. So some changes to make ccp use it would be necessary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30643
[Bug middle-end/31096] New: a*C == b*C where C is a constant is not optimized to a == b
The following two functions should be equzlivant when overflow is undefined:
int f(int a, int b)
{
return a * 10 == b*10;
}
int f1(int a, int b)
{
return a==b;
}
--
Summary: a*C == b*C where C is a constant is not optimized to a
== b
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31096
[Bug middle-end/31096] a*C == b*C where C is a constant is not optimized to a == b
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19987 nThis|| Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31096
[Bug middle-end/31097] New: a/C == b/C is not foldded to a == b with --fast-math/floating point
The following two functions should be equalivant with --fast-math:
int f(float a, float b)
{
return a/10 == b/10;
}
int f1(float a, float b)
{
return a == b;
}
--
Summary: a/C == b/C is not foldded to a == b with --fast-
math/floating point
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31097
[Bug middle-end/31097] a/C == b/C is not foldded to a == b with --fast-math/floating point
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19987 nThis|| Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31097
[Bug middle-end/31098] New: a*C == b*C is not foldded to a == b with --fast-math/floating point
The following two functions should be equalivant with --fast-math:
int f(float a, float b)
{
return a*10 == b*10;
}
int f1(float a, float b)
{
return a == b;
}
--
Summary: a*C == b*C is not foldded to a == b with --fast-
math/floating point
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
OtherBugsDependingO 19987
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31098
[Bug c++/29164] Overloaded operator delete[] doesn't get called
--- Comment #8 from Andreas dot Kowarz at tu-dresden dot de 2007-03-09 09:37 --- It seems that the bug triggers only when returning NULL in the new operators. Returning something different ( tested with (void *)1 ) is a workaround for the problem. Checking for not returning NULL in the new operators seems reasonable even if it does not solve the mentioned mis-compilation of the delete operators. Tested for - g++ 3.2.3 - g++ 4.1.1 - icpc 9.1 (returning NULL prevents both delete operators from being called correctly) Andreas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29164
[Bug bootstrap/30635] --enable-stage1-langauges configure option is not documented.
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-09 09:42:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30635
[Bug libfortran/31099] New: Runtime error on legal code using RECL
$ cat a.f90 PROGRAM TEST INTEGER :: A OPEN(10, FORM=UNFORMATTED, RECL=1024) A = -1 WRITE(10) A END PROGRAM TEST $ gfortran a.f90 ./a.out At line 5 of file a.f90 Fortran runtime error: I/O past end of record on unformatted file $ pgf90 a.f90 ./a.out xxd fort.10 000: 0400 0400 $ sunf90 a.f90 ./a.out xxd fort.10 000: 0400 0400 $ ifort a.f90 ./a.out xxd fort.10 000: 0400 0400 -- Summary: Runtime error on legal code using RECL Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
[Bug target/31100] New: ASM_OUTPUT_ALIGN_WITH_NOP wrong on sparc/gas
The macro ASM_OUTPUT_ALIGN_WITH_NOP on sparc contains an explicit filler on the
align statement. This is given as a word representing the NOP. The GNU
assembler only uses the last byte of the filler. This generates wrong code. The
original SUN assembler needs this word to insert NOPs instead of zero.
The testcase is compiled with gcc -v -S -O3 -falign-labels=16 test.c
The testcase:
int f(int i)
{
int res;
switch ( i )
{
case 5:
res = i -i ;
break;
default:
res = i* 2;
}
return res;
}
int f(int);
main()
{
return f(2);
}
--
Summary: ASM_OUTPUT_ALIGN_WITH_NOP wrong on sparc/gas
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Erwin dot Unruh at fujitsu-siemens dot com
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31100
[Bug libfortran/31099] [4.3/4.2 regression] Runtime error on legal code using RECL
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-09 10:06 --- This one hurts. Nevertheless, it's probably too late for 4.2.0... -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||jerrydy at sbcglobal dot net Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.2.0 4.3.0 Known to work||4.1.2 Last reconfirmed|-00-00 00:00:00 |2007-03-09 10:06:17 date|| Summary|Runtime error on legal code |[4.3/4.2 regression] Runtime |using RECL |error on legal code using ||RECL Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
[Bug target/31054] FLDx not emitted for 80387 constants in 64-bit mode.
--- Comment #1 from ubizjak at gmail dot com 2007-03-09 10:22 --- This problem is fixed in 4.3.0. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-09 10:22:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31054
[Bug tree-optimization/31090] Revision 121302 causes 30% performance regression
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-09 10:32 --- It looks like a no-op change. For reference: --- ChangeLog (revision 121301) +++ ChangeLog (revision 121302) @@ -1,3 +1,41 @@ +2007-01-28 Daniel Berlin [EMAIL PROTECTED] + + * tree.h (struct tree_memory_tag): Add aliases member. + (MTAG_ALIASES): New macro. + * tree-ssa-alias.c (alias_bitmap_obstack): New variable. + (add_may_alias): Remove pointer-set. Update for may_aliases being + a bitmap. + (mark_aliases_call_clobbered): Update for may_aliases being a + bitmap. + (compute_tag_properties): Ditto. + (create_partition_for): Ditto. + (compute_memory_partitions): Ditto. + (dump_may_aliases_for): Ditto. + (is_aliased_with): Ditto. + (add_may_alias_for_new_tag): Ditto. + (rewrite_alias_set_for): Rewrite for may_aliases being a bitmap. + (compute_is_aliased): New function. + (compute_may_aliases): Call compute_is_aliased). + (init_alias_info): Initialize alias_bitmap_obstack. + (union_alias_set_into): New function. + (compute_flow_sensitive_aliasing): Use union_aliases_into. + (have_common_aliases_p): Rewrite to take two bitmaps and use + intersection. + (compute_flow_insensitive_aliasing): Stop using pointer-sets. + Update for bitmaps. + (finalize_ref_all_pointers): Update for add_may_alias changes. + (new_type_alias): Ditto. + * tree-flow-inline.h (may_aliases): Return a bitmap. + * tree-dfa.c (dump_variable): Check for MTAG_P'ness. + * tree-ssa.c (verify_flow_insensitive_alias_info): Update for + may_aliases being a bitmap. + * tree-flow.h (struct var_ann_d): Remove may_aliases member. + may_aliases now returns a bitmap. + * tree-ssa-structalias.c (merge_smts_into): Update for may_aliases + being a bitmap. + * tree-ssa-operands.c (add_virtual_operand): Update for + may_aliases being a bitmap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
[Bug middle-end/31094] Support annotating function parameters as read-only and/or non-escaping
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 10:33 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, rguenth at gcc dot gnu ||dot org, dnovillo at redhat ||dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-09 10:33:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31094
[Bug middle-end/31096] a*C == b*C where C is a constant is not optimized to a == b
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 10:35 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-09 10:35:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31096
[Bug middle-end/31097] a/C == b/C is not foldded to a == b with --fast-math/floating point
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 10:36 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-09 10:36:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31097
[Bug middle-end/31098] a*C == b*C is not foldded to a == b with --fast-math/floating point
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 10:37 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-09 10:37:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31098
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #29 from baldrick at free dot fr 2007-03-09 10:41 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails Sure, it's just that overloading V_C_E like this feels somehow wrong to me. Why? It's not overloading. V_C_E of an expression E of type X to type Y means interpret the bits of E as if it were type Y and not type X. If Y is X'Base, then interpreting E as being Y means that it can now have all the values of Y. For example, after the view conversion it is legal to place a value in it that is in the range of Y but not of X. This is logical. What seems illogical to me is that by doing the V_C_E you are supposed to forget anything you had deduced about the bits before the conversion. For example, suppose you had deduced that the bits were all zero. After the V_C_E the bits will still be zero - are you really supposed to forget this information? Another example: suppose you had worked out somehow that the bits corresponded to an integer in the range 4..5. After the V_C_E this is still true - why is it logical to forget this information? You may well respond that you are only supposed to forget information you deduced from the range of the type, not information you worked out by some other means. But these cannot really be distinguished, c.f. VRP. In short, it is overloading because it means: consider this bunch of bits to be of the new type AND forget anything you ever deduced about them. In other words, we could only change a V_C_E to a NOP_EXPR if we can prove that the value of E is in range of *both* X and Y. Surely you only have to prove that it is in the range of Y, since if it is not in the range of X then you have a bounded error, and doing a NOP_EXPR should be perfectly legal. Of course, we still have a bit of a mess here in that the real point is a confusion between what in Ada is called a Bounded Error and C's notion of undefined (Ada's erroneous). But I think we can do better in this area: we just haven't gotten to take a really good look at it. However I haven't been able to put my finger on any technical obstacle to this use of V_C_E. Nor can I ... Actually I do have a technical objection, however it comes from my LLVM port and not mainline gcc. LLVM is lower level than gimple. Supposing types X and Y have eg 32 bits, then they both get mapped to LLVM's Int32 type. A V_C_E gets turned into nothing at all. There are no types with restricted ranges. Suppose x is a variable of type X. When a value is loaded into x I'm planning on generating the following LLVM code: x = value; assert(x = lower_bound_for_gcc_type x = upper_bound_for_gcc_type); I don't generate the assert when you do a V_C_E, so for example suppose there is a y = V_C_E(Y, x). This gets turned into: y = x; Since the optimizers have range info for x, they instantly deduce the same ranges for y as for x. Thus if you test for validity of y using valid = (y = lower_bound_for_gcc_type_X y = upper_bound_for_gcc_type-X); then the result is always true. How to get around this? The obvious method is to use an intrinsic, such as __builtin_nop. For the V_C_E I can then do: y = __builtin_nop(x); and all will be well. However, I only really need to use the __builtin_nop if I'm doing the V_C_E in order to implement 'Valid. For other uses of V_C_E it is unnecessary and gets in the way of optimization. So I would much rather that 'Valid directly made use of a builtin. Ciao, Duncan. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
--- Comment #8 from tbm at cyrius dot com 2007-03-09 10:52 --- I definitely think this should be an error, not a warning. I only saw this problem by luck. I'm compiling the entire Debian archive (ie 7000 packages) on IA64 with GCC 4.3 and I cannot look at every log file (especially when the build was successful). I only noticed this one because the program failed to compile later on and I looked at the log to see the error. Anyway, are there any other warning messages like this one? If so, I can search my log files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug rtl-optimization/31101] New: Problem with -funroll-all-loops
This testcase:
double t (double a, double b)
{
return fmod (a, b);
}
generates wrong code when compiled with -O2 -funroll-all-loops
(-ffast-math -fomit-frame-pointer is used here only for clarity):
:
fldl4(%esp)
fldl12(%esp)
fxch%st(1)
.L2:
fprem
fnstsw %ax
sahf
jnp .L22
fprem
fnstsw %ax
sahf
jnp .L22
fprem
jnp .L22
fprem
.p2align 4,,2
jnp .L22
fprem
.p2align 4,,5
jnp .L22
fprem
.p2align 4,,5
jnp .L22
fprem
.p2align 4,,5
jnp .L22
fprem
.p2align 4,,5
jp .L2
.p2align 4,,7
.L22:
fstp%st(1)
.p2align 4,,5
ret
Please note that from second iteration,fnstsw %ax and sahf are not present
anymore in the instruction stream. The problem starts in .159r.postreload RTL
dump, where missing instructions just vanish without NOTE_INSN_DELETED trace
from RTL insn stream, although they are still present in 158r.greg dump.
--
Summary: Problem with -funroll-all-loops
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31101
[Bug middle-end/31095] [4.3 Regression] ICE in expand_expr_real_1, at expr.c:8786
--- Comment #2 from tbm at cyrius dot com 2007-03-09 11:11 --- I've confirmed that this doesn't happen with 4.2.0 20070309. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31095
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #30 from rguenth at gcc dot gnu dot org 2007-03-09 11:11 --- Well, the only problem with V_C_E is that if you assert on the range of the base type like if (V_C_E X'Base (y) 5) abort(); that you still want VRP to infer that V_C_E X'Base (y) is = 5 after this check (to eliminate further checks). I believe this will not automatically happen at the moment because V_C_E X'Base (y) will not have the same ssa name assigned for evey occurance. But of course we will never know until the Ada FE people finally fix their frontend. All the mess would be way easier if the FE would not expose the subtypes to the middle-end... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2007-03-09 11:19 --- All the mess would be way easier if the FE would not expose the subtypes to the middle-end... I personally agree, but there is no clear consensus among the Ada maintainers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
--- Comment #9 from tbm at cyrius dot com 2007-03-09 11:21 --- This warning is really frequent. I can find 2200 warnings that mention const and same canonical type node for different types. Some don't mention const; I'll look at them and file separate bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
--- Comment #10 from ubizjak at gmail dot com 2007-03-09 11:22 --- (In reply to comment #8) Anyway, are there any other warning messages like this one? If so, I can search my log files. Yes, the one reported in PR middle-end/30666. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug c++/31027] [4.1/4.2/4.3 regression] Compiler segfaults in simple virtual inheritance situation
--- Comment #5 from v dot lesk at ic dot ac dot uk 2007-03-09 11:28 --- Can anyone suggest a workaround? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #32 from baldrick at free dot fr 2007-03-09 11:34 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails Well, the only problem with V_C_E is that if you assert on the range of the base type like if (V_C_E X'Base (y) 5) abort(); that you still want VRP to infer that V_C_E X'Base (y) is = 5 after this check (to eliminate further checks). I don't think this is a very serious problem. My understanding is that the checks can be divided into two classes: normal checks and validity checks. A normal check, such as when you do a type conversion, does not use a V_C_E, it just does: if (y new_type_lb || y new_type_ub) abort; new_var = (new_type) y; A validity check does: if (V_C_E X'Base (y) x_lb || V_C_E X'Base (y) x_ub) abort(); Note how it checks that x is in the range of x's type, so this does not give any new information about x. It is true that multiple validity checks will not be eliminated (multiple normal checks will be eliminated), but validity checks are not that common. One place that might hurt is in array accesses: IIRC the front-end does a validity check on the index before accessing an array, rather than a normal check, because it considers it too dangerous to do otherwise (eg: they want to catch the case when the index has an out-of-range value because it is uninitialized). My suggested use of a builtin would allow multiple redundant validity checks to be safely eliminated, because the builtin would be a pure function. The validity check becomes: y2 = __builtin_nop(y); if (y2 x_lb || y2 x_ub) abort(); Now suppose you do another one: y22 = __builtin_nop(y); if (y22 x_lb || y22 x_ub) abort(); The compiler can deduce that y2 and y22 are the same, and eliminate the second check. I believe this will not automatically happen at the moment because V_C_E X'Base (y) will not have the same ssa name assigned for evey occurance. But of course we will never know until the Ada FE people finally fix their frontend. All the mess would be way easier if the FE would not expose the subtypes to the middle-end... I agree. The LLVM model seems more sensible in this regard. D. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #33 from baldrick at free dot fr 2007-03-09 11:50 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails My suggested use of a builtin would allow multiple redundant validity checks to be safely eliminated, because the builtin would be a pure function. This is presumably also the case with V_C_E. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug middle-end/31096] a*C == b*C where C is a constant is not optimized to a == b
--- Comment #2 from joseph at codesourcery dot com 2007-03-09 12:06 ---
Subject: Re: New: a*C == b*C where C is a constant
is not optimized to a == b
On Fri, 9 Mar 2007, pinskia at gcc dot gnu dot org wrote:
The following two functions should be equzlivant when overflow is undefined:
int f(int a, int b)
{
return a * 10 == b*10;
}
int f1(int a, int b)
{
return a==b;
}
If the constant is odd, they are equivalent for wrapping (but not for
trapping) and for unsigned as well.
(If the constant is 0, they aren't equivalent at all but the first should
become return 1;.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31096
[Bug c++/31102] New: ICE with -O2 -ftracer
cat bug.cc
inline double f(double) {
int t;
asm(fldcw %0 : : m(t));
}
double a;
void g(unsigned long long c) {
double b = c;
a = f(b) ? b : b - a;
}
g++ -O2 -ftracer bug.cc
bug.cc: In function 'void g(long long unsigned int)':
bug.cc:9: internal compiler error: Segmentation fault
g++ --version
g++ (GCC) 4.3.0 20070309 (experimental)
--
Summary: ICE with -O2 -ftracer
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at pi dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31102
[Bug c++/31102] ICE with -O2 -ftracer
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-09 12:10:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31102
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
--- Comment #11 from tbm at cyrius dot com 2007-03-09 12:13 --- Another problem is that this warning does not always occur, even when I use the same source and options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug libfortran/31099] [4.3/4.2 regression] Runtime error on legal code using RECL
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-09 12:29 ---
The error setting happens in io/transfer.c's write_buf:
/* Unformatted sequential. */
have_written = 0;
if (dtp-u.p.current_unit-flags.has_recl
(gfc_offset) nbytes dtp-u.p.current_unit-bytes_left)
{
printf(write_buf: has_recl=%d, nbytes=%ld, bytes_left=%ld\n,
dtp-u.p.current_unit-flags.has_recl, nbytes,
dtp-u.p.current_unit-bytes_left);
nbytes = dtp-u.p.current_unit-bytes_left;
short_record = 1;
}
else
short_record = 0;
My added printf shows:
write_buf: has_recl=1, nbytes=4, bytes_left=0
The check was added in Thomas' record length patch PR 29568.
http://gcc.gnu.org/viewcvs/trunk/libgfortran/io/transfer.c?r1=119087r2=119412diff_format=h
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org, tkoenig at gcc dot gnu
||dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
[Bug tree-optimization/30904] VRP does not track values of shifts and/or bitfields?
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-03-09 12:29 --- Subject: Bug 30904 Author: rguenth Date: Fri Mar 9 12:29:09 2007 New Revision: 122748 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122748 Log: 2007-03-09 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/30904 PR middle-end/31058 * tree-vrp.c (extract_range_from_binary_expr): Handle RSHIFT_EXPR the same way as *_DIV_EXPR. * gcc.dg/pr30904.c: Remove xfail. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr30904.c trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30904
[Bug middle-end/31058] overflow warnings should not be enabled with -Wall
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-03-09 12:29 --- Subject: Bug 31058 Author: rguenth Date: Fri Mar 9 12:29:09 2007 New Revision: 122748 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122748 Log: 2007-03-09 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/30904 PR middle-end/31058 * tree-vrp.c (extract_range_from_binary_expr): Handle RSHIFT_EXPR the same way as *_DIV_EXPR. * gcc.dg/pr30904.c: Remove xfail. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr30904.c trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug tree-optimization/30904] VRP does not track values of shifts and/or bitfields?
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-09 12:29 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30904
[Bug middle-end/31058] overflow warnings should not be enabled with -Wall
--- Comment #25 from rguenth at gcc dot gnu dot org 2007-03-09 12:30 --- The original issue is fixed. The rest belongs in a different bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||30904 Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 Bug 31058 depends on bug 30904, which changed state. Bug 30904 Summary: VRP does not track values of shifts and/or bitfields? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30904 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug c++/30822] wrong choice of overloaded template functions in recursive call
--- Comment #6 from Zarathustra at gentlemansclub dot de 2007-03-09 12:35
---
(In reply to comment #5)
So, the way I read this is that gcc3.3 and icc9.0 agree that the call is
ambiguous. I must admit that I don't know whether this is the correct
behavior.
Also the SunCC yields the ambiguity message. I think in all such cases the
compilers do not implement all rules for the look up of template names as given
by the standard. Probably starting from version 3.4.0 of gcc the error message
changes.
Perhaps it is worth taking a look at the following code:
One template argument is left away, and some are added.
foo2 is accepted, foo3 is not! From this I assume that there is some problem
with the implementation of the argument-dependent lookup (ADP) in gcc. Does
anyone have any other assumptions?
struct cons_end {};
templatetypename U,typename V struct cons {
U elem;
V tail;
};
templatetypename U, typename V
void foo2(U elem, V tail)
{
foo2(tail.elem,tail.tail);
}
templatetypename U
void foo2(U elem, cons_end tail)
{}
templatetypename U, typename V
void foo3(U elem, V tail)
{
foo3(tail.elem,tail.tail); // -- the difference is here ( added)
}
templatetypename U
void foo3(U elem, cons_end tail)
{}
int main()
{
consint,consint,cons_end list;
foo2(list.elem,list.tail);
foo2(list.elem,list.tail);
foo3(list.elem,list.tail);
}
The error message (from gcc 4.1.2 and gcc 4.3):
test_gccbug.cpp: In function void foo3(U, V) [with U = int, V = cons_end]:
test_gccbug.cpp:32: instantiated from void foo3(U, V) [with U = int, V =
consint, cons_end]
test_gccbug.cpp:44: instantiated from here
test_gccbug.cpp:32: error: struct cons_end has no member named elem
test_gccbug.cpp:32: error: struct cons_end has no member named tail
Volker
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30822
[Bug rtl-optimization/30643] [4.1/4.2/4.3 regression] CSE pessimization
--- Comment #11 from patchapp at dberlin dot org 2007-03-09 12:40 --- Subject: Bug number PR30643 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00545.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30643
[Bug c++/31103] New: [4.3 Regression] same canonical type node for different types with long int
warning: same canonical type node for different types - with long int % /usr/lib/gcc-snapshot/bin/g++ -c -g -O2 icu-dtfmtsym.ii dtfmtsym.cpp: In member function 'void icu_3_6::DateFormatSymbols::setMonths(const icu_3_6::UnicodeStr ing*, int32_t, icu_3_6::DateFormatSymbols::DtContextType, icu_3_6::DateFormatSymbols::DtWidthType)': dtfmtsym.cpp:738: warning: same canonical type node for different types icu_3_6::UnicodeString [(long int)iftmp.95] and icu_3_6::UnicodeString [(long int)iftmp.95] array_type 0x2b142b100600 type record_type 0x2b142b13b600 UnicodeString sizes-gimplified addressable asm_written tree_2 nee ds-constructing type_1 type_4 type_5 type_6 BLK size integer_cst 0x2b142ab7be40 constant invariant 320 unit size integer_cst 0x2b142ab831e0 constant invariant 40 align 64 symtab 722782848 alias set 4 canonical type 0x2b142b13b600 fields field_decl 0x2b142b1b2000 D.4165 type record_type 0x2b142b13b6c0 Replaceable ignored decl_6 BLK file ../common/unicode/unistr.h line 188 size integer_cst 0x2b142aa0fb70 constant invariant 64 unit size integer_cst 0x2b142aa0fba0 constant invariant 8 align 64 offset_align 128 offset integer_cst 0x2b142aa0f720 constant invariant 0 bit offset integer_cst 0x2b142aa30360 constant invariant 0 context record_type 0x2b142b 13b600 UnicodeString chain const_decl 0x2b142b152280 kInvariant context namespace_decl 0x2b142b11 a340 icu_3_6 needs-constructor needs-destructor X() X(constX) new new[] delete delete[] this=(X) n_parents =1 use_template=0 interface-only pointer_to_this pointer_type 0x2b142b1739c0 reference_to_this reference_type 0x2b142b13f240 chain type_decl 0x2b142b11add0 UnicodeString needs-constructing type_4 BLK size mult_expr 0x2b142b593080 type integer_type 0x2b142aa210c0 bit_size_type public unsigned sizetype DI size integer_cst 0x2b142aa0fb70 64 unit size integer_cst 0x2b142aa0fba0 8 align 64 symtab 0 alias set -1 canonical type 0x2b142aa21e40 precision 64 min integer_cst 0x2b142aa30360 0 max integer_cst 0x2b142aa30330 18446744073709551615 side-effects invariant arg 0 nop_expr 0x2b142b5930c0 type integer_type 0x2b142aa210c0 bit_size_type side-effects invariant ... -- Summary: [4.3 Regression] same canonical type node for different types with long int Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31103
[Bug c++/31103] [4.3 Regression] same canonical type node for different types with long int
--- Comment #1 from tbm at cyrius dot com 2007-03-09 12:46 --- Created an attachment (id=13176) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13176action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31103
[Bug c++/31104] New: [4.3 Regression] same canonical type node for different types with anonymous
warning: same canonical type node for different types - anonymous % /usr/lib/gcc-snapshot/bin/g++ -c -g -O2 dosbox-sdl_mapper.ii sdl_mapper.cpp: In function 'void CreateBindGroups()': sdl_mapper.cpp:1554: warning: same canonical type node for different types CBindList [(long int)anonymous] and CBindList [(long int)anonymous] array_type 0x2b3867154000 type record_type 0x2b3867280f00 CBindList addressable asm_written needs-constructing type_1 type_ 4 type_5 BLK size integer_cst 0x2b3865ae9de0 constant invariant 128 unit size integer_cst 0x2b3865ae9e10 constant invariant 16 align 64 symtab 1730749184 alias set -1 canonical type 0x2b3867280e40 fields field_decl 0x2b38673460c0 D.26723 type record_type 0x2b38672d86c0 _List_base ignored decl_6 BLK file /usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.3.0/../../../../i nclude/c++/4.3.0/bits/stl_list.h line 408 size integer_cst 0x2b3865ae9de0 128 unit size integer_cst 0x2b3865ae9e10 16 align 64 offset_align 128 offset integer_cst 0x2b3865ae9720 constant invariant 0 bit offset integer_cst 0x2b3865b0a360 constant invariant 0 context record_type 0x2b3867 280e40 list chain type_decl 0x2b3867314410 list context namespace_decl 0x2b3865b080d0 std needs-constructor needs-destructor X() X(constX) this=(X) n_parents=1 use_template=1 interfac e-unknown pointer_to_this pointer_type 0x2b386735f600 reference_to_this reference_type 0x2b38673ae600 chain type_decl 0x2b386727f410 list needs-constructing type_4 BLK size mult_expr 0x2b3867368980 type integer_type 0x2b3865afb0c0 bit_size_type public unsigned sizetype DI size integer_cst 0x2b3865ae9b70 constant invariant 64 unit size integer_cst 0x2b3865ae9ba0 constant invariant 8 align 64 symtab 0 alias set -1 canonical type 0x2b3865afbe40 precision 64 min integer_cst 0x2b3865b0a360 0 max integer_cst 0x2b3865b0a330 18446744073709551615 side-effects invariant ... -- Summary: [4.3 Regression] same canonical type node for different types with anonymous Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31104
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
--- Comment #12 from tbm at cyrius dot com 2007-03-09 12:49 --- PR31103 - same canonical type node for different types with long int PR31104 - same canonical type node for different types with anonymous -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug c++/31104] [4.3 Regression] same canonical type node for different types with anonymous
--- Comment #1 from tbm at cyrius dot com 2007-03-09 12:50 --- Created an attachment (id=13177) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13177action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31104
[Bug libfortran/31099] [4.3/4.2 regression] Runtime error on legal code using RECL
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-09 12:55 ---
I was checking where bytes_left is set:
open.c: u-bytes_left = 0;
This is the default setting in new_unit (/* Open an unused unit. */)
It is also set to 0 in file_pos.c (two places).
In list_read.c's next_char it is set to current_unit-recl;
And in transfer.c:
- read_block
- write_block (but only if stdout/stderr or default reclen, otherwise a
ERROR_EOR error is generated, but this is not the error of this PR.)
- us_read
- us_write: This one is also not called for this PR
- next_record_w: Not for unformatted
The problem seems to be that bytes_left == 0 from the initial setting in
new_unit as no data has been written. And as 4bytes have to be written, nbytes
= 4 bytes_left.
Note: The same problem occurs if one tries to read from a file which has been
written by gfortran-4.1. In this case the error condition is in:
transfer.c's read_block_direct:
if (dtp-u.p.current_unit-flags.has_recl)
{
to_read_record =
*nbytes (size_t) dtp-u.p.current_unit-bytes_left ?
*nbytes : (size_t) dtp-u.p.current_unit-bytes_left;
short_record = 1;
}
else
{
to_read_record = *nbytes;
short_record = 0;
}
This check has been introduced by the same patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
[Bug c++/31103] [4.3 Regression] same canonical type node for different types with long int
--- Comment #2 from tbm at cyrius dot com 2007-03-09 13:06 --- Created an attachment (id=13178) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13178action=view) testcase I should mention that this warning doesn't show up all the time, but it'll eventually show when you try long enough. This applies both to the smaller testcase and the original preprocessed source. See e.g. here: (sid)4419:[EMAIL PROTECTED]: ~] rm -f icu*.o; g++ -c -g -O2 icu*.cc x 21 ; ls -l x -rw-r--r-- 1 tbm users 0 2007-03-09 13:00 x (sid)4420:[EMAIL PROTECTED]: ~] rm -f icu*.o; g++ -c -g -O2 icu*.cc x 21 ; ls -l x -rw-r--r-- 1 tbm users 0 2007-03-09 13:00 x (sid)4421:[EMAIL PROTECTED]: ~] rm -f icu*.o; g++ -c -g -O2 icu*.cc x 21 ; ls -l x -rw-r--r-- 1 tbm users 0 2007-03-09 13:00 x (sid)4422:[EMAIL PROTECTED]: ~] rm -f icu*.o; g++ -c -g -O2 icu*.cc x 21 ; ls -l x -rw-r--r-- 1 tbm users 55766 2007-03-09 13:00 x (sid)4423:[EMAIL PROTECTED]: ~] head -3 x icu-dtfmtsym.cc: In member function 'void icu_3_6::DateFormatSymbols::initZoneStrings(UErrorCode)': icu-dtfmtsym.cc:166: warning: same canonical type node for different types icu_3_6::UnicodeString [(long int)iftmp.10] and icu_3_6::UnicodeString [(long int)iftmp.10] array_type 0x2b9eeb353a80 (sid)4424:[EMAIL PROTECTED]: ~] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31103
[Bug driver/31087] gcc 323 reports output filename specified twice error for simple x.c compilation
--- Comment #2 from droessle at us dot ibm dot com 2007-03-09 13:25 --- Thanks for the direction. I will take the issue up at RH. -- droessle at us dot ibm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31087
[Bug c/31105] New: build broken (trunk rev 122742)
/home/Marco/Desktop/compile-lin-lin/gcc-build/./prev-gcc/xgcc -B/home/Marco/Desktop/compile-lin-lin/gcc-build/./prev-gcc/ -B/home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror-DHAVE_CONFIG_H -I. -I. -I/usr/local/src/gcc/gcc -I/usr/local/src/gcc/gcc/. -I/usr/local/src/gcc/gcc/../include -I/usr/local/src/gcc/gcc/../libcpp/include -I/home/Marco/Desktop/compile-lin-lin/gmp-out/include -I/home/Marco/Desktop/compile-lin-lin/mpfr-out/include -I/usr/local/src/gcc/gcc/../libdecnumber -I../libdecnumber /usr/local/src/gcc/gcc/recog.c -o recog.o cc1: warnings being treated as errors /usr/local/src/gcc/gcc/recog.c: In function 'decode_asm_operands': /usr/local/src/gcc/gcc/recog.c:1558: error: ISO C90 forbids mixed declarations and code /usr/local/src/gcc/gcc/recog.c:1600: error: ISO C90 forbids mixed declarations and code make[3]: *** [recog.o] Error 1 make[3]: Leaving directory `/home/Marco/Desktop/compile-lin-lin/gcc-build/gcc' This strongly remembers me to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510 Is it possible that some flags trigger the warnings being treated as errors but most developers don't use this? That would explain why people stumble over it while it seems to work after changes for the developers?! I configured with: /usr/local/src/gcc/configure --prefix=/home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin --with-sysroot=/home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/sys-root --build=`/usr/local/src/gcc/config.guess` --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --enable-languages=c,c++,java --enable-libgcj --disable-shared --with-gnu-as --with-gnu-ld --disable-nls --disable-debug --disable-checking --enable-threads=posix --disable-win32-registry --enable-java-gc=boehm --enable-java-maintainer-mode --with-gmp=/home/Marco/Desktop/compile-lin-lin/gmp-out --with-mpfr=/home/Marco/Desktop/compile-lin-lin/mpfr-out -- Summary: build broken (trunk rev 122742) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mtrudel at gmx dot ch GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31105
[Bug c++/31106] New: FPE, floating point exception bugs
1) fesetexcept(FE_EXCEPT_ALL) sets the control fpu control word to 0x342, so that the denormal operand exeption is masked, by definition all exceptions are supposed to be enabled so it should be using 0x340. 2) If I establish a signal handler for FPEs the fpu is being reset to its default state before the signal handler is called, so that fegetexcept and fegetenv are unable to return any information about the exception that occured. here is information about my FC2 x86_64 athlon system: [EMAIL PROTECTED] burlen]$ g++ -v Reading specs from /usr/lib/gcc-lib/x86_64-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=x86_64-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Summary: FPE, floating point exception bugs Product: gcc Version: 3.3.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burlen at apollo dot sr dot unh dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31106
[Bug c++/31106] FPE, floating point exception bugs
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 13:58 --- These are all not compiler issues but glibc and/or kernel issues. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31106
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #34 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09 13:59 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails You may well respond that you are only supposed to forget information you deduced from the range of the type, not information you worked out by some other means. But these cannot really be distinguished, c.f. VRP. Exactly. That's indeed the problem. It's similar to the whole signed-overflow issue: what you're able to safely do with with VRP-derived information depends on how you derived it and there's no way of tracking that. Surely you only have to prove that it is in the range of Y, since if it is not in the range of X then you have a bounded error, and doing a NOP_EXPR should be perfectly legal. Think of a range check being done in a subscript reference in the LHS of an assignment. A bounded error is not allowed to cause a memory store outside the bounds of an array. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug c/31105] build broken (trunk rev 122742)
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 13:59 --- Fixed by http://gcc.gnu.org/viewcvs?root=gccview=revrev=122746 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31105
[Bug rtl-optimization/31101] Problem with -funroll-all-loops
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 14:03 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-09 14:03:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31101
[Bug boehm-gc/29476] [cygwin] gcc compilation is broken
--- Comment #3 from mtrudel at gmx dot ch 2007-03-09 14:05 --- I close this bug as WONTFIX because there's no active cygwin maintainer for libjava. So, if it's not fixed already, it probably won't be fixed anyway. I just once tested it for fun :-) -- mtrudel at gmx dot ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29476
[Bug c/31105] build broken (trunk rev 122742)
--- Comment #2 from mtrudel at gmx dot ch 2007-03-09 14:12 --- Thanks. But actually I also tried to start a discussion why such compilation errors can happen: This strongly remembers me to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510 Is it possible that some flags trigger the warnings being treated as errors but most developers don't use this? That would explain why people stumble over it while compilation seems to work for the developers?! Of course I could be completely wrong. But if I'm right, there would be an easy way to prevent such build breaks... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31105
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #35 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09 14:18 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails All the mess would be way easier if the FE would not expose the subtypes to the middle-end... I don't see how giving *additional* information could be bad: the middle-end is certainly free to ignore the bounds if it wants to! The point is that the bounds *do* say something and provide useful information to optimizers. The problem is that they don't say what the middle-end *wants* them to say! What they *do* mean is that it's a bounded error for a variable to have a value outside of the given bounds. What the middle-end *wants* them to mean is that it's *erroneous* for a variable to have a value outside of the given bounds. We need to reconcile those two concepts. From a pragmatic point of view, they aren't that different, but there are a couple of important exceptions. The array bound on the LHS is one of them. A full solution to this is complex, but is indeed something that I'd like to happen some day. It involves work in various places. One thing that would help is that many variables can be proven to have the property that the only way they can have an invalid value is if erroneous behavior has occurred. For such variables, the meaning of the bounds is precisely what the middle-end expects it to mean. The most common case where you can't do this is for component references or pointer dereferences. In that case, we have to address this by distinguishing between two types of tests, those that will just propagate the bounded error condition and those that would convert a bounded error to erroneous behavior. We are allowed to use the bounds information in reasoning about the former, but not the latter. Note that there are similarities to the signed-overflow case here: there are some tests that we can safely eliminate with knowlege that signed-overflow is undefined, but others that we don't want to. So I think the final solution here will be to have the Ada front end provide the flag information on variables and tests mentioned above and extend VRP to use them. One of the two front-end issues (the latter) is quite easy and I think the other is moderately-easy. I don't know how much work the required VRP changes would be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #36 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09 14:29 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails I don't think this is a very serious problem. My understanding is that the checks can be divided into two classes: normal checks and validity checks. A normal check, such as when you do a type conversion, does not use a V_C_E, it just does: if (y new_type_lb || y new_type_ub) abort; new_var = (new_type) y; Not clear. Consider the range check for a subscript on the LHS, for example. These issues are *very* subtle ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug c++/31103] [4.3 Regression] same canonical type node for VLAs
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 Regression] same |[4.3 Regression] same |canonical type node for |canonical type node for VLAs |different types with long | |int | Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31103
[Bug driver/31107] New: --target-help doesn't say which options are compiler, assembler or linker options
--target-help shows compiler, assembler and linker options together, without saying which is which. It can confuse users (see PR31073 for example). Example: on i686-pc-linux-gnu, with mainline: $ gcc --target-help | tail -n 35 -mtune= Schedule code for given CPU -muclibcUse uClibc instead of GNU libc -Q ignored -V print assembler version number -k ignored -n Do not optimize code alignment -q quieten some warnings -s ignored --divideignored elf_i386: -Bgroup Selects group name lookup rules for DSO --disable-new-dtags Disable new dynamic tags --enable-new-dtagsEnable new dynamic tags --eh-frame-hdrCreate .eh_frame_hdr section -z combreloc Merge dynamic relocs into one section and sort -z defs Report unresolved symbols in object files. -z execstack Mark executable as requiring executable stack -z initfirst Mark DSO to be initialized first at runtime -z interpose Mark object to interpose all DSOs but executable -z loadfltr Mark object requiring immediate process -z muldefsAllow multiple definitions -z nocombrelocDon't merge dynamic relocs into one section -z nocopyrelocDon't create copy relocs -z nodefaultlib Mark object not to use default search paths -z nodelete Mark DSO non-deletable at runtime -z nodlopen Mark DSO not available to dlopen -z nodump Mark DSO not available to dldump -z noexecstackMark executable as not requiring executable stack -z norelroDon't create RELRO program header -z nowMark object non-lazy runtime binding -z origin Mark object requiring immediate $ORIGIN processing at runtime -z relro Create RELRO program header -z KEYWORDIgnored for Solaris compatibility The first options displayed above are the last of the compiler options, followed (without any explicit mention) by the assembler options, and the linker options. Users then want to try an option in the list, and it doesn't work: $ gcc --eh-frame-hdr a.c cc1: error: unrecognized command line option -feh-frame-hdr -- Summary: --target-help doesn't say which options are compiler, assembler or linker options Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31107
[Bug driver/31107] --target-help doesn't say which options are compiler, assembler or linker options
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.1 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-09 15:18:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31107
[Bug target/31073] symbol names are not created with stdcall syntax
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-03-09 15:23 --- (In reply to comment #6) when typing gfortran --target-help those options are all listed as compiler options. We all agree it's a bug: compiler, assembler and linker options are listed there indifferently. I filed it as a different PR (PR 31107) so that we don't get too confused. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31073
[Bug driver/31107] --target-help doesn't say which options are compiler, assembler or linker options
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-09 15:23 --- I think gas should be fixed instead of the driver. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31107
[Bug boehm-gc/29476] [cygwin] gcc compilation is broken
--- Comment #4 from manu at gcc dot gnu dot org 2007-03-09 15:30 --- (In reply to comment #3) I close this bug as WONTFIX because there's no active cygwin maintainer for libjava. So, if it's not fixed already, it probably won't be fixed anyway. I just once tested it for fun :-) Hum, perhaps someone will step in in the future... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29476
[Bug ada/31108] New: [regression 4.2] ACATS C35507M fails on MinGW
The ACATS failure occurs with gcc-4.2-20070307 bootstrapped from gcc-4.2-20061226. I was not able to build any 4.0 or 4.1 Ada compiler on MinGW, so this is a regression against gcc-3.4. ,.,. C35507M ACATS 2.5 07-03-09 15:15:52 C35507M CHECK THAT THE ATTRIBUTES 'POS' AND 'VAL' YIELD THE CORRECT RESULTS WHEN THE PREFIX IS A CHARACTER TYPE WITH AN ENUMERATION REPESENTATION CLAUSE. * C35507M NO EXCEPTION RAISED FOR CHAR'VAL (IDENT_INT(2)) - 2. * C35507M NO EXCEPTION RAISED FOR NEWCHAR'VAL (IDENT_INT (-1)) - 2. C35507M FAILED . -- Summary: [regression 4.2] ACATS C35507M fails on MinGW Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rolf dot ebert dot gcc at gmx dot de GCC host triplet: mingw32 GCC target triplet: mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31108
[Bug c/17946] wanted: warning for a MASK when a MASK was probably intended
--- Comment #13 from mueller at gcc dot gnu dot org 2007-03-09 16:16 --- Subject: Bug 17946 Author: mueller Date: Fri Mar 9 16:16:35 2007 New Revision: 122751 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122751 Log: 2007-03-09 Dirk Mueller [EMAIL PROTECTED] PR c++/17946 * doc/invoke.texi (-Wlogical-op): Document. * common.opt (-Wlogical-op): New. * c-common.h (warn_logical_operator): Declare. * c-common.c (warn_logical_operator): Define. * c-typeck.c (parser_build_binary_op): Call warn_logical_operator. * cp/call.c (build_new_op): Call warn_logical_operator. * testsuite/gcc.dg/Wlogical-op-1.c: New. * testsuite/g++.dg/warn/Wlogical-op-1.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/Wlogical-op-1.C trunk/gcc/testsuite/gcc.dg/Wlogical-op-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-common.h trunk/gcc/c-typeck.c trunk/gcc/common.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17946
[Bug c/17946] wanted: warning for a MASK when a MASK was probably intended
--- Comment #14 from mueller at gcc dot gnu dot org 2007-03-09 16:17 --- Fixed for 4.3. -- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17946
[Bug c/31109] New: gcc 3.3 not functioning under Interix 3.5
gcc 3.3 is working fine in Interix (Services for Unix under Windows) on other Windows XP machines that I use (both laptop and desktop) A new installation of SFU35SEL_EN.exe (SFU/Interix) on a new IBM ThinkPad laptop with Centrino Duo procesor does not seem to allow compilation of any program (I for instance tried the well-known dedos program). The system description is: Interix 3.5 SP-8.0.1969.1 x86 Intel_x86_Family6_Model15_Stepping6 while the reported error message (in response to: gcc dedos.c) is: gcc; Internal error: Segmentation fault (program cc1) -- Summary: gcc 3.3 not functioning under Interix 3.5 Product: gcc Version: 3.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: j dot b dot o dot s dot martens at tue dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31109
[Bug target/31109] gcc 3.3 not functioning under Interix 3.5
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31109
[Bug target/30987] [4.3 Regression] Problem while compiling gcc for score
--- Comment #4 from mstein at phenix dot rootshell dot be 2007-03-09 17:05 --- Created an attachment (id=13179) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13179action=view) from SVN revision: 122728 Commandline used to create libgcc2.i: /home/mstein/sim/score-elf/build/./gcc/xgcc -B/home/mstein/sim/score-elf/build/./gcc/ -nostdinc -B/home/mstein/sim/score-elf/build/score-elf/newlib/ -isystem /home/mstein/sim/score-elf/build/score-elf/newlib/targ-include -isystem /n/07/mstein/combined-trunk/newlib/libc/include -B/n/07/mstein/cross-local/score-elf-new/score-elf/bin/ -B/n/07/mstein/cross-local/score-elf-new/score-elf/lib/ -isystem /n/07/mstein/cross-local/score-elf-new/score-elf/include -isystem /n/07/mstein/cross-local/score-elf-new/score-elf/sys-include -L/home/mstein/sim/score-elf/build/./ld -O2 -g -O2 -mmac -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -G 0 -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/n/07/mstein/combined-trunk/libgcc -I/n/07/mstein/combined-trunk/libgcc/. -I/n/07/mstein/combined-trunk/libgcc/../gcc -I/n/07/mstein/combined-trunk/libgcc/../include -I/n/07/mstein/combined-trunk/libgcc/../libdecnumber -I../../../libdecnumber -o _floatdisf.o -MT _floatdisf.o -MD -MP -MF _floatdisf.dep -DL_floatdisf -c /n/07/mstein/combined-trunk/libgcc/../gcc/libgcc2.c \ -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30987
[Bug target/31073] symbol names are not created with stdcall syntax
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-09 17:05 --- This is not that much of a blocker, really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31073
[Bug target/31073] symbol names are not created with stdcall syntax
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-09 17:08 --- In fact this is an enhancement and really there just needs a new win32 option for this feature. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|GNU Fortran 95 (GCC) 4.3.0 | |20061021 (experimental) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31073
[Bug tree-optimization/31090] Revision 121302 causes 30% performance regression
--- Comment #3 from hjl at lucon dot org 2007-03-09 17:11 --- Gcc 4.3 revision 122738 has the same issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
[Bug c/31105] build broken (trunk rev 122742)
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-09 17:14 --- Of course I could be completely wrong. But if I'm right, there would be an easy way to prevent such build breaks... People make mistakes, this was just one of them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31105
[Bug tree-optimization/31090] Revision 121302 causes 30% performance regression
--- Comment #4 from hjl at lucon dot org 2007-03-09 17:40 --- Created an attachment (id=13180) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13180action=view) A breakdown testcase xxx.f90 is the problem. -fdump-tree-all shows that revision 121302 generates very different alias info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
