On 31/01/2025 14:22, noname noname via Gcc wrote:
hello, I'm a regular user of Fedora 41 Workstation. I usually install all
my apps through one command which has tons of packages to it. So I'm not
sure which one of them pulled gcc as a dependency. But either way. While
installing all of them, dnf
On Fri, 31 Jan 2025 at 13:24, noname noname via Gcc wrote:
>
> hello, I'm a regular user of Fedora 41 Workstation. I usually install all
> my apps through one command which has tons of packages to it. So I'm not
> sure which one of them pulled gcc as a dependency. But either way. While
> installin
On 31/01/2025 14:22, noname noname via Gcc wrote:
hello, I'm a regular user of Fedora 41 Workstation. I usually install all
my apps through one command which has tons of packages to it. So I'm not
sure which one of them pulled gcc as a dependency. But either way. While
installing all of them, dnf
sorry, I forgot to mention that the packages were installed somewhere in
November or December 2024. So this bug might already be resolved by now.
пт, 31 янв. 2025 г. в 15:22, noname noname :
> hello, I'm a regular user of Fedora 41 Workstation. I usually install all
> my apps through one command
hello, I'm a regular user of Fedora 41 Workstation. I usually install all
my apps through one command which has tons of packages to it. So I'm not
sure which one of them pulled gcc as a dependency. But either way. While
installing all of them, dnf said:
[128/579] Installing libgcc-0:14.2.1-3.fc41.
On Mon, Aug 7, 2023 at 8:52 AM Şahin Duran via Gcc wrote:
>
> Dear GCC Developers,
>
> I think I've just discovered a bug/ undefined situation in the compiler.
> When I try to call a weakly defined function, compiler successfully
> generates the code of calling procedure
On 07/08/2023 16:51, Şahin Duran via Gcc wrote:
Dear GCC Developers,
I think I've just discovered a bug/ undefined situation in the compiler.
When I try to call a weakly defined function, compiler successfully
generates the code of calling procedure. However, this calling procedure is
no
Dear GCC Developers,
I think I've just discovered a bug/ undefined situation in the compiler.
When I try to call a weakly defined function, compiler successfully
generates the code of calling procedure. However, this calling procedure is
nothing but branching to address 0 which resul
What is going on out there these days? I've added more addresses from
the GCC mailing list to my killfile in the last week than in the
previous two years combined.
Yeesh.
Seriously? You UNIX folks are completely clueless about usability! It would
have been far easier to supply a built-in or separate utility to
automatically collect all the pertinent source files with the option of
mailing them to you. It also wouldn't be half as backward if you didn't
make me read a
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
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
>
> 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 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
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 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 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 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
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/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
: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?
> > > >>
> > > >>
> > > >
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
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
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
> 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;
>
= _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
_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
_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
(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
;
> 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
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
basic block without
> > checking if any GIMPLE_ASM defines labels.
> > Is this a bug or invalid code?
>
> This is invalid code, GCC documentation is clear that the compiler
> may duplicate inline asm statements (passes other than tracer can do
> that too, loop unswitching j
c block without
> > checking if any GIMPLE_ASM defines labels.
> > Is this a bug or invalid code?
>
> This is invalid code, GCC documentation is clear that the compiler
> may duplicate inline asm statements (passes other than tracer can do
> that too, loop unswitching just to give on
On Sat, 29 Dec 2018, Bin.Cheng wrote:
> tracer-1.c: Assembler messages:
> tracer-1.c:16: Error: symbol `foo_label' 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
' 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
$ 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
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
exit status
Is this a bug? If yes, is it known?
GCC 4.8.3 works fine though.
Thanks,
-- Ilya
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
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 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
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
>> 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
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
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 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
>> 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
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
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
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 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 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 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.
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
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
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
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
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
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
gister allocation pass decided to reuse
> stack slot 12(%rsp) where key_data persisted.
>
> movl key_gdata(%rip), %eax
> movl %eax, 12(%rsp)
> call _setjmp
>
> ... and later ...
>
> .L10:
> movl 12(%rsp), %edi <--- oops!
> call foo
>
>
call foo
setjmp stored stack pointer, next frame slot is overwritten by
spill/fill (because compiler thinks that key_data is already dead at
this point. Then everything explodes.
I am not sure that it is a bug, but situation is rather complicated
for programmer -- I think in this case programmer
"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
> > "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:
>> 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
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
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
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
This question is not appropriate for this mailing list, questions
about using GCC should be sent to the gcc-h...@gcc.gnu.org list,
please take any follow up there, thanks.
On 24 February 2012 08:34, Yang Yueming wrote:
>
> The result of xyz should be "0"，but it is "2468acf123579bc" ,same as xyz =
Yang Yueming writes:
> long long abc = 0x01234567891abcde;
> long long xyz;
...
> xyz = abc << 65;
...
> The result of xyz should be "0"，but it is "2468acf123579bc" ,same as
> xyz = abc << 1,Why?
Because the shift operators in C have an undefined result when the
shift-count is larger than
Case:
#include
#include
long long abc = 0x01234567891abcde;
long long xyz;
int main ()
{
xyz = abc << 65;
printf("%llx\n", xyz);
return 0;
}
The result of xyz should be "0"，but it is "2468acf123579bc" ,same as xyz = abc
<< 1,Why?
So as for "i
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
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
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
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 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
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 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
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 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
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 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 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
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
s duplicates.
>
> Nenad
>
> On 7/8/10 7:33 PM, asmwarrior wrote:
>>
>> I have post this message to both GCC and GDB, because I'm not sure it is
>> a bug in GDB or GCC.
>> Hi, I have just find two dwarf debug entries f
On 2010-7-9 13:58, Nenad Vukicevic wrote:
I reported something similar back in January:
http://gcc.gnu.org/ml/gcc/2010-01/msg00054.html
As I recall, GCC creates duplicates.
Nenad
Thanks for the reply. I also found your message,
This bug has been fixed,see:
http://gcc.gnu.org/bugzilla/show_
I reported something similar back in January:
http://gcc.gnu.org/ml/gcc/2010-01/msg00054.html
As I recall, GCC creates duplicates.
Nenad
On 7/8/10 7:33 PM, asmwarrior wrote:
I have post this message to both GCC and GDB, because I'm not sure it
is a bug in GDB or GCC.
Hi, I have just
I have post this message to both GCC and GDB, because I'm not sure it
is a bug in GDB or GCC.
Hi, I have just find two dwarf debug entries for one local variables.
For example, the sample code is just like:
-
wxString ParserThread::ReadAncesto
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)
> &
"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
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))
n fact, removing the PCH and recreating it fixed the problem! Thanks for the
hint.
How can I report such a bug? Including all involved files in a tarball
would violate the rules for reporting bugs.
Do it anyhow if that is the only way.
hmmm, actually I didn't make a backup copy of the da
Francesco Montorsi writes:
> I'm new to GCC project so let me know if this is the wrong place
> where I can ask such a question.
The mailing list gcc-h...@gcc.gnu.org would be a better place.
> I've found a bug in Gcc 4.3.3 (on machine "Linux ubuntu
> 2.6.28-9-gen
Hi,
I'm new to GCC project so let me know if this is the wrong place where I can
ask such a question.
I've found a bug in Gcc 4.3.3 (on machine "Linux ubuntu 2.6.28-9-generic
#31-Ubuntu SMP Wed Mar 11 15:43:49 UTC 2009 x86_64 GNU/Linux") which I can
reliably reproduce
On Tue, Dec 16, 2008 at 10:41 AM, Jan Engelhardt wrote:
> Is not this a use of an rvalue array too?:
>printf("%p\n", (struct { char x[20]; }){{"Hello"}}.x);
No, compound literals are always lvalues in C99.
Thanks,
Andrew Pinski
On Tuesday 2008-12-16 18:43, Michel Van den Bergh wrote:
> Andrew Haley wrote:
>> Andrew Thomas Pinski wrote:
>>
>> > C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
>> > arrays in C++98. Also this code is still undefined C99 but will most
>> > likely become valid C1x.
>>
On Tue, Dec 16, 2008 at 9:43 AM, Michel Van den Bergh
wrote:
> Andrew Haley wrote:
>>
>> Andrew Thomas Pinski wrote:
>>
>>>
>>> C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
>>> arrays in C++98. Also this code is still undefined C99 but will most
>>> likely become valid C1
Andrew Haley wrote:
Andrew Thomas Pinski wrote:
C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
arrays in C++98. Also this code is still undefined C99 but will most
likely become valid C1x.
Ah, it's an rvalue array. Good point.
Ok now I understand. I assume t
>
> On Tuesday 2008-12-16 17:05, Michel Van den Bergh wrote:
>
>> 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(){
>> st
Andrew Thomas Pinski wrote:
> C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
> arrays in C++98. Also this code is still undefined C99 but will most
> likely become valid C1x.
Ah, it's an rvalue array. Good point.
> Sent from my iPhone
Advertising on gcc list. Dear me...
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
1 - 100 of 156 matches
Mail list logo
