On Apr 29, 2009, at 9:58 PM, Jack Howarth wrote:
Does anyone understand why Apple's gcc-4.2 compiler in
Xcode 3.1.2 accepts the following code...
typedef const struct __CFString * CFStringRef;
typedef struct __CFBundle *CFBundleRef;
extern
CFStringRef CFBundleCopyLocalizedString(CFBundleRef
Does anyone understand why Apple's gcc-4.2 compiler in
Xcode 3.1.2 accepts the following code...
typedef const struct __CFString * CFStringRef;
typedef struct __CFBundle *CFBundleRef;
extern
CFStringRef CFBundleCopyLocalizedString(CFBundleRef bundle, CFStringRef key,
CFStringRef value, CFStri
On Wed, Apr 29, 2009 at 6:19 PM, Steven Bosscher wrote:
> On Thu, Apr 30, 2009 at 12:15 AM, Richard Guenther
> wrote:
>> Well, the challenge is to retain the per SSA name information across
>> Graphite. At some point we need to stop re-computing points-to
>> information because we cannot do so w
Esben Mose Hansen writes:
> this program SEGFAULTs
>
> #include
>
> int main() {
> int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
> const std::size_t nn = sizeof(numbers)/sizeof(int);
> int sum = 0;
> int f = 5;
> std::for_each(&numbers[0], &numbers[nn], [&] (int n) {
> sum +=
Michael Hope wrote:
HI there. I'm working on porting gcc to a new architecture which only
does indirect addressing - there is no indirect with displacement.
The IA-64 target also has only indirect addressing. Well, it has some
auto-increment addressing modes too, but that isn't relevant here
On Wednesday 29 April 2009 12:47:04 Joern Rennecke wrote:
Something which I miss in C++ is a way to declare that a function uses
an integral type to pass an enum value (in arguments or return value),
and then at function definition time only check that the integral type
is sufficently large to ho
On Wed, 2009-04-29 at 08:56 -0500, Tom Browder wrote:
> Attached is a shortened test report with the following lines removed:
>
> XFAIL
> PASS
> UNSUPPORTED
The preferred way to post test results is by running the script
$SRC/contrib/test_summary from within the build directory. It
produces a su
On Thu, Apr 30, 2009 at 12:15 AM, Richard Guenther
wrote:
> Well, the challenge is to retain the per SSA name information across
> Graphite. At some point we need to stop re-computing points-to
> information because we cannot do so with retaining IPA results.
Not to mention the compile time pain
On Thu, Apr 30, 2009 at 12:06 AM, Tobias Grosser
wrote:
> On Wed, 2009-04-29 at 23:57 +0200, Richard Guenther wrote:
>> On Wed, Apr 29, 2009 at 11:34 PM, Tobias Grosser
>> wrote:
>> > Hi gcc developers, hi graphities
>> >
>> > here are some notes from our weekly phone call. Unfortunately I missed
On Wed, Apr 29, 2009 at 16:57, Richard Guenther
wrote:
>>
>> * Reductions: Diego OK with going out of SSA.
>
> You will loose all points-to information. I think going out of SSA is
> a very bad idea.
>
There is no loss of information: we go out of SSA only for scalar phi
nodes that cannot b
On Wed, 2009-04-29 at 23:57 +0200, Richard Guenther wrote:
> On Wed, Apr 29, 2009 at 11:34 PM, Tobias Grosser
> wrote:
> > Hi gcc developers, hi graphities
> >
> > here are some notes from our weekly phone call. Unfortunately I missed
> > to send out the notes from the last two phone calls, but I
On Wed, Apr 29, 2009 at 11:34 PM, Tobias Grosser
wrote:
> Hi gcc developers, hi graphities
>
> here are some notes from our weekly phone call. Unfortunately I missed
> to send out the notes from the last two phone calls, but I hope to get
> them out more regulary. Believe in me! ;-)
>
> http://gcc
Hi gcc developers, hi graphities
here are some notes from our weekly phone call. Unfortunately I missed
to send out the notes from the last two phone calls, but I hope to get
them out more regulary. Believe in me! ;-)
http://gcc.gnu.org/wiki/Graphite_Phone_Call/2009_04_29
Attendees: Li, Jan, Kon
I have updated
http://gcc.gnu.org/wiki/SvnBranch
with information on how to use svn 1.5.0 to maintain branches.
Please review, comment, edit etc. - especially in the places marked
"untested" :)
Thanks,
--
Laurynas
Hi,
this program SEGFAULTs
#include
int main() {
int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
const std::size_t nn = sizeof(numbers)/sizeof(int);
int sum = 0;
int f = 5;
std::for_each(&numbers[0], &numbers[nn], [&] (int n) {
sum += n * f;
});
}
Now, my assembly days are
On Wednesday 29 April 2009 12:47:04 Joern Rennecke wrote:
> Something which I miss in C++ is a way to declare that a function uses
> an integral type to pass an enum value (in arguments or return value),
> and then at function definition time only check that the integral type
> is sufficently large
Quoting "Joseph S. Myers" :
I think the cleanups involved in using the target vector / class more, and
other cleanups involved in the natural approach to multi-target GCC of
which the target vector is a part, are more useful than the end result
(for which compiling large parts of the compiler mul
Quoting Ian Lance Taylor :
I'm not sure why you are singling me out.
You seemed to be actively working on the branch, and the c++ enum type
checks provide a motivation to make changes. Also, this issue should
be considered in general when people change their coding habits in order
for the cod
On Wed, 29 Apr 2009, Joseph S. Myers wrote:
> On Wed, 29 Apr 2009, Richard Earnshaw wrote:
>
> If you are building a non-C front end without bootstrapping you need at
> least 2.95:
>
> To build all languages in a cross-compiler or other configuration where
> 3-stage bootstrap is not perfor
2009/4/29 Joseph S. Myers :
> On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
>
>> 2009/4/29 Joseph S. Myers :
>> > On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
>> >
>> >> >> BTW, why is this warned about?
>> >> >
>> >> > I imagine because in C it is not conventional to use "extern" when
>> >> >
On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
> 2009/4/29 Joseph S. Myers :
> > On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
> >
> >> >> BTW, why is this warned about?
> >> >
> >> > I imagine because in C it is not conventional to use "extern" when
> >> > defining something, only on a declara
On Wed, Apr 29, 2009 at 9:29 AM, Dennis Clarke wrote:
>
>> Attached is a shortened test report with the following lines removed:
>>
>
> excellent, now we have a benchmark/comparison to look at. Well done,
> excellent work.
>
> What did you use to build libgmp and mpfr ? I am curious because most
>
2009/4/29 Joseph S. Myers :
> On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
>
>> >> BTW, why is this warned about?
>> >
>> > I imagine because in C it is not conventional to use "extern" when
>> > defining something, only on a declaration that is not a definition.
>>
>> But may it lead to some co
On Wed, 29 Apr 2009, Ian Lance Taylor wrote:
> (I'm not personally convinced that a multi-targeted gcc is particularly
> useful, though I don't object if there is a general desire to support
> it.)
I think the cleanups involved in using the target vector / class more, and
other cleanups involved
On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
> >> BTW, why is this warned about?
> >
> > I imagine because in C it is not conventional to use "extern" when
> > defining something, only on a declaration that is not a definition.
>
> But may it lead to some confusion or subtle error? It seems ov
Manuel López-Ibáñez writes:
> 2009/4/29 Sebastian Redl :
>> So MSC will warn about this construct, but GCC will not, due to its
>> whitespace rule:
>
> I think we should just remove the whitespace rule and implement the
> warning in C.
Actually it appears that the whitespace rule was already rem
Michael Hope writes:
> HI there. I'm working on porting gcc to a new architecture which only
> does indirect addressing - there is no indirect with displacement.
>
> The problem is with spill locations in GCC 4.4.0. The elimination
> code correctly elimates the frame and args pointer and replac
> Attached is a shortened test report with the following lines removed:
>
excellent, now we have a benchmark/comparison to look at. Well done,
excellent work.
What did you use to build libgmp and mpfr ? I am curious because most
people that try wwith Sun Studio Express or Sun Studio 12 fail pret
Joern Rennecke writes:
> I've found some issues with gcc-in-cxx both specific to these
> targets, and specific to (parts of) compiler passes that are
> only compiled for a subset of all tagets, which include one or
> more of the above mentioned three.
I'd be happy to see and approve your patches
Richard Guenther writes:
>> * The C++ frontend emits some warnings on code which is known to be
>> never executed, which the C frontend does not. This leads to some
>> warnings compiling code in gcc. I think it is reasonable to fix this
>> in the C++ frontend.
>
> Or just amend the C fronten
2009/4/29 Sebastian Redl :
> So MSC will warn about this construct, but GCC will not, due to its
> whitespace rule:
I think we should just remove the whitespace rule and implement the
warning in C.
Cheers,
Manuel.
Joseph S. Myers wrote:
> On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
>
>
>> 2009/4/29 Joseph S. Myers :
>>
>>> On Wed, 29 Apr 2009, Ian Lance Taylor wrote:
>>>
>>>
* The C++ frontend warns about "while (true);" when there is no
whitespace between the ')' and the ';'.
2009/4/29 Joseph S. Myers :
> On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
>
> I don't know the rationale for this warning. Is it to do with the C++0x
> specification that certain loops may be assumed to terminate?
I guess the rationale is that there is little use for while(true) ;
so it is pr
On Wed, 29 Apr 2009, Richard Earnshaw wrote:
> > The question is not just one for bootstrapping a native compiler but also
> > one of what compiler can be used to build a cross compiler (such as that
> > with multiple targets), which is not bootstrapped in the usual GCC sense.
> > There we pre
On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
> 2009/4/29 Joseph S. Myers :
> > On Wed, 29 Apr 2009, Ian Lance Taylor wrote:
> >
> >> * The C++ frontend warns about "while (true);" when there is no
> >> whitespace between the ')' and the ';'. The C frontend does not. I'm
> >> not sure how
On Wed, 2009-04-29 at 13:21 +, Joseph S. Myers wrote:
> On Wed, 29 Apr 2009, Joern Rennecke wrote:
>
> > Quoting "Joseph S. Myers" :
> >
> > > On Wed, 29 Apr 2009, Joern Rennecke wrote:
> > >
> > > > What are your thoughts on using gcc extensions for gcc-in-cxx ?
> > >
> > > I believe we ag
On Wed, 29 Apr 2009, Joern Rennecke wrote:
> Quoting "Joseph S. Myers" :
>
> > On Wed, 29 Apr 2009, Joern Rennecke wrote:
> >
> > > What are your thoughts on using gcc extensions for gcc-in-cxx ?
> >
> > I believe we agreed in a previous discussion to aim for building with the
> > intersection
2009/4/29 Joseph S. Myers :
> On Wed, 29 Apr 2009, Ian Lance Taylor wrote:
>
>> * The C++ frontend warns about "while (true);" when there is no
>> whitespace between the ')' and the ';'. The C frontend does not. I'm
>> not sure how to best handle this. It doesn't make much sense to warn
>>
Quoting "Joseph S. Myers" :
On Wed, 29 Apr 2009, Joern Rennecke wrote:
What are your thoughts on using gcc extensions for gcc-in-cxx ?
I believe we agreed in a previous discussion to aim for building with the
intersection of C++98/C++03 and C++ as supported by GCC 3.4 (including
making sure
On Wed, 29 Apr 2009, Joern Rennecke wrote:
> What are your thoughts on using gcc extensions for gcc-in-cxx ?
I believe we agreed in a previous discussion to aim for building with the
intersection of C++98/C++03 and C++ as supported by GCC 3.4 (including
making sure at an appropriate point that
On Wed, 29 Apr 2009, Ian Lance Taylor wrote:
> * The C++ frontend warns about "while (true);" when there is no
> whitespace between the ')' and the ';'. The C frontend does not. I'm
> not sure how to best handle this. It doesn't make much sense to warn
> about this with -Wc++-compat. Sho
In order to be able to use namespaces in my endeavour to
support gcc with multiple targets, I've first done a merge
from the gcc-in-cxx branch.
For my initial implementation, I choose as configuration
--target=m32r-elf --with-extra-target-list='sh64-elf arc-elf32' .
I've found some issues with g
HI there. I'm working on porting gcc to a new architecture which only
does indirect addressing - there is no indirect with displacement.
The problem is with spill locations in GCC 4.4.0. The elimination
code correctly elimates the frame and args pointer and replaces it
with register X. The prob
On Tue, 2009-04-28 at 14:52 -0700, Doug Kwan (關振德) wrote:
> I would like to run the testsuite using qemu as the gdb simulator does
> not support newer ARMs. However, there does not seems to be any good
> documents on that topic. Could someone give me a pointer or two?
At least on a linux system,
On Wed, Apr 29, 2009 at 9:39 AM, Ian Lance Taylor wrote:
> I've finished my set of patches which fix -Wc++-compat to check for enum
> conversions which are valid in C++. Adding those checks forced a lot of
> changes in mainline to compile cleanly with -Wc++-compat. I have merged
> those changes
I've finished my set of patches which fix -Wc++-compat to check for enum
conversions which are valid in C++. Adding those checks forced a lot of
changes in mainline to compile cleanly with -Wc++-compat. I have merged
those changes over to the gcc-in-cxx branch. In the gcc directory
itself, exclu
46 matches
Mail list logo
