[Bug c/31887] bad warning converting qualified void* to qualified array pointer
--- Comment #4 from bugs at 59A2 dot org 2008-11-17 12:24 ---
There is no way to qualify an array type, but this sort of conversion is very
useful. For instance, the optimizer produces better code for
void foo(const double a[], int m, int n) {
const double (*b)[n] = (const double(*)[n])a;
/* use b[i][j] in inner loops */
}
than when `a[i*n+j]' is used (without manually hoisting arithmetic out of inner
loops). With -Wcast-qual, a warning is given since the qualifier does not
apply to the array type, only the elements. Note that this example is very
similar to the example given in
http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf page 87
(physical page 94). Clearly the cast above should be possible, although there
is no way to express it in a way that is compatible with C99 paragraph 6.7.3.8.
I propose that -Wcast-qual promote qualifiers on array elements to the array
itself when determining whether a cast discards qualifiers. That is, not warn
for casts like the one above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31887
[Bug fortran/42852] New: gfortran -Wall warns about truncated lines when only a continuation character is truncated
gfortran -Wall currently warns about truncated lines even when character 73 is an ampersand. Observe item (4) of Note 3.10 in the Fortran 2003 standard: In some circumstances, for example where source code is maintained in an INCLUDE file for use in programs whose source form might be either fixed or free, observing the following rules allows the code to be used with either source form: (1) Confine statement labels to character positions 1 to 5 and statements to character positions 7 to 72; (2) Treat blanks as being significant; (3) Use only the exclamation mark (!) to indicate a comment, but do not start the comment in character position 6; (4) For continued statements, place an ampersand (&) in both character position 73 of a continued line and character position 6 of a continuing line. -- Summary: gfortran -Wall warns about truncated lines when only a continuation character is truncated Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bugs at 59A2 dot org GCC build triplet: gcc-4.5-20100121 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42852
[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated
--- Comment #2 from bugs at 59A2 dot org 2010-01-23 21:54 --- > In other words, fix your code by putting an & in column 72. This is not a solution since it makes it invalid fixed-form source: Error: Syntax error in argument list at (1) Not treating the char-73 & specially makes -Wline-truncation useless in projects containing source that is intended to be both fixed and free-form. I realize the note is not normative, and the spec states "If a source line contains only default kind characters, it shall contain exactly 72 characters; otherwise, its maximum number of characters is processor dependent". However, there are many people formatting code according to note 4.10, especially header code provided by libraries. Choosing fixed or free-form forces a convention on users, and this is really unacceptable. So, in lieu of gfortran addressing this ticket, the only way for a library to not break its users' ability to use -Wline-truncation would be to generate two versions of the header, but this is work to maintain and requires users to update all include statements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42852
[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated
--- Comment #4 from bugs at 59A2 dot org 2010-01-25 10:33 --- (In reply to comment #3) > So it's gfortran's fault you write non-portable code, and instead > of dealing with it on your end, you think that gfortran developers > should do the work to make your code compile. Actually, gfortran versions up to and including 4.4.2 do not complain about this usage (but it looks like that was due to -Wline-truncation being defective). All versions of gfortran compile this hybrid source "correctly", it's only (what I consider) a spurious warning with -Wline-truncation, and only in the 4.5 snapshot. > I'll note that I stated that I felt it should be closed with a > WONTFIX, but changed it to an enhancement request. In lieu of receiving > a patch from you to address the issue, someone may someday in the > distant future, when there are less important bugs to fix, might > address the issue. I'm not familiar with the project, but if you tell me where to look, I may be able to submit a patch. > The Note in the Standard is assuming a specific behavior for a > processor-dependent behavior. gfortran currently does not > assume that specific choice. Based on the way the source is compiled, as opposed to warnings under -Wline-truncation, gfortran *does* make that specific choice. If you are saying that this may change in the future (making such source an error instead of a warning), then the warning is completely valid (but anticipate user complaints if such a change happens). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42852
[Bug inline-asm/42881] New: SSE2 intrinsics miscompiled at -O0 -march=k8
ch=k8 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: inline-asm AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bugs at 59A2 dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42881
[Bug c++/42883] New: 4.5-20100121: internal compiler error: in redirect_eh_edge_1, at tree-eh.c:2112
This only occurs at positive optimization levels $ g++-4.5 -c -O0 avtOpenFOAMFileFormat.preprocessed.C # okay $ g++-4.5 -c -O1 avtOpenFOAMFileFormat.preprocessed.C /home/jed/visit/src/databases/OpenFOAM/avtOpenFOAMFileFormat.C: In member function vtkUnstructuredGrid* avtOpenFOAMFileFormat::MakeInternalMesh(): /home/jed/visit/src/databases/OpenFOAM/avtOpenFOAMFileFormat.C:443:23: internal compiler error: in redirect_eh_edge_1, at tree-eh.c:2112 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. $ g++-4.5 -v Using built-in specs. COLLECT_GCC=g++-4.5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr --enable-languages=c,c++,fortran --enable-gold --enable-plugin --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-lto --enable-gnu-unique-object --disable-multilib --disable-libstdcxx-pch --with-tune=generic --with-system-zlib --with-ppl --with-cloog --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-werror --enable-checking=release --program-suffix=-4.5 --enable-version-specific-runtime-libs : (reconfigured) ../configure --prefix=/usr --enable-languages=c,c++,fortran --enable-gold --enable-plugin --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-lto --enable-gnu-unique-object --disable-multilib --disable-libstdcxx-pch --with-system-zlib --with-ppl --with-cloog --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-werror --enable-checking=release --program-suffix=-4.5 --enable-version-specific-runtime-libs Thread model: posix gcc version 4.5.0 20100121 (experimental) (GCC) -- Summary: 4.5-20100121: internal compiler error: in redirect_eh_edge_1, at tree-eh.c:2112 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bugs at 59A2 dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42883
[Bug c++/42883] 4.5-20100121: internal compiler error: in redirect_eh_edge_1, at tree-eh.c:2112
--- Comment #1 from bugs at 59A2 dot org 2010-01-27 13:13 --- Created an attachment (id=19728) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19728&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42883
[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated
--- Comment #11 from bugs at 59A2 dot org 2010-07-25 16:23 --- Will this be applied to 4.5.1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42852
[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated
--- Comment #14 from bugs at 59A2 dot org 2010-07-25 19:23 --- Okay, thanks for the fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42852
[Bug c/44657] New: GCCSense: merge code-assist branch, or plugin
Some impressive code-completion features have been implemented as part of GCCSense, providing accurate editor-agnostic code completion. http://cx4a.org/software/gccsense/ This required some GCC modifications, and thus requires a customized compiler. It would be very useful if these modifications were merged upstream, or could at least be implemented as a plugin. Repository here: http://cx4a.org/repo/gcc.git -- Summary: GCCSense: merge code-assist branch, or plugin Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bugs at 59A2 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44657
[Bug c/44657] GCCSense: merge code-assist branch, or plugin
--- Comment #2 from bugs at 59A2 dot org 2010-06-24 18:08 --- Thanks, I have notified the author. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44657
