https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85633
--- Comment #4 from Julian Taylor ---
Oh that is unfortunate.
I guess one has to inject the dependency in the fpu checking function as an
argument then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85633
--- Comment #2 from Julian Taylor ---
changing the fpu state does not count as a side effect?
This doesn't seem plausible, this type of code is one the reasons the fpu
exception state exists.
There is a lot of code written with this in mind which
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
Target Milestone: ---
gcc-8 seems to ignore the global fpu exception state when reordering functions.
In this example it reorders the
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
Target Milestone: ---
__builtin_cpu_supports("avx") checks that the cpu supports avx instructions,
but without OS support the instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80198
--- Comment #5 from Julian Taylor ---
I have been searching for a workaround as this has pretty bad performance
impact in my usecase. I found that putting this into the inplace conditional
#pragma GCC ivdep
allows it to be vectorized again with g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65917
Julian Taylor changed:
What|Removed |Added
CC||jtaylor.debian at googlemail
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80198
Julian Taylor changed:
What|Removed |Added
Summary|regression, does not|regression [6/7], does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80198
Julian Taylor changed:
What|Removed |Added
Summary|does not vectorize generic |regression, does not
|
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
Target Milestone: ---
In the following code the generic function does not vectorize when provided
with arguments that do an inplace operation. GCC does emit vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79128
Julian Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
Target Milestone: ---
GCC provides the __FAST_MATH__ when building with -ffast-math.
This allows c libraries to use other types of math functions that still comply
with this setting, e.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79117
--- Comment #3 from Julian Taylor ---
using isinf is not correct as isinf(nan) == 0
why does isinf do the truncation on x87 and isfinite does not?
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
Target Milestone: ---
following program (arguably) incorrectly outputs "not finite when compiled:
gcc test.c -O2 -m32
on gcc 6.3.0
#include
#include
void __attribute__((noi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66553
--- Comment #3 from Julian Taylor ---
Would adding a libgomp threadsanitizer configure switch be an option?
It could enable --disable-linux-futex which you need for omp critical sections,
set the right compile and link flags and add some extra lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69489
--- Comment #14 from Julian Taylor ---
I am on x86_64. It actually does vectorize with -mavx but not with -msse2.
The other variant of the loop I posted does vectorize with sse2.
$ gcc --version
gcc (GCC) 7.0.0 20160421 (experimental)
Copyright
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69489
--- Comment #12 from Julian Taylor ---
the testcase in this ticket is not yet vectorized with gcc 20160421 (r235341)
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
Target Milestone: ---
following (abbreviated) code does not vectorize with gcc 5.2.1:
gcc file.c -O2 -ftree-vectorize -c
double
yule_bool_distance_char2(const char *u, const char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
Julian Taylor changed:
What|Removed |Added
CC||jtaylor.debian at googlemail
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68761
--- Comment #1 from Julian Taylor ---
5.2.0 seems to also be affected.
Also tested 4.9.2 which works. Probably an regression of 5.x then.
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
Target Milestone: ---
following code causes an ICE in gcc 5.3.0 when compiled with
-floop-interchange. Not sure if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68145
--- Comment #5 from Julian Taylor ---
thanks, the full application now compiles successfully
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
Target Milestone: ---
Created attachment 36612
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36612&action=edit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66553
--- Comment #2 from Julian Taylor ---
if it is a false positive, is there a way to silence it too make the thread
sanitize more useful with openmp task using programs?
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
when libgomp has been built with -fsanitize=thread works very well on programs
that
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
following function calling cabsf exhibits poor performance when compiled with
gcc:
#include
using namespace std;
void __attribute__((noinline)) v
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
It would be nice if for some simple cases too large vector_size for the
selected instruction set would still produce efficient code.
E.g. using vector_size of 32 for SSE2 code
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
following code does not print overflow while the result does clearly overflow:
$ cat test.c
#include
int __attribute__((noinline)) wrapper(long a, long b, long * r)
{
return
: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
Created attachment 33856
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33856&action=edit
creduced testcase files
attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63342
--- Comment #6 from Julian Taylor ---
thanks, head (and branches) work fine now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655
Julian Taylor changed:
What|Removed |Added
CC||jtaylor.debian at googlemail
dot c
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
Created attachment 33538
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33538&action=edit
preprocessed source
with gcc 5 current svn rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
--- Comment #9 from Julian Taylor ---
thanks, please also clarify/remove the sentence about the sign as the result
sign is not the sign of the input as indicated by the docs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
--- Comment #7 from Julian Taylor ---
But the docs indicate that there is no undefined behavior.
As I interpret them the result of int() is always well defined.
If the documentation would not state what happens in the case of overflow it
would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
--- Comment #5 from Julian Taylor ---
oh I overlooked you put in positive input, thats strange
then the documentation should be updated that its undefined behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
--- Comment #4 from Julian Taylor ---
no x86 behaves as documented, the documentation states the sign is retained.
You can debate on what largest integer means here, it could be -1 as >
-2147483648 but as positive inputs give -2147483647 I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
--- Comment #2 from Julian Taylor ---
mips is the only architecture with this behavior, all others behave as
documented.
Shouldn't that be reason enough to change mips?
if not please document the exception on mips.
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
gfortran miscompiles int() for negative overflows leading to a build
timeout of python-scipy, see #756905
below a testcase, according to
https://gcc.gnu.org/onlinedocs/gfortran/INT.html the result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62105
--- Comment #2 from Julian Taylor ---
-whole-archive applies to static libraries, gcc links a shared library by
default
using -static-libtsan does not add libtsan at all:
$ gcc-4.10 test.c -static-libtsan -fsanitize=thread -v -fPIC -shared 2>&1
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
when linking a file with -fsanitize=* the sanatizer library (e.g. -ltsan is
placed before the object on the command line:
gcc-4.10 test.c
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
__builtin_ffs is well defined for 0 according to the gcc documentation:
Returns one plus the index of the least significant 1-bit of x, or if x
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
in this example file compiled with gcc-4.10 -O3 inlines the memcpy, but not the
memmove:
#include
void a(int *a, int *b)
{
memcpy(a, b, sizeof(*a));
}
void b(int *a, int *b)
{
memmove(a, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61473
--- Comment #1 from Julian Taylor ---
I am using glibc 2.19-0ubuntu6 from the ubuntu 14.04 trusty repository
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
following file with a syntax error (wrong braces at end of line) results in an
ICE with gcc-4.9.0 and recent SVN head (14. may 2014):
double f(double * A, double * B)
{
return __sec_reduce_add((B[0:500
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
this code comparing shorts into chars:
void __attribute__((optimize("O3"))) f(char * a_, short * b_)
{
char *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59385
--- Comment #8 from Julian Taylor ---
>
> > also gcc 4.9 still documents -ffp-contract=fast as being the default
> while
> > it is apparently not anymore.
>
> it's the default unless you override it with -std=c99 (always use
> -std=gnu99).
>
it w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58928
Julian Taylor changed:
What|Removed |Added
CC||jtaylor.debian at googlemail
dot c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54344
Julian Taylor changed:
What|Removed |Added
CC||jtaylor.debian at googlemail
dot c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59385
--- Comment #6 from Julian Taylor ---
shouldn't -ffast-math enable -ffp-contract=fast?
also gcc 4.9 still documents -ffp-contract=fast as being the default while it
is apparently not anymore.
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
compiling this code leads to a compilation error on -O3:
#include "math.h"
void fun() __attribute__((target("
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
attached code does not emit fma instructions in gcc 4.9 while it did in gcc-4.8
(ffast-math is enabled):
$ gcc -v
COLLECT_GCC=/scratch/jtaylor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59385
--- Comment #1 from Julian Taylor ---
Created attachment 31381
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31381&action=edit
code reproducing the issue
51 matches
Mail list logo
