[Bug target/30484] Miscompilation of remainder expressions on CPUs of the i386 family
--- Comment #6 from veksler at il dot ibm dot com 2007-01-17 08:49 --- (In reply to comment #0) The program below shows (at all the optimization levels) a miscompilation of the remainder expression that causes INT_MIN % -1 to cause a SIGFPE on CPUs of the i386 family. For the record on Linux i386, this was my suggestion for the best performing work-around (fastest at least for all cases other than INT_MIN % -1). Intercept SIGFPE, and if it comes from idivl then set the remainder to 0, and the quotient to INT_MIN (in C/C++ we are allowed to do this because INT_MIN/-1 is undefined). There are several technical problems to this suggestion: (1) To avoid interference with user assembly code that expects SIGFPE in case of INT_MIN/-1 (e.g. -ftrapv), the compiler will have to mark this idivl in some special way (e.g. add some useless prefixes, or write something in one of the ELF sections). (2) Who should intercept SIGFPE? User space or kernel? (2.1) User space is much more complicated, because it might interfere with other user set SIGFPE signal handlers. libgcc would have to chain the signal handlers. (2.2) If implemented in the kernel then it will take much more time to see this change propagate to all users. This also means that BSD,Hurd and cygwin will all have to use a different fix, each. -- veksler at il dot ibm dot com changed: What|Removed |Added CC||veksler at il dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #10 from bugzilla at bennee dot com 2007-01-17 10:35 --- (In reply to comment #9) (In reply to comment #4) Testcase compiles OK with gcc version 4.3.0 20070115 (experimental). Uh, I was compiling in 32bit mode. For x86_64 compilation fails as documented in comment #3. What glibc version do you have? And what platform are you building on? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug fortran/30476] [Regression 4.2, 4.3] Via other module imported generic interface rejected
--- Comment #2 from pault at gcc dot gnu dot org 2007-01-17 10:44 --- Confirmed. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-17 10:44:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30476
[Bug c/8268] no compile time array index checking
--- Comment #42 from mueller at gcc dot gnu dot org 2007-01-17 10:51 --- no, its going in real soon now (finally) :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug libstdc++/30464] [regression] -Wconversion triggers warnings for deque::push_back()
--- Comment #10 from gdr at cs dot tamu dot edu 2007-01-17 11:09 --- Subject: Re: [regression] -Wconversion triggers warnings for deque::push_back() pcarlini at suse dot de [EMAIL PROTECTED] writes: | Gaby, any news about the signed - unsigned warning itself? Are we going to | keep it or are we coming to the conclusion it's too noisy? Hi Paolo, Here is the key element we should think about, and why I think this specific warning is not useful. GCC supports only 2s complement targets. Given that, I don't see what this altering value diagnostoc is helping. I consider that a conversion from T to U may alter value if a round trip may give a different result back. E.g. Given U u = t; the assertion assert (T(u) == t); may fail for some value in T. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
[Bug target/29281] natPlainDatagramSocketImpl.cc:148: internal compiler error
--- Comment #9 from msvoboda at ra dot rockwell dot com 2007-01-17 11:12 --- Created an attachment (id=12913) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12913action=view) preprocessed file I crossed this error too. I'm attaching required preprocessed file. This bug occured during building big endian version for arm. Little endian was build correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29281
[Bug bootstrap/30136] bootstrap fail for 4.3-20061209
--- Comment #6 from dcb314 at hotmail dot com 2007-01-17 12:14 --- (In reply to comment #5) I can confirm this problem on recent snapshots as well (20070105 and 20070112). Agreed. Snapshot 20010112 goes wrong and it's definately the flag --with-cpu=opteron that causes the trouble. Looks like a broken machine description to me, but I could be wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30136
[Bug c++/30490] New: Segmentation fault for legal code with -O2
I just tried to compile package FlightGear-0.9.10-40 with the GNU C++ compiler version 4.3 snapshot 20070112. The compiler said replay.cxx: In function 'FGReplayData interpolate(double, FGReplayData, FGReplayData)': replay.cxx:224: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Here is some help from valgrind ==7400== Invalid read of size 8 ==7400==at 0x5C731A: finalize_ssa_vuses (tree-ssa-operands.c:553) ==7400==by 0x5C8047: finalize_ssa_stmt_operands (tree-ssa-operands.c:1169) ==7400==by 0x5C8D3D: update_stmt_operands (tree-ssa-operands.c:2357) ==7400==by 0x5D20C4: compute_may_aliases (tree-flow-inline.h:388) ==7400==by 0x905CC4: execute_one_pass (passes.c:951) ==7400==by 0x905EFB: execute_pass_list (passes.c:999) ==7400==by 0x905F0D: execute_pass_list (passes.c:1000) ==7400==by 0x58D0D1: tree_rest_of_compilation (tree-optimize.c:543) ==7400==by 0x4F0317: expand_body (semantics.c:3095) ==7400==by 0x95EF41: cgraph_expand_function (cgraphunit.c:989) ==7400==by 0x960F75: cgraph_optimize (cgraphunit.c:1052) ==7400==by 0x4924D4: cp_write_global_declarations (decl2.c:3347) ==7400== Address 0xAFAFAFAFAFAFAFAF is not stack'd, malloc'd or (recently) free'd Preprocessed source code attached. Flag -O2 required. -- Summary: Segmentation fault for legal code with -O2 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30490
[Bug c++/30490] Segmentation fault for legal code with -O2
--- Comment #1 from dcb314 at hotmail dot com 2007-01-17 12:17 --- Created an attachment (id=12914) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12914action=view) gzipped C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30490
[Bug c++/11856] unsigned warning in template
--- Comment #20 from tromey at gcc dot gnu dot org 2007-01-17 12:32 --- The particularity of such expressions is that they are constants. I've thought about this a bit but I don't have a real conclusion. I don't know why this warning was added in the first place... it seems like perhaps it was to deal with comparisons against constants. For instance comparing unsigned 0 or what have you. If this is the case (and we'd have to dig a bit to find out) then that would seem to argue against this approach. My interest here is template-oriented... I consider it from a generic programming point of view. I was trying to write a certain program in the generic style, and one particular template instantiation yielded a warning. One possible idea would be an expression attriute of some kind: __do_not_warn__ (val 0) I'm not extremely happy with this however. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #11 from ubizjak at gmail dot com 2007-01-17 12:39 --- (In reply to comment #10) What glibc version do you have? And what platform are you building on? GNU C Library development release version 2.3.6 2.6.17-1.2142_FC4smp on i686-pc-linux-gnu and x86_64-pc-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug driver/30491] New: behaviour with -MMD and -c / -E causes differring behaviours.
Checked this with gcc-3.4.6 and gcc 4.1.2 on an ubuntu edgy box.
[EMAIL PROTECTED]:~/try/bug$ cat makefile
all:
gcc-3.4 -c main.c -o obj-c/main.o -MMD -MF obj-c/main.d
gcc-3.4 -E main.c -o obj-E/main.i -MMD -MF obj-E/main.d
diff obj-c/main.d obj-E/main.d
[EMAIL PROTECTED]:~/try/bug$ cat main.c
#include aaa.h
int main(void)
{
return AAA;
}
gcc-3.4 -c main.c -o obj-c/main.o -MMD -MF obj-c/main.d
gcc-3.4 -E main.c -o obj-E/main.i -MMD -MF obj-E/main.d
diff obj-c/main.d obj-E/main.d
1c1
obj-c/main.o: main.c aaa.h
---
main.o: main.c aaa.h
Contents of obj-c and obj-E are
[EMAIL PROTECTED]:~/try/bug$ ls obj-c/
main.d main.o
[EMAIL PROTECTED]:~/try/bug$ ls obj-E/
main.d main.i
A workaround that we can do is to use the -MT with the option at the moment.
--
Summary: behaviour with -MMD and -c / -E causes differring
behaviours.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana dot radhakrishnan at codito dot com
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30491
[Bug c++/11856] unsigned warning in template
--- Comment #21 from gdr at cs dot tamu dot edu 2007-01-17 13:47 --- Subject: Re: unsigned warning in template tromey at gcc dot gnu dot org [EMAIL PROTECTED] writes: | The particularity of such expressions is that they are constants. | | I've thought about this a bit but I don't have a real conclusion. | | I don't know why this warning was added in the first place... it seems | like perhaps it was to deal with comparisons against constants. | For instance comparing unsigned 0 or what have you. If this is the | case (and we'd have to dig a bit to find out) then that would seem to | argue against this approach. I see what you mean. Let me think about it. | My interest here is template-oriented... I consider it from a generic | programming point of view. I was trying to write a certain program | in the generic style, and one particular template instantiation yielded | a warning. | | One possible idea would be an expression attriute of some kind: | | __do_not_warn__ (val 0) | | I'm not extremely happy with this however. neither am I. We have introduced a warning, the usefulness of which is questionable in this specific case; now, we would be forced to used non-standard constructs to get out of that questionable warning. Something must be wrong :-) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
[Bug tree-optimization/30334] Request for -Wundefined
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-17 13:47 --- Perhaps Wundefined should warn for PR 29465 ? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
[Bug tree-optimization/30334] Request for -Wundefined
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-17 13:49 --- Also, not sure whether Wundefined or Wsequence-points should handle PR 24016. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
[Bug tree-optimization/30334] Request for -Wundefined
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-17 13:52 --- Another candidate is PR 30457. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #9 from felix-gcc at fefe dot de 2007-01-17 13:55 --- Hey Andrew, do you really think this issue goes away if you keep closing the bugs fast enough? Let me tell you something: that INT_MAX way to do it is bogus. These checks are there so that it is obvious the int overflow is caught and handled. If you use INT_MAX, then the auditor still has to check if it was an int and not an unsigned int, for example. If that doesn't convince you, let's say it's not int, but it's ptrdiff_t. Or off_t. Or beancount_t, which the application defined somewhere. Then limits.h won't have a _MAX definition for it. What if the size of the type depends on the context as well? There are multiple definitions of it depending on some -Dwhatever on the command line? All these cases were covered just fine by the if (a+100 a) check. There is no context needed about the type of a, it works for pointers, unsigned integers, and signed integers. Well, you broke the pointer bit once, too, but that was reverted. The guy who reverted it back then should come back, we need someone with his vision and good judgement here now. No, let's face it. You fucked this up royally, and now you are trying to close all the bugs as fast as you can, so nobody sees just how much damage you have done. You, sir, are unprofessional and a disgrace to the gcc development team. And this bug stays open until you revert the change or make it opt-in instead of opt-out. As long as you just destroy programs where the author foolishly opted in, I don't care. But I will not let you make my work environment less secure because you don't have the professionalism to let your pet optimization go, after it was shown to do more damage than good. How much more proof do you need? For god's sake, autoconf considers turning your optimization off globally! Do you even notice all the explosions around you? PS: Mr Simon, that link to a how-to that says btw this doesn't work for this special input, is that supposed to impress anyone? It certainly does not impress me very much, really. It's better to keep your mouth shut and appear stupid than to open it and remove all doubt. --Mark Twain (1835 - 1910) -- felix-gcc at fefe dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug libgcj/30454] [4.3 Regression] classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: error: cannot find file for class gnu.javax.crypto.jce.mac.HMacSHA512Spi
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-17 13:56 --- Unfortunately I still haven't been able to reproduce this. I do have a few questions: I'd like to see more of the build log, in particular what happened before the failing command. Does the failing gcj invocation work if you try it from the command line? Try it with -v, too, since that may be interesting. cannot find file for class gnu.javax.crypto.jce.mac.HMacSHA512Spi Look in trunk/libjava/classpath/lib/gnu/javax/crypto/jce/mac. Does HMacSHA512Spi.class exist? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30454
[Bug tree-optimization/30334] Request for -Wundefined
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-17 14:00 --- Not so sure about this one PR 12411 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
[Bug tree-optimization/30334] Request for -Wundefined
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-17 14:04 --- Not sure about this one either, there seems to be a warning in C++ but I am not sure what option controls it now: PR 30368. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
[Bug tree-optimization/30334] Request for -Wundefined
--- Comment #7 from gdr at cs dot tamu dot edu 2007-01-17 14:06 --- Subject: Re: Request for -Wundefined manu at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Perhaps Wundefined should warn for PR 29465 ? Where feasable with minimum overhead, yes. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
[Bug tree-optimization/30334] Request for -Wundefined
--- Comment #8 from gdr at cs dot tamu dot edu 2007-01-17 14:08 --- Subject: Re: Request for -Wundefined manu at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Also, not sure whether Wundefined or Wsequence-points should handle PR 24016. unspecified beahviour is not the same as undefined behaviour. Wsequence-points is probably better for this. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
[Bug tree-optimization/30334] Request for -Wundefined
--- Comment #9 from gdr at cs dot tamu dot edu 2007-01-17 14:09 --- Subject: Re: Request for -Wundefined manu at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Another candidate is PR 30457. agreed. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
[Bug fortran/30407] Elemental functions in WHERE assignments wrongly rejected
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-17 14:11 --- Expected: As elemental procedures are also allowed, a case EXEC_ASSIGN_CALL: has to be added. This is the easy bit... You then get: $ /irun/bin/gfortran pr30407.f90 pr30407.f90: In function 'MAIN__': pr30407.f90:79: internal compiler error: in gfc_trans_where_2, at fortran/trans- stmt.c:3260 because none of the equipment is in place to do the subroutine call. This was easy for FORALL because the masking is done externally to the assignment. The WHERE construct is a totally different kettle of fish and it will take a while to deal with it. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30407
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-01-17 14:26 --- You need to improve your communication skills - pissing people off doesn't help your agenda. Btw, pointer overflow is undefined and we use that fact. -- 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=30475
[Bug tree-optimization/30334] Request for -Wundefined
--- Comment #10 from gdr at cs dot tamu dot edu 2007-01-17 14:26 --- Subject: Re: Request for -Wundefined manu at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Not so sure about this one PR 12411 order of evaluation is unspecified, should go under the sequence-points umbrella. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
[Bug tree-optimization/30334] Request for -Wundefined
--- Comment #11 from gdr at cs dot tamu dot edu 2007-01-17 14:29 --- Subject: Re: Request for -Wundefined manu at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Not sure about this one either, there seems to be a warning in C++ | but I am not sure what option controls it now: PR 30368. Some warnings will stay non-controlable. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-01-17 14:31 --- Btw. your testcase fails with gcc 2.95.3 for me as well, so no news here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #12 from felix-gcc at fefe dot de 2007-01-17 15:21 --- (In reply to comment #11) Btw. your testcase fails with gcc 2.95.3 for me as well, so no news here. Bullshit. $ ./gcc2 -v Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs gcc version 2.95.3 20010315 (release) $ ./gcc2 -o int int.c 200 100 int: int.c:4: foo: Assertion `a+100 a' failed. $ Why don't you get your facts straight. My gcc is the stock gcc 2.95.3, your's is apparently some butchered distro version. You know, the more apologists for the current behavior come forward, the less credible your position looks. -- felix-gcc at fefe dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug middle-end/19020] libcalls are removed (-ftrapv does not work)
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-01-17 15:35 --- There are a few issues, first we use emit_libcall_block to emit the trapping PLUS which sets a REG_EQUAL note with a non-trapping PLUS. Second we analyze iaddv as not possibly throwing so we remove the call from main() during tree optimization as the result is unused. Third, we widen the integer addition to DImode and dispatch to libgcc2 __addvdi3 which looks like Dump of assembler code for function __addvdi3: 0x00400580 __addvdi3+0: sub$0x8,%rsp 0x00400584 __addvdi3+4: test %rsi,%rsi 0x00400587 __addvdi3+7: lea(%rdi,%rsi,1),%rax 0x0040058b __addvdi3+11: js 0x4005a0 __addvdi3+32 0x0040058d __addvdi3+13: cmp%rax,%rdi so it tests for 64bit overflow instead of 32bit one. Obviously allowind LIBCALL_WIDEN is wrong for the trapping optabs, too. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-01-17 16:32 --- [EMAIL PROTECTED]:/tmp /space/rguenther/install/gcc-2.95/bin/gcc -o int int.c -O [EMAIL PROTECTED]:/tmp ./int 200 100 -2147483549 2147483647 stock 2.95.3 sources. Don't tell people words, it makes you look like an asshole -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #14 from felix-gcc at fefe dot de 2007-01-17 16:37 --- 1. apologist, in contrast to asshole, is not a cuss word. Apparently you are as ignorant about English as you are about the issue at hand. 2. I showed my gcc -v, why don't you? Maybe it's platform dependent? For all we know you could be running this on an old Alpha where sizeof(int)==8. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #15 from erdgeist-gcc at erdgeist dot org 2007-01-17 16:54 --- (In reply to comment #11) Btw. your testcase fails with gcc 2.95.3 for me as well, so no news here. Putting your struggles here aside, I'd like to see a type-agnostic assert from you C-cracks to use for my source code now where the way I handled this is gone. Could you please deliver that or revert the change that led to this unsatisfying situation? Thank you. -- erdgeist-gcc at erdgeist dot org changed: What|Removed |Added CC||erdgeist-gcc at erdgeist dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-01-17 16:56 --- http://c-faq.com/misc/sd26.html is all I am going to say from now on. It tell you explictly how to dectect an overflow before an overflow is going to happen. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug fortran/30432] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL
--- Comment #6 from sje at cup dot hp dot com 2007-01-17 16:58 --- The code in comment #5 works fine. In pure C cases, if a prototype has been seen when you get to the call, the floating point value goes into a FP reg. If you haven't seen a prototype then the value goes into both an FP reg -and- a general register. In the Fortran case the floating point value is only going into a general register. I think the only way to reproduce this in C is to have a protype for the f_to_f function that looks like f_to_f (int, ...). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30432
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #17 from felix-gcc at fefe dot de 2007-01-17 17:02 --- You misunderstand. We don't want you to say anything. We want to you make your optimization off by default, or remove it altogether. You could also try to convince us that there is any actual tangible performance gain, then you would at least have a leg to stand on. We would still laugh in your face because you broke security code in real world apps and refuse to fix it, though, but it would be a start. -- felix-gcc at fefe dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-01-17 17:05
---
There is no single change that led to this situation and reverting it from
current development sources will not satisfy you anyway because old versions
are then still affected.
The correct way to test for this overflow with compilers that implement
C90 6.2.1.2 / C99 6.3.1.3 as using modulo 2^N reduction is to simply
use unsigned arithmetic:
int foo(int a) {
assert((signed)((unsigned)a+100) a);
printf(%d %d\n,a+100,a);
return a;
}
if that is not the case you need to avoid the overflow (as a conforming
implementation may also trap here) in the first place, so for example
int foo(int a)
{
if (a INT_MAX - 100)
abort ();
printf(%d %d\n, a, a + 100);
return a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug target/30492] New: Undocumented ASM_OUTPUT_EXTERNAL_LIBCALL
There are alpha/elf.h:#define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN) \ alpha/unicosmk.h:#define ASM_OUTPUT_EXTERNAL_LIBCALL(STREAM,SYMREF) \ arm/aof.h:#define ASM_OUTPUT_EXTERNAL_LIBCALL(STREAM,SYMREF)\ cris/aout.h:#define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN) \ i386/cygming.h:#define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN) \ ia64/hpux.h:#define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN) \ pa/elf.h:#define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, RTL) \ pa/pa64-hpux.h:#define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN) \ pa/pa-linux.h:#define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN)\ pa/som.h:#define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, RTL) \ But it isn't documented. However we do have TARGET_ASM_EXTERNAL_LIBCALL, which is redundant (PR 30480). -- Summary: Undocumented ASM_OUTPUT_EXTERNAL_LIBCALL Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org BugsThisDependsOn: 30480 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30492
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #19 from pinskia at gcc dot gnu dot org 2007-01-17 17:12 --- Again your code is broken to the standard and the comp.lang.c faq mentions a way to not dependent on the undefined code so this again is not really a bug. The question about security is what do you trust, the inputs or the outputs? Really what you are saying with your current code, you trust the inputs but not the outputs. What the code given in the comp.lang.c faq does is not trust the inputs. I am sorry that you wrote broken code to begin with but given you are writting C+signedintegeroverflowaswrapping code and not C (and GCC is a C compiler), GCC breaks your code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug fortran/30444] sfstubs.f90:48: internal compiler error: Illegal instruction
--- Comment #6 from orion at cora dot nwra dot com 2007-01-17 17:14 --- Sorry, Fedora libmpfr packaging bug -- orion at cora dot nwra dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30444
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #20 from amacleod at redhat dot com 2007-01-17 17:14 --- Perhaps comment #12 and comment #13 would have the same results if they both used the same options? One has -O and the other does not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #21 from felix-gcc at fefe dot de 2007-01-17 17:20 --- I DID NOT WRITE THE BROKEN CODE. Trying to trivialize the issue or insult me will not make it go away. So, please tell me, which part of the argument in comment #9 were you unable to follow? I could try using less complicated words so you actually understand it this time around. Guys, your obligation is not just to implement the C standard. Your obligation is also not to break apps that depend on you. And A LOT of apps are depending on you. When you broke the floating point accuracy, you made it opt-in (-ffast-math). When you added the aliasing breakage, you made it opt-in (-fstrict-aliasing). IIRC for that you also quoted some legalese from the standard at first, until people with more grounding in reality overruled you. And I'm going to keep this bug open until the same thing happens again for this issue. You can't just potentially break of the free software in the world because you changed your mind about what liberty the C standard gives you. Grow up or move out of the way and let more responsible people handle our infrastructure. You know that the Ariane 5 rocket crashed (and could have killed people!) because of an int overflow? What if people die because you decided the C standard allows you to optimize away other people's security checks? Again: IT DOES NOT MATTER WHAT THE C STANDARD SAYS. You broke code, people are suffering damage. Now revert it. The least you can do is make -fwrapv on by default. You would still have to make it actually work (I hear it's broken in some corner cases?), but that's another story. -- felix-gcc at fefe dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c++/17947] bad warning with implicit conversion and __attribute__((deprecated))
--- Comment #3 from patchapp at dberlin dot org 2007-01-17 17:20 --- Subject: Bug number PR 17947 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-01/msg01439.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17947
[Bug other/30465] Duplicated overflow warning
--- Comment #1 from patchapp at dberlin dot org 2007-01-17 17:21 --- Subject: Bug number PR30465 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-01/msg01440.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30465
[Bug tree-optimization/30493] New: [4.1 Regression] Unexpected compilation results: -O versus no optimization
The following C code demonstrates incorrect results when any optimization
is used:
#include stdio.h
#include stdlib.h
#include string.h
#include complex.h
#include math.h
struct fs {
int order;
int numpoles;
unsigned int polemask;
complex data[100];
};
void choosepole(complex z, struct fs *flt)
{
static int i=0;
if (creal(z) 0.0)
{
if (flt-polemask 1)
flt-numpoles++;
flt-polemask = 1;
}
flt-data[i++]=z;
}
int main(int argc, char *argv[])
{
struct fs flt;
int i;
flt.order=3;
flt.numpoles=0;
flt.polemask=(~0);
memset(flt.data,0,100*sizeof(complex));
for (i=0;i2*flt.order;i++)
{
/* Following line is optimized incorrectly!!! */
double theta = (flt.order1) ?
(i*M_PI)/flt.order :
((i+0.5)*M_PI)/flt.order;
choosepole(cexp(I*theta),flt);
}
for (i=0;i2*flt.order;i++)
{
fprintf(stderr,flt.data[%d]=%lg + I * %lg\n,
i,
creal(flt.data[i]),
cimag(flt.data[i]));
}
return EXIT_SUCCESS;
}
+++ This bug was initially created as a clone of Bug #30088 +++
The following C++ program (preprocessed source attached) produces unexpected
results when compiled with -O1 -fstrict-aliasing (as opposed to -O1 only) or
with any higher level of optimization (-O2 or -O3). No compilation warnings
are emitted in any of the cases.
#include cassert
#include string
struct A
{
A() : _x(0.0), _y(0.0) { }
float f(const int i) { return (i == 0 ? _x : _y); }
float _x, _y;
};
struct B
{
B(const char* s) : _s(s) { }
std::string g() { return std::string(_s); }
const char* _s;
};
A h(const char* s)
{
if (s == 0)
return A();
A a;
B b(s);
if (b.g().compare(std::string()) == 0)
a.f(0) = a.f(1) = 1.0;
else if (b.g().compare(std::string()))
b.g().compare(std::string());
return a;
}
int main()
{
A a(h());
assert(a._x 0.0 a._y 0.0);
return 0;
}
Compilation results:
$ g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../src/configure --prefix=/opt/gcc-4.1.1
Thread model: posix
gcc version 4.1.1
$ g++ -W -Wall -O1 testcase.cc
$ ./a.out
$ g++ -W -Wall -O1 -fstrict-aliasing testcase.cc
$ ./a.out
a.out: testcase.cc:34: int main(): Assertion `a._x 0.0 a._y 0.0' failed.
Aborted
The assertion ceases to fail (with -O1 -fstrict-aliasing) when adding any
(single one) of the options -fno-tree-copy-prop, -fno-tree-dce,
-fno-tree-salias or -fno-inline to the compiler command line.
--
Summary: [4.1 Regression] Unexpected compilation results: -O
versus no optimization
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sam at sambromley 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=30493
[Bug fortran/30476] [Regression 4.2, 4.3] Via other module imported generic interface rejected
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-17 17:33 --- Subject: Bug 30476 Author: pault Date: Wed Jan 17 17:33:35 2007 New Revision: 120860 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120860 Log: 2007-01-17 Paul Thomas [EMAIL PROTECTED] PR fortran/30476 * module.c (load_generic_interfaces): Make the marking of the symbol as ambiguous conditional on the module names being different. (write_generic): Ensure that the generic interface has a non-NULL module field. 2007-01-17 Paul Thomas [EMAIL PROTECTED] PR fortran/30476 * gfortran.dg/generic_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/generic_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30476
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #22 from pinskia at gcc dot gnu dot org 2007-01-17 17:42 --- (In reply to comment #21) I DID NOT WRITE THE BROKEN CODE. But you wrote the bug so I assumed you wrote it. Trying to trivialize the issue or insult me will not make it go away. How about this has not changed since at least January 24, 1994 (when 2.5.8 was released) so the decission about this code was made 13 years ago. What does that say about new code since then? So, please tell me, which part of the argument in comment #9 were you unable to follow? I could try using less complicated words so you actually understand it this time around. None. Just this decission was done a long long time ago before I even started working on GCC. Guys, your obligation is not just to implement the C standard. Your obligation is also not to break apps that depend on you. And A LOT of apps are depending on you. When you broke the floating point accuracy, you made it opt-in (-ffast-math). Actually -ffast-math breaks the C standard too so your argument here fails. When you added the aliasing breakage, you made it opt-in (-fstrict-aliasing). I think we should not have made that optional but I was not around when that decission was made. Also remember we had a release (2.95) where it was on and then it had to be turned off by default (2.95.2) while people fixed there code but while this optimization was on during that time. And we do make this optimization optional with -fwrapv already so I don't see where you argument is going to now. IIRC for that you also quoted some legalese from the standard at first, until people with more grounding in reality overruled you. And I'm going to keep this bug open until the same thing happens again for this issue. Why this really should not be discussed in the bug but on the gcc@ mailing list where all over discussions happen? You can't just potentially break of the free software in the world because you changed your mind about what liberty the C standard gives you. Grow up or move out of the way and let more responsible people handle our infrastructure. Wait a minute, this optimization has been there since 1994, if new code in the free software world has abused signed overflow like this, they were asking for it. You know that the Ariane 5 rocket crashed (and could have killed people!) because of an int overflow? And I showed you how to find an overflow before it happens and not after so that argument is dead in the water. What if people die because you decided the C standard allows you to optimize away other people's security checks? Again I showed you how to check for integer overflows before they happen instead of after. You can teach other security people how to write that code. Again: IT DOES NOT MATTER WHAT THE C STANDARD SAYS. You broke code, people are suffering damage. Now revert it. Revert what was done 13 years ago. Do you have a time machine, because I sure had hoped so because I wantted to change what happened last year a little bit. The least you can do is make -fwrapv on by default. It is default on languages which actually define the language that way. You would still have to make it actually work (I hear it's broken in some corner cases?), but that's another story. It __WAS__ broken in a corner case but that already was fixed in 4.0.0. Again there is no reason why this decussion should not be on gcc@ and not here. I gave the correct way of writting overflow dection and if you don't like what the C standard says, that is not my fault at all. Remember GCC is also an optimizing compiler, if you want optimizations, you need to follow the language which you are writting in closer instead of playing it loose which is what is happening with both C and C++ in general. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/16202] The -Wsequence-point warning misses many important instances
--- Comment #9 from trt at acm dot org 2007-01-17 18:15 --- I made lvalue_p a global function in my personal gcc. I've proposed a dozen different warnings-related things for gcc, and never made headway on any of them. I'm just a random user and don't know the secret handshake. The people who do seem utterly uninterested in gcc diagnostics. If you, or anyone, would get this patch working and into gcc, I would be delighted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16202
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #23 from felix-gcc at fefe dot de 2007-01-17 18:23 --- In earlier gcc versions this only happened if the optimizer was on. So your argument might hold some water there, if I squint my eyes enough. But gcc 4.1 removes that code even with the optimizer turned off. There goes your argument. Please make -fwrapv default again and I'll shut up. -- felix-gcc at fefe dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug fortran/30476] [Regression 4.2, 4.3] Via other module imported generic interface rejected
--- Comment #4 from pault at gcc dot gnu dot org 2007-01-17 18:33 --- Subject: Bug 30476 Author: pault Date: Wed Jan 17 18:33:35 2007 New Revision: 120864 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120864 Log: 2007-01-17 Paul Thomas [EMAIL PROTECTED] PR fortran/30476 * module.c (load_generic_interfaces): Make the marking of the symbol as ambiguous conditional on the module names being different. (write_generic): Ensure that the generic interface has a non-NULL module field. 2007-01-17 Paul Thomas [EMAIL PROTECTED] PR fortran/30476 * gfortran.dg/generic_12.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/generic_12.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/module.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30476
[Bug fortran/30476] [Regression 4.2, 4.3] Via other module imported generic interface rejected
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-17 18:38 --- Fixed on trunk and 4.2. Thanks for the report! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30476
[Bug driver/10961] read_specs -- compilers[n_compilers].cpp_spec not initialized
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-17 18:39 ---
I read through the existing code here and I think it is subtly correct.
The default_compilers array has a final entry consisting of all zeroes:
/* Mark end of table. */
{0, 0, 0, 0, 0}
'compilers' is initially a copy of this table. So, the last entry in
compilers is all zeroes.
The code quoted in the PR is reallocating the compilers array. It sets
some fields in the final entry -- but not all fields. However, this is ok
since we know those to be zero. Then this code memset()s the new
terminating entry to be all zeroes. This lets us conclude that this
code is safe, by induction.
So, I am closing this PR as invalid. If you believe this analysis is
in error, please reopen the PR and explain how. I will provide a patch
in this case.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
||org
Status|NEW |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10961
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #24 from pinskia at gcc dot gnu dot org 2007-01-17 18:43 --- Try doing some timings with and without -fwrapv and see what happens for normal code. You will see that without -fwrapv code runs faster. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #25 from felix-gcc at fefe dot de 2007-01-17 19:04 --- Well, duh. You removed the security checks. Hey, I have one for you, too. Optimize away all calls to pthread_mutex_lock, and lo and behold, multithreaded code will be much faster! It will also be broken, but apparently, that's not much of a concern around here. The most time critical code I have, I just benchmarked. $ gcc -O3 -fomit-frame-pointer -funroll-loops -march=athlon64 -o t t.c misc.c add.c mul.c write.c read.c comba.c $ ./t adding two bignums: 84 cycles multiply two bignums: 1414 cycles writing a bignum as radix 10: 207488 cycles comba: 1467 cycles $ gcc -O3 -fomit-frame-pointer -funroll-loops -march=athlon64 -o t t.c misc.c add.c mul.c write.c read.c comba.c -fwrapv adding two bignums: 82 cycles multiply two bignums: 1414 cycles writing a bignum as radix 10: 202761 cycles comba: 1465 cycles $ So, uh, where does the optimization part about your optimization come in? This is code that has no integer overflow checks. So my conjecture is: your optimization makes code faster in exactly those cases where it removes security checks from it, endangering people on the way. So, again, please make -fwrapv the default, and I'll leave you alone. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/16202] The -Wsequence-point warning misses many important instances
--- Comment #10 from manu at gcc dot gnu dot org 2007-01-17 19:12 --- I am also new, my first patch was just a few months ago, so let me say that I understand your situation. On the other hand, I got patches committed, so also let me say that it is not as bad as you may think. The secret handshake is quite simple actually: 1) Have a copyright assignment: http://gcc.gnu.org/contribute.html#legal 2) Post patches to [EMAIL PROTECTED] (you can also add them to the patch queue http://www.dberlin.org/patchdirections.html but posting to gcc-patches is essential, bugzilla attachments are not considered serious proposals). 3) Add testcases to the patch and bootstrap and regression test for a recent revision, and say that you have done so. Add a Changelog to your mail (but not to the patch). More info at http://gcc.gnu.org/contribute.html 4) Wait, wait, wait, make a comment about your patch pending review (if you follow the list, you will see that people do this very often), then wait, wait and wait a bit more, perhaps make another comment and eventually your patch will be reviewed and surely you will have to make changes. In that case, goto 2. 5) Ask for someone to commit the patch for yourself or ask for write-after-approval rights. The wait-wait-wait thing may apply here again. Patience, you can have as many patches pending review as you wish, just ping them once every while. Easy, isn't it? I think the first step is to get subscribed to gcc-patches to check out how people submit and get reviewed patches. What are you waiting for? We look forward to have you on board! Cheers, Manuel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16202
[Bug tree-optimization/29516] gfortran miscompiled
--- Comment #33 from mrs at apple dot com 2007-01-17 19:13 --- I think 4.2 would be a better release with this patch in it, could we push this into 4.2, thanks. Any concerns about the satefy of the patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #26 from pinskia at gcc dot gnu dot org 2007-01-17 19:17 --- (In reply to comment #25) Well, duh. You removed the security checks. Which were wrong to begin with, See the comp.lang.c faq. Hey, I have one for you, too. Optimize away all calls to pthread_mutex_lock, and lo and behold, multithreaded code will be much faster! It will also be broken, but apparently, that's not much of a concern around here. No, because it is not undefined for pthread_mutex_lock unlike this case. The most time critical code I have, I just benchmarked. $ gcc -O3 -fomit-frame-pointer -funroll-loops -march=athlon64 -o t t.c misc.c add.c mul.c write.c read.c comba.c $ ./t adding two bignums: 84 cycles multiply two bignums: 1414 cycles writing a bignum as radix 10: 207488 cycles comba: 1467 cycles $ gcc -O3 -fomit-frame-pointer -funroll-loops -march=athlon64 -o t t.c misc.c add.c mul.c write.c read.c comba.c -fwrapv adding two bignums: 82 cycles multiply two bignums: 1414 cycles writing a bignum as radix 10: 202761 cycles comba: 1465 cycles $ So, uh, where does the optimization part about your optimization come in? Most of the time it is loops. Try adding bounds checking to the code and try again. You will then see the difference, This is an important optimization for C++ code that has bound checked array accesses, Java code and Fortran code. This is code that has no integer overflow checks. Your specific code has no code which benifits that much. Try again with some C++ code which uses vector and get. You will see a huge difference in the code there. So my conjecture is: your optimization makes code faster in exactly those cases where it removes security checks from it, endangering people on the way. You are missunderstanding, your one piece of code does not benifit so you can just alway turn on -fwrapv if you really depend on signed integer overflow wrapping. You need to look at the bigger picture: 1) security is important 2) code generation is important which one is better for the users, all of the above. Just because the person who wrote the security checks in the code you are looking at got it wrong is no reason to penality the people who actually got it right by using the way decribed in the comp.lang.c faq. This is my point, you are trying to penality the people who wrote their security checks so it is defined C. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug libfortran/27107] Make dependency on io/io.h broken
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-01-17 19:44 --- Subject: Bug 27107 Author: fxcoudert Date: Wed Jan 17 19:44:00 2007 New Revision: 120869 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120869 Log: PR libfortran/27107 * runtime/environ.c: Don't include io/io.h. * runtime/string.c: Don't include io/io.h. (compare0): Add cast to avoid warning. * runtime/error.c: Don't include io/io.h. (st_printf): Move to io/unix.c. * intrinsics/flush.c: Delete, contents moved to io/intrinsics.c. * intrinsics/fget.c: Likewise. * intrinsics/ftell.c: Likewise. * intrinsics/tty.c: Likewise. * libgfortran.h (DEFAULT_RECL, notification_std, get_unformatted_convert, IOPARM_*, st_parameter_common, unit_convert, DEFAULT_TEMPDIR): New declarations. * io/io.h (DEFAULT_RECL, notification_std, get_unformatted_convert, IOPARM_*, st_parameter_common, unit_convert, DEFAULT_TEMPDIR): Move to libgfortran.h. * io/unix.c: Add io/unix.h content. (st_printf): New function. * io/intrinsics.c: New file. * io/unix.h: Remove, contents moved into unix.c. * libtool-version: Update library version to 3.0.0. * configure.ac: Update library version to 0.3. * Makefile.am (intrinsics/fget.c, intrinsics/flush.c, intrinsics/ftell.c, intrinsics/tty.c, libgfortran.h): Remove targets. * Makefile.in: Regenerate. * configure: Regenerate. Added: trunk/libgfortran/io/intrinsics.c - copied, changed from r120528, trunk/libgfortran/intrinsics/fget.c Removed: trunk/libgfortran/intrinsics/fget.c trunk/libgfortran/intrinsics/flush.c trunk/libgfortran/intrinsics/ftell.c trunk/libgfortran/intrinsics/tty.c trunk/libgfortran/io/unix.h Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/io/io.h trunk/libgfortran/io/unix.c trunk/libgfortran/libgfortran.h trunk/libgfortran/libtool-version trunk/libgfortran/runtime/environ.c trunk/libgfortran/runtime/error.c trunk/libgfortran/runtime/string.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27107
[Bug fortran/30437] [4.0/4.1/4.2/4.3 Regression] -Wno-all is rejected (even when fortran is not included)
--- Comment #7 from patchapp at dberlin dot org 2007-01-17 19:46 --- Subject: Bug number PR 30437 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-01/msg01456.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30437
[Bug driver/30491] behaviour with -MMD and -c / -E causes differring behaviours.
--- Comment #1 from fang at csl dot cornell dot edu 2007-01-17 20:39 --- The problem with passing -E -o ... is that gcc has to assume the default output object as the target, which strips the directory from the name, since -o is used for the resulting .i file. That is what -MT is for, as you've found. Usually when I generate .i files, I don't care what .o file it assumes (or its deps), and just redirect the result: gcc -E file.c file.i If you want to generate both .o and .i at the same time, you could pass -save-temps? -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30491
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #34 from bergner at gcc dot gnu dot org 2007-01-17 20:58 --- Created an attachment (id=12915) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12915action=view) Patch to commutative_operand_precedence to increase the precedence of REG_POINTER and MEM_POINTER objects. This patch modifies commutative_operand_precedence to increase the precedence of REG_POINTER and MEM_POINTER objects. This obviates the need for swap_commutative_operands_with_target which has been replaced by a call to swap_commutative_operands_p. This patch improves performance on POWER6 (using -mcpu=power6) by 30% across both specint and specfp, with a 498% improvement on galgel. On POWER5 (using -mcpu=power5), there was only negligible differences between the base and patched compilers. It also correctly transforms all of the above test cases except those with artificial pointers which will have to wait until Andrew's PTR_PLUS_EXPR work is complete. Paolo tested this patch on x86 and saw 4% degradation on galgel which he said he'd look into. However, overall across both specint and specfp, the performance change didn't seem that bad. -- bergner at gcc dot gnu dot org changed: What|Removed |Added Attachment #12375|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug libfortran/27107] Make dependency on io/io.h broken
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-17 22:15 --- Subject: Bug 27107 Author: tromey Date: Wed Jan 17 22:14:48 2007 New Revision: 120878 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120878 Log: PR libgfortran/27107: * aclocal.m4, configure, Makefile.in: Rebuilt. * configure.ac: Enable automake dependency tracking. Update minimum automake version. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.in trunk/libgfortran/aclocal.m4 trunk/libgfortran/configure trunk/libgfortran/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27107
[Bug target/29302] isfinite returns wrong result at -O1
--- Comment #31 from echristo at gcc dot gnu dot org 2007-01-17 23:30 --- Subject: Bug 29302 Author: echristo Date: Wed Jan 17 23:30:30 2007 New Revision: 120884 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120884 Log: 2007-01-17 Eric Christopher [EMAIL PROTECTED] Backport from mainline: 2006-12-18 Roger Sayle [EMAIL PROTECTED] Eric Christopher [EMAIL PROTECTED] PR target/29302 * real.c (real_maxval): Correctly handle IBM extended double format. 2007-01-17 Eric Christopher [EMAIL PROTECTED] Backport from mainline: 2006-12-19 Eric Christopher [EMAIL PROTECTED] PR target/29302 * gcc.c-torture/execute/pr29302-1.c: New. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/pr29302-1.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/real.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29302
[Bug tree-optimization/29516] gfortran miscompiled
--- Comment #34 from howarth at nitro dot med dot uc dot edu 2007-01-17 23:38 --- Also as the gfortran developers have pointed out, this bug is currently has a target milestone 4.2.0 which implies it was intended to be fixed in gcc 4.2 branch as well. Unfortunately, I am having trouble getting the patch checked into gcc trunk to apply cleanly to gcc 4.2 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
[Bug target/30222] gcc.target/i386/vectorize1.c ICEs
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2007-01-18 02:32 --- What target milestone is this bug? If it is meant to be 4.2.0, shouldn't the missing section of the original patch be applied to gcc 4.2 branch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30222
[Bug preprocessor/8270] [4.0/4.1/4.2/4.3 Regression] back-slash white space newline with comments, no warning
--- Comment #36 from gdr at gcc dot gnu dot org 2007-01-18 02:37 --- A fix is not going to happen for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
[Bug c++/11987] [4.0/4.1/4.2/4.3 regression] Accepts-invalid with inherited nested type
--- Comment #11 from gdr at gcc dot gnu dot org 2007-01-18 02:39 --- Not to be fixed in GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11987
[Bug preprocessor/13726] [4.0 regression]cpp -C -dI loses comments on same line as #include directives
--- Comment #13 from gdr at gcc dot gnu dot org 2007-01-18 02:48 --- Closing as fixed in recent version of GCC. Not to be fixed in GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13726
[Bug c++/14179] [4.0/4.1/4.2/4.3 Regression] out of memory while parsing array with many initializers
--- Comment #46 from gdr at gcc dot gnu dot org 2007-01-18 02:51 --- Won't fix for 4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179
[Bug preprocessor/13726] [4.0 regression]cpp -C -dI loses comments on same line as #include directives
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13726
[Bug c++/14777] [4.0/4.1/4.2/4.3 Regression] typedef doesn't fully expose base class type
--- Comment #9 from gdr at gcc dot gnu dot org 2007-01-18 02:52 --- Not to be fixed in GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
[Bug other/15082] [4.0/4.1/4.2/4.3 regression] Minor compilation problem for cross to Solaris 8
--- Comment #20 from gdr at gcc dot gnu dot org 2007-01-18 02:54 --- Won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15082
[Bug target/15184] [4.0/4.1/4.2/4.3 Regression] Direct access to byte inside word not working with -march=pentiumpro
--- Comment #12 from gdr at gcc dot gnu dot org 2007-01-18 02:55 --- Won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184
[Bug inline-asm/16194] [4.0 Regression] global register with inline-asm and clobered
--- Comment #21 from gdr at gcc dot gnu dot org 2007-01-18 02:56 --- Fixed in GCC-4.1.x. Won't fix in GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16194
[Bug tree-optimization/16306] [4.0/4.1/4.2/4.3 Regression] restrict and copying pointers problem
--- Comment #6 from gdr at gcc dot gnu dot org 2007-01-18 02:57 --- Won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16306
[Bug rtl-optimization/16613] [4.0 Regression] compile time regression, when adding cerr usage
--- Comment #17 from gdr at gcc dot gnu dot org 2007-01-18 02:58 --- Won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16613
[Bug bootstrap/16865] False alarm about use of uninitialized variable breaks bootstrap at -O3
--- Comment #10 from gdr at gcc dot gnu dot org 2007-01-18 03:00 --- Won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16865
[Bug inline-asm/16194] [4.0 Regression] global register with inline-asm and clobered
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.2 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16194
[Bug tree-optimization/16913] [4.0/4.1/4.2/4.3 Regression] restrict does not make a difference
--- Comment #9 from gdr at gcc dot gnu dot org 2007-01-18 03:01 --- Won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16913
[Bug c++/17053] [4.0/4.1/4.2/4.3 Regression] Repo functionality partially broken on AIX (collect2.c)
--- Comment #16 from gdr at gcc dot gnu dot org 2007-01-18 03:03 --- won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17053
[Bug c++/17763] [4.0/4.1/4.2/4.3 Regression] Wrong context in error message for template parameter
--- Comment #16 from gdr at gcc dot gnu dot org 2007-01-18 03:04 --- Won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17763
[Bug libstdc++/17789] [4.0/4.1/4.2/4.3 Regression] Cannot 'make check' inside libstdc++-v3
--- Comment #10 from gdr at gcc dot gnu dot org 2007-01-18 03:05 --- won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17789
[Bug tree-optimization/17863] [4.0/4.1/4.2/4.3 Regression] performance loss (not inlining as much??)
--- Comment #32 from gdr at gcc dot gnu dot org 2007-01-18 03:06 --- No fix will happen for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
[Bug c++/17913] [4.0 Regression] ICE jumping into statement expression
--- Comment #24 from gdr at gcc dot gnu dot org 2007-01-18 03:07 --- No fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913
[Bug tree-optimization/18463] [4.0 Regression] suboptimal use of fancy x86 addressing modes
--- Comment #30 from gdr at gcc dot gnu dot org 2007-01-18 03:09 --- Fixed in GCC-4.1.0. Not to be fixed in GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18463
[Bug target/18631] [4.0 Regression] missing error messages passing vectors with -mno-altivec -mabi=altivec
--- Comment #7 from gdr at gcc dot gnu dot org 2007-01-18 03:11 --- Won't fix for GCC-4.0.x -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18631
[Bug rtl-optimization/18853] [4.0 Regression] ICE: genautomata.c:5238, error: verify_flow_info: Incorrect fallthru
--- Comment #13 from gdr at gcc dot gnu dot org 2007-01-18 03:13 --- Fixed in GCC-4.1.0 and later. Won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18853
[Bug debug/19192] [4.0/4.1/4.2/4.3 Regression] Current development gcc generates inaccurate line info for example code
--- Comment #6 from gdr at gcc dot gnu dot org 2007-01-18 03:35 --- won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
[Bug middle-end/19988] [4.0/4.1/4.2/4.3 Regression] pessimizes fp multiply-add/subtract combo
--- Comment #10 from gdr at gcc dot gnu dot org 2007-01-18 03:36 --- Won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19988
[Bug preprocessor/20077] [4.0/4.1/4.2/4.3 Regression] GCC accepts macro definitions that fail a constraint
--- Comment #6 from gdr at gcc dot gnu dot org 2007-01-18 03:36 --- Won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20077
[Bug c++/20209] [4.0 Regression] Missing warnings for aggregate has a partly bracketed initializer
--- Comment #7 from gdr at gcc dot gnu dot org 2007-01-18 03:37 --- won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20209
[Bug preprocessor/20285] [4.0/4.1/4.2/4.3 Regression] gcc -E - . gives a misleading error message
--- Comment #3 from gdr at gcc dot gnu dot org 2007-01-18 03:38 --- Won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20285
[Bug c++/20293] [4.0 regression] Wrong diagnostic for ambiguous access
--- Comment #10 from gdr at gcc dot gnu dot org 2007-01-18 03:39 --- Fixed in 4.1.0. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20293
[Bug rtl-optimization/20583] [4.0 regression] ICE in output_operand: invalid expression as operand
--- Comment #13 from gdr at gcc dot gnu dot org 2007-01-18 03:40 --- Fixed in 4.1.0. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20583
[Bug c++/20681] [4.0/4.1/4.2/4.3 Regression] wrong control reaches warning with switches
--- Comment #19 from gdr at gcc dot gnu dot org 2007-01-18 03:41 --- won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20681
[Bug bootstrap/20698] [4.0 Regression] configure broken
--- Comment #3 from gdr at gcc dot gnu dot org 2007-01-18 03:42 --- won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20698
[Bug tree-optimization/20773] [4.0 Regression] ICE: SEGV building jar file
--- Comment #13 from gdr at gcc dot gnu dot org 2007-01-18 03:43 --- Fixed in 4.1.0. won't fix in 4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20773
[Bug middle-end/21032] [4.0 Regression] With -frounding-math, incorrectly reorders unary minus
--- Comment #20 from gdr at gcc dot gnu dot org 2007-01-18 03:45 --- Fixed in GCC-4.1.1 and above. Won't fix in GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug target/21081] [4.0 Regression] internal compiler error: verify_stmts failed.
--- Comment #21 from gdr at gcc dot gnu dot org 2007-01-18 03:46 --- won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21081
[Bug target/21169] [4.0 regression] ICE in reload_cse_simplify_operands with -fnon-call-exceptions -fPIC -O2
--- Comment #10 from gdr at gcc dot gnu dot org 2007-01-18 03:46 --- won't fix for GCC-4.0.x. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21169
