[Bug c++/38986] New: comparing lengths of 2 strings reads through both strings completely
Suppose that someone wants to see if a string is shorter than another and
writes:
#include
bool f(char const * const a, char const * const b) {return strlen(a) <=
strlen(b);}
Then g++ generates this:
pushl %ebp
movl%esp, %ebp
pushl %ebx
subl$4, %esp
movl8(%ebp), %eax
movl%eax, (%esp)
callstrlen
movl%eax, %ebx
movl12(%ebp), %eax
movl%eax, (%esp)
callstrlen
cmpl%eax, %ebx
setbe %al
addl$4, %esp
popl%ebx
popl%ebp
ret
But it looks like this code reads through both strings completely! This is
obviously very efficient if one of the strings is much longer than the other.
It should of course only read as far into each string as the shortest of them
is long. The generated code should be similar to what this would give:
bool g(char const * a, char const * b) {
for (;; ++a, ++b)
if (not *a)
return true;
else if (not *b)
return false;
}
--
Summary: comparing lengths of 2 strings reads through both
strings completely
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: esigra at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38986
[Bug c++/38986] comparing lengths of 2 strings reads through both strings completely
--- Comment #2 from esigra at gmail dot com 2009-01-30 16:12 --- GCC already understands the semantics of strlen. If one of the operands to "<" is a constant and the other is strlen, it is optimized (such as "strlen(str) >= 1). It just seems like the case with strlen on both sides is missing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38986
[Bug c++/40614] New: no -Werror= for attribute warn_unused_result
There is no way to get an error for ignoring the result of a function with attribute warn_unused_result. There should be something like -Werror=unused-return-value (or attribute error_unused_result). -- Summary: no -Werror= for attribute warn_unused_result Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: esigra at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40614
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #11 from esigra at gmail dot com 2008-09-21 20:38 --- I found that James' wish is already implemented in some cases: $ strings /usr/i686-pc-linux-gnu/gnat-gcc-bin/4.2/gnat|grep "RM " illegal use of remote access-to-class-wide type, see RM E.4(18) A user that gets that error message can look it up at for example [http://www.adacore.com/multimedia/Ada2005_RM_HTML/RM-E-4.html]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug ada/37618] New: parameter used for dispatching gives warning: formal parameter "X" is not referenced
A parameter of a type without actual data components, that is only used for
dispatching, gives:
warning: formal parameter "X" is not referenced
But the type is a null record, so there is nothing that could be referenced.
And the parameter is actually used to select which function to call. Sample
code will be attached.
--
Summary: parameter used for dispatching gives warning: formal
parameter "X" is not referenced
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: esigra at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37618
[Bug ada/37618] parameter used for dispatching gives warning: formal parameter "X" is not referenced
--- Comment #1 from esigra at gmail dot com 2008-09-23 09:38 --- Created an attachment (id=16383) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16383&action=view) Makefile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37618
[Bug ada/37619] New: overriding Finalize gives: warning: declaration of "Finalize" hides one at line N
The procedure Finalize is supposed to be overridden to get a constructor for a type, but doing so gives a warning, eventhough the code explicitly states that the new Finalize should override the old one. Sample code attached. -- Summary: overriding Finalize gives: warning: declaration of "Finalize" hides one at line N Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: esigra at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37619
[Bug ada/37619] overriding Finalize gives: warning: declaration of "Finalize" hides one at line N
--- Comment #1 from esigra at gmail dot com 2008-09-23 09:51 --- Created an attachment (id=16386) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16386&action=view) Makefile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37619
[Bug ada/37619] overriding Finalize gives: warning: declaration of "Finalize" hides one at line N
--- Comment #2 from esigra at gmail dot com 2008-09-23 09:51 --- Created an attachment (id=16387) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16387&action=view) specification -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37619
[Bug ada/37619] overriding Finalize gives: warning: declaration of "Finalize" hides one at line N
--- Comment #3 from esigra at gmail dot com 2008-09-23 09:52 --- Created an attachment (id=16388) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16388&action=view) implementation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37619
[Bug ada/37618] parameter used for dispatching gives warning: formal parameter "X" is not referenced
--- Comment #2 from esigra at gmail dot com 2008-09-23 09:39 --- Created an attachment (id=16384) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16384&action=view) specification -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37618
[Bug ada/37618] parameter used for dispatching gives warning: formal parameter "X" is not referenced
--- Comment #3 from esigra at gmail dot com 2008-09-23 09:39 --- Created an attachment (id=16385) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16385&action=view) implementation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37618
[Bug ada/37620] warning: variable "X" is not referenced eventhough it is referenced by (implicit) procedure calls
--- Comment #1 from esigra at gmail dot com 2008-09-23 10:26 --- Created an attachment (id=16390) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16390&action=view) Makefile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37620
[Bug ada/37620] warning: variable "X" is not referenced eventhough it is referenced by (implicit) procedure calls
--- Comment #2 from esigra at gmail dot com 2008-09-23 10:27 --- Created an attachment (id=16391) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16391&action=view) implementation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37620
[Bug ada/37620] New: warning: variable "X" is not referenced eventhough it is referenced by (implicit) procedure calls
Even though a variable is referenced by (implicit) procedure calls (such as
Initialize and Finalize), GCC gives:
warning: variable "X" is not referenced
This happens especially when using the RAII design pattern. The warning should
not be shown when the variable is referenced by a procedure call, even if it is
implicit. Sample code attached.
--
Summary: warning: variable "X" is not referenced eventhough it is
referenced by (implicit) procedure calls
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: esigra at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37620
[Bug ada/37620] warning: variable "X" is not referenced eventhough it is referenced by (implicit) procedure calls
--- Comment #3 from esigra at gmail dot com 2008-09-23 10:32 --- Created an attachment (id=16392) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16392&action=view) Makefile -- esigra at gmail dot com changed: What|Removed |Added Attachment #16390|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37620
[Bug ada/37572] compile Ada program fails (XML/Ada, 64 bit AMD)
--- Comment #6 from esigra at gmail dot com 2008-10-05 13:42 --- This problem went away for me when I upgraded to GCC 4.3.1 (Gentoo x86), so it seems to be fixed. -- esigra at gmail dot com changed: What|Removed |Added CC||esigra at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37572
[Bug other/36150] colorize output of gcc
--- Comment #2 from esigra at gmail dot com 2008-05-06 17:27 --- I would definitely like GCC to produce colourized output. It can really improve the readability. I miss that feature. It has my vote. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #4 from esigra at gmail dot com 2008-05-06 18:00 --- (In reply to comment #3) > 2) Standards are not freely distributable, thus they are not widely available. You say that as if it was a general fact, but it is certainly not. For example the Ada reference manual is available right here: [http://www.ada-auth.org/arm.html] More correct would be to say that *some* standards are not widely available. > Finally, if you still think it is worth it, you could implement it yourself > as a wrapper to the output of GCC (similar to how colorgcc [*] works). You must mean similar to how colorgcc *not* works. colorgcc is just an ugly hack that should be scrapped and burned as soon as GCC is fixed to format its own output properly. What colorgcc tries to do is total nonsense. It tries to parse localized output! Of course it fails for 94% of the supported languages (only English sort-of works as far as I know). Even English may fail if there is a version mismatch. And seriously, what is more efficent, adding a colour code sequence to the string constant in GCC that says "warning:" or having separate scripts for each combination of locale and GCC version, that parse the output of GCC and recreates it with colour codes? What would distributions prefer to maintain? -- esigra at gmail dot com changed: What|Removed |Added CC| |esigra at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug other/36150] colorize output of gcc
--- Comment #6 from esigra at gmail dot com 2008-05-06 18:40 --- (In reply to comment #4) > I rather not add too much complexity to gcc diagnostic output. Which means > no color. We did not demand that you do it personally. We just think that it would be a really good idea if someone would do it some time. Just how much complexity would it take? > colorgcc could be extended to get the correct coloring for the locazation. Sure it *could* be done, but it would require a version of colorgcc for each (combination of GCC version and) localization. Now we are talking about complexity! Localized output is inherently unsuitable for parsing. The existence of such an ugly hack is certainly no excuse for not allowing a proper implementation in GCC itself, where it belongs. And seriously, what is more efficcent, adding a colour code sequence to the string constans in GCC that says "warning:", "error:" etc or having a bunch of scripts for parsing the output of various GCC versions/localizations, recreating it with colour codes? What would distributions prefer to maintain? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #6 from esigra at gmail dot com 2008-05-06 18:47 --- (In reply to comment #5) > But seriously colorization should not be done in the compiler. Just like IDE > should not be part of the compiler ... Colorization of a message is part of the message. It should obviously be done whereever the message is constructed. (IDE has nothing to do with this.) With your argument, the compiler should not do text messages (or any localization thereof) either, but rather return some code that an external program formats/localizes and presents to the user in a suitable way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug other/36150] colorize output of gcc
--- Comment #8 from esigra at gmail dot com 2008-05-06 21:55 ---
(In reply to comment #7)
> If you added escape sequences to the string constants in the gcc source
> then it would only work for the C locale messages.
Adding escape sequences for colours would work as well with localization as any
other formatting. Simple example:
printf("%s%s%s%s", warning_format_start, _("warning: "), _("the actual
message"), warning_format_end);
Here warning_format_start may be a pointer to "" and warning_format_end
a pointer to "". If colours are disabled, they both point to "". So
the result might be "warning: the actual message" or "warning: the
actual message". Localization would work fine for both "warning: " and
"the actual message". I do not really see the problem that you were thinking
of.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #8 from esigra at gmail dot com 2008-05-07 13:08 --- (In reply to comment #7) > Adding color output (ala ls --color) or the proposal in this bug (gcc as a > lecturer in programming) show a critical misunderstanding: Assuming that GCC > developers are bored and have nothing to do. There are many many features that > GCC developers themselves would like to see implemented and they are not > because of lack of time. Therefore, people coming up with random half-backed > ideas, which they do not intend to fully specify, much less implement, is > hopeless. Sorry, you got it totally wrong! When someone suggests a feature that he thinks would be useful, he does definitely not imply that the current developers are bored and have nothing to do. The critical misunderstanding here is that some GCC developers think that a feature request is something that they are obliged to implement within a certain time and the only way to get rid of that obligation is to dismiss any idea, that they do not have time to implement right now, as invalid. We are developers too for various projects and we get feature requests all the time. Many of the ideas that we get are useful but there is no way that we can implement them all within the foreseeable future. Still we do not rush to dismiss ideas as invalid. And we certainly do not misconceieve it as implications that we are bored or do not have any ideas of our own. I think the criterion for closing feature requests as invalid should be modified from "we do not have time to implement this feature any time soon" to "there is no way that this feature would be useful". This is how most projects handle it and what reporters interpret it as. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
