On Thu, Mar 12, 2009 at 11:29 PM, Dave Korn
wrote:
> James Dennett wrote:
>> On Thu, Mar 12, 2009 at 4:56 PM, Robert Dewar wrote:
>>> Nathan Ridge wrote:
>>>
Why does gcc not give an error about this?
If I compile with "-Wall", it will give a WARNING saying
"control reaches end of
James Dennett wrote:
> On Thu, Mar 12, 2009 at 4:56 PM, Robert Dewar wrote:
>> Nathan Ridge wrote:
>>
>>> Why does gcc not give an error about this?
>>> If I compile with "-Wall", it will give a WARNING saying
>>> "control reaches end of non-void function".
>>> However, shouldn't it be an ERROR t
Hello,
> > Using testsuite/gcc.dg/sms-6.c as an example and compiling it for
> PowerPC,
> > node 18 (see attachment) is in a SCC and cannot be scheduled until
> spliting
> > twice. The MII = 20 and the schedule can only be found at II = 24.
>
> Yes, I see. This example raises a couple of issues:
> On Thu, Mar 12, 2009 at 4:56 PM, Robert Dewar wrote:
>> Nathan Ridge wrote:
>>
>>> Why does gcc not give an error about this?
>>> If I compile with "-Wall", it will give a WARNING saying
>>> "control reaches end of non-void function".
>>> However, shouldn't it be an ERROR to return nothing
>>> f
On Thu, Mar 12, 2009 at 4:56 PM, Robert Dewar wrote:
> Nathan Ridge wrote:
>
>> Why does gcc not give an error about this?
>> If I compile with "-Wall", it will give a WARNING saying
>> "control reaches end of non-void function".
>> However, shouldn't it be an ERROR to return nothing
>> from a fu
writes:
> Is it a problem that is worth being put onto bugzilla or I just have to do
> some trickery to save the compiler from being smarter than it is?
I think this is worth being put into bugzilla.
Ian
On Thu, Mar 12, 2009 at 6:11 PM, Jack Howarth wrote:
> I think we may have a regression in gcc trunk
> on i686-apple-darwin9. We seem to be failing the
> following testcase in current gcc trunk (r144825)...
>
> Running
> /sw/src/fink.build/gcc44-4.3.999-20090312/gcc-4.4-2009
Using 4.4.0 gcc, I compiled a function and found it a tad long. The
command line is:
gcc -Os -mcpu=arm7tdmi-s -S func.c
although the output is pretty much the same with -O2 or -O3 as well (only
a few instructions longer).
The function is basically an unrolled 32 bit unsigned division by 1E9:
un
Hi, thanks for your help!
stage 1 gcc compiled with the modified "callz" instruction.
The "callz" instruction showed up in my assembly dump now!!
Thanks so much,
David.
2009/3/13 Ian Lance Taylor :
>
> Part of stage 1 involves building the runtime support library. This is
> needed in order to b
On Thu, Mar 12, 2009 at 6:11 PM, Jack Howarth wrote:
> I think we may have a regression in gcc trunk
> on i686-apple-darwin9. We seem to be failing the
> following testcase in current gcc trunk (r144825)...
>
> Running
> /sw/src/fink.build/gcc44-4.3.999-20090312/gcc-4.4-2009
dhua026 dhua026 writes:
> but most importantly, it used the "callz" instruction:
> /tmp/ccshjbUO.s: Assembler messages:
> /tmp/ccshjbUO.s:41: Error: no such instruction: `callz __fixunss...@plt'
> /tmp/ccshjbUO.s:53: Error: no such instruction: `callz __fixunss...@plt'
> make[1]: *** [_fixsfdi.o]
I think we may have a regression in gcc trunk
on i686-apple-darwin9. We seem to be failing the
following testcase in current gcc trunk (r144825)...
Running
/sw/src/fink.build/gcc44-4.3.999-20090312/gcc-4.4-20090312/gcc/testsuite/gcc.dg/dg.exp
...
FAIL: gcc.dg/asm-b.c (test for excess errors
Nathan Ridge wrote:
Why does gcc not give an error about this?
If I compile with "-Wall", it will give a WARNING saying
"control reaches end of non-void function".
However, shouldn't it be an ERROR to return nothing
from a function that's supposed to return something?
Does this not result in
(Note that this is really a question for gcc-help.)
On Thu, 2009-03-12 at 23:42 +, Nathan Ridge wrote:
> Why does gcc not give an error about this?
> If I compile with "-Wall", it will give a WARNING saying
> "control reaches end of non-void function".
You can turn this warning into an error
Hi all,
I am a newbie to GCC, but have long wanted to work with it. So I got
the chance to work on it with a research project, what I am trying to
do is add a custom backend to the GCC framework through machine
descriptions. I got the release sources (not from the SVN repository,
4.3.3), and foll
Hello,
So many times I write code like this:
SomeType function()
{
SomeType result;
// do something with result
return result;
}
except I often forget the "return result" statement.
Why does gcc not give an error about this?
If I compile with "-Wall", it will give a WARNING say
Snapshot gcc-4.3-20090312 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090312/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
p...@po.cwru.edu (Paul Jarc) writes:
> To find gcc's installation prefix, I've been using
> "gcc -print-search-dirs". That worked up until 4.3, but now gcc
> chases symlinks so it can print symlink-free paths. What I want is
> the installation path just as it was spelled in
> "./configure --pref
To find gcc's installation prefix, I've been using
"gcc -print-search-dirs". That worked up until 4.3, but now gcc
chases symlinks so it can print symlink-free paths. What I want is
the installation path just as it was spelled in
"./configure --prefix=...". In my case, that spelling is an absolu
CC using revision 144821 and rebuilt HIRLAM
with that compiler.
It doesn't exhibit the Infinity's anymore. A typical time step output is:
NSTEP3 BEGINS HERE:
1800s into the forecast; valid on 20090312 at 09:30:00
---
ABS
Thanks, after testing, I found that this performs what I need:
/* Insert at the beginning */
edge e = find_edge (ENTRY_BLOCK_PTR, ENTRY_BLOCK_PTR->next_bb);
basic_block newstart = split_edge(e);
i = bsi_last(newstart);
tree call = create_function_call(profile_begin, funcname);
Bingfeng Mei wrote:
> Hello, I am confused by one very basic concept :). In the following rtx
> expression, if const_int is 32-bit and DImode is 64-bit, will the const_int
> sign-extended or zero-extended. In other word, is the content of reg:DI 95
> 0x9 or 0x9 after this i
On Thu, Mar 12, 2009 at 12:08 PM, Joseph S. Myers
wrote:
> On Thu, 12 Mar 2009, Diego Novillo wrote:
>
>> Since C treats enums as ints, the maximum value is always INT_MAX
>> regardless of how many values are declared. So the question is, how
>> should we lower enums into gimple?
>>
>> The tempta
Hello,
I am confused by one very basic concept :). In the following rtx expression,
if const_int is 32-bit and DImode is 64-bit, will the const_int sign-extended
or zero-extended. In other word, is the content of reg:DI 95
0x9 or 0x9 after this instruction?
(set:DI (re
On Thu, Mar 12, 2009 at 13:08, Joseph S. Myers wrote:
> On Thu, 12 Mar 2009, Diego Novillo wrote:
>
>> Since C treats enums as ints, the maximum value is always INT_MAX
>> regardless of how many values are declared. So the question is, how
>> should we lower enums into gimple?
>>
>> The temptatio
On Thu, Mar 12, 2009 at 13:08, Steven Bosscher wrote:
> On Thu, Mar 12, 2009 at 5:36 PM, Diego Novillo wrote:
>> This is related to the different FE behaviour on const arguments that
>> I posted earlier (http://gcc.gnu.org/ml/gcc/2009-03/msg00316.html).
>> When an enum E is compiled by two differ
On Thu, Mar 12, 2009 at 5:36 PM, Diego Novillo wrote:
> This is related to the different FE behaviour on const arguments that
> I posted earlier (http://gcc.gnu.org/ml/gcc/2009-03/msg00316.html).
> When an enum E is compiled by two different front ends, when we try to
> combine them in lto1, we tr
On Thu, 12 Mar 2009, Diego Novillo wrote:
> Since C treats enums as ints, the maximum value is always INT_MAX
> regardless of how many values are declared. So the question is, how
> should we lower enums into gimple?
>
> The temptation is to use C++'s limits, but I'm concerned that may
> produce
On Thu, Mar 12, 2009 at 12:46, Steven Bosscher wrote:
> On Thu, Mar 12, 2009 at 5:36 PM, Diego Novillo wrote:
>> The temptation is to use C++'s limits, but I'm concerned that may
>> produce confusion somewhere down the line with the optimizers or other
>> diagnostics. Or should we use C's notion
On Thu, Mar 12, 2009 at 11:15 AM, Mark Mitchell wrote:
> Daniel Berlin wrote:
>
>> But if it was following this and removing const qualifiers, shouldn't
>> it have remove the const from const char * too?
>> Or am i missing something?
>
> No, that is not a top-level qualifier.
>
Ah, it only removes
On Thu, Mar 12, 2009 at 5:36 PM, Diego Novillo wrote:
> The temptation is to use C++'s limits, but I'm concerned that may
> produce confusion somewhere down the line with the optimizers or other
> diagnostics. Or should we use C's notion and treat them as ints?
The limits are a language-specific
I need to compile a multi-file test case where each file needs to use
a different front end to generate IL. This is to process the test
case I posted with http://gcc.gnu.org/ml/gcc/2009-03/msg00316.html.
I partially succeeded by putting the files in g++.dg/lto and using '-x
c' on the second file,
On Thu, Mar 12, 2009 at 02:02:36PM +0100, Joel Porquet wrote:
> > Check what symbol is at, or near, 0x4003 + 22368. It's probably
> > the GOT plus a constant bias.
>
> It seems there is nothing at this address. Here is the program header:
Don't know then. Look at compiler-generated assembly
Hi JC,
On Thu, Mar 12, 2009 at 10:58, fearyourself wrote:
> Dear all,
>
> I've been trying to add a pass that adds a function call at the
> beginning of each function. However, my first solution was to simply
> do something like this:
>
> bb = ENTRY_BLOCK_PTR ->next_bb;
> i = bsi_start (bb);
> tr
This is related to the different FE behaviour on const arguments that
I posted earlier (http://gcc.gnu.org/ml/gcc/2009-03/msg00316.html).
When an enum E is compiled by two different front ends, when we try to
combine them in lto1, we trigger an ODR violation because we try to
assert that both enums
On Thu, Mar 12, 2009 at 8:58 AM, H.J. Lu wrote:
> Index: i386.md
> ===
> --- i386.md (revision 144796)
> +++ i386.md (working copy)
> @@ -20813,7 +20813,7 @@
> [(match_dup 0)
> (match
On Thu, Mar 12, 2009 at 8:00 AM, Richard Guenther
wrote:
> On Thu, Mar 12, 2009 at 3:56 PM, Steven Bosscher
> wrote:
>> - Show quoted text -
>> On Thu, Mar 12, 2009 at 3:34 PM, Paolo Bonzini wrote:
>>>
Will "REGNO (operands[0]) == REGNO (operands[1])" work here?
>>>
>>> Yes. I wanted to b
Dear all,
I've been trying to add a pass that adds a function call at the
beginning of each function. However, my first solution was to simply
do something like this:
bb = ENTRY_BLOCK_PTR ->next_bb;
i = bsi_start (bb);
tree call = create_function_call(profile_begin, funcname);
bsi_insert_before(&
Daniel Berlin wrote:
> On Thu, Mar 12, 2009 at 9:32 AM, Paolo Carlini
> wrote:
>> Hi,
>>> Notice how the third argument is 'int' instead of 'const int'. Is
>>> this the way C++ is supposed to behave or is this a bug in the FE?
>>>
>> Well, I would say this is a rather well known C++ feature not
Daniel Berlin wrote:
> But if it was following this and removing const qualifiers, shouldn't
> it have remove the const from const char * too?
> Or am i missing something?
No, that is not a top-level qualifier.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
On Thu, Mar 12, 2009 at 9:32 AM, Paolo Carlini wrote:
> Hi,
>> Notice how the third argument is 'int' instead of 'const int'. Is
>> this the way C++ is supposed to behave or is this a bug in the FE?
>>
> Well, I would say this is a rather well known C++ feature not a bug. It
> took me a little ti
On Thu, Mar 12, 2009 at 10:51, Gabriel Dos Reis wrote:
>> $ cat f.h
>> typedef const char * (*Callback)(void *, const char *, const int);
>
> The 'const' on third argument is superfluous.
>
> (Similar thing happens if you put 'const' on a scalar type on the
> return type).
Thanks. I've arranged
On Thu, Mar 12, 2009 at 3:56 PM, Steven Bosscher wrote:
> - Show quoted text -
> On Thu, Mar 12, 2009 at 3:34 PM, Paolo Bonzini wrote:
>>
>>> Will "REGNO (operands[0]) == REGNO (operands[1])" work here?
>>
>> Yes. I wanted to be conservative in case one day subregs or who knows
>> what are allow
On Thu, Mar 12, 2009 at 3:34 PM, Paolo Bonzini wrote:
>
>> Will "REGNO (operands[0]) == REGNO (operands[1])" work here?
>
> Yes. I wanted to be conservative in case one day subregs or who knows
> what are allowed. I'll defer to maintainers or other people (Steven?),
> either way is fine by me.
On Thu, Mar 12, 2009 at 5:42 AM, Diego Novillo wrote:
> Apologies if this is a basic misunderstanding of how C++ works, but to
> me this looks like a bug. I am tracking down an ODR violation message
> that LTO is emitting when linking two TUs that include the same header
> file, but whose IL was
On Thu, Mar 12, 2009 at 10:29, Mark Mitchell wrote:
> Just to be completely clear: top-level cv-qualifiers (don't forget
> volatile, and don't forget to think about restrict) are removed from the
> type of function parameters when computing the type of the function.
Yes, I mean removing the 'con
> Will "REGNO (operands[0]) == REGNO (operands[1])" work here?
Yes. I wanted to be conservative in case one day subregs or who knows
what are allowed. I'll defer to maintainers or other people (Steven?),
either way is fine by me.
Paolo
Diego Novillo wrote:
> Remove the const in the C FE. A const qualifier in a pass-by-value
> argument does not really add any useful information. It's different
> if this was a pass-by-reference.
Just to be completely clear: top-level cv-qualifiers (don't forget
volatile, and don't forget to thi
On Thu, Mar 12, 2009 at 10:09, Michael Veksler
wrote:
> Which way the cleanup is going to be? Remove the "const" from
> the C FE or re-add the "const" to the IL of the C++ FE?
Remove the const in the C FE. A const qualifier in a pass-by-value
argument does not really add any useful informatio
Diego Novillo wrote:
On Thu, Mar 12, 2009 at 09:32, Paolo Carlini wrote:
Hi,
Notice how the third argument is 'int' instead of 'const int'. Is
this the way C++ is supposed to behave or is this a bug in the FE?
Well, I would say this is a rather well known C++ feature not a bu
On Thu, Mar 12, 2009 at 7:03 AM, Paolo Bonzini wrote:
> Toon Moene wrote:
>> Paolo Bonzini wrote:
>>
Attached you'll find the (preprocessed) source of the routine that
printed the Infinity's (of course, I cannot be completely certain that
it actually resulted in the wrong code, but
Toon Moene wrote:
> Paolo Bonzini wrote:
>
>>> Attached you'll find the (preprocessed) source of the routine that
>>> printed the Infinity's (of course, I cannot be completely certain that
>>> it actually resulted in the wrong code, but at least it might be studied
>>> to see if it helps to find t
On Thu, Mar 12, 2009 at 5:53 AM, Toon Moene wrote:
>
> Yep, sorry: -g -O3 -ffast-math -mcpu=native -march=native
> on a x86-64-unknown-linux-gnu system (native 64-bit).
>
Please also try -fno-vectorize to see if this peephole issue is triggered by
vectorizer.
--
H.J.
On Wed, Mar 11, 2009 at 03:33:28PM +0100, Ulrich Weigand wrote:
> > It doesn't work. It causes a loop somewhere in gcc. I can get a gdb
> > trace if needed.
>
> Yes, this does not work. Jumps are special; the CFG logic makes
> a lot of assumptions how jump patterns look.
[...]
> The s390 back-en
On Thu, Mar 12, 2009 at 09:32, Paolo Carlini wrote:
> Hi,
>> Notice how the third argument is 'int' instead of 'const int'. Is
>> this the way C++ is supposed to behave or is this a bug in the FE?
>>
> Well, I would say this is a rather well known C++ feature not a bug. It
> took me a little time
On Thu, Mar 12, 2009 at 1:48 AM, Toon Moene wrote:
>
> Ah, but it did: throwing out the second peephole (in stead of both) fixed
> the problem too.
>
Is a bug opened for this? If not, please open one.
Thanks.
--
H.J.
On Thu, Mar 12, 2009 at 5:53 AM, Toon Moene wrote:
>>
>> (*) it would have helped to know the compilation flags and target, of
>> course.
>
> Yep, sorry: -g -O3 -ffast-math -mcpu=native -march=native
> on a x86-64-unknown-linux-gnu system (native 64-bit).
>
Please show output of 'gcc -v" on t
Hi,
> Notice how the third argument is 'int' instead of 'const int'. Is
> this the way C++ is supposed to behave or is this a bug in the FE?
>
Well, I would say this is a rather well known C++ feature not a bug. It
took me a little time finding the exact section of the standard where it
is stat
> Check what symbol is at, or near, 0x4003 + 22368. It's probably
> the GOT plus a constant bias.
It seems there is nothing at this address. Here is the program header:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x34 0x5ffe
Paolo Bonzini wrote:
Attached you'll find the (preprocessed) source of the routine that
printed the Infinity's (of course, I cannot be completely certain that
it actually resulted in the wrong code, but at least it might be studied
to see if it helps to find the culprit).
No, this function is
Apologies if this is a basic misunderstanding of how C++ works, but to
me this looks like a bug. I am tracking down an ODR violation message
that LTO is emitting when linking two TUs that include the same header
file, but whose IL was generated with different front ends:
$ cat f.h
typedef const c
> Attached you'll find the (preprocessed) source of the routine that
> printed the Infinity's (of course, I cannot be completely certain that
> it actually resulted in the wrong code, but at least it might be studied
> to see if it helps to find the culprit).
No, this function is sane (the peepho
--- Mer 11.3.09, Ian Lance Taylor wrote:
> But they aren't documented in the user manual. I think
> they should be, just as we document the machine specific
> constraint characters in the user manual.
> I think it would be appropriate to open a bug report about this.
>
> Ian
http://gcc.gnu.org
On Thu, Mar 12, 2009 at 1:15 AM, Jan Hubicka wrote:
>> Timothy Madden wrote:
>> > Hello
>> >
>> > Is -mfpmath=both for i386 and x86-64 still experimental in gcc 4.3, as
>> > the in the online manual page ?
[...]
>
> The fundamental problem here is that backend lies to compiler about the
> fact tha
Paolo Bonzini wrote:
Toon Moene wrote:
H.J. Lu wrote:
If you can provide a testcase, I can take a look. If it isn't easy to
find
a testcase, please disable the second pattern:
(define_peephole2
[(set (match_operand 0 "register_operand" "")
(match_operand 1 "register_operand" ""))
Toon Moene wrote:
> H.J. Lu wrote:
>
>> If you can provide a testcase, I can take a look. If it isn't easy to
>> find
>> a testcase, please disable the second pattern:
>>
>> (define_peephole2
>> [(set (match_operand 0 "register_operand" "")
>> (match_operand 1 "register_operand" ""))
>>
> In addition, all but one of the fixes that H.J. made (and for which I
> have to thank him) were unrecognizable insns due to a misunderstanding
> of how peephole2 worked
I stand corrected; *all* of the fixes. The patch hadn't had a
correctness problem until your message, "only" ice-on-valids.
1) As multiple people said, it *was* a regression bug fix. It actually
fixed two regressions. (That it fixed the second was discovered only
after I committed it). I'm sorry that it caused problems for you (even
though it's actually lucky for GCC), but I can't help saying that it
might have been
68 matches
Mail list logo
