http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
--- Comment #12 from Aldy Hernandez 2013-03-01
19:17:32 UTC ---
> --- Comment #11 from Ian Lance Taylor 2013-03-01
> 14:52:53 UTC ---
> I suspect we can handle this case by observing that all the incoming values to
> the PHI node are con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
--- Comment #14 from Aldy Hernandez 2013-03-01
19:33:47 UTC ---
On 03/01/13 13:23, ian at airs dot com wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
>
> --- Comment #13 from Ian Lance Taylor 2013-03-01
> 19:23:00 UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52297
--- Comment #7 from Aldy Hernandez 2012-02-22
20:20:34 UTC ---
On 02/22/12 14:08, jakub at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52297
>
> --- Comment #6 from Jakub Jelinek 2012-02-22
> 20:08:46 UTC ---
> (In repl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558
--- Comment #6 from Aldy Hernandez 2012-03-12
15:42:45 UTC ---
On 03/12/12 10:32, rguenther at suse dot de wrote:
es, but still cared about introducing write
>> data races. This test case has both. I don't understand why we would allow
>> intro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558
--- Comment #10 from Aldy Hernandez 2012-03-12
15:56:30 UTC ---
On 03/12/12 10:45, rguenther at suse dot de wrote:
>> Just to get this straight, am I to assume that the default code
>> generation for GCC is a single threaded environment? I just
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59160
--- Comment #1 from Aldy Hernandez ---
> Is the line
>
> /* FIXME: This test has been xfailed until reductions are fixed. */
>
> still relevant? I don't see any xfail in the source.
>
The FIXME is not relevant anymore. Can you post a patch to g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59160
--- Comment #3 from Aldy Hernandez ---
On 11/18/13 09:02, dominiq at lps dot ens.fr wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59160
>
> --- Comment #2 from Dominique d'Humieres ---
>> The FIXME is not relevant anymore. Can you post a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59160
--- Comment #5 from Aldy Hernandez ---
On 11/18/13 09:45, dominiq at lps dot ens.fr wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59160
>
> --- Comment #4 from Dominique d'Humieres ---
>> You need to post it on gcc-patches because I am not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56572
--- Comment #6 from Aldy Hernandez ---
> walk the transaction tree and delete nested transactions. Hopefully
> we could do this before actually creating the uninstrumented path.
>
> I think moving the creation of the uninstrumented path after ipa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51174
--- Comment #9 from Aldy Hernandez 2011-11-17
19:04:43 UTC ---
> I do not understand what you are asking. You can reproduce the failures or
> you
> cannot? My rs6000.c patch fixes some of the failures. The varasm.c patch is
> necessary to fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51916
--- Comment #3 from Aldy Hernandez 2012-01-20
16:25:19 UTC ---
> No luck!-(I get 'No symbol "fcode" in current context.' and if not ' optimized out>').
> The only things I have been to print stepping through
> streamer_get_builtin_tree (ib=, data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51916
--- Comment #5 from Aldy Hernandez 2012-01-20
20:03:09 UTC ---
> I have never done that!-(I guess I have to pass something like CFLAGS and
> CXXFLAGS in configure or make). What is the official way to do it?
From the Debugging GCC wiki (http://
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #12 from Aldy Hernandez ---
The warning occurs in vrp1, not evrp, but for the record...
evrp dump:
tcp_chrono_set (struct tcp_sock * tp)
{
int type;
_1;
int _2;
unsigned char _3;
unsigned char _4;
:
_1 = tp_11(D)->ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84068
--- Comment #4 from Aldy Hernandez ---
> Yes it's latent and the fix is trivial. Testing to see whether it affects
> codequality.
Thanks Wilco, I appreciate it. Errr, we all do :).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393
--- Comment #13 from Aldy Hernandez ---
Do we care though? Does this bug pose a big enough problem on non
MIPS16 that we would like addressed? Just curious
On Sun, Feb 4, 2018 at 10:50 AM, law at redhat dot com
wrote:
> https://gcc.gnu.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87059
--- Comment #8 from Aldy Hernandez ---
On 08/23/2018 04:08 PM, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87059
>
> --- Comment #7 from Martin Sebor ---
> The MIN_EXPR code predates my change -- r255898 just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87059
--- Comment #16 from Aldy Hernandez ---
On 08/24/2018 11:41 AM, segher at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87059
>
> --- Comment #15 from Segher Boessenkool ---
> (In reply to Aldy Hernandez from comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
--- Comment #7 from Aldy Hernandez ---
Ok. Will do.
On Feb 20, 2018 15:12, "law at redhat dot com"
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
>
> Jeffrey A. Law changed:
>
>What|Removed |Ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87813
--- Comment #10 from Aldy Hernandez ---
On 11/5/18 11:06 AM, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87813
>
> --- Comment #9 from Martin Sebor ---
> (In reply to Aldy Hernandez from comment #6)
>
> I ag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734
--- Comment #10 from Aldy Hernandez 2012-12-18
16:48:40 UTC ---
Ah yes, now I remember. Yes, there is a problem with libgcov.a. I
wasn't seeing it because I was only building cc1. You are correct
Teresa, that is the reason for the gym
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54139
--- Comment #6 from Aldy Hernandez 2013-01-15
16:49:24 UTC ---
> The third is for failures like "FAIL: gcc.c-torture/execute/builtins/memset.c
> compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects" that fail to
> link due to m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #14 from Aldy Hernandez 2013-01-18
17:14:56 UTC ---
> You can use DYLD_PRINT_BINDINGS to find out which __cxa_allocate_exception
> call
> is being used, it'll also give you the addresses so you can make sure that the
> right o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939
--- Comment #9 from Aldy Hernandez 2013-01-22
00:23:03 UTC ---
An image with parameters/instructions would be ideal. Heck...not ideal...great!
Thanks so much.
"mikpe at it dot uu.se" wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #25 from Aldy Hernandez 2013-01-23
14:11:53 UTC ---
> looks like (yet another) permutation of what works/doesn't with "ELF-style
> weak
> linking" I don't have darwin11 or 12 (yet) - but should do soon.
>
FWIW, I reproduced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939
--- Comment #16 from Aldy Hernandez 2013-01-29
19:47:24 UTC ---
>> double d, d2;
>> ...
>> if (d != d2) {
>> dumpd(d,d2);
>> return -1;
>> }
>>
>> By this point, "d" and "d2" are in fp2/fp3, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691
--- Comment #18 from Aldy Hernandez ---
On 12/07/2016 11:38 AM, law at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691
>
> --- Comment #17 from Jeffrey A. Law ---
> It's just latent. We still need to fix it appropriat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at redhat dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47889
--- Comment #12 from Aldy Hernandez ---
On 01/09/14 15:43, d.g.gorbachev at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47889
>
> --- Comment #11 from Dmitry Gorbachev ---
> GCC 4.7 still crashes on the testcase from attach
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47889
--- Comment #14 from Aldy Hernandez ---
On 01/09/14 16:01, d.g.gorbachev at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47889
>
> --- Comment #13 from Dmitry Gorbachev ---
> It was 4.7.4 20131207 (prerelease).
>
Can you tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315
--- Comment #21 from Aldy Hernandez ---
On 02/24/2015 12:39 AM, rguenther at suse dot de wrote:
> But yes, we have multiple such assignments to 'this' at the (possible
> assembler) location of a single statement which of course doesn't help.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315
--- Comment #23 from Aldy Hernandez ---
On 02/24/2015 07:53 AM, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315
>
> --- Comment #22 from Jakub Jelinek ---
> (In reply to Aldy Hernandez from comment #21)
>> Le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65278
--- Comment #4 from Aldy Hernandez ---
On 03/02/2015 08:30 AM, doko at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65278
>
> --- Comment #2 from Matthias Klose ---
> yes, 32bit powerpc,
>
> /usr/lib/gcc/powerpc-linux-gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
--- Comment #5 from Aldy Hernandez ---
I don't have access to a Darwin box. Could you provide a preprocessed file so I
can try to reproduce the defined but not used problem on a cross build?
Also, what triplet?
Thanks.
On Jun 7, 2015 4:09 AM,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
--- Comment #10 from Aldy Hernandez ---
It's not supposed to. It's for issue three as stated.
On Jun 9, 2015 4:36 AM, "dominiq at lps dot ens.fr"
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
>
> --- Comment #9 from Dominique d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66597
--- Comment #4 from Aldy Hernandez ---
On 06/19/2015 11:50 AM, krebbel at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66597
>
> --- Comment #2 from Andreas Krebbel ---
> (In reply to Aldy Hernandez from comment #1)
>> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66468
--- Comment #9 from Aldy Hernandez ---
On 07/20/2015 03:14 PM, jason at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66468
>
> --- Comment #8 from Jason Merrill ---
> The problem seems to be that we inlined the function,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124
--- Comment #5 from Aldy Hernandez 2011-03-15
12:42:36 UTC ---
> struct S
> {
>signed a : 26;
>signed b : 16;
>signed c : 10;
>volatile signed d : 14;
>int e;
> } s;
> I think you can't just modify s.e when writing s.d (I thin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818
--- Comment #11 from Aldy Hernandez ---
Ah...it can be closed.
On Wed, Oct 14, 2020, 17:58 jamborm at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818
>
> --- Comment #10 from Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97609
--- Comment #8 from Aldy Hernandez ---
Yes.
On Thu, Oct 29, 2020, 09:47 marxin at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97609
>
> Martin Liška changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
--- Comment #10 from Aldy Hernandez ---
> > as well as here:
> >
> > if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
> > {
> > /* We cannot compare overflowed values. */
> > if (TREE_OVERFLOW (v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #20 from Aldy Hernandez ---
On Wed, May 19, 2021 at 8:31 AM rguenth at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
>
> --- Comment #17 from Richard Biener ---
> (In reply to Andrew Macleod from co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #26 from Aldy Hernandez ---
On Wed, May 26, 2021 at 10:34 AM rguenther at suse dot de
wrote:
> It's probably too strict for multiple_of_p which is fine with
> overflows that preserve modulo behavior.
Could you provide an example?
od at redhat dot com wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
>>
>> --- Comment #28 from Andrew Macleod ---
>> (In reply to rguent...@suse.de from comment #27)
>>> On Wed, 26 May 2021, aldyh at redhat dot com wrote:
>>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787
--- Comment #7 from Jakub Jelinek ---
Perhaps if EVRP is folding debug stmts it could first fold non-debug stmts (and
remember if there were any debug stmts) and only fold debug stmts afterwards,
either just by using caches and not adding anythi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106679
--- Comment #2 from Aldy Hernandez ---
Huh. I wonder why this didn't show up in my regression tests. Are these
tests not run by default?
Either way, I'll take a look.
On Thu, Aug 18, 2022, 23:29 pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #18 from Defunct account. Do not use. ---
> Yes. I guess it would be nice to have a CTOR or so for the case
> where the path is really a single edge like in this case.
Good idea. Will do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103188
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #16 from Aldy Hernandez ---
On Wed, Sep 29, 2021 at 10:46 PM dje at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
>
> --- Comment #15 from David Edelsohn ---
> I annotated execute_vrp_threader() to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #11 from Aldy Hernandez ---
This looks mighty suspicious ;-)
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 69a3ab0ea9d..c24c67f8874 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -4408,6 +4408,7 @@ hybrid_threader::~hybrid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #20 from Aldy Hernandez ---
Doesn't make a difference. If the blocks are stale, they need to be
reconstructed anyhow. It's preexisting behavior in VRP anyhow.
I heard you the first time ;-).
On Thu, Sep 30, 2021 at 7:49 AM aldot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #21 from Aldy Hernandez ---
However, if you care to test a patch, I'd be happy to review it.
On Thu, Sep 30, 2021 at 7:49 AM aldot at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
>
> Bernhard Reutn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102542
--- Comment #7 from Aldy Hernandez ---
On Fri, Oct 1, 2021 at 1:46 PM rguenth at gcc dot gnu.org
wrote:
> > Could I inconvenience you to tweak this function with your insight? It's a
> > tiny function, and it seems you're much more qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546
--- Comment #12 from Aldy Hernandez ---
Absolutely, but I didn't want to pollute the patch for this PR. Consider
the patch to do so pre-approved :-).
On Sat, Oct 2, 2021, 00:20 jakub at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> http
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605
--- Comment #5 from Aldy Hernandez ---
> > BTW, the __MEM_REF output from the dumps does not work in -fgimple either.
> > More errors.
>
> Can you share an example?
This is from gcc.c-torture/execute/961125-1.c compiled with -fgimple:
char * b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605
--- Comment #7 from Aldy Hernandez ---
On Wed, Oct 6, 2021 at 10:14 AM rguenther at suse dot de
wrote:
> Btw, please report cases where -gimple doesn't produce valid GIMPLE FE
> inputs (OK, there are known cases with mangled symbol names when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622
--- Comment #10 from Aldy Hernandez ---
Does :1-1 fail? In which case it's definitely the first thread.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102646
--- Comment #3 from Aldy Hernandez ---
Most if not all the performance changes I've seen so far have been,
not due to the jump threader changes, but to the restrictions we've
put into place for jump threadable paths. Before, we used to thread
p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703
--- Comment #8 from Aldy Hernandez ---
On Wed, Oct 13, 2021, 11:37 pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703
>
> --- Comment #7 from Andrew Pinski ---
> Because:
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102794
--- Comment #2 from Aldy Hernandez ---
I haven't looked at this, but there's a pending patch with more
restrictions for loop threading in the presence of loops. Does this help?
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581637.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857
--- Comment #12 from Aldy Hernandez ---
Thank you for your help on this (and the myriad of other PRs ;-)).
I'll submit upstream.
On Sat, Oct 23, 2021 at 11:06 AM pinskia at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101671
--- Comment #2 from Aldy Hernandez ---
Yeah, that would be great. Thanks!
On Thu, Jul 29, 2021 at 6:05 PM msebor at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101671
>
> Martin Sebor changed:
>
>What
62 matches
Mail list logo
