[Bug web/45655] New: GCC WIki Needs Text Colorizing Capability
The GCC Wiki does not have the text colorizing macro installed (or else it doesn't seem to work as it's supposed to). See http://moinmo.in/MacroMarket/Color2 for more details on it. -- Summary: GCC WIki Needs Text Colorizing Capability Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tom dot browder at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45655
[Bug preprocessor/45599] New: Remove all code applying to obsolete #pragma once
The pragma once is obsolete due to cpp optimizations and #pragma once can be completely ignored. Any code referring to it should be removed. -- Summary: Remove all code applying to obsolete #pragma once Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tom dot browder at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45599
[Bug preprocessor/45599] Remove all code applying to obsolete #pragma once
--- Comment #2 from tom dot browder at gmail dot com 2010-09-08 15:02 --- Ah, you are correct--old code may have that only. How about a warning instead about using the recommended construct (the header guard) instead of the pragma once? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45599
[Bug preprocessor/45599] Remove all code applying to obsolete #pragma once
--- Comment #4 from tom dot browder at gmail dot com 2010-09-08 15:29 --- Oops, I missed that PR. I still think that an optional warning should be there--something like -Wpragma-once with a message about the better practice. (Sorry I missed finding the original bug--I only looked at open bugs--I now know better.) -- tom dot browder at gmail dot com changed: What|Removed |Added CC||tom dot browder at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45599
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
--- Comment #34 from tom dot browder at gmail dot com 2010-09-07 17:58 --- (In reply to comment #33) I guess you meant to be CC'ed? Yes. The work I started was a Perl script to convert a 2.20+ database to the latest version. The last question I had of Daniel was could we get a test bed so others could try out the new bugzilla setup--looks like that is underway. There was another problem I had that I don't remember at the moment, but that was where I left it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug c++/45555] New: Add warnings for changes to code with option -fipa-sra
The -fipa-sra option may result in object code changes. Users should be notified of such changes so they can make source code changes. -- Summary: Add warnings for changes to code with option -fipa-sra Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tom dot browder at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug bootstrap/45556] New: Add PPL and CLooG-PPL source to gcc source tree for build
As of now, gcc builds with gmp, mpfr, and mpc source directories placed in the gcc tree by the user. Adding the other two main prerequisites into the tree for full gcc features would be a win for users. The inter-dependence of the configuration options between the latter two and gmp, mpfr, and mpc makes it difficult for a user to build all successfully without trial and error. An explicitly versioned set of the five sources known to work for a given version of gcc to be downloaded with a helper script (like the one by Andrew Haley: download_prerequisites.sh) would be very helpful and ease debugging and help for all. -- Summary: Add PPL and CLooG-PPL source to gcc source tree for build Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tom dot browder at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45556
[Bug other/45503] New: make distclean Does Not Remove All Local Configuration Data
After an aborted or clean build in a directory outside the gcc source tree, make distclean is supposed to remove all configuration information. However, that is not the case for at least one target (pdf). Using gcc-4.5.1 in my build directory (as a bash user): $ cd gcc_build $ ../gcc-4.5.1/configure ... # nothing unusual $ make pdf ... # nothing unusual except pdf target seems to # result in LOTs of extra compilation Come back the next day $ export CC=/usr/local/bin/gcc-4.5.1 $ cd gcc_build $ make distclean $ ls -aCF ./ ../ fixincludes/ $ ../gcc-5.5.1/configure ... # nothing unusual $ make pdf make[1]: Entering directory `/usr/local/src/gcc_build' make[2]: Entering directory `/usr/local/src/gcc_build' make[2]: Leaving directory `/usr/local/src/gcc_build' Configuring in ./fixincludes configure: loading cache ./config.cache configure: error: `CC' has changed since the previous run: configure: former value: `gcc' configure: current value: `/usr/local/bin/gcc-4.5.1' configure: error: in `/usr/local/src/gcc_build/fixincludes': configure: error: changes in the environment can compromise the build configure: error: run `make distclean' and/or `rm ./config.cache' and start over make[1]: *** [configure-fixincludes] Error 1 make[1]: Leaving directory `/usr/local/src/gcc_build' make: *** [do-pdf] Error 2 -- Summary: make distclean Does Not Remove All Local Configuration Data Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tom dot browder at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45503
[Bug fortran/38830] New: Add Variable Format Expression I/O Capability
I would like to see a new gfortran extension added so that the Variable Format Expression I/O capability will be available with gfortran as it is on many commercial compilers. Such a capability was once proposed as an addition to the Fortran 95 standard but was not accepted for some reason. -- Summary: Add Variable Format Expression I/O Capability Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tom dot browder at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38830
[Bug fortran/38830] Add Variable Format Expression I/O Capability
--- Comment #3 from tom dot browder at gmail dot com 2009-01-14 00:10 --- I'm sorry I didn't catch the original bug. I did search but missed the obvious reference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38830
[Bug fortran/38773] New: Arithmetic Overflow with Integer Parameter Assignment
The attached program causes an arithmetic overflow error with the following gfortran versions: 4.3.1, 4.3.2, and the trunk at revision 143193. It does NOT cause an error with version 4.2.1. Also attached is the output from running gfortran -v --save-temps. -- Summary: Arithmetic Overflow with Integer Parameter Assignment Product: gcc Version: unknown Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tom dot browder at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38773
[Bug fortran/38773] Arithmetic Overflow with Integer Parameter Assignment
--- Comment #1 from tom dot browder at gmail dot com 2009-01-09 01:13 --- Created an attachment (id=17060) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17060action=view) Program demonstrating the overflow error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38773
[Bug fortran/38773] Arithmetic Overflow with Integer Parameter Assignment
--- Comment #2 from tom dot browder at gmail dot com 2009-01-09 01:14 --- Created an attachment (id=17061) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17061action=view) Output from gfortran with -v --save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38773
[Bug fortran/38672] New: ICE during build with versions 4.3.2 and 4.4-20081226
The attached archive (Makefile, 2 source files, and output from gfortran -v) yields an ICE during build with versions 4.3.2 and 4.4-20081226 (but not version 4.1.2 20070925 (Red Hat 4.1.2-27)). -- Summary: ICE during build with versions 4.3.2 and 4.4-20081226 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tom dot browder at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38672
[Bug fortran/38672] ICE during build with versions 4.3.2 and 4.4-20081226
--- Comment #1 from tom dot browder at gmail dot com 2008-12-30 13:09 --- Created an attachment (id=17014) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17014action=view) Output from gfortan -v -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38672
[Bug fortran/38672] ICE during build with versions 4.3.2 and 4.4-20081226
--- Comment #2 from tom dot browder at gmail dot com 2008-12-30 13:11 --- Created an attachment (id=17015) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17015action=view) Archive with files to demonstrate the bug. The Makefile has a variable at the top to pick specific (or not) versions of gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38672
[Bug other/37210] Prohibit Default Builds in the GCC Source Tree
--- Comment #2 from tom dot browder at gmail dot com 2008-08-24 22:07 --- Andrew, you're right--it's not prohibited, but my argument is that it should be prohibited as the default build (but have a specific configure variable to allow it), at least until it is tested. Over the years I've watched people have a build problem, and the first thing the gurus tell them is *don't* build in the gcc tree, so this enhancement would at least get newbies' attention instead of continuing to waste help bandwidth. Note the recommendation to not build in the tree has been around I'll guess for at least ten years. And with the complexity of the build I doubt that the tested in-tree build will ever be a requirement for a release. I envision a short but succinct message telling about the prohibition and adding a link to more detail. The installation instructions should perhaps have text enhancement or other edits to highlight the reason for the prohibition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37210
[Bug other/37210] New: Prohibit Default Builds in the GCC Source Tree
The gcc configuration instructions *highly* recommend building outside the gcc source tree, and often, following the gcc-help list, I see that doing so causes problems. I propose that the build process be modified so as to default to *failing* to build under those circumstances. Add a configuration variable, if necessary, to allow such a build. In the meantime, I recommend that the highly recommendation be changed to some more mandatory language unless the user is a gcc developer. -- Summary: Prohibit Default Builds in the GCC Source Tree Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tom dot browder at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37210
[Bug c++/34198] -Wconversion gives apparent erroneous warning with g++ 4.3-20071109
--- Comment #15 from tom dot browder at gmail dot com 2007-11-24 02:36 --- Tried: g++ -c -Wconversion test_conversion.cc using g++ trunk of svn version 30392 and had no warnings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34198
[Bug c++/34198] New: -Wconversion gives apparent erroneous warning with g++ 4.3-20071109
Consider the following code:
f.cc ==
void f(const unsigned char b)
{
unsigned char c = static_castunsigned char(b 0xff);
}
== f.cc
Compile with g++ 4.1.2:
$ g++-4.3-20071109 -c f.cc -Wconversion
$
Note no warnings.
Compile with g++ 4.3-20071109:
$ g++-4.3-20071109 -c f.cc -Wconversion
f.cc: In function 'void f(unsigned char)':
f.cc:3: warning: conversion to 'unsigned char' from 'int' may alter its value
--
Summary: -Wconversion gives apparent erroneous warning with g++
4.3-20071109
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tom dot browder at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34198
[Bug c++/34198] -Wconversion gives apparent erroneous warning with g++ 4.3-20071109
--- Comment #2 from tom dot browder at gmail dot com 2007-11-22 21:37 --- Created an attachment (id=14617) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14617action=view) Intermediate file produced by g++-4.3-20071109 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34198
[Bug c++/34198] -Wconversion gives apparent erroneous warning with g++ 4.3-20071109
--- Comment #1 from tom dot browder at gmail dot com 2007-11-22 21:35 --- Created an attachment (id=14616) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14616action=view) Output from running: g++-4.3-20071109 -v -save-temps -c test_conversion.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34198
[Bug c++/34198] -Wconversion gives apparent erroneous warning with g++ 4.3-20071109
--- Comment #6 from tom dot browder at gmail dot com 2007-11-23 02:03 --- Created an attachment (id=14623) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14623action=view) Output from running: g++-4.3-20071109 -v -save-temps -c -wconversion test_conversion.cc -- tom dot browder at gmail dot com changed: What|Removed |Added Attachment #14616|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34198
[Bug c++/34198] -Wconversion gives apparent erroneous warning with g++ 4.3-20071109
--- Comment #7 from tom dot browder at gmail dot com 2007-11-23 02:05 --- Created an attachment (id=14624) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14624action=view) Intermediate file produced by g++-4.3-20071109 -- tom dot browder at gmail dot com changed: What|Removed |Added Attachment #14617|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34198
