https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109290
lavr at ncbi dot nlm.nih.gov changed:
What|Removed |Added
CC||lavr at ncbi dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
lavr at ncbi dot nlm.nih.gov changed:
What|Removed |Added
CC||lavr at ncbi dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108561
--- Comment #3 from lavr at ncbi dot nlm.nih.gov ---
Also, the standard seems to mention that flush() is an "unformatted output
function", meaning it is supposed to build and check a sentry object (which in
case of a bad stream, woul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108561
--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
Indeed, it does not. But the reason the endl manipulator is there, is to flush
_after_ '\n'. If the stream has gone bad in between, it is the gray area, but
for the output device (
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
As implemented:
template
inline basic_ostream<_CharT, _Traits>&
endl(basic_ostream<_CharT, _Traits>& __os)
{ return flush(__o
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
Tried on both Ubuntu and Cygwin, the same gcc-11.3.0 -- and the same problem:
$ gcc --version
gcc (Ubuntu 11.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96293
--- Comment #10 from lavr at ncbi dot nlm.nih.gov ---
> In your code, `&a->record.data[0]` is not a well-aligned access
It is well-aligned, its offset gets printed out by the very test code, and it's
2.
> because `struct att
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96293
--- Comment #8 from lavr at ncbi dot nlm.nih.gov ---
Consider the following code:
struct record {
unsigned char len;
unsigned short data[5];
} __attribute__((packed));
struct attribute {
unsigned char code;
struct record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96293
--- Comment #7 from lavr at ncbi dot nlm.nih.gov ---
The problem with the aligned(4) attribute is that if this structure appears as
a member of an outer packed structure, it may not be "enclosed" properly
without a gap.
The wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106092
--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
Created attachment 53201
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53201&action=edit
preprocessed source
Attached! It's rather big
++
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
I got the following report from the compilation:
In file included from /home/ANTON/cxx/src/util/qparse/parser.cpp:352:
query_parser_bison.tab.c: In function ‘int ncbi_q_parse(void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103835
--- Comment #4 from lavr at ncbi dot nlm.nih.gov ---
Thank you for investigating this!
Like I said, it's better NOT to emit any warnings if some machinery in the
compiler is not perfect enough to recognize the danger correctly (as it used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103835
--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
Irrespective of whether atoi() is known, printing an "int" (or two) will never
produce this many characters... This, however, also seems to have triggered
some weird logic tha
: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
Please address these warnings because they create more noise than they help!
$ cat test.c
#include
#include
#include
const char* fun(char* buf, const char* pfx, int a, int b)
{
sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403
--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
> undefined if msg is not in the range of x.rec[0]...x.rec[RECLEN]
Indeed for the segmented data address space. But in most systems it's linear,
and the warning is then arch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100401
--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
> GCC warnings are designed to "report constructions that are not inherently
> erroneous but that are risky or suggest there may have been an error."
Certainly, but the [
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.2.0
$ cat test.c
#include
#include
#define RECLEN 128
struct R {
int head;
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.2.0
$ cat bogus.c
#include
#define RECLEN 128
struct S {
int code;
char text[0];
};
const void fun(int n)
{
union {
struct S s
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.2.0
$ cat test.c
#include
#include
int main(int argc, const char* argv[])
{
size_t len0 = strlen(argv[0]), len1 = strlen(argv[1]);
char buf[444
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96293
--- Comment #5 from lavr at ncbi dot nlm.nih.gov ---
My test case is not invalid. You're talking about base address of a structure,
which would make offsets within it all unaligned, which is why I said "the same
rule should apply for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96293
lavr at ncbi dot nlm.nih.gov changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96293
--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
I don't want my structure to be aligned at the int boundary. I want my
structure to reflect the actual data layout "byte","byte","short","int&quo
NCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
Hi,
Beginning version 9 GCC started to generate tons of warnings of "unaligned
pointer valu
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
When I use the -O6 optimization, I noticed that GCC 7.4.0 interjects some
redundant code, like marked below:
mulP:
.seh_endprologue
movq%rcx, %r10
movq%rdx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230
--- Comment #6 from lavr at ncbi dot nlm.nih.gov ---
That said, any function call within the outer "if()" but before the inner
"if()" would cause the warning, even if that call does not accept any pointers
(and thus cannot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230
--- Comment #5 from lavr at ncbi dot nlm.nih.gov ---
Thank you Martin, for giving me the idea of where the problem might be stemming
from! It does look like *printf() is not recognized by GCC as not modifying
the local memory. But in your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230
--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
Okay, but "d" points to a clearly separate storage on stack within a local
frame. None of the pointers passed to (s)printf() relate to that area (either
they are also clearly separ
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
I have a piece of code that reads like this (line numbers added):
2401 if (d->D_fid[2] || !(hdr = getfh(vol, d->D_fid[0],
tmp)) || d->D_fid[1] != hdr->H_fse
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
The following code
$ cat bogus1.c
#include
static char* print(const unsigned short a[2])
{
static char buf[3];
if (a[0] && a[0] < a[1])
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100
--- Comment #10 from lavr at ncbi dot nlm.nih.gov ---
> I guess also a dup of PR57201.
While I can agree these cases (and the one mentioned within PR57201) look
similar, the gravity of the disappearing warning in case of a mismatched type
is m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100
--- Comment #8 from lavr at ncbi dot nlm.nih.gov ---
This is the code from the original .c file that fails to post a warning.
sock->w_len -= BUF_PeekAtCB(sock->w_buf,
BUF_Size(sock->w_buf) - so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100
--- Comment #6 from lavr at ncbi dot nlm.nih.gov ---
The .c file has a lot of headers included. Do you want all of them, as well?
OTOH, the code in the preprocessed file clearly shows the use of a function
pointer of mismatched type gone un
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100
--- Comment #4 from lavr at ncbi dot nlm.nih.gov ---
Created attachment 32072
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32072&action=edit
Preprocessed C source that fails to produce a warning when compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100
--- Comment #3 from lavr at ncbi dot nlm.nih.gov ---
Ok, sorry and let me start again. My original mockup case wasn't good enough.
So attached is the real (preprocessed) code that fails to produce a warning
(yet when compiled from the .c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100
--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
> Because your command line did not actual compile anything.
Indeed. with .i I see the warning again. But I can't see
any warning if the precompiled file is processed through distcc...
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Created attachment 32070
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32070&action=edit
GCC specs are attached
Hello,
When compiling the attached C code w
36 matches
Mail list logo
