> ../../gcc-boehm-custom-marking/gcc/value-prof.h:48: syntax error,
> unexpected '*', expecting ')'
>
> What should I do about it?
>
Have to typedef the pointer due to gengtype silliness, IIRC.
IE typedef struct histogram_value_t *histogram_value_t_p;
then use histogram_value_t_p in the structu
I was told in January that the "comparison is always true due to
limited range of data type" warning has been guarded by -Walways-true
in gcc-4.2.0. But it's still issued unconditionally in
gcc-4.2.0-0.20060806r115974.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^
Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
> So, I guess my inclination would be to just write out the type
> information now, and thereby avoid the dependency on fixing GIMPLE.
>
Please don't take this the wrong way, but this approach is the reason
GIMPLE is not flat/tupelized, not type con
On Sat, Aug 12, 2006 at 02:53:47PM -0400, John David Anglin wrote:
> > In order to build gcc 4.1.1 on HP-UX 10.20 I had to install GNU awk
> > and also configure with --disable-threads. The vendor's awk did not
> > build the options.h file correctly; the exact symptom was duplicated
> > OPT_d and
Daniel Berlin wrote on 08/14/06 09:04:
> If this is a cleanup we actually want done, IMHO, we should do it first.
>
Agreed. This is a good opportunity for us to design a GIMPLE type
system. Besides the obvious space savings and cleanliness, it is also
needed to remove lang_hooks.types_compatibl
Daniel Berlin wrote:
> Mark Mitchell wrote:
>> Kenneth Zadeck wrote:
>>
>> So, I guess my inclination would be to just write out the type
>> information now, and thereby avoid the dependency on fixing GIMPLE.
> Please don't take this the wrong way, but this approach is the reason
> GIMPLE is not f
Diego Novillo wrote:
> If we had a GIMPLE type-system, we could allow the implicit type
> conversions.
Right, I was trying to make this point earlier, but not being clear. It
doesn't matter if every last conversion is explicit, as long as there
are clear rules about where conversions may be impl
"Laurynas Biveinis" <[EMAIL PROTECTED]> writes:
> > > ../../gcc-boehm-custom-marking/gcc/value-prof.h:48: syntax error,
> > > unexpected '*', expecting ')'
> > >
> > > What should I do about it?
> > >
> >
> > Have to typedef the pointer due to gengtype silliness, IIRC.
> >
> > IE typedef struct hi
This is gcc-4.2.0-0.20060806r115974
Source:
--
typedef struct descr *descr_t;
typedef descr_t *value_t;
struct descr {descr_t descr;};
typedef struct {descr_t descr; value_t fields[2];} object_t_2;
value_t **marked_top, **marked_
> > Regarding the use of pthreads, that's strange. Without --disable-threads,
> > GCC should use DCE threads on hpux10. GCC definitely knows about the
> > threads available in HP-UX 10. See for example, gthr-dce.h.
>
> I have GNU pth installed in /usr/local, and (according to gcc/config.log)
>
On Mon, Aug 14, 2006 at 08:37:41AM +0200, Paolo Bonzini wrote:
> But isn't reg 32 dead, because it is only set by insn 98:
>
> (insn 98 96 101 9 (set (reg/v:HI 32 [ size ])
> (reg:HI 43)) 33 {movhi} (insn_list:REG_DEP_TRUE 96 (nil))
> (nil))
>
> after copyprop?
No, because insn 96,
>
> This is gcc-4.2.0-0.20060806r115974
Can you submit a real bug report to http://gcc.gnu.org/bugzilla
as mentioned on http://gcc.gnu.org/bugs.html?
Thanks,
Andrew Pinski
On Aug 11, 2006, at 4:21 AM, kees de jong wrote:
When I changed the program to use openmp and compiled it
with the new -fopenmp switch, everything went fine.
But what amazed me, on running this program it only used
6 seconds to complete the multiplication!
Glad to hear it and thanks for the fee
DJ Delorie wrote:
>> And back to my original answer: it's up to each language to decide
>> that.
>
> Hence my original question: is it legal or not? What did the C++
> developers decide?
The C++ standard implies that for all pointer-to-object types have the
same size and that all pointer-to-func
kees de jong wrote on 08/11/06 07:21:
> If you want to look at the program concerned, please
> let me know that. I can than make some small
> alterations (it is a little bit interactive, using the
> Dutch language) and send it to you.
>
Thanks for the feedback. As long as your code is not doing
Hi,
On Mon, 14 Aug 2006, Mark Mitchell wrote:
> pressure build on some set of infrastructure until it has been painfully
> obvious for some amount of time that it has to change. (In my
> experience, the same thing happens in developing proprietary software;
> convincing product management to let
> Diego Novillo writes:
Diego> Agreed. This is a good opportunity for us to design a GIMPLE type
Diego> system. Besides the obvious space savings and cleanliness, it is also
Diego> needed to remove lang_hooks.types_compatible_p.
And this last statement is the key point. We can and
Michael Matz wrote:
>> pressure build on some set of infrastructure until it has been painfully
>> obvious for some amount of time that it has to change. (In my
>> experience, the same thing happens in developing proprietary software;
>> convincing product management to let you spend significant
Dear all,
Wtraditional warns for "Conversions by prototypes between
fixed/floating point values and vice versa. The absence
of these prototypes when compiling with traditional C would cause
serious problems. "
In addition, the following program:
void ffloat(float x);
void h(void
David Edelsohn wrote:
>> Diego Novillo writes:
>>
>
> Diego> Agreed. This is a good opportunity for us to design a GIMPLE type
> Diego> system. Besides the obvious space savings and cleanliness, it is also
> Diego> needed to remove lang_hooks.types_compatible_p.
>
> And
On Aug 14, 2006, at 9:52 AM, Michael Matz wrote:
How true :) Nevertheless the goals for the FSF GCC should IMHO be
purely based on rather technical arguments and considerations, not
the drive by paying customers.
:-) I'd of course argue that a compiler with no customers (I'd use
the term
> The C++ standard implies that for all pointer-to-object types have the
> same size and that all pointer-to-function types have the same size.
> (Technically, it doesn't say that that; it says that you can convert T*
> -> U* -> T* and get the original value.)
Then they don't need to be the same
Apologies for the previous incomplete reply. Here's the rest of the
comments I had for this patch.
> + @itemize
> + @item @code{flow_loops_dump}: Dumps the information about loops to file.
^^^
Andrew Pinski <[EMAIL PROTECTED]> writes:
>> This is gcc-4.2.0-0.20060806r115974
>
> Can you submit a real bug report to http://gcc.gnu.org/bugzilla
> as mentioned on http://gcc.gnu.org/bugs.html?
Done; http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28727
--
__("< Marcin Kowalczyk
\_
Mark Mitchell <[EMAIL PROTECTED]> writes:
| DJ Delorie wrote:
| >> And back to my original answer: it's up to each language to decide
| >> that.
| >
| > Hence my original question: is it legal or not? What did the C++
| > developers decide?
|
| The C++ standard implies that for all pointer-to-o
> However, the C++ definition has been amended at the last Lillehammer
> meeting to allow that cast as "conditionally supported": either it is
> valid or it errors out. the compiler has to tell.
Also, the mechanism to create multiple pointer sizes
(attribute((mode))) is a GCC extension. Hence,
On Sun, Aug 13, 2006 at 10:16:02PM +0200, Rask Ingemann Lambertsen wrote:
> Note that right after expand, we have:
>
> (note 91 90 0 NOTE_INSN_BASIC_BLOCK)
>
> ;; size = size - 1
> (insn 93 91 96 (set (reg:HI 42)
> (const_int -1 [0x])) -1 (nil)
> (nil))
>
> (insn 96 93 97 (p
Jeff wrote:
I added fprintf (asm_out_file, "\tnop\n"); to the end of case
CODE_LABEL. Then I recompile the gcc. Unfortunately, it doesn't seem
that a NOP was inserted. Any ideaes?
What testcase did you try? Not every basic block starts with a label.
Only basic blocks that are the target of
Drgt <[EMAIL PROTECTED]> writes:
> It seems, that "#pragma once" isn't in ISO, and will never be, especially
> because it is Microsoft (am I right ?) C extension.
> (http://gcc.gnu.org/ml/gcc/2004-06/msg01887.html)
I believe that gcc was actually the first compiler to implement
"#pragma once". I
On Mon, Aug 14, 2006 at 06:30:26PM +0100, Manuel López-Ibáñez wrote:
> Dear all,
>
> Wtraditional warns for "Conversions by prototypes between
> fixed/floating point values and vice versa. The absence
> of these prototypes when compiling with traditional C would cause
> serious prob
Hello!
I've been bitten by a bug in some software I use every day (I didn't
write it, but it's a part of. When compiling it with gcc-4.1.1, I'm
getting tons of warnings, and the bug was triggering a warning too, I
think it should have been an error.
It's the case where the return value of an und
On Mon, Aug 14, 2006 at 12:45:55PM -0700, Janis Johnson wrote:
> On Mon, Aug 14, 2006 at 06:30:26PM +0100, Manuel López-Ibáñez wrote:
> > 3) The above question may not have a sensible answer. It may be either
> > because decimal float "is a GCC extensions and thus not relevant to
> > traditional C
DJ Delorie wrote:
>> However, the C++ definition has been amended at the last Lillehammer
>> meeting to allow that cast as "conditionally supported": either it is
>> valid or it errors out. the compiler has to tell.
>
> Also, the mechanism to create multiple pointer sizes
> (attribute((mode))) is
Pavel Roskin <[EMAIL PROTECTED]> writes:
> I don't know much about gcc implementation, but if it's not hard to
> check the context of the function call (or, alternatively, the
> provenance of the integer that is about to be cast to a pointer), I'll
> appreciate if this case is promoted to an error
>
> DJ Delorie wrote:
> >> However, the C++ definition has been amended at the last Lillehammer
> >> meeting to allow that cast as "conditionally supported": either it is
> >> valid or it errors out. the compiler has to tell.
> >
> > Also, the mechanism to create multiple pointer sizes
> > (attr
Andrew Pinski wrote:
> Aren't there some targets (like ia64-hpux) that support two different
> sizes of pointers
Those are entirely separate ABIs, controlled by a command-line option.
There are not multiple pointer sizes within any single program.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
> I'm very suspicious of allowing users to specify this via attributes.
Me too, but that's what extensions are all about. You never know what
the user is going to need to do.
The M16C is an example - it has a 16 bit pointer, but has a few
special opcodes for using a 32 bit pointer to access add
> Aren't there some targets (like ia64-hpux) that support two different
> sizes of pointers,
Heck, the i386 has ALWAYS supported multiple pointer sizes (16, 16+16,
32, and 32+16). We've just refused to pay the (high) price for
supporting them.
On 14/08/06, Janis Johnson <[EMAIL PROTECTED]> wrote:
It makes sense to have warnings about calls where default argument
promotions would have made a difference, but not for the calls in
gcc.dg/dfp/Wconversion-2.c.
But there are no default promotions for decimal float, as you say in
your previ
> "Dan" == Daniel Berlin <[EMAIL PROTECTED]> writes:
Dan> I do not *fault* Diego (and others) for the decision to get a
Dan> prototype of GIMPLE/tree-ssa first, and clean it up later.
FWIW my experience writing a front end was that trees remain weird to
work with -- sometimes fixing type comp
Hi,
GNU Classpath 0.92 was released last week. It contains a lot of new
standard library classes and bug fixes. See
http://savannah.gnu.org/forum/forum.php?forum_id=4573
And the list of fixed bugs:
http://gcc.gnu.org/bugzilla/buglist.cgi?product=classpath&target_milestone=0.92
This version has be
DJ Delorie wrote:
>> I'm very suspicious of allowing users to specify this via attributes.
>
> Me too, but that's what extensions are all about. You never know what
> the user is going to need to do.
Sorry, but I think that's far too casual. The long history of GCC
extensions causing various ki
On Mon, 2006-08-14 at 22:44 +0200, Andreas Schwab wrote:
> Pavel Roskin <[EMAIL PROTECTED]> writes:
>
> > I don't know much about gcc implementation, but if it's not hard to
> > check the context of the function call (or, alternatively, the
> > provenance of the integer that is about to be cast to
"Laurynas Biveinis" <[EMAIL PROTECTED]> writes:
> After my best effor so far:
>
> struct histogram_value_t GTY(())
> {
> struct
> {/* <--- line 48, error below occurs here */
> tree value; /* The value to profile. */
> tree stmt;
> Well, I think it's in direct conflict with the C++ standard. If "X" is
> a 32-bit pointer type, and "x" is a value of type X, "Y" is a 16-bit
> pointer type, then:
>
> (X*)(Y*)x
>
> is supposed to get you back the value of "x", but I don't see how that
> can work, in general.
Where in the
Kenneth Zadeck wrote:
> I am modifying my code so that their is a preprocessor flag,
> STUPID_TYPE_SYSTEM that either writes or does not write the redundant
> type nodes.
I think the macro name is needlessly negative, but I think the idea is
fine. Could we just say something like EXPLICIT_TYPE_
DJ Delorie wrote:
>> Well, I think it's in direct conflict with the C++ standard. If "X" is
>> a 32-bit pointer type, and "x" is a value of type X, "Y" is a 16-bit
>> pointer type, then:
>>
>> (X*)(Y*)x
>>
>> is supposed to get you back the value of "x", but I don't see how that
>> can work, in
Gentle People?
I am currently running gcc 3.1 on both my Ultra 5
Solaris 8 Sparc machine and on Solaris 8 Intel machine.
The Application C source code that compiles and executes
perfectly on the Ultra 5 will not compile on the Intel machine!
The compilation errors, shown below, seem to relate to
> The "except that" sentence implies the statement above, assuming
> that the pointed-to type does not have stricter alignment. So, if
> casting a 32-bit pointer to int to a 16-bit pointer to char and back
> does not always yield the same value, then something has to give.
reinterpret_cast doesn
On Aug 14, 2006, at 6:29 PM, Thomas Dineen wrote:
Gentle People?
Wow, someone's been spreading false accusations about us. :-)
I am currently running gcc 3.1 on both my Ultra 5
Solaris 8 Sparc machine and on Solaris 8 Intel machine.
The Application C source code that compiles and executes
pe
On Aug 14, 2006, at 7:09 PM, [EMAIL PROTECTED] wrote:
We have porting our S+core 32b CPU gcc backend for gcc-4.1.1, and have
finished applying process in FSF,
but how can i add our backend code into gcc package?
Please see http://gcc.gnu.org/contribute.html in general.
You'd need to file an as
> I'm very suspicious of allowing users to specify this via attributes.
> Having pointers-to-objects or pointers-to-functions with different sizes
> (within one of those classes) seems problematic, but perhaps you can say
> more about how you expect this to work in the presence of conversions
> and
DJ Delorie wrote:
>> The "except that" sentence implies the statement above, assuming
>> that the pointed-to type does not have stricter alignment. So, if
>> casting a 32-bit pointer to int to a 16-bit pointer to char and back
>> does not always yield the same value, then something has to give.
>
Richard Kenner wrote:
>> I'm very suspicious of allowing users to specify this via attributes.
>> Having pointers-to-objects or pointers-to-functions with different sizes
>> (within one of those classes) seems problematic, but perhaps you can say
>> more about how you expect this to work in the pre
> The confusion is perhaps that you're thinking that my statement that we
> need to specify the semantics is clearly implies that I don't think it's
> a useful feature? I do think it's a useful feature, but I also think
> that you can't just drop it into C++ without thinking about all the
> conseq
> > reinterpret_cast doesn't require that the intermediate form have the
> > same bit pattern.
>
> Exactly so. However, all valid pointers must be handles, so unless the
> 32-bit address space is "sparse", something will go wrong.
I would go so far as to say that it's defined (hence supported)
DJ Delorie wrote:
>>> reinterpret_cast doesn't require that the intermediate form have the
>>> same bit pattern.
>> Exactly so. However, all valid pointers must be handles, so unless the
>> 32-bit address space is "sparse", something will go wrong.
I didn't help things here by saying "handles"; I
57 matches
Mail list logo
