Hi,
The following program segfaults when compiled with gcc
but runs fine when compiled with g++ or icc (the intel C compiler)
#include
struct Hello {
char world[20];
};
struct Hello s(){
struct Hello r;
r.world[0]='H';
r.world[1]='\0';
return r;
}
int main(){
> Hi,
>
> The following program segfaults when compiled with gcc
> but runs fine when compiled with g++ or icc (the intel C compiler)
>
> #include
> struct Hello {
> char world[20];
> };
> struct Hello s(){
> struct Hello r;
> r.world[0]='H';
> r.world[1]='\0';
>
2008/12/16 Dennis Clarke :
>
>> Hi,
>>
>> The following program segfaults when compiled with gcc
>> but runs fine when compiled with g++ or icc (the intel C compiler)
>>
>> #include
>> struct Hello {
>> char world[20];
>> };
>> struct Hello s(){
>> struct Hello r;
>> r.worl
That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu 8.10
(Intel core2 duo)
I get
stest.c: In function ‘main’:
stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2
has type ‘char[20]’
The resulting binary does not segfault but prints garbage (probably
uniniti
Michel Van den Bergh wrote:
That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu
8.10 (Intel core2 duo)
I get
stest.c: In function ‘main’:
stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2
has type ‘char[20]’
The resulting binary does not segfault but prin
On Tuesday 2008-12-16 18:01, Sebastian Redl wrote:
> Michel Van den Bergh wrote:
>> That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu 8.10
>> (Intel core2 duo)
>> I get
>>
>> stest.c: In function ‘main’:
>> stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2 ha
The C standard says no such thing; only integer promotions are
performed. (See 6.5.2.2 of the C99 final draft.)
Ok one more question. Why does this not give a warning then (and runs fine)?
#include
struct Hello {
char world[20];
};
struct Hello s(){
struct Hello r;
r.wor
Sebastian Redl wrote:
> Michel Van den Bergh wrote:
>> That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu
>> 8.10 (Intel core2 duo)
>> I get
>>
>> stest.c: In function ‘main’:
>> stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2
>> has type ‘char[20]’
>>
>> The
Hi,
I have been debugging a runtime error caused by value range propagation. and
finally located to the following gcc routine:
vrp_meet_1 in gcc/tree-vrp.c
/* Meet operation for value ranges. Given two value ranges VR0 and
VR1, store in VR0 a range that contains both VR0 and VR1. This
nc.c
float func(int a, int b)
{
return (float)(a + b);
}
I assume it's a bug: func in main funcion is different from the
function in func.c
My gcc version is gcc 3.2.2.
May be not this version, i have forgotten.
Hello,
I ran into the following using gcc 4.2.3 on ubuntu 8.04. I ran it with
-Werror so it died on receiving this warning:
cc1: warnings being treated as errors
tux3fuse.c: In function 'tux3_lookup':
tux3fuse.c:78: warning: initialized field overwritten
tux3fuse.c:78: warning: (near initializati
;
> let me know your opinion.
>
> thanks a lot for the help.
I think we (Richi and I) went through this about a year ago and the
conclusion was we should be looking at how you're getting into the
vrp_meet with the VR_UNDEFINED.
If it happens because the user's code has an undefined use, then, the
consensus has been to go ahead and optimize it.
If it happens for any other reason, then it's likely a bug in GCC. We
had a couple of these when we made EVRP a re-usable module and started
exploiting its data in the jump threader.
So you need to work backwards from this point to figure out how you got
here.
jeff
(value_range *vr0, const value_range *vr1)
>> {
>> value_range saved;
>>
>> if (vr0->type == VR_UNDEFINED)
>>{
>> /* VR0 already has the resulting range. */
>> return;
>>}
>>
>> if (vr1->type == VR_UND
_98;
> _152 = MAX_EXPR <_98, 0>;
> i_49 = _152;
>
>and all the i_49 are replaced with _152.
>
>However, the value range info for _152 doesnot reflect the one for
>i_49, it keeps as UNDEFINED.
>
>is this the root problem?
It looks like DOM fails to visit
_52(D);
>> k_105 = _98;
>> _152 = MAX_EXPR <_98, 0>;
>> i_49 = _152;
>>
>> and all the i_49 are replaced with _152.
>>
>> However, the value range info for _152 doesnot reflect the one for
>> i_49, it keeps as UNDEFINED.
>>
>> is
= _152
> ASGN i_49 = _152
>
> then bb 4 becomes:
>
> [local count: 12992277]:
> _98 = (int) ufcMSR_52(D);
> k_105 = _98;
> _152 = MAX_EXPR <_98, 0>;
> i_49 = _152;
>
> and all the i_49 are replaced with _152.
>
> However, the value range info for _152
> Folded to: i_49 = _152;
>> LKUP STMT i_49 = _152
>> ASGN i_49 = _152
>>
>> then bb 4 becomes:
>>
>> [local count: 12992277]:
>> _98 = (int) ufcMSR_52(D);
>> k_105 = _98;
>> _152 = MAX_EXPR <_98, 0>;
>> i_49 = _152;
>
Hi, Richard,
> On Mar 4, 2019, at 5:45 AM, Richard Biener wrote:
>>
>> It looks like DOM fails to visit stmts generated by simplification. Can you
>> open a bug report with a testcase?
>>
>>
>> The problem is, It took me quite some time in order to c
On Mon, Mar 4, 2019 at 11:01 PM Qing Zhao wrote:
>
> Hi, Richard,
>
> > On Mar 4, 2019, at 5:45 AM, Richard Biener
> > wrote:
> >>
> >> It looks like DOM fails to visit stmts generated by simplification. Can
> >> you open a bug report with a tes
fails to visit stmts generated by simplification. Can
> > >> you open a bug report with a testcase?
> > >>
> > >>
> > >> The problem is, It took me quite some time in order to come up with a
> > >> small and independent testcase for this pr
:45 AM, Richard Biener
> > > > wrote:
> > > >>
> > > >> It looks like DOM fails to visit stmts generated by simplification.
> > > >> Can you open a bug report with a testcase?
> > > >>
> > > >>
> > > >
On 3/1/19 10:49 AM, Qing Zhao wrote:
> Jeff,
>
> thanks a lot for the reply.
>
> this is really helpful.
>
> I double checked the dumped intermediate file for pass “dom3", and
> located the following for _152:
>
> BEFORE the pass “dom3”, there is no _152, the corresponding Block
> looks lik
gt;> then bb 4 becomes:
>>
>> [local count: 12992277]:
>> _98 = (int) ufcMSR_52(D);
>> k_105 = _98;
>> _152 = MAX_EXPR <_98, 0>;
>> i_49 = _152;
>>
>> and all the i_49 are replaced with _152.
>>
>> However, the value range info fo
On 3/5/19 7:44 AM, Richard Biener wrote:
> So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
> the MAX_EXPR introduced by folding makes it somewhat ugly.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> Any ideas how to make it less so? I can split o
On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote:
>
> On 3/5/19 7:44 AM, Richard Biener wrote:
>
> > So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
> > the MAX_EXPR introduced by folding makes it somewhat ugly.
> >
> > Bootstrapped on x86_64-unknown-linux-gnu, testing in pr
On Wed, Mar 6, 2019 at 11:05 AM Richard Biener
wrote:
>
> On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote:
> >
> > On 3/5/19 7:44 AM, Richard Biener wrote:
> >
> > > So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
> > > the MAX_EXPR introduced by folding makes it somewhat
On 3/6/19 3:05 AM, Richard Biener wrote:
> On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote:
>>
>> On 3/5/19 7:44 AM, Richard Biener wrote:
>>
>>> So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
>>> the MAX_EXPR introduced by folding makes it somewhat ugly.
>>>
>>> Bootstrap
On Tue, Mar 19, 2019 at 8:53 PM Jeff Law wrote:
>
> On 3/6/19 3:05 AM, Richard Biener wrote:
> > On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote:
> >>
> >> On 3/5/19 7:44 AM, Richard Biener wrote:
> >>
> >>> So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
> >>> the MAX_EXP
> I have now applied this variant.
You backported it onto the 8 branch on Friday:
2019-05-03 Richard Biener
Backport from mainline
[...]
2019-03-07 Richard Biener
PR tree-optimization/89595
* tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Take
On Sun, May 5, 2019 at 11:09 PM Eric Botcazou wrote:
>
> > I have now applied this variant.
>
> You backported it onto the 8 branch on Friday:
>
> 2019-05-03 Richard Biener
>
> Backport from mainline
> [...]
> 2019-03-07 Richard Biener
>
> PR tree-optimization/89595
>
It's not a bug. It conforms the C standard. C, unlike C++,
distinguishes functions ONLY by name, not by arguments.
C allows calling functions that are not declared by assuming they
return int. So GCC would assume that the prototype of "func" to be
"int func()" when co
Dear Sirs,
I use the gcc 3.3.5 20050117 prerelease that came with SuSe 10 and have a
problem and a question.
The problem first:
When debugging programs like this:
quote
-
using namespace std;
#include
#include
class Nwh {
char Firstname [12];
int age;
public:
Nwh ( char *
Hi,
in include/linux/compiler-gcc.h :
/* Optimization barrier */
/* The "volatile" is due to gcc bugs */
#define barrier() __asm__ __volatile__("": : :"memory")
The comment of Linux says this is a gcc bug.But will any sane compiler
disable optimization without "volatile" key word?
--
Reg
Hello,
I am tracking a bug and find the lshift_value function in
expmed.c questionable (both head and gcc 4.4).
Suppose HOST_BITS_PER_WIDE_INT = 32, bitpos = 0
and bitsize = 33, the following expression is wrong
high = (v >> (HOST_BITS_PER_WIDE_INT - bitpos))
&d);
7 printf ("%f\n", d);
8 asm ("nop");
9 }
(gdb) b 8
Breakpoint 2 at 0x2a10: file t.cc, line 8.
(gdb) cont
Continuing.
3.141500
Breakpoint 2, main () at t.cc:8
8 asm ("nop");
(gdb) p d
$1 = 3.14150002
(gdb) quit
The progr
On Mar 5, 2006, at 11:15 AM, Mike Stump wrote:
The string is a bit trickier, strncpy (newbuf, buf+30, 40); newbuf
[70] = 0;
[40] = 0; I meant of course.
ot; prototype in the declaration of
struct b
or
-change the foo(void) function into a bar(void) function.
I am under the impression that it is a bug of gcc. Should I fill a
bug, or am I the one who is confused ?
Pierre Chatelier
Hello,
On C structures, for attributes like "const", it is enough to consider
that each field inherit the attribute of the structure.
But for the volatile attribute, is it valid to treat each field as
volatile like GCC does it now?
I mean:
volatile struct { unsigned char a,b,c,d; } volstruct;
voi
So, with the new bugzilla, how does one confirm a bug
is a bug? If I click on the button next to the
"status:" field, the selections listed are unconfirmed,
new, assigned, suspended, waiting, and resolved. Where's
the confirm selection?
--
Steve
On Tue, Mar 4, 2014 at 7:40 AM, lin zuojian wrote:
> Hi,
> in include/linux/compiler-gcc.h :
>
> /* Optimization barrier */
> /* The "volatile" is due to gcc bugs */
> #define barrier() __asm__ __volatile__("": : :"memory")
>
> The comment of Linux says this is a gcc bug.But will any sane comp
e of a problem in gcc-2.7.2:
| Add __volatile__ to barrier() definition, I convinced Linus
| to eat this patch. The problem is that with gcc-2.7.2 derived
| compilers the instruction scheduler can move it around due to
| a bug. This bug appears on sparc64/SMP with our old compiler
| in that is mis
n,
>> nothing more.
>
> This is meant to be a compiler barrier not a memory barrier and got
> added by David Miller because of a problem in gcc-2.7.2:
>
> | Add __volatile__ to barrier() definition, I convinced Linus
> | to eat this patch. The problem is that with gcc-2.7.2
quot;) is a memory barrier. Adding volatile
>>> to the asm makes it a barrier for every other volatile instruction,
>>> nothing more.
>>
>> This is meant to be a compiler barrier not a memory barrier and got
>> added by David Miller because of a problem in gcc-2.7.2
t; : : : "memory") is a memory barrier. Adding volatile
> >> to the asm makes it a barrier for every other volatile instruction,
> >> nothing more.
> >
> > This is meant to be a compiler barrier not a memory barrier and got
> > added by David Miller be
On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
>> > So the bug was probably fixed more than 15 years ago.
> Probably :)
>
> But the __volatile__ shoud do no harm and shouldn't influence code
> generation in any way, no?
Of course it will: it's a barrier.
Andrew.
On Tue, Mar 04, 2014 at 09:26:31AM +, Andrew Haley wrote:
> On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
> >> > So the bug was probably fixed more than 15 years ago.
> > Probably :)
> >
> > But the __volatile__ shoud do no harm and shouldn't influence code
> > generation in any way, no?
On Tue, Mar 4, 2014 at 10:33 AM, Hannes Frederic Sowa
wrote:
> On Tue, Mar 04, 2014 at 09:26:31AM +, Andrew Haley wrote:
>> On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
>> >> > So the bug was probably fixed more than 15 years ago.
>> > Probably :)
>> >
>> > But the __volatile__ shoud do
On Tue, Mar 04, 2014 at 12:08:19PM +0100, Richard Biener wrote:
> On Tue, Mar 4, 2014 at 10:33 AM, Hannes Frederic Sowa
> wrote:
> > On Tue, Mar 04, 2014 at 09:26:31AM +, Andrew Haley wrote:
> >> On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
> >> >> > So the bug was probably fixed more t
Richard wrote:
> volatile __asm__("":::"memory")
>
> is a memory barrier and a barrier for other volatile instructions.
AFAIK asm without output arguments is implicitly marked as volatile. So
it may not be needed in barrier() at all.
-Y
t may
> not be needed in barrier() at all.
Yes, exactly. Had it at some time been needed, that'd be a bug.
(I have a faint recollection of that, faint enough to be a false
memory.)
brgds, H-P
>> AFAIK asm without output arguments is implicitly marked as volatile. So it
>> may
>> not be needed in barrier() at all.
>
> Yes, exactly. Had it at some time been needed, that'd be a bug.
> (I have a faint recollection of that, faint enough to be a false
> memory.)
Ah, indeed.
> brgds, H-P
On Tue, Mar 04, 2014 at 12:08:19PM +0100, Richard Biener wrote:
> On Tue, Mar 4, 2014 at 10:33 AM, Hannes Frederic Sowa
> wrote:
> > On Tue, Mar 04, 2014 at 09:26:31AM +, Andrew Haley wrote:
> >> On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
> >> >> > So the bug was probably fixed more t
On 03/04/2014 01:23 AM, Richard Biener wrote:
> Doesn't sound like a bug but a feature. We can move
> asm ("" : : : "memory") around freely up to the next/previous
> instruction involving memory.
Asms without outputs are automatically volatile. So there ought b
On Mar 4, 2014, at 2:30 PM, Richard Henderson wrote:
> On 03/04/2014 01:23 AM, Richard Biener wrote:
>> Doesn't sound like a bug but a feature. We can move
>> asm ("" : : : "memory") around freely up to the next/previous
>> instruction i
>> Asms without outputs are automatically volatile. So there ought be
zero change
>> with and without the explicit use of the __volatile__ keyword.
>
> That’s what the documentation says but it wasn’t actually true
> as of a couple of releases ago, as I recall.
Looks like 2005:
$ git annotate
What is volatile instructions? Can you give us an example?
Check volatile_insn_p. AFAIK there are two classes of volatile instructions:
* volatile asm
* unspec volatiles (target-specific instructions for e.g. protecting
function prologues)
-Y
On 03/04/2014 10:12 PM, Yury Gribov wrote:
>>> Asms without outputs are automatically volatile. So there ought be zero
>>> change
>>> with and without the explicit use of the __volatile__ keyword.
>>
>> That’s what the documentation says but it wasn’t actually true
>> as of a couple of releases a
On Mar 5, 2014, at 10:07 AM, Richard Henderson wrote:
> On 03/04/2014 10:12 PM, Yury Gribov wrote:
Asms without outputs are automatically volatile. So there ought be zero
change
with and without the explicit use of the __volatile__ keyword.
>>>
>>> That’s what the documentation
On Wed, Mar 05, 2014 at 10:39:51AM +0400, Yury Gribov wrote:
> >What is volatile instructions? Can you give us an example?
>
> Check volatile_insn_p. AFAIK there are two classes of volatile instructions:
> * volatile asm
> * unspec volatiles (target-specific instructions for e.g. protecting
> func
I am making a OS for a PC/AT compatible machine with gcc on ubuntu.
The code , whose extension is .c , to task switch in the handler for PIT(timer)
interrupt is...
int tr=(a selector(segment number));
farjmp(0,tr);
the function prototype is
farjmp(int eip,int cs);
farjmp() is defined in another
"Bingfeng Mei" writes:
> /* Obtain value by shifting and set zeros for remaining part*/
> if((bitpos + bitsize) > HOST_BITS_PER_WIDE_INT)
> high = (v >> (HOST_BITS_PER_WIDE_INT - bitpos))
> & ((1 << (bitpos + bitsize - HOST_BITS_PER_WIDE_INT)) - 1);
That is
eng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: A bug on 32-bit host?
>
> "Bingfeng Mei" writes:
>
> > /* Obtain value by shifting and set zeros for remaining part*/
> > if((bitpos + bitsize) > HOST_BITS_PER_WIDE_INT)
> &
o(2));
}
virtual ~c(){}
};
This is not a bug in gcc. foo in b hides the one from a.
You can "fix" the source by:
struct b : public a
{
virtual int foo(int a) =0;
using a::foo;
virtual ~b(){}
};
Which interjects foo from a into b's "namespace".
-- Pinski
Thanks for the quick answer.
This is ok to fix the source, but I do not understand why it is
normal behaviour that the foo() in b hides the one from a. They have
different prototypes.
Regards,
Pierre Chatelier
This is not a bug in gcc. foo in b hides the one from a.
You can "fix
On Mar 6, 2006, at 5:21 AM, Pierre Chatelier wrote:
This is ok to fix the source, but I do not understand why it is
normal behaviour that the foo() in b hides the one from a. They
have different prototypes.
That's just how C++ is designed/defined, any book on C++ should be
able to explain
That's just how C++ is designed/defined, any book on C++ should be
able to explain this in more detail.
Since it was not a bug, I have posted related questions on the gcc-
help list, and I have had valuable answers.
http://gcc.gnu.org/ml/gcc-help/2006-03/msg00026.html
Now I have under
Etienne Lorrain wrote:
> On C structures, for attributes like "const", it is enough to consider
> that each field inherit the attribute of the structure.
> But for the volatile attribute, is it valid to treat each field as
> volatile like GCC does it now?
"An object that has volatile-qualified ty
> > On C structures, for attributes like "const", it is enough to
> > consider that each field inherit the attribute of the structure.
> > But for the volatile attribute, is it valid to treat each field as
> > volatile like GCC does it now?
>
> "An object that has volatile-qualified type may be
>
Etienne Lorrain wrote:
>>> On C structures, for attributes like "const", it is enough to
>>> consider that each field inherit the attribute of the structure.
>>> But for the volatile attribute, is it valid to treat each field as
>>> volatile like GCC does it now?
>> "An object that has volatile-qu
On Fri, Sep 24, 2010 at 10:44:54PM -0700, Steve Kargl wrote:
> So, with the new bugzilla, how does one confirm a bug
> is a bug? If I click on the button next to the
> "status:" field, the selections listed are unconfirmed,
> new, assigned, suspended, waiting, and re
On Sat, Sep 25, 2010 at 10:46:32AM +0200, Jakub Jelinek wrote:
> On Fri, Sep 24, 2010 at 10:44:54PM -0700, Steve Kargl wrote:
> > So, with the new bugzilla, how does one confirm a bug
> > is a bug? If I click on the button next to the
> > "status:" field, the se
On 25 September 2010 16:28, Steve Kargl
wrote:
> On Sat, Sep 25, 2010 at 10:46:32AM +0200, Jakub Jelinek wrote:
>> On Fri, Sep 24, 2010 at 10:44:54PM -0700, Steve Kargl wrote:
>> > So, with the new bugzilla, how does one confirm a bug
>> > is a bug? If I clic
On 25 September 2010 15:28, Steve Kargl wrote:
> On Sat, Sep 25, 2010 at 10:46:32AM +0200, Jakub Jelinek wrote:
>> On Fri, Sep 24, 2010 at 10:44:54PM -0700, Steve Kargl wrote:
>> > So, with the new bugzilla, how does one confirm a bug
>> > is a bug? If I clic
an:
-
-
-
-Status
-Resolution
-
-
-
-The status field indicates the general health of a bug. Only
-certain status transitions are allowed.
-The resolution field indicates what happened to this bug.
-
-
-
+The status and resolution fields define and track the life cycle of a
+bug. In addition to th
On Sat, 9 Apr 2011, Gerald Pfeifer wrote:
> -NEW
> -A maintainer has verified that this is indeed a bug in GCC. Every
> -once in a while, old reports will need to be rechecked, to find out
> -whether the bug still exists.
I think this text is superior for GCC to that on the generic
s not true. VERIFIED and CLOSED are valid bug statuses used in the
GCC Bugzilla. There are 517 bugs with one of these statuses.
In reply to Gerald, Bugzilla 4.2 will contain a hook which will let us
easily customize the http://gcc.gnu.org/bugzilla/page.cgi?id=fields.html
page. For now, if changes are wa
On 10 April 2011 23:51, Frédéric Buclin wrote:
> Le 10. 04. 11 02:19, Joseph S. Myers a écrit :
>> Likewise. We don't use VERIFIED and CLOSED in GCC, proper text should
>> reflect the existence of only one closed state with a genuine meaning and
>> not mention the others (ideally they'd be complet
Le 11. 04. 11 01:33, Jonathan Wakely a écrit :
> Most of those cases are the reporter changing the status to VERIFIED
> after a gcc maintainer has set it to RESOLVED. That doesn't mean the
> maintainers use VERIFIED of that keeping it is useful.
If they are useless, then they should be removed to
On Mon, 11 Apr 2011, Frédéric Buclin wrote:
> Le 10. 04. 11 02:19, Joseph S. Myers a écrit :
> > Likewise. We don't use VERIFIED and CLOSED in GCC, proper text should
> > reflect the existence of only one closed state with a genuine meaning and
> > not mention the others (ideally they'd be comp
n tell, this is not a gcc question at all.
You seem to be asking about how the instruction
jmp far [%esp+4]
should be assembled. That is a question about the assembler, which is
not a part of gcc.
In any case, I agree that the GNU assembler appears to misassemble this
instruction in Inte
Hello,
I casually found a bug in the current released GCC 4.0.0. However, I
have located the wrong code, and it's very easy to be fixed, so it's not
necessary to still submit a bug report. See the following artificial
C++ code:
int *x;
void f()
{
tes either. Note, I tried adding --enable-checking=all to
my configure but all that did was cause a library installation failure.
If anybody has any clues about how to handle this kind of a bug or
even better yet if you have an a idea of what I did wrong then please
let me know.
Note, the particular op
exit status
Is this a bug? If yes, is it known?
GCC 4.8.3 works fine though.
Thanks,
-- Ilya
I am using gcc 3.3.5 with the latest m68hc1x patches to compile programs for a
9s12 processor, and cc1 calls abort when compiling the following code:
void func()
{
short a, *b;
a &= *b;
}
The rtl for the instructions dump as follows:
-> (insn 9 6 10 (nil) (set (reg:HI 53)
-> (mem/f:H
Hello. A couple years ago I got really excited about the gcc "split stacks"
feature that was being developed, and I recently noticed that it is ready to
use now. I thereby have been spending the last few days trying it with one of
my side-projects (currently just a toy, but something I hope to h
On Apr 23, 2005, at 6:35 AM, ~{Dt>Clb~} wrote:
Hello,
I casually found a bug in the current released GCC 4.0.0. However, I
have located the wrong code, and it's very easy to be fixed, so it's
not
necessary to still submit a bug report. See the following artificial
C++ code:
86_AMD64 machine.
I think it's a bug. Can anybody please confirm?
Thanks
Gaurav
collect2: error: ld returned 1 exit status
Is this a bug? If yes, is it known?
GCC 4.8.3 works fine though.
Not a bug, that's what inline means in C99 and later.
--
Marc Glisse
$ gcc main.c
> /tmp/ccD1LeXo.o: In function `main':
> main.c:(.text+0xa): undefined reference to `foo'
> collect2: error: ld returned 1 exit status
>
> Is this a bug? If yes, is it known?
> GCC 4.8.3 works fine though.
Not a bug, just different inline semantics now that
' is already defined
Root cause is in tracer.c which duplicates basic block without
checking if any GIMPLE_ASM defines labels.
Is this a bug or invalid code?
Thanks,
bin
"Sean D'Epagnier" <[EMAIL PROTECTED]> writes:
> -> (insn 10 9 11 (nil) (set (reg:HI 54)
> -> (and:HI (reg:HI 53)
> -> (mem:HI (mem/f:HI (plus:HI (reg/f:HI 49 virtual-stack-vars)
> -> (const_int 2 [0x2])) [0 b+0 S2 A16]) [0 S2 A8])))
> -1 (nil)
> ->
On Fri, Jan 19, 2007 at 05:10:27PM -0700, Sean D'Epagnier wrote:
> I am using gcc 3.3.5 with the latest m68hc1x patches to compile programs for a
> 9s12 processor, and cc1 calls abort when compiling the following code:
It would be most useful to have the exact error message. I'm guessing
that t
Hi, I changed:
(match_operand:HI 2 "general_operand" "")))]
to
(match_operand:HI 2 "splitable_operand" "")))]
as suggested, and the problem seems to be solved!
I posted a bug report the the m68hc1x site, I will post a follow up.
Thanks,
Sean D'Epagnier
ferences to __morestack
> and "cmp %fs:0x70,%rsp" in functions that would otherwise be just a
> few instructions long. Functions that don't use stack should avoid the
> check.
I agree. Want to write a patch? Or at least file a bug report.
> 6) I have noticed that the
etter describe what I mean by this. I've started
the process of getting a copyright assignment in place (sent an e-mail to
fsf-reco...@gnu.org per http://gcc.gnu.org/wiki/CopyrightAssignment).
> I agree. Want to write a patch? Or at least file a bug report.
Sure.
> [paragraph moved
"Jay Freeman (saurik)" writes:
>> As you know, I wanted to allow for future expansion. I agree that it
>> would be possible to avoid storing MORESTACK_SEGMENTS--that would trade
>> off space for time, since it would mean that setcontext would have to
>> walk up the list. I think CURRENT_STACK i
> > "Jay Freeman (saurik)" writes:
> "Ian Lance Taylor" wrote:
> > After getting more sleep, I realize that this problem is actually much
> > more endemic than I had even previously thought. Most any vaguely
> > object-oriented library is going to have tons of function pointers in
> > it, and yo
"Jay Freeman (saurik)" writes:
> So, imagine a more general linker feature (again, one which may
> already exist) that allowed you to have a "low-priority symbol" in
> your object file. As in, one which if you find a copy elsewhere the
> linker will use that one, but if it doesn't then it will "f
d %d %d\n", a,b,c);
> return 0;
> }
> The option -fshort-enums has no effect and the output is same as it is
> without this option.
It's not a bug. Add sizeof(enum aa) to your printf; _that_ will be
affected by -fshort-enums. The type of the enumerators remains int.
--
Daniel Jacobowitz
CodeSourcery, LLC
Thanks for the reply,
But why is there a difference in the output of same tc, with an old gcc
compiler and a new version of compiler.
Was there a bug in the earlier gcc.
I have a doubt.
Gcc manual says that
"-fshort-enums
Allocate to an enum type only as many bytes as it needs fo
1 - 100 of 151 matches
Mail list logo
