Note, this mailing list is for development of gcc, gcc-help
would be more appropriate.
On Fri, Mar 11, 2022 at 07:53:32PM +, Larry Jackson via Gcc wrote:
> I goofed and failed to put a space after the "case" word:
>
> switch(nu){
> case1: v1 =val;break;
> case2: v2 =val;break;
> case3: v3 =va
Hi Nick,
On Wed, Mar 18, 2020 at 08:56:11PM -0400, Nicholas Krause wrote:
> I've not sure if I've misunderstanding something in the combine code but
> in make_more_copies
> for combine.c this seems very odd:
> if (!(REG_P (dest) && !HARD_REGISTER_P (dest)))
> continue;
>
> rtx src = SET_
That makes me wonder if there is a latent bug though. Consider pushing
args to a pure function. Could we then try to CSE the memory reference
and get it wrong because we haven't accounted for the autoinc?
>>>
>>> Can't know for sure but one would hope something would test for
>>> s
On 05/15/2018 12:58 PM, A. Skrobov wrote:
>>> That makes me wonder if there is a latent bug though. Consider pushing
>>> args to a pure function. Could we then try to CSE the memory reference
>>> and get it wrong because we haven't accounted for the autoinc?
>>
>> Can't know for sure but one woul
>> That makes me wonder if there is a latent bug though. Consider pushing
>> args to a pure function. Could we then try to CSE the memory reference
>> and get it wrong because we haven't accounted for the autoinc?
>
> Can't know for sure but one would hope something would test for
> side_effects_
On 05/14/2018 10:55 PM, Jeff Law wrote:
> That does sound vaguely familiar. Did we put autoinc notes on the stack
> pushes?
Not as far as I recall. I only see REG_ARGS_SIZE notes in the dumps.
> That makes me wonder if there is a latent bug though. Consider pushing
> args to a pure function. C
On 05/12/2018 01:35 PM, Bernd Schmidt wrote:
> On 05/12/2018 07:01 PM, Jeff Law wrote:
>
>> No. We're not supposed to have any auto-inc insns prior to the auto-inc
>> pass. A stack push/pop early in the compiler would have to be
>> represented by a PARALLEL.
>>
>> It's been this way forever. It
On 05/12/2018 07:01 PM, Jeff Law wrote:
> No. We're not supposed to have any auto-inc insns prior to the auto-inc
> pass. A stack push/pop early in the compiler would have to be
> represented by a PARALLEL.
>
> It's been this way forever. It's documented in the internals manual
> somewhere.
S
Jeff Law writes:
> On 05/12/2018 10:02 AM, Richard Sandiford wrote:
>> "A. Skrobov" writes:
If we look in sel-sched-ir.c we see that it calls into hash_rtx_cb
(sigh, bad modularity). I'm not at all familiar with how the hashing
is used within the selective scheduler, so I can't r
On 05/12/2018 10:02 AM, Richard Sandiford wrote:
> "A. Skrobov" writes:
>>> If we look in sel-sched-ir.c we see that it calls into hash_rtx_cb
>>> (sigh, bad modularity). I'm not at all familiar with how the hashing
>>> is used within the selective scheduler, so I can't really say what the
>>> s
>>> If we look in sel-sched-ir.c we see that it calls into hash_rtx_cb
>>> (sigh, bad modularity). I'm not at all familiar with how the hashing
>>> is used within the selective scheduler, so I can't really say what the
>>> selective scheduler *should* be doing here.
>>
>> OK, I see. Now what do y
"A. Skrobov" writes:
>> If we look in sel-sched-ir.c we see that it calls into hash_rtx_cb
>> (sigh, bad modularity). I'm not at all familiar with how the hashing
>> is used within the selective scheduler, so I can't really say what the
>> selective scheduler *should* be doing here.
>
> OK, I se
> If we look in sel-sched-ir.c we see that it calls into hash_rtx_cb
> (sigh, bad modularity). I'm not at all familiar with how the hashing
> is used within the selective scheduler, so I can't really say what the
> selective scheduler *should* be doing here.
OK, I see. Now what do you think woul
On 05/10/2018 11:45 PM, A. Skrobov wrote:
> On Fri, May 11, 2018 at 12:09 AM, Jeff Law wrote:
>>
>> My recollection is that auto-increment addressing modes should not
>> appear in the RTL in the CSE pass.
>
> Fair enough; but they're explicitly listed in the big switch block in
> hash_rtx_cb ().
On Fri, May 11, 2018 at 12:09 AM, Jeff Law wrote:
>
> My recollection is that auto-increment addressing modes should not
> appear in the RTL in the CSE pass.
Fair enough; but they're explicitly listed in the big switch block in
hash_rtx_cb ().
Should my added line change from "invalidate_dest (XE
On 05/10/2018 01:44 PM, A. Skrobov wrote:
> Hello,
>
> While working on a port of GCC for a non-public architecture that has
> pre/post-modify memory access instructions, I discovered what looks
> like a bug which can cause incorrect code generation.
>
> My suggested fix is trivial:
> https://git
Hi,
"A. Skrobov" writes:
> Hello,
>
> While working on a port of GCC for a non-public architecture that has
> pre/post-modify memory access instructions, I discovered what looks
> like a bug which can cause incorrect code generation.
>
> My suggested fix is trivial:
> https://github.com/tyomitch/
Sir,
On Thu, Sep 28, 2017 at 4:03 PM, Manuel López-Ibáñez
wrote:
> On 27/09/17 21:56, nick wrote:
>>
>> Greetings All,
>>
>> I commented here a few names ago,
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82230. Not
>> to be a annoyance but I have a school assignment and would like someone to
>
On 27/09/17 21:56, nick wrote:
Greetings All,
I commented here a few names ago,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82230. Not
to be a annoyance but I have a school assignment and would like someone to
reply if it's
correct or something. I am assuming it's probably wrong but any comme
On 12/05/16 12:37, Richard Biener wrote:
On Thu, May 12, 2016 at 12:17 PM, Richard Biener
wrote:
On Thu, May 12, 2016 at 12:10 PM, Claudiu Zissulescu
wrote:
Hi,
I've been trying the following simple test case on latest gcc, and it seems to
produce unwanted unaligned accesses for bit-fields.
On Thu, May 12, 2016 at 12:17 PM, Richard Biener
wrote:
> On Thu, May 12, 2016 at 12:10 PM, Claudiu Zissulescu
> wrote:
>> Hi,
>>
>> I've been trying the following simple test case on latest gcc, and it seems
>> to produce unwanted unaligned accesses for bit-fields.
>>
>> Test cases:
>>
>> struc
On Thu, May 12, 2016 at 12:10 PM, Claudiu Zissulescu
wrote:
> Hi,
>
> I've been trying the following simple test case on latest gcc, and it seems
> to produce unwanted unaligned accesses for bit-fields.
>
> Test cases:
>
> struct lock_chain {
> unsigned int irq_context: 2,
> depth: 6,
>
Hi Andrew.
Thank you, I will. Of course; I'm just a bit absent at the moment. ;)
In fact, I'm sure this must be a linker problem.
Love
Jens
On Tue, 07 May 2013 09:47:34 +0100, Andrew Haley wrote:
> On 05/07/2013 08:18 AM, Jens Bauer wrote:
>> Please let me know if I need to provide more informa
On 05/07/2013 08:18 AM, Jens Bauer wrote:
> Please let me know if I need to provide more information.
I'm afraid you have sent this to the wrong place. The assembler doesn't
use gcc, and this is the gcc list. Please send it to the binutils list.
Andrew.
>>> As some digging shows, already GCC 1.35 had effectively the same code.
>>> As soon as parameters are passed in registers GCC loads the parts fitting
>>> into registers as full words. We could simply sorry() for these cases, as
>>> they never worked correctly. Though I suppose that's quite unf
On Mon, Mar 28, 2011 at 3:36 PM, Paolo Bonzini wrote:
> On 03/28/2011 02:27 PM, Michael Matz wrote:
>>> type>>> size
unit size
align 8 symtab 0 alias set -1 canonical type 0x75b29540
which looks ok to me.
>>>
>>> It already isn't,
On 03/28/2011 02:27 PM, Michael Matz wrote:
unit size
align 8 symtab 0 alias set -1 canonical type 0x75b29540
which looks ok to me.
It already isn't, why is the alignment 8 if __alignof__
(GENOME_LOC_TYPE_2) is 1?
The aligns are printed in bits. It really is okay
Hi,
On Mon, 28 Mar 2011, Paolo Bonzini wrote:
> > At expansion time we have the following for the call argument:
> >
> >> type > size
> > unit size
> > align 8 symtab 0 alias set -1 canonical type 0x75b29540
> >
> > which looks ok to me.
>
> It already isn
On Mon, Mar 28, 2011 at 1:36 PM, Paolo Bonzini wrote:
> On 03/28/2011 01:06 PM, Richard Guenther wrote:
>>>
>>> /* GCC uses 8-byte loads and register passing even though sizeof = 6 */
>>> typedef struct __attribute__((__packed__))
>>> {
>>> unsigned chr :16;
>>> unsigned loc
On 03/28/2011 01:06 PM, Richard Guenther wrote:
/* GCC uses 8-byte loads and register passing even though sizeof = 6 */
typedef struct __attribute__((__packed__))
{
unsigned chr:16;
unsigned loc:32;
} GENOME_LOC_TYPE_2;
//#define GENOME_LOC_TYPE GENOME_LOC_TYPE_1
#d
On Mon, Mar 28, 2011 at 12:42 PM, Paolo Bonzini wrote:
> On 03/27/2011 06:27 AM, Ian Lance Taylor wrote:
>>
>> Nathan Boley writes:
>>
>>> In a much larger application, I was getting a weird segfault that an
>>> assignment to a temporary variable fixed. I distilled the example into
>>> the attach
On 03/27/2011 06:27 AM, Ian Lance Taylor wrote:
Nathan Boley writes:
In a much larger application, I was getting a weird segfault that an
assignment to a temporary variable fixed. I distilled the example into
the attached "test_case.c". When I run test_case.c under valgrind I
get a memory read
Nathan Boley writes:
> In a much larger application, I was getting a weird segfault that an
> assignment to a temporary variable fixed. I distilled the example into
> the attached "test_case.c". When I run test_case.c under valgrind I
> get a memory read error, and it segfaults with electric fenc
On Sat, Jul 3, 2010 at 6:42 PM, Mike Stump wrote:
> On Jul 1, 2010, at 11:29 PM, Eric Siroker wrote:
>> I'm getting the frontend for the Go programming language to work in
>> Darwin. I encountered what looks like a bug in Darwin-specific gcc
>> code.
>
> You are obligated to spell the name of the
On Jul 1, 2010, at 11:29 PM, Eric Siroker wrote:
> I'm getting the frontend for the Go programming language to work in
> Darwin. I encountered what looks like a bug in Darwin-specific gcc
> code.
You are obligated to spell the name of the section correctly...
$ cat t.s
.section __TEXT,__
On Jul 1, 2010, at 11:29 PM, Eric Siroker wrote:
Hello Darwin port maintainers,
I'm getting the frontend for the Go programming language to work in
Darwin. I encountered what looks like a bug in Darwin-specific gcc
code.
The Go frontend saves language-specific export information in the
obj
2010/1/19 Simon Hill:
> Axel Quote:
> "Anyways there is an already filed GCC bug about this defect report
> against the standard,
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29131 ."
>
> That bug report is suspended. Is this due to the C++ standards issue
> you referred to?:
> http://www.open-std
Axel Quote:
"Anyways there is an already filed GCC bug about this defect report
against the standard,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29131 ."
That bug report is suspended. Is this due to the C++ standards issue
you referred to?:
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.h
On Mon, Jan 18, 2010 at 4:20 PM, Simon Hill wrote:
> I'm pretty sure this is a bug but I'd like a confirmation (or
> refutation) before I submit a bug report.
>
First the issue here is what namespace does the foundental types in
C++ have? The standard says none which makes this code invalid but
Re Axel:
Quote (Axel):
"Well, I think g++ behaves correctly. As I understand the standard,
the normal function foo(int) can't be used in the template "bar",
because it is only declared afterwards."
Me:
I don't think this can be correct. Removing the template foo() but
leaving the normal one also
Hi
On Mon, Jan 18, 2010 at 10:37:34PM +1300, Simon Hill wrote:
> http://www.gamedev.net/community/forums/topic.asp?topic_id=559287
>
> SOURCE
>
> template
> void foo(pTYPE arg)
> { arg.nid(); }
>
> template
> void bar()
> {
> pTYPE var;
> foo(var);
>
On Fri, Jul 10, 2009 at 1:48 PM, Maciej Cencora wrote:
> Hi,
>
> I think I've found a bug in g++. Let's say we have following files:
>
> // a.hpp
>
> template
> void func1()
> {
> // general code
> }
>
> // a.cpp
>
> #include "a.hpp"
>
> template<>
> void func1()
> {
> // specialized
Jim Wilson wrote:
> JoseD wrote:
> > @James
> > What do you mean by 16.3.3/3? GCC's version ?
>
> This is a reference to the ISO C standard.
No. It's a reference to the ISO C++ standard. 16.3.3/3
includes the sentence "If the result [of the ## operator] is
not a valid preprocessing token, the
JoseD wrote:
@James
What do you mean by 16.3.3/3? GCC's version ?
This is a reference to the ISO C standard.
Still don't see what the problem whith 2 tokens is...
The problem is the fact that they are 2 tokens. You can do a ## b to
create ab, but you can not do a ## ( to create a( becaus
@NullHeart
Yes, but this is just a small code snippet reproducing the problem, I don't
think that will work when pasting with a macro's argument is required..
@James
What do you mean by 16.3.3/3? GCC's version ?
Still don't see what the problem whith 2 tokens is...
Shame that there doesn't s
JoseD wrote:
> Hi. Just wanted to share that the following macro gives an error on latest
> versions of GCC, but is reported to work on 2.95.3 (tested on MorphOS but
> should be the same for other OSses of course).
> Both an old version of SASC(AmigaOS) and Borland (on X86) worked fine.
>
> #inclu
You could just remove the '##'.
Soma
On 3/30/07, JoseD <[EMAIL PROTECTED]> wrote:
Hi. Just wanted to share that the following macro gives an error on latest
versions of GCC, but is reported to work on 2.95.3 (tested on MorphOS but
should be the same for other OSses of course).
Both an old vers
On Thu, 2006-10-26 at 17:37 -0300, [EMAIL PROTECTED] wrote:
> Hi, I've come with a problem with g++ 4.1.1 and people at gcc-help said
> they think it's a bug, so I'll forward my original email to this list.
And this is the same issue as PR 11407, http://gcc.gnu.org/PR11407 .
-- Pinski
Hello,
> There don't seem to be many comments explaining why we're doing
> what we're doing here, so I'm not sure whether this was the intended
> behaviour or not. Do we really want to kick out existing DECL_RTLs,
> or is there simply a missing !DECL_RTL_SET_P in the DECL_P condition:
I think th
On 09/08/05 16:25, Laurent GUERBY wrote:
FYI, this fixes both PR ada/23141 and ada/23142.
Well, but I cannot get a clean bootstrap with it. It fails building
libstdc++ on x86_64 and libgfortran on x86. I'll have to poke more.
FYI, this fixes both PR ada/23141 and ada/23142.
Laurent
On Thu, 2005-09-08 at 10:27 -0400, Diego Novillo wrote:
> On 09/05/05 17:39, Richard Kenner wrote:
>
> >Shouldn't the test be that both lhs_vr *and* vr_result are VR_RANGE?
> >
> >
> Yes, good catch. If that fixes your testcase, please
On 09/07/05 16:18, Jeffrey A Law wrote:
Are you getting something different?
We'd probably trigger a problem if
lhs_vr = [0, max]
vr_result = ~[max, max]
in that case, the code at the end of vrp_visit_phi_node would
erroneously set VR_RESULT to ~[-INF, max], which I can see causing
On 09/08/05 10:49, Richard Kenner wrote:
I saw email from Jeff yesterday asking
for more details, though. I was travelling yesterday, but will try to
get back to that message tomorrow.
Hmm, I missed that. Will check the archives.
Yes, good catch. If that fixes your testcase, please apply the fix.
You are referring to this, right?
Will do. Yes, precisely that. I saw email from Jeff yesterday asking
for more details, though. I was travelling yesterday, but will try to
get back to that message tomorrow.
On 09/05/05 17:39, Richard Kenner wrote:
Shouldn't the test be that both lhs_vr *and* vr_result are VR_RANGE?
Yes, good catch. If that fixes your testcase, please apply the fix.
You are referring to this, right?
--- tree-vrp.c 7 Sep 2005 20:35:19 - 2.54
+++ tree-vrp.c 8 Sep 2
On Mon, 2005-09-05 at 17:39 -0400, Richard Kenner wrote:
> Suppose lhs_vr is [64,64] and vr_result is ~[0,0]. It would seem
> that the code near the end of this function will malfunction.
>
> Shouldn't the test be that both lhs_vr *and* vr_result are VR_RANGE?
>
> This is causing an ACATS failur
56 matches
Mail list logo
