Suggestion: We should make sure we can accommodate F2003 with
4.2 and 4.3 by increasing the possible number of flags as needed.
I'm in favour of that, and I already started writing the necessary
patch. But it looks like we'll have to bump the so number a last
time, for 4.3, and then make th
Gaby says:
> I believe we do care for good diagnostic purposes.
Yes. Diagnostics are very important. Please let's not regress on this
point. In a perfect world we'd get the diagnostic advantages of
concepts with the ability to configure typedefs.
Mike says:
> As for warning/error messages, I'd
How can I get a full list of all GCC C++ built-in functions that may be
used on a given platform or GCC build?
For example, __cxa_begin_catch(), __cxa_end_catch(), __builtin_memset ...
I am currently working with GCC 4.0.1 source base.
Thanks,
Brendon.
Hello Basile,
* Basile STARYNKEVITCH wrote on Tue, Nov 07, 2006 at 11:19:16PM CET:
>
> http://gcc.gnu.org/wiki/AboutGCCConfiguration
>
> I borrowed a few sentences elsewhere, in particular from the autobook
> http://sources.redhat.com/autobook/ by Gary V. Vaughan, Ben Elliston,
> Tom Tromey and
I entirely agree. There definitely should be a PR for this, if there isn't
already.
dorit
"Michael James" <[EMAIL PROTECTED]> wrote on 05/11/2006 22:03:47:
> Hello Dorit,
>
> Thank you for the list of references.
>
> What I gathered from reading this is that alignment attributes applied
> to th
> My conclusion at the end was, the best speed up possible, isn't to
> mess with the callers, but rather, to get types canonicalized, then
> all the work that comptypes would normally do, hopefully, just all
> goes away. Though, in the long run those quadratic algorithms have to
> one day
Hi,
Bug #28468 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28468)
causes a crash of nearly every valid program that parallelizes a loop
through OMP when OMP_NUM_THREADS > 1.
The affected systems are probably all Linux/x86 systems on which a glibc
with LinuxThreads and without TLS is installed, a
Benjamin Kosnik <[EMAIL PROTECTED]> writes:
[...]
| My suggestion, which I've not seen here before, is to allow end-users
| to configure this. I see the need for both kinds of behavior: people
| who want to see the "real type" of the thing that they are using, and
| people who need "shorthands" t
On Tue, 7 Nov 2006, Mike Stump wrote:
> On Nov 7, 2006, at 3:48 PM, Kaveh R. GHAZI wrote:
> > Perhaps we could take a second look at this decision? The average
> > system has increased in speed many times since then. (Although
> > sometimes I feel like bootstrapping time has increased at an even
Hi all,
I have used cbranchmode4 instruction to generate combined compare and
branch instruction.
(define_insn "cbranchmode4"
(set (pc) (if_then_else
(match_operator:CC 0 "comparison_operator"
[ (match_operand:SI 1 "register_operand" "r,r")
(match_o
On Tue, 7 Nov 2006, Mark Mitchell wrote:
> > I object.
>
> Me too.
>
> I'm a big proponent of testing, but I do think there should be some
> bang/buck tradeoff. (For example, we have tests in the GCC testsuite
> that take several minutes to run -- but never fail. I doubt these tests
> are ac
On 11/8/06, Mike Stump <[EMAIL PROTECTED]> wrote:
On Nov 7, 2006, at 7:13 PM, Doug Gregor wrote:
> Now, how much do we worry about the fact that we won't be printing
> typedef names
The only potential language gotcha I can think of is:
5 If the typedef declaration defines an unnamed class (or
"Rohit Arul Raj" <[EMAIL PROTECTED]> writes:
> I have used cbranchmode4 instruction to generate combined compare and
> branch instruction.
>
> (define_insn "cbranchmode4"
> (set (pc) (if_then_else
> (match_operator:CC 0 "comparison_operator"
> [ (match_operand:SI 1
[EMAIL PROTECTED] (Richard Kenner) writes:
> > My conclusion at the end was, the best speed up possible, isn't to
> > mess with the callers, but rather, to get types canonicalized, then
> > all the work that comptypes would normally do, hopefully, just all
> > goes away. Though, in the long
Paolo Bonzini wrote:
The following patch fixes it, but it's completely untested.
2006-11-07 Paolo Bonzini <[EMAIL PROTECTED]>
* gimplify.c (fold_indirect_ref_rhs): Use
STRIP_USELESS_TYPE_CONVERSION rather than STRIP_NOPS.
Index: ../../gcc/gimplify.c
=
Brendon Costa <[EMAIL PROTECTED]> writes:
> How can I get a full list of all GCC C++ built-in functions that may be
> used on a given platform or GCC build?
>
> For example, __cxa_begin_catch(), __cxa_end_catch(), __builtin_memset ...
>
> I am currently working with GCC 4.0.1 source base.
Well,
On Wed, Nov 08, 2006 at 02:33:08PM +0100, Bruno Haible wrote:
> * config/tls.m4 (GCC_CHECK_TLS): Also check whether the libc supports
> TLS via __thread.
Ok.
r~
Paolo Bonzini writes:
>
> > At a wild guess, maybe strip_useless_type_conversions() is doing
> > something Bad.
>
> Almost there. It looks like strip_useless_type_conversions is not used,
> and then something Bad happens.
>
> The following patch fixes it, but it's completely untested.
On 08 November 2006 12:25, Ralf Wildenhues wrote:
> Hello Basile,
>
> * Basile STARYNKEVITCH wrote on Tue, Nov 07, 2006 at 11:19:16PM CET:
>>
>> http://gcc.gnu.org/wiki/AboutGCCConfiguration
> If you need a [ ... ]
> The first chapter of the Automake 1.10 manual [ ... ]
> The Autobook and the
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| [EMAIL PROTECTED] (Richard Kenner) writes:
|
| > > My conclusion at the end was, the best speed up possible, isn't to
| > > mess with the callers, but rather, to get types canonicalized, then
| > > all the work that comptypes would normally do, h
"Doug Gregor" <[EMAIL PROTECTED]> writes:
| On 11/8/06, Mike Stump <[EMAIL PROTECTED]> wrote:
| > On Nov 7, 2006, at 7:13 PM, Doug Gregor wrote:
| > > Now, how much do we worry about the fact that we won't be printing
| > > typedef names
| >
| > The only potential language gotcha I can think of is
Andrew Haley <[EMAIL PROTECTED]> writes:
> > 2006-11-07 Paolo Bonzini <[EMAIL PROTECTED]>
> >
> > * gimplify.c (fold_indirect_ref_rhs): Use
> > STRIP_USELESS_TYPE_CONVERSION rather than STRIP_NOPS.
>
> Regtested x86-64-gnu-linux. The only interesting failure was
> mayali
* Ian Lance Taylor <[EMAIL PROTECTED]> [061108 16:15]:
> This assumes, of course, that we can build an equivalence set for
> types. I think that we need to make that work in the middle-end, and
> force the front-ends to conform. As someone else mentioned, there are
> horrific cases in C like a[]
"Bernhard R. Link" <[EMAIL PROTECTED]> writes:
> * Ian Lance Taylor <[EMAIL PROTECTED]> [061108 16:15]:
> > This assumes, of course, that we can build an equivalence set for
> > types. I think that we need to make that work in the middle-end, and
> > force the front-ends to conform. As someone e
* Dave Korn wrote on Wed, Nov 08, 2006 at 04:59:34PM CET:
> >> http://gcc.gnu.org/wiki/AboutGCCConfiguration
[...]
> You don't really "get" wiki, do you? ;-)
Oh, I didn't know this wiki was editable by anybody.
I mistakenly inferred from notices on other wiki pages
that there are restrictions a
On Wed, 2006-11-08 at 14:33 +0100, Bruno Haible wrote:
> Hi,
>
> 2006-11-07 Bruno Haible <[EMAIL PROTECTED]>
>
> * config/tls.m4 (GCC_CHECK_TLS): Also check whether the libc supports
> TLS via __thread.
How well does this work with cross compiler?
Thanks,
Andrew Pinski
"Bernhard R. Link" <[EMAIL PROTECTED]> writes:
| * Ian Lance Taylor <[EMAIL PROTECTED]> [061108 16:15]:
| > This assumes, of course, that we can build an equivalence set for
| > types. I think that we need to make that work in the middle-end, and
| > force the front-ends to conform. As someone e
On 08 November 2006 16:19, 'Ralf Wildenhues' wrote:
> * Dave Korn wrote on Wed, Nov 08, 2006 at 04:59:34PM CET:
http://gcc.gnu.org/wiki/AboutGCCConfiguration
> [...]
>> You don't really "get" wiki, do you? ;-)
>
> Oh, I didn't know this wiki was editable by anybody.
> I mistakenly inferre
Andrew Pinski wrote:
> > 2006-11-07 Bruno Haible <[EMAIL PROTECTED]>
> >
> > * config/tls.m4 (GCC_CHECK_TLS): Also check whether the libc supports
> > TLS via __thread.
>
> How well does this work with cross compiler?
The proposed patch changes only the ACTION-IF-TRUE argument of an
AC
On 08 November 2006 08:13, FX Coudert wrote:
>> Suggestion: We should make sure we can accommodate F2003 with
>> 4.2 and 4.3 by increasing the possible number of flags as needed.
>
> I'm in favour of that, and I already started writing the necessary
> patch. But it looks like we'll have to bump
What's the problem with just adding a new 'extended private
stuff' field to
the very end of the struct and allocating one of the remaining flag
bits to
say if it's present or not?
That requires to have a version of the library that can work without
it, and it's one more requirement on th
Thanks for the information. It was very helpful.
I have now written some code (Seperate to gcc) that makes use of the
builtins.def and associated def files to generate a list of all builtin
functions as i require with the full prototypes as would be declared in
say a header file. Are there als
Brendon Costa <[EMAIL PROTECTED]> writes:
> Are there also frontend specific
> builtins that I will need to handle in addition to those builtins
> defined in builtins.def?
No.
> As for the libsupc++.a and libgcc*.* libraries. Are they compiled with
> the newly generated gcc/g++ compilers or are
On Wed, 2006-11-08 at 21:25 -0800, Brooks Moses wrote:
> ---
> ffixed-line-length-none
> C ObjC
>
> ffixed-line-length-
> C ObjC Joined
> ---
>
> Thus, when one
There's something weird going on with Fortran's -ffixed-line-length
options, and in how the lang.opt files get processed to produce the
--help results from cc1 (and cc1plus, f951, etc.).
Specifically, the fortran/lang.opt file contains the following lines:
-
How do i determine if two type nodes in the C front end are equivilent?
In C++ i use same_type_p() but do not see an equivilant for the C front end.
Thanks,
Brendon.
On Thu, 2006-11-09 at 06:17 +, Brendon Costa wrote:
> How do i determine if two type nodes in the C front end are equivilent?
> In C++ i use same_type_p() but do not see an equivilant for the C front end.
Hi Brendon,
Wouldn't the C++ one (mostly) be a superset of the C?
Thanks,
Sohail
37 matches
Mail list logo
