: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
I was a bit surprised to learn that a semi-obvious bug like
memcmp(counter2, counter2, 16)
is not flagged by -Wtautological-compare. The optimizer certainly knows that
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64965
Rasmus Villemoes changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
This causes an ICE:
#include
extern "C" void __cxa_allocate_exception(std::size_t size);
int f(int x)
{
if (x > 27)
throw 19;
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
Consider these examples:
#include
#include
const char *foo (const char *fmt, ...)
__attribute__((format(printf, 1, 2)));
int f1(const char *s, int x)
{
const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86338
--- Comment #2 from Rasmus Villemoes ---
I believe and hope Rainer's fix r262195 also takes care of these.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86068
--- Comment #2 from Rasmus Villemoes ---
The page https://gcc.gnu.org/projects/cxx-status.html probably needs to be
updated to say __cpp_transactional_memory >= 201500.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
The comment above the definition of __cpp_transactional_memory suggests that
201500 was meant to be used. Currently, gcc advertises support for whatever
transactional_memory
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
I need to enable -mlongcall for a PPC/VxWorks target. However, starting from
gcc 6, that leads to lots of warnings due to the "lon
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
Everything below applies to the case of unsigned operands; signed division is a
whole other matter.
When a is an odd constant, the expression x % a == 0 is equivalent to x
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
CC: rostedt at goodmis dot org
Target Milestone: ---
The motivation for this comes from the linux kernel's
include/trace/trace_events.h file (hence the cc Steven Rostedt
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
Using "a + b < a" is the standard (and well-defined) way of checking for
overflow when adding unsigned variables
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
int f(unsigned a, unsigned b)
{
if (!a || b >= a)
return 5;
return 2;
}
compiles to
f(unsigned int, unsigned
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
Playing around with the __builtin_*_overflow checkers, I noticed that when the
third argument is pointer to _Bool one gets "error: argument 3 in call to
fun
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
Target: x86/generic
In code such as
unsigned f(unsigned x, int n)
{
return x >> (n % 32);
}
I think gcc sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64965
Rasmus Villemoes changed:
What|Removed |Added
Severity|normal |minor
--- Comment #2 from Rasmus Vill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64965
--- Comment #1 from Rasmus Villemoes ---
Created attachment 34693
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34693&action=edit
Make __FILE__ work for filenames containing newline
y: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
While trying to come up with test cases for a bug in the static analyzer
sparse, I tried to see how gcc did in some corner cases. Turns out that using
__FILE__ in a file whose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64753
--- Comment #1 from Rasmus Villemoes ---
FWIW, I wrote a stupid script looking for the pattern
<(conditional) jump to abcd>
...
abcd:
Compiling a defconfig linux kernel with gcc 4.7 gives 201 instances, 5.0 gives
252. The second test/cm
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Host: x86_64
Target: x86_64
The linux kernel's library strncmp is this:
int strncmp(const char *cs, const char *ct, size_t count)
{
unsigned char c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64567
--- Comment #2 from Rasmus Villemoes ---
(In reply to Andreas Schwab from comment #1)
> This transformation is incorrect if the lvalue may be pointing to a
> read-only object.
True. And one may also incur an extra cache penalty if the cache line
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
(Not sure the "Component" is correct). gcc fails to optimize
if (foo & FLAG)
foo &= ~FLAG;
into simply uncondi
21 matches
Mail list logo
