: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
This bug report is vaguely related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26542 but whereas that report asks
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
Consider the following code:
va_list ap;
void *result;
va_start(ap, ptr_type);
switch (ptr_type) {
case 0: result = va_arg(ap, int*); break;
case 1: result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80409
--- Comment #2 from Pascal Cuoq ---
> it should work even with standard c
Quoting from 7.6.1.1:2
… the behavior is undefined, except for the following cases:
* …
* one type is pointer to void and the other is a pointer to a character
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
Consider the function f below:
int f(void) {
volatile char *p = (volatile char[1]){1};
for (int i=1; i<10; i++) *p=4;
return *p;
}
Volatile access is a visible side-effect,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82340
--- Comment #2 from Pascal Cuoq ---
Richard:
> I don't see how a volatile compound literal could make any sense or how
> you'd observe the side-effect of multiple stores to it
Well, I have the same question about volatile variables the
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
This report is about GCC's handling of low-level pointer tricks such as the XOR
linked list [1]. Uses of this sort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86026
--- Comment #2 from Pascal Cuoq ---
Created attachment 44223
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44223=edit
Complete source code for functions in the description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84764
--- Comment #1 from Pascal Cuoq ---
I meant "the warning implies that the constant is typed as unsigned long
long...".
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
According to the output of the following program, the type of the constant
1000 is __int128, which is a s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89888
--- Comment #1 from Pascal Cuoq ---
errata: “outside the range of an unsigned char”
: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
Consider the C function:
long long X;
void f(unsigned char x
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
This report is similar to but different from my previous report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82340
Consider the C code
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
I think that this report is related to the implementation of a resolution from
DR 423 in 2017: https://gcc.gnu.org/bugzilla/show_bug.cgi?id
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
Consider the two compilation units below, that differ only in the name of the
automatic variable inside
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90472
--- Comment #2 from Pascal Cuoq ---
Thanks for this link.
So the bug report is that the file below is rejected by GCC 9.1 (and every GCC
version present on Compiler Explorer down to 4.1.2), whereas according to the
arguments in
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
Consider the following program:
#include
#include
#define MY_HUGE_VALF 0x1.0p255f
float f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93031
--- Comment #3 from Pascal Cuoq ---
@amonakov
The two blog posts below exist themselves, and describe tools that exist,
because software that makes misaligned access exists, although it seems to
be a “examples too numerous to list” situation
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
GCC assumes that pointers must be aligned as part of its optimizations, even if
the ISA does not force
mal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
Consider the three functions check, test0 and test1:
(Compiler Explorer link: https://gcc.godbolt.org/z/Sh4GpR )
#include
#def
normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
Consider the functions:
(Compiler Explorer link: https://gcc.godbolt.org/z/Uzd6nd )
#define POWER_OF_TWO (1UL
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
C17 6.5:6 says:
The effective type of an object for an access to its stored value is the
declared type of the object, if any.88) If a value is stored into an object
having
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94658
--- Comment #1 from Pascal Cuoq ---
Clang bug for the same optimization in Clang 10 filed at
https://bugs.llvm.org/show_bug.cgi?id=45607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #25 from Pascal Cuoq ---
Would it be reasonable to have three settings for -fstrict-aliasing, rather
then the current two?
- off
- strict
- assume-no-reuse
(I would let you find a better name for the third one.)
It seems to me
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
The closest existing ticket I found for this one is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48316
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
This bug seems most similar to (but still different from)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59711 (in which a comment says
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788
Pascal Cuoq changed:
What|Removed |Added
CC||pascal_cuoq at hotmail dot com
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
In the GCC versions available as 11.2 and as “trunk” (as of this writing) on
Compiler Explorer, the following C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104607
--- Comment #2 from Pascal Cuoq ---
Well that's a quick resolution to a bug report that contained that actual
phrase “and any padding is initialized to zero bits”, and this in a quote from
the C11 standard, but I guess one of us can't read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #13 from Pascal Cuoq ---
@Martin
I completely agree with comment 12, however about the last paragraph, I would
like to point out that for purposes of memcpy'ing to or from such a struct with
initialized FAM, it is enough to
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
Static-lifetime variables of type “struct with FAM” (flexible array member)
with an initializer for the FAM are a GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #3 from Pascal Cuoq ---
@Andrew Pinski
You don't even need to invoke the fact that this is an extension. GCC could
reserve 17 bytes for each variable i of type “int”, and as long as “sizeof i”
continued to evaluate to 4 (4 being
31 matches
Mail list logo
