https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110018
--- Comment #2 from Hongtao.liu ---
> Currently, when modifier is NONE, vectorizable_conversion doesn't try any
> immediate type, it can be extended similar like WIDEN.
>
After gdb the testcase, the modifier is not NONE, it's widen from V8QI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110018
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110018
Bug ID: 110018
Summary: Missing vectorizable_conversion(unsigned char ->
double) for BB vectorizer
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016
--- Comment #9 from Andrew Pinski ---
So I think this is a bug in your code:
Inside substrate::threadPool_t::finish,
we have:
finished = true;
haveWork.notify_all();
If I change it to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016
--- Comment #8 from Andrew Pinski ---
Here is the backtrace in that case:
(gdb) bt
#0 0xf6acd22c in futex_wait_cancelable (private=,
expected=0, futex_word=0xf3103c64) at
../sysdeps/unix/sysv/linux/futex-internal.h:88
#1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109987
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016
--- Comment #7 from Andrew Pinski ---
I can reproduce the failure on aarch64-linux-gnu on the trunk with `-std=c++17
-pthread -O2 -fsanitize=thread -fno-inline` so your theory about inlining is
causing an issue is so incorrect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Did you try on some other target than x86 for gcc?
To answer my own question is that it fails on aarch64-linux-gnu also. So this
makes it more likely a library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016
--- Comment #4 from Andrew Pinski ---
Did you try on some other target than x86 for gcc?
--- Comment #5 from Andrew Pinski ---
Did you try on some other target than x86 for gcc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016
--- Comment #4 from Andrew Pinski ---
Did you try on some other target than x86 for gcc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016
--- Comment #3 from Andrew Pinski ---
When you say you compiled with clang, did you use libstdc++ or libc++?
Did you try adding gnu::always_inline attribute on the lambda to see if it
fails there too?
Again the inlining should not have an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016
--- Comment #2 from Amyspark ---
We've seen failures both in Windows (all ABI flavors) and macOS only when
compiled with GCC -- AppleClang, Clang, and MSVC (in its three flavors) all
work without issue. So I'm doubtful it's a logical issue,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94892
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> Two things we should simplify:
> _4 = _3 >> 31;
> _4 != -1
>
> Into:
> _3 >= 0 (if _3 is signed, otherwise false)
>
> (this will solve f0)
See bug 85234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85234
--- Comment #5 from Andrew Pinski ---
Here is the testcase for the constants besides 0:L
```
#define N 3
#define unsigned int
#define cmp ==
#define M 0xf000u
_Bool f(unsigned x, int t)
{
return (x << N) cmp (M << N);
}
_Bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110017
--- Comment #4 from cqwrteur ---
Created attachment 55182
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55182=edit
Here is the build script (need to install a x86_64-w64-mingw32 cross compiler
first)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110017
--- Comment #3 from cqwrteur ---
(In reply to Andrew Pinski from comment #2)
> How are you configuring GCC?
gcc/configure --disable-nls --disable-werror --enable-languages=c,c++
--enable-multilib --with-multilib-list=m64,m32,mx32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110017
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110017
--- Comment #1 from cqwrteur ---
(In reply to cqwrteur from comment #0)
> I attempted crossback compilation for GCC, where the compiler is built on
> Linux, runs on Windows, and is targeted for Linux again. However, the build
> system of libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110017
Bug ID: 110017
Summary: Crossback Compilation for multilib fails on latest
ubuntu due to -mx32 being disabled by the linux kernel
Product: gcc
Version: unknown
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109914
--- Comment #3 from Bruno Haible ---
(In reply to Jan Hubicka from comment #2)
> The reason why gcc warns is that it is unable to prove that the function is
> always finite. This means that it can not auto-detect pure attribute since
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85234
--- Comment #4 from Andrew Pinski ---
Here are some testcases dealing with this and showing what still needs to be
done:
```
#define N 3
#define unsigned int
#define cmp !=
_Bool rshift(unsigned x, int t)
{
return (x << N) cmp 0;
}
_Bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016
Andrew Pinski changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110007
--- Comment #8 from Richard Yao ---
(In reply to Alexander Monakov from comment #6)
> Are you sure the branch is unpredictable in your micro-benchmark? If you
> have repeated runs you'll train the predictors.
(In reply to Jan Hubicka from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016
Bug ID: 110016
Summary: [12/13/14] Possible miscodegen when inlining
std::condition_variable::wait predicate causes
deadlock
Product: gcc
Version: 12.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985
--- Comment #6 from Jan Hubicka ---
Created attachment 55180
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55180=edit
untested patch
It turns out that as modref was written for memory loads/stores only and later
side effects discovery
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109914
--- Comment #2 from Jan Hubicka ---
The reason why gcc warns is that it is unable to prove that the function is
always finite. This means that it can not auto-detect pure attribute since
optimizing the call out may turn infinite program to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79704
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015
--- Comment #1 from Jan Hubicka ---
opj_t1_enc_refpass is not inlined due to large function growth and some others
due to max-inline-insns-auto. With inlining forced I get profile:
87.35% opj_t1_cblk_encode_processor
6.22%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #9 from Georg-Johann Lay ---
The bug works as follows:
postreload.cc::reload_cse_move2add() loops over all insns, and at some point it
encounters
(insn 44 14 15 2 (set (reg/f:HI 14 r14 [58])
(reg/v/f:HI 16 r16 [orig:51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015
Bug ID: 110015
Summary: openjpeg is slower when built with gcc13 compared to
clang16
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88486
--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> Affects versions down to at least gfortran-5.
> Under the hood related to pr85686.
>
>
> $ cat z1.f90
> subroutine s(x)
>character(:), allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812
--- Comment #10 from Jan Hubicka ---
This is benchmarkeable version of the simplified testcase:
jan@localhost:/tmp> cat t.c
#define N 1000
struct rgb {unsigned char r,g,b;} rgbs[N];
int *addr;
struct drgb {double r,g,b;
#ifdef OPACITY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88486
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812
--- Comment #9 from Jan Hubicka ---
Oddly enough simplified version of the loop SLP vectorizes for me:
struct rgb {unsigned char r,g,b;} *rgbs;
int *addr;
double *weights;
struct drgb {double r,g,b;};
struct drgb sum()
{
struct drgb r;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110014
Bug ID: 110014
Summary: -Wanalyzer-allocation-size mishandles realloc (...,
* sizeof (object))
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
Bug 68241 depends on bug 65381, which changed state.
Bug 65381 Summary: [10/11/12/13/14 Regression] ICE during array result,
assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65381
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65381
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812
--- Comment #8 from Jan Hubicka ---
Created attachment 55178
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55178=edit
Preprocessed source of VerticalFiller and HorisontalFiller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812
Jan Hubicka changed:
What|Removed |Added
Summary|GraphicsMagick resize is a |GraphicsMagick resize is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331
Georg-Johann Lay changed:
What|Removed |Added
Status|ASSIGNED|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331
Georg-Johann Lay changed:
What|Removed |Added
Assignee|gjl at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110007
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139
--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to sandra from comment #4)
> The problem noted in comment 1 looks related to PR 102641 --
> automatically-inserted implicit initialization code can't cope with
> assumed-rank arrays.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110009
--- Comment #2 from Andrew Pinski ---
(In reply to Georg-Johann Lay from comment #1)
> (In reply to Andrew Pinski from comment #0)
> > unsigned
> > f1 (int v)
> > {
> > [...]
> > int b_5;
> >
> > b_5 = v>>(sizeof(v)*8 - 1);
>
> Does it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #8 from Nikolas Klauser ---
(In reply to Florian Weimer from comment #7)
> (In reply to Nikolas Klauser from comment #6)
> > Does that make sense?
>
> Not quite. I was trying to suggest that you also need to suppress all
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99435
Georg-Johann Lay changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #44 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #43)
>
> Well, not really. Look what's happening during expand pass when 'ashrsi3' is
> expanding. Function 'expand_ashiftrt' is called and what it does at the end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #43 from Alexander Klepikov
---
> > Thank you! I have an idea. If it's impossible to defer initial optimization,
> > maybe it's possible to emit some intermediate insn and catch it and optimize
> > later?
>
> This is basically what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110009
--- Comment #1 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #0)
> unsigned
> f1 (int v)
> {
> [...]
> int b_5;
>
> b_5 = v>>(sizeof(v)*8 - 1);
Does it depend on -fwrapv maybe.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
Georg-Johann Lay changed:
What|Removed |Added
Summary|[AVR] Miscompilation and|[postreload] Uses content
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #7 from Florian Weimer ---
(In reply to Nikolas Klauser from comment #6)
> Does that make sense?
Not quite. I was trying to suggest that you also need to suppress all
inter-procedural analysis. This will inhibit quite a few useful
53 matches
Mail list logo
