headers
Andris Kalnozols | 1 Jan 2010 06:44
Picon
Favicon

gcc-2.95 OK, gcc-{3,4}.X not OK

I've got a bit of a quandry here and would like the advice
of people who are more experienced than I am at C programming
and debugging.

We've got a legacy application that compiles and runs fine
using the following compilers/platforms:

  HP-UX 11.23 (PA-RISC) ANSI-C and aC++ C.11.23.04
  HP-UX 11.31 (ia64)    HP C/aC++ B3910B A.06.23 [May 18, 2009]
  Debian "squeeze" i686 gcc-2.95

Here is some debugging output during a runtime parse
of the application's custom scripting language after
compiling with gcc-2.95:

    'encountered _endif_; leaving gen_if()
    '*cmd->cmd' is '134523664'
    ' cmd->op'  is '200'
    ' flags'    is '0'
    ' pc'       is '200'
    'tokenbuf' is 'endif'
    ' pcptr      '     is '155572084'
    '*pcptr      '     is '0'
    ' pcptr->code'     is '155572068'
    '*pcptr->code'     is '200'
    ' pc'              is '155572068'
    '*pc'              is '200'
    ' pcptr->code->op' is '200'
    calling '[while]parse_cmd' in parse_body
  in parse_cmd():
(Continue reading)

Permalink | Reply | 6 comments |
headers
Amker.Cheng | 1 Jan 2010 12:39
Picon

question about replace_in_call_usage in regmove.c

Hi :
  In regmove.c there is function "replace_in_call_usage" called in
fixup_match_1,
It replaces dst register by src in call_insn, I suspect whether it is necessary
Since comment of CALL_INSN_FUNCTION_USAGE says that no pseudo register
can appear in it and seems src is pseudo register.

further more, no replace(dst->src) is done when building bootstrap
gcc-4.2.4, which
confirmed my understanding.

Is it right or I've missed something important? Please help.

Thanks in advance.

--

-- 
Best Regards.
Permalink | Reply | 1 comment |
headers
Andrew Haley | 1 Jan 2010 12:47
Picon
Favicon

Re: gcc-2.95 OK, gcc-{3,4}.X not OK

[redir to gcc-help]

On 01/01/2010 05:44 AM, Andris Kalnozols wrote:

> If the bug was a basic programming error, one would expect a
> runtime failure (dereferencing a NULL pointer) no matter which
> compiler was used.

I would not expect that, and I have no idea whay you would.  Undefined
behaviour can happen in any way: maybe the program appears to run
correctly, maybe it faults.

> The application compiles cleanly with no warnings using "-Wall".
> Were there any transition issues with the newer gcc compilers of
> which I may not be aware?

No.  As you've done the obvious first stage (using -Wall) you now
should run your program under Valgrind, assuming that it is available
on your system.

Andrew.
Permalink | Reply | 5 comments |
headers
FX | 1 Jan 2010 13:07
Picon

Big regression showing up on darwin

I know something is going on with section names, so I thought I'd mention that there is a big regression on
darwin (most "-flto -fwhopr -O2" tests fail) at rev. 155544. An example is:

FAIL: gcc.c-torture/compile/20010313-1.c  -O2 -fwhopr  (test for excess errors)
Excess errors:
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc8BGFLD.s:1:Expected comma after segment-name
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc8BGFLD.s:1:Rest of line ignored. 1st junk
character valued 32 ( ).

The assembler rejects lines such as the following:

        .section .gnu.lto_.jmpfuncs

Hope this can be fixed quickly, as it seriously hamper other regtesting.
FX
Permalink | Reply | 2 comments |
headers
Andrew Pinski | 1 Jan 2010 17:46
Picon

Re: Big regression showing up on darwin

On Fri, Jan 1, 2010 at 7:07 AM, FX <fxcoudert <at> gmail.com> wrote:
> I know something is going on with section names, so I thought I'd mention that there is a big regression on
darwin (most "-flto -fwhopr -O2" tests fail) at rev. 155544. An example is:

Really lto should be disabled when targeting darwin.  See PR 41529.

Thanks,
Andrew Pinski
Permalink | Reply | 1 comment |
headers
Benjamin Redelings I | 2 Jan 2010 01:12
Picon
Favicon

The "right way" to handle alignment of pointer targets in the compiler?

Hi,

I have been playing with the GCC vectorizer and examining assembly code 
that is produced for dot products that are not for a fixed number of 
elements.  (This comes up surprisingly often in scientific codes.)  So 
far, the generated code is not faster than non-vectorized code, and I 
think that it is because I can't find a way to tell the compiler that 
the target of a double* is 16-byte aligned.

I have three questions:

1. First, is there (unofficially, or in someone's head) a planned 
solution to this problem? If so, is it based on types with special 
attributes, or on something else?

The reason that I ask is that the current approaches seem to be based on 
types -- and I am able to hack this information into the compiler using 
the following 2-line approach:

   typedef double aligned_double __attribute__((aligned(16)))
   typedef aligned_double* SSE_PTR;

This works in simple examples.  (But doesn't work in my actually code - 
see the attached file test.C)

The more obvious approach of the 1-line

   typedef double __attribute__((aligned(16))) *SSE_PTR;

does not work.  I believe this is documented as (a) being correct and
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tim Prince | 2 Jan 2010 03:51
Picon
Favicon

Re: The "right way" to handle alignment of pointer targets in the compiler?

Benjamin Redelings I wrote:
> Hi,
> 
> I have been playing with the GCC vectorizer and examining assembly code 
> that is produced for dot products that are not for a fixed number of 
> elements.  (This comes up surprisingly often in scientific codes.)  So 
> far, the generated code is not faster than non-vectorized code, and I 
> think that it is because I can't find a way to tell the compiler that 
> the target of a double* is 16-byte aligned.
> 

> 
>  From Pr 27827 - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827 :
>  "I just quickly glanced at the code, and I see that it never uses 
> "movapd" from memory, which is a key to getting decent performance."
> 
How many people would take advantage of special machinery for some old 
CPU, if that's your goal?

simplifying your example to

double f3(const double* p_, const double* q_,int n)
{
       double sum = 0;
       for(int i=0; i<n;i++)
             sum += p_[i] * q_[i];

       return sum;
       }
g++ -S -O3 -march=pentium-m -ffast-math -mtune=barcelona -mfpmath=sse
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Korn | 2 Jan 2010 16:12

Re: Big regression showing up on darwin

Andrew Pinski wrote:
> On Fri, Jan 1, 2010 at 7:07 AM, FX <fxcoudert <at> gmail.com> wrote:
>> I know something is going on with section names, so I thought I'd mention that there is a big regression on
darwin (most "-flto -fwhopr -O2" tests fail) at rev. 155544. An example is:
> 
> Really lto should be disabled when targeting darwin.  See PR 41529.

  Also this particular error is caused by the asterisks-in-DECL_ASSEMBLER_NAME
problem (PR42531) that should be fixed at r.155555.

    cheers,
      DaveK
Permalink | Reply | 0 comments |
headers
Gerald Pfeifer | 2 Jan 2010 16:30

Re: Please update GNU GCC mirror list

On Wed, 16 Dec 2009, JohnT wrote:
> Some of the sites listed on the mirror list 
> http://gcc.gnu.org/mirrors.html aren't up to date and some aren't 
> accessible. LaffeyComputer.com doesn't allow access, and used to
> require a password for access. This isn't the way a GNU mirror site
> ought to operate. There should be free public access.

Thanks for the report, John.  I regularily run a link checker that
also covers our mirror sites.  That is not as easy as it may seem
at first since some mirrors only provide local access within their
geography and removing them based on my testing from one place on
the planet would be premature.

That said, mirrors.laffeycomputer.com may indeed not be active 
anymore.  Let me include mirrormaster <at> laffey.biz, the documented
contact for that mirror.

mirrormaster <at> laffey.biz, would you mind letting us know about the
status of your GCC mirror site?  Indeed I'm not able to access this
from any machine I am trying, always running into a timeout.

Gerald
Permalink | Reply | 1 comment |

Gmane