> "tm" == tm gccmail <[EMAIL PROTECTED]> writes:
tm> On 25 Mar 2005, Ian Lance Taylor wrote:
>> Safe but very costly. It assumes that every processor has a cheap
>> way to save and restore the condition codes in user mode, which is
>> not necessarily the case. And it assumes that the sav
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> Georg Bauhaus <[EMAIL PROTECTED]> writes:
>> | A busy-loop function is used to effect a delay, not too precise,
>> | but portably. Like
>> |
>> | #define COUNT 1000
>> |
>> | void f() { | /*volatile*/ /*register*/ int i;
>> |
>>
> "Andrew" == Andrew Pinski <[EMAIL PROTECTED]> writes:
Andrew> Yes it might be a silent miscompiling but there is an easy
Andrew> work around, use a temporary variable, ...
I'm not sure how there can ever be an "easy" workaround to silent
miscompiles -- by definition you may not know there
> "Michael" == Michael N Moran <[EMAIL PROTECTED]> writes:
Michael> Jason Merrill wrote:
>> One proposed change is to the semantics of volatile.
Michael> Since IANALL, but I believe (as obviously you do) that
Michael> changing the semantics of volatile should be under-taken
Michael> with
> "Jason" == Jason Merrill <[EMAIL PROTECTED]> writes:
Jason> On Thu, 14 Apr 2005 15:47:44 -0500, Robert Dewar
Jason> <[EMAIL PROTECTED]> wrote:
>> [Ada standard]
Jason> Yep, sounds a lot like C/C++: volatile reads and writes are
Jason> required to have sequential ordering relative to ea
> "Marcin" == Marcin Dalecki <[EMAIL PROTECTED]> writes:
Marcin> Templates are a no-go for a well known and well defined
Marcin> subset for C++ for embedded programming known commonly as
Marcin> well embedded C++.
I don't think that's a good argument. If people want to emasculate
the la
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
Ralf> struct entrystruct * entry __attribute__ ((packed));
Ralf> is interpreted as "packed pointer to struct" not as "pointer to
Ralf> packed struct", i.e. this construct is not meaningful.
Yes it's meaningful, it may not be what you
> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes:
>> Michael N. Moran wrote: I'm very much in favor of fine grained
>> synchronization primitives in the compiler, but not of changes to
>> volatile semantics.
Paul> I wonder if it would be sufficient (if not preferable) to only
Paul> ext
>>>>> "E" == E Weddington <[EMAIL PROTECTED]> writes:
E> Paul Koning wrote:
>> It sure would be useful, though, if there were a construct that
>> does mean "pointer to packed T". In particular, I've often needed
>> "
>>>>> "E" == E Weddington <[EMAIL PROTECTED]> writes:
E> Paul Koning wrote: According to the docs here:
E>
<http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Type-Attributes.html#Type-Attributes>
>>
E> what about doing something like this?:
>
> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
Dave> Doesn't the C language spec require the mode to be switchable
Dave> at runtime?
Dave> In any case, the ARM or Alpha isn't prevented from working in
Dave> such a fashion just because the rounding mode is encoded in the
Dave> instruct
>>>>> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
Dave> ----Original Message
>> From: Paul Koning Sent: 15 April 2005 17:56
>>>>>>> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
>>
Dave> Doesn&#x
> "Marcin" == Marcin Dalecki <[EMAIL PROTECTED]> writes:
Marcin> On 2005-04-15, at 20:18, Mike Stump wrote:
>> On Thursday, April 14, 2005, at 08:48 PM, Marcin Dalecki wrote:
>>> Templates are a no-go for a well known and well defined subset
>>> for C++ for embedded programming known comm
> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
Robert> Ken Raeburn wrote:
>> That's what I thought. So, unless the compiler (or language spec)
>> is going to become thread-aware, any data to be shared across
>> threads needs to be declared volatile, even if some other
>> mechanis
>>>>> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
Robert> Paul Koning wrote:
>>>>>>> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
>>
Robert> Ken Raeburn wrote:
>> >> That's w
> "PhilipG" == Philip George <[EMAIL PROTECTED]> writes:
>> What did you really mean?
PhilipG> I need to install gcc into a disk image that will accompany
PhilipG> a gui application i'm writing.
PhilipG> ...the entire package (gui app + disk image with gcc) will be
PhilipG> downloadable,
> "Steven" == Steven Bosscher <[EMAIL PROTECTED]> writes:
Steven> On Wednesday 27 April 2005 17:45, Matt Thomas wrote:
>> If no one builds natively on older platforms, the recognition that
>> the new features maybe a problem for older platforms will never be
>> made.
Steven> Maybe the o
>>>>> "Steven" == Steven Bosscher <[EMAIL PROTECTED]> writes:
Steven> On Wednesday 27 April 2005 22:06, Paul Koning wrote:
>> Isn't a full bootstrap (all languages) part of the required test
>> procedure for changes? That's what the webs
> "Andrew" == Andrew Pinski <[EMAIL PROTECTED]> writes:
>> However, I can always tell when a GCC build has hit the libjava
>> build -- that's when the *whole system* suddenly slows to a crawl.
>> Maybe it comes from doing some processing on 5000 foo.o files all
>> at once... :-(
Andrew>
> "Nathan" == Nathan Sidwell <[EMAIL PROTECTED]> writes:
Nathan> Dale Johannesen wrote:
>> However, as a QOI issue, I believe the compiler should treat the
>> reference as volatile if either the object or the lvalue is
>> volatile. That is obviously the user's intent.
Nathan> I'm not di
This test program:
struct bar;
template struct bar *foo (T *p)
{
return p->t;
}
produces an error in 4.0.0:
test.cc:3: error: β??barβ?? is not a template type
Without the keyword "struct" it compiles fine. Earlier versions
(3.3.2, and I'm pretty sure 3.4.1 as well) don't complain.
> "James" == James E Wilson writes:
James> Jonathan Bastien-Filiatrault wrote:
>> * We have defined BIT_PER_WORD to 16 and UNITS_PER_WORD to 1. On
>> this DSP, there are two 40-bits accumulators. How do we make GCC
>> take advantage of this and which machine mode do we use ?
James> GCC
> "Dale" == Dale Johannesen <[EMAIL PROTECTED]> writes:
Dale> On May 4, 2005, at 5:06 AM, Gabriel Dos Reis wrote:
>> Andrew Haley <[EMAIL PROTECTED]> writes:
>>
>> | Nathan Sidwell writes: | > Dale Johannesen wrote:
>> | >
>> | > > And we don't have to document the behavior at all; it
>>>>> "James" == James E Wilson writes:
James> On Wed, 2005-05-04 at 06:00, Paul Koning wrote:
>> I wonder if the work-in-progress PDP10 port
>> (http://pdp10.nocrew.org/gcc/) might help with this.
James> Interesting, but a hobbyist port for a 3
I'm doing some tests to see if 4.0.0 will improve our debug
experience, which is mixed indeed with complex C++ code and 3.3.3.
So far it looks like things are MUCH worse. I built my application
and looked at it with GDB. Many of the structure names are missing.
I did some checking with readelf,
>>>>> "Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
Daniel> On Wed, May 04, 2005 at 03:53:35PM -0400, Paul Koning wrote:
>> I'm doing some tests to see if 4.0.0 will improve our debug
>> experience, which is mixed indeed with c
>>>>> "Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
Daniel> On Wed, May 04, 2005 at 04:15:53PM -0400, Paul Koning wrote:
>> OUCH.
>>
>> Some of the types in question are probably not used in the program
>> -- they are the
> "Kai" == Kai Henningsen <[EMAIL PROTECTED]> writes:
Kai> As a QOI issue, it would be nice if such a situation caused a
Kai> warning ("ignoring volatile cast ..." or something like that).
Kai> It's rather dangerous to have the user believe that this worked
Kai> as intended when it didn't
> "Florian" == Florian Weimer <[EMAIL PROTECTED]> writes:
Florian> Indeed. Explicitly pushing an exception frame pointer on
Florian> the main stack is covered by the patent.
Oh, like VMS has done since V1.0, in 1978?
paul
>>>>> "Geoffrey" == Geoffrey Keating <[EMAIL PROTECTED]> writes:
Geoffrey> Paul Koning <[EMAIL PROTECTED]> writes:
>> Still, never mind what the C spec appears to say, optimizing away
>> the cast cannot possibly what the user intended.
G
I ran into link errors complaining about references to hidden symbol
_Unwind_GetIP from a DSO.
It turns out unwind-dw2.c is compiled with -fvisibility=hidden for the
static library case (but not for the shared library case).
In my link, I was using the libgcc.a (for that particular platform I
don
>>>>> "Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
Daniel> On Fri, May 13, 2005 at 05:33:21PM -0400, Paul Koning wrote:
>> I ran into link errors complaining about references to hidden
>> symbol _Unwind_GetIP from a DSO.
>
> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
Robert> Peter Barada wrote:
>>> We're not talking about 5% speedup; if the linker starts
>>> thrashing because of insufficient memory you pay far more than
>>> that. And certainly anyone with an older computer who is
>>> dissatified
I'm upgrading to V4.0.0 and struggling with some code that's seriously
into templates. One puzzling error is this one:
keyed_obj.hh:159: error: no matching function for call to
'CxnIndex::CxnIndex(CxnIndex)'
Indeces.hh:150: note: candidates are: CxnIndex::CxnIndex(CxnIndex&)
Indeces.hh:145: note
> "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
Gabriel> Joe is right. But I think the diagnostic is very very
Gabriel> confusing and it is not obvious what was going from the type
Gabriel> signature. Please fill a bugzilla PR and ask for diagnostic
Gabriel> enhancement.
Tha
> "Sam" == Sam Lauber <[EMAIL PROTECTED]> writes:
>> > The documentation for -fvisibility=hidden suggets that this
>> switch is > useful for shared libraries, to make things smaller
>> and faster. It > doesn't seem to be appropriate for object
>> libraries.
>> It's done *exactly* so tha
>>>>> "Richard" == Richard Henderson <[EMAIL PROTECTED]> writes:
Richard> On Wed, May 18, 2005 at 11:32:51AM -0400, Paul Koning wrote:
>> What surprises me is that it's normally ok to mix static and
>> shared libs, but not here. And the messa
>>>>> "Richard" == Richard Henderson <[EMAIL PROTECTED]> writes:
Richard> On Wed, May 18, 2005 at 01:04:15PM -0400, Paul Koning wrote:
>> Fine, but are GCC *users* expected to search the GCC list
>> archives?
Richard> If they want to know t
> "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
Gabriel> http://www.gnu.org/software/gcc/codingconventions.html
Gabriel> Avoid the use of identifiers or idioms that would prevent
Gabriel> code compiling with a C++ compiler. Identifiers such as new
Gabriel> or class, that are r
> "Scott" == Scott Robert Ladd <[EMAIL PROTECTED]> writes:
Scott> Richard Henderson wrote:
>> On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote:
>>
>>> static const double range = PI; // * 2.0; static const double
>>> incr = PI / 100.0;
>>
>>
>> The trig insns fail w
> "Kevin" == Kevin Handy <[EMAIL PROTECTED]> writes:
Kevin> But, you are using a number in the range of 2^90, only have 64
Kevin> bits for storing the floating point representation, and some
Kevin> of that is needed for the exponent.
Fair enough, so with 64 bit floats you have no right to
> "Scott" == Scott Robert Ladd <[EMAIL PROTECTED]> writes:
Scott> Dave Korn wrote:
>> It's difficult to tell from that quote, which lacks sufficient
>> context, but you *appear* at first glance to be conflating the
>> fundamental trignometric *functions* with the trignometric
>> *identiti
After some off-line exchanges with Dave Korn, it seems to me that part
of the problem is that the documentation for
-funsafe-math-optimizations is so vague as to have no discernable
meaning.
For example, does the wording of the documentation convey the
limitation that one should only invoke math
> "Uros" == Uros Bizjak <[EMAIL PROTECTED]> writes:
Uros> Hello!
>> Fair enough, so with 64 bit floats you have no right to expect an
>> accurate answer for sin(2^90). However, you DO have a right to
>> expect an answer in the range [-1,+1] rather than the 1.2e+27 that
>> Richard quoted.
> "Allan" == Allan Sandfeld Jensen <[EMAIL PROTECTED]> writes:
Allan> Maybe the real goal like other have mentioned should be to
Allan> divide the -ffast-math into multiple switches.
Yes, and document them so both users and implementers can tell what
they mean, which is not currently the ca
>>>>> "Scott" == Scott Robert Ladd <[EMAIL PROTECTED]> writes:
Scott> Paul Koning wrote:
Allan> Maybe the real goal like other have mentioned should be to
Allan> divide the -ffast-math into multiple switches.
>> Yes, and document them so both user
>>>>> "Geoffrey" == Geoffrey Keating <[EMAIL PROTECTED]> writes:
Geoffrey> Paul Koning <[EMAIL PROTECTED]> writes:
>> After some off-line exchanges with Dave Korn, it seems to me that
>> part of the problem is that the documentation for
>
> "Nathanael" == Nathanael Nerode <[EMAIL PROTECTED]> writes:
Nathanael> * pdp11-*-* (generic only) Useless generic.
I believe this one generates DEC (as opposed to BSD) calling
conventions, so I'd rather keep it around. It also generates .s files
that can (modulo a few bugfixes I need to g
>>>>> "Nathanael" == Nathanael Nerode <[EMAIL PROTECTED]> writes:
Nathanael> Paul Koning wrote:
>>>>>>> "Nathanael" == Nathanael Nerode <[EMAIL PROTECTED]>
>>>>>>> writes:
>>
Nathanael>
> "Nathan" == Nathan Sidwell <[EMAIL PROTECTED]> writes:
>> And all useful programs we write rely on undefined behaviour of
>> one sort or the other, starting with GCC. In the case of
Nathan> They do? I thought they usually relied on implementation
Nathan> defined, documented extensions
> "Steven" == Steven Bosscher <[EMAIL PROTECTED]> writes:
Steven> Indeed. Frankly this "seems likely" guess confuses me. It
Steven> is already well known that using unsigned types for loop
Steven> counters may greatly improve the code gcc can generate for
Steven> loops. With wrap-around
> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
Robert> I am puzzled, why would *ANYONE* who knows C use int rather
Robert> than unsigned if they want wrap around semantics?
Because most people don't follow the rule that "always use unsigned
variables unless you know that it really n
> "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> Robert Dewar <[EMAIL PROTECTED]> writes:
>
> Gabriel Dos Reis wrote:
>> Robert Dewar <[EMAIL PROTECTED]> writes:
>> >"has the semantics that Gabriel Dos Reis wants" is not an evaluable
>> >predicate!
>> You completely missed the poi
> "Nicholas" == Nicholas Nethercote <[EMAIL PROTECTED]> writes:
Nicholas> This point about 33-bit machines is interesting because it
Nicholas> raises an optimisation scenario that hasn't been mentioned
Nicholas> so far.
Nicholas> Consider doing 32-bit integer arithmetic on 64-bit machines
> "Falk" == Falk Hueffner <[EMAIL PROTECTED]> writes:
>> $ alpha-unknown-linux-gnu-gcc -fno-common -ffreestanding -O2 \
>> -mno-fp-regs -ffixed-8 -msmall-data -mcpu=ev5 -Wa,-mev6 -c
>> core_cia.i
Falk> I don't see any fault on gcc's side here. You could argue that
Falk> the command line
> "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:
Joseph> On Mon, 11 Jul 2005, Michael Cieslinski wrote:
>> I also could convert parts of the ggcinternals manual into wiki
>> pages. But only if there is a consensus about this being the way
>> to go.
Joseph> I'm sure it's the wron
>>>>> "Kevin" == Kevin Handy <[EMAIL PROTECTED]> writes:
Kevin> Paul Koning wrote:
>>>>>>> "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:
>>>>>>>
>>>>>>>
>>
J
> "Matthew" == Matthew Woodcraft <[EMAIL PROTECTED]> writes:
Matthew> Paul Schlie wrote:
>> As optimization seems to be a non-argument, as by analogy all
>> optimizations which are available for unsigned arithmetic are
>> correspondingly available for signed integer operations; as any
>>
> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes:
>> From: Robert Dewar <[EMAIL PROTECTED]>
>>> Paul Schlie wrote:
What about optimising x*2/2 to x?
>>> Given that "C" requires the above be evaluated as (x*2)/2, as the
>>> language specifies that the syntax defines the precedence o
> "Vincent" == Vincent Lefevre <[EMAIL PROTECTED]> writes:
Vincent> On 2005-07-12 23:42:23 +0200, Erik Trulsson wrote:
>> Pointer subtraction is only well defined if both pointers point to
>> elements in the same array (or one past the end of the array).
Vincent> I don't know what you mea
>>>>> "Vincent" == Vincent Lefevre <[EMAIL PROTECTED]> writes:
Vincent> On 2005-07-17 12:55:38 -0400, Paul Koning wrote:
>> Are you sayinvg that a-b is not always "guaranteed to work" when a
>> and b point to elements of the same a
> "D" == D Hugh Redelmeier <[EMAIL PROTECTED]> writes:
D> This is true. And an abomination. But I will explain a bit more
D> where this came from. ...
Thanks Doug.
"Abomination" is a good word for it.
paul
One of the things that continues to baffle me (and my colleagues) is
the bizarre way in which attributes such as "packed" work when applied
to structs.
It would be natural to assume, as Shaun did, that marking a struct
"packed" (or, for that matter, "packed,aligned(2)") would apply that
attribute
>>>>> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
Dave> Original Message
>> From: Shaun Jackman Sent: 02 August 2005 20:26
>> On 8/2/05, Paul Koning <[EMAIL PROTECTED]> wrote:
>>> One of the things that continues to b
> "Shaun" == Shaun Jackman <[EMAIL PROTECTED]> writes:
>> 2) Is there padding between the struct members to maintain their
>> natural alignments (on the assumption that the struct's base
>> address is aligned.)
Shaun> There is no padding. The structure is defined as
Shaun> __attribute__(
> "Andrew" == Andrew Pinski <[EMAIL PROTECTED]> writes:
>> Yes, this is a compiler bug in the expansion of memcpy, please
>> file a bug report. The solution is for the compiler to notice the
>> memory alignment of the destination and `do-the-right-thing' when
>> it isn't aligned.
Andrew
>>>>> "Shaun" == Shaun Jackman <[EMAIL PROTECTED]> writes:
Shaun> On 8/2/05, Paul Koning <[EMAIL PROTECTED]> wrote:
>> It sounds like the workaround is to avoid memcpy, and just use
>> variable assignment. Alternatively, cast the pointe
> "Richard" == Richard Henderson <[EMAIL PROTECTED]> writes:
>> > No it is not, once you take the address (which should be
>> rejected), it > is of type "unsigned int *" and not unaligned
>> variable, passing it to > memcpy assumes the type alignment is the
>> natural alignment.
>>
>> T
> "Mike" == Mike Stump <[EMAIL PROTECTED]> writes:
Mike> On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
>> We had a situation come up here where things are like this
>> (simplified, obviously):
>>
>> c() { char x[100]; }
Mike> I think we should turn off inlining for functions
Two things I'm wondering about:
1. Why do _builtin_ia32_paddusb and similar functions take signed
vector arguments, when the hardware primitive is defined to operate
on unsigned vectors?
2. Why are there no sse equivalents of those functions, ones that
operate on 128 bit values (i.e., pa
>>>>> "Richard" == Richard Henderson <[EMAIL PROTECTED]> writes:
Richard> On Tue, Aug 23, 2005 at 04:32:42PM -0400, Paul Koning wrote:
>> 1. Why do _builtin_ia32_paddusb and similar functions take signed
>> vector arguments, when the hardware p
> "Jonathan" == Jonathan Day <[EMAIL PROTECTED]> writes:
Jonathan> Hi, I am trying to compile a toolchain for a Broadcom SB1
Jonathan> processor in big-endian mode with a host Operating System
Jonathan> of Linux. (The SB1 is a MIPS64, but there is also a
Jonathan> specific SB1 target.) So
> "Mike" == Mike Stump <[EMAIL PROTECTED]> writes:
Mike> On Sep 6, 2005, at 6:16 PM, Gabriel Dos Reis wrote:
>> wrong-code generation that was fixed.
Mike> Customers validate their app and are `happy' with the code
Mike> generation, so this appears to not be a real an issue. Failure
Mik
> "shreyas" == shreyas krishnan <[EMAIL PROTECTED]> writes:
shreyas> Hi , I am looking for an efficient data structure to map
shreyas> from a range of addresses to a single address. As it is
shreyas> used at runtime, I want it to be as efficient as possible,
shreyas> with perhaps updaing
> On Aug 31, 2018, at 11:41 AM, Matthew Malcomson
> wrote:
>
> Hi there,
>
> I'm looking into whether it's possible to require even numbered registers on
> modes that need more than one hard-register to represent them. But only in
> some cases.
>
> The problem is the one mentioned explicitl
> On Sep 3, 2018, at 12:10 PM, Matthew Malcomson
> wrote:
>
>>
>> I think you can use pdp11 as an example, it does two things that are similar
>> to what you're describing.
>>
>> One is that it requires SImode to go into an even regno, and indicates that
>> it uses two registers. See TAR
> On Sep 3, 2018, at 1:25 PM, Matthew Malcomson
> wrote:
>
>>>
>>> Thanks for the suggestions,
>>> I've had a look into these, and unfortunately it seems they have the same
>>> problem I've been hitting before.
>>>
>>> The use of the TARGET_HARD_REGNO_MODE_OK macro limits all uses of regis
> On Sep 4, 2018, at 12:40 PM, gérard Calliet
> wrote:
>
> (our build version is 4.7.3)
>
> Hello,
>
> I'm just a beginner in gcc. (I contributed to the rebuild of the gnat ada
> compiler (version 3.4.7) on OpenVMS last year:
> https://github.com/AdaLabs/gnat-vms).
>
> As I do love books
that correct? It seems that this is worth using for any machine where it's
desirable to avoid executing stack data.
paul
> On Aug 31, 2018, at 9:19 AM, Paul Koning wrote:
>
>
>
>> On Aug 30, 2018, at 9:02 PM, Jeff Law wrote:
>>
>> On 08/30/2018 10:5
The documentation says that argument 4 of the blkmov insn gives the alignment,
for example 4 if things are word-aligned.
It's documented that, say, the value 4 means source and destination are
multiples of 4. What isn't clear is whether the length is also a multiple of 4
in this case. In othe
> On Oct 5, 2018, at 12:21 PM, Richard Biener
> wrote:
>
> On October 5, 2018 4:17:53 PM GMT+02:00, Paul Koning
> wrote:
>> The documentation says that argument 4 of the blkmov insn gives the
>> alignment, for example 4 if things are word-aligned.
>>
I have a movmem pattern in my target that pays attention to the alignment
argument.
GCC isn't passing in the expected alignment part of the time. I have this test
case:
extern int *i, *j;
extern int iv[40], jv[40];
void f1(void)
{
__builtin_memcpy (i, j, 32);
}
void f2(void)
{
__buil
> On Oct 8, 2018, at 11:09 AM, Richard Biener
> wrote:
>
> On Mon, Oct 8, 2018 at 3:57 PM Paul Koning wrote:
>>
>> I have a movmem pattern in my target that pays attention to the alignment
>> argument.
>>
>> GCC isn't passing in the ex
> On Oct 8, 2018, at 1:29 PM, Andrew Haley wrote:
>
> On 10/08/2018 06:20 PM, Michael Matz wrote:
>> Only if you somewhere visibly add accesses to *i and *j. Without them you
>> only have the "accesses" via memcpy, and as Richi says, those don't imply
>> any alignment requirements. The i a
> On Oct 8, 2018, at 5:43 PM, Eric Botcazou wrote:
>
>> That's correct, I was explaining from the middle-end perspective. There
>> we are consciously more lenient as we have to support the real world and
>> other languages than C. This is one of the cases.
>
> This had worked as Paul expect
I'm trying to build the current code on Linux with GCC 4.3.2 (stock compiler in
Fedora 10 which is my old test system). It fails like this:
In file included from
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/tree-data-ref.h:27,
from
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/gimple-loo
> On Jul 17, 2018, at 9:36 AM, Richard Biener
> wrote:
>
> On Tue, Jul 17, 2018 at 3:08 PM Paul Koning wrote:
>>
>>
>>> On Jul 17, 2018, at 5:46 AM, Richard Biener
>>> wrote:
>>>
>>>> ...
>>>
>>> There i
I have a doloop_end pattern in pdp11.md which looks like this:
(define_insn_and_split "doloop_end"
[(set (pc)
(if_then_else
(ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m")
(const_int 1))
(label_ref (match_operand 1 "" ""))
(pc)))
(set (m
> On Oct 11, 2018, at 3:11 AM, Segher Boessenkool
> wrote:
>
> Hi!
>
> On Wed, Oct 10, 2018 at 08:55:12PM -0400, Paul Koning wrote:
>
> [ snip ]
>
>> ...
>> Why is this happening, and how can I fix it (short of removing the
>> doloop_end patt
In running the gcc testsuite on pdp11, I get some failures like this:
collect2: fatal error: /Users/pkoning/Documents/svn/buildpdp/gcc/nm returned 1
exit status
compilation terminated.
compiler exited with status 1
FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O3
-fomit-frame-
> On Oct 23, 2018, at 6:08 AM, Richard Biener
> wrote:
>
> On Tue, Oct 23, 2018 at 2:39 AM Paul Koning wrote:
>>
>> In running the gcc testsuite on pdp11, I get some failures like this:
>>
>> collect2: fatal error: /Users/pkoning/Documents/svn/buildp
In my target (pdp11) which has 16 bit words, I see some test suite failures
because of unresolved references to __cmpsi2. The strange thing is that most
of the time 32 bit compares are expanded by GCC into a sequence of word
compares and branches.
Why would GCC sometimes generate library calls
I was reviewing some back end code that handles integer values of various
sizes, and got confused reading about CONST_INT and CONST_DOUBLE.
It's pretty clear that CONST_DOUBLE is used for values bigger than
HOST_WIDE_INT. But the description of INTVAL is contradictory. In some
places, it stat
I noticed an inconsistency in the handling of the aligned attribute. When
applied to variables, I get an error message if the alignment is too large for
the platform. But when applied to functions, there is no error check. The
same applies to label alignment (from the -falign-labels switch).
> On Oct 29, 2018, at 10:54 AM, Martin Sebor wrote:
>
> On 10/29/2018 07:45 AM, Paul Koning wrote:
>> I noticed an inconsistency in the handling of the aligned attribute. When
>> applied to variables, I get an error message if the alignment is too large
>>
> On Oct 29, 2018, at 10:54 AM, Martin Sebor wrote:
>
> On 10/29/2018 07:45 AM, Paul Koning wrote:
>> I noticed an inconsistency in the handling of the aligned attribute. When
>> applied to variables, I get an error message if the alignment is too large
>>
> On Oct 29, 2018, at 11:18 AM, Paul Koning wrote:
>
> ...
>
>> That said, attribute problems aren't handled perfectly consistently
>> in GCC. Some result in errors, others in warnings, and some are
>> silently ignored. I've been tracking the prob
> On Oct 29, 2018, at 4:08 PM, Martin Sebor wrote:
>
> On 10/29/2018 09:19 AM, Paul Koning wrote:
>>
>>
>>> On Oct 29, 2018, at 10:54 AM, Martin Sebor wrote:
>>>
>>> On 10/29/2018 07:45 AM, Paul Koning wrote:
>>>> I noticed an i
I noticed a curious inconsistency.
Some testcases (like gcc.dg/Wrestrict-4.c) have declarations like this:
void *alloca();
void* memcpy ();
Those don't generate warnings in a just built V9.0 gcc for x86. And the
testcase clearly doesn't expect warnings.
But I do get a warning (warning: confli
I see some test cases that say dg-add-options ieee. That apparently means:
pretend we have IEEE float even when the target does not.
What is the point of doing that? On non-IEEE targets such test cases fail --
at least they do on pdp11. Instead I'd expect a check that skips these tests
if no
1 - 100 of 363 matches
Mail list logo
