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
I goofed and failed to put a space after the "case" word:
switch(nu){
case1: v1 =val;break;
case2: v2 =val;break;
case3: v3 =val;break;
case4: v4 =val;break;
}
gcc compiler showed NO errors or warnings. Execution of the code produced
incorrect results.
After I added a space(no other changes), ev
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_
Greetings Segher,
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_SRC (set);
if (!(REG_P (src) && HARD_REGISTER_P (src)))
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/
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/gcc/commit/7d9cc102adf11065358d4694109ce3
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
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 comment would
be very
helpful befor
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,
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,
base: 24;
};
struct lock_chain * foo (struct lock_chain *chain)
{
int i;
f
(should have been gcc-h...@gcc.gnu.org, please send any follow-ups there)
On Wed, 23 Apr 2014, George R Goffe wrote:
I'm trying to build the latest gcc
Do you really need gcj? If not, please disable java.
and am getting a message from the
process "collect2: error: ld returned 1 exit status"
Hi,
I'm trying to build the latest gcc and am getting a message from the process
"collect2: error: ld returned 1 exit status" for this library
/usr/lsd/Linux/lib/libgmp.so. Here's the full msg:
"/usr/lsd/Linux/lib/libgmp.so: could not read symbols: File in wrong format"
When I use the file c
On Mon, Mar 10, 2014 at 1:30 PM, Basile Starynkevitch
wrote:
> Hello All,
>
>
> I am a bit confused (or unhappy) about the current_pass variable
> (in GCC 4.9 svn rev.208447); I believe we have some incoherency about it.
>
> It is generally (as it used to be in previous versions of GCC)
> a global
Hello All,
I am a bit confused (or unhappy) about the current_pass variable
(in GCC 4.9 svn rev.208447); I believe we have some incoherency about it.
It is generally (as it used to be in previous versions of GCC)
a global pointer to some opt_pass, declared in gcc/tree-pass.h line 590.
It is a
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.
I'm using a GCC toolchain similar to Yagarto for making code for the LPC1768
microcontroller.
My gcc is version 4.7.2, my binutils is version 2.23.1
To make parts of my code run faster (a timer interrupt to be exact), I've used
a modified linker script, so that I get a '.fastcode' section.
The
>>> 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
Hi All,
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 fence, but I'm
not actuall
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
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
object file inside a special section. This works fine in
Hello all,
I have noticed something that is creating problems in my modified GCC,
and I see it as a bug, maybe I don't do something right. If you take a
look at cpp_interpret_string() function in charset.c you will see the
following part:
for (;;)
{
base = p;
while (p
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);
>
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);
}
void foo(int)
{}
int main()
{
int i;
foo(i); // OK: Resolves foo(int
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
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 code
}
// main.cpp
#include "a.hpp"
int main(void)
{
func1();
I installed gcc4.3 20080215 on os x10.5.2 using macports
The configure arguments (with prefix = /opt/local) are:
47 configure.args --enable-languages=c,c++,objc,obj-c++ \
48 --libdir=${prefix}/lib/${name} \
49 --includedir=${prefix}/include/${name} \
"Macy Gasp" <[EMAIL PROTECTED]> writes:
> Any ideas on how I could solve this?
There is no way around va_copy. But please ask in [EMAIL PROTECTED],
this is off-topic here.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germa
On 10/17/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Macy Gasp writes:
> > On 10/17/07, Macy Gasp <[EMAIL PROTECTED]> wrote:
> > > On 10/17/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
> > > > Macy Gasp writes:
> > > > > Hi everybody,
> > > >
> > > > Read the Fine Manual:
> > > >
> > > >
On 10/17/07, Macy Gasp <[EMAIL PROTECTED]> wrote:
> On 10/17/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
> > Macy Gasp writes:
> > > Hi everybody,
> >
> > Read the Fine Manual:
> >
> >
> >int vsprintf(char *str, const char *format, va_list ap);
> >
> >The functions vprintf(), vfpri
On 10/17/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Macy Gasp writes:
> > Hi everybody,
>
> Read the Fine Manual:
>
>
>int vsprintf(char *str, const char *format, va_list ap);
>
>The functions vprintf(), vfprintf(), vsprintf(), vsnprintf()
>are equivalent to the function
Macy Gasp writes:
> Hi everybody,
>
> I'm experiencing a weird behaviour when using va_list with gcc 4.1.2
> on a x86_64 linux distribution.
>
> Below is my test program (yes, I know about the possible buffer
> overflows but please, bear with me, this is just a proof of concept):
>
> #i
On 10/17/07, Macy Gasp <[EMAIL PROTECTED]> wrote:
> Hi everybody,
>
> I'm experiencing a weird behaviour when using va_list with gcc 4.1.2
> on a x86_64 linux distribution.
>
> Below is my test program (yes, I know about the possible buffer
> overflows but please, bear with me, this is just a proof
Hi everybody,
I'm experiencing a weird behaviour when using va_list with gcc 4.1.2
on a x86_64 linux distribution.
Below is my test program (yes, I know about the possible buffer
overflows but please, bear with me, this is just a proof of concept):
#include
#include
int var(const char* fmt, .
Hi all,
there is a problem in the vcg file created when compiling the following code
with gcc's -fdump-rtl-stack -dv:
#include
void fun(void) {
printf("fun\n");
}
int main(void) {
fun();
return 0;
}
the vcg file created has the two nodes "main.0" and "fun.0"
disconnect
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
Hello,
I've noticed some strange behavior regarding C++ SFINAE that I believe
may not be ISO-14882 compliant. I've tried to get a minimal example to
reproduce the compilation errors I'm getting, but some explanation is
needed.
I'm working on a boolean metafunction to detect nested member
templat
e that there doesn't seem to be a consistent preprocessor spec.
--
View this message in context:
http://www.nabble.com/Possible-bug-in-preprocessor-tf3494353.html#a9827482
Sent from the gcc - Dev mailing list archive at Nabble.com.
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
a, b) a, b
int main (int argc, char **argv)
{ printf("%s %s\n", GETBRCKTELMNT((YYY, XXX)));
getchar();
return (0);
}
Regs
Jose
--
View this message in context:
http://www.nabble.com/Possible-bug-in-preprocessor-tf3494353.html#a9760061
Sent from the gcc - Dev mailing list archive at Nabble.com.
((YYY, XXX)));
getchar();
return (0);
}
Regs
Jose
--
View this message in context:
http://www.nabble.com/Possible-bug-in-preprocessor-tf3494353.html#a9760061
Sent from the gcc - Dev mailing list archive at Nabble.com.
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
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.
Regards,
Rodolfo Lima
- Forwarded message from Rodolfo Schulz de Lima <[EMAIL PROTECTED]> -
> Date: Fri, 13 Oct 2006 14:05:27 -0300
> From: R
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
I notice that the following testcase:
int x[4];
void f1 (long long n) { while (n-- != 0) x[n] = 1; }
void f2 (long long n) { while (n-- != 0) x[n] = 1; }
void f3 (long long n) { while (n-- != 0) x[n] = 1; }
when compiled with optimisation enabled on i386-linux-gnu, causes us to
go
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
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 failure in c45651a and possibly others.
On Tue, 2005-03-01 at 15:29, Petko Manolov wrote:
> On Tue, 1 Mar 2005, Paul Brook wrote:
>
> > The "old" arm-none-elf and arm-linux targets still use SJLJ exceptions. They
> > will probably never be "fixed" as this would involve an ABI change.
>
> Didn't understand that. How is all non scratch
On Tuesday 01 March 2005 15:29, Petko Manolov wrote:
> On Tue, 1 Mar 2005, Paul Brook wrote:
> > The "old" arm-none-elf and arm-linux targets still use SJLJ exceptions.
> > They will probably never be "fixed" as this would involve an ABI change.
>
> Didn't understand that. How is all non scratch F
On Tue, 1 Mar 2005, Paul Brook wrote:
The "old" arm-none-elf and arm-linux targets still use SJLJ exceptions. They
will probably never be "fixed" as this would involve an ABI change.
Didn't understand that. How is all non scratch FP registers save at the
prologue related to the exceptions?
Pet
> [Paul]:
> Is this problem present also in CSL-3.4.x branch?
That depends which target you are using. It Richard's analysis is correct this
is an ABI limitation rather than a compiler problem.
The "old" arm-none-elf and arm-linux targets still use SJLJ exceptions. They
will probably never be
On Tue, 2005-03-01 at 10:54, Vladimir Ivanov wrote:
> Hello,
>
> [Richard]:
> Does this mean that GCC-3.4.x won't be fixed?
>
Most certainly it won't be. 3.4 is in regression-fix only mode and this
is not a regression.
R.
Hello,
[Richard]:
Does this mean that GCC-3.4.x won't be fixed?
[Paul]:
Is this problem present also in CSL-3.4.x branch?
Best regards,
-- Vladimir
On Tue, 1 Mar 2005, Richard Earnshaw wrote:
On Mon, 2005-02-28 at 12:51, Vladimir Ivanov wrote:
Hello all,
While compiling this:
On Mon, 2005-02-28 at 12:51, Vladimir Ivanov wrote:
> Hello all,
>
> While compiling this:
> http://sourceforge.net/projects/raytracer/
>
> I think I've spotted a bug in ARM port of G++.
>
> The problem is that many method functions tend to save all callee-saved FP
> registers, while they
Hello all,
While compiling this:
http://sourceforge.net/projects/raytracer/
I think I've spotted a bug in ARM port of G++.
The problem is that many method functions tend to save all callee-saved FP
registers, while they use few or none of them.
Here's a small snippet from "base3d.cpp" fil
93 matches
Mail list logo
