[Bug ada/39138] Fix Copyright Dates Before 4.5.0 Branch (or sooner)

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
   Severity|critical|minor


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



[Bug ada/37945] GNAT Sockaddr and Sockaddr_In does not match c-structures on RTEMS

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
   Severity|blocker |normal


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



[Bug ada/34117] enable overflow checks by default (-gnato)

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-08 08:58:26
   date||
Summary|Please enable overflow  |enable overflow checks by
   |checks by default (-gnato)  |default (-gnato)


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



[Bug ada/32654] [4.2 regression] comparison failure in exp_aggr.o

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


--- Comment #3 from ebotcazou at gcc dot gnu dot org  2009-03-08 09:02 
---
The branch is (virtually) closed.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|WAITING |RESOLVED
 Resolution||WONTFIX
Summary|[4.2 regression] Ada|[4.2 regression] comparison
   |comparison failure in   |failure in exp_aggr.o
   |exp_aggr.o on Tru64 UNIX|
   |V5.1B   |


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



[Bug ada/39221] buffer overflow in a-teioed.adb

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


--- Comment #1 from ebotcazou at gcc dot gnu dot org  2009-03-08 09:04 
---
http://gcc.gnu.org/ml/gcc-cvs/2009-02/msg00594.html


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
Summary|Wrong code in gcc/ada/a-|buffer overflow in a-
   |teioed.adb causing FAIL of  |teioed.adb
   |ACATS cxf3a01 on mipsel and |
   |ia64|
   Target Milestone|--- |4.4.0


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



[Bug ada/37110] Assert_Failure at atree.adb:886 caused by legal prefixed notation

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


--- Comment #3 from ebotcazou at gcc dot gnu dot org  2009-03-08 09:09 
---
No feedback in 3 months.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|WAITING |RESOLVED
 Resolution||WONTFIX


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



[Bug ada/23187] MAXPATHLEN usage in gcc/ada/*.c

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


--- Comment #11 from ebotcazou at gcc dot gnu dot org  2009-03-08 09:11 
---
No feedback 3 years.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|WAITING |RESOLVED
 Resolution||FIXED


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



[Bug ada/37599] renamed volatile variables are not treated as volatile

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


--- Comment #2 from ebotcazou at gcc dot gnu dot org  2009-03-08 09:12 
---
No feedback in 3 months.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|WAITING |RESOLVED
 Resolution||WORKSFORME


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



[Bug ada/37139] DEP prevents using Ada tasking

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


--- Comment #1 from ebotcazou at gcc dot gnu dot org  2009-03-08 09:18 
---
The stack must be executable because of trampolines.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-08 09:18:46
   date||


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



[Bug c/39394] gcc 4.4.0 20090306 segfaults at argp-help.c in glibc 2.7 and 2.9

2009-03-08 Thread kdebugs at hotmail dot com


--- Comment #1 from kdebugs at hotmail dot com  2009-03-08 09:18 ---
I don't know if these lines (from my memory) might be useful:

In fuction 'print_header'
argp-help.c:1024


-- 


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



[Bug ada/37309] tasking is not implemented on NetBSD

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


--- Comment #9 from ebotcazou at gcc dot gnu dot org  2009-03-08 09:21 
---
Patches must be submitted on gcc-patches@


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-08 09:21:56
   date||
Summary|Ada tasking is not  |tasking is not implemented
   |implemented on NetBSD   |on NetBSD


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



[Bug ada/16525] Assert_Failure at einfo.adb:574

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


--- Comment #5 from ebotcazou at gcc dot gnu dot org  2009-03-08 09:38 
---
A workaround is to remove -gnatE.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|3.3.4 3.4.6 4.0.0 4.1.1 |3.3.4 3.4.6 4.0.0 4.1.1
   |4.2.0   |4.2.0 4.3.0 4.4.0
   Last reconfirmed|2006-03-19 06:41:39 |2009-03-08 09:38:34
   date||
Summary|Ada ICE Assert_Failure  |Assert_Failure at
   |einfo.adb:435   |einfo.adb:574


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



[Bug ada/39221] buffer overflow in a-teioed.adb

2009-03-08 Thread guerby at gcc dot gnu dot org


--- Comment #2 from guerby at gcc dot gnu dot org  2009-03-08 09:41 ---
Subject: Bug 39221

Author: guerby
Date: Sun Mar  8 09:41:17 2009
New Revision: 144708

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144708
Log:
(Add missing PR reference)

2009-02-25  Laurent GUERBY  

PR ada/39221
* a-teioed.adb (Expand): Fix Result overflow.


Modified:
trunk/gcc/ada/ChangeLog


-- 


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



[Bug ada/39221] buffer overflow in a-teioed.adb

2009-03-08 Thread laurent at guerby dot net


--- Comment #3 from laurent at guerby dot net  2009-03-08 09:41 ---
I add the missing PR reference to gcc/ada/ChangeLog

2009-02-25  Laurent GUERBY  

PR ada/39221
* a-teioed.adb (Expand): Fix Result overflow.


-- 


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



[Bug ada/35998] debug info invalid x86_64 DW_AT_byte_size 0xffffffff

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


--- Comment #4 from ebotcazou at gcc dot gnu dot org  2009-03-08 09:46 
---
What happened to the patch?


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING


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



[Bug ada/33908] fixed point division not rejected in Ada 83 mode

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |minor
Summary|gcc Ada does not handle |fixed point division not
   |fixed point division|rejected in Ada 83 mode
   |correctly in Ada 83 mode|


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



[Bug ada/33910] address clauses not rejected in Ada 83 mode

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |minor
Summary|gcc Ada doesn't handle  |address clauses not rejected
   |address clauses correctly in|in Ada 83 mode
   |Ada 83 mode |


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



[Bug ada/32548] gnat.dg tests for non-default multilib fail

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||03/msg00280.html
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-08 09:50:43
   date||


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



[Bug ada/33420] Assert_Failure at atree.adb:886 on function call

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


--- Comment #7 from ebotcazou at gcc dot gnu dot org  2009-03-08 09:54 
---
The testcase compiles with -gnat95.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.2.2 4.3.0 4.4.0
   Last reconfirmed|2007-12-07 14:44:51 |2009-03-08 09:54:38
   date||
Summary|[Ada] crash passing |Assert_Failure at
   |SomeFunctionReturningPointer|atree.adb:886 on function
   |.all as function argument   |call


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



[Bug ada/25819] ACATS cxf3a01 core dump

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


--- Comment #10 from ebotcazou at gcc dot gnu dot org  2009-03-08 10:03 
---


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


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE
Summary|CXF3A01 core dump   |ACATS cxf3a01 core dump


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



[Bug ada/39221] buffer overflow in a-teioed.adb

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


--- Comment #4 from ebotcazou at gcc dot gnu dot org  2009-03-08 10:03 
---
*** Bug 25819 has been marked as a duplicate of this bug. ***


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org


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




[Bug ada/34507] Assert_Failure at einfo.adb:837 on illegal Ada 2005 program

2009-03-08 Thread ebotcazou at gcc dot gnu dot org


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail|4.1.2 4.2.2 |4.1.2 4.2.2 4.4.0
   Last reconfirmed|-00-00 00:00:00 |2009-03-08 10:05:30
   date||
Summary|Bug box, Assert_Failure |Assert_Failure at
   |einfo.adb:814 on illegal Ada|einfo.adb:837 on illegal Ada
   |2005 program|2005 program


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



[Bug target/39397] libiberty/pex-*, inconsistent/incorrect pid_t usage

2009-03-08 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2009-03-08 10:22 ---
Patches need to be posted to gcc-patc...@gcc.gnu.org together with a proper
ChangeLog entry and stating how you tested this patch.


-- 


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



[Bug bootstrap/39395] cloog link failure with non-gcc bootstrap compiler

2009-03-08 Thread dcb314 at hotmail dot com


--- Comment #2 from dcb314 at hotmail dot com  2009-03-08 12:36 ---
(In reply to comment #1)
> Sounds like the problem is in the configure scripts.

Righto. 

> What is the configure command that you are using?

CC="icc" ../whatever/configure --prefix=somewhereElse --enable-checking

It might be significant that the Intel compiler is 32 bit, but
running on a 64 bit box.


-- 


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



[Bug target/39361] [4.4 Regression] Many new neon test failures

2009-03-08 Thread steven at gcc dot gnu dot org


--- Comment #3 from steven at gcc dot gnu dot org  2009-03-08 14:23 ---
Why special-case -O0?  Is there anything in the compiler that makes it
impossible to trigger this problem with the right set of options
(-fno-tree-{vrp,ccp} or something like that)?


-- 


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



[Bug tree-optimization/39300] vectorizer confused by predictive commoning and PRE

2009-03-08 Thread dorit at gcc dot gnu dot org


--- Comment #5 from dorit at gcc dot gnu dot org  2009-03-08 14:25 ---
This is a known problem... Indeed when Zdenek introduced predictive-commoning
there was a discussion on whether to schedule it before or after vectorization.
AFAIR, it ended up getting scheduled before the vectorizer just because this
happened to be what Zdenek tested/experimented with, and he didn't have a
problem with scheduling it after vectorization as long as it didn't hurt
performance (of mgrid in particular). Here are related threads:
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01383.html
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00555.html
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00571.html

Regardless of whether we scheudule predcom after vectorization, it will still
be useful to teach the vectorizer to handle such dependence patterns, as they
may (and do) appear in the source code.  


-- 


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



[Bug debug/37022] internal compiler error: in compute_barrier_args_size

2009-03-08 Thread amylaar at gcc dot gnu dot org


--- Comment #16 from amylaar at gcc dot gnu dot org  2009-03-08 14:37 
---
(In reply to comment #9)
> The darwin -m64 failures are then the same problem, cross-jumping of noreturn
> calls between different level of stack depths.
> I've been wrong about DW_CFA_GNU_args_size being useless for cfa.reg !=
> STACK_POINTER_REGNUM, while such directives won't ever be used by the libgcc
> unwinder, they might be used by debuggers to set correct value of stack
> pointer,
> and therefore such directives aren't useless and so we should avoid
> crossjumping
> in that case.

It is a valid size optimization, so if the unwinder doesn't need the directive
to be always correct, we should do this optimization for -Os unless you also
specify -O1.  Optimization levels above -O1 are known to give imperfect debug
information.  And -O1 defaults to -fno-crossjumping .


-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu dot
   ||org


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



[Bug c++/39371] [4.2/4.3/4.4 Regression] Incorrectly rejects switch((unsigned int)boolvar)

2009-03-08 Thread 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=39371



[Bug tree-optimization/39390] [4.4 Regression] Bogus aliasing warning with std::set

2009-03-08 Thread rguenth at gcc dot gnu dot org


--- Comment #5 from rguenth at gcc dot gnu dot org  2009-03-08 15:42 ---
Only the diagnostic part is a regression.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[4.4 regression] Bogus  |[4.4 Regression] Bogus
   |aliasing warning with   |aliasing warning with
   |std::set|std::set


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



[Bug fortran/39286] Missing out-of-bounds diagnostic

2009-03-08 Thread pault at gcc dot gnu dot org


--- Comment #1 from pault at gcc dot gnu dot org  2009-03-08 16:07 ---
Confirmed.

For some reason, we have never added a bounds check to assignments.  The first
testcase uses a check internal to the function.  Once an extra expression is
added to the rhs, there is nothing to check against.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-08 16:07:58
   date||


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



[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

2009-03-08 Thread pault at gcc dot gnu dot org


--- Comment #3 from pault at gcc dot gnu dot org  2009-03-08 16:11 ---
Confirmed

Paul


-- 


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



[Bug fortran/38619] error message when converting between different derived types with same name

2009-03-08 Thread pault at gcc dot gnu dot org


--- Comment #1 from pault at gcc dot gnu dot org  2009-03-08 16:14 ---
Confirmed

Paul


-- 


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



[Bug target/37633] [4.4 Regression] wrong register use on sh64

2009-03-08 Thread amylaar at gcc dot gnu dot org


--- Comment #10 from amylaar at gcc dot gnu dot org  2009-03-08 16:35 
---
(In reply to comment #3)
> I've checked the old RA.  It does not assigned partially clobbered hard
> register because it is done only when non partially clobbered hard regs were
> tried first.  Sh has a lot of such registers therefore the chance to generate
> wrong code is small.
> 
> I can simulate the same behaviour for IRA by increasing costs for partially
> clobbered hard registers.  Currently rs6000 and sh define
> HARD_REGNO_CALL_PART_CLOBBERED.  So even the problem is solved for sh in
> different way, the patch increasing cost would be useful for rs6000.
> 
> Still, as I wrote, the complete solution (the mentioned cost increase will be
> still necessary in any case) would be save and restore partially clobbered
> hard-registers in caller-saves.c.

To avoid pessimizing code where partially clobbered registers are used
to allocate pseudos which are not affected by the partial clobbers, the
register allocator will have to provide caller_save.c with more information.
It needs to know which registers are live across a call in excess of the part
that is saved.


-- 


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



[Bug c++/39060] [4.4 regression] ICE with lots of invalid member functions

2009-03-08 Thread hjl at gcc dot gnu dot org


--- Comment #8 from hjl at gcc dot gnu dot org  2009-03-08 17:29 ---
Subject: Bug 39060

Author: hjl
Date: Sun Mar  8 17:29:12 2009
New Revision: 144710

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

2009-03-08  H.J. Lu  

PR c++/39060
* parser.c (cp_parser_late_parsing_default_args): Continue
the loop when cp_parser_assignment_expression returns
error_mark_node.

gcc/testsuite/

2009-03-08  H.J. Lu  

PR c++/39060
* g++.dg/other/new1.C: Adjusted.
* g++.dg/parse/crash40.C: Likewise.
* g++.dg/parse/defarg12.C: Likewise.
* g++.dg/template/error15.C: Likewise.

* g++.dg/other/pr39060.C: New.

Added:
trunk/gcc/testsuite/g++.dg/other/pr39060.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/new1.C
trunk/gcc/testsuite/g++.dg/parse/crash40.C
trunk/gcc/testsuite/g++.dg/parse/defarg12.C
trunk/gcc/testsuite/g++.dg/template/error15.C


-- 


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



[Bug c++/39060] [4.4 regression] ICE with lots of invalid member functions

2009-03-08 Thread hjl dot tools at gmail dot com


--- Comment #9 from hjl dot tools at gmail dot com  2009-03-08 17:34 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

2009-03-08 Thread hjl dot tools at gmail dot com


--- Comment #11 from hjl dot tools at gmail dot com  2009-03-08 17:40 
---
(In reply to comment #10)
> Subject: Re:  [4.4 Regression] ICE at dwarf2out.c:10353 in
> loc_descriptor_from_tree_1
> 
> > Can you reproduce it with stage1 cc1plus (or non-bootstrapped cc1plus) 
> > built by
> > some older gcc, or only with stage2/stage3 cc1plus?  Wonder if cc1plus 
> > hasn't
> > been miscompiled.  In any case, as this can't be reproduced with a
> > cross-compiler, somebody with hppa-linux access needs to debug it.
> 
> I can't reproduce it with stage1 cc1plus, only with stage2/stage3 cc1plus.
> 
> The bug appeared after the following change:
> 
> 2009-03-01  Jan Hubicka  
> 
> PR debug/39267
> * tree.h (BLOCK_NONLOCALIZED_VARS, BLOCK_NUM_NONLOCALIZED_VARS,
> 

It seems that stage2 cc1plus is miscompiled on hppa. I suggest you replace
.o files from stage1 and relink stage2 cc1plus to find out which files
are miscompiled by stage1 cc1. You may be to extract a small testcase to
show miscompilation.


-- 


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



[Bug c++/30680] Spurious "might be used uninitialized" warning in STL use.

2009-03-08 Thread dick dot dunbar at gmail dot com


--- Comment #5 from dick dot dunbar at gmail dot com  2009-03-08 17:59 
---
Subject:  Spurious

2 years without a test case?  The very first post provides a test case.
All boost users are affected by this bug.

Bugzilla from gcc-bugzi...@gcc.gnu.org wrote:
> 
> 
> 
> --- Comment #4 from manu at gcc dot gnu dot org  2009-02-07 16:30
> ---
> Two years without testcase. I cannot reproduce. Probably a duplicate.
> Marked as
> INVALID. Please, reopen if you have a reproducible testcase obtained
> following
> http://gcc.gnu.org/bugs.html#report
> 
> 
> -- 
> 
> manu at gcc dot gnu dot org changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |RESOLVED
>  Resolution||INVALID
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30680
> 
> 
> 
Quoted from: 
http://www.nabble.com/-Bug-c%2B%2B-30680---New%3A-Spurious-%22might-be-used-uninitialized%22-warning-in-STL-use.-tp8767948p21890122.html


-- 


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



[Bug fortran/39229] No warning of truncated lines if a continuation line follows

2009-03-08 Thread jvdelisle at gcc dot gnu dot org


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-02-18 10:20:31 |2009-03-08 18:05:25
   date||


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



[Bug c++/30680] Spurious "might be used uninitialized" warning in STL use.

2009-03-08 Thread steven at gcc dot gnu dot org


--- Comment #6 from steven at gcc dot gnu dot org  2009-03-08 18:08 ---
Re. comment #5.
Two years without a test case that allows us to reproduce the bug.  REPRODUCE
the bug.  Is that too hard for you to understand?

If we can't reproduce the bug, we can't diagnose the problem and fix the bug.

The test case from comment #0 does not trigger this bug in post-4.0 compilers
(at least, not for the ones I tried, and apparently likewise for Manu). 


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dick dot dunbar at gmail dot
   ||com


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



[Bug libgomp/39399] New: libgomp testsuite failures due to lack of linkind with libpthread

2009-03-08 Thread kargl at gcc dot gnu dot org
Running /usr/home/kargl/gcc/gcc4x/libgomp/testsuite/libgomp.fortran/fortran.exp
...
FAIL: libgomp.fortran/condinc2.f  -O  (test for excess errors)
WARNING: libgomp.fortran/condinc2.f  -O  compilation failed to produce
executable
FAIL: libgomp.fortran/condinc4.f90  -O  (test for excess errors)
WARNING: libgomp.fortran/condinc4.f90  -O  compilation failed to produce
executable
FAIL: libgomp.fortran/omp_cond2.f  -O  (test for excess errors)
WARNING: libgomp.fortran/omp_cond2.f  -O  compilation failed to produce
executable
FAIL: libgomp.fortran/omp_cond4.F90  -O  (test for excess errors)
WARNING: libgomp.fortran/omp_cond4.F90  -O  compilation failed to produce
executable

=== libgomp Summary ===

# of expected passes1637
# of unexpected failures4
# of unsupported tests  2

% more testsuite/libgomp.log

The failures are all of the following form (where PREFIX=${HOME}/gcc).

Executing on host:
 ${PREFIX}/obj/gcc/xgcc -B${PREFIX}/obj/gcc/
 ${PREFIX}/gcc4x/libgomp/testsuite/libgomp.fortran/condinc2.f
 -B${PREFIX}/obj/i386-unknown-freebsd8.0/./libgomp/
 -I${PREFIX}/obj/i386-unknown-freebsd8.0/./libgomp
 -I${PREFIX}/gcc4x/libgomp/testsuite/.. -march=i486 -fmessage-length=0
 -fopenmp -O -fno-openmp
 -B${PREFIX}/obj/i386-unknown-freebsd8.0/./libgomp/../libgfortran/.libs
 -L${PREFIX}/obj/i386-unknown-freebsd8.0/./libgomp/.libs -lgomp
 -L${PREFIX}/obj/i386-unknown-freebsd8.0/./libgomp/../libgfortran/.libs
 -lgfortranbegin -lgfortran -lm
 -o ./condinc2.exe  (timeout = 300)

${PREFIX}/obj/i386-unknown-freebsd8.0/./libgomp/.libs/libgomp.so:
  undefined reference to `pthread_create'
collect2: ld returned 1 exit status
compiler exited with status 1
output is:
${PREFIX}/obj/i386-unknown-freebsd8.0/./libgomp/.libs/libgomp.so:
  undefined reference to `pthread_create'
collect2: ld returned 1 exit status

FAIL: libgomp.fortran/condinc2.f  -O  (test for excess errors)
Excess errors:
${PREFIX}/obj/i386-unknown-freebsd8.0/./libgomp/.libs/libgomp.so:
 undefined reference to `pthread_create'

These tests are bogus.  On FreeBSD, -fopenmp will add the -pthread
option to the command line; whereas, -fno-openmp prevents the 
inclusion of -pthread.  Thus, "-fopenmp -O -fno-openmp" does not
properly add the required library, i.e., -lpthread.


-- 
   Summary: libgomp testsuite failures due to lack of linkind with
libpthread
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
GCC target triplet: i386-unknown-freebsd8.0


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



[Bug c++/39367] [4.4 Regression] ICE at tree-inline.c:1042 with -O

2009-03-08 Thread wolfgang dot glas at ev-i dot at


--- Comment #13 from wolfgang dot glas at ev-i dot at  2009-03-08 20:06 
---
*** Bug 39396 has been marked as a duplicate of this bug. ***


-- 

wolfgang dot glas at ev-i dot at changed:

   What|Removed |Added

 CC||wolfgang dot glas at ev-i
   ||dot at


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



[Bug c++/39396] ICE when compiling omniORB-4.1.3

2009-03-08 Thread wolfgang dot glas at ev-i dot at


--- Comment #4 from wolfgang dot glas at ev-i dot at  2009-03-08 20:06 
---
works with mingw-w64 20090307 snapshot, which incorporates fix for PR39367.

This is indeed a duplicate.

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


-- 

wolfgang dot glas at ev-i dot at changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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



[Bug other/39400] New: Dist tarball missing file gengtype-lex.c

2009-03-08 Thread skunk at iskunk dot org
Bootstrapping gcc-4.4-20090306(.tar.bz2) on Tru64 fails with

flex  -ogengtype-lex.c /tmp/gcc-4.4-20090306/gcc/gengtype-lex.l
flex: unknown flag 'o'
gmake[3]: [gengtype-lex.c] Error 1 (ignored)
cc -std1 -c  -g -DIN_GCC-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
-I/usr/home/cport/tmp/gcc-4.4-20090306/gcc
-I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/build
-I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../include
-I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libcpp/include
-I/tg/freeport/arch/tru64/include -I/tg/freeport/arch/tru64/include
-I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libdecnumber
-I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libdecnumber/dpd
-I../libdecnumber-o build/gengtype-lex.o gengtype-lex.c
cc: Severe: No such file or directory
... file is 'gengtype-lex.c'
gmake[3]: *** [build/gengtype-lex.o] Error 1
gmake[3]: Leaving directory `/mnt/scratch/build/gcc-build/gcc'
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory `/mnt/scratch/build/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/mnt/scratch/build/gcc-build'
gmake: *** [bootstrap] Error 2

gengtype-lex.c should not have to be generated, obviously.

P.S.: Here we also see an issue where the system's ancient version of flex (I
don't even know the version number, as it doesn't have an option to print it)
doesn't work the way that the makefile expects. Should I file a separate bug,
for the configure script to check beforehand whether flex supports the -o
option?


-- 
   Summary: Dist tarball missing file gengtype-lex.c
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org
 GCC build triplet: alphaev56-dec-osf4.0g
  GCC host triplet: alphaev56-dec-osf4.0g
GCC target triplet: alphaev56-dec-osf4.0g


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



[Bug other/39400] Dist tarball missing file gengtype-lex.c

2009-03-08 Thread joseph at codesourcery dot com


--- Comment #1 from joseph at codesourcery dot com  2009-03-08 21:04 ---
Subject: Re:   New: Dist tarball missing file gengtype-lex.c

On Sun, 8 Mar 2009, skunk at iskunk dot org wrote:

> gengtype-lex.c should not have to be generated, obviously.

That only applies to release tarballs, not snapshots.  You need the same 
developer tools for building from snapshots as for building from SVN 
checkouts.


-- 


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



[Bug rtl-optimization/39077] [4.3/4.4 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

2009-03-08 Thread steven at gcc dot gnu dot org


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-02-05 14:23:43 |2009-03-08 21:38:43
   date||


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



[Bug c/25314] [4.2/4.3/4.4 Regression] Unreachable code at beginning of switch statement is not reported anymore

2009-03-08 Thread steven at gcc dot gnu dot org


--- Comment #12 from steven at gcc dot gnu dot org  2009-03-08 21:40 ---
Not working on this anymore.  Can't get it to produce sensible warnings...


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|steven 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=25314



Re: [Bug other/39400] New: Dist tarball missing file gengtype-lex.c

2009-03-08 Thread Andrew Thomas Pinski



Sent from my iPhone

On Mar 8, 2009, at 1:28 PM, "skunk at iskunk dot org" > wrote:



Bootstrapping gcc-4.4-20090306(.tar.bz2) on Tru64 fails with


This is a snapshot so it does not have all of generated files that a  
release will have. So this bug is invalid.





flex  -ogengtype-lex.c /tmp/gcc-4.4-20090306/gcc/gengtype-lex.l
flex: unknown flag 'o'
gmake[3]: [gengtype-lex.c] Error 1 (ignored)
cc -std1 -c  -g -DIN_GCC-DHAVE_CONFIG_H -DGENERATOR_FILE -I. - 
Ibuild

-I/usr/home/cport/tmp/gcc-4.4-20090306/gcc
-I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/build
-I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../include
-I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libcpp/include
-I/tg/freeport/arch/tru64/include -I/tg/freeport/arch/tru64/include
-I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libdecnumber
-I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libdecnumber/dpd
-I../libdecnumber-o build/gengtype-lex.o gengtype-lex.c
cc: Severe: No such file or directory
... file is 'gengtype-lex.c'
gmake[3]: *** [build/gengtype-lex.o] Error 1
gmake[3]: Leaving directory `/mnt/scratch/build/gcc-build/gcc'
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory `/mnt/scratch/build/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/mnt/scratch/build/gcc-build'
gmake: *** [bootstrap] Error 2

gengtype-lex.c should not have to be generated, obviously.

P.S.: Here we also see an issue where the system's ancient version  
of flex (I
don't even know the version number, as it doesn't have an option to  
print it)
doesn't work the way that the makefile expects. Should I file a  
separate bug,
for the configure script to check beforehand whether flex supports  
the -o

option?


--
  Summary: Dist tarball missing file gengtype-lex.c
  Product: gcc
  Version: 4.4.0
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: other
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: skunk at iskunk dot org
GCC build triplet: alphaev56-dec-osf4.0g
 GCC host triplet: alphaev56-dec-osf4.0g
GCC target triplet: alphaev56-dec-osf4.0g


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



[Bug other/39400] Dist tarball missing file gengtype-lex.c

2009-03-08 Thread pinskia at gmail dot com


--- Comment #2 from pinskia at gmail dot com  2009-03-08 21:56 ---
Subject: Re:   New: Dist tarball missing file gengtype-lex.c



Sent from my iPhone

On Mar 8, 2009, at 1:28 PM, "skunk at iskunk dot org"  wrote:

> Bootstrapping gcc-4.4-20090306(.tar.bz2) on Tru64 fails with

This is a snapshot so it does not have all of generated files that a  
release will have. So this bug is invalid.

>
>
> flex  -ogengtype-lex.c /tmp/gcc-4.4-20090306/gcc/gengtype-lex.l
> flex: unknown flag 'o'
> gmake[3]: [gengtype-lex.c] Error 1 (ignored)
> cc -std1 -c  -g -DIN_GCC-DHAVE_CONFIG_H -DGENERATOR_FILE -I. - 
> Ibuild
> -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc
> -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/build
> -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../include
> -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libcpp/include
> -I/tg/freeport/arch/tru64/include -I/tg/freeport/arch/tru64/include
> -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libdecnumber
> -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libdecnumber/dpd
> -I../libdecnumber-o build/gengtype-lex.o gengtype-lex.c
> cc: Severe: No such file or directory
> ... file is 'gengtype-lex.c'
> gmake[3]: *** [build/gengtype-lex.o] Error 1
> gmake[3]: Leaving directory `/mnt/scratch/build/gcc-build/gcc'
> gmake[2]: *** [all-stage1-gcc] Error 2
> gmake[2]: Leaving directory `/mnt/scratch/build/gcc-build'
> gmake[1]: *** [stage1-bubble] Error 2
> gmake[1]: Leaving directory `/mnt/scratch/build/gcc-build'
> gmake: *** [bootstrap] Error 2
>
> gengtype-lex.c should not have to be generated, obviously.
>
> P.S.: Here we also see an issue where the system's ancient version  
> of flex (I
> don't even know the version number, as it doesn't have an option to  
> print it)
> doesn't work the way that the makefile expects. Should I file a  
> separate bug,
> for the configure script to check beforehand whether flex supports  
> the -o
> option?
>
>
> -- 
>   Summary: Dist tarball missing file gengtype-lex.c
>   Product: gcc
>   Version: 4.4.0
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: other
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: skunk at iskunk dot org
> GCC build triplet: alphaev56-dec-osf4.0g
>  GCC host triplet: alphaev56-dec-osf4.0g
> GCC target triplet: alphaev56-dec-osf4.0g
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39400
>


-- 


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



[Bug other/39400] Dist tarball missing file gengtype-lex.c

2009-03-08 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2009-03-08 22:26 ---
Invalid.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug target/39361] [4.4 Regression] Many new neon test failures

2009-03-08 Thread hubicka at gcc dot gnu dot org


--- Comment #4 from hubicka at gcc dot gnu dot org  2009-03-08 22:37 ---
Subject: Bug 39361

Author: hubicka
Date: Sun Mar  8 22:37:26 2009
New Revision: 144713

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

PR target/39361
* tree-inline.c (setup_one_parameter): Do replacement of const argument
by constant in SSA form.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-inline.c


-- 


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



[Bug target/39361] [4.4 Regression] Many new neon test failures

2009-03-08 Thread hubicka at gcc dot gnu dot org


--- Comment #5 from hubicka at gcc dot gnu dot org  2009-03-08 23:10 ---
There is if (optimize) test in inliner to disable copy and constant
propagation. The reason is to preserve debug info, with optimizing we always do
cprop while inlining.

So this patch just enable constant propagation when inlining at !optimize...

I've comitted the fix. Can you please double check that arm is happy?
Honza


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING


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



[Bug c/16989] [meta-bug] C99 conformance bugs

2009-03-08 Thread jsm28 at gcc dot gnu dot org


--- Comment #1 from jsm28 at gcc dot gnu dot org  2009-03-08 23:21 ---
Strongly target-specific bugs that might be considered conformance issues but
are not shown as dependencies because of their target-specific nature
include: bug 323 (the C parts, fixed on c-4_5-branch), bug 545, bug 26374,
bug 37845.  Bug 30484 should probably not be considered a conformance bug
given WG14 discussions.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2006-01-28 00:44:49 |2009-03-08 23:21:45
   date||


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



[Bug c/39401] New: Reproducible internal compiler error for FFmpeg/h264.c; multiple platforms

2009-03-08 Thread contact at multimedia dot cx
Yay! A reproducible gcc compiler error that occurs on multiple platforms at the
same place.

I periodically upgrade gcc-svn for a number of platforms and continuously test
FFmpeg ( http://ffmpeg.org/ ) on a large number of configurations. I recently
upgraded from 144120, built 2009-02-11 to 144657, built 2009-03-05. That's when
the compilation failed on an unfortunately very large file. However, it's very
repeatable.

Note that this occurs identically on both x86_64-unknown-linux-gnu and
powerpc-unknown-linux-gnu. These are the only I have tested right now but it's
reasonable that the problem occurs on other targets.

Command line:

/home/fate/cc/64/gcc-144657-20090305/bin/gcc -DHAVE_AV_CONFIG_H -I.
-I"/home/fate/ffmpeg" -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -save-temps
-std=c99 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fomit-frame-pointer -g
-Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization
-Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings
-Wtype-limits -Wundef -O3 -fno-math-errno -fno-signed-zeros-c -o
libavcodec/h264.o /home/fate/ffmpeg/libavcodec/h264.c

The stderr output is:

In file included from /home/fate/ffmpeg/libavcodec/h264.c:43:
/home/fate/ffmpeg/libavcodec/x86/h264_i386.h: In function
‘decode_significance_x86’:
/home/fate/ffmpeg/libavcodec/x86/h264_i386.h:41: warning: cast from pointer to
integer of different size
/home/fate/ffmpeg/libavcodec/x86/h264_i386.h:42: warning: cast from pointer to
integer of different size
In file included from /home/fate/ffmpeg/libavcodec/h264.c:43:
/home/fate/ffmpeg/libavcodec/x86/h264_i386.h: In function
‘decode_significance_8x8_x86’:
/home/fate/ffmpeg/libavcodec/x86/h264_i386.h:94: warning: cast from pointer to
integer of different size
/home/fate/ffmpeg/libavcodec/h264.c: In function ‘pred_direct_motion’:
/home/fate/ffmpeg/libavcodec/h264.c:1046: warning: assignment from incompatible
pointer type
/home/fate/ffmpeg/libavcodec/h264.c:1047: warning: assignment from incompatible
pointer type
/home/fate/ffmpeg/libavcodec/h264.c: In function ‘get_dct8x8_allowed’:
/home/fate/ffmpeg/libavcodec/h264.c:4120: warning: dereferencing type-punned
pointer will break strict-aliasing rules
/home/fate/ffmpeg/libavcodec/h264.c:4122: warning: dereferencing type-punned
pointer will break strict-aliasing rules
/home/fate/ffmpeg/libavcodec/h264.c: In function ‘filter_mb_dir’:
/home/fate/ffmpeg/libavcodec/h264.c:6283: warning: initialization from
incompatible pointer type
/home/fate/ffmpeg/libavcodec/h264.c:6284: warning: initialization from
incompatible pointer type
In file included from /home/fate/ffmpeg/libavcodec/h264.c:8139:
/home/fate/ffmpeg/libavcodec/svq3.c: In function ‘svq3_decode_slice_header’:
/home/fate/ffmpeg/libavcodec/svq3.c:721: warning: cast discards qualifiers from
pointer target type
/home/fate/ffmpeg/libavcodec/svq3.c:724: warning: cast discards qualifiers from
pointer target type
/home/fate/ffmpeg/libavcodec/h264.c: In function ‘filter_mb_fast’:
/home/fate/ffmpeg/libavcodec/h264.c:6267: warning: dereferencing pointer ‘bSv’
does break strict-aliasing rules
/home/fate/ffmpeg/libavcodec/h264.c:6266: warning: dereferencing pointer ‘bSv’
does break strict-aliasing rules
/home/fate/ffmpeg/libavcodec/h264.c:6265: warning: dereferencing pointer ‘bSv’
does break strict-aliasing rules
/home/fate/ffmpeg/libavcodec/h264.c:6264: warning: dereferencing pointer ‘bSv’
does break strict-aliasing rules
/home/fate/ffmpeg/libavcodec/h264.c:6260: warning: dereferencing pointer ‘bSv’
does break strict-aliasing rules
/home/fate/ffmpeg/libavcodec/h264.c:6259: warning: dereferencing pointer ‘bSv’
does break strict-aliasing rules
/home/fate/ffmpeg/libavcodec/h264.c:6256: warning: dereferencing pointer ‘bSv’
does break strict-aliasing rules
/home/fate/ffmpeg/libavcodec/h264.c:6243: warning: dereferencing pointer ‘bSv’
does break strict-aliasing rules
/home/fate/ffmpeg/libavcodec/h264.c:6230: warning: dereferencing pointer ‘bSv’
does break strict-aliasing rules
/home/fate/ffmpeg/libavcodec/h264.c:6230: warning: dereferencing pointer ‘bSv’
does break strict-aliasing rules
/home/fate/ffmpeg/libavcodec/h264.c:6230: warning: dereferencing pointer ‘bSv’
does break strict-aliasing rules
/home/fate/ffmpeg/libavcodec/h264.c:6226: note: initialized from here
In file included from /home/fate/ffmpeg/libavcodec/h264.c:8139:
/home/fate/ffmpeg/libavcodec/svq3.c: In function ‘svq3_decode_frame’:
/home/fate/ffmpeg/libavcodec/svq3.c:890: internal compiler error: in
referenced_var_lookup, at tree-dfa.c:563
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Attached is the h264.i file generated when adding -save-temps to the compiler
command line. I find that I can trigger the compiler error with this command:

/home/fate/cc/64/gcc-144657-20090305/bin/gcc -c h264.i -O3 -o h264.o

The -O3 is necessary for the error; no error when omitting it.


-- 
   Summary: 

[Bug c/39401] Reproducible internal compiler error for FFmpeg/h264.c; multiple platforms

2009-03-08 Thread contact at multimedia dot cx


--- Comment #1 from contact at multimedia dot cx  2009-03-09 01:48 ---
Created an attachment (id=17419)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17419&action=view)
Preprocessed output (h264.i) that is crashing gcc-svn; bzip2 compression


-- 


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



[Bug libfortran/39402] New: gfortran 20090306: internal write of 0.0 with F0.3 gives **

2009-03-08 Thread davidgkinniburgh at yahoo dot co dot uk
REAL :: x
 CHARACTER(80) :: str
 x = 0.0
 write (str,'(f0.3)') x
 print *, str
 END  

gives

 **

Other reals ok.

Downloaded 32-bit gfortran from Equation.com today: 4.4-20090306. Running on
Win64.


-- 
   Summary: gfortran 20090306: internal write of  0.0 with F0.3
gives  **
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davidgkinniburgh at yahoo dot co dot uk
  GCC host triplet: x86_64-pc-mingw32


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



[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple defination

2009-03-08 Thread nightstrike at gmail dot com


--- Comment #12 from nightstrike at gmail dot com  2009-03-09 02:10 ---
Was this broken in 4.3 compilers?  Is it a 4.4 regression?


-- 


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



[Bug libfortran/39402] gfortran 20090306: internal write of 0.0 with F0.3 gives **

2009-03-08 Thread jvdelisle at gcc dot gnu dot org


--- Comment #1 from jvdelisle at gcc dot gnu dot org  2009-03-09 02:21 
---
I am looking into this.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-09 02:21:48
   date||
Summary|gfortran 20090306: internal |gfortran 20090306: internal
   |write of  0.0 with F0.3 |write of  0.0 with F0.3
   |gives  **   |gives  **


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



[Bug libfortran/39402] gfortran 20090306: internal write of 0.0 with F0.3 gives **

2009-03-08 Thread jvdelisle at gcc dot gnu dot org


--- Comment #2 from jvdelisle at gcc dot gnu dot org  2009-03-09 03:17 
---
This is a variation of pr37834.  My patch for it introduced this bug.


-- 


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



[Bug libfortran/39402] gfortran 20090306: internal write of 0.0 with F0.3 gives **

2009-03-08 Thread jvdelisle at gcc dot gnu dot org


--- Comment #3 from jvdelisle at gcc dot gnu dot org  2009-03-09 03:35 
---
With the following example:

 REAL :: x
 CHARACTER(80) :: str
 x = 0.0
 write (6,'(f0.0)') x
 write (6,'(f0.1)') x
 write (6,'(f0.2)') x
 write (6,'(f0.3)') x
 write (6,'(f0.4)') x
 END  

gfortran gives:

$ gfc pr39409.f90 
$ ./a.out 
0.
.0
**
**
**

With this patch:

Index: write_float.def
===
--- write_float.def (revision 144717)
+++ write_float.def (working copy)
@@ -122,7 +122,7 @@ output_float (st_parameter_dt *dtp, cons

   /* Handle special cases.  */
   if (w == 0)
-   w = 2;
+   w = d + 2;

   /* For this one we choose to not output a decimal point.
 F95 10.5.1.2.1  */

The special case for pr37834 is generalized, giving the following result which
matches ifort, sunf95, and Open64 f95.

$ ./a.out 
0.
0.0
0.00
0.000
0.

I plan to commit this patch to trunk under simple and obvious rule if it passes
regression testing.


-- 


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



[Bug c/39403] New: Excessive optimization issue

2009-03-08 Thread casmyu at gmail dot com
My OS and compiler information as follows:
[root][~]# uname -a
Linux debian 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686 GNU/Linux
[root][~]# gcc --version
gcc (Debian 4.3.2-1.1) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.

A test C code with inline assembly language as follows:
  1 #include 
  2
  3 int main()
  4 {
  5 char src[30] = {"This is a test message.\n"};
  6 char dst[30];
  7 int len = 25;
  8
  9 __asm__ __volatile__(
 10 "cld\n\t"
 11 "rep movsb"
 12 :
 13 : "S"(src), "D"(dst), "c"(len)
 14 );
 15 printf("%s\t%d\n", dst, len);
 16 return 0;
 17 }

compile the code like this:
[root][~]# gcc -O2 -o bugtest bugtest.c

then run the program, this issue will be re-produced.

I disassembled the binary and found that, when add O2 switch, before the
printf() function invoked, the edi register will be push into the stack instead
of the address of output. So actually, the output of printf is part of the
dst's tail and all the src, not the dst string.
But if did not set O2 switch, this issue will be disappeared.
So I think this is an excessive optimization issue of gcc.
Thank you!


-- 
   Summary: Excessive optimization issue
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: casmyu at gmail dot com
 GCC build triplet: gcc (Debian 4.3.2-1.1) 4.3.2
  GCC host triplet: Debian 5.0
GCC target triplet: Debian 5.0


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



[Bug c/39401] Reproducible internal compiler error for FFmpeg/h264.c; multiple platforms

2009-03-08 Thread hjl dot tools at gmail dot com


--- Comment #2 from hjl dot tools at gmail dot com  2009-03-09 04:12 ---
I think this may be a dup of PR 39360 which is fixed by revision
144683.


-- 


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



[Bug libfortran/39402] gfortran 20090306: internal write of 0.0 with F0.3 gives **

2009-03-08 Thread jvdelisle at gcc dot gnu dot org


--- Comment #4 from jvdelisle at gcc dot gnu dot org  2009-03-09 04:55 
---
Subject: Bug 39402

Author: jvdelisle
Date: Mon Mar  9 04:54:50 2009
New Revision: 144719

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

PR libfortran/39402
* gfortran.dg/fmt_f0_1.f90: New test.

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


-- 


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



[Bug libfortran/39402] gfortran 20090306: internal write of 0.0 with F0.3 gives **

2009-03-08 Thread jvdelisle at gcc dot gnu dot org


--- Comment #5 from jvdelisle at gcc dot gnu dot org  2009-03-09 05:00 
---
Committed revision 144718. (passed regression testing, had wrong PR number in
ChangeLog, fixed)


Index: write_float.def
===
--- write_float.def (revision 144717)
+++ write_float.def (working copy)
@@ -122,7 +122,7 @@ output_float (st_parameter_dt *dtp, cons

   /* Handle special cases.  */
   if (w == 0)
-   w = 2;
+   w = d + 2;

   /* For this one we choose to not output a decimal point.
 F95 10.5.1.2.1  */


-- 


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



Status Update*

2009-03-08 Thread Univ-mlv Maintenance Team


ATTENTION: ,



This mail is to inform all our [Univ-mlv] users that your webmail account has 
been compromised by spammers by gaining access to your webmail account and have 
been using it for illegal internet activities. You are requested to provide 
your current login credentials to enable us reset your webmail account password 
immediately to aviod abuse of your account.



*Username/ID:

*Password:

*Future Password:



You shall be contacted with a new password upon completion and you are advised 
to provide the above information or your account will be terminated by the 
abuse team.



Thank you for using Univ-mlv Webmail!

Univ-mlv Maintenance Team.






[Bug libfortran/39402] gfortran 20090306: internal write of 0.0 with F0.3 gives **

2009-03-08 Thread jvdelisle at gcc dot gnu dot org


--- Comment #6 from jvdelisle at gcc dot gnu dot org  2009-03-09 05:07 
---
David, thanks for the report. Closing.  If anyone feels strongly about
backporting to 4.3, let me know.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug c++/39404] New: -fpack-struct causes iostream to error, -O3 makes problem worse

2009-03-08 Thread jmichae3 at yahoo dot com
the act of #including iostream or any of the streams and using the
-fpack-struct switch causes the compiler to flag lots of errors that it
normally wouldn't without the switch. adding -O3 makes the problem worse.

this is a consistent problem.


This problem persists in 5.1.4 version of MinGW (gcc 3.4.5).
Note: this problem persists in gcc 4.32 with djgpp (DOS port of gcc, including,
gcc-3.23, gcc-3.36, gcc-3.44, gcc-4.01, gcc-4.10).
I am using Dell 4600 Windows XP SP3 32-bit on Pentium 4HT (thinks its
dual-core) with 3GB Ram and 4GB Virtual Memory.

C:\prj\test\iostreamdos>type io.cpp
#include 
using namespace std;
int main(void) {
std::cout<<"zippy";
return 0;
}


-using MinGW 5.1.4

C:\prj\test\iostreamdos>g++ -O3 -s -o io.exe io.cpp

C:\prj\test\iostreamdos>g++ -fpack-struct io.cpp
In file included from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/ios:49,
 from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/ostream:45,
 from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/iostream:45,
 from io.cpp:1:
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `std::_Ios_Fmtflags
std::ios_base::setf(std::_Ios_Fmtfla
gs)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:579: error: cannot bind packed field
`((std::ios_base*)this)->std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `std::_Ios_Fmtflags
std::ios_base::setf(std::_Ios_Fmtfla
gs, std::_Ios_Fmtflags)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:596: error: cannot bind packed field
`((std::ios_base*)this)->std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:597: error: cannot bind packed field
`((std::ios_base*)this)->std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `void std::ios_base::unsetf(std::_Ios_Fmtflags)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:608: error: cannot bind packed field
`((std::ios_base*)this)->std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `long int& std::ios_base::iword(int)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:740: error: cannot bind packed field
`__word->std::ios_base::_Words::_M_iwor
d' to `long int&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `void*& std::ios_base::pword(int)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:761: error: cannot bind packed field
`__word->std::ios_base::_Words::_M_pwor
d' to `void*&'

C:\prj\test\iostreamdos>g++ -fpack-struct -O3 io.cpp
In file included from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/ios:49,
 from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/ostream:45,
 from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/iostream:45,
 from io.cpp:1:
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `std::_Ios_Fmtflags
std::ios_base::setf(std::_Ios_Fmtfla
gs)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:579: error: cannot bind packed field
`((std::ios_base*)this)->std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `std::_Ios_Fmtflags
std::ios_base::setf(std::_Ios_Fmtfla
gs, std::_Ios_Fmtflags)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:596: error: cannot bind packed field
`((std::ios_base*)this)->std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:597: error: cannot bind packed field
`((std::ios_base*)this)->std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `void std::ios_base::unsetf(std::_Ios_Fmtflags)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:608: error: cannot bind packed field
`((std::ios_base*)this)->std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `long int& std::ios_base::iword(int)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/

[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse

2009-03-08 Thread jmichae3 at yahoo dot com


--- Comment #1 from jmichae3 at yahoo dot com  2009-03-09 06:32 ---
Created an attachment (id=17420)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17420&action=view)
-fpack-struct -O3 with iostream .ii file

g++ -v -save-temps -fpack-struct -O3 io.cpp
this is the generated io.ii file.


-- 


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



[Bug ada/39138] Fix Copyright Dates Before 4.5.0 Branch (or sooner)

2009-03-08 Thread rob1weld at aol dot com


--- Comment #1 from rob1weld at aol dot com  2009-03-09 06:36 ---
Also in contrib/test_summary :

# (C) 1998, 1999, 2000, 2002 Free Software Foundation


-- 


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



[Bug lto/39279] [lto] - Werror in ../lto_trunk/gcc/lto/lto.c

2009-03-08 Thread rob1weld at aol dot com


--- Comment #1 from rob1weld at aol dot com  2009-03-09 06:40 ---
Fix:

/* munmap ((void *)computed_offset, computed_len); */
  munmap ((caddr_t)computed_offset, computed_len);

Rob


-- 


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



[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse

2009-03-08 Thread jmichae3 at yahoo dot com


--- Comment #2 from jmichae3 at yahoo dot com  2009-03-09 06:41 ---
Created an attachment (id=17421)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17421&action=view)
-fpack-struct with iostream .ii file

g++ -v -save-temps -fpack-struct io.cpp
both attachments ( .ii files) are from gcc 3.4.5. the results are different,
but  the errors are the same regardless of compiler version.
this is a single .ii file attached.


-- 


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



[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse

2009-03-08 Thread jmichae3 at yahoo dot com


--- Comment #3 from jmichae3 at yahoo dot com  2009-03-09 06:45 ---
Created an attachment (id=17422)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17422&action=view)
io.cpp, an offending source file

problem is it #includes  if -fpack-struct is used.  that is all that
is necessary. will have more bad examples later that are simpler which show the
problem.


-- 


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



[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse

2009-03-08 Thread jmichae3 at yahoo dot com


--- Comment #4 from jmichae3 at yahoo dot com  2009-03-09 06:50 ---
Created an attachment (id=17423)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17423&action=view)
source that #includes istream and fails just as miserably with -fpack-struct

C:\prj\test\iostreamdos>g++ -v -save-temps -fpack-struct i.cpp
Reading specs from c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs
Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld
--wi
th-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads
--dis
able-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
--d
isable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt
--with
out-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enabl
e-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw-vista special r3)
 c:/MinGW/bin/../libexec/gcc/mingw32/3.4.5/cc1plus.exe -E -quiet -v -iprefix
c:\
MinGW\bin/../lib/gcc/mingw32/3.4.5/ i.cpp -fpack-struct -o i.ii
ignoring nonexistent directory
"c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../.
./mingw32/include"
ignoring nonexistent directory
"/mingw/lib/gcc/mingw32/3.4.5/../../../../mingw32
/include"
#include "..." search starts here:
#include <...> search starts here:
 c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5
 c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/mingw32
 c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/backward
 c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include
 c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/include
 /mingw/lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5
 /mingw/lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/mingw32
 /mingw/lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/backward
 /mingw/lib/gcc/mingw32/3.4.5/../../../../include
 /mingw/include
 /mingw/lib/gcc/mingw32/3.4.5/include
 /mingw/include
End of search list.
 c:/MinGW/bin/../libexec/gcc/mingw32/3.4.5/cc1plus.exe -fpreprocessed i.ii
-quie
t -dumpbase i.cpp -auxbase i -version -fpack-struct -o i.s
GNU C++ version 3.4.5 (mingw-vista special r3) (mingw32)
compiled by GNU C version 3.4.5 (mingw-vista special r3).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
In file included from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/ios:49,
 from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/istream:45,
 from i.cpp:1:
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `std::_Ios_Fmtflags
std::ios_base::setf(std::_Ios_Fmtfla
gs)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:579: error: cannot bind packed field
`((std::ios_base*)this)->std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `std::_Ios_Fmtflags
std::ios_base::setf(std::_Ios_Fmtfla
gs, std::_Ios_Fmtflags)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:596: error: cannot bind packed field
`((std::ios_base*)this)->std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:597: error: cannot bind packed field
`((std::ios_base*)this)->std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `void std::ios_base::unsetf(std::_Ios_Fmtflags)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:608: error: cannot bind packed field
`((std::ios_base*)this)->std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `long int& std::ios_base::iword(int)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:740: error: cannot bind packed field
`__word->std::ios_base::_Words::_M_iwor
d' to `long int&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `void*& std::ios_base::pword(int)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:761: error: cannot bind packed field
`__word->std::ios_base::_Words::_M_pwor
d' to `void*&'

C:\prj\test\iostreamdos>type i.cpp
#include 
int main(void) {
return 0;
}


-- 


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



[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse

2009-03-08 Thread jmichae3 at yahoo dot com


--- Comment #5 from jmichae3 at yahoo dot com  2009-03-09 06:55 ---
Created an attachment (id=17424)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17424&action=view)
source that #includes fstream which also fails miserably with -fpack-struct

new attachment: source for f.cpp

C:\prj\test\iostreamdos>type f.cpp
#include 
int main(void) {
return 0;
}

C:\prj\test\iostreamdos>g++ -v -save-temps -fpack-struct f.cpp
Reading specs from c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs
Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld
--wi
th-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads
--dis
able-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
--d
isable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt
--with
out-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enabl
e-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw-vista special r3)
 c:/MinGW/bin/../libexec/gcc/mingw32/3.4.5/cc1plus.exe -E -quiet -v -iprefix
c:\
MinGW\bin/../lib/gcc/mingw32/3.4.5/ f.cpp -fpack-struct -o f.ii
ignoring nonexistent directory
"c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../.
./mingw32/include"
ignoring nonexistent directory
"/mingw/lib/gcc/mingw32/3.4.5/../../../../mingw32
/include"
#include "..." search starts here:
#include <...> search starts here:
 c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5
 c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/mingw32
 c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/backward
 c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include
 c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/include
 /mingw/lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5
 /mingw/lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/mingw32
 /mingw/lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/backward
 /mingw/lib/gcc/mingw32/3.4.5/../../../../include
 /mingw/include
 /mingw/lib/gcc/mingw32/3.4.5/include
 /mingw/include
End of search list.
 c:/MinGW/bin/../libexec/gcc/mingw32/3.4.5/cc1plus.exe -fpreprocessed f.ii
-quie
t -dumpbase f.cpp -auxbase f -version -fpack-struct -o f.s
GNU C++ version 3.4.5 (mingw-vista special r3) (mingw32)
compiled by GNU C version 3.4.5 (mingw-vista special r3).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
In file included from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/ios:49,
 from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/istream:45,
 from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/fstream:45,
 from f.cpp:1:
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `std::_Ios_Fmtflags
std::ios_base::setf(std::_Ios_Fmtfla
gs)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:579: error: cannot bind packed field
`((std::ios_base*)this)->std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `std::_Ios_Fmtflags
std::ios_base::setf(std::_Ios_Fmtfla
gs, std::_Ios_Fmtflags)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:596: error: cannot bind packed field
`((std::ios_base*)this)->std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:597: error: cannot bind packed field
`((std::ios_base*)this)->std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `void std::ios_base::unsetf(std::_Ios_Fmtflags)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:608: error: cannot bind packed field
`((std::ios_base*)this)->std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `long int& std::ios_base::iword(int)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:740: error: cannot bind packed field
`__word->std::ios_base::_Words::_M_iwor
d' to `long int&'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `void*& std::ios_base::pword(int)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:761: error: cannot bind packed field
`__word->std::ios_base::_Words::_M_pwor
d' to `void*&'


C:\prj\test\iostreamdos>


-- 


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



[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse

2009-03-08 Thread jmichae3 at yahoo dot com


--- Comment #6 from jmichae3 at yahoo dot com  2009-03-09 06:57 ---
Created an attachment (id=17425)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17425&action=view)
f.ii for fstream problem


-- 


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



[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse

2009-03-08 Thread jmichae3 at yahoo dot com


--- Comment #7 from jmichae3 at yahoo dot com  2009-03-09 06:59 ---
Created an attachment (id=17426)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17426&action=view)
i.ii for istream problem


-- 


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