[Bug testsuite/39537] overhaul printf formats and type casts in testsuite

[kees at outflux dot net]

--- Comment #3 from kees at outflux dot net  2009-03-24 07:10 ---
g++.old-deja/g++.pt/t39.C: It looks like ptr[0],[1],[2] are either int or const
char (i.e. ptr is int* or const char*). %p doesn't make much sense in those
cases, so I opted for a cast.

I'm not sure I followed your last sentence; I realize that many people find the
Ubuntu default compiler flags inappropriate, but I'm hoping that can be set
aside in the interests of helping to improve our ability to compare testsuite
output.  As you say, many of the changes are correct, and the rest have no
negative impact.


-- 


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

[Bug testsuite/39537] overhaul printf formats and type casts in testsuite

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-03-24 07:28 ---
(In reply to comment #3)
> g++.old-deja/g++.pt/t39.C: It looks like ptr[0],[1],[2] are either int or 
> const
> char (i.e. ptr is int* or const char*). %p doesn't make much sense in those
> cases, so I opted for a cast.

Woops I needed to look at the testcase closer.  Yes casting to int here is
correct.


> I'm not sure I followed your last sentence; I realize that many people find 
> the
> Ubuntu default compiler flags inappropriate, but I'm hoping that can be set
> aside in the interests of helping to improve our ability to compare testsuite
> output.  As you say, many of the changes are correct, and the rest have no
> negative impact.

What I am saying is that those testcase does not need to change as the
undefined behavior is not invoked so the warning does not matter, which case
Ubuntu's default compiler flags are very inappropriate.  Remember undefined
behavior at runtime cannot cause a diagnostic by default according to the C/C++
standard and this is only undefined behavior at runtime.


-- 


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

[Bug tree-optimization/39529] ICE on valid code

[irar at il dot ibm dot com]

--- Comment #2 from irar at il dot ibm dot com  2009-03-24 08:23 ---
I am testing this patch:

Index: tree-vect-transform.c
===
--- tree-vect-transform.c   (revision 145027)
+++ tree-vect-transform.c   (working copy)
@@ -1099,7 +1099,10 @@ vect_create_data_ref_ptr (gimple stmt, s
   if (!MTAG_P (tag))
 new_type_alias (vect_ptr, tag, DR_REF (dr));
   else
-set_symbol_mem_tag (vect_ptr, tag);
+{
+  set_symbol_mem_tag (vect_ptr, tag);
+  mark_sym_for_renaming (tag);
+}

   /** Note: If the dataref is in an inner-loop nested in LOOP, and we are
   vectorizing LOOP (i.e. outer-loop vectorization), we need to create two


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-24 08:23:00
   date||


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

[Bug debug/39535] wrong function name and line numbers with -g -O2 option

[MR dot Swami dot Reddy at nsc dot com]

--- Comment #2 from MR dot Swami dot Reddy at nsc dot com  2009-03-24 08:35 
---
Subject: Re:  wrong function name and line numbers with
 -g -O2 option

pinskia at gcc dot gnu dot org wrote:
> 
> --- Comment #1 from pinskia at gcc dot gnu dot org  2009-03-24 05:16 
> ---
> Please reopen PR 39527 if it is a GCC issue.  As far as I can tell it is not a
> GCC issue from looking at the debugging information from i686-linux-gnu.

OK. I will reopen PR 39527, as  the target.h (ie crx.h file) need debug related 
macros to be defined.

Thanks
Swami


-- 


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

[Bug fortran/39528] [4.2/4.3/4.4 Regression] repeated entries are not read when using list-directed input

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.0/4.1/4.2/4.3/4.4|[4.2/4.3/4.4 Regression]
   |Regression] repeated entries|repeated entries are not
   |are not read when using |read when using list-
   |list-directed input |directed input
   Target Milestone|--- |4.2.5


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

[Bug debug/39538] New: wrong function name and line numbers with -g -O2 option

[MR dot Swami dot Reddy at nsc dot com]

With -g -O2 option, crx-elf-gcc generates wrong line numbers and function
names.
==
/tmp/ccrrZsJf.o: In function `090312 (experimental)':
/home10/swami/test.c:5: undefined reference to `_f1'
collect2: ld returned 1 exit status
===

Expected output could be:
===
/tmp/ccEJcFRs.o: In function `main':
/home10/swami/test.c:6: undefined reference to `_f1'
collect2: ld returned 1 exit status



testcase: "test.c"


int f = 1;
extern int f1 ();

main () {
   f1();
}
===


-- 
   Summary: wrong function name and line numbers with -g -O2 option
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: MR dot Swami dot Reddy at nsc dot com
  GCC host triplet: Native Linux
GCC target triplet: crx-elf


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

[Bug debug/39539] New: wrong function name and line numbers with -g -O2 option

[MR dot Swami dot Reddy at nsc dot com]

With -g -O2 option, crx-elf-gcc generates wrong line numbers and function
names.
==
/tmp/ccrrZsJf.o: In function `090312 (experimental)':
/home10/swami/test.c:5: undefined reference to `_f1'
collect2: ld returned 1 exit status
===

Expected output could be:
===
/tmp/ccEJcFRs.o: In function `main':
/home10/swami/test.c:6: undefined reference to `_f1'
collect2: ld returned 1 exit status



testcase: "test.c"


int f = 1;
extern int f1 ();

main () {
   f1();
}
===


-- 
   Summary: wrong function name and line numbers with -g -O2 option
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: MR dot Swami dot Reddy at nsc dot com
  GCC host triplet: Native Linux
GCC target triplet: crx-elf


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

[Bug debug/39540] New: wrong function name and line numbers with -g -O2 option

[MR dot Swami dot Reddy at nsc dot com]

With -g -O2 option, crx-elf-gcc generates wrong line numbers and function
names.
==
/tmp/ccrrZsJf.o: In function `090312 (experimental)':
/home10/swami/test.c:5: undefined reference to `_f1'
collect2: ld returned 1 exit status
===

Expected output could be:
===
/tmp/ccEJcFRs.o: In function `main':
/home10/swami/test.c:6: undefined reference to `_f1'
collect2: ld returned 1 exit status



testcase: "test.c"


int f = 1;
extern int f1 ();

main () {
   f1();
}
===


-- 
   Summary: wrong function name and line numbers with -g -O2 option
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: MR dot Swami dot Reddy at nsc dot com
  GCC host triplet: Native Linux
GCC target triplet: crx-elf


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

[Bug c++/39541] New: Templates class instantiation -name lookup

[anubhav dot saxena at wipro dot com]

Hi,

Consider the code

struct A{ 
void fn(){cout << "1";} 
}; 

template 
struct B{ 
void fn(){cout << "2";} 
}; 


template 
struct C : A, B{ 
C(){ fn(); }  // fn is a non dependent name. 
}; 

int main(){ 
C c; 
}

In this case, it looks fairly intuitive that the call to 'fn' is ambiguous.
However there are two things that I am not able to resolve

a) I cannot find anything in the Standard that talk about such a scenario.
Going by the rules of non dependent names (bound in lookup phase 1), fn should
be in fact bound to A::fn.

b) Comeau online compiler accepts this code and compiles it fine.

So, I want to confirm if gcc 4.1.1 behavior is right? Any relevant quotes from
the Standard will also help.

Regards,
Anubhav.


-- 
   Summary: Templates class instantiation -name lookup
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anubhav dot saxena at wipro dot com


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

[Bug c++/26155] ICE after error with namespace alias

[doko at ubuntu dot com]

--- Comment #4 from doko at ubuntu dot com  2009-03-24 10:40 ---
confirmed with 4.3.4 and 4.4.0


-- 


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

[Bug debug/39540] wrong function name and line numbers with -g -O2 option

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-24 11:00 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug debug/39535] wrong function name and line numbers with -g -O2 option

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-03-24 11:00 ---
*** Bug 39540 has been marked as a duplicate of this bug. ***


-- 


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

[Bug debug/39539] wrong function name and line numbers with -g -O2 option

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-24 11:00 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug debug/39535] wrong function name and line numbers with -g -O2 option

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-03-24 11:00 ---
*** Bug 39539 has been marked as a duplicate of this bug. ***


-- 


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

[Bug debug/39538] wrong function name and line numbers with -g -O2 option

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-24 11:01 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug debug/39535] wrong function name and line numbers with -g -O2 option

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-03-24 11:01 ---
*** Bug 39538 has been marked as a duplicate of this bug. ***


-- 


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

[Bug debug/39535] wrong function name and line numbers with -g -O2 option

[MR dot Swami dot Reddy at nsc dot com]

--- Comment #6 from MR dot Swami dot Reddy at nsc dot com  2009-03-24 11:04 
---
Subject: Re:  wrong function name and line numbers with
 -g -O2 option

rguenth at gcc dot gnu dot org wrote:
> 
> --- Comment #4 from rguenth at gcc dot gnu dot org  2009-03-24 11:00 
> ---
> *** Bug 39539 has been marked as a duplicate of this bug. ***
> 

Could please explain, why multiple PR ID generated for one issue/bug?

Thanks
Swami


-- 


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

[Bug libstdc++/39542] New: doesn't contain vasprintf() and asprintf()

[doko at ubuntu dot com]

[forwarded from https://launchpad.net/bugs/332115]

While the documentation states that vasprintf and asprintf belong to the the
 header, the C++ header  doesn't contain any definition to
them, thus forcing one to also #include 


-- 
   Summary:  doesn't contain vasprintf() and asprintf()
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com


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

[Bug libstdc++/39542] doesn't contain vasprintf() and asprintf()

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-24 11:20 ---
These are GNU extensions not appropriate for a ISO C++ header file (the
standard lists which functions are to be made available in the std namespace).
So at most they could be added to the __gnucxx namespace?


-- 


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

[Bug rtl-optimization/39543] New: [4.4 Regression] Reload failure on mplayer from SVN

[jakub at gcc dot gnu dot org]

The following testcase errors while reloading the asms with -O3 -m32 or
-O3 -m32 -DOMIT_FRAME_POINTER -fomit-frame-pointer since r139993 (before that
it worked even with IRA, after that -fno-ira cured it while we still had it).
I agree mplayer pushes the limits a little bit too far by having so many "m"
and "=m" constraints, on the other side e.g. in baz when it is inlined none of
the asms actually need any registers to reload them, all the mems are actually
s[012345] + some small constant, so on i386 all of them can be expanded as
s0+16 and similar.  In the *.optimized dump they are still constants, wonder
why during expand we decide to force all the MEM addresses into registers.


-- 
   Summary: [4.4 Regression] Reload failure on mplayer from SVN
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: i686-linux


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

[Bug libstdc++/39542] doesn't contain vasprintf() and asprintf()

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-03-24 11:36 
---
This is definitely not a bug. Note, in our implementation  is included
anyway from  as an implementation detail.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/39529] ICE on valid code

[irar at il dot ibm dot com]

--- Comment #3 from irar at il dot ibm dot com  2009-03-24 11:42 ---
(In reply to comment #0)
> My solution:
> After each loop is vectorized, and SSA is updated, I re-compute alias
> info. I am not familiar with the vectorizer sources, so I don't know
> if there is a more efficient way to fix this problem, and still be
> sure it would be correct for all inputs.

I think that just marking the created pointer for renaming can be enough...

Ira


-- 


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

[Bug c/39464] [4.2/4.3/4.4 Regression] Attribute may_alias causes invalid warning

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug rtl-optimization/39543] [4.4 Regression] Reload failure on mplayer from SVN

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-03-24 11:27 ---
Ah, forgot the testcase:

float __attribute__ ((aligned (16))) s0[128];
const float s1 = 0.707;
float s2[8] __attribute__ ((aligned (16)));
float s3[8] __attribute__ ((aligned (16)));
float s4[16] __attribute__ ((aligned (16)));
float s5[16] __attribute__ ((aligned (16)));

void
foo (int k, float *x, float *y, const float *d, const float *z)
{
  float *a, *b, *c, *e;

  a = x + 2 * k;
  b = a + 2 * k;
  c = b + 2 * k;
  e = y + 2 * k;
  __asm__ volatile (""
: "=m" (x[0]), "=m" (b[0]), "=m" (a[0]), "=m" (c[0])
: "m" (y[0]), "m" (y[k * 2]), "m" (x[0]), "m" (a[0])
: "memory");
  for (;;)
{
  __asm__ volatile (""
:
: "m" (y[2]), "m" (d[2]), "m" (e[2]), "m" (z[2])
: "memory");
  if (!--k)
break;
}
  __asm__ volatile (""
: "=m" (x[2]), "=m" (x[10]), "=m" (x[6]), "=m" (x[14])
: "m" (y[2]), "m" (y[6]), "m" (x[2]), "m" (x[6]), "m" (s1)
: "memory");
}

void
bar (float *a)
{
  foo (4, a, a + 16, s2, s3);
  foo (8, a, a + 32, s4, s5);
}

void
baz (void)
{
  bar (s0);
}


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug pch/39492] [4.3/4.4 Regression] Parallel compilation fail using PCH on Windows NT>= 5.0

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-03-24 11:47 ---
How is this a regression?


-- 


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

[Bug bootstrap/39503] [4.4 Regression] libgcc2.c doesn't compile anymore

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-03-24 11:47 ---
Can we please have a status update on whether this is a problem with your
header setup or GCCs fault?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug middle-end/39514] [4.4 Regression] unreported change to packed bitfields

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug fortran/39528] [4.2/4.3/4.4 Regression] repeated entries are not read when using list-directed input

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug pch/39492] [4.3/4.4 Regression] Parallel compilation fail using PCH on Windows NT>= 5.0

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-03-24 12:16 ---
(In reply to comment #3)
> How is this a regression?
Because it used to work in 4.1.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||4.3.0 4.4.0
  Known to work||4.1.1


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

[Bug tree-optimization/39529] ICE on valid code

[irar at gcc dot gnu dot org]

--- Comment #4 from irar at gcc dot gnu dot org  2009-03-24 12:18 ---
Subject: Bug 39529

Author: irar
Date: Tue Mar 24 12:18:19 2009
New Revision: 145029

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

PR tree-optimization/39529
* tree-vect-transform.c (vect_create_data_ref_ptr): Call
mark_sym_for_renaming for the tag copied to the new vector
pointer.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr39529.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-transform.c


-- 


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

[Bug fortran/39528] [4.2/4.3/4.4 Regression] repeated entries are not read when using list-directed input

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2009-03-24 12:24 
---
Subject: Bug 39528

Author: jvdelisle
Date: Tue Mar 24 12:24:29 2009
New Revision: 145030

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145030
Log:
2009-03-24  Jerry DeLisle  

PR libfortran/39528
* io/list_read.c (list_formatted_read_scalar): Move check for read
completion to just after the check for a repeated value.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c


-- 


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

[Bug fortran/39528] [4.2/4.3/4.4 Regression] repeated entries are not read when using list-directed input

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2009-03-24 12:30 
---
Subject: Bug 39528

Author: jvdelisle
Date: Tue Mar 24 12:30:17 2009
New Revision: 145031

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145031
Log:
2009-03-24  Jerry DeLisle  

PR libfortran/39528
* gfortran.dg/read_repeat.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/read_repeat.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/39528] [4.2/4.3 Regression] repeated entries are not read when using list-directed input

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2009-03-24 12:33 
---
Fixed on 4.4.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.4.0 4.3.3 4.2.3   |4.3.3 4.2.3
Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3 Regression]
   |repeated entries are not|repeated entries are not
   |read when using list-   |read when using list-
   |directed input  |directed input


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

[Bug c++/39544] New: Grammar error in russian localization

[xredor at gmail dot com]

test.cpp:17: îøèáêà: ‘operator[]’ íå èìååò àðãóìåíòîâ, çàâèñÿùèõ îò
ïàðàìåòðà-øàáëîíà, ïîýòîìó äîëæíà áûòü äîñüóïíà!!! äåêëàðàöèÿ
‘operator[]’
test.cpp:17: îøèáêà: (ñ êëþ÷îì ‘-fpermissive’, G++ ïðèìåò äàííûé êîä, íî
ðàçðåøåíèå èñïîëüçîâàòü íåäåêëàðèðîâàííûå èìåíà áóäåò îòìåíåíî â äàëüíåéøèõ
âåðñèÿõ)

Äîëæíî áûòü "äîñòóïíà"


-- 
   Summary: Grammar error in russian localization
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xredor at gmail dot com
 GCC build triplet: Ubuntu Linux 2.6.27 x86_64
  GCC host triplet: Ubuntu Linux 2.6.27 x86_64
GCC target triplet: Ubuntu Linux 2.6.27 x86_64


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

[Bug rtl-optimization/39543] [4.4 Regression] Reload failure on mplayer from SVN

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-03-24 12:54 ---
The reason for forcing the MEM addresses in "m"/"=m" into register is:
  /* By passing constant addresses through registers
 we get a chance to cse them.  */
  if (! cse_not_expected && CONSTANT_P (x) && CONSTANT_ADDRESS_P (x))
x = force_reg (Pmode, x);
in memory_address.  On a simple s0[0] = 0; s0[4] = 0; s0[8] = 0; s0[12] = 0;
the addresses are propagated back into the MEMs during fwprop1 (or during
combine for -fno-forward-propagate), but this for some reason doesn't happen
for the asm operands.
Either we need to disable this kind of forcing into register for (constant)
memory operands, or better find out and fix why neither fwprop nor combiner
merges the memory operands back.


-- 


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

[Bug c/39464] [4.2/4.3/4.4 Regression] Attribute may_alias causes invalid warning

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-03-24 12:54 ---
It's not that easy.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug testsuite/39537] overhaul printf formats and type casts in testsuite

[joseph at codesourcery dot com]

--- Comment #5 from joseph at codesourcery dot com  2009-03-24 13:19 ---
Subject: Re:   New: overhaul printf formats and type
 casts in testsuite

The testsuite in FSF GCC tests correct behavior of FSF GCC and code 
compiled with it.  If correct behavior for Ubuntu GCC and code compiled 
with that is different, Ubuntu needs to maintain its own testsuite 
patches.

If a test will actually fail (compilation or execution) *with FSF GCC* on 
some platform at present, then a fix (to gcc-patches in the usual way 
following the documentation in contribute.html) would be appropriate.


-- 


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

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

[joseph at codesourcery dot com]

--- Comment #10 from joseph at codesourcery dot com  2009-03-24 13:22 
---
Subject: Re:  stddef.h assumes machinee/ansi.h defines
 _ANSI_H_

On Tue, 24 Mar 2009, aran at 100acres dot us wrote:

> This is a combination of the other two patches.  GCC's version of stddef.h is
> still installed and fixed for NetBSD.  The copy of sys/types.h is not
> installed.

Once you have finished testing, please send the patch with ChangeLog 
entries and a self-contained explanation to gcc-patches as described in 
contribute.html.

Do not include the diffs to the generated file fixincl.x; the person 
committing it will need to regenerate it using a current autogen version 
(which would keep GPLv3 notices there rather than wrongly substituting 
GPLv2 notices).


-- 


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

[Bug c++/39544] Grammar error in russian localization

[joseph at codesourcery dot com]

--- Comment #1 from joseph at codesourcery dot com  2009-03-24 13:26 ---
Subject: Re:   New: Grammar error in russian localization

We do not maintain the translations in GCC and the Russian team does not 
have a Bugzilla account, so you will need to pass your report on to 
g...@mx.ru yourself.


-- 


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

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

[joseph at codesourcery dot com]

--- Comment #11 from joseph at codesourcery dot com  2009-03-24 13:32 
---
Subject: Re:  stddef.h assumes machinee/ansi.h defines
 _ANSI_H_

I see you did in fact send the stddef.h changes to gcc-patches - thanks 
for splitting up the separate logical parts of the patch (which is always 
best to do, since the stddef.h and fixincludes changes can reasonably be 
reviewed separately).


-- 


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

[Bug bootstrap/39503] [4.4 Regression] libgcc2.c doesn't compile anymore

[forumer at smartmobili dot com]

--- Comment #6 from forumer at smartmobili dot com  2009-03-24 13:51 ---
I think you can close it because I suppose the problem only happens with my
includes/toolchains.
I don't know why but normally DWORD definitions should be known since
VirtualProtect is.If you really wanted to make everyone happy, you could define
unsigned long instead of DWORD.


-- 

forumer at smartmobili dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug c++/26693] [4.2/4.3/4.4 regression] Access checks not performed for types in templates

[howarth at nitro dot med dot uc dot edu]

--- Comment #10 from howarth at nitro dot med dot uc dot edu  2009-03-24 
13:55 ---
Shouldn't this be closed as fixed?


-- 


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

[Bug tree-optimization/39120] [4.2/4.3/4.4 Regression] Missed escape constraints for call results

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2009-03-24 
14:02 ---
Can this be back ported to gcc trunk?


-- 


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

[Bug rtl-optimization/39543] [4.4 Regression] Reload failure on mplayer from SVN

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-03-24 14:18 ---
Ok, so the reason why fwprop doesn't propagate this is:

forward_propagate_and_simplify doing:
  rtx use_set = single_set (use_insn);
...
  if (!use_set)
return false;

ASM_OPERANDS with multiple output regs obviously isn't single_set, so nothing
is propagated.  Paolo, any reason to restrict this, or at least could
forward_propagate_and_simplify specially propagate also to memory addresses in
asms?

The reason why combiner doesn't do anything is that when the pseudos
initialized to constants are used multiple times (not dead on the asm insn),
try_combine
sets added_sets_2 and as the insn is a PARALLEL, appends the added set to that,
making it invalid (asm_noperands (body) returns -1).

So, to fix this bug, either we can teach fwprop to do this kind of propagation
(my preference), or e.g. temporarily set cse_not_expected in
expand_asm_operands.  I can easily test the latter as a fallback variant if the
former is deemed too unsafe for 4.4.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug tree-optimization/39120] [4.2/4.3/4.4 Regression] Missed escape constraints for call results

[rguenther at suse dot de]

--- Comment #4 from rguenther at suse dot de  2009-03-24 14:20 ---
Subject: Re:  [4.2/4.3/4.4 Regression] Missed
 escape constraints for call results

On Tue, 24 Mar 2009, howarth at nitro dot med dot uc dot edu wrote:

> --- Comment #3 from howarth at nitro dot med dot uc dot edu  2009-03-24 
> 14:02 ---
> Can this be back ported to gcc trunk?

It can, but it would drag in some dependencies, in particular the CALLUSED
handling rewrite and eventually the changes related to handling NONLOCAL
vs. ESCAPED.  I will try to cook up sth but planned to merge these changes
early in stage1 to backport them for 4.4.1 eventually.

Richard.


-- 


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

[Bug tree-optimization/39120] [4.2/4.3/4.4 Regression] Missed escape constraints for call results

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-03-24 14:40 ---
Created an attachment (id=17532)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17532&action=view)
part #2

Untested patches for the backport.


-- 


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

[Bug tree-optimization/39120] [4.2/4.3/4.4 Regression] Missed escape constraints for call results

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-03-24 14:39 ---
Created an attachment (id=17531)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17531&action=view)
part #1


-- 


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

[Bug rtl-optimization/39543] [4.4 Regression] Reload failure on mplayer from SVN

[bonzini at gnu dot org]

--- Comment #4 from bonzini at gnu dot org  2009-03-24 15:03 ---
The only thing to be careful is to have set_reg_equal == FALSE if the insn has
multiple sets, and find which set in a multiple-set insn is actually referring
to USE (a combination of note_stores and loc_mentioned_in_p will do).  Such a
patch is definitely backportable to 4.4 even if it is not ready for 4.4.0.

However, I'm not sure it is good to have the best possible addressing mode in
an asm, because I wonder if this could cause other kinds of reload failure. 
Think of:

   char p[10];
   ...
   a = b * 4 + c;
   asm ("" : : "m" (p[a]))

Which fwprop would likely change to a base/index/displacement address, with 2
registers gone.

Setting cse_not_expected in practice would not use an addressing mode that is
more complicated than the one specified by the user; for an asm, I think this
is actually the least surprising behavior.


-- 


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

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

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-03-24 15:37 ---
Patch sent.

http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01129.html


-- 

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-03-18 21:33:49 |2009-03-24 15:37:36
   date||


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

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

[aran at 100acres dot us]

--- Comment #12 from aran at 100acres dot us  2009-03-24 15:49 ---
Subject: Re:  stddef.h assumes machinee/ansi.h defines _ANSI_H_

Joseph,
The fixincludes changes fix another issue.  Should I create 
a new bug and reference that bug in the e-mail or just 
describe the problem in the e-mail?

Aran

On Tuesday 24 March 2009 6:22:25 joseph at codesourcery dot 
com wrote:
> --- Comment #10 from joseph at codesourcery dot com 
> 2009-03-24 13:22 --- Subject: Re:  stddef.h assumes
> machinee/ansi.h defines _ANSI_H_
>
> On Tue, 24 Mar 2009, aran at 100acres dot us wrote:
> > This is a combination of the other two patches.  GCC's
> > version of stddef.h is still installed and fixed for
> > NetBSD.  The copy of sys/types.h is not installed.
>
> Once you have finished testing, please send the patch
> with ChangeLog entries and a self-contained explanation
> to gcc-patches as described in contribute.html.
>
> Do not include the diffs to the generated file fixincl.x;
> the person committing it will need to regenerate it using
> a current autogen version (which would keep GPLv3 notices
> there rather than wrongly substituting GPLv2 notices).


-- 


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

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

[joseph at codesourcery dot com]

--- Comment #13 from joseph at codesourcery dot com  2009-03-24 16:04 
---
Subject: Re:  stddef.h assumes machinee/ansi.h defines
 _ANSI_H_

On Tue, 24 Mar 2009, aran at 100acres dot us wrote:

> Joseph,
> The fixincludes changes fix another issue.  Should I create 
> a new bug and reference that bug in the e-mail or just 
> describe the problem in the e-mail?

Describing the problem in the email is sufficient.  If the patch isn't 
reviewed within a week or so then ping it (as many times as needed).  If 
the patch is approved but not committed, make clear that you need someone 
with write access to commit it for you.


-- 


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

[Bug target/39545] New: structures with zero-length array passed/returned inconsistently

[hjl dot tools at gmail dot com]

[...@gnu-6 tmp]$ cat f-1.c
struct line {
int length;
char contents[];
};

void foo (struct line);

struct line
bar ()
{
 struct line x;
 x.length = sizeof (struct line);
 foo (x);
 return x;
}
[...@gnu-6 tmp]$ /usr/gcc-4.4/bin/gcc -fno-asynchronous-unwind-tables -O2 -S
f-1.c
[...@gnu-6 tmp]$ cat f-1.s
.file   "f-1.c"
.text
.p2align 4,,15
.globl bar
.type   bar, @function
bar:
pushq   %rbx
movq%rdi, %rbx
subq$32, %rsp
movl$4, (%rdi)
movl$4, (%rsp)
callfoo
movl$4, (%rbx)
movq%rbx, %rax
addq$32, %rsp
popq%rbx
ret
.size   bar, .-bar
.ident  "GCC: (GNU) 4.4.0 20090317 (experimental) [trunk revision
144915]"
.section.note.GNU-stack,"",@progbits
[...@gnu-6 tmp]$ cat f-2.c
struct line {
int length;
struct {} c;
};

void foo (struct line);

struct line
bar ()
{
 struct line x;
 x.length = sizeof (struct line);
 foo (x);
 return x;
}
[...@gnu-6 tmp]$ /usr/gcc-4.4/bin/gcc -fno-asynchronous-unwind-tables -O2 -S
f-2.c
[...@gnu-6 tmp]$ cat f-2.s
.file   "f-2.c"
.text
.p2align 4,,15
.globl bar
.type   bar, @function
bar:
subq$8, %rsp
movl$4, %edi
callfoo
movl$4, %eax
addq$8, %rsp
ret
.size   bar, .-bar
.ident  "GCC: (GNU) 4.4.0 20090317 (experimental) [trunk revision
144915]"
.section.note.GNU-stack,"",@progbits
[...@gnu-6 tmp]$


-- 
   Summary: structures with zero-length array passed/returned
inconsistently
   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: x86_64-pc-linux-gnu


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

[Bug tree-optimization/39355] [4.4 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[danglin at gcc dot gnu dot org]

--- Comment #48 from danglin at gcc dot gnu dot org  2009-03-24 16:31 
---
On i686-apple-darwin9, this doesn't fail because DECL_HAS_VALUE_EXPR_P (loc)
is not set:

(gdb) p debug_tree (loc)
 
unit size 
align 64 symtab 28208224 alias set 24 canonical type 0xf6adb0
precision 64
pointer_to_this  reference_to_this
>
sizes-gimplified asm_written type_6 DC
size 
unit size 
align 64 symtab 28379296 alias set 26 canonical type 0xf6dba0
pointer_to_this >
used DC file
/Users/dave/gnu/gcc/objdir/i686-apple-darwin9/libstdc++-v3/include/complex line
993 col 60 size  unit size 
align 64 context  arg-type
>
$15 = void
(gdb) p loc->decl_common.decl_flag_3
$16 = 0


-- 


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

[Bug libstdc++/39546] New: parallel mode doesn't support implicit string conversion

[suokkos at gmail dot com]

In parallel mode automatic conversion from string literal to std::string
doesn't work when passing literal as parameter to std::find.

Woring compiler parameters:
g++ test.cpp -o test

Failing compiler line:
g++ -D_GLIBCXX_PARALLEL -fopenmp -lgomp test.cpp -o test


Simple work around is making explicit temporary std::string object.


-- 
   Summary: parallel mode doesn't support implicit string conversion
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suokkos 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=39546

[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion

[suokkos at gmail dot com]

--- Comment #1 from suokkos at gmail dot com  2009-03-24 16:43 ---
Created an attachment (id=17533)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17533&action=view)
g++ -v output when trying to compiling in parallel mode


-- 


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

[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion

[suokkos at gmail dot com]

--- Comment #2 from suokkos at gmail dot com  2009-03-24 16:46 ---
Created an attachment (id=17534)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17534&action=view)
--save-temps test.ii from failed compilation in parallel mode


-- 


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

[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion

[suokkos at gmail dot com]

--- Comment #3 from suokkos at gmail dot com  2009-03-24 16:48 ---
Created an attachment (id=17535)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17535&action=view)
Source for the simple test case


-- 


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

[Bug libstdc++/39547] New: deque::erase invalidates end()

[terra at gnome dot org]

The program below should print nothing.  For me, it prints "1".

When erasing at the beginning or the end of a deque, the only iterators
to be invalidated are those of elements being erased.  All others, and
in particular end(), should remain valid.  (I am fairly certain that the
standard didn't mean to keep end() valid, but that's what it says.)


#include 
#include 

int
main ()
{
  std::deque d;
  d.resize (1, 1);
  std::deque::iterator the_end = d.end ();
  d.erase (d.begin (), the_end);
  for (std::deque::iterator i = d.begin ();
   i != the_end;
   ++i)
std::cerr << *i << std::endl;

  return 0;
}


-- 
   Summary: deque::erase invalidates end()
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terra at gnome dot org
GCC target triplet: x86_64-suse-linux


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

[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-03-24 17:25 
---
Johannes, can you have a look? To be honest, I'm not sure that using those
binders (with all the known limitations which led to deprecation for C++0x) in
dispatching functions really can be made to work also in the corner cases...
Maybe we can deal somehow easily with this specific case?


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||singler at gcc dot gnu dot
   ||org


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

[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-24 17:26:00
   date||


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

[Bug preprocessor/39533] -MM may list a header file twice

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-03-24 17:26 ---
Created an attachment (id=17536)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17536&action=view)
A updated testcase

Here is the correct testcase.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Attachment #17527|0   |1
is obsolete||


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

[Bug preprocessor/39533] -MM may list a header file twice

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2009-03-24 17:26 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01133.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||03/msg01133.html


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

[Bug libstdc++/39547] deque::erase invalidates end()

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-03-24 17:31 
---
Yes, this is DR 638:

  http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug testsuite/39537] overhaul printf formats and type casts in testsuite

[kees at outflux dot net]

--- Comment #6 from kees at outflux dot net  2009-03-24 17:39 ---
I'm trying to minimize the Ubuntu patch by getting changes accepted for the FSF
GCC testsuite.  I'm hoping to demonstrate that many of the changes are valid
and represent stricter C coding, though none change the behavior of the test
itself.

Are there any parts of the above patchset that would be acceptable?  Anything I
can trim or change?

(Also, please see bug 39536, which should also be trivial and useful to add.)


-- 


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

[Bug preprocessor/39533] -MM may list a header file twice

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2009-03-24 17:43 ---
Created an attachment (id=17537)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17537&action=view)
A real tescase

This should be correct.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Attachment #17536|0   |1
is obsolete||


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

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[rwild at gcc dot gnu dot org]

--- Comment #8 from rwild at gcc dot gnu dot org  2009-03-24 17:47 ---
Hello David,

(In reply to comment #0)
> I'm trying to compile gcc 4.3.1 on a Laptop running Solaris Express Community
> Edition Build 89.
[...]
> A search on the web for the "configure: error: cannot compute suffix of object
> files: cannot compile" suggests setting LD_LIBRARY_PATH, as above. That does
> not work. I've also tried
> 
> set LD_LIBRARY_PATH=/usr/local/lib
> export LD_LIBRARY_PATH
> 
> but that does not work either.

Is that exactly what you tried?  Because that doesn't do the right thing.
Instead, use
  LD_LIBRARY_PATH=/usr/local/lib
  export LD_LIBRARY_PATH

with a Bourne-like shell, or
  setenv LD_LIBRARY_PATH /usr/local/lib

with a csh-like shell.

> Also tried LDFLAGS='-L/usr/local/lib -R/usr/local/lib'
> but again did not help.

This might work in the SVN trunk version of GCC (haven't checked though).


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rwild at gcc dot gnu dot org


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

[Bug tree-optimization/39548] New: gcc ICE compiling code with option -fprofile-generate

[davidxl at gcc dot gnu dot org]

The tot compile ICEs when compiling the following code with these options.

 -Wno-error -fno-exceptions -fno-tree-vrp -O2 -fprofile-generate=.


copyprop.C: In member function 'void foo_14::hh_29(blah_46)':
copyprop.C:1051: error: definition in block 29 does not dominate use in block
30
for SSA_NAME: D.43954_350 in statement:
prephitmp.3431_374 = PHI 
PHI argument
D.43954_350
for PHI node
prephitmp.3431_374 = PHI 
copyprop.C:1051: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.



The problem is that the legality check done in copy-prop simulation Iphi node
visiting) stage and the actual substitute and folding stage is not consistent
-- the former is more relaxed. For some phi, the one of the phi argument is
propagated to LHS and lead to cfg's virtual simplification (edge pruning) --
the  simplified CFG leads to RHS ARG propagation of more PHI nodes.  In the
final stage, the copy-prop that leads to the simplified CFG may be found legal
and abandoned -- the end result is inconsistent data flow (SSA) and CFG.


-- 
   Summary: gcc ICE compiling code with option -fprofile-generate
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davidxl at gcc dot gnu dot org


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

[Bug preprocessor/39533] -MM may list a header file twice

[rwild at gcc dot gnu dot org]

--- Comment #8 from rwild at gcc dot gnu dot org  2009-03-24 17:49 ---
Why is this a bug?  I'm really curious to know; the manual doesn't document
that -MM output is uniquified.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rwild at gcc dot gnu dot org


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

[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate

[davidxl at gcc dot gnu dot org]

--- Comment #1 from davidxl at gcc dot gnu dot org  2009-03-24 17:50 ---
Created an attachment (id=17538)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17538&action=view)
Test case


-- 

davidxl at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |davidxl at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED


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

[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate

[davidxl at gcc dot gnu dot org]

--- Comment #2 from davidxl at gcc dot gnu dot org  2009-03-24 17:51 ---
Created an attachment (id=17539)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17539&action=view)
patch file


-- 


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

[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-03-24 17:55 ---
It might be better to place the check after the loop (and put an assert in
set_copy_of_val that triggers the copy may not happen).


-- 


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

[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-03-24 17:56 ---
Btw, it shouldn't really happen that we are not allowed to copyprop PHI
arguments.  It hints at some inconsistency in the IL instead.


-- 


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

[Bug target/38203] attribute `noreturn' isn't effective when -mthumb param is active

[ramana dot r at gmail dot com]

--- Comment #2 from ramana dot r at gmail dot com  2009-03-24 18:34 ---
(In reply to comment #1)
> Created an attachment (id=16728)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16728&action=view) [edit]
> A more involved testcase.
> 
> This testcase shows the preserving behaviour on multiple call-clobbered
> registers, in spite of noreturn attribute.
> 

The save of registers appears on


Using built-in specs.
Target: arm-none-eabi
Configured with: /home/ramana/cos/mycos/combined-arm-none-eabi/configure
--target=arm-none-eabi --enable-languages=c,c++ : (reconfigured)
/home/ramana/cos/mycos/combined-arm-none-eabi/configure --target=arm-none-eabi
--enable-languages=c,c++ : (reconfigured)
/home/ramana/cos/mycos/combined-arm-none-eabi/configure --target=arm-none-eabi
target_alias=arm-none-eabi --enable-languages=c,c++ --no-create --no-recursion
Thread model: single
gcc version 4.4.0 20090324 (experimental) [trunk revision 143499] (GCC) 

and might be related to PR #38570 . 


-- 

ramana dot r at gmail dot com changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu dot
   ||org, ramana dot r at gmail
   ||dot com


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

[Bug target/39545] structures with zero-length array passed/returned inconsistently

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-03-24 18:43 ---
i386.c has

static int
classify_argument (enum machine_mode mode, const_tree type, 
   enum x86_64_reg_class classes[MAX_CLASSES], int bit_offset)
{
  HOST_WIDE_INT bytes =
(mode == BLKmode) ? int_size_in_bytes (type) : (int) GET_MODE_SIZE (mode);
  int words = (bytes + (bit_offset % 64) / 8 + UNITS_PER_WORD - 1) /
UNITS_PER_WORD;

  /* Variable sized entities are always passed/returned in memory.  */
  if (bytes < 0)
return 0;

bytes == 0 for "char xxx[0]" and bytes == -1 for "char xxx[]". We can't
return "char []" and "char xxx[]" is passed as pointer. So

  /* Variable sized entities are always passed/returned in memory.  */
  if (bytes < 0)
return 0;

only applies to zero-length array in a structure like

struct line {
int length;
char contents[];
};

This patch was added by

http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01595.html

Jan, what was the rational for this change?


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||jh at suse dot cz


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

Re: Small error in manual

[Ralf Wildenhues]

Hello Reuben,

I think nowadays the gcc-bugs list is meant only as gateway for bugzilla
messages, so you might want to open a bugzilla for future reports.
Thanks.

* Reuben Thomas wrote on Mon, Mar 23, 2009 at 02:58:20AM CET:
> (Found in 4.3; I was unable to discover without checking out the sources  
> whether the error is still present in head, as I couldn't work out which  
> file to look in using ViewVC; sorry.)
>
> -fno-merge-debug-strings is documented as if it were 
> -fmerge-debug-strings; the description needs to be negated.

Thanks for the report.  OK to push this patch, tested 'make info pdf
html'?

Thanks,
Ralf

gcc/ChangeLog:
2009-03-24  Ralf Wildenhues  

* doc/invoke.texi (Debugging Options): Fix description of
-fno-merge-debug-strings.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index d1c86dc..8b97fa0 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -4408,11 +4408,11 @@ This option works only with DWARF 2.
 @item -fno-merge-debug-strings
 @opindex fmerge-debug-strings
 @opindex fno-merge-debug-strings
-Direct the linker to merge together strings which are identical in
-different object files.  This is not supported by all assemblers or
-linker.  This decreases the size of the debug information in the
-output file at the cost of increasing link processing time.  This is
-on by default.
+Direct the linker to not merge together strings which are identical in
+different object files.  Merging is not supported by all assemblers or
+linker.  It decreases the size of the debug information in the output
+file at the cost of increasing link processing time.  Merging is enabled
+by default.
 
 @item -fdebug-prefix-m...@var{old}=@var{new}
 @opindex fdebug-prefix-map

[Bug target/36209] arm-*-linux-gnueabi-gcc (4.3.0) segment fault during build of procps-3.2.7

[ramana dot r at gmail dot com]

--- Comment #5 from ramana dot r at gmail dot com  2009-03-24 18:53 ---
I can confirm that this is fixed with revision 145038 in the 4.3 branch which
is due to the fix committed here. 


http://gcc.gnu.org/viewcvs?view=rev&revision=143942 which is essentially a
backport of the patch http://gcc.gnu.org/viewcvs?view=rev&revision=137235 .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964


-- 

ramana dot r at gmail dot com changed:

   What|Removed |Added

 CC||ramana dot r at gmail dot
   ||com


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

[Bug c/39549] New: Nonoptimal byte load. mov (%rdi),%al better then movzbl (%rdi),%eax

[vvv at ru dot ru]

> gcc --version
gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]

> cat test.c
// file test.c One byte transfer

void f(char *a,char *b){
*b=*a;
}

void F(char *a,char *b){
asm volatile("mov (%rdi),%al\nmov %al,(%rsi)");
}
...

> gcc -g -otest test.c -O2 -mtune=core2
> objdump -d test

004004f0 :
  4004f0:   0f b6 07movzbl (%rdi),%eax
  4004f3:   88 06   mov%al,(%rsi)
  4004f5:   c3  retq   
  4004f6:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
  4004fd:   00 00 00 

00400500 :
  400500:   8a 07   mov(%rdi),%al
  400502:   88 06   mov%al,(%rsi)
  400504:   c3  retq   

GCC use movzbl (%rdi),%eax, but better to use mov (%rdi),%al, because last
instruction 1 byte shorter. Execution time the same (at least on Core 2 Duo and
Core 2 Solo).

Probably it is result of Intel recomendations to use movz to avoid a partial
register stall. But smaller instruction reduce fetch bandwidth... and

Qwote from: Intel® 64 and IA-32 Architectures Optimization Reference Manual
248966. 3.5.2.3 Partial Register Stalls
"The delay of a partial register stall is small in processors based on Intel
Core and
NetBurst microarchitectures, and in Pentium M processor (with CPUID signature
family 6, model 13), Intel Core Solo, and Intel Core Duo processors. Pentium M
processors (CPUID signature with family 6, model 9) and the P6 family incur a
large
penalty."


-- 
   Summary: Nonoptimal byte load. mov (%rdi),%al better then movzbl
(%rdi),%eax
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vvv at ru dot ru


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

[Bug target/39545] structures with zero-length array passed/returned inconsistently

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-03-24 19:26 ---
A patch is posted at:

http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01144.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||03/msg01144.html
   Target Milestone|--- |4.4.0


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

Re: Small error in manual

[Dave Korn]

Ralf Wildenhues wrote:

> Thanks for the report.  OK to push this patch, tested 'make info pdf
> html'?

  You forgot "dvi".

cheers,
  DaveK

Re: Small error in manual

[Ralf Wildenhues]

* Dave Korn wrote on Tue, Mar 24, 2009 at 08:40:08PM CET:
> Ralf Wildenhues wrote:
> 
> > Thanks for the report.  OK to push this patch, tested 'make info pdf
> > html'?
> 
>   You forgot "dvi".

I forgot to mention it, but I did test it.  OK?

[Bug target/39545] structures with zero-length array passed/returned inconsistently

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-03-24 21:21 ---
The updated patch with testcases is at

http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01155.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-
   |03/msg01144.html|03/msg01155.html


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

[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate

[davidxl at gcc dot gnu dot org]

--- Comment #5 from davidxl at gcc dot gnu dot org  2009-03-24 21:25 ---
(In reply to comment #3)
> It might be better to place the check after the loop (and put an assert in
> set_copy_of_val that triggers the copy may not happen).
> 

This sounds good.

David


-- 


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

[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate

[davidxl at gcc dot gnu dot org]

--- Comment #6 from davidxl at gcc dot gnu dot org  2009-03-24 21:33 ---
(In reply to comment #4)
> Btw, it shouldn't really happen that we are not allowed to copyprop PHI
> arguments.  It hints at some inconsistency in the IL instead.
> 

This sounds good.

David(In reply to comment #4)
> Btw, it shouldn't really happen that we are not allowed to copyprop PHI
> arguments.  It hints at some inconsistency in the IL instead.
> 

Yes I suspect that too, but this is an independent issue. As long as the check
is done in replace_uses_in (tree-ssa-propagate), it should be done in the copy
chain computation -- at least it should be done in line 742 of tree-ssa-copy.c
(copy_prop_visit_cond_stmt), which was my original fix.

By the way, the check that fails in may_propagate_copy is -- which looks hairy.
If you think it is ok, I can file a different bug to track this.



  else if (!MTAG_P (SSA_NAME_VAR (dest))
   && !MTAG_P (SSA_NAME_VAR (orig))
   && (DECL_NO_TBAA_P (SSA_NAME_VAR (dest))
   != DECL_NO_TBAA_P (SSA_NAME_VAR (orig


Thanks,

David


-- 


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

[Bug testsuite/39550] New: compat tests for flexible array members

[jsm28 at gcc dot gnu dot org]

Bug 39545 is an x86_64 ABI issue relating to the handling of structures
with flexible array members in function call and return.  It seems likely
this corner case has bugs (and incompatibilities with other implementations)
for other targets as well.  There should be gcc.dg/compat tests specifically
testing the ABI when structures with flexible array members, and unions
containing such structures, are passed to or returned from functions
(including passing through ... and va_arg), covering various cases for the
types of the initial elements and the flexible array members.

If we believe that [0] arrays (the old GNU extension) at the ends of structures
should be passed identically to [] arrays (C99 flexible array members), which
is probably a good idea, then there should be tests of this as well.


-- 
   Summary: compat tests for flexible array members
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org


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

[Bug c++/28274] [4.2/4.3/4.4 Regression] Redeclaration with extra default argument doesn't work

[jason at gcc dot gnu dot org]

--- Comment #13 from jason at gcc dot gnu dot org  2009-03-24 22:26 ---
Subject: Bug 28274

Author: jason
Date: Tue Mar 24 22:26:21 2009
New Revision: 145042

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145042
Log:
PR c++/28274
* name-lookup.c (pushdecl_maybe_friend): Check default args later.

Added:
trunk/gcc/testsuite/g++.dg/parse/defarg14.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/28274] [4.2/4.3 Regression] Redeclaration with extra default argument doesn't work

[jason at gcc dot gnu dot org]

--- Comment #14 from jason at gcc dot gnu dot org  2009-03-24 22:27 ---
Fixed for 4.4.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3 Regression]
   |Redeclaration with extra|Redeclaration with extra
   |default argument doesn't|default argument doesn't
   |work|work


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

[Bug target/39545] structures with zero-length array passed/returned inconsistently

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2009-03-24 23:35 ---
The updated patch is at

http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01161.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-
   |03/msg01155.html|03/msg01161.html


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

Re: Small error in manual

[Dave Korn]

Ralf Wildenhues wrote:
> * Dave Korn wrote on Tue, Mar 24, 2009 at 08:40:08PM CET:
>> Ralf Wildenhues wrote:
>>
>>> Thanks for the report.  OK to push this patch, tested 'make info pdf
>>> html'?
>>   You forgot "dvi".
> 
> I forgot to mention it, but I did test it.  OK?

  Well, it aint my say-so, but it ought to be!

cheers,
  DaveK

[Bug c++/39551] New: C++ frontend not warn about unused dereference operator with -Wunused-value

[lcwu at gcc dot gnu dot org]

Given the following code, where the value of the dereference operation is
unused, 

$ cat unused_deref.c
void Foo(int* x) {
  *x++;
}

if it is compiled with gcc (C frontend) with -Wunused-value option, we get a
warning.

$ gcc -Wunused-value -c unused_deref.c
unused_deref.c: In function 'Foo':
unused_deref.c:2: warning: value computed is not used

However, if the code is compiled with g++, we don't get the warning.

$ g++ -Wunused-value -c unused_deref.c


After doing some triage, it appears that C++ frontend silently gets rid of
INDIRECT_REF operator (without emitting any warnings) when it processes the
expression '*x++' in convert_to_void() in cp/cvt.c.

Here is the version string of the compiler that I tried:
gcc version 4.4.0 20090324 (experimental) (GCC)


-- 
   Summary: C++ frontend not warn about unused dereference operator
with -Wunused-value
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lcwu at gcc dot gnu dot org
 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=39551

[Bug testsuite/39550] compat tests for flexible array members

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-03-25 00:40 ---
Flexible array member isn't allowed in union:

[...@gnu-34 pr39545]$ cat u-1.i
union line {
int length;
char contents[];
};

void foo (union line);

union line
bar ()
{
 union line x;
 x.length = sizeof (union line);
 foo (x);
 return x;
}
[...@gnu-34 pr39545]$ gcc -S u-1.i
u-1.i:3: error: flexible array member in union
[...@gnu-34 pr39545]$ 


-- 


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

[Bug testsuite/39550] compat tests for flexible array members

[joseph at codesourcery dot com]

--- Comment #2 from joseph at codesourcery dot com  2009-03-25 00:45 ---
Subject: Re:  compat tests for flexible array members

On Wed, 25 Mar 2009, hjl dot tools at gmail dot com wrote:

> Flexible array member isn't allowed in union:

However, a union may contain a structure that in turn contains a flexible 
array member.  And a union may contain a union containing such a 
structure, and so on.


-- 


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

Re: Small error in manual

[Ian Lance Taylor]

Ralf Wildenhues  writes:

> 2009-03-24  Ralf Wildenhues  
>
> * doc/invoke.texi (Debugging Options): Fix description of
> -fno-merge-debug-strings.

Really the original text is slightly wrong.

> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index d1c86dc..8b97fa0 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -4408,11 +4408,11 @@ This option works only with DWARF 2.
>  @item -fno-merge-debug-strings
>  @opindex fmerge-debug-strings
>  @opindex fno-merge-debug-strings
> -Direct the linker to merge together strings which are identical in
> -different object files.  This is not supported by all assemblers or
> -linker.  This decreases the size of the debug information in the
> -output file at the cost of increasing link processing time.  This is
> -on by default.
> +Direct the linker to not merge together strings which are identical in
> +different object files.  Merging is not supported by all assemblers or
> +linker.  It decreases the size of the debug information in the output
> +file at the cost of increasing link processing time.  Merging is enabled
> +by default.

This option only applies to strings in debugging information.  It should
say something like "Direct the linker to not merge together strings in
the debugging information which are identical in different object
files."  Also I think s/It decreases/Merging decreases/.

OK with those changes.

Thanks.

Ian

Re: [Bug testsuite/39550] compat tests for flexible array members

[Joseph S. Myers]

On Wed, 25 Mar 2009, hjl dot tools at gmail dot com wrote:

> Flexible array member isn't allowed in union:

However, a union may contain a structure that in turn contains a flexible 
array member.  And a union may contain a union containing such a 
structure, and so on.

-- 
Joseph S. Myers
jos...@codesourcery.com

[Bug middle-end/39552] New: Unnecessary stack usage with flexible array member

[hjl dot tools at gmail dot com]

After fixing PR 39545, I got

[...@gnu-34 pr39545]$ cat f-1.i
struct line {
int length;
char contents[];
};

void foo (struct line);

struct line
bar ()
{
 struct line x;
 x.length = sizeof (struct line);
 foo (x);
 return x;
}
[...@gnu-34 pr39545]$ make f-1.s
/export/build/gnu/gcc-avx/build-x86_64-linux/stage1-gcc/xgcc
-B/export/build/gnu/gcc-avx/build-x86_64-linux/stage1-gcc/ -O2
-fno-asynchronous-unwind-tables -S -o f-1.s f-1.i
f-1.i: In function ‘bar’:
f-1.i:10: note: The ABI of passing struct with a flexible array member has
changed in GCC 4.4
[...@gnu-34 pr39545]$ cat f-1.s
.file   "f-1.i"
.text
.p2align 4,,15
.globl bar
.type   bar, @function
bar:
subq$40, %rsp
movl$4, 16(%rsp)
movq16(%rsp), %rdi
callfoo
movl$4, %eax
addq$40, %rsp
ret
.size   bar, .-bar
[...@gnu-34 pr39545]$ cat f-3.i
struct line {
int length;
char contents[0];
};

void foo (struct line);

struct line
bar ()
{
 struct line x;
 x.length = sizeof (struct line);
 foo (x);
 return x;
}
[...@gnu-34 pr39545]$ make f-3.s
/export/build/gnu/gcc-avx/build-x86_64-linux/stage1-gcc/xgcc
-B/export/build/gnu/gcc-avx/build-x86_64-linux/stage1-gcc/ -O2
-fno-asynchronous-unwind-tables -S -o f-3.s f-3.i
[...@gnu-34 pr39545]$ cat f-3.s
.file   "f-3.i"
.text
.p2align 4,,15
.globl bar
.type   bar, @function
bar:
subq$8, %rsp
movl$4, %edi
callfoo
movl$4, %eax
addq$8, %rsp
ret
.size   bar, .-bar
[...@gnu-34 pr39545]$ 

With char contents[0], gcc doesn't touch stack. With char contents[],
we put value on stack even if it is passed in register.


-- 
   Summary: Unnecessary stack usage with flexible array member
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
 BugsThisDependsOn: 39545


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

Re: Small error in manual

[Ralf Wildenhues]

* Ian Lance Taylor wrote on Wed, Mar 25, 2009 at 01:51:01AM CET:
> 
> Really the original text is slightly wrong.
[...]
> This option only applies to strings in debugging information.  It should
> say something like "Direct the linker to not merge together strings in
> the debugging information which are identical in different object
> files."  Also I think s/It decreases/Merging decreases/.
> 
> OK with those changes.

Thanks, this is how I applied it (also s/assemblers or linker/&s/)
after retesting.

Cheers,
Ralf

2009-03-25  Ralf Wildenhues  

* doc/invoke.texi (Debugging Options): Fix description of
-fno-merge-debug-strings.

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 145050)
+++ gcc/doc/invoke.texi (working copy)
@@ -4408,11 +4408,11 @@
 @item -fno-merge-debug-strings
 @opindex fmerge-debug-strings
 @opindex fno-merge-debug-strings
-Direct the linker to merge together strings which are identical in
-different object files.  This is not supported by all assemblers or
-linker.  This decreases the size of the debug information in the
-output file at the cost of increasing link processing time.  This is
-on by default.
+Direct the linker to not merge together strings in the debugging
+information which are identical in different object files.  Merging is
+not supported by all assemblers or linkers.  Merging decreases the size
+of the debug information in the output file at the cost of increasing
+link processing time.  Merging is enabled by default.
 
 @item -fdebug-prefix-m...@var{old}=@var{new}
 @opindex fdebug-prefix-map