Andrew Pinski <[EMAIL PROTECTED]> writes:
> I noticed this with the recent C99 inline changes but it is unrelated to
> the changes as 4.1 also has the same issue. With the following TU:
> extern void f(void) __asm__("g");
> extern void g(void);
> extern void f(void) {}
> extern void g(void) {}
>
Hi,
> I want to make sure that you are aware of the ongoing LTO effort to
> implement whole program optimization.
Yes, Sebastian volunteered to regularly sync from both mainline and the
lto-branch.
Regards,
Gwenole.
On 11/2/06, Roger Sayle <[EMAIL PROTECTED]> wrote:
Steven Bosscher might even have plans for reorganizing jump bypassing
already as part of his CSE/GCSE overhaul?
Yes, and one part of that plan is to pre-split all critical edges so
that you never have to insert on edges. That would make your p
I noticed this with the recent C99 inline changes but it is unrelated to
the changes as 4.1 also has the same issue. With the following TU:
extern void f(void) __asm__("g");
extern void g(void);
extern void f(void) {}
extern void g(void) {}
---
We don't reject this TU during compiling
On Tue, 31 Oct 2006, Dave Korn wrote:
> Tracking down a gcse bug while unrolling a loop where the count is
> known to be one, I've narrowed the problem down to the actions of
> commit_edge_insertions and bypass_conditional_jumps, and I could use
> a little help in appreciating the reasoning behin
Assuming I understand the proposal properly, this sounds to me like
it amounts reversing the change we experienced in the Apple GCC from
3.3 -> 4.0. Type checking became a lot more lax for us in 4.0.
We use AltiVec very heavily. From experience in cases when our 4.0
code had to be back
Hi list!
For those interested, GCC Algol 60 project, the byproduct of GCC
Frontend Howto diploma thesis, still lives, and its second milestone is
available:
http://projects.almad.net/gcc-algol/wiki/Milestones
Thanks,
PM
On Wed, 1 Nov 2006, Andrew Pinski wrote:
> Also it would be nice to have an attribute or a new keyword to get the
> old "extern inline" behavior, something like __extern_but_inline? Or is
> there a real equavilant with C99 style inling (I have not followed this
> part close enough to figure th
Joseph S. Myers wrote:
On Wed, 1 Nov 2006, Ian Lance Taylor wrote:
According to the proposal, we will restore the GNU handling for
"extern inline" even when using -std=c99, which will fix the problem
when using glibc.
We definitely need to revert that until the fixincludes changes are
availa
On Wed, 1 Nov 2006, Ian Lance Taylor wrote:
> According to the proposal, we will restore the GNU handling for
> "extern inline" even when using -std=c99, which will fix the problem
> when using glibc.
We definitely need to revert that until the fixincludes changes are
available. (The precise na
Andrew Pinski <[EMAIL PROTECTED]> writes:
> In the 4.3 timeframe, can we also add a flag to enable the correct behavior?
> Yes the problem with this is that we have to support this flag for a long time
> but the benifit is that we can change the default to the new way with just
> flipping
> a swi
>
> "Steven Bosscher" <[EMAIL PROTECTED]> writes:
>
> > On 11/1/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> > >
> > > > According to the proposal, we will restore the GNU handling for
> > > > "extern inline" even when using -std=c99, which will fix the problem
> > > > when using glibc.
> > >
>
On Nov 1, 2006, at 10:48 AM, Steven Bosscher wrote:
I am probably overlooking something, but if the only problematic
system
is glibc, maybe this can be fixed with a fixincludes hack?
That would be a massive hack.
Yes, fixincludes is a massive hack. Yes, it should not exist. But,
let's k
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
> On 11/1/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> >
> > > According to the proposal, we will restore the GNU handling for
> > > "extern inline" even when using -std=c99, which will fix the problem
> > > when using glibc.
> >
> > I am probably ov
>
> Steven Bosscher wrote:
>
> >
> > So you don't report any error messages at all and leave us guessing?
> >
>
> AFAIK fortran is not supposed to be configured at all for a cross-compiler.
> Or has that changed recently? It was certainly not configured in my
> previous
> builds of gcc 4.2
Steven Bosscher wrote:
So you don't report any error messages at all and leave us guessing?
AFAIK fortran is not supposed to be configured at all for a cross-compiler.
Or has that changed recently? It was certainly not configured in my
previous
builds of gcc 4.2 snapshots.
On Wed, 1 Nov 2006, Daniel Jacobowitz wrote:
> On Wed, Nov 01, 2006 at 06:59:42PM +, Joseph S. Myers wrote:
> > I'd rather simply fix glibc to work with C99 inline semantics. For the
> > above you might use
> >
> > #define tolower(c) __tolower_inline(c)
> > static __inline __attribute__((__
On Wed, Nov 01, 2006 at 06:59:42PM +, Joseph S. Myers wrote:
> I'd rather simply fix glibc to work with C99 inline semantics. For the
> above you might use
>
> #define tolower(c) __tolower_inline(c)
> static __inline __attribute__((__always_inline__)) int tolower_inline ...
>
> and #undef t
On Wed, 1 Nov 2006, Ian Lance Taylor wrote:
> glibc uses "extern inline", and exploits the traditional gcc ability
> to override the "extern inline" function with a regular function. For
> example, the definition of tolower in is:
>
> extern __inline int
> __NTH (tolower (int __c))
> {
> retu
On 11/1/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> According to the proposal, we will restore the GNU handling for
> "extern inline" even when using -std=c99, which will fix the problem
> when using glibc.
I am probably overlooking something, but if the only problematic system
is glibc, may
On 10/31/06, Roger Sayle <[EMAIL PROTECTED]> wrote:
I foresee no problems in getting the fwprop pass merged into mainline
this week. One detail I would like resolved however, is if you and
Steven Bosscher could confirm you're both co-ordinating your efforts.
Presumably, adding fwprop is part of
According to the proposal, we will restore the GNU handling for
"extern inline" even when using -std=c99, which will fix the problem
when using glibc.
I am probably overlooking something, but if the only problematic system
is glibc, maybe this can be fixed with a fixincludes hack?
Paolo
I believe the appropriate next step is to freshen these patches against
mainline, and re-bootstrap and regression test them.
Sure, I just wanted to make sure that it was worth the cycles. I'll do
so as soon as possible.
Thanks,
Paolo
On 11/1/06, Joern RENNECKE <[EMAIL PROTECTED]> wrote:
With literally more than ten thousand lines of error messages per
multilib for fortran, that makes the test results unreportable.
So you don't report any error messages at all and leave us guessing?
Gr.
Steven
Ian Lance Taylor wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
Ian Lance Taylor wrote:
Here is a review followed by a proposal.
How does this proposal handle the current problematic situation that
-std=c99 is broken on Linux?
According to the proposal, we will restore the GNU handling f
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
>
> > Here is a review followed by a proposal.
>
> How does this proposal handle the current problematic situation that
> -std=c99 is broken on Linux?
According to the proposal, we will restore the GNU handling for
"extern inli
On Wednesday 01 November 2006 17:39, Richard Sandiford wrote:
> Can a register be used more than once in an insn if one of those uses is
> an auto-modification? I've looked at this several times in the past and
> never come to a conclusion. doc/rtl.texi says:
We have a related problem on ARM. Th
Can a register be used more than once in an insn if one of those uses is
an auto-modification? I've looked at this several times in the past and
never come to a conclusion. doc/rtl.texi says:
If a register used as the operand of these [auto-modification]
expressions is used in another addres
Ian Lance Taylor wrote:
Here is a review followed by a proposal.
How does this proposal handle the current problematic situation that
-std=c99 is broken on Linux?
We could either revert Geoff's patch, or conditionalize it on Linux.
I'd argue against the latter approach (which is what I bel
When I configure an sh-elf cross tool chain without a specific
--enable-languages
option (which used to work with gcc 4.2), I get:
The following languages will be built: c,c++,fortran,java,objc
*** This configuration is not supported in the following subdirectories:
target-libmudflap target-l
[ Moved from gcc-patches@ to [EMAIL PROTECTED] ]
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Tue, 2006-10-31 at 21:34 -0800, Geoffrey Keating wrote:
> > Here's the list of log (and therefore ChangeLog) entries. There is
> > one change that I haven't merged yet, Caroline's pubtypes changes;
I am having difficulty getting configure properly
regenerated in libjava so that Geoff's multilib changes
will take effect. What versions of automake and libtool
is required by the current gcc 4.2 branch? I have been trying
automake 1.10 and libtool 1.5.22. However whenever I use
autoreconf -I
Compiler version: 4.2.0 20061030 (prerelease)
Platform: hppa64-hp-hpux11.00
revision 118179
configure flags: --prefix=/SCRATCH/gcc-build/HP-UX/hppa64-hp-hpux11.00/install
--with-gnu-as
--with-as=/SCRATCH/gcc-build/HP-UX/hppa64-hp-hpux11.00/install/bin/as
--with-ld=/usr/ccs/bin/ld --enable-threads=
33 matches
Mail list logo
