Kenneth Pronovici writes: > > You may have been confused by the multiple layers of bug tracking going > > on here. The above was written by an upstream GCC maintainer, who isn't > > necessarily running Debian. > > No, actually I understood that... mainly, I did not realize that I was > supposed to be managing this bug report with upstream myself.
For reports forwarded upstream it is certainly useful to subscribe to the upstream report as well. This particular report was erreanously forwarded with a -quiet submitter address, so I didn't notice much progress, however I did check that the source isn't available anymore at the specified address, so it's not reproducible anymore. > > On top of that, it is longstanding GCC policy to refuse bug reports of > > the form "go download the source from blahblahblah and build it yourself". > > Which is fine, but then I would have expected the Debian maintainers to > ask me to put something else together before submitting the bug upstream > (remember, I didn't submit the bug to upstream, I submitted it to > Debian, and someone else later submitted it upstream). > > > That's why "just apt-get from sid" doesn't do anything to help. > > You're right, that won't help the GCC folks, but it should help the > Debian folks whose bug we're talking about (again, I was under the > assumption that someone other than me was managing this bug). No, I wouldn't have time for anything else if I would do this. > Don't get me wrong - I don't blame the GCC folks for closing this bug. > If they didn't get enough information or any responses, what else could > they do? I'm annoyed at the lack of communication that kept the GCC > folks from getting the information they needed even thought they waited > three months for it. > > > What more information do we need? For a C-family language, it would be > > "complete preprocessed source, and all compiler diagnostics." I'm not a > > Java maintainer, but I believe they need something similar. Does that help? > > Yes, it does. > > There isn't much to NBIO - only about 2700 lines of code - and the test > case is pretty tiny. However, I'll spend some time trying to reduce > that to as small of an example as I can. > > Incidentally, at this point, I'm not sure whether this is a compiler bug > or an interpreter bug. I'm leaning toward it being an interpreter bug, > since Kaffe seems to be able to run the test code with no problems even > when the .jar and .class files are built with gcj. try to run/build it with gcc-snapshot. If it's not a regression compared to a former gcc version, it probably won't be fixed in gcc-3.3. it may be fixed in 3.4, if you provide information on: - the gcc versions you tested with (3.3.2 and mainline aka gcc-snapshot) - the NBIO version/sources used. something preprocessed might be difficult in this case, but at least a location, where the sources can be fetched without debian specific tools. - the flags used to compile - the testcase, which fails. If you attach this information to the upstream report, then its forwarded to the Debian report as well. Thanks, Matthias
