Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hv at crypt dot org
Target Milestone: ---
In https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html and
https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Other-Builtins.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329
--- Comment #5 from Hugo van der Sanden ---
(In reply to Martin Sebor from comment #4)
> For functions like pthread_getspecific() and pthread_setspecific() that do
> not access the object GCC provides attribute access none to suppress the
> warn
Assignee: unassigned at gcc dot gnu.org
Reporter: hv at crypt dot org
Target Milestone: ---
This is reduced from perl source code. Reduction was a challenge, so there's a
risk the essence may have been lost.
The following code gives a -Wmaybe-uninitialized warning with each of &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329
--- Comment #2 from Hugo van der Sanden ---
I guess this is justified by the second paragraph of the -Wmaybe-uninitialized
docs: "In addition, passing a pointer (or in C++, a reference) to an
uninitialized object to a const-qualified function ar
iority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hv at crypt dot org
Target Milestone: ---
Reduced from perl source code:
% cat test.c
extern void *malloc (long unsigned int size);
extern void f1 (const void *pointer);
void perl_alloc(void) {
: unassigned at gcc dot gnu.org
Reporter: hv at crypt dot org
Target Milestone: ---
The following code warns with gcc-11.2.0 (but not with 9.2.1-17ubuntu1~18.04.1)
in testera(), but not in testerb() which differs only by the removal of an
assert. I don't understand this, and canno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44081
--- Comment #14 from Hugo van der Sanden ---
(In reply to Manuel López-Ibáñez from comment #13)
> Should we close this?
With what status?
I think it should at least be updated to CONFIRMED, based on the comments from
valeriy.
I should note als
--- Comment #9 from hv at crypt dot org 2010-05-12 10:54 ---
The direction of discussion has centred so far on the documentation, but as far
as I can tell the only point at which the documentation confused someone was
the triage at #3. Should there not be a separate bug opened for
--- Comment #4 from hv at crypt dot org 2010-05-11 15:38 ---
(In reply to comment #3)
> That's a user bug. You shouldn't pass NULL to arguments declared nonnull.
> To quote gcc documentation:
> "The compiler may also choose to make optimizations based
> on
--- Comment #2 from hv at crypt dot org 2010-05-11 14:41 ---
Created an attachment (id=20631)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20631&action=view)
Generated assembly code, with annotation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44081
--- Comment #1 from hv at crypt dot org 2010-05-11 14:41 ---
Created an attachment (id=20630)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20630&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44081
s/2010-05/msg00316.html>.
--
Summary: Incorrect nonnull assumed in code generation
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
Repor
--- Comment #1 from hv at crypt dot org 2010-05-05 14:39 ---
Created an attachment (id=20562)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20562&action=view)
Example C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43992
erity: enhancement
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hv at crypt dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43992
14 matches
Mail list logo
