[Bug c++/39487] New: Useless -Wshadow warnings for function pointer parameters

[derefer at gmail dot com]

Consider the following function declaration:

int f(int a, int (*b)(int a));

When compiled with g++ trunk using -Wshadow, some new, probably useless,
warnings appear:

shadow.h:2: warning: declaration of 'int a' shadows a parameter
shadow.h:2: warning: shadowed declaration is here

It seems to be a C++ related issue, since gcc -Wshadow compiles this
declaration with no warnings.  As I see, the new warnings are present from
revision 140120.


-- 
   Summary: Useless -Wshadow warnings for function pointer
parameters
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: derefer at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug ada/39446] Can not resolve PUT between String and Character versions.

[mark_r_eggleston at yahoo dot co dot uk]

--- Comment #4 from mark_r_eggleston at yahoo dot co dot uk  2009-03-18 
08:59 ---
Subject: Re:  Can not resolve PUT between String and Character versions.


Sam,

Thank you that make complete sense and explains why I could only reproduce this
problem with integers ans its sub types as the parameter.

I'd forgotten all about Ada array indexing and due to a limitation of the Ada
syntax the difference between a function call and accessing an array element
look identical which is why I suppose that there are named parameters available
in subprogram calls.

Had I been using Ada longer I would have recognised the ambiguity at thogh the
time it did look to me to be an obvious bug. I apologise for wasting your time.

--- On Tue, 17/3/09, sam at gcc dot gnu dot org 
wrote:

> From: sam at gcc dot gnu dot org 
> Subject: [Bug ada/39446] Can not resolve PUT between String and Character 
> versions.
> To: mark_r_eggles...@yahoo.co.uk
> Date: Tuesday, 17 March, 2009, 2:28 PM
> 
> 
> --- Comment #3 from sam at gcc dot gnu dot org 
> 2009-03-17 14:28 ---
> This is not a bug. The compiler really has no way to
> distinguish between the
> following two interpretations for "Put (Get_Name (7))":
> 
>   1- Get_Name (7) is a call to Get_Name with argument
> 7, which returns a String
>   2- Get_Name (7) is a call to Get_Name without
> argument, which returns a
> String, and you attempt to take the 7th character of this
> string, which is a
> Character
> 
> Hence the ambiguity.
> 
> 
> -- 
> 
> sam at gcc dot gnu dot org changed:
> 
>            What 
>   |Removed           
>          |Added
> 
>              
>    CC|         
>                
>   |sam at gcc dot gnu dot org
>          
>    Status|UNCONFIRMED     
>            |RESOLVED
>          Resolution| 
>                
>           |INVALID
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39446
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> 


-- 


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

[Bug c++/39487] Useless -Wshadow warnings for function pointer parameters

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-03-18 09:00 ---


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


-- 

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=39487

[Bug c++/38022] [4.4 regression, g++] Incorrect warning with -Wshadow

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2009-03-18 09:00 ---
*** Bug 39487 has been marked as a duplicate of this bug. ***


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||derefer at gmail dot com


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

[Bug c++/39480] generated memcpy causes trouble in assignment

[jakub at gcc dot gnu dot org]

--- Comment #20 from jakub at gcc dot gnu dot org  2009-03-18 09:10 ---
So let's use memmove on alpha and let targets with sane memcpy not suffer just
because of one dead architecture.


-- 


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

[Bug target/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2009-03-18 09:11 
---
Still broken on the trunk as well.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.1.2 4.3.3 4.4.0


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

[Bug debug/39485] -O0 -g still puts whole object to a register

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-03-18 08:56 ---
Created an attachment (id=17483)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17483&action=view)
gcc44-pr39485.patch

Self inflicted pain I'd say, if you don't want something in register, don't use
a register keyword.  That said, the following patch does that for you.
In 4.3 the reason why the above testcase had v stored in memory, not in
register, has been just that it has been used in multiple basic blocks and
global allocation wasn't performed.
If you use a simpler testcase like:
struct S
{
  int x;
  int method ();
};

int
S::method ()
{
  return x + 5;
}

int
main ()
{
  register S v;
  v.x = 0;
  return v.x + 5;
}
then even g++ 4.3 and earlier will allocate v in a register and so you won't be
able to do v.method () in the debugger (though, with the attached patch you
can).
With the patch:
struct S
{
  int x;
};

int
main ()
{
  register int v;
  int i;
  v = 0;
  for (i = 0; i < 13; ++i)
v += i;
  --v;
  return v + 5;
}
will still use a register for v, but that is definitely fine.


-- 

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|UNCONFIRMED |ASSIGNED


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

[Bug c++/39480] generated memcpy causes trouble in assignment

[falk at debian dot org]

--- Comment #19 from falk at debian dot org  2009-03-18 09:06 ---
(In reply to comment #18)
> I can't imagine an implementation of memcpy that would break when the two
> addresses are the same, it just doesn't work if one is offset but 
> overlapping. 
> So the valgrind warning is pedantically correct, but I think it doesn't
> indicate a real safety issue.

As I mentioned in comment #6, it could go wrong if memcpy uses "cache prefetch
with write intent" instructions.


-- 


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

[Bug fortran/39489] New: Error in module with gfortran 4.3 in 32 bit processors.

[n dot pinhao at netvisao dot pt]

The compilation with gfortran 4.3 on i486 processors seems to produces a module
with an error. Further include of that module produces an overflow message and
aborts the compilation.
The same module compiles without problems with gfortran 4.3.2 on x86_64
processors.
I'm not sure what further information I should submit...


-- 
   Summary: Error in module with gfortran 4.3 in 32 bit processors.
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: n dot pinhao at netvisao dot pt
 GCC build triplet: Linux, i486
  GCC host triplet: Linux, i486
GCC target triplet: Linux, i486


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

[Bug c/39488] ARM ABI: enum comparison against zero optimized away

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-18 09:43 ---
a is promoted to unsigned int because the enum is unsigned.


-- 


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

[Bug c/39488] ARM ABI: enum comparison against zero optimized away

[algrant at acm dot org]

--- Comment #2 from algrant at acm dot org  2009-03-18 09:45 ---
No, the enum is signed, see AAPCS 7.1.3: "the container type is int
unless the upper bound is greater than 2147483647".


-- 


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

[Bug fortran/39489] Error in module with gfortran 4.3 in 32 bit processors.

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2009-03-18 09:46 ---
> I'm not sure what further information I should submit...

Submit a reduced test case showing the problem.


-- 


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

[Bug c++/39480] generated memcpy causes trouble in assignment

[rguenth at gcc dot gnu dot org]

--- Comment #21 from rguenth at gcc dot gnu dot org  2009-03-18 09:47 
---
For

struct A
{
  int i[200];
};

struct A *p1, *p2;
void f()
{
  *p1 = *p2;
}

we are sure that either p1 == p2 or *p1 and *p2 do not overlap because
otherwise there would be an alias violation.


-- 


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

[Bug fortran/39490] New: Non-standard assignment of arrays of character objects

[n dot pinhao at netvisao dot pt]

gfortran accepts the following syntax for the assignment of character objects:

CHARACTER(14) :: prop(4) = (/'name', 'data_file_name', 'Ho_units',
'mpolar_units'/)

Although this is convenient, is not according to the Fortran standard that
requires that all of the elements of a constructor be the same kind, type and
for characters, length.
According to this the correct syntax is:

CHARACTER(14) :: prop(4) = (/'name  ', 'data_file_name', &
  'Ho_units  ', 'mpolar_units  '/)


-- 
   Summary: Non-standard assignment of arrays of character objects
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: n dot pinhao at netvisao dot pt
 GCC build triplet: Linux, x86_64 and i486
  GCC host triplet: Linux, x86_64 and i486
GCC target triplet: Linux, x86_64 and i486


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

[Bug fortran/39489] Error in module with gfortran 4.3 in 32 bit processors.

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2009-03-18 10:01 ---
It's hard to tell without a code example, really ...


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
   Severity|blocker |normal
 Status|UNCONFIRMED |WAITING
  GCC build triplet|Linux, i486 |
   GCC host triplet|Linux, i486 |
 GCC target triplet|Linux, i486 |


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

[Bug c++/39480] generated memcpy causes trouble in assignment

[jakub at gcc dot gnu dot org]

--- Comment #24 from jakub at gcc dot gnu dot org  2009-03-18 10:11 ---
The problem with that is that in most cases you won't be able to prove it and
memmove is certainly more expensive than memcpy and usually isn't even expanded
inline (unless it is optimized into memcpy by proving non-overlap).
fold_builtin_memory_op currently optimizes memmove into memcpy only when
source is read-only or length is 1 byte, could be improved by analysis of
non-overlapping, but in many cases you really don't know if the two pointers
can or can't overlap.
Having an internal builtin for the case that either source and dest don't
overlap, or are equal could improve things, then when expanding that inline if
we knew the expanded code is ok for src == dst, we could expand it as inline
memcpy and if we didn't know that, we could add (predicted unlikely) jump
around the memcpy call (or inline expansion that is not safe for src == dst).


-- 


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

[Bug target/39491] New: [4.4 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore

[doko at ubuntu dot com]

On hppa-linux-gnu the symbol __signb...@glibcxx_3.4 isn't exported anymore (4.4
20090317 built using binutils 2.19.1 and glibc-2.9)


-- 
   Summary: [4.4 regression] symbol __signb...@glibcxx_3.4 in
libstdc++ not exported anymore
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com
GCC target triplet: hppa-linux-gnu


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

[Bug fortran/39490] Non-standard assignment of arrays of character objects

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2009-03-18 11:17 ---
Confirmed on 4.3.3, trunk gives:

pr39490.f90:1.36:

CHARACTER(14) :: prop(4) = (/'name', 'data_file_name', 'Ho_units', 'mpolar_unit
1
Error: Different CHARACTER lengths (4/14) in array constructor at (1)


-- 


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

[Bug c/39488] New: ARM ABI: enum comparison against zero optimized away

[algrant at acm dot org]

With ARM ABI variant selected by -fno-short-enums the compare shouldn't
be optimized away:

  enum RC { X, Y, Z };
  int check_error(enum RC a) { return a < 0; }

C 6.3#2 guarantees that any value of the compatible type can be assigned
to and from values of the enumerator type "with no change to the value or
the representation".  So if the implementation defines the compatible 
type to be a signed type (which ARM ABI -fno-short-enums does in this case,
see AAPCS 7.1.3), objects of the enumerator type can validly have negative
values and the test is not redundant.  (Of course, a strictly conforming
program cannot rely on this or any other property of the ABI.)

(Aside: this optimization is valid for C++, following 7.2#6.)


-- 
   Summary: ARM ABI: enum comparison against zero optimized away
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org
GCC target triplet: arm-none-eabi-gcc


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

[Bug middle-end/34109] Incorrect code for tail calls with a structure as 4th argument

[rearnsha at gcc dot gnu dot org]

--- Comment #3 from rearnsha at gcc dot gnu dot org  2009-03-18 11:49 
---
No feedback in over a year.  Presumed fixed in 4.3.0.


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug c++/39480] generated memcpy causes trouble in assignment

[fpbeekhof at gmail dot com]

--- Comment #22 from fpbeekhof at gmail dot com  2009-03-18 09:56 ---
Subject: Re:  generated memcpy causes trouble in assignment



jakub at gcc dot gnu dot org wrote:
> --- Comment #20 from jakub at gcc dot gnu dot org  2009-03-18 09:10 
> ---
> So let's use memmove on alpha and let targets with sane memcpy not suffer just
> because of one dead architecture.

1) sane memcpy, by the standard, is unsafe.

2) alpha was just an example, I vaguely remember that similar problems
were found on x86 with certain mmx instructions, but don't remember the
details.

A better approach is to use memmove by default, and memcpy when you can
prove that it's safe; rather than assuming that a "non-dead"
architecture extends the standard.

Alternatively, the following should be safe too, in accordance with
comment #21:
Foo &operator=(const Foo &rhs)
{
if (this != &rhs)
memcpy(this, &rhs, sizeof(Foo));
}
But that introduces a branch instruction.

Another safe alternative is to do what is described in comment #12.


-- 


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

[Bug c++/39480] generated memcpy causes trouble in assignment

[fpbeekhof at gmail dot com]

--- Comment #23 from fpbeekhof at gmail dot com  2009-03-18 10:04 ---
My last comment (#22) of course does not address issues pointed out by jason in
#18.

Even if "we know that we are sure that either p1 == p2 or *p1 and *p2 do not
overlap because otherwise there would be an alias violation." (comment #21)
there is a problem because if p1 == p2 then memcpy is unsafe.


-- 


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

[Bug debug/38757] gcc does not emit DW_LANG_C99

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-03-18 10:59 ---
BTW, related, we only generate DW_AT_prototyped attributes for DW_LANG_C89,
shouldn't we generate them also for DW_LANG_C99, DW_LANG_ObjC?

As lang_hooks are const, we can't modify lang_hooks.name depending on
-std={c,gnu}99 vs. -std={c,gnu}89 (for Fortran I think we don't support
-std=f77 or -std=f90, so there isn't a problem until Dwarf4 adds new
DW_LANG_Fortran* codes), so we'd need a langhook function that would return the
desired DW_LANG_* value or something like that.


-- 


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

[Bug target/39488] ARM ABI: enum comparison against zero optimized away

[jsm28 at gcc dot gnu dot org]

--- Comment #3 from jsm28 at gcc dot gnu dot org  2009-03-18 12:25 ---
The enum is unsigned by present GNU C rules.  This is a bug (that I was
already aware of, but may be hard to fix) in the AAPCS implementation,
not a front-end bug.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c   |target
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-18 12:25:28
   date||


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

[Bug target/39457] [power7-meissner] unable to find a register to spill in class 'LINK_OR_CTR_REGS'

[gnu at the-meissners dot org]

--- Comment #5 from gnu at the-meissners dot org  2009-03-18 12:48 ---
Subject: Re:   New: [power7-meissner] unable to find a
register to spill in class 'LINK_OR_CTR_REGS'

If possible, please send mail on power7 to meiss...@linux.vnet.ibm.com.  I
don't read mail on my home account (g...@the-meissners.org) as frequently as I
do on the work email.


-- 


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

[Bug debug/38757] gcc does not emit DW_LANG_C99

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-03-18 12:52 ---
Created an attachment (id=17484)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17484&action=view)
gcc44-pr38757.patch

Fix which will allow later on similar differentiation between C++98 and C++0x
or say Fortran 95 and Fortran 200{3,8} if Dwarf4 adds new DW_LANG_* codes.


-- 

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=38757

[Bug pch/39492] New: Parallel compilation fail using PCH on Windows NT>= 5.0

[agalkin at hypercom dot com]

If two parallel GCC compilation processes, which use different PCH files, run
on Windows NT version 5 or newer (e.g. Win2K, WinXP, Vista) in the same session
then a race condition occurs, which most likely leads to "Access Denied" error.

This may happen even if different toolchains are used or different projects are
compiled at the same time.

As it appears, the problem occurs because MinGW host hooks implementation uses
a single session-wide name for memory mapping object.

My suggested solution is to append current GCC process ID to that name. This
makes the mapping name unique and avoids name collisions. Below is the patch
for GCC 4.3.2 source. Tested on WinXP. As I've checked the current GCC trunk,
it has the same issue.

--- gcc/config/i386/host-mingw32.c  2007-08-02 13:49:31.0 +0300
+++ gcc/config/i386/host-mingw32.c  2009-03-17 21:00:21.422434682 +0200
@@ -120,8 +120,19 @@
  namespace when running an application in a Terminal Server
  session.  This causes failure since, by default, applications 
  don't get SeCreateGlobalPrivilege. We don't need global
- memory sharing so explicitly put object into Local namespace.  */
-   const char object_name[] = "Local\\MinGWGCCPCH";
+ memory sharing so explicitly put object into Local namespace.
+
+ There is also another issue, which appears if multiple concurrent
+ GCC processes use PCH functionality. MapViewOfFileEx returns
+ "Access Denied" error. So we need to make the session-wide mapping
+ name unique. Let's use current process ID for that. */
+  const char object_name_prefix[] = "Local\\MinGWGCCPCH-";
+
+  /* Alloc enough space for name prefix and max possible DWORD decimal
+ representation */
+  char object_name[sizeof( object_name_prefix ) + 10];
+  snprintf (object_name, sizeof(object_name), "%s%lu", object_name_prefix,
+GetCurrentProcessId());

   /* However, the documentation for CreateFileMapping says that on NT4
  and earlier, backslashes are invalid in object name.  So, we need


-- 
   Summary: Parallel compilation fail using PCH on Windows NT>= 5.0
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: pch
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: agalkin at hypercom dot com
 GCC build triplet: any
  GCC host triplet: i686-pc-mingw32
GCC target triplet: any


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[sliwa at cft dot edu dot pl]

--- Comment #21 from sliwa at cft dot edu dot pl  2009-03-18 13:25 ---
Yes, yes, using gcc has to be pain in the neck.

You are reluctant to fix an obvious mistake and instead of saying "sorry" are
keeping it broken.


-- 


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

[Bug c/39493] New: [Mips] No space for arguments when implicitely calling __get_tls_addr

[joel dot porquet at gmail dot com]

Mips ABI specifies to let the space for 4 arguments in stack when calling a
function. This is not respected when accessing tls variable with a dynamic
model: gcc implicitely calls __get_tls_addr without making rooms for the
arguments. The top of the stack is then likely to be erase.
Here is an example:

- test.c:

extern void* __get_tls_addr(void*);
extern __thread int a;
void func(void)
{
a++;
}

Compiled and linked with:

mipsel-unknown-elf-gcc -fpic -mshared -nostdinc -nostdlib -fno-builtin -mips2
-EL -mabicalls -G0 -c -o test.o test.c
mipsel-unknown-elf-ld -shared test.o -o test.so

Result in assembly:

5ffe0390 :
5ffe0390:   3c1c0001lui gp,0x1
5ffe0394:   279c9090addiu   gp,gp,-28528
5ffe0398:   0399e021addugp,gp,t9
5ffe039c:   27bdffe8addiu   sp,sp,-24
5ffe03a0:   afbf0014sw  ra,20(sp)
5ffe03a4:   afbe0010sw  s8,16(sp)
5ffe03a8:   afbcsw  s0,12(sp)
5ffe03ac:   03a0f021moves8,sp
5ffe03b0:   afbcsw  gp,0(sp)
5ffe03b4:   8f99802clw  t9,-32724(gp)
5ffe03b8:   27848030addiu   a0,gp,-32720
5ffe03bc:   0320f809jalrt9
5ffe03c0:   nop
5ffe03c4:   8fdclw  gp,0(s8)
5ffe03c8:   8c42lw  v0,0(v0)
...

We can see than $gp is saved directly at the top of the stack 0($sp), and is
likely to be erase in the callee function.

A temporarily workaround is to insert a real function call in the same function
which uses a tls variable.
Example:

extern void* __get_tls_addr(void*);
extern __thread int a;
static inline void fake(void){}
void func(void)
{
fake();
a++;
}

This result is then:
5ffe0390 :
5ffe0390:   3c1c0001lui gp,0x1
5ffe0394:   279c90c0addiu   gp,gp,-28480
5ffe0398:   0399e021addugp,gp,t9
5ffe039c:   27bdffd8addiu   sp,sp,-40
5ffe03a0:   afbf0024sw  ra,36(sp)
5ffe03a4:   afbe0020sw  s8,32(sp)
5ffe03a8:   afb0001csw  s0,28(sp)
5ffe03ac:   03a0f021moves8,sp
5ffe03b0:   afbc0010sw  gp,16(sp)
5ffe03b4:   8f828018lw  v0,-32744(gp)
5ffe03b8:   24590418addiu   t9,v0,1048
5ffe03bc:   0320f809jalrt9
5ffe03c0:   nop
5ffe03c4:   8fdc0010lw  gp,16(s8)
...

We can now see that $gp is stored at 16($sp), which gives the required spare
space for the 4 arguments in stack.


-- 
   Summary: [Mips] No space for arguments when implicitely calling
__get_tls_addr
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel dot porquet at gmail dot com
  GCC host triplet: i486-linux-gnu
GCC target triplet: mipsel-unknown-elf


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

[Bug c/39493] [Mips] No space for arguments when implicitely calling __get_tls_addr

[joel dot porquet at gmail dot com]

--- Comment #1 from joel dot porquet at gmail dot com  2009-03-18 14:06 
---
Created an attachment (id=17485)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17485&action=view)
Makefile


-- 


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

[Bug c/39493] [Mips] No space for arguments when implicitely calling __get_tls_addr

[joel dot porquet at gmail dot com]

--- Comment #2 from joel dot porquet at gmail dot com  2009-03-18 14:06 
---
Created an attachment (id=17486)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17486&action=view)
Example C file


-- 


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

Re: [Bug c/39493] New: [Mips] No space for arguments when implicitely calling __get_tls_addr

[Andrew Thomas Pinski]

Sent from my iPhone

On Mar 18, 2009, at 7:05 AM, "joel dot porquet at gmail dot com" > wrote:


Mips ABI specifies to let the space for 4 arguments in stack when  
calling a
function. This is not respected when accessing tls variable with a  
dynamic
model: gcc implicitely calls __get_tls_addr without making rooms for  
the

arguments. The top of the stack is then likely to be erase.


__get_tls_addr is a special function and does not have to follow that  
part of the ABI but a different part which should be documented about  
tls and dynamic tls.




Here is an example:

- test.c:

extern void* __get_tls_addr(void*);
extern __thread int a;
void func(void)
{
   a++;
}

Compiled and linked with:

mipsel-unknown-elf-gcc -fpic -mshared -nostdinc -nostdlib -fno- 
builtin -mips2

-EL -mabicalls -G0 -c -o test.o test.c
mipsel-unknown-elf-ld -shared test.o -o test.so

Result in assembly:

5ffe0390 :
5ffe0390:   3c1c0001lui gp,0x1
5ffe0394:   279c9090addiu   gp,gp,-28528
5ffe0398:   0399e021addugp,gp,t9
5ffe039c:   27bdffe8addiu   sp,sp,-24
5ffe03a0:   afbf0014sw  ra,20(sp)
5ffe03a4:   afbe0010sw  s8,16(sp)
5ffe03a8:   afbcsw  s0,12(sp)
5ffe03ac:   03a0f021moves8,sp
5ffe03b0:   afbcsw  gp,0(sp)
5ffe03b4:   8f99802clw  t9,-32724(gp)
5ffe03b8:   27848030addiu   a0,gp,-32720
5ffe03bc:   0320f809jalrt9
5ffe03c0:   nop
5ffe03c4:   8fdclw  gp,0(s8)
5ffe03c8:   8c42lw  v0,0(v0)
...

We can see than $gp is saved directly at the top of the stack  
0($sp), and is

likely to be erase in the callee function.

A temporarily workaround is to insert a real function call in the  
same function

which uses a tls variable.
Example:

extern void* __get_tls_addr(void*);
extern __thread int a;
static inline void fake(void){}
void func(void)
{
   fake();
   a++;
}

This result is then:
5ffe0390 :
5ffe0390:   3c1c0001lui gp,0x1
5ffe0394:   279c90c0addiu   gp,gp,-28480
5ffe0398:   0399e021addugp,gp,t9
5ffe039c:   27bdffd8addiu   sp,sp,-40
5ffe03a0:   afbf0024sw  ra,36(sp)
5ffe03a4:   afbe0020sw  s8,32(sp)
5ffe03a8:   afb0001csw  s0,28(sp)
5ffe03ac:   03a0f021moves8,sp
5ffe03b0:   afbc0010sw  gp,16(sp)
5ffe03b4:   8f828018lw  v0,-32744(gp)
5ffe03b8:   24590418addiu   t9,v0,1048
5ffe03bc:   0320f809jalrt9
5ffe03c0:   nop
5ffe03c4:   8fdc0010lw  gp,16(s8)
...

We can now see that $gp is stored at 16($sp), which gives the  
required spare

space for the 4 arguments in stack.


--
  Summary: [Mips] No space for arguments when implicitely  
calling

   __get_tls_addr
  Product: gcc
  Version: 4.3.1
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: c
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: joel dot porquet at gmail dot com
 GCC host triplet: i486-linux-gnu
GCC target triplet: mipsel-unknown-elf


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

[Bug c/39493] [Mips] No space for arguments when implicitely calling __get_tls_addr

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2009-03-18 14:22 ---
Subject: Re:   New: [Mips] No space for arguments when implicitely calling
__get_tls_addr



Sent from my iPhone

On Mar 18, 2009, at 7:05 AM, "joel dot porquet at gmail dot com"
 wrote:

> Mips ABI specifies to let the space for 4 arguments in stack when  
> calling a
> function. This is not respected when accessing tls variable with a  
> dynamic
> model: gcc implicitely calls __get_tls_addr without making rooms for  
> the
> arguments. The top of the stack is then likely to be erase.

__get_tls_addr is a special function and does not have to follow that  
part of the ABI but a different part which should be documented about  
tls and dynamic tls.

>
> Here is an example:
>
> - test.c:
>
> extern void* __get_tls_addr(void*);
> extern __thread int a;
> void func(void)
> {
>a++;
> }
>
> Compiled and linked with:
>
> mipsel-unknown-elf-gcc -fpic -mshared -nostdinc -nostdlib -fno- 
> builtin -mips2
> -EL -mabicalls -G0 -c -o test.o test.c
> mipsel-unknown-elf-ld -shared test.o -o test.so
>
> Result in assembly:
>
> 5ffe0390 :
> 5ffe0390:   3c1c0001lui gp,0x1
> 5ffe0394:   279c9090addiu   gp,gp,-28528
> 5ffe0398:   0399e021addugp,gp,t9
> 5ffe039c:   27bdffe8addiu   sp,sp,-24
> 5ffe03a0:   afbf0014sw  ra,20(sp)
> 5ffe03a4:   afbe0010sw  s8,16(sp)
> 5ffe03a8:   afbcsw  s0,12(sp)
> 5ffe03ac:   03a0f021moves8,sp
> 5ffe03b0:   afbcsw  gp,0(sp)
> 5ffe03b4:   8f99802clw  t9,-32724(gp)
> 5ffe03b8:   27848030addiu   a0,gp,-32720
> 5ffe03bc:   0320f809jalrt9
> 5ffe03c0:   nop
> 5ffe03c4:   8fdclw  gp,0(s8)
> 5ffe03c8:   8c42lw  v0,0(v0)
> ...
>
> We can see than $gp is saved directly at the top of the stack  
> 0($sp), and is
> likely to be erase in the callee function.
>
> A temporarily workaround is to insert a real function call in the  
> same function
> which uses a tls variable.
> Example:
>
> extern void* __get_tls_addr(void*);
> extern __thread int a;
> static inline void fake(void){}
> void func(void)
> {
>fake();
>a++;
> }
>
> This result is then:
> 5ffe0390 :
> 5ffe0390:   3c1c0001lui gp,0x1
> 5ffe0394:   279c90c0addiu   gp,gp,-28480
> 5ffe0398:   0399e021addugp,gp,t9
> 5ffe039c:   27bdffd8addiu   sp,sp,-40
> 5ffe03a0:   afbf0024sw  ra,36(sp)
> 5ffe03a4:   afbe0020sw  s8,32(sp)
> 5ffe03a8:   afb0001csw  s0,28(sp)
> 5ffe03ac:   03a0f021moves8,sp
> 5ffe03b0:   afbc0010sw  gp,16(sp)
> 5ffe03b4:   8f828018lw  v0,-32744(gp)
> 5ffe03b8:   24590418addiu   t9,v0,1048
> 5ffe03bc:   0320f809jalrt9
> 5ffe03c0:   nop
> 5ffe03c4:   8fdc0010lw  gp,16(s8)
> ...
>
> We can now see that $gp is stored at 16($sp), which gives the  
> required spare
> space for the 4 arguments in stack.
>
>
> -- 
>   Summary: [Mips] No space for arguments when implicitely  
> calling
>__get_tls_addr
>   Product: gcc
>   Version: 4.3.1
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: c
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: joel dot porquet at gmail dot com
>  GCC host triplet: i486-linux-gnu
> GCC target triplet: mipsel-unknown-elf
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39493
>


-- 


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

[Bug c/39493] [Mips] No space for arguments when implicitely calling __get_tls_addr

[joseph at codesourcery dot com]

--- Comment #4 from joseph at codesourcery dot com  2009-03-18 14:27 ---
Subject: Re:  [Mips] No space for arguments when implicitely
 calling __get_tls_addr

On Wed, 18 Mar 2009, pinskia at gmail dot com wrote:

> __get_tls_addr is a special function and does not have to follow that  
> part of the ABI but a different part which should be documented about  
> tls and dynamic tls.

If that's what we decide to change in this case (rather than the 
compiler), it's  that will need to be 
updated.


-- 


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

[Bug target/35180] built-in-setjmp.x2

[joel at gcc dot gnu dot org]

--- Comment #6 from joel at gcc dot gnu dot org  2009-03-18 14:27 ---
OK. I decided to look at this in more detail in the simulator.  The failing
instruction is:

 2001358:   d0 07 bf fc ld  [ %fp + -4 ], %o0

and when I run with a breakpoint there, a dump of the registers shows that fp
is 0!!  When I try to step, it doesn't happen.  If I do a "watch $fp", it never
goes to 0 and runs correctly.

The task has a 256K stack so it isn't blowing it. No interrupts are occurring. 
No context switches are occurring.

Any ideas on how to narrow this down would be appreciated.  Normal debugging
seems to be failing me.


-- 


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

[Bug c++/39494] New: Bad assembly when derived class has same name as virtual method

[james dot ashley at gmail dot com]

I'm sorry...I don't know what "triplet" means.  There was nothing about it in
the FAQ. I took my best guess.

g++ -v --version prints
g++ (Debian 4.3.2-1.1) 4.3.2

cat /proc/version prints
Linux version 2.6.26-1-686 (Debian 2.6.26-13) (wa...@debian.org) (gcc version
4.1.3 20080704 (prerelease) (Debian 4.1.2-24)) #1 SMP Sat Jan 10 18:29:31 UTC
2009

I'm using the stock g++ build that came from Debian, whatever compiler options
they use.

After I traced it down, the problem turned out to be fairly simple  [to
produce].

In what looks [to me] like the vtable for the constructor of the derived class,
the compiler's appending *INTERNAL*.

Since I don't know whether there's a page 2,

The command  gcc -c -Wall compilerBug.cpp

produces the output 

/tmp/ccHFsjIR.s: Assembler messages:
/tmp/ccHFsjIR.s:68: Warning: missing operand; zero assumed
/tmp/ccHFsjIR.s:68: Error: undefined symbol `INTERNAL' in operation

The line it's complaining about looks like this:
.long   _ZN7DerivedC1Ev *INTERNAL* 

I've boiled the precompiled source file down to

# 1 "compilerBug.cpp"
# 1 ""
# 1 ""
# 1 "compilerBug.cpp"
class Base
{
   public:
  virtual void Derived() = 0;
};

class Derived : public Base
{
   public:
  Derived();
};

Derived::Derived()
   : Base()
{}

(Everything else I tried to delete let the compiler optimize everything away).

I have no idea what the standard says about how this should actually work (or
not). Compiler error about conflicting symbols?  Warning about "this is stupid,
and you probably don't want to do it"? Or just go ahead and magically work?

Especially since the work-around's as easy as renaming either the function or
the derived class.

I just know that the FAQ says that invalid assembly output is a bug, so here we
go.

Thanks *so* much for committing time and effort to work on the compiler. It
really is the heart and soul of the entire free software movement.


-- 
   Summary: Bad assembly when derived class has same name as virtual
method
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: james dot ashley at gmail dot com
 GCC build triplet: 4.3.2
  GCC host triplet: 2.6.26-13
GCC target triplet: 2.6.26-13


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

[Bug c++/39494] Bad assembly when derived class has same name as virtual method

[james dot ashley at gmail dot com]

--- Comment #1 from james dot ashley at gmail dot com  2009-03-18 14:33 
---
Created an attachment (id=17487)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17487&action=view)
Smallest example I could come up with

Sorry, like I said in the description, I wasn't sure I'd have a chance to do
this


-- 


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

[Bug c++/39494] Bad assembly when derived class has same name as virtual method

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-03-18 14:56 ---
This means that a reference to an abstract function is emitted which should
have been cloned.  EDG accepts this testcase so I qualify this as wrong-code
bug.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid, wrong-code
  Known to fail||3.3.6 4.0.0 4.3.3 4.4.0
   Last reconfirmed|-00-00 00:00:00 |2009-03-18 14:56:55
   date||


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

[Bug c++/39425] [4.2/4.3/4.4 Regression] gcc loops after reporting template instantiation errors

[hjl at gcc dot gnu dot org]

--- Comment #4 from hjl at gcc dot gnu dot org  2009-03-18 14:57 ---
Subject: Bug 39425

Author: hjl
Date: Wed Mar 18 14:56:45 2009
New Revision: 144932

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

2009-03-18  H.J. Lu  

PR c++/39425
* parser.c (cp_parser_explicit_specialization): Don't skip the
rest of the specialization when begin_specialization returns
false.

gcc/testsuite/

2009-03-18  H.J. Lu  

PR c++/39425
* g++.dg/template/pr39425.C: New.

* g++.dg/template/spec33.C: Updated.

Added:
trunk/gcc/testsuite/g++.dg/template/pr39425.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/template/spec33.C


-- 


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

[Bug c++/39425] [4.2/4.3/4.4 Regression] gcc loops after reporting template instantiation errors

[hjl at gcc dot gnu dot org]

--- Comment #5 from hjl at gcc dot gnu dot org  2009-03-18 15:00 ---
Subject: Bug 39425

Author: hjl
Date: Wed Mar 18 15:00:32 2009
New Revision: 144933

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

2009-03-18  H.J. Lu  

Backport from mainline:
2009-03-18  H.J. Lu  

PR c++/39425
* parser.c (cp_parser_explicit_specialization): Don't skip the
rest of the specialization when begin_specialization returns
false.

gcc/testsuite/

2009-03-18  H.J. Lu  

Backport from mainline:
2009-03-18  H.J. Lu  

PR c++/39425
* g++.dg/template/pr39425.C: New.

* g++.dg/template/spec33.C: Updated.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/pr39425.C
  - copied unchanged from r144932,
trunk/gcc/testsuite/g++.dg/template/pr39425.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/parser.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/spec33.C


-- 


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

[Bug fortran/39489] Error in module with gfortran 4.3 in 32 bit processors.

[n dot pinhao at netvisao dot pt]

--- Comment #3 from n dot pinhao at netvisao dot pt  2009-03-18 15:06 
---
Created an attachment (id=17488)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17488&action=view)
Streamlined module files reproducing the error

See the README for compilation instructions


-- 


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

[Bug fortran/39489] Error in module with gfortran 4.3 in 32 bit processors.

[n dot pinhao at netvisao dot pt]

--- Comment #4 from n dot pinhao at netvisao dot pt  2009-03-18 15:08 
---
The code was tested only with gfortran 4.3.2


-- 


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

[Bug fortran/39489] Error in module with gfortran 4.3 in 32 bit processors.

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2009-03-18 15:44 ---
On powerpc-apple-darwin9 with gfortran 4.3.3 (with or without -m64) I get:

[karma] Downloads/gftest% gfortran -c MpkBase.f95
MpkBase.f95:831.17:

END MODULE pkBase
 1
Internal Error at (1):
gfc_code2string(): Bad code

MpkBase.f95 compiles with gfortran from trunk. However I got many errors with
MpkData.f95:

MpkData.f95:598.70:

IF( p_energy%value == 0 ) p_energy%value = Species(j)%p_energy
  1
Error: 'p_energy' at (1) is not a member of the 'particle' structure
MpkData.f95:680.60:

initial_conc%value, mpolar, data_file, gains, losses )
1
Error: Too many components in structure constructor at (1)!
...
MpkData.f95:93.30:

call pkReadData( UI, FMT, IOError(3) )
  1
Warning: Actual argument contains too few elements for dummy argument 'iostat'
(1/3) at (1)
MpkData.f95:95.32:

call pkReadData( UI, iostat=IOError(3) )
1
Warning: Actual argument contains too few elements for dummy argument 'iostat'
(1/3) at (1)

Too many errors to have chance to fix them right now.


-- 


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

[Bug c++/39494] Bad assembly when derived class has same name as virtual method

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-03-18 16:16 ---
Icc ia32 generates:

_ZTV7Derived:
.type   _ZTV7Derived,@object
.size   _ZTV7Derived,12
.long   0   
.long   _ZTI7Derived
.long   __cxa_pure_virtual

Gcc generates:

.size   _ZTV7Derived, 24
_ZTV7Derived:
.long   0
.long   _ZTI7Derived
.long   __cxa_pure_virtual
.long   _ZN7DerivedC1Ev *INTERNAL*
.long   _ZN7DerivedC2Ev
.long   _ZN7DerivedC1Ev


-- 


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

[Bug fortran/39489] [4.3 Regression] write_atom(): Writing negative integer

[dfranke at gcc dot gnu dot org]

--- Comment #6 from dfranke at gcc dot gnu dot org  2009-03-18 16:35 ---
With 4.3.4 (20090318) I get:

$> gfortran-4.3 -o test MpkCommon.f95 MpkBase.f95 MpkData.f95 teste.f95
MpkBase.f95:831.17:

END MODULE pkBase
 1
Internal Error at (1):
write_atom(): Writing negative integer
Fatal Error: Reading module pkbase at line 358 column 47: Expected integer
Fatal Error: Reading module pkbase at line 358 column 47: Expected integer


but 4.2 (20090203) and 4.4 (20090317, to be released soonish) give:
$> gfortran-svn -o test MpkCommon.f95 MpkBase.f95 MpkData.f95 teste.f95
MpkData.f95:598.70:

IF( p_energy%value == 0 ) p_energy%value = Species(j)%p_energy
  1
Error: 'p_energy' at (1) is not a member of the 'particle' structure
MpkData.f95:680.60:

initial_conc%value, mpolar, data_file, gains, losses )
1
Error: Too many components in structure constructor at (1)!
MpkData.f95:735.34:

  ELSE IF (Species(i)%constant) THEN
  1
Error: 'constant' at (1) is not a member of the 'particle' structure
MpkData.f95:739.33:

  ELSE IF( Species(i)%cascade ) THEN
 1
Error: 'cascade' at (1) is not a member of the 'particle' structure
MpkData.f95:774.29:

  IF (Species(i)%constant) THEN
 1
Error: 'constant' at (1) is not a member of the 'particle' structure
MpkData.f95:777.36:

Species(i)%name /= 'e') THEN
1
Error: Unexpected ELSE IF statement at (1)
MpkData.f95:783.43:

  ELSE IF( Species(i)%name == 'e') THEN
   1
Error: Unexpected ELSE IF statement at (1)
MpkData.f95:785.58:

  ELSE IF( INDEX(Species(i)%name, 'photon') /= 0) THEN
  1
Error: Unexpected ELSE IF statement at (1)
MpkData.f95:787.33:

  ELSE IF( Species(i)%cascade) THEN
 1
Error: 'cascade' at (1) is not a member of the 'particle' structure
MpkData.f95:790.65:

( Species(i)%v == -1 .and. Species(i)%energy > 0 ) ) THEN
 1
Error: Unexpected ELSE IF statement at (1)
MpkData.f95:792.47:

  ELSE  ! .not. Species(i)%constant
   1
Error: Unexpected ELSE statement at (1)
MpkData.f95:794.9:

  END IF
 1
Error: Expecting END DO statement at (1)
MpkData.f95:2061.55:

  mask=Kreac(i)%Nreactants(:)>0) )%p_energy ) &
   1
Error: 'p_energy' at (1) is not a member of the 'particle' structure
MpkData.f95:2091.54:

  mask=Kreac(i)%Nproducts(:)>0) )%p_energy ) + &
  1
Error: 'p_energy' at (1) is not a member of the 'particle' structure
MpkData.f95:2112.51:

mask=Kreac(i)%Nproducts(:)>0))%p_energy ) + &
   1
Error: 'p_energy' at (1) is not a member of the 'particle' structure
MpkData.f95:2394.75:

  Index = i; name = Species(i)%name; constant = Species(i)%constant
   1
Error: 'constant' at (1) is not a member of the 'particle' structure
MpkData.f95:2395.38:

  cascade = Species(i)%cascade; charge = Species(i)%charge
  1
Error: 'cascade' at (1) is not a member of the 'particle' structure
MpkData.f95:2397.40:

  p_energy = Species(i)%p_energy; energy = Species(i)%energy
1
Error: 'p_energy' at (1) is not a member of the 'particle' structure
MpkData.f95:93.30:

call pkReadData( UI, FMT, IOError(3) )
  1
Warning: Actual argument contains too few elements for dummy argument 'iostat'
(1/3) at (1)
MpkData.f95:95.32:

call pkReadData( UI, iostat=IOError(3) )
1
Warning: Actual argument contains too few elements for dummy argument 'iostat'
(1/3) at (1)


As the error does not occur in trunk, I believe it is unlikely that it will be
fixed in the branch.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
  Known to fail||4.3.4
 

[Bug target/35180] built-in-setjmp.x2

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2009-03-18 16:56 
---
> OK. I decided to look at this in more detail in the simulator.  The failing
> instruction is:
> 
>  2001358:   d0 07 bf fc ld  [ %fp + -4 ], %o0
> 
> and when I run with a breakpoint there, a dump of the registers shows that
> fp is 0!!  When I try to step, it doesn't happen.  If I do a "watch $fp",
> it never goes to 0 and runs correctly.

Looks like the current register window is not flushed before the setjmp.  You
need to investigate whether traps work correctly on the simulator.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


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

[Bug debug/39485] -O0 -g still puts whole object to a register

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-03-18 17:06 ---
Subject: Bug 39485

Author: jakub
Date: Wed Mar 18 17:06:15 2009
New Revision: 144939

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144939
Log:
PR debug/39485
* function.c (use_register_for_decl): When not optimizing, disregard
register keyword for variables with types containing methods.

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


-- 


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

[Bug target/35180] built-in-setjmp.x2

[joel at gcc dot gnu dot org]

--- Comment #8 from joel at gcc dot gnu dot org  2009-03-18 17:12 ---
(In reply to comment #7)
> > OK. I decided to look at this in more detail in the simulator.  The failing
> > instruction is:
> > 
> >  2001358:   d0 07 bf fc ld  [ %fp + -4 ], %o0
> > 
> > and when I run with a breakpoint there, a dump of the registers shows that
> > fp is 0!!  When I try to step, it doesn't happen.  If I do a "watch $fp",
> > it never goes to 0 and runs correctly.
> 
> Looks like the current register window is not flushed before the setjmp.  You
> need to investigate whether traps work correctly on the simulator.
> 

I think I see this now.  It looks like "ta 3" is not flush on RTEMS.   I am
going to have to talk with some of the SPARC RTEMS folks to make sure and
address this one.  Leave it open.  I am reassigning this to me since it
looks RTEMS run-time specific.


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |joel at gcc dot gnu dot org
   |dot org |


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

[Bug fortran/39489] [4.3 Regression] write_atom(): Writing negative integer

[n dot pinhao at netvisao dot pt]

--- Comment #7 from n dot pinhao at netvisao dot pt  2009-03-18 17:44 
---
Created an attachment (id=17489)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17489&action=view)
Streamlined module files reproducing the error (2)

Test files with a corrected version of MpkData.f95.
With gfortran 4.3.2 in i486 both MpkCommon.f95 and MpkBase.f95 files compile
without errors but the instruction "gfortran -c MpkData.f95" produces the
following error message:
Fatal Error: Reading module pkbase at line 22 column 20: Integer overflow


-- 

n dot pinhao at netvisao dot pt changed:

   What|Removed |Added

  Attachment #17488|0   |1
is obsolete||


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

[Bug target/39386] [avr] different computation results for O1 and O0 executables

[eric dot weddington at atmel dot com]

--- Comment #2 from eric dot weddington at atmel dot com  2009-03-18 17:47 
---
Confirmed with gcc 4.3.2.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.3.3 4.3.2
   Last reconfirmed|-00-00 00:00:00 |2009-03-18 17:47:31
   date||


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

[Bug fortran/39489] [4.3 Regression] write_atom(): Writing negative integer

[n dot pinhao at netvisao dot pt]

--- Comment #8 from n dot pinhao at netvisao dot pt  2009-03-18 17:48 
---
The code compiles with gfortran 4.2 without problems.


-- 

n dot pinhao at netvisao dot pt changed:

   What|Removed |Added

 CC||n dot pinhao at netvisao dot
   ||pt


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

[Bug middle-end/39447] ICE in create_data_ref with -O1 -floop-interchange

[spop at gcc dot gnu dot org]

--- Comment #8 from spop at gcc dot gnu dot org  2009-03-18 17:48 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/39485] -O0 -g still puts whole object to a register

[jan dot kratochvil at redhat dot com]

--- Comment #3 from jan dot kratochvil at redhat dot com  2009-03-18 18:01 
---
I see I messed it up, in some way was gcc-4.4 more correct than gcc-4.3
Thanks for the fix although now I would not probably bugreport it at all.

It turned PASS->XFAIL.
But in fact PASS means SKIP(not-testable) and XFAIL means PASS - for GDB.

gdb.cp/classes.exp:
# This class is so small that an instance of it can fit in a register.
# When gdb tries to call a method, it gets embarrassed about taking
# the address of a register.
#
# TODO: I think that message should be a PASS, not an XFAIL.
# gdb prints an informative message and declines to do something
# impossible.
#
# The method call actually succeeds if the compiler allocates very
# small classes in memory instead of registers.  So this test does
# not tell us anything interesting if the call succeeds.


-- 


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

[Bug target/35180] built-in-setjmp.x2

[joel at gcc dot gnu dot org]

--- Comment #9 from joel at gcc dot gnu dot org  2009-03-18 18:18 ---
Jiri Gaisler confirms there is no "ta 3" handler in RTEMS currently.  He will
be adding it to RTEMS.


-- 


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

[Bug debug/39485] -O0 -g still puts whole object to a register

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-03-18 18:48 ---
Anyway, I consider this fixed.  If gdb wants to test also what happens with
such classes in registers, it can always use -O1 or above.


-- 

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=39485

[Bug target/35180] built-in-setjmp.x2

[ebotcazou at gcc dot gnu dot org]

--- Comment #10 from ebotcazou at gcc dot gnu dot org  2009-03-18 18:54 
---
Subject: Bug 35180

Author: ebotcazou
Date: Wed Mar 18 18:54:31 2009
New Revision: 144942

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144942
Log:
PR target/35180
* config/sparc/sparc.md (do_builtin_setjmp_setup): Prettify asm output.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.md


-- 


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

[Bug fortran/39490] Non-standard assignment of arrays of character objects

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-03-18 19:12 ---
> Confirmed on 4.3.3

Well, I get also with 4.3.x an error with -std=f95.

The question is rather: Is is on purpose that it is rejected with -std=gnu with
4.4, while 4.2/4.3 accept it. (g95, sunf95 and NAG f95 reject it; while ifort
and openf95 accept it with default options.)

Another version of legal code is:

CHARACTER(14) :: prop(4) = (/ character(14) :: 'name', 'data_file_name',
'Ho_units','mpolar_units'/)


-- 


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

[Bug c/39495] New: OMP parallel loop w/ unsigned index var rejected

[brian dot e dot bliss at intel dot com]

% cat test.c

#include 
#include 

void foo(unsigned ub, unsigned *array)
{
unsigned i;

// test passes for N >= 1
#define N   0

#pragma omp for
for (i = ub; i > N; i -=2) {
array[i] = i;
}
}

% gcc -fopenmp -c test.c
test.c: In function ΓÇÿfooΓÇÖ:
test.c:13: error: invalid controlling predicate
% gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /net/gnu-13/export/gnu/src/gcc/gcc/configure --enableclocale=g
nu --with-system-zlib --enable-checking=assert --with-demangler-in-ld
--enable-shared --enable-threads=posix --enable-haifa --prefix=/usr/gcc-4.4
--with-local-prefix=/usr/local
Thread model: posix
gcc version 4.4.0 20090311 (experimental) [trunk revision 144788] (GCC)

Aparrently, the compiler is trying to prevent the user from accidentally
running into an infinite loop, if the value of lb is odd.  Nonetheless, the
program is legal if lb is even, but it won't compile.


-- 
   Summary: OMP parallel loop w/ unsigned index var rejected
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brian dot e dot bliss at intel dot com


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

[Bug c/39495] OMP parallel loop w/ unsigned index var rejected

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-18 20:49 ---
This is likely because fold canonicalizes i > 0 to i != 0 for unsigned i which
is a predicate not handled by c_finish_omp_for.  Likely the same issue exists
for other frontends.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2009-03-18 20:49:57
   date||


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

[Bug middle-end/39497] New: dfp.c:239: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules

[hjl dot tools at gmail dot com]

On Linux/x86-64, I got

/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c: In function ‘encode_decimal32’:
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:142: warning: dereferencing
type-punned pointer will break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c: In function ‘decode_decimal32’:
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:158: warning: dereferencing
type-punned pointer will break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c: In function ‘encode_decimal64’:
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:182: warning: dereferencing
type-punned pointer will break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:188: warning: dereferencing
type-punned pointer will break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c: In function ‘decode_decimal64’:
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:207: warning: dereferencing
type-punned pointer will break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:212: warning: dereferencing
type-punned pointer will break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c: In function
‘encode_decimal128’:
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:238: warning: dereferencing
type-punned pointer will break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:248: warning: dereferencing
type-punned pointer will break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c: In function
‘decode_decimal128’:
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:267: warning: dereferencing
type-punned pointer will break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:274: warning: dereferencing
type-punned pointer will break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:267: warning: dereferencing
pointer ‘({anonymous})’ does break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:267: note: initialized from here
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:268: warning: dereferencing
pointer ‘({anonymous})’ does break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:268: note: initialized from here
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:269: warning: dereferencing
pointer ‘({anonymous})’ does break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:269: note: initialized from here
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:270: warning: dereferencing
pointer ‘({anonymous})’ does break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:270: note: initialized from here
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c: In function
‘encode_decimal128’:
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:238: warning: dereferencing
pointer ‘({anonymous})’ does break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:238: note: initialized from here
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:239: warning: dereferencing
pointer ‘({anonymous})’ does break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:239: note: initialized from here
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:240: warning: dereferencing
pointer ‘({anonymous})’ does break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:240: note: initialized from here
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:241: warning: dereferencing
pointer ‘({anonymous})’ does break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:241: note: initialized from here
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c: In function ‘decode_decimal32’:
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:158: warning: dereferencing
pointer ‘({anonymous})’ does break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:158: note: initialized from here
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c: In function ‘encode_decimal64’:
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:182: warning: dereferencing
pointer ‘({anonymous})’ does break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:182: note: initialized from here
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:183: warning: dereferencing
pointer ‘({anonymous})’ does break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:183: note: initialized from here
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c: In function ‘decode_decimal64’:
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:207: warning: dereferencing
pointer ‘({anonymous})’ does break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:207: note: initialized from here
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:208: warning: dereferencing
pointer ‘({anonymous})’ does break strict-aliasing rules


-- 
   Summary: dfp.c:239: warning: dereferencing pointer
'({anonymous})' does break strict-aliasing rules
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRM

[Bug target/39496] GCC uses non-standard calling conventions for static functions with -O0.

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-03-18 21:14 ---
"even though the standard IA-32 calling conventions pass the
first argument on the stack"

I thought this was disabled at -O0.  At -O1 this should be enabled.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |target
Summary|GCC uses non-standard   |GCC uses non-standard
   |calling conventions, even   |calling conventions for
   |with -O0|static functions with -O0.


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

[Bug bootstrap/39497] dfp.c:239: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Component|middle-end  |bootstrap
   Target Milestone|--- |4.4.0


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

[Bug middle-end/39497] dfp.c:239: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-03-18 21:16 ---
Related to PR 37897.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|bootstrap   |middle-end
   Target Milestone|4.4.0   |---


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

[Bug c++/39496] New: GCC uses non-standard calling conventions, even with -O0

[jimb at red-bean dot com]

Even when compiling with -O0, GCC uses non-standard parameter passing
conventions for static inline functions, which makes debugging difficult.

In this case, the function of interest converts a tagged value to a pointer;
it's very helpful to be able to use this in GDB 'print' commands.

In the assembly code shown, notice that the function is expecting to find its
argument in %eax, even though the standard IA-32 calling conventions pass the
first argument on the stack.  The GDB session also demonstrates this.

$ (cd ~/gcc/gcc; svn info)
Path: .
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 144927
Node Kind: directory
Schedule: normal
Last Changed Author: gccadmin
Last Changed Rev: 144927
Last Changed Date: 2009-03-17 17:16:40 -0700 (Tue, 17 Mar 2009)

$ cat jsobj.i
extern "C"
{
  static inline struct JSObject *JSVAL_TO_OBJECT (int v)
  {
return (struct JSObject *) (v & ~3);
  }
}
static int
obj_toSource (int *vp)
{
  JSVAL_TO_OBJECT (vp[0]);
}
int
main(int argc, char **argv)
{
}
$ c++ -v -O0 -g jsobj.i -o jsobj -save-temps
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/jimb/gcc
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.0 20090318 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-O0' '-g' '-o' 'jsobj' '-save-temps' '-shared-libgcc'
'-mtune=generic'
 /home/jimb/gcc/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1plus -fpreprocessed
jsobj.i -quiet -dumpbase jsobj.i -mtune=generic -auxbase jsobj -g -O0 -version
-o jsobj.s
GNU C++ (GCC) version 4.4.0 20090318 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.4.0 20090318 (experimental), GMP version
4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 00b593c3c99bbacc875575ff2b6655cc
COLLECT_GCC_OPTIONS='-v' '-O0' '-g' '-o' 'jsobj' '-save-temps' '-shared-libgcc'
'-mtune=generic'
 as -V -Qy -o jsobj.o jsobj.s
GNU assembler version 2.18.93 (i486-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.18.93.20081009
COMPILER_PATH=/home/jimb/gcc/libexec/gcc/i686-pc-linux-gnu/4.4.0/:/home/jimb/gcc/libexec/gcc/i686-pc-linux-gnu/4.4.0/:/home/jimb/gcc/libexec/gcc/i686-pc-linux-gnu/:/home/jimb/gcc/lib/gcc/i686-pc-linux-gnu/4.4.0/:/home/jimb/gcc/lib/gcc/i686-pc-linux-gnu/
LIBRARY_PATH=/home/jimb/gcc/lib/gcc/i686-pc-linux-gnu/4.4.0/:/home/jimb/gcc/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-O0' '-g' '-o' 'jsobj' '-save-temps' '-shared-libgcc'
'-mtune=generic'
 /home/jimb/gcc/libexec/gcc/i686-pc-linux-gnu/4.4.0/collect2 --eh-frame-hdr -m
elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o jsobj /usr/lib/crt1.o
/usr/lib/crti.o /home/jimb/gcc/lib/gcc/i686-pc-linux-gnu/4.4.0/crtbegin.o
-L/home/jimb/gcc/lib/gcc/i686-pc-linux-gnu/4.4.0
-L/home/jimb/gcc/lib/gcc/i686-pc-linux-gnu/4.4.0/../../.. jsobj.o -lstdc++ -lm
-lgcc_s -lgcc -lc -lgcc_s -lgcc
/home/jimb/gcc/lib/gcc/i686-pc-linux-gnu/4.4.0/crtend.o /usr/lib/crtn.o
$ cat jsobj.s
...
JSVAL_TO_OBJECT:
.LFB0:
.file 1 "jsobj.i"
.loc 1 4 0
.cfi_startproc
.cfi_personality 0x0,__gxx_personality_v0
pushl   %ebp
.cfi_def_cfa_offset 8
movl%esp, %ebp
.cfi_offset 5, -8
.cfi_def_cfa_register 5
subl$4, %esp
movl%eax, -4(%ebp)
.loc 1 5 0
movl-4(%ebp), %eax
andl$-4, %eax
.loc 1 6 0
leave
ret
...
$ gdb jsobj
GNU gdb (GDB) 6.8.50.20090106-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) start
Temporary breakpoint 1 at 0x804844c: file jsobj.i, line 16.
Starting program: /home/jimb/mc/b/static-call/jsobj 

Temporary breakpoint 1, main (argc=1, argv=0xb8a4) at jsobj.i:16
16  }
Current language:  auto; currently c++
(gdb) set $eax = 0x42424242
(gdb) print JSVAL_TO_OBJECT(0x53535353)
$1 = (struct JSObject *) 0x42424240
(gdb) quit
The program is running.  Quit anyway (and kill it)? (y or n) y
$


-- 
   Summary: GCC uses non-standard calling conventions, even with -O0
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jimb at red-bean dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/39496] GCC uses non-standard calling conventions, even with -O0

[jimb at red-bean dot com]

--- Comment #1 from jimb at red-bean dot com  2009-03-18 21:11 ---
Created an attachment (id=17490)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17490&action=view)
Test case

This is the same test case used in the transcript; attached just for
convenience.


-- 


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

[Bug middle-end/39497] dfp.c:239: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-03-18 21:24 ---
A patch to build dfp.c with -fno-strict-aliasing is pre-approved (just use the
dfp.o-warn variable in Makefile.in)


-- 


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

[Bug target/39496] [4.2/4.3/4.4 Regression] GCC uses non-standard calling conventions for static functions with -O0.

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-03-18 21:32 ---
Confirmed.  In 3.3 this worked (was probably not implemented).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.0.4 4.3.3 4.4.0
  Known to work||3.3.6
   Last reconfirmed|-00-00 00:00:00 |2009-03-18 21:32:10
   date||
Summary|GCC uses non-standard   |[4.2/4.3/4.4 Regression] GCC
   |calling conventions for |uses non-standard calling
   |static functions with -O0.  |conventions for static
   ||functions with -O0.
   Target Milestone|--- |4.2.5
Version|unknown |4.4.0


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

[Bug middle-end/39497] dfp.c:239: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-03-18 21:33 ---
Confirmed.  dfp.c is crap.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||build, wrong-code
   Last reconfirmed|-00-00 00:00:00 |2009-03-18 21:33:49
   date||


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

[Bug ada/39498] New: [4.4 Regression] ACATS test c94001c fails

[andreasmeier80 at gmx dot de]

I see the ACATS test c94001c failing in revision 144928 on i686-pc-linux-gnu,
in revision 144811 it was okay.


-- 
   Summary: [4.4 Regression] ACATS test c94001c fails
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andreasmeier80 at gmx dot de


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

[Bug ada/39498] [4.4 Regression] ACATS test c94001c fails

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-18 21:55 ---
It works here:

http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg01891.html

can you reproduce it?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug target/39496] [4.2/4.3/4.4 Regression] GCC uses non-standard calling conventions for static functions with -O0.

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-03-18 21:56 ---
  /* Use register calling convention for local functions when possible.  */
  if (decl && TREE_CODE (decl) == FUNCTION_DECL
  && !profile_flag)


That should include !optimize I think.


-- 


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

[Bug target/39496] [4.2/4.3/4.4 Regression] GCC uses non-standard calling conventions for static functions with -O0.

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-03-18 21:57 ---
We used to check flag_unit_at_a_time in this function:
  /* Use register calling convention for local functions when possible.  */
  if (decl && TREE_CODE (decl) == FUNCTION_DECL
  && flag_unit_at_a_time && !profile_flag)

Which meant it never worked for C++ in 3.4 and above , for C, it always worked
until 4.4 which removed the check.


-- 


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

[Bug target/32542] When -msdata is set, gcc sent -memb to gas.

[bje at gcc dot gnu dot org]

--- Comment #1 from bje at gcc dot gnu dot org  2009-03-18 22:11 ---
Invoking gcc with every possible argument to -msdata, I see:

eabi
 "./as" "-mppc" "-many" "-Qy" "-memb" "-o" "foo.o" "/tmp/ccVvv3TA.s"
sysv
 "./as" "-mppc" "-many" "-Qy" "-o" "foo.o" "/tmp/ccdORyjE.s"
default
 "./as" "-mppc" "-many" "-Qy" "-o" "foo.o" "/tmp/ccF1e9nC.s"
data
 "./as" "-mppc" "-many" "-Qy" "-o" "foo.o" "/tmp/ccxu9bXC.s"
none
 "./as" "-mppc" "-many" "-Qy" "-o" "foo.o" "/tmp/ccrsxKQF.s"

These all look correct.  The bare -msdata option produces:

 "./as" "-mppc" "-many" "-Qy" "-memb" "-o" "foo.o" "/tmp/ccdImACc.s"

I don't think it should be passing -memb on a GNU/Linux system by default.


-- 


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

[Bug ada/39498] [4.4 Regression] ACATS test c94001c fails

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-03-18 22:19 ---
-- THIS TEST CONTAINS SHARED VARIABLES AND RACE CONDITIONS.


-- 


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

[Bug ada/39498] [4.4 Regression] ACATS test c94001c fails

[laurent at guerby dot net]

--- Comment #3 from laurent at guerby dot net  2009-03-18 22:22 ---
One ACTS test fail are usually due to some race, could you look at the exact
message related to the FAIL in build/gcc/testsuite/ada/acats/acats.log?


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net


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

[Bug ada/39498] [4.4 Regression] ACATS test c94001c fails

[ebotcazou at gcc dot gnu dot org]

--- Comment #4 from ebotcazou at gcc dot gnu dot org  2009-03-18 22:24 
---
Please post the failure message when you report failures.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


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

[Bug target/38609] [4.4 Regression]: gcc.c-torture/execute/built-in-setjmp.c execute -O2 and above

[hp at gcc dot gnu dot org]

--- Comment #12 from hp at gcc dot gnu dot org  2009-03-18 22:24 ---
(In reply to comment #11)
> I think you may need a frame pointer for
> 
>   if (cfun->calls_alloca
>   || cfun->has_nonlocal_label
>   || crtl->has_nonlocal_goto)

That should be covered by the generic code, not the target's
FRAME_POINTER_REQUIRED, and besides, for this target (if I decode defaults.h
correctly, and what seems intuitively correct):

> See expand_stack_alignment in cfgexpand.c.

For this target (if I decode defaults.h correctly, and what seems intuitively
correct):

  if (! SUPPORTS_STACK_ALIGNMENT)
return;

No, this seems more like a case of reload not being able to keep track of
stack-pointer adjustments.  Actually, I see that for all labels that are
reachable by indirect jumps, it assumes they are reached only by locations that
have the initial elimination offsets.  Instead, it should bail out on those
(signalling that the offset is not known), always or optionally, if there is
any call or any indirect jump in the function that does not have the initial
elimination offset or optionally (set it to the offsets for the first), and if
any call or indirect jump has different elimination offsets, bail out.


-- 


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

[Bug middle-end/38609] [4.4 Regression]: gcc.c-torture/execute/built-in-setjmp.c execute -O2 and above

[hp at gcc dot gnu dot org]

--- Comment #13 from hp at gcc dot gnu dot org  2009-03-18 22:29 ---
Noticed bug in middle-end (reload1.c:set_label_offsets) changing to middle-end.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|target  |middle-end


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

[Bug middle-end/39499] New: [4.4 Regression]: gcc.c-torture/execute/built-in-setjmp.c execute -O2 and above

[hp at gcc dot gnu dot org]

+++ This bug was initially created as a clone of Bug #38609 +++

See PR38609 comment 12.
I noticed that reload1.c:set_label_offsets assumes that all labels reachable
from indirect jumps are assumed to be at their "initial elimination offsets",
which fails if there's an alloca call or similar adjustment before the're
reached.  For *some* targets, gcc.c-torture/execute/built-in-setjmp.c expose
this bug, but one or more separate test-cases is called for to expose it for
the wider audience: main is not useful wherein to test sp vs. fp
misadjustments, and the test-case should not need for run-time sp realignments,
else for many targets, fp->sp elimination will not happen.  Also, computed
gotos can be probably also be used to expose the bug, rather than
__builtin_setjmp/longjmp.  This code deserves to be fixed correctly, but
considering the current development stage and the limited use of this code,
I'll do like other targets and bail out for cris*-*-* by forcing a
frame-pointer.  Therefore this clone.


-- 
   Summary: [4.4 Regression]: gcc.c-torture/execute/built-in-
setjmp.c execute -O2 and above
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf
 BugsThisDependsOn: 38609


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

[Bug middle-end/39499] reload1.c:set_label_offsets assumes that all labels reachable from indirect jumps are assumed to be at their "initial elimination offsets"

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2009-03-18 23:42 ---
Whoops.  Summary improved.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.4 Regression]: gcc.c-|reload1.c:set_label_offsets
   |torture/execute/built-in-   |assumes that all labels
   |setjmp.c execute -O2 and|reachable from indirect
   |above   |jumps are assumed to be at
   ||their "initial elimination
   ||offsets"


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

[Bug c/39500] New: autopar fails to parallel

[nemokingdom at gmail dot com]

autopar fails auto-parallelization with the code below:

int X[1000];

int main(void)
{
  int i;

  for (i = 0; i < 100; i++)
  X[i] = X[i+100];

  return 0;
}


-- 
   Summary: autopar fails to parallel
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nemokingdom at gmail dot com


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

[Bug c/39500] autopar fails to parallel

[nemokingdom at gmail dot com]

--- Comment #1 from nemokingdom at gmail dot com  2009-03-19 01:27 ---
(In reply to comment #0)
> autopar fails auto-parallelization with the code below:
> 
> int X[1000];
> 
> int main(void)
> {
>   int i;
> 
>   for (i = 0; i < 100; i++)
>   X[i] = X[i+100];
> 
>   return 0;
> }
> 
This bug basically about x1 and y1 not allowed to be in between zero and niter
- 1. This seems to be an typical off by one error.

x1 and y1 not allowed to be in between zero and niter - 1. This seems to
be an typical off by one error.

Index: tree-data-ref.c
===
--- tree-data-ref.c (revision 144721)
+++ tree-data-ref.c (working copy)
@@ -2292,7 +2292,7 @@

  /* If the overlap occurs outside of the bounds of the
 loop, there is no dependence.  */
- if (x1 > niter || y1 > niter)
+ if (x1 >= niter || y1 >= niter)
{
  *overlaps_a = conflict_fn_no_dependence ();
  *overlaps_b = conflict_fn_no_dependence ();


-- 

nemokingdom at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/39500] autopar fails to parallel

[spop at gcc dot gnu dot org]

--- Comment #2 from spop at gcc dot gnu dot org  2009-03-19 02:06 ---
The patch looks good.  I'm bootstrapping and testing it, and then I will apply
it to trunk.

Thanks,
Sebastian


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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

[Bug c/39500] autopar fails to parallel

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2009-03-19 02:07 ---
I will take care of this one.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spop at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-19 02:07:15
   date||


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

[Bug c/39500] autopar fails to parallel

[nemokingdom at gmail dot com]

--- Comment #4 from nemokingdom at gmail dot com  2009-03-19 02:46 ---
(In reply to comment #3)
> I will take care of this one.
> 
I add test case for this situation.

Index: testsuite/gcc.dg/autopar/pr39500-1.c
===
--- testsuite/gcc.dg/autopar/pr39500-1.c(revision 0)
+++ testsuite/gcc.dg/autopar/pr39500-1.c(revision 0)
@@ -0,0 +1,29 @@
+/* pr39500: autopar fails to parallel */
+/* origin: nemoking...@gmail.com(LiFeng)*/
+/* { dg-do compile } */
+/* { dg-options "-O2 -ftree-parallelize-loops=4 -fdump-tree-parloops-details
-fdump-tree-final_cleanup" } */
+
+void abort (void);
+
+int main(void)
+{
+  int i;
+  int x[100];
+
+  for (i = 0; i < 100; i++)
+  x[i] = x[i+100];
+
+  for (i = 0; i < 100; i++)
+{
+  if (x[i] != x[i+100])
+   abort ();
+}
+
+  return 0;
+}
+
+/* Check that the first loop in parloop got parallelized.  */
+
+/* { dg-final { scan-tree-dump-times "SUCCESS: may be parallelized" 1
"parloops" } } */
+/* { dg-final { cleanup-tree-dump "parloops" } } */
+/* { dg-final { cleanup-tree-dump "final_cleanup" } } */
Index: testsuite/gcc.dg/autopar/pr39500-2.c
===
--- testsuite/gcc.dg/autopar/pr39500-2.c(revision 0)
+++ testsuite/gcc.dg/autopar/pr39500-2.c(revision 0)
@@ -0,0 +1,21 @@
+/* pr39500: autopar fails to parallel */
+/* origin: nemoking...@gmail.com(LiFeng)*/
+/* { dg-do compile } */
+/* { dg-options "-O2 -ftree-parallelize-loops=4 -fdump-tree-parloops-details
-fdump-tree-final_cleanup" } */
+
+int main(void)
+{
+  int i;
+  int x[100];
+
+  for (i = 0; i < 101; i++)
+  x[i] = x[i+100];
+
+  return 0;
+}
+
+/* Check that the first loop in parloop got parallelized.  */
+
+/* { dg-final { scan-tree-dump-times "SUCCESS: may be parallelized" 0
"parloops" } } */
+/* { dg-final { cleanup-tree-dump "parloops" } } */
+/* { dg-final { cleanup-tree-dump "final_cleanup" } } */
Index: tree-data-ref.c
===
--- tree-data-ref.c (revision 144648)
+++ tree-data-ref.c (working copy)
@@ -2302,7 +2302,7 @@

  /* If the overlap occurs outside of the bounds of the
 loop, there is no dependence.  */
- if (x1 > niter || y1 > niter)
+ if (x1 >= niter || y1 >= niter)
{
  *overlaps_a = conflict_fn_no_dependence ();
  *overlaps_b = conflict_fn_no_dependence ();


-- 

nemokingdom at gmail dot com changed:

   What|Removed |Added

  Component|middle-end  |c


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

[Bug c/39500] autopar fails to parallel

[sebpop at gmail dot com]

--- Comment #5 from sebpop at gmail dot com  2009-03-19 02:52 ---
Subject: Re:  autopar fails to parallel

On Wed, Mar 18, 2009 at 20:46, nemokingdom at gmail dot com
 wrote:
> I add test case for this situation.
>

Yes, indeed this is a good idea.
Thanks for the testcase,
Sebastian


-- 


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

[Bug c/39500] autopar fails to parallel

[sebpop at gmail dot com]

--- Comment #6 from sebpop at gmail dot com  2009-03-19 02:53 ---
Subject: Re:  autopar fails to parallel

>           What    |Removed                     |Added
> 
>          Component|middle-end                  |c

Please leave the Component to be "middle-end",
this bug is not related to the "c" language.

Sebastian


-- 


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

[Bug middle-end/38609] [4.4 Regression]: gcc.c-torture/execute/built-in-setjmp.c execute -O2 and above

[hp at gcc dot gnu dot org]

--- Comment #14 from hp at gcc dot gnu dot org  2009-03-19 03:53 ---
Subject: Bug 38609

Author: hp
Date: Thu Mar 19 03:52:58 2009
New Revision: 144951

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144951
Log:
PR middle-end/38609
* config/cris/cris.h (FRAME_POINTER_REQUIRED): Force for all
functions with dynamic stack-pointer adjustments.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/cris/cris.h


-- 


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

[Bug middle-end/38609] [4.4 Regression]: gcc.c-torture/execute/built-in-setjmp.c execute -O2 and above

[hp at gcc dot gnu dot org]

--- Comment #15 from hp at gcc dot gnu dot org  2009-03-19 04:17 ---
Follow-up to 39499.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/39500] autopar fails to parallel

[spop at gcc dot gnu dot org]

--- Comment #7 from spop at gcc dot gnu dot org  2009-03-19 06:49 ---
Subject: Bug 39500

Author: spop
Date: Thu Mar 19 06:49:14 2009
New Revision: 144952

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144952
Log:
2009-03-19  Li Feng  

PR middle-end/39500
* tree-data-ref.c (analyze_subscript_affine_affine): There is no
dependence if the first conflict is after niter iterations.

testsuite/
* gcc.dg/autopar/pr39500-1.c: New.
* gcc.dg/autopar/pr39500-2.c: New.


Added:
trunk/gcc/testsuite/gcc.dg/autopar/pr39500-1.c
trunk/gcc/testsuite/gcc.dg/autopar/pr39500-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c


-- 


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

[Bug middle-end/39500] autopar fails to parallel

[spop at gcc dot gnu dot org]

--- Comment #8 from spop at gcc dot gnu dot org  2009-03-19 06:51 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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