[Bug libfortran/20179] cannot mix C and Fortran I/O
--- Comment #23 from fxcoudert at gcc dot gnu dot org 2005-10-29 12:44 --- Patch for that PR submitted (http://gcc.gnu.org/ml/fortran/2005-10/msg00682.html). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/fortra ||n/2005-10/msg00682.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179
[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2005-10-29 12:55 --- Confirmed and marked as an enhancement. The standard clearly forbids the behaviour the reporter would like (and that some commercial compilers exhibit), so it's not a bug. However, it could be an interesting feature, if someone has time to implement it. The code proposed in comment #6 is indeed the right way to use unit numbers in a very general way to avoid clashes (well, there is a race condition, but i'm not sure how you could avoid it). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Last reconfirmed|-00-00 00:00:00 |2005-10-29 12:55:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24576
[Bug libfortran/15234] libgfortran doesn't compile on Tru64 UNIX V4.0F
--- Comment #33 from fxcoudert at gcc dot gnu dot org 2005-10-29 12:57 --- (In reply to comment #30) > I do agree with you. Can you re-submit the patch on the fortran ml for > approval? ping*2 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15234
[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-29 13:21 --- And I really think this is just an manufacting of PR 22298 in a different way. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||22298 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24576
[Bug fortran/24579] error on list directed read
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24579
[Bug fortran/24285] format(1000(a,$))
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-10-29 13:42 --- Confirmed. I'm working on this and related problems in io.c. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-29 13:42:24 date|| Summary|format( 1000(a,$)) |format(1000(a,$)) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24285
[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2005-10-29 13:47 --- (In reply to comment #8) > And I really think this is just an manufacting of PR 22298 in a different way. No it's not. The same problem happens with dynamic linking, static linking has nothing to do with this bug. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-10-29 12:55:40 |2005-10-29 13:47:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24576
[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-29 14:09 --- Can you try the following "work around": gfortran -fPIC -shared -Wl,-Bsymbolic -o libtest.so test.f \ -Wl,--whole-archive /usr/lib64/libgfortran.a -Wl,--no-whole-archive This should work and if it does, then the orginal problem is really just another manfacturing of PR 22298. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24576
[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2005-10-29 14:24 --- (In reply to comment #10) > Can you try the following "work around": > gfortran -fPIC -shared -Wl,-Bsymbolic -o libtest.so test.f \ > -Wl,--whole-archive /usr/lib64/libgfortran.a -Wl,--no-whole-archive "That works for me" (TM). So, once 22298 is fixed, you (Iwan) will be able to do as was possible with older GCC releases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24576
[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library
--- Comment #12 from iwan at irs dot phy dot nrc dot ca 2005-10-29 15:01 --- Subject: Re: Fortran I/O to same unit number in main program and in a shared library Using -Wl,--whole-archive /usr/lib64/libgfortran.a -Wl,--no-whole-archive works for me too. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24576
[Bug inline-asm/23200] [4.0/4.1 regression] rejects "i"(&var + 1)
--- Comment #9 from steven at gcc dot gnu dot org 2005-10-29 15:11 --- I'm testing the patch from comment #8 on a few targets. -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-08-02 20:57:12 |2005-10-29 15:11:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug fortran/24534] PUBLIC derived types with private components
--- Comment #2 from steven at gcc dot gnu dot org 2005-10-29 15:15 --- How can this possibly be a GCC 4.0/4.1 regression?! Before GCC 4.0 we didn't even have a Fortran with support for derived types. -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1 Regression] PUBLIC |PUBLIC derived types with |derived types with private |private components |components | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24534
[Bug fortran/24534] [4.0/4.1 Regression] PUBLIC derived types with private components
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-29 15:20 --- (In reply to comment #2) > How can this possibly be a GCC 4.0/4.1 regression?! Because in 4.0.0, this worked. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.0 4.0.3 Known to work||4.0.0 Summary|PUBLIC derived types with |[4.0/4.1 Regression] PUBLIC |private components |derived types with private ||components http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24534
[Bug libfortran/24576] Fortran I/O to same unit number in main program and in a shared library
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2005-10-29 15:39 --- Then we can close this PR as duplicate of 22298. *** This bug has been marked as a duplicate of 22298 *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24576
[Bug libfortran/22298] libgfortran init() constructor isn't called if executable is statically linked
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-10-29 15:39 --- *** Bug 24576 has been marked as a duplicate of this bug. *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||iwan at irs dot phy dot nrc ||dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22298
[Bug tree-optimization/21829] [4.1 Regression] missed jump threading after unroller
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-29 15:52 --- This really does not need to be targeted towards 4.1 (this is a bug I filed looking at code gen problems with some weird code which I made up). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-09-16 23:14:06 |2005-10-29 15:52:25 date|| Target Milestone|4.1.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21829
[Bug tree-optimization/24365] [4.1 Regression] statement makes a memory store with complex
--- Comment #5 from steven at gcc dot gnu dot org 2005-10-29 16:28 --- This does not fail for me... Neither the original test case nor the reduced one. The compiler I used was "GNU C++ version 4.1.0 20051029 (experimental) (x86_64-unknown-linux-gnu)" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24365
[Bug c++/24580] New: [3.4/4.0/4.1 Regression] virtual base class cause exception not to be caught
The following code should not abort:
struct vbase {};
struct foo : virtual vbase {
foo() {
throw "exception in foo ctor";
}
};
main()
{
struct bar : public foo {};
try {
bar a;
}
catch ( ... ) {
}
return 0;
};
This is forwarded from:
http://gcc.gnu.org/ml/gcc/2005-09/msg00253.html
--
Summary: [3.4/4.0/4.1 Regression] virtual base class cause
exception not to be caught
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: c++
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=24580
[Bug tree-optimization/24365] [4.1 Regression] statement makes a memory store with complex
--- Comment #6 from steven at gcc dot gnu dot org 2005-10-29 16:41 --- This does ICE for i686 or for AMD64 -m32. For 64 bits it passes for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24365
[Bug c++/24580] [3.4/4.0/4.1 Regression] virtual base class cause exception not to be caught
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.3 Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24580
[Bug c++/24580] [3.4/4.0/4.1 Regression] virtual base class cause exception not to be caught
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-29 16:42 --- Confirmed as a bug in: http://gcc.gnu.org/ml/gcc/2005-09/msg00329.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.0.4 3.4.0 4.0.0 3.3.3 ||3.2.3 Known to work||2.95.3 Last reconfirmed|-00-00 00:00:00 |2005-10-29 16:42:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24580
[Bug c/15389] Error when compiling anything on Knoppix
--- Comment #2 from clum at users dot sourceforge dot net 2005-10-29 17:57 --- This is really weird. I have used gcc many, many times, (but never on Knoppix before) and have never had such a problem. I'm having the exact same problem. It happens right away when I compile, even if I only do preprocessing with -E. It works fine if I su into root. But I have full permissions on the file and directory I'm doing it in (/home/knoppix). I'm running a Dell Dimension 8100 with a P4 processor and Knoppix 4.0.2. I just tried an experiment and got it to work with user knoppix as well. What I had to do was set a password for user knoppix. If I tried passwd directly in knoppix, it asks for the current password, which doesn't exist, so I can't change it, but if I su, and then passwd knoppix, and enter a new password, and exit, then gcc works fine. This Knoppix comes with gcc 3.3.6. -- clum at users dot sourceforge dot net changed: What|Removed |Added CC||clum at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15389
[Bug tree-optimization/24365] [4.1 Regression] statement makes a memory store with complex
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-29 18:01 --- I have a fix but it could cause missed optimizations but from the looks of it, that is because we don't use SFT on complex variables (or it might be on RESULT_DECL which is the real issue). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24365
[Bug tree-optimization/21559] [4.1 Regression] missed jump threading
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-29 18:09 --- Another one of these I filed this bug after looking at someone else's bug for code gen regressions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21559
[Bug middle-end/24565] [4.1 Regression] facerec performance regression
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|regression |middle-end Keywords||missed-optimization Summary|facerec performance |[4.1 Regression] facerec |regression |performance regression Target Milestone|--- |4.1.0 Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24565
[Bug c/24581] New: Complex arithmetic on special cases is incorrect.
/*
* The C99 standard intends x+I*y to be used for this, but x+I*y is
* currently unusable because gcc introduces many overflow,
* underflow, sign and efficiency bugs by rewriting I*y as
* (0.0+I)*(y+0.0*I) and laboriously computing the full complex product.
* In particular, I*Inf is corrupted to NaN+I*Inf, and I*-0 is corrupted
* to -0.0+I*0.0.
*/
#include
#include
#include
int main(void) {
double complex z;
double x, y;
x = 0.;
y = 1. / x;
x = copysign(x, -1.);
/* z = 0 + i (-0) */
z = I * x;
printf("%e %e\n", creal(z), cimag(z));
/* z = 0 + i Inf */
z = I * y;
printf("%e %e\n", creal(z), cimag(z));
}
kargl[223] gcc -o z a.c -lm
kargl[224] ./z
-0.00e+00 0.00e+00
nan inf
This bug is in 3.4.4 up to an including mainline.
--
Summary: Complex arithmetic on special cases is incorrect.
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581
[Bug c/24581] Complex arithmetic on special cases is incorrect.
--- Comment #1 from joseph at codesourcery dot com 2005-10-29 20:09 --- Subject: Re: New: Complex arithmetic on special cases is incorrect. On Sat, 29 Oct 2005, kargl at gcc dot gnu dot org wrote: > * underflow, sign and efficiency bugs by rewriting I*y as > * (0.0+I)*(y+0.0*I) and laboriously computing the full complex product. Note that the correct form is (0.0+I)*y, since I is (per C99+TC1+TC2) _Complex_I, of complex type (Annex G imaginary types conflicting with the normative standard, unless and until anything changes in this respect following DR#323). But the usual arithmetic conversions as specified in the standard do not convert both operands to complex, so one can be real and one complex. I suspect there are lots of presumptions in the compiler that arithmetic operations such as PLUS_EXPR and MULT_EXPR have both operands of the same type, which would need to be fixed to represent a real*complex product properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581
[Bug middle-end/24581] Complex arithmetic on special cases is incorrect.
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-29 20:10 --- Hmm, I want to say this is a defect in the standard but what do I know. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581
[Bug middle-end/24581] Complex arithmetic on special cases is incorrect.
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-29 20:14 --- (In reply to comment #1) > I suspect there are lots of presumptions in the compiler that arithmetic > operations such as PLUS_EXPR and MULT_EXPR have both operands of the same > type, which would need to be fixed to represent a real*complex product > properly. Or get the front-end emitting the correct code in the first place and not worry about real*complex in the middle-end which is a much better option and safer one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581
[Bug c/24581] Complex arithmetic on special cases is incorrect.
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu 2005-10-29 20:27 --- Subject: Re: Complex arithmetic on special cases is incorrect. On Sat, Oct 29, 2005 at 08:09:45PM -, joseph at codesourcery dot com wrote: > > > * underflow, sign and efficiency bugs by rewriting I*y as > > * (0.0+I)*(y+0.0*I) and laboriously computing the full complex product. > > Note that the correct form is (0.0+I)*y, since I is (per C99+TC1+TC2) > _Complex_I, of complex type (Annex G imaginary types conflicting with the > normative standard, unless and until anything changes in this respect > following DR#323). But the usual arithmetic conversions as specified in > the standard do not convert both operands to complex, so one can be real > and one complex. > If I read Annex G correctly, the z = I*inf = NaN + I inf is going to really bad things because the NaN is going to propagate if z is used in further computations. Annex G says z is an infinity. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581
[Bug c/21343] [4.0/4.1 Regression] incompatible internal linkage declarations in different scopes not diagnosed
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-29 20:45 --- Should this block PR 16620 and PR 16989? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21343
[Bug c/21343] [4.0/4.1 Regression] incompatible internal linkage declarations in different scopes not diagnosed
--- Comment #3 from joseph at codesourcery dot com 2005-10-29 20:48 --- Subject: Re: [4.0/4.1 Regression] incompatible internal linkage declarations in different scopes not diagnosed On Sat, 29 Oct 2005, pinskia at gcc dot gnu dot org wrote: > Should this block PR 16620 and PR 16989? No, because there is no requirement for a diagnostic in these cases; they are all compile-time undefined behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21343
[Bug middle-end/21718] real.c rounding not perfect
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-29 20:50 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-29 20:50:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
[Bug c/24581] Complex arithmetic on special cases is incorrect.
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-29 20:51 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-29 20:51:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581
[Bug middle-end/24565] [4.1 Regression] facerec performance regression
--- Comment #2 from steven at gcc dot gnu dot org 2005-10-29 21:52 --- You'll have to investigate the drop a bit more. That patch you identified was supposed to fix the performance problems of a previous fix for some bug. It should not have any adverse effects. You'll have to identify the code that is worse optimized now (hopefully find a small test case too), so that we can look into this problem and figure out what's wrong... -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24565
[Bug c++/24582] New: [4.1 regression] ICE in decl_jump_unsafe
Compile the to-be-attached test case, and you get an ICE in the front end after errors: jigdo-file.cc: At global scope: jigdo-file.cc:491: error: 'class JigdoFileCmd::Command' is not a class or namespace jigdo-file.cc:491: error: ISO C++ forbids declaration of 'cmdOptions' with no type int::cmdOptions(int, char**) jigdo-file.cc:493: error: 'binaryName' was not declared in this scope jigdo-file.cc:496: error: 'optReporter' was not declared in this scope jigdo-file.cc:546: error: 'optZipQuality' was not declared in this scope jigdo-file.cc:547: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in decl_jump_unsafe, at cp/decl.c:2153 -- Summary: [4.1 regression] ICE in decl_jump_unsafe Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: minor Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: steven at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24582
[Bug c++/24582] [4.1 regression] ICE in decl_jump_unsafe
--- Comment #1 from steven at gcc dot gnu dot org 2005-10-29 22:10 --- Created an attachment (id=10080) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10080&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24582
[Bug c++/24582] [4.1 regression] ICE in decl_jump_unsafe
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-29 22:23 --- This is my fault, will fix but tomorrow. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24582
[Bug target/23070] [3.4 only] CALL_V4_CLEAR_FP_ARGS flag not properly set
--- Comment #5 from amodra at gcc dot gnu dot org 2005-10-29 22:35 --- Subject: Bug 23070 Author: amodra Date: Sat Oct 29 22:35:37 2005 New Revision: 105998 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105998 Log: PR target/23070 * config/rs6000/rs6000.c (function_arg): For ABI_V4 calls to stdarg functions, set/clear the fp marker even when no variable args are passed. * config/rs6000/sysv4.h (SUBTARGET_SWITCHES): Describe -mprototype and -mno-prototype. Modified: branches/gcc-3_4-branch/gcc/ChangeLog branches/gcc-3_4-branch/gcc/config/rs6000/rs6000.c branches/gcc-3_4-branch/gcc/config/rs6000/sysv4.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23070
[Bug tree-optimization/17863] [4.0/4.1 Regression] threefold performance loss, not inlining as much
--- Comment #26 from steven at gcc dot gnu dot org 2005-10-29 22:36 --- Waiting for someone to look into this... -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
[Bug target/23070] [3.4 only] CALL_V4_CLEAR_FP_ARGS flag not properly set
--- Comment #6 from amodra at bigpond dot net dot au 2005-10-29 22:36 --- Fixed. -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23070
[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP
--- Comment #20 from steven at gcc dot gnu dot org 2005-10-29 22:38 --- amacleod, are you going to post your patch and/or commit it?? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097
[Bug tree-optimization/23335] [4.0/4.1 Regression] copyrename does not coalesce different type variables (useless type conversion)
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-29 22:43 --- Is the only problem here one single extra SET produced by expand, or do we have a bug here somewhere? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23335
[Bug libstdc++/22087] ctype tables are offset by one on DJGPP
--- Comment #6 from pcarlini at suse dot de 2005-10-29 22:45 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22087
[Bug libgcj/24583] New: InetAddress.getLocalHost() returns broken InetAddress object when run in chroot
When a Java program is run in a chroot environment on Linux,
InetAddress.getLocalHost() returns a broken InetAddress object (broken in the
same way as it was in bug 17069).
Test case:
import java.net.InetAddress;
import java.net.UnknownHostException;
public class TestAddr {
public static void main (String args []) throws UnknownHostException {
InetAddress.getLocalHost ().getAddress ();
}
} // end of class TestAddr
The test case prints this inside the chroot:
Exception in thread "main" java.lang.NullPointerException
at java.net.InetAddress.getAddress() (/usr/lib/libgcj.so.6.0.0)
at TestAddr.main(java.lang.String[]) (Unknown Source)
at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0)
at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0)
and nothing when not in a chroot.
By using LD_LIBRARY_PATH I have verified that the brokenness _is_ triggered by
the chroot, not by the different versions of libc and libgcj that are
dynamically linked against when inside the chroot:
bash-3.00$ LD_LIBRARY_PATH=/mnt/rawhide/usr/lib:/mnt/rawhide/lib ldd
/mnt/rawhide/home/greenrd/testaddr
linux-gate.so.1 => (0xe000)
libgcc_s.so.1 => /mnt/rawhide/lib/libgcc_s.so.1 (0x00db1000)
libgcj.so.6 => /mnt/rawhide/usr/lib/libgcj.so.6 (0x0200)
libm.so.6 => /mnt/rawhide/lib/libm.so.6 (0x00354000)
libpthread.so.0 => /mnt/rawhide/lib/libpthread.so.0 (0x0039)
libz.so.1 => /mnt/rawhide/usr/lib/libz.so.1 (0x0037b000)
libdl.so.2 => /mnt/rawhide/lib/libdl.so.2 (0x0034e000)
libc.so.6 => /mnt/rawhide/lib/libc.so.6 (0xf7ed1000)
/lib/ld-linux.so.2 (0x00248000)
bash-3.00$ LD_LIBRARY_PATH=/mnt/rawhide/usr/lib:/mnt/rawhide/lib
/mnt/rawhide/home/greenrd/testaddr
bash-3.00$
The real /dev, /proc and /sys are mounted inside the chroot, and /sbin/ifconfig
can see all the network interfaces and their IPs when run as the same user from
inside the chroot, so it is not the case that the kernel is hiding this
information.
--
Summary: InetAddress.getLocalHost() returns broken InetAddress
object when run in chroot
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: greenrd at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24583
[Bug libgcj/24583] InetAddress.getLocalHost() returns broken InetAddress object when run in chroot
--- Comment #1 from greenrd at gcc dot gnu dot org 2005-10-30 00:21 --- Also, the hostname command does work inside the chroot - it returns the hostname of the real machine. So I don't think this is a reoccurrence of bug 17069. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24583
[Bug bootstrap/24394] Bootstrap failure: conflicting types for 'floatformat_to_double', others
--- Comment #3 from mckelvey at maskull dot com 2005-10-30 01:23 --- OK, I updated my cygwin and it built. You can close the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24394
Gnu-gcc-bug accidia alehoof
Hey Jennie, Remember I told you about that e-mail I got the other day saying I could get my B/A, B/S/C, M/A, M/S/C, M/B/A, P/H/D, in 2 weeks without any study required and 100% verifiable ? Well bro I gave it a shot and now 2 weeks later I have my BA and working on getting my Masters which I will have finished up in the next week and half! I didn't believe this either man, I was a bit skeptical when i first heard about this program, but the counselor made it clear it was ,.100% legit and the op,portunity exists due to a legal loophole allowing some established colleges to award degre.es at their dis.cretion. bro life cant get any better for me right now... I have jobs that wouldn't of gave me a chance before calling me off the hook wanting me to come work for them, also the money i'm capable of making now is amazing! Listen Jennie,I've known you for over 10years man, I know you have been struggling with bills, and working 2 jobs I just want to let you know man,things can be alot easier for you call this # n,ow 1-206- 338-5780. Well, Listen to an old friend for once , and do this one thing not just for me and my satisfac,tion of seeing you succeed , but just think how much happier you & your family will be when you are making the money you deserve at a job you actually like! Take advantage of this opportunity right now man , the counselor told me the other day they aren't accepting many more students for this offer so hurry and call this # 1- 2,0,6,-338-5780 it will be the best thing you ever did, trust me! Just leave a brief message with the de.gree you're interested and they will call back A.S,A,P. Well bud, opport,unity only knocks once... and I opened the door. I'm on my way to being the successful man that I always knew I would be, just didn't think it would be this fast and easy! let me know how it goes your friend, Nunez I hate playing quickly.. Did Alfred's niece like playing well?. I am not missing surfing.. But this is where you come in: Between now and November, you, the American people, you can reject the tired, old, hateful, negative politics of the past. And instead you can embrace the politics of hope, the politics of what's possible because this is America, where everything is possible.. Cathy hasn't practiced reading yet.. Joseph has just remembered walking.. Don't you practice dancing as often as possible?. cheese burger and cheese fries m. 5. That computer programmer isn't enjoying swimming behind the post office right at this time. I am missing working right now.. Jackie has disliked writing since five weeks ago.. I don't hate studying in London.. That flight attendant is not missing playing below the bridge at this exact moment.. today i need to goto the store. . 10. Ninety six bottles of beer, three a's, three b's, one c, two d's, thirty six e's, three f's, two g's, seven h's, eleven i's, one j, one k, six l's, one m, twenty n's, twelve o's, one p, one q, six r's, twenty eight s's, nineteen t's, seven v's, seven w's, six x's, and five y's on the wall.. I don't practice reading once a week.. Joseph doesn't dislike praying carelessly.. Jackie has disliked writing since five weeks ago.. 2. 10. Ninety six bottles of beer, three a's, three b's, one c, two d's, thirty six e's, three f's, two g's, seven h's, eleven i's, one j, one k, six l's, one m, twenty n's, twelve o's, one p, one q, six r's, twenty eight s's, nineteen t's, seven v's, seven w's, six x's, and five y's on the wall.. That flight attendant is not missing playing below the bridge at this exact moment.. Weren't those plumbers practicing talking last month?. Were those pilots practicing praying?. I am enjoying eating in the river.. I'll study as soon as you have liked skiing.. I have just practiced talking.. 2. Those janitors aren't missing sleeping right now.. Those news announcers aren't practicing shaving next to the police station right at this time.. Have the managers already loved shouting?.
[Bug libfortran/24459] gfortran namelist problem
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2005-10-30 02:59 --- OK I have a patch for the segfault I was seeing and now I see the error the OP discusses. I will continue on that as soon as I get the other bug fix submitted for review. (I will have to create a new PR for the segfault) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24459
[Bug libfortran/24584] New: Segfault when reading empty string in namelist file
The following program segfaults when the input file has an empty string
specified.
PROGRAM foo
IMPLICIT NONE
CHARACTER(len=10) var
CHARACTER(len=10) sname
NAMELIST /input/ var
sname = 'howdy'
WRITE(*,*) sname, "<<<"
OPEN(unit=1,file="input.tmp",delim='apostrophe',status='unknown')
READ(1,NML=input) var
CLOSE(1)
WRITE(*,*) var
END PROGRAM foo
The input file is:
$ cat input.tmp
&INPUT
var=''
/
The following patch fixes this problem:
Index: io/list_read.c
===
--- io/list_read.c (revision 105987)
+++ io/list_read.c (working copy)
@@ -799,8 +799,11 @@
push_char (quote);
break;
}
-
unget_char (c);
+
+ /* Must be an empty string. */
+
+ push_char('\0');
goto done;
CASE_SEPARATORS:
--
Summary: Segfault when reading empty string in namelist file
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: jvdelisle at gcc dot gnu dot org
ReportedBy: jvdelisle at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24584
[Bug libfortran/24584] Segfault when reading empty string in namelist file
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-10-30 03:56 --- With this patch there is a side effect with read_null_string.f90 in gfortran.fortran-torture. Checking on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24584
[Bug libfortran/24584] Segfault when reading empty string in namelist file
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2005-10-30 04:51
---
OK Now, Regrssion tested OK Will submit to list for approval
Index: io/list_read.c
===
--- io/list_read.c (revision 105987)
+++ io/list_read.c (working copy)
@@ -1998,12 +1998,18 @@
break;
case BT_CHARACTER:
- m = (dlen < saved_used) ? dlen : saved_used;
- pdata = (void*)( pdata + clow - 1 );
- memcpy (pdata, saved_string, m);
+ if (saved_string)
+ {
+ m = (dlen < saved_used) ? dlen : saved_used;
+ pdata = (void*)( pdata + clow - 1 );
+ memcpy (pdata, saved_string, m);
+ }
+ else
+ m = 0;
+
if (m < dlen)
memset ((void*)( pdata + m ), ' ', dlen - m);
- break;
+ break;
default:
break;
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2005-10-30 04:51:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24584
[Bug bootstrap/24394] Bootstrap failure: conflicting types for 'floatformat_to_double', others
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-30 05:48 --- Closing as works for me then. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24394
