[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[bonzini at gnu dot org]

--- Comment #23 from bonzini at gnu dot org  2009-02-10 09:50 ---
> I guess it is too expensive to add a new reg class for each
> register to support constraints for all registers.

This has no reference to the actual problem of this PR.

The sparc testcase that Jakub posted is particularly significative, since you
don't get ICEs but wrong code there.

> Unfortunately this means that in a function which contains both local register
> variables and an asm, we must severely restrict any code motion which may
> involve a function call or the use of hidden registers.

I think that in the GIMPLE grammar local register variables should be treated
as memory, with loads and stores separated from the computations; and just like
memory, each asm or function call should have a VUSE and (depending on the
asm's inputs, outputs and clobbers; and in the case of function calls for
call-clobbered local register variables) VDEF for the local register variables.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-02-10 09:50:44
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139

[Bug c++/34397] [4.2/4.3/4.4 regression] ICE on invalid default template parameter

[paolo dot carlini at oracle dot com]

--- Comment #25 from paolo dot carlini at oracle dot com  2009-02-10 10:03 
---
Thanks. I'll try to submit something more polished along these lines...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397

[Bug c/12245] [4.2/4.3/4.4 regression] Uses lots of memory when compiling large initialized arrays

[rguenth at gcc dot gnu dot org]

--- Comment #39 from rguenth at gcc dot gnu dot org  2009-02-10 10:12 
---
*** Bug 39142 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||macdonellba+gcc at gmail dot
   ||com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245

[Bug middle-end/39142] Compilation fails with specialised optimisations.

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-02-10 10:12 ---
gcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See  for instructions.

Which means that your kernel killed the compiler, likely due to memory
usage issues.  On x86_64 the testcase uses 1.4GB.

Note that the issue is likely the large static initializer of ___lbl_tbl.
See PRs 14179 and 12245.  Removing that initializer the file needs 67MB to
build.

*** This bug has been marked as a duplicate of 12245 ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39142

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jakub at gcc dot gnu dot org]

--- Comment #24 from jakub at gcc dot gnu dot org  2009-02-10 10:20 ---
Their loads and stores are already separated from other computations, as
they aren't is_gimple_reg.  And they do have VDEFs/VUSES:
  # a1D.1284_24 = VDEF  { a1D.1284 }
  a1D.1284 = 11;
  y.0D.1287_15 = (long unsigned intD.4) &eD.1268;
  # a2D.1285_26 = VDEF  { a2D.1285 }
  a2D.1285 = y.0D.1287_15;
  # eD.1268_28 = VDEF 
  # rD.1283_29 = VDEF 
  # a1D.1284_30 = VDEF 
  # a2D.1285_31 = VDEF  { eD.1268 rD.1283 a1D.1284 a2D.1285 }
  __asm__ __volatile__("" : "=r" rD.1283, "=r" a1D.1284, "=r" a2D.1285 : "1"
a1D.1284 : "2" a2D.1285 : "memory");

But that is not enough to prevent sinking in between these, sinking of e = {}
looks solely at eD.1268_* VUSEs and the immediate user is therefore the asm.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jakub at gcc dot gnu dot org]

--- Comment #25 from jakub at gcc dot gnu dot org  2009-02-10 10:29 ---
Created an attachment (id=17275)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17275&action=view)
gcc44-pr39139.patch

Quick patch to avoid sinking of block copies or clearings if current function
has local explicit register vars.  If there are other passes that move around
calls or potential calls to places where they haven't been originally, they
could do similar thing.  If needed, we could track which basic blocks have such
vars live etc., but I don't think it is worth it.

The alternative would be to make DECL_HARD_REGISTER initializations (and uses?)
act like loads/stores of pointers that can point to any memory, but that seems
to me even bigger overkill, there is nothing wrong with moving a normal memory
load or store, it is just the potential libcalls and inline stringops that are
a problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[rguenth at gcc dot gnu dot org]

--- Comment #26 from rguenth at gcc dot gnu dot org  2009-02-10 10:35 
---
I could imagine that other architectures have other special registers, so
I think treating them like pointer dereferences to anything would be more
robust than changing all code-motion passes.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[bonzini at gnu dot org]

--- Comment #27 from bonzini at gnu dot org  2009-02-10 10:49 ---
The patch does not seem too bad.  You could add a target hook to get a
HARD_REG_SET or constituting an optimization barriers (defaulting to all
call-clobbered registers, which would be okay for all targets that do not have
stringops).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139

[Bug middle-end/39142] Compilation fails with specialised optimisations.

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2009-02-10 10:21 
---
Thanks Richard, noticed the Killed too late...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39142

[Bug middle-end/39127] Invalid GIMPLE with OpenMP

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-02-10 12:46 ---
I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-02-10 12:46:08
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39127

[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler

[earthengine at gmail dot com]

--- Comment #13 from earthengine at gmail dot com  2009-02-10 12:48 ---

> whereas the --build part used to not be necessary. (Although I suppose 
> omitting
> both host and build flags might work too, or just supplying
> --host=x86_64-unknown-linux-gnu when compiling on x86_64 so that auto-detected
> --build will be filled in equivalently.)
 No, you are wrong. If use
--host=x86_64-unknown-linux-gnu and omitting the --build flag, in some machine
the detected --build flag in 4.3.x is
--build=core2-unknown-linux-gnu
and in this case it is still a canadian cross build.
I have seen it before.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35942

[Bug c++/39140] g++ doesn't inline vararg functions

[thomas dot bleher at philosys dot de]

--- Comment #2 from thomas dot bleher at philosys dot de  2009-02-10 12:53 
---
Thank you for the very fast response! Good to see that this is already fixed in
a newer GCC.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39140

[Bug tree-optimization/39132] wrong code generated with -ftree-loop-disttribution

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-02-10 13:15 ---
Confirmed.  There is wrong alias-information on the memset:

:
Invalid sum of outgoing probabilities 0.0%
  D.1641_35 = &ep + 8;
  # rx_ring_36 = VDEF 
  # SMT.12_37 = VDEF 
  __builtin_memset (D.1641_35, 0, 20);

:
Invalid sum of incoming frequencies 0, should be 1667
  # VUSE 
  D.1609_10 = ep.rx_skbuff[0];
  if (D.1609_10 != 0)

the memset should clobber ep.  Investigating.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-02-10 13:15:51
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39132

[Bug tree-optimization/39132] wrong code generated with -ftree-loop-disttribution

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-02-10 13:29 ---
I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-02-10 13:15:51 |2009-02-10 13:29:52
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39132

[Bug target/39119] Update classification of aggregates with __m256

[hjl at gcc dot gnu dot org]

--- Comment #3 from hjl at gcc dot gnu dot org  2009-02-10 14:01 ---
Subject: Bug 39119

Author: hjl
Date: Tue Feb 10 14:00:46 2009
New Revision: 144058

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144058
Log:
gcc/

2009-02-10  H.J. Lu  

PR target/39119
* config/i386/i386.c (x86_64_reg_class): Remove X86_64_AVX_CLASS.
(x86_64_reg_class_name): Removed.
(classify_argument): Return 0 if bytes > 32.  Return 0 if the
first one isn't X86_64_SSE_CLASS or any other ones aren't
X86_64_SSEUP_CLASS when size > 16bytes.  Don't turn
X86_64_SSEUP_CLASS into X86_64_SSE_CLASS if the preceded one
is X86_64_SSEUP_CLASS.  Set AVX modes to 1 X86_64_SSE_CLASS
and 3 X86_64_SSEUP_CLASS.
(construct_container): Remove X86_64_AVX_CLASS.  Handle 4
registers with 1 X86_64_SSE_CLASS and 3 X86_64_SSEUP_CLASS.

gcc/testsuite/

2009-02-10  H.J. Lu  

PR target/39119
* gcc.target/x86_64/abi/avx/abi-avx.exp: New.
* gcc.target/x86_64/abi/avx/args.h: Likewise.
* gcc.target/x86_64/abi/avx/asm-support.S: Likewise.
* gcc.target/x86_64/abi/avx/avx-check.h: Likewise.
* gcc.target/x86_64/abi/avx/test_m256_returning.c: Likewise.
* gcc.target/x86_64/abi/avx/test_passing_m256.c: Likewise.
* gcc.target/x86_64/abi/avx/test_passing_structs.c: Likewise.
* gcc.target/x86_64/abi/avx/test_passing_unions.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/x86_64/abi/avx/
trunk/gcc/testsuite/gcc.target/x86_64/abi/avx/abi-avx.exp
trunk/gcc/testsuite/gcc.target/x86_64/abi/avx/args.h
trunk/gcc/testsuite/gcc.target/x86_64/abi/avx/asm-support.S
trunk/gcc/testsuite/gcc.target/x86_64/abi/avx/avx-check.h
trunk/gcc/testsuite/gcc.target/x86_64/abi/avx/test_m256_returning.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/avx/test_passing_m256.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/avx/test_passing_structs.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/avx/test_passing_unions.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39119

[Bug middle-end/39124] [4.4 Regression]: -fno-exceptions leads to a ICE

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2009-02-10 14:11 ---
Created an attachment (id=17276)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17276&action=view)
gcc44-pr39124.patch

The problem is that remove_path first calls remove_bbs and afterwards
cancel_loop_tree.  The first call removes all bbs from one loop (a loop inside
of another loop that has niter == 0 and is peeled completely to nothing) and
the second attempts to remove it.  But, get_loop_body asserts the loop has at
least one bb, which is not true after all its bbs have been removed.

This patch fixes this by first calling cancel_loop_tree and afterwards
remove_bbs.  E.g. tree-loop-distribution.c also calls it in this order, first
cancel_loop_tree, then delete_basic_blocks.  Also cancel_loop comment suggests
that bbs should be removed afterwards.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39124

[Bug target/16331] x86-64 inline asm register constraints insufficient WRT ABI

[thutt at vmware dot com]

--- Comment #13 from thutt at vmware dot com  2009-02-10 14:34 ---
(In reply to comment #12)
> (In reply to comment #11)
> > Uros, how hard to support this in x86 backend?
>



> OTOH, constraints should be used to support correct register
> allocation for machine instructions, not to emulate ABI in order to
> support calls from inside asm statements.

Please indulge me for a moment.

What exactly is a call?

Are you considering the only method of transferring control to be the
standard 'near call' & 'near ret' instructions on the x86?

What about the following modes of transferring control to another
address?

   int
   iret
   ret
   sysenter
   sysexit
   syscall
   sysret
   ud2
   int3
   jmp

Then, what of these?

   lcall
   lret
   ljmp

Every one of these is a method to transfer control to another address
with a programmer-defined set of input register.  More importantly,
none of these are directly supported by gcc to invoke functions
without resorting to inline assembly.

If you're working on an operating system, a virtualization engine or
some other embedded device you might need to transfer control using
one of these methods.

As a really simple example, consider a handler for a timer interrupt.
Let's say that the prologue for the interrupt (written in assembly)
handler storing all the machine registers into a data structure
accessible from C.  Then, the prologue transfers to the handler which is
conveniently written in C.  Wouldn't it be really nice if one could
restore all the saved registers in C code using only inline assembly
instruction?

__asm__("iret"
:
: force restoring registers saved in data structure);

I'm confident you can see the advantage of doing this in C and letting
the compiler deal with the bookkeeping details, rather than resorting
to another assembly language function which does such a simple feat.

I think I pretty clearly demonstrate here that calling other functions
using the x86 architecture isn't as simple as assuming it's going only
to be done with 'call', 'jmp' and 'ret', and many of those methods are
not possible with straight C, even with gcc's helpful extensions.

Should gcc prevent the developer from using the ABI just because the
inline assembly wasn't meant to 'support calls from inside assembly
statements'?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16331

[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm

[rearnsha at gcc dot gnu dot org]

--- Comment #6 from rearnsha at gcc dot gnu dot org  2009-02-10 14:36 
---
This is not a bug, but a problem with your source code.

In order to understand why, you need to pre-process the code and look at the
output:

...
void *memset_arm9(void *a, int b, int c)
{
  return ({ uint8_t *dst = ((uint8_t *)a); uint8_t c = (b); int count = (c);
uin
t32_t dummy0, dummy1, dummy2; __asm__ __volatile__ (

Notice that first there is a declaration of a variable c (uint8_t), then in the
next statement there is a use of c.  This use (which is intended to be of the
formal parameter passed to memset_arm9 is instead interpreted as the newly
declared variable c (the uint8 one).


Compiling your testcase with -Wshadow gives:

inl.c: In function 'memset_arm9':
inl.c:66: warning: declaration of 'c' shadows a parameter
inl.c:64: warning: shadowed declaration is here


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693

[Bug target/39119] Update classification of aggregates with __m256

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2009-02-10 14:38 ---
Fixed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39119

[Bug target/39119] Update classification of aggregates with __m256

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-02-10 14:38 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39119

[Bug tree-optimization/39132] wrong code generated with -ftree-loop-disttribution

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-02-10 14:54 ---
Subject: Bug 39132

Author: rguenth
Date: Tue Feb 10 14:54:13 2009
New Revision: 144060

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144060
Log:
2009-02-10  Richard Guenther  

PR tree-optimization/39132
* tree-loop-distribution.c (todo): New global var.
(generate_memset_zero): Trigger TODO_rebuild_alias.
(tree_loop_distribution): Return todo.

* gcc.dg/torture/pr39132.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr39132.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-loop-distribution.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39132

[Bug middle-end/39127] Invalid GIMPLE with OpenMP

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-02-10 14:55 ---
Subject: Bug 39127

Author: rguenth
Date: Tue Feb 10 14:55:15 2009
New Revision: 144061

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144061
Log:
2009-02-10  Richard Guenther  

PR middle-end/39127
* gimplify.c (gimple_regimplify_operands): Always look if
we need to create a temporary.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39127

[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm

[siarhei dot siamashka at gmail dot com]

--- Comment #7 from siarhei dot siamashka at gmail dot com  2009-02-10 
15:11 ---
(In reply to comment #6)
> This is not a bug, but a problem with your source code.
> 
> In order to understand why, you need to pre-process the code and look at the
> output:
> 
> ...
> void *memset_arm9(void *a, int b, int c)
> {
>   return ({ uint8_t *dst = ((uint8_t *)a); uint8_t c = (b); int count = (c);
> uin
> t32_t dummy0, dummy1, dummy2; __asm__ __volatile__ (
> 
> Notice that first there is a declaration of a variable c (uint8_t), then in 
> the
> next statement there is a use of c.  This use (which is intended to be of the
> formal parameter passed to memset_arm9 is instead interpreted as the newly
> declared variable c (the uint8 one).
> 
> 
> Compiling your testcase with -Wshadow gives:
> 
> inl.c: In function 'memset_arm9':
> inl.c:66: warning: declaration of 'c' shadows a parameter
> inl.c:64: warning: shadowed declaration is here

Thanks for having a look at this. Indeed, macros are quite dangerous.

Nevertheless, would it make sense to add this -Wshadow option into the set
provided by -Wextra, or even introduce something like -Wreally-all option
specifically for debugging such cases?

Even better (but understandably not realistic) would be to have an option to
show this warning only for the code which was expanded by C preprocessor in
order to reduce the number of false positives.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[jsm28 at gcc dot gnu dot org]

--- Comment #11 from jsm28 at gcc dot gnu dot org  2009-02-10 15:17 ---
I plan to fix this for 4.5.  Testing the preliminary patch to make cpplib use
the diagnostic.c infrastructure.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jsm28 at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-01-21 03:04:29 |2009-02-10 15:17:10
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15638

[Bug target/16331] x86-64 inline asm register constraints insufficient WRT ABI

[ubizjak at gmail dot com]

--- Comment #14 from ubizjak at gmail dot com  2009-02-10 15:20 ---

> > OTOH, constraints should be used to support correct register
> > allocation for machine instructions, not to emulate ABI in order to
> > support calls from inside asm statements.
> 
> Please indulge me for a moment.
> 
> What exactly is a call?
> 
> Are you considering the only method of transferring control to be the
> standard 'near call' & 'near ret' instructions on the x86?

I was referring at the procedure call, where you need to setup outgoing
arguments on the calling point and setup incoming arguments on caller point.
gcc will magically match these two no matter what ABI-changing compile flag
(i.e. -mregparm) you use. When you call procedure from inside asm, gcc does not
know about that, and there is no way that gcc will know where arguments are to
be found.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16331

[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm

[rearnsha at gcc dot gnu dot org]

--- Comment #8 from rearnsha at gcc dot gnu dot org  2009-02-10 15:21 
---
Opinions vary wildly as to which warnings should be on by default, and which
should be part of whatever bundle.

I personally agree that shadowing variables is generally bad practice, but you
then have to be wary when porting code because you can end up shadowing things
that come from a library (different standard libraries contain all sorts of
wild and wacky variables or functions, most of which you'll never care about). 
For example:

#include 

int f()
{
  int printf = 3; return printf;
}

will generate a warning if compiled with -Wshadow (ok, that's somewhat
perverse, since every library has printf, but it makes the point).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[manu at gcc dot gnu dot org]

--- Comment #12 from manu at gcc dot gnu dot org  2009-02-10 15:24 ---
Could we take a look at the patch? I have also a half-baked patch. Are you
going to replace cpplib functions completely or just set up call-backs as C++
does? If the latter, then there is already a patch in bug 34695.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15638

[Bug target/16331] x86-64 inline asm register constraints insufficient WRT ABI

[thutt at vmware dot com]

--- Comment #15 from thutt at vmware dot com  2009-02-10 15:35 ---
(In reply to comment #14)
> > > OTOH, constraints should be used to support correct register
> > > allocation for machine instructions, not to emulate ABI in order to
> > > support calls from inside asm statements.
> >
> > Please indulge me for a moment.
> >
> > What exactly is a call?
> >
> > Are you considering the only method of transferring control to be the
> > standard 'near call' & 'near ret' instructions on the x86?
>
> I was referring at the procedure call, where you need to setup outgoing
> arguments on the calling point and setup incoming arguments on caller point.
> gcc will magically match these two no matter what ABI-changing compile flag
> (i.e. -mregparm) you use. When you call procedure from inside asm, gcc does 
> not
> know about that, and there is no way that gcc will know where arguments are to
> be found.

I understand.

I'm not expecting gcc to handle those aspects of the inline assembly.

My request is just to be able to specify any GP hardware register in a
constraint.  Both input & output.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16331

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[joseph at codesourcery dot com]

--- Comment #13 from joseph at codesourcery dot com  2009-02-10 15:35 
---
Subject: Re:  gcc should have option to treat missing
 headers as fatal

On Tue, 10 Feb 2009, manu at gcc dot gnu dot org wrote:

> Could we take a look at the patch? I have also a half-baked patch. Are you
> going to replace cpplib functions completely or just set up call-backs as C++
> does? If the latter, then there is already a patch in bug 34695.

I'll post my patch once it's passed testing.  It makes cpplib use 
callbacks unconditionally, removing cpplib's own support for printing 
diagnostics directly, and its notions of pedantic_errors, 
inhibit_warnings, warn_system_headers, inhibit_errors, warnings_are_errors 
(and client_diagnostic and cpplib's own count of errors).  I don't see any 
of the patches in bug 34695 as particularly useful in this regard.

For a library, having a single callback hook for diagnostics seems better 
to me than requiring that the library's user define functions with special 
names such as "error" and "warning".


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15638

[Bug tree-optimization/39132] wrong code generated with -ftree-loop-disttribution

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-02-10 16:12 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39132

[Bug middle-end/39127] Invalid GIMPLE with OpenMP

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-02-10 16:12 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39127

[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation

[uros at gcc dot gnu dot org]

--- Comment #9 from uros at gcc dot gnu dot org  2009-02-10 16:12 ---
Subject: Bug 39118

Author: uros
Date: Tue Feb 10 16:12:33 2009
New Revision: 144063

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144063
Log:
PR target/39118
* config/i386/i386.c (expand_prologue): Emit blockage at the end
of function prologue when frame pointer is used to access
red zone area.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118

[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation

[uros at gcc dot gnu dot org]

--- Comment #10 from uros at gcc dot gnu dot org  2009-02-10 16:13 ---
Subject: Bug 39118

Author: uros
Date: Tue Feb 10 16:12:47 2009
New Revision: 144064

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144064
Log:
PR target/39118
* config/i386/i386.c (expand_prologue): Emit blockage at the end
of function prologue when frame pointer is used to access
red zone area.


Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/i386/i386.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118

[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation

[ubizjak at gmail dot com]

--- Comment #11 from ubizjak at gmail dot com  2009-02-10 16:14 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118

[Bug tree-optimization/39132] wrong code generated with -ftree-loop-disttribution

[kazu at gcc dot gnu dot org]

--- Comment #5 from kazu at gcc dot gnu dot org  2009-02-10 16:19 ---
Thanks, Richard!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39132

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jakub at gcc dot gnu dot org]

--- Comment #28 from jakub at gcc dot gnu dot org  2009-02-10 16:22 ---
Subject: Bug 39139

Author: jakub
Date: Tue Feb 10 16:22:29 2009
New Revision: 144065

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144065
Log:
PR target/39139
* function.h (struct function): Add has_local_explicit_reg_vars
bit.
* gimplify.c (gimplify_bind_expr): Set it if local DECL_HARD_REGISTER
VAR_DECLs were seen.
* tree-ssa-live.c (remove_unused_locals): Recompute
cfun->has_local_explicit_reg_vars.
* tree-ssa-sink.c (statement_sink_location): Don't sink BLKmode
copies or clearings if cfun->has_local_explicit_reg_vars.

* gcc.target/i386/pr39139.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr39139.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.h
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-live.c
trunk/gcc/tree-ssa-sink.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139

[Bug middle-end/39124] [4.4 Regression]: -fno-exceptions leads to a ICE

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2009-02-10 16:23 ---
Subject: Bug 39124

Author: jakub
Date: Tue Feb 10 16:23:17 2009
New Revision: 144066

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144066
Log:
PR middle-end/39124
* cfgloopmanip.c (remove_path): Call remove_bbs after
cancel_loop_tree, not before it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgloopmanip.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39124

[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3

[dwarak dot rajagopal at amd dot com]

--- Comment #20 from dwarak dot rajagopal at amd dot com  2009-02-10 16:28 
---
Paulo,
(a)   movaps  (%rax, %rsi), %xmm0
  addps  %xmm0, %xmm1

(b)   movaps  %xmm0, %xmm1
  addps  (%rax, %rsi), %xmm1

Yes, case (a) is slightly better than case (b). It shouldn't matter much though
in amdfam10(shanghai) processors. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824

[Bug c/39084] [4.3/4.4 regression] ice on struct redefinition

[sje at gcc dot gnu dot org]

--- Comment #5 from sje at gcc dot gnu dot org  2009-02-10 16:33 ---
Subject: Bug 39084

Author: sje
Date: Tue Feb 10 16:33:19 2009
New Revision: 144067

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144067
Log:
PR c/39084
* c-decl.c (start_struct): Return NULL on error.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-decl.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39084

[Bug c/39084] [4.3/4.4 regression] ice on struct redefinition

[sje at gcc dot gnu dot org]

--- Comment #6 from sje at gcc dot gnu dot org  2009-02-10 16:34 ---
Subject: Bug 39084

Author: sje
Date: Tue Feb 10 16:34:30 2009
New Revision: 144068

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144068
Log:
PR c/39084
gcc.dg/pr39084.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr39084.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39084

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jakub at gcc dot gnu dot org]

--- Comment #29 from jakub at gcc dot gnu dot org  2009-02-10 16:35 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139

[Bug middle-end/39124] [4.4 Regression]: -fno-exceptions leads to a ICE

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2009-02-10 16:35 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39124

[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3

[bonzini at gnu dot org]

--- Comment #21 from bonzini at gnu dot org  2009-02-10 16:39 ---
So my patch should be a uniform win.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824

[Bug c/39084] [4.3/4.4 regression] ice on struct redefinition

[sje at gcc dot gnu dot org]

--- Comment #7 from sje at gcc dot gnu dot org  2009-02-10 16:44 ---
Subject: Bug 39084

Author: sje
Date: Tue Feb 10 16:43:49 2009
New Revision: 144070

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144070
Log:
PR c/39084
* c-decl.c (start_struct): Return NULL on error.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/c-decl.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39084

[Bug c/39084] [4.3/4.4 regression] ice on struct redefinition

[sje at gcc dot gnu dot org]

--- Comment #8 from sje at gcc dot gnu dot org  2009-02-10 16:45 ---
Subject: Bug 39084

Author: sje
Date: Tue Feb 10 16:45:37 2009
New Revision: 144071

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144071
Log:
PR c/39084
gcc.dg/pr39084.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr39084.c
Modified:
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39084

[Bug c/39084] [4.3/4.4 regression] ice on struct redefinition

[sje at cup dot hp dot com]

--- Comment #9 from sje at cup dot hp dot com  2009-02-10 16:49 ---
Fixed on mainline for 4.4.0 and on 4.3 branch for 4.3.4.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail|4.3.4 4.4.0 |4.3.3
  Known to work|4.2.3 4.3.0 |4.2.3 4.3.0 4.3.4 4.4.0
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39084

[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-02-10 17:05 ---
A patch:
  http://gcc.gnu.org/ml/fortran/2009-01/msg00325.html

Comment to the patch:
  http://gcc.gnu.org/ml/fortran/2009-02/msg00050.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979

[Bug driver/39147] New: [4.4 Regression] Gcc accepts invalid options

[hjl dot tools at gmail dot com]

Gcc accepts any -Wno-foobar, even if -Wfoobar doesn't exist:

[...@gnu-6 gcc]$ ./xgcc -B./ -Wno-foobar -S /tmp/x.c
[...@gnu-6 gcc]$ ./xgcc -B./ -Wfoobar -S /tmp/x.c
cc1: error: unrecognized command line option "-Wfoobar"
[...@gnu-6 gcc]$


-- 
   Summary: [4.4 Regression]  Gcc accepts invalid options
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39147

[Bug driver/39147] [4.4 Regression] Gcc accepts invalid options

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Known to fail||4.4.0
  Known to work||4.3.4
   Target Milestone|--- |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39147

[Bug driver/39147] [4.4 Regression] Gcc accepts invalid options

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-02-10 17:32 ---
I think this is by design.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39147

[Bug driver/39147] [4.4 Regression] Gcc accepts invalid options

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-02-10 17:40 ---
(In reply to comment #1)
> I think this is by design.
> 

It is different from gcc 4.3. Where is this feature documented?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39147

[Bug c++/23287] [4.2 regression] Explicitly invoking destructor of template class in a template and is dependent

[jason at gcc dot gnu dot org]

--- Comment #25 from jason at gcc dot gnu dot org  2009-02-10 17:51 ---
fixed for 4.3 as well, closing.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|3.3.4 4.4.0 |3.3.4 4.4.0 4.3.4
 Resolution||FIXED
Summary|[4.2/4.3 regression]|[4.2 regression] Explicitly
   |Explicitly invoking |invoking destructor of
   |destructor of template class|template class in a template
   |in a template and is|and is dependent
   |dependent   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287

[Bug driver/39147] [4.4 Regression] Gcc accepts invalid options

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-02-10 18:01 ---


*** This bug has been marked as a duplicate of 28322 ***


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39147

[Bug other/28322] GCC new warnings and compatibility

[jakub at gcc dot gnu dot org]

--- Comment #23 from jakub at gcc dot gnu dot org  2009-02-10 18:01 ---
*** Bug 39147 has been marked as a duplicate of this bug. ***


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28322

[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation

[ian at airs dot com]

--- Comment #12 from ian at airs dot com  2009-02-10 19:56 ---
I didn't get around to commenting on the patch; I'll just note that it is
conservative.  We don't have to block every instruction, just those which use
memory.

Do we have to worry about the function epilogue?  I don't see any reason why
the scheduler would move any of the pop instructions ahead of something which
references off of %rbp.  But I also don't see anything which explicitly
prevents that from happening.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118

[Bug target/39148] New: -Os increase code size when stack is aligned

[hjl dot tools at gmail dot com]

[...@gnu-6 pr39137]$ cat pr39137-3.i
void foo (unsigned long long *);

void
bar (void)
{
  unsigned long long l __attribute__ ((aligned(32)));
  foo (&l);
}
[...@gnu-6 pr39137]$ /export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-avx/build-x86_64-linux/gcc/ -m32 -Os  pr39137-3.i -S
[...@gnu-6 pr39137]$ cat pr39137-3.s
.file   "pr39137-3.i"
.text
.globl bar
.type   bar, @function
bar:
leal4(%esp), %ecx
andl$-32, %esp
pushl   -4(%ecx)
pushl   %ebp
movl%esp, %ebp
pushl   %ecx
subl$64, %esp
leal-56(%ebp), %eax
pushl   %eax
callfoo
movl-4(%ebp), %ecx
addl$16, %esp
leave
leal-4(%ecx), %esp
ret
.size   bar, .-bar
[...@gnu-6 pr39137]$ /export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-avx/build-x86_64-linux/gcc/ -m32 -O  pr39137-3.i -S
[...@gnu-6 pr39137]$ cat pr39137-3.s
.file   "pr39137-3.i"
.text
.globl bar
.type   bar, @function
bar:
pushl   %ebp
movl%esp, %ebp
andl$-32, %esp
subl$48, %esp
leal16(%esp), %eax
movl%eax, (%esp)
callfoo
leave
ret
.size   bar, .-bar
[...@gnu-6 pr39137]$ 

-Os generates bigger binary.


-- 
   Summary: -Os increase code size when stack is aligned
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148

[Bug target/39148] -Os increase code size when stack is aligned

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-02-10 20:32 ---
Created an attachment (id=17277)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17277&action=view)
A patch

Does this patch look OK? If yes, I will submit it with a couple of
testcases.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug target/39148] -Os increase code size when stack is aligned

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-02-10 20:46 ---
The problem is

static rtx
ix86_get_drap_rtx (void)
{
  if (ix86_force_drap || !ACCUMULATE_OUTGOING_ARGS)
crtl->need_drap = true; 


-Os turns off ACCUMULATE_OUTGOING_ARGS, which turns on DRAP. Does
ACCUMULATE_OUTGOING_ARGS really increase code size?


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||jh at suse dot cz, ubizjak
   ||at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2009-02-10 20:48 ---
This would mean -Os vs. -O2 gives different __alignof__(long long) values, I
think that's a bad idea.  I think a new option to disable dynamic realignment
or at least do that if estimated stack size is <= 64 bits would be better.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2009-02-10 21:02 ---
(In reply to comment #6)
> This would mean -Os vs. -O2 gives different __alignof__(long long) values, I
> think that's a bad idea.  I think a new option to disable dynamic realignment
> or at least do that if estimated stack size is <= 64 bits would be better.
> 

We do stack alignment to satisfy variable alignment requirement. You
don't want to disable it blindly. The proper way to avoid stack
alignment is to tell compiler not to align variable on stack.
We can add a new option, -malign-double=4, to align DI/DF to
4 bytes on stack.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation

[ian at airs dot com]

--- Comment #13 from ian at airs dot com  2009-02-10 21:03 ---
Created an attachment (id=17278)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17278&action=view)
Test case

This test case is from Mark Heffernan.  When compiling with -O2
-fno-omit-frame-pointer with gcc 4.3, it shows a red zone violation in the
epilogue:

movl-160(%rbp), %eax
popq%r15
leave
ret

It does work with mainline, though.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118

[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation

[ian at airs dot com]

--- Comment #14 from ian at airs dot com  2009-02-10 21:10 ---
I've verified that the problem in the epilogue occurs using the current 4.3
sources, so reopening the bug report.  (There is no longer any problem in the
prologue.)


-- 

ian at airs dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2009-02-10 21:15 ---
(In reply to comment #6)
> This would mean -Os vs. -O2 gives different __alignof__(long long) values, I

__alignof__(type) isn't that useful. The alignment of double
changes depending on

1. If it is on stack.
2. If -malign-double is used.
3. If it is used in structure.
4. If it is passed on stack.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug target/39082] union with long double doesn't follow x86-64 psABI

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2009-02-10 21:44 ---
The updated patch is at

http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00477.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
   |patches/2009-   |patches/2009-
   |02/msg00259.html|02/msg00477.html


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39082

[Bug c++/34397] [4.2/4.3/4.4 regression] ICE on invalid default template parameter

[paolo at gcc dot gnu dot org]

--- Comment #26 from paolo at gcc dot gnu dot org  2009-02-10 21:47 ---
Subject: Bug 34397

Author: paolo
Date: Tue Feb 10 21:47:12 2009
New Revision: 144083

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144083
Log:
/cp
2009-02-10  Paolo Carlini  

PR c++/34397
* typeck.c (build_x_array_ref): New.
* cp-tree.h: Declare it.
* pt.c (tsubst_copy_and_build): Use it for case ARRAY_REF.

/testsuite
2009-02-10  Paolo Carlini  

PR c++/34397
* g++.dg/template/crash88.C: New.
* g++.dg/template/crash89.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/template/crash88.C
trunk/gcc/testsuite/g++.dg/template/crash89.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397

[Bug c++/34397] [4.2/4.3 regression] ICE on invalid default template parameter

[paolo dot carlini at oracle dot com]

--- Comment #27 from paolo dot carlini at oracle dot com  2009-02-10 21:48 
---
Fixed for 4.4.0.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
   |dot com |dot org
 Status|ASSIGNED|NEW
Summary|[4.2/4.3/4.4 regression] ICE|[4.2/4.3 regression] ICE on
   |on invalid default template |invalid default template
   |parameter   |parameter


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397

[Bug c/33466] mixed-case suffix for decimal float constants

[janis at gcc dot gnu dot org]

--- Comment #3 from janis at gcc dot gnu dot org  2009-02-10 21:50 ---
Suffixes for fixed-point constants are broken as well.  GCC allows the letters
in them to be in any order, except that "ll" must be together and in the same
case.  GCC does not reject 'l' by itself as invalid.  N1169, a draft of TR
18037, says that a suffix is case-insensitive but isn't clear about whether
that means that a suffix can mix cases within a suffix or just that
all-uppercase or all-lowercase varieties are valid.

Function interpret_float_suffix in libcpp/expr.c was originally quite simple. 
It was not designed to support long suffixes like those for decimal-float and
fixed-point constants.  It will need to get even more complicated with support
for suffix 'd' for double contants (PR c/39027) and pragma
FLOAT_CONST_DECIMAL64 (PR c/39037), which specifies whether an unsuffixed float
constant is double or _Decimal64.  I'm looking at reasonable ways to rewrite
it.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||joseph at codesourcery dot
   ||com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33466

[Bug target/39149] New: Typo in i386.c

[hjl dot tools at gmail dot com]

[...@gnu-6 gcc]$ ./xgcc -B./ -malign-functions=3 /tmp/x.c -S
/tmp/x.c:1: warning: -malign-functions is obsolete, use -malign-functions

Shouldn't be

/tmp/x.c:1: warning: -malign-functions is obsolete, use -falign-functions


-- 
   Summary: Typo in i386.c
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39149

[Bug target/39149] Typo in i386.c

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39149

[Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2009-02-10 22:03 
---
Reopening to ...


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39136

[Bug target/39149] Typo in i386.c

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-02-10 22:03 ---
[...@gnu-6 gcc]$ ./xgcc -B./ -malign-loops=3 /tmp/x.c -S
/tmp/x.c:1: warning: -malign-loops is obsolete, use -malign-loops
[...@gnu-6 gcc]$ ./xgcc -B./ -malign-jumps=3 /tmp/x.c -S
/tmp/x.c:1: warning: -malign-jumps is obsolete, use -malign-jumps
[...@gnu-6 gcc]$ 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39149

[Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2009-02-10 22:03 
---
Mark this as a dup of bug 37088.

*** This bug has been marked as a duplicate of 37088 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39136

[Bug c++/37088] Functions with default parameters not correctly handled inside templates.

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-02-10 22:03 ---
*** Bug 39136 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fang at csl dot cornell dot
   ||edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37088

[Bug c/26542] bogus diagnostic with -pedantic?: format '%p'; expects type 'void*', but argument 2 has type 'A*'

[jason dot orendorff at gmail dot com]

--- Comment #9 from jason dot orendorff at gmail dot com  2009-02-10 22:22 
---
Please consider reopening this bug.

I appreciate that the relevant standards don't guarantee this idiom will always
work.  On the other hand, this warning is in practice only a nuisance.  Balance
the real work this makes for people who try to keep their code pedantic-clean
against the risk that someday an architecture will come along where it matters.

Could we maybe delete this warning just until we have some reason to believe
that such an architecture is likely to exist someday, and then reinstate it?


-- 

jason dot orendorff at gmail dot com changed:

   What|Removed |Added

 CC||jason dot orendorff at gmail
   ||dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26542

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2009-02-10 22:29 ---
Created an attachment (id=17279)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17279&action=view)
A patch to add a new -malign-double= option


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug c++/36744] [C++0x] function modifying argument received by-value affects caller's variable when passed as rvalue

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-01-31 17:25:01 |2009-02-10 22:45:16
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36744

[Bug c++/37862] Parenthesised indirection alters class member access

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2009-02-10 23:11 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37862

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[Joey dot ye at intel dot com]

--- Comment #10 from Joey dot ye at intel dot com  2009-02-11 01:03 ---
(In reply to comment #9)
> Created an attachment (id=17279)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17279&action=view) [edit]
> A patch to add a new -malign-double= option
This patch looks OK to me.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug preprocessor/34695] Preprocessor warning->error conversion from -Werror is silent

[jsm28 at gcc dot gnu dot org]

--- Comment #9 from jsm28 at gcc dot gnu dot org  2009-02-11 01:14 ---
This is fixed by my patch to make cpplib always use the diagnostic.c
infrastructure: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00491.html

(This change is the cause of the Wvariadic-1.c and Wvariadic-3.c testcase
changes in that patch.)

Thus, assigning the bug to myself.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jsm28 at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-07 20:08:47 |2009-02-11 01:14:11
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34695

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[joseph at codesourcery dot com]

--- Comment #14 from joseph at codesourcery dot com  2009-02-11 01:16 
---
Subject: Re:  gcc should have option to treat missing
 headers as fatal

I have now posted my preliminary patch: 
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00491.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15638

[Bug target/39082] union with long double doesn't follow x86-64 psABI

[mmitchel at gcc dot gnu dot org]

--- Comment #5 from mmitchel at gcc dot gnu dot org  2009-02-11 01:45 
---
Is this a regression?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39082

[Bug bootstrap/39150] New: Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).

[rob1weld at aol dot com]

I am building gcc 4.4.0 [trunk revision 144083] for OpenSolaris 2009.06 .


I have ./configured using:

../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++
--enable-shared --disable-static --enable-multilib --enable-decimal-float
--with-long-double-128 --with-included-gettext --enable-stage1-checking
--enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8
--with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld
--with-ld=/usr/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local

--

When (some) other people build for a 64-Bit Operating System and they
submit Testsuite Results the results _sometimes_ have entries like these
in: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01039.html

...
Native configuration is x86_64-unknown-linux-gnu

=== g++ tests ===

Running target unix/-m32

=== g++ Summary for unix/-m32 ===

# of expected passes6810
# of expected failures  28
# of unsupported tests  10

Running target unix

=== g++ Summary for unix ===

# of expected passes6763
# of expected failures  28
# of unsupported tests  20

=== g++ Summary ===

# of expected passes38731
# of expected failures  282
# of unsupported tests  346
/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/g++/../../g++  version 4.4.0
20090210 (experimental) [trunk revision 144083] (GCC) 
...

--


When I built gcc and submitted my Testsuite Results I do NOT get
"multilib Tests", see:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01013.html


When I 'file' gcc (built, booted in 64-Bit Mode) using the "file" command I
see:

# file /usr/local/bin/gcc
/usr/local/bin/gcc: ELF 32-bit LSB executable 80386 Version 1, dynamically
linked, not stripped

I see that as 'acceptable' but technically it is wrong. What is _great_
is that the executable will run in both 32 and 64 bit Boot Mode. So let
us _not_ fix that portion of this Bug.


The "Bug" in gcc 4.4.0 [trunk revision 144083] is that the "config.guess"
(and other related files, EG: config.host) only support the 'HTB' of
i386-pc-solaris2.* and do not support (without a little modification)
either the 'pseudo-name' (it is renamed) amd64-pc-solaris2.* _or_ 
the Target x86_64-pc-solaris2.* .


This issue starts in ../gcc_trunk/config.guess (near line 333):

...
i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*)
eval $set_cc_for_build
SUN_ARCH="i386"
# If there is a compiler, see if it is configured for 64-bit objects.
# Note that the Sun cc does not turn __LP64__ into 1 like gcc does.
# This test works for both compilers.
if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then
if (echo '#ifdef __amd64'; echo IS_64BIT_ARCH; echo '#endif') | \
(CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \
grep IS_64BIT_ARCH >/dev/null
then
SUN_ARCH="x86_64"
fi
fi


# I added this section, see:
http://defect.opensolaris.org/bz/show_bug.cgi?id=2820#c6

case "`isainfo -k`" in
amd64)
SUN_ARCH="amd64";;
*)
SUN_ARCH="i386";;
esac

echo ${SUN_ARCH}-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
exit ;;
...


Please notice that (according to the notes in the code) the supposed
purpose of that code is to determine if "it is configured for 64-bit 
objects". The code I added checks the Boot Mode (and assumes that the
compiler will work in the mode it is booted in). In doing so it alters
the Target from 'i386-pc-solaris2.11 to 'x86_64-pc-solaris2.11'.


A few fixes to files '../gcc_trunk/libjava/classpath/config.guess',
'../gcc_trunk/libgcc/config.host' and '../gcc_trunk/gcc/config.gcc'
and we are all set ...

I hope that once I have built gcc with a few small mods that I will
then be able to run the full "multilib Testsuite".


Mine (for now), Fixing, back with the diffs and Test Results,
Rob


-- 
   Summary: Configure scripts have no 64-Bit Solaris defined (only
i386-solaris*).
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
 GCC build triplet: *-solaris2*
  GCC host triplet: *-solaris2*
GCC target triplet: *-solaris2*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150

[Bug bootstrap/39151] New: If you build and install 'ppl' (and not 'cloog') then files will still link with 'ppl'.

[rob1weld at aol dot com]

I'm running OpenSolaris 2009.06, building "gcc 4.4.0 [trunk revision 144083]".

If you build and install 'ppl' (because you desire to try it) and 
choose not to build and install 'cloog' (because you do not desire 
to have it) the ./configure scripts detect ppl (and not cloog)
but files will link with 'ppl'.


If we do not have both (and they are not the correct versions) then neither
should be added to the link lines. Here it uses the wrong library and fails:

ranlib  libbackend.a
gcc -m64  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -o
cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o
c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o
c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o
c-parser.o i386-c.o sol2-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o
c-omp.o dummy-checksum.o \
  main.o tree-browser.o libbackend.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ./../intl/libintl.a 
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -L/lib -lppl_c -lppl
-lgmpxx -L/usr/local/lib -L/usr/local/lib -lmpfr -lgmp
ld: fatal: file /usr/local/lib/libppl_c.so: wrong ELF class: ELFCLASS32
ld: fatal: file /usr/local/lib/libppl.so: wrong ELF class: ELFCLASS32
ld: fatal: file processing errors. No output written to cc1-dummy
collect2: ld returned 1 exit status
gmake[3]: *** [cc1-dummy] Error 1
gmake[3]: Leaving directory `/usr/share/src/gcc_build/gcc'
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory `/usr/share/src/gcc_build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/usr/share/src/gcc_build'
gmake: *** [all] Error 2


If I recompile that with "-lppl_c -lppl" removed then 'cc1-dummy'
will build without linking errors. Do NOT link to the wrong ABI of
a library we are not even using ...

Thanks,
Rob


-- 
   Summary: If you build and install 'ppl' (and not 'cloog') then
files will still link with 'ppl'.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
 GCC build triplet: *
  GCC host triplet: *
GCC target triplet: *


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39151

[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_

[hbent at cs dot oberlin dot edu]

--- Comment #2 from hbent at cs dot oberlin dot edu  2009-02-11 04:32 
---
I am seeing this on NetBSD 5.99.7, and can confirm that this prevents gcc from
building at all on NetBSD 5.99.x.  Is there any way this can get into 4.4.0? 
It is a very simple fix and applies cleanly.


-- 

hbent at cs dot oberlin dot edu changed:

   What|Removed |Added

 CC||hbent at cs dot oberlin dot
   ||edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182

[Bug c++/36744] [C++0x] function modifying argument received by-value affects caller's variable when passed as rvalue

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2009-02-11 05:23 ---
Subject: Bug 36744

Author: jason
Date: Wed Feb 11 05:23:02 2009
New Revision: 144091

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144091
Log:
PR c++/36744
* tree.c (lvalue_p_1): Condition rvalue ref handling on
treat_class_rvalues_as_lvalues, too.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/rv9p.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36744

[Bug c++/38649] [4.4 regression] Trouble with defaulted constructors

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2009-02-11 05:23 ---
Subject: Bug 38649

Author: jason
Date: Wed Feb 11 05:23:38 2009
New Revision: 144092

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144092
Log:
PR c++/38649
* class.c (defaultable_fn_p): Handle ... properly.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/defaulted8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38649

[Bug c++/38649] [4.4 regression] Trouble with defaulted constructors

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2009-02-11 05:25 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38649

[Bug c++/36744] [C++0x] function modifying argument received by-value affects caller's variable when passed as rvalue

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2009-02-11 05:26 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36744

[Bug c++/30111] Value-initialization of POD base class doesn't initialize members

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-12-30 19:40:22 |2009-02-11 05:35:35
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111

[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation

[ubizjak at gmail dot com]

--- Comment #15 from ubizjak at gmail dot com  2009-02-11 07:09 ---
(In reply to comment #12)
> I didn't get around to commenting on the patch; I'll just note that it is
> conservative.  We don't have to block every instruction, just those which use
> memory.

True, but as described in the gcc-patches@ mailing list, this situation should
not happen often. OTOTH, if there is some standard way to insert memory
blockage no-ops, we can use these instead of unspec_volatile.

> Do we have to worry about the function epilogue?  I don't see any reason why
> the scheduler would move any of the pop instructions ahead of something which
> references off of %rbp.  But I also don't see anything which explicitly
> prevents that from happening.

We should also add blockage there.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118

[Bug target/39149] Typo in i386.c

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2009-02-11 07:15 ---
See the comment:

"... Remove this code in GCC 3.2 or later."


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39149

[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3

[xuepeng dot guo at intel dot com]

--- Comment #22 from xuepeng dot guo at intel dot com  2009-02-11 07:37 
---
(In reply to comment #18)
> Xuepeng, can you test with the loop as produced by my posted patch, that is:
> .L11:
> movaps  (%rsi,%rax), %xmm0
> addps   %xmm1, %xmm0
> movaps  %xmm0, (%rdi,%rax)
> addq$16, %rax
> cmpq%rdx, %rax
> jne .L11
> I don't have access to new enough chips.

Your patch improved the performance. My machine is "Intel(R) Core(TM)2 Quad CPU
   Q6700  @ 2.66GHz". The results are:

[xg...@shgcc-9 38824]$ time ./gcc-42.out

real0m1.991s
user0m1.990s
sys 0m0.000s
[xg...@shgcc-9 38824]$ time ./gcc-42.out

real0m1.991s
user0m1.991s
sys 0m0.001s
[xg...@shgcc-9 38824]$ time ./gcc-42.out

real0m1.991s
user0m1.989s
sys 0m0.002s
[xg...@shgcc-9 38824]$ time ./gcc-44.out

real0m1.880s
user0m1.879s
sys 0m0.001s
[xg...@shgcc-9 38824]$ time ./gcc-44.out

real0m1.878s
user0m1.878s
sys 0m0.000s
[xg...@shgcc-9 38824]$ time ./gcc-44.out

real0m1.870s
user0m1.869s
sys 0m0.002s
[xg...@shgcc-9 38824]$ time ./gcc-44p.out

real0m1.690s
user0m1.690s
sys 0m0.000s
[xg...@shgcc-9 38824]$ time ./gcc-44p.out

real0m1.690s
user0m1.689s
sys 0m0.002s
[xg...@shgcc-9 38824]$ time ./gcc-44p.out

real0m1.690s
user0m1.690s
sys 0m0.000s

The only difference is:

--- 44.s2009-02-11 15:34:57.0 +0800
+++ 44p.s   2009-02-11 15:34:49.0 +0800
@@ -102,8 +102,8 @@ _Z7bench_1PfS_fj:
.p2align 4,,10
.p2align 3
 .L11:
-   movaps  %xmm0, %xmm1
-   addps   (%rsi,%rax), %xmm1
+   movaps  (%rsi,%rax), %xmm1
+   addps   %xmm0, %xmm1
movaps  %xmm1, (%rdi,%rax)
addq$16, %rax
cmpq%rdx, %rax


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824

[Bug inline-asm/39078] Registers in on clober list are cloberred when compiled with optimization (x86_64) ?

[ubizjak at gmail dot com]

--- Comment #7 from ubizjak at gmail dot com  2009-02-11 07:50 ---
(In reply to comment #5)

> Any why you say I shouldn't call other function from inside asm ?

See for example [1].

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16331#c14


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39078