Hi Richard,
I found the following in my build logs, and thought it was worth
reporting to you. Although I don't speak texinfo, the lines in
questions are the ones introduced by your ColdFire 9/63 patch
(commited as rev. 120713):
perl /home/fxcoudert/gfortran_nightbuild/trunk/gcc/../contrib/texi2
On Tue, 6 Feb 2007, Dorit Nuzman wrote:
> > Hi Richard,
> >
> >
> ...
> > However...,
> >
> > I have seen cases in which complete unrolling before vectorization
> enabled
> > constant propagation, which in turn enabled significant simplification of
> > the code, thereby, in fact making a previousl
Richard Guenther <[EMAIL PROTECTED]> wrote on 06.02.2007 11:19:15:
> On Tue, 6 Feb 2007, Dorit Nuzman wrote:
> > After sleeping on it, it actually makes a lot of sense to me to
schedule
> > complete loop unrolling before vectorization - I think it would either
> > simplify loops (sometimes creatin
Dorit Nuzman/Haifa/IBM wrote on 05/02/2007 21:13:40:
> Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 17:59:00:
>
> > On Mon, 5 Feb 2007, Paolo Bonzini wrote:
> >
> > >
> > > > As we also only vectorize innermost loops I believe doing a
> > > > complete unrolling pass early will help i
Ira Rosen/Haifa/IBM wrote on 06/02/2007 11:49:17:
> Dorit Nuzman/Haifa/IBM wrote on 05/02/2007 21:13:40:
>
> > Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 17:59:00:
> >
...
> >
> > That's going to change once this project goes in: "(3.2) Straight-
> > line code vectorization" from htt
On Tue, 6 Feb 2007, Dorit Nuzman wrote:
> Ira Rosen/Haifa/IBM wrote on 06/02/2007 11:49:17:
>
> > Dorit Nuzman/Haifa/IBM wrote on 05/02/2007 21:13:40:
> >
> > > Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 17:59:00:
> > >
> ...
> > >
> > > That's going to change once this project goes
"François-Xavier Coudert" <[EMAIL PROTECTED]> writes:
> I found the following in my build logs, and thought it was worth
> reporting to you. Although I don't speak texinfo, the lines in
> questions are the ones introduced by your ColdFire 9/63 patch
> (commited as rev. 120713):
>
> perl /home/fxcou
Hi list!
First, I am not subscribed to this list, so please CC me on answers, thanks!
I try to build gcc trunk (r121622) on x86_64/core2duo but I get an ICE.
Thanks for any help in advance!
Regards,
Hanno
___
Build config:
# ./xgcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Confi
On Tue, 6 Feb 2007, Richard Sandiford wrote:
> Ugh, thanks for the heads-up. This patch adds some rudimentary
> support for @multitable. As far as I know, perldoc doesn't have
> anything equivalent to multi-column tables, so I just treated them
> as itemized lists and used ":" as a column separa
In an OS kernel functions that do not return are commonly used and
practically always their code is beyond gcc's ability to recognize
noreturn functions. A typical example would for example be the BUG()
function in Linux which is implemented as something like:
static inline void __attribute__((no
> Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 18:16:05:
>
> > On Mon, 5 Feb 2007, Jan Hubicka wrote:
> ...
> > > Did you run some benchmarks?
> >
> > Not yet - I'm looking at the C++ SPEC 2006 benchmarks at the moment
> > and using vectorization there seems to do a lot of collateral d
Hi,
I tried to compile glibc 2.3.6 and 2.4 for an e500 target using
gcc-4.1.2-20070128.
I applied the proposed patch for PR30370 go get gcc compiled.
Unfortunately, glibc compilation fails. After some testing, I was able
to create a small test program - see below. It turns out that the
problem w
Hello Paolo, all,
* Paolo Bonzini wrote on Mon, Feb 05, 2007 at 10:30:41AM CET:
>
> >The macro $(SYSTEM_HEADER_DIR) is used in a double-quoted context,
> >leading to nonportable "...`..."..."...`...", [...]
> >Proposed untested patch. (I also haven't checked whether there are
> >other instances
On Jan 29, 2007, "Manuel López-Ibáñez" <[EMAIL PROTECTED]> wrote:
> * You can add a return 0 or an exit(1) at the end of the function or
> in a default label. Since in your case the code is unreachable, the
> optimiser may remove it or it will never be executed.
But this would generate additional
On 1/31/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Paulo J. Matos wrote on 01/31/07 11:26:
> So, ideally, I would like just the gcc part until the first part of
> the middleend where you have a 'no optimizations', language
> independent AST of the source file.
>
OK, so you probably want to inj
Hello,
> Ira Rosen/Haifa/IBM wrote on 06/02/2007 11:49:17:
>
> > Dorit Nuzman/Haifa/IBM wrote on 05/02/2007 21:13:40:
> >
> > > Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 17:59:00:
> > >
> ...
> > >
> > > That's going to change once this project goes in: "(3.2) Straight-
> > > line
On Tue, Feb 06, 2007 at 04:44:50PM -0200, Alexandre Oliva wrote:
> > * You can add a return 0 or an exit(1) at the end of the function or
> > in a default label. Since in your case the code is unreachable, the
> > optimiser may remove it or it will never be executed.
>
> But this would generate a
On 06/02/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
On Jan 29, 2007, "Manuel López-Ibáñez" <[EMAIL PROTECTED]> wrote:
> * You can add a return 0 or an exit(1) at the end of the function or
> in a default label. Since in your case the code is unreachable, the
> optimiser may remove it or it w
On Tue, Feb 06, 2007 at 08:00:29PM +, Ralf Baechle wrote:
> On Tue, Feb 06, 2007 at 04:44:50PM -0200, Alexandre Oliva wrote:
> > Meanwhile, there's __builtin_trap() already, and Ralf might use that
> > even to remove the asm volatile, and Paweł could use it in a default:
> > label. It's still
> In an OS kernel functions that do not return are commonly used and
> practically always their code is beyond gcc's ability to recognize
> noreturn functions. A typical example would for example be the BUG()
> function in Linux which is implemented as something like:
>
> static inline void __att
Paulo J. Matos wrote on 02/06/07 14:19:
Why before pass_build_ssa? (version 4.1.1)
It depends on the properties your pass requires. If you ask for
PROP_cfg and PROP_gimple_any then you should schedule it after the CFG
has been built, but if you need PROP_ssa, then you must be after
pass_bui
I am implementing -Wstrict-aliasing by catching simple cases in the
frontend and more complex ones in the backend. The frontend mechanism
is tree pattern matching. The backend one uses flow-sensitive points-to
information.
I want to avoid duplicate warnings. I thought of a few ways, but n
On Tue, Feb 06, 2007 at 01:53:44PM -0800, Silvius Rus wrote:
> I am implementing -Wstrict-aliasing by catching simple cases in the
> frontend and more complex ones in the backend. The frontend mechanism
> is tree pattern matching. The backend one uses flow-sensitive points-to
> information.
>
Silvius Rus <[EMAIL PROTECTED]> writes:
> I want to avoid duplicate warnings. I thought of a few ways, but none
> seems perfect. Can you please advise which of the following I should
> choose, suggest alternatives, or let me know if a solution exists.
It may work to set and check TREE_NO_WARNIN
Back in 2000 I wrote a really simple patch that caused gcc to treat an
ASM_OPERANDS that clobbered "pc" as a control flow barrier, exactly
for this problem.
http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html
I still think it was a good idea, but at the time it was received
unenthusiasticall
Zack Weinberg wrote:
> Back in 2000 I wrote a really simple patch that caused gcc to treat an
> ASM_OPERANDS that clobbered "pc" as a control flow barrier, exactly
> for this problem.
>
> http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html
>
> I still think it was a good idea, but at the time
"Zack Weinberg" <[EMAIL PROTECTED]> writes:
> Back in 2000 I wrote a really simple patch that caused gcc to treat an
> ASM_OPERANDS that clobbered "pc" as a control flow barrier, exactly
> for this problem.
>
> http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html
>
> I still think it was a go
On Tue, Feb 06, 2007 at 04:14:30PM -0800, Ian Lance Taylor wrote:
> I also think it would be good to have one option affecting it: turn
> __builtin_unreachable() into an abort(), or turn it into a "cannot be
> reached" marker. I think the former should be the default at -O0, the
> latter at -O1 an
Joe Buck <[EMAIL PROTECTED]> writes:
> On Tue, Feb 06, 2007 at 04:14:30PM -0800, Ian Lance Taylor wrote:
> > I also think it would be good to have one option affecting it: turn
> > __builtin_unreachable() into an abort(), or turn it into a "cannot be
> > reached" marker. I think the former should
On Feb 6, 2007, at 5:06 PM, Joe Buck wrote:
On Tue, Feb 06, 2007 at 04:14:30PM -0800, Ian Lance Taylor wrote:
I also think it would be good to have one option affecting it: turn
__builtin_unreachable() into an abort(), or turn it into a "cannot be
reached" marker. I think the former should be
30 matches
Mail list logo
