[Bug regression/39418] New: [4.4 Regression] code mistakenly optimized out when -O2 is enabled

[r0bertz at gentoo dot org]

$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.4.0_pre/work/gcc-4.4.0-/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.0-pre
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-pre/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-pre
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-pre/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-pre/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-pre/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
--disable-multilib --enable-libmudflap --disable-libssp --disable-libgomp
--enable-cld --disable-libgcj --with-arch=i686 --enable-languages=c,c++
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion=
Thread model: posix
gcc version 4.4.0-pre built 20090310 (Gentoo SVN ebuild) rev. 144732 () 

The command to trigger the bug:
gcc prdtoa.i -g -c -O2

The symptom of the bug:
In the output of objdump -S -l prdtoa.o
/tmp/prdtoa.c:1837
#endif
/* rv = */ rounded_product(dval(rv), tens[e]);
goto ret;
#endif
}
  i = DBL_DIG - nd;
These 6 lines of code only generate one instruction
25de:   ba 25 00 00 00  mov$0x25,%edx

If use gcc 4.3.3, the output is like this:
/tmp/prdtoa.c:1833
if (sign) {
rv = -rv;
sign = 0;
}
#endif
/* rv = */ rounded_product(dval(rv), tens[e]);
284e:   8b 5d 90mov-0x70(%ebp),%ebx
2851:   dd 45 d0fldl   -0x30(%ebp)
2854:   dc 0c dd e0 00 00 00fmull  0xe0(,%ebx,8)
285b:   8b 5d 98mov-0x68(%ebp),%ebx
285e:   e9 cd fd ff ff  jmp2630 
2863:   90  nop
2864:   8d 74 26 00 lea0x0(%esi,%eiz,1),%esi

The impact of this bug:
prdtoa.c is from NSPR, NetScape Portable Runtime, which is used by firefox.
This bug will cause font size of certain tags become extremely large because of
the abnormal behavior of function PR_strtod. For example, given "1.5" as a
parameter, PR_strtod will return 15.0. I found this when trying firefox on N32
ABI Loongson system. Since Loongson specific support only avaiable in gcc 4.4.

Will post the prdtoa.i soon.


-- 
   Summary: [4.4 Regression] code mistakenly optimized out when -O2
is enabled
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r0bertz at gentoo 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=39418

[Bug regression/39418] [4.4 Regression] code mistakenly optimized out when -O2 is enabled

[r0bertz at gentoo dot org]

--- Comment #1 from r0bertz at gentoo dot org  2009-03-10 07:16 ---
http://www.gentoo-cn.org/~zhangle/prdtoa.i

my router does not work well with bugzilla.
It seems some data packet of the session can't make their way from server to my
notebook or vice versa. I need to re-login many times unnecessarily.
So I can't attach file here.
My server may not be very stable. If you can't get the file, please let me
know, I will restart the server or the apache service.

Here is the sha1sum:
$ sha1sum prdtoa.i 
44ae99b08409f06dc8f7d7ca30b8ba508f9318b7  prdtoa.i


-- 


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

[Bug c++/39419] New: internal compiler error: Segmentation fault In function �void std::sort_heap'

[schmir at gmail dot com]

[py25] ~/bbot/ % gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --enable-shared
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --enable-threads=posix
--mandir=/usr/share/man --infodir=/usr/share/info --enable-__cxa_atexit
--disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu
--disable-libstdcxx-pch--with-tune=generic
Thread model: posix
gcc version 4.3.3 (GCC)

[py25] ~/bbot/ % g++ _ezindex.ii -c -O2
easyindex/src/_ezindex.cc: In function ‘PyObject*
SortingContainer_new(PyTypeObject*, PyObject*, PyObject*)’:
easyindex/src/_ezindex.cc:163: warning: deprecated conversion from string
constant to ‘char*’
easyindex/src/_ezindex.cc:163: warning: deprecated conversion from string
constant to ‘char*’
easyindex/src/_ezindex.cc:163: warning: deprecated conversion from string
constant to ‘char*’
easyindex/src/_ezindex.cc:163: warning: deprecated conversion from string
constant to ‘char*’
easyindex/src/_ezindex.cc: At global scope:
easyindex/src/_ezindex.cc:810: warning: deprecated conversion from string
constant to ‘char*’
easyindex/src/_ezindex.cc:810: warning: deprecated conversion from string
constant to ‘char*’
easyindex/src/_ezindex.cc: In function ‘void std::sort_heap(_RAIter, _RAIter,
_Compare) [with _RAIter = Ranking**, _Compare = DummyRanker::_RankingLt]’:
easyindex/src/_ezindex.cc:1476: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: internal compiler error: Segmentation fault In function
‘void std::sort_heap'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schmir at gmail dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug regression/39418] [4.4 Regression] code mistakenly optimized out when -O2 is enabled

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-03-10 07:58 ---
nspr is buggy.  See
https://bugzilla.redhat.com/show_bug.cgi?id=487844


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/39419] internal compiler error: Segmentation fault In function �void std::sort_heap'

[schmir at gmail dot com]

--- Comment #1 from schmir at gmail dot com  2009-03-10 07:59 ---
Created an attachment (id=17434)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17434&action=view)
preprocessed source file which triggers segfault


-- 


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

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

[jakub at gcc dot gnu dot org]

--- Comment #15 from jakub at gcc dot gnu dot org  2009-03-10 08:05 ---
You can start with trying if -O2 -fno-inline -fno-inline-small-functions is
still miscompiled and if -O0 works, then you can add
__attribute__((__optimized__([02]))) to suspected functions.


-- 


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

[Bug c++/39419] internal compiler error: Segmentation fault In function �void std::sort_heap'

[schmir at gmail dot com]

--- Comment #2 from schmir at gmail dot com  2009-03-10 08:06 ---
just downgraded to gcc 4.3.2, which compiles this file without problems...


-- 


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

[Bug pch/39420] New: Using pre-compiled headers results in a bus error

[johnw at gnu dot org]

I've tried to reduce this down to a smaller case, but using -save-temps
resulted in a file which does not manifest the problem.  But then, maybe it
shouldn't have.

My project is publically avaliable at http://github.com/jwiegley/ledger. 
Perhaps this is too oblique, but if you pull the project and run "./acprep make
--no-patch --pch", it will generate a Bus Error when compiling as follows
(assuming you have Boost, GMP and MPFR devel libraries installed as well):

libtool: compile:  /opt/local/bin/g++-mp-4.4 -DHAVE_CONFIG_H -I.
-I/Users/johnw/Projects/ledger -I/Users/johnw/Projects/ledger/src
-I/Users/johnw/Projects/ledger/lib
-I/Users/johnw/Projects/ledger/lib/utfcpp/source -isystem /usr/local/include
-isystem /usr/local/include/boost-1_38 -isystem /usr/local/include -isystem
/usr/include/python2.5 -isystem /opt/local/include -isystem
/usr/local/stow/cppunit/include -fpch-deps -Wconversion -ansi -Wall
-Winvalid-pch -Wextra -Wcast-align -Wcast-qual -Wfloat-equal
-Wmissing-field-initializers -Wno-endif-labels -Woverloaded-virtual
-Wsign-compare -Wsign-promo -Wstrict-null-sentinel -Wwrite-strings
-Wno-old-style-cast -Wno-deprecated -g -pipe -MT libledger_report_la-stats.lo
-MD -MP -MF .deps/libledger_report_la-stats.Tpo -c
/Users/johnw/Projects/ledger/src/stats.cc -o libledger_report_la-stats.o
cc1plus: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [libledger_report_la-stats.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

If I run with -H, I see:

. /Users/johnw/Projects/ledger/src/derive.h
.. /Users/johnw/Projects/ledger/src/value.h
... /Users/johnw/Projects/ledger/src/balance.h
 /Users/johnw/Projects/ledger/src/amount.h
. /Users/johnw/Projects/ledger/src/utils.h
.! ./system.hh.gch
 /Users/johnw/Projects/ledger/src/utils.h
. /Users/johnw/Projects/ledger/src/error.h
.. /Users/johnw/Projects/ledger/src/accum.h
 /Users/johnw/Projects/ledger/src/times.h
 /Users/johnw/Projects/ledger/src/flags.h
 (null)
 /Users/johnw/Projects/ledger/src/mask.h
 (null)
 /Users/johnw/Projects/ledger/src/xact.h
. /Users/johnw/Projects/ledger/src/item.h
.. /Users/johnw/Projects/ledger/src/scope.h
... /Users/johnw/Projects/ledger/src/op.h
 /Users/johnw/Projects/ledger/src/expr.h
. /Users/johnw/Projects/ledger/src/predicate.h
.. /Users/johnw/Projects/ledger/src/commodity.h
 /Users/johnw/Projects/ledger/src/post.h
 /Users/johnw/Projects/ledger/src/account.h
 /Users/johnw/Projects/ledger/src/report.h
. /Users/johnw/Projects/ledger/src/interactive.h
. /Users/johnw/Projects/ledger/src/chain.h
. /Users/johnw/Projects/ledger/src/stream.h
. /Users/johnw/Projects/ledger/src/option.h
 /Users/johnw/Projects/ledger/src/session.h
. /Users/johnw/Projects/ledger/src/journal.h
.. /Users/johnw/Projects/ledger/src/hooks.h
 (null)
cc1plus: internal compiler error: Bus error

I'm running on OS X 10.5.6, although I see the same bug on the latest Ubuntu
using g++ 4.3.

My gcc version is: gcc-mp-4.4 (GCC) 4.4.0 20090306 (experimental)

System uname -a: Darwin Hermes 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24
17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386

This bug happens with 4.3.3 on my system as well, but works exactly as expected
with 4.2.1:

i686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5566)


-- 
   Summary: Using pre-compiled headers results in a bus error
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: johnw at gnu dot org


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

[Bug pch/39420] Using pre-compiled headers results in a bus error

[johnw at gnu dot org]

--- Comment #1 from johnw at gnu dot org  2009-03-10 08:42 ---
Created an attachment (id=17435)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17435&action=view)
The file resulting from using -save-temps

This code uses Boost extensively, although I don't know if that has any bearing
on the matter.


-- 


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

[Bug debug/39412] [4.2/4.3/4.4 Regression] ICE in gen_tagged_type_instantiation_die

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-03-10 09:43 ---
What's the point in generating the DIE in gen_tagged_type_instantiation_die?
Seems we are generating that since like forever (that function existed already
when dwarf2out.c was added to the repository in 1996), but as it doesn't
equate_type_number_to_die, unless -fno-eliminate-unused-debug-types it is
always pruned anyway and even if it is not pruned, it is never used by
anything.
If there is an inline function which defines some type, variables of that type
will be typically emitted inside of the abstract DW_TAG_subprogram DIE and vars
elsewhere will just have DW_AT_abstract_origin pointing to those, not defining
the type at all.
Also, gen_tagged_type_instantiation_die types can be emitted many times.
Say:
struct S { int i; };

extern void baz (void *);

inline void
bar (void *x, unsigned long y)
{
  union { struct S a[y]; } *u = x;
  baz (&u);
}

void
foo (void *x, unsigned long y)
{
  bar (x, y);
}

at -fno-eliminate-unused-debug-types -g -O2 -dA has 2:
.uleb128 0x12   # (DIE (0xda) DW_TAG_union_type)
.long   0x6b# DW_AT_abstract_origin
.uleb128 0x12   # (DIE (0xdf) DW_TAG_union_type)
.long   0x6b# DW_AT_abstract_origin
(both unused).  So before teaching gen_tagged_type_instantiation_die to handle
quals (add DW_TAG_const_type or DW_TAG_volatile_type around it), I'd like to
question if gen_tagged_type_instantiation_die shouldn't be nuked instead.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug middle-end/39421] New: Wrong code for optimizition on 64-bit scalar integers

[ktietz at gcc dot gnu dot org]

All of these problems are adisappearing when the code is compiled without the
-O2 flag. 

I have tried to reproduce the problems using simple code fragments, but I have
only succeeded in doing this for 2 of these problems (t1 and t3 in the attached
testcase). I cannot reproduce the other problem (t2 in the following code).
Running the program (with -O2) produced the following: 

$ ~/a.exe 
w is 8000 
, V is 8000 
t1 Wrong! 
v != w 
t2 Correct! 
t3: w = 8000 
t3 Wrong! 

In our actual code corresponding to t2, we do the same comparison of  
if ((uword) w > (uword) MX_S_W)) 

and the comparison fails when w was originally negative.  

For t1 and t3, I can see why some optimisation might reason away the actual
tests, if it does not consider overflow of the signed word. Curiously, removing
the printf before if (w <= 0) ... line in t3 cause the  
if (w <= 0) test to fail -- I don't see why this happens. 

(in our original code, we don't have the printf, but w <= 0 does succeed, it is
the w == MN_S_W test that fails as in t3).


-- 
   Summary: Wrong code for optimizition on 64-bit scalar integers
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ktietz at gcc dot gnu dot org
GCC target triplet: x86_64-*-*


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

[Bug middle-end/39421] Wrong code for optimizition on 64-bit scalar integers

[ktietz at gcc dot gnu dot org]

--- Comment #1 from ktietz at gcc dot gnu dot org  2009-03-10 09:46 ---
Created an attachment (id=17436)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17436&action=view)
testcase C file

Test case for this problem. It can be reproduce AFAI tested on x86_64-pc-linux
and on x86_64-pc-mingw32.


-- 


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

[Bug middle-end/39421] Wrong code for optimizition on 64-bit scalar integers

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-03-10 09:52 ---
This is invalid testcase, relies on signed overflow.  Compile with -fwrapv or
better don't do such broken things.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug debug/39412] [4.2/4.3/4.4 Regression] ICE in gen_tagged_type_instantiation_die

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-03-10 11:01 ---
Sounds reasonable.


-- 


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

[Bug c++/39415] static_cast used as downcast can silently lose const

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-10 11:04 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||accepts-invalid
   Last reconfirmed|-00-00 00:00:00 |2009-03-10 11:04:47
   date||


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

[Bug tree-optimization/39417] [4.2/4.3 Regression] Incorrect values computed with -ftree-copy-prop

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-03-10 11:15 ---
Confirmed.  Workaround with -fno-tree-loop-im.

Maybe just latent on the trunk.

We perform the following:

Executing store motion of init from loop 1
Executing store motion of init from loop 1
Moving statement
init_lsm.127 = init;
(cost 0) out of loop 1.

Moving statement
init_lsm.128 = init;
(cost 0) out of loop 1.

which of course can't work.  Likely the SM rewrite on the trunk fixed this.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|c++ |tree-optimization
 Ever Confirmed|0   |1
   Keywords||wrong-code
  Known to fail||4.0.4 4.1.3 4.2.4 4.3.4
  Known to work||3.4.6 4.4.0
   Last reconfirmed|-00-00 00:00:00 |2009-03-10 11:15:32
   date||
Summary|Incorrect values computed   |[4.2/4.3 Regression]
   |with -ftree-copy-prop   |Incorrect values computed
   ||with -ftree-copy-prop


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

[Bug c++/39419] internal compiler error: Segmentation fault In function �void std::sort_heap'

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-03-10 11:22 ---
It works for me.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Version|unknown |4.3.3


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

[Bug pch/39420] Using pre-compiled headers results in a bus error

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-03-10 11:24 ---
You need to make sure to include the pch only from the toplevel source. 
Otherwise
interesting things may happen.  A convenient way to do so is to include the
pch via the -include command-line option.


-- 


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

[Bug testsuite/39422] New: [4.4 regression] Failing SPU vectorizer testcases

[uweigand at gcc dot gnu dot org]

The following two SPU test cases now fail on mainline (they pass on 4.3):

FAIL: gcc.dg/vect/costmodel/spu/costmodel-vect-76b.c scan-tree-dump-times vect
"vectorized 1 loops" 1
FAIL: gcc.dg/vect/costmodel/spu/costmodel-vect-76c.c scan-tree-dump-times vect
"vectorized 1 loops" 1


-- 
   Summary: [4.4 regression] Failing SPU vectorizer testcases
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
GCC target triplet: spu-elf


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

[Bug target/39423] New: [

[chrbr at gcc dot gnu dot org]

-- 
   Summary: [
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chrbr at gcc dot gnu dot org


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

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

[danglin at gcc dot gnu dot org]

--- Comment #6 from danglin at gcc dot gnu dot org  2009-03-10 13:29 ---
We are back to the previous set of neon fails.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug target/39423] [

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-03-10 13:34 
---
.


-- 

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

[Bug testsuite/39422] [4.4 regression] Failing SPU vectorizer testcases

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/39417] [4.2/4.3 Regression] Incorrect values computed with -ftree-copy-prop

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.4


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

[Bug testsuite/39422] [4.4 regression] Failing SPU vectorizer testcases

[irar at il dot ibm dot com]

--- Comment #1 from irar at il dot ibm dot com  2009-03-10 13:55 ---
I am preparing a patch.


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |irar at il dot ibm dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-10 13:55:31
   date||


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

[Bug middle-end/28779] internal compiler error: in cgraph_estimate_size_after_inlining, at ipa-inline.c:106

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |---


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

[Bug fortran/39314] -ffpe-trap=invalid gives no FPE for acos(-5.0)

[burnus at gcc dot gnu dot org]

--- Comment #10 from burnus at gcc dot gnu dot org  2009-03-10 15:29 ---
> Can someone reproduce this with C code?

Yes: The following gives a SIGFPE with -m32 (logf, sqrtf) and with -m64 and
"sqrtf" but not with -m64 with "logf". (Compile with "-fsignaling-nans" and
"-lm".)

-

#ifndef __SUPPORT_SNAN__
#  error No SNAN support - use "-fsignaling-nans"
#endif
#define _WANT_SNAN 1
#include 
#include 
#include 

int main()
{
  float x = -5.0, y;
  feenableexcept(FE_ALL_EXCEPT);
  y = logf(x);
  printf("%e\n",y);
  return 0;
}


-- 


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

[Bug middle-end/37850] infinite recursive call to __mulsc3 when multiplying not-constant complexs

[froydnj at gcc dot gnu dot org]

--- Comment #9 from froydnj at gcc dot gnu dot org  2009-03-10 15:43 ---
Subject: Bug 37850

Author: froydnj
Date: Tue Mar 10 15:42:51 2009
New Revision: 144751

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144751
Log:
PR middle-end/37850
* libgcc2.c (__mulMODE3): Use explicit assignments to form the
result.
(__divMODE3): Likewise.

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


-- 


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

[Bug middle-end/37850] infinite recursive call to __mulsc3 when multiplying not-constant complexs

[froydnj at gcc dot gnu dot org]

--- Comment #10 from froydnj at gcc dot gnu dot org  2009-03-10 15:49 
---
Fixed on trunk.


-- 

froydnj at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/37850] infinite recursive call to __mulsc3 when multiplying not-constant complexs

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug debug/39412] [4.2/4.3/4.4 Regression] ICE in gen_tagged_type_instantiation_die

[jason at redhat dot com]

--- Comment #5 from jason at redhat dot com  2009-03-10 16:41 ---
Subject: Re:  [4.2/4.3/4.4 Regression] ICE in gen_tagged_type_instantiation_die

jakub at gcc dot gnu dot org wrote:
> What's the point in generating the DIE in gen_tagged_type_instantiation_die?

It seems to be for generating the DIE to represent the type definition 
in a concrete instance of an inline function.  I don't know why it would 
be called multiple times, since it's only called when we process the 
stub TYPE_DECL; calling gen_decl_die multiple times for that seems 
surprising.

But as you say, there doesn't seem to be any point in emitting such a 
DIE at all, since the variables will already have a type in the abstract 
instance.

> I'd like to question if gen_tagged_type_instantiation_die shouldn't be nuked 
> instead.

Go ahead.

Jason


-- 


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

[Bug bootstrap/35855] build locale not properly handled with awk scripts

[urmet dot saar at gmail dot com]

--- Comment #1 from urmet dot saar at gmail dot com  2009-03-10 17:24 
---
I can confirm this, it's been annoying me for some time.
When I changed every "A-Za-z0-9" to [:alnum:] the symbol conflicts went away
and diff confirmed that the generated files were identical to the ones
generated earlier with LC_ALL="C"


-- 

urmet dot saar at gmail dot com changed:

   What|Removed |Added

 CC||urmet dot saar at gmail dot
   ||com


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

[Bug testsuite/39422] [4.4 regression] Failing SPU vectorizer testcases

[irar at gcc dot gnu dot org]

--- Comment #2 from irar at gcc dot gnu dot org  2009-03-10 17:29 ---
Subject: Bug 39422

Author: irar
Date: Tue Mar 10 17:29:21 2009
New Revision: 144754

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144754
Log:
PR tree-optimization/39422
* gcc.dg/vect/costmodel/spu/costmodel-vect-76b.c: Move
constant array with static initialization to global memory.
* gcc.dg/vect/costmodel/spu/costmodel-vect-76c.c: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/costmodel/spu/costmodel-vect-76b.c
trunk/gcc/testsuite/gcc.dg/vect/costmodel/spu/costmodel-vect-76c.c


-- 


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

[Bug c/39170] cannot silence -Wconversion warnings for bit-fields

[tom at atoptech dot com]

--- Comment #4 from tom at atoptech dot com  2009-03-10 17:40 ---
Manuel,

You miss understood what I meant by "old behavior was just fine". I was saying
that the previous behavior of "gcc" worked fine and I was NOT referring
specifically to the "-Wconversion" option. 

The previous version of "gcc" warned when implicit narrowing of doubles to
integral values, such as

double n = 0.05;
int d = n;

when using the "-Wall" option. 

The behavior of "gcc" has changed. Moving all the conversion warnings to fall
under "-Wconversion" may make semantic sense, but it alters the behavior of
"gcc". 

We can fault ourselves for missing this change in the documentation, but there
a level of expectation that the fundamental behavior of the compiler is
consistent from release-to-release. And when fundamental behavior of "gcc"
changes, ample notice should be given. People need to change Makefiles, alter
code (if possible), etc... 

With regard to "-Wtraditional-conversion", it does not work when compiling
"C++" code.

> Do you think this would be an acceptable solution? (I don't know if this works
> now in GCC 4.4)

Absolutely not. It's not a portable solution. There is nothing in the "C++"
standard (that I'm aware of) that suggests that "anding" an integral value with
a "constant" value results in a truncated integral value. It's a bad hack.

As you say, its is unfortunate that "C" and "C++" do not have a bit-field
"cast-operators". But that is the reality. 

There is a lot of code written using "bit-fields". Look at "gcc" itself. Until
the "C" or "C++" language contains a "type-safe" construct, such as a
cast-operator, "gcc" should not issue a warning by default.

If you have ideas on how to solve this, please submit them to the "C" or "C++"
standards group.

The "gcc" 4.3 stream is not safe (for us) to use as is. We need the compiler to
issue warnings when implicit narrowing occurs (expect in the case of a
bit-field). As is, we get thousands of warnings from our code when using
"-Wconversion". Consequently, we are forced disable "-Wconversion" to suppress
the bit-field warnings at the risk of missing other narrowing warnings. And
this is not acceptable to us.

We've already moved back to the 4.2 "gcc".

Best Regards,

Tom Geocaris


-- 


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

[Bug middle-end/39392] internal compiler error: in referenced_var_lookup

[jkolb at wsi dot com]

--- Comment #5 from jkolb at wsi dot com  2009-03-10 17:58 ---
This is now fixed.  Definite duplicate of 39360.


-- 

jkolb at wsi dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/39170] cannot silence -Wconversion warnings for bit-fields

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2009-03-10 19:15 ---
(In reply to comment #4)
> 
> The previous version of "gcc" warned when implicit narrowing of doubles to
> integral values, such as
> 
> double n = 0.05;
> int d = n;
> 
> when using the "-Wall" option.

AFAIK, that is not true. I just tried your very example with gcc 4.2.4 and it
doesn't warn with -Wall -Wextra -Wconversion. g++ did warn but not with -Wall,
you still needed to specify -Wconversion, and it did not warn in many cases. So
please, check your facts.

> The behavior of "gcc" has changed. Moving all the conversion warnings to fall
> under "-Wconversion" may make semantic sense, but it alters the behavior of
> "gcc". 

Fixing bugs alters behaviour. The change of behaviour was documented beyond
what is normally expected.

> We can fault ourselves for missing this change in the documentation, but there
> a level of expectation that the fundamental behavior of the compiler is
> consistent from release-to-release. And when fundamental behavior of "gcc"
> changes, ample notice should be given. People need to change Makefiles, alter
> code (if possible), etc... 

The behaviour of the compiler changes *every* release in many aspects. That is
exactly what http://gcc.gnu.org/gcc-X.X/changes.html is for.

> With regard to "-Wtraditional-conversion", it does not work when compiling
> "C++" code.

Of course it doesn't. Have you understood what -Wtraditional-converion (and the
old -Wconversion) actually warned for?

> Absolutely not. It's not a portable solution. There is nothing in the "C++"
> standard (that I'm aware of) that suggests that "anding" an integral value 
> with
> a "constant" value results in a truncated integral value. It's a bad hack.
> 

Really? Then I have no ideas. In any case, someone else would need to take care
of this because I do not have time. http://gcc.gnu.org/faq.html#support

> If you have ideas on how to solve this, please submit them to the "C" or "C++"
> standards group.

bit-field cast operators?

> We've already moved back to the 4.2 "gcc".

Good that you found a solution. I will leave this open in case someone finds a
better solution and decides to submit a patch.


-- 


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

[Bug pch/39420] Using pre-compiled headers results in a bus error

[johnw at gnu dot org]

--- Comment #3 from johnw at gnu dot org  2009-03-10 19:32 ---
Hmm... I have ensured that the #include chain in every source file results in
the given header appearing first.  That is, whatever a file includes, it will
include utils.h, which includes system.hh.  And so, it works with 4.2 just fine
(I checked using -H, to ensure the includes it actually does process are the
right ones).  So why would it start crashing with 4.3?

Also, -include is not a portable option.  I'll just reorganize my code.  Thanks
for the quick response!!


-- 


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

[Bug c/39170] cannot silence -Wconversion warnings for bit-fields

[tom at atoptech dot com]

--- Comment #6 from tom at atoptech dot com  2009-03-10 20:34 ---
Subject: Re:  cannot silence -Wconversion warnings for
bit-fields


> AFAIK, that is not true. I just tried your very example with gcc 4.2.4 and it
> doesn't warn with -Wall -Wextra -Wconversion. g++ did warn but not with -Wall,
> you still needed to specify -Wconversion, and it did not warn in many cases. 
> So
> please, check your facts.

You are correct in 4.2 you still need the -Wconversion option. We
upgraded from 3.4.6 to 4.2/4.3. In 3.4.6, gcc warned of this error
without any additional options.

> Fixing bugs alters behaviour. The change of behaviour was documented 
> beyond what is normally expected.

You are splitting hairs. I don't see this change as a bug-fix. It's
along the lines to reinterpreting the "C" or "C++" language with regard
to bit-field assignments. The only way "C" or "C++" to assign a integral
variable a bit field is an assignment:

   struct A
   {
  unsigned int v : 2;
   }

   void foo( A * a, int v ) { a->v = v; }

For which "gcc" now issues an warning for, always! And there is no
"language" defined way to eliminate this warning. Outside of writing
something ugly like:

 struct A
 {
union {
   unsigned int v : 2;
   unsigned int fill;
};
  };

  void foo( A * a, int v )
  {
a->fill |= v & 0x3;
  }

And if I have to write this, I might as well not use a bit-field!

Again, gcc 4.3.x now issues thousands of warnings (in our code) for
which we have NO reasonable and portable way to clean the code and NO
way to suppress the warning.

It makes the compiler (for us) not usable.

> Of course it doesn't. Have you understood what -Wtraditional-converion (and 
> the
> old -Wconversion) actually warned for?

I don't care what "-Wconversion" previously did. We never used it, we
did not need to! In 3.4.6 the compiler issued the implicit conversion
warnings without additional options. In 4.2/4.3 you need -Wconversion to
get these warnings. In 4.2.4, "gcc" doesn't warn about bit-fields, but
in 4.3.x it does.

> Really? Then I have no ideas. In any case, someone else would need to 
> take care of this because I do not have time. >
> http://gcc.gnu.org/faq.html#support

I don't understand why this change was made when "C" and the "C++"
language has no support for it... 

Given this has not been been an issue with "C" for over 30 years, there
is probably a reason it is not in the language.


-- 


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

[Bug c++/39424] New: MinGW doesn't seem to work if main disk is not C:\

[JoshV at zoominternet dot net]

On this computer, the main disk is labeled H:\, and GCC won't so much as print
its version. It repeatedly causes crss to throw a No Disk error, which doesn't
accept cancel as an answer. Can't really isolate problem; don't have access to
any other computers without C:\ as main drive, and since it won't even give me
a version number...

Thanks, and best of luck.


-- 
   Summary: MinGW doesn't seem to work if main disk is not C:\
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: JoshV at zoominternet dot net


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

[Bug c++/39425] New: gcc loops after reporting template instantiation errors

[mm at mezzarobba dot net]

On the following example, gcc seems to loop and starts filling the ram after
reporting the errors. Same issue on x86_64-linux-gnu or with older 4.x
versions.

~/tmp$ cat test2.cpp
class a {

  template
struct _rec {
  static const char size = _rec< (s >> 1) >::size;
};

  template<>
  struct _rec <0> {
static const char size = 0;
  };

  static const unsigned int value = _rec < 1 >::size;

}
~/tmp$ g++-4.3 -v -ftemplate-depth-4 test2.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-5'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.3 (Debian 4.3.3-5) 
COLLECT_GCC_OPTIONS='-v' '-ftemplate-depth-4' '-shared-libgcc' '-mtune=generic'
 /usr/lib/gcc/i486-linux-gnu/4.3.3/cc1plus -quiet -v -D_GNU_SOURCE test2.cpp
-quiet -dumpbase test2.cpp -mtune=generic -auxbase test2 -version
-ftemplate-depth-4 -o /tmp/ccZ7Hrtb.s
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.3
 /usr/include/c++/4.3/i486-linux-gnu
 /usr/include/c++/4.3/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.3.3/include
 /usr/lib/gcc/i486-linux-gnu/4.3.3/include-fixed
 /usr/include
End of search list.
GNU C++ (Debian 4.3.3-5) version 4.3.3 (i486-linux-gnu)
compiled by GNU C version 4.3.3, GMP version 4.2.4, MPFR version
2.4.0-p2.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64543
Compiler executable checksum: 6dda33bccb1e3fda2076fc047c4bfa75
test2.cpp:8: error: explicit specialization in non-namespace scope ‘class
a’
test2.cpp:5: error: template instantiation depth exceeds maximum of 4 (use
-ftemplate-depth-NN to increase the maximum) instantiating
‘a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<1u>::size’
test2.cpp:13:   instantiated from here

test2.cpp:5: error: template instantiation depth exceeds maximum of 4 (use
-ftemplate-depth-NN to increase the maximum) instantiating
‘a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<1u>::size’
test2.cpp:13:   instantiated from here

test2.cpp:5: error: template instantiation depth exceeds maximum of 4 (use
-ftemplate-depth-NN to increase the maximum) instantiating
‘a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<1u>::size’
test2.cpp:13:   instantiated from here

test2.cpp:5: error: ‘a::_rec<0u>::size’ cannot be initialized by a
non-constant expression when being declared
test2.cpp:5: error: template instantiation depth exceeds maximum of 4 (use
-ftemplate-depth-NN to increase the maximum) instantiating
‘a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<1u>::size’
test2.cpp:13:   instantiated from here

test2.cpp:5: error: template instantiation depth exceeds maximum of 4 (use
-ftemplate-depth-NN to increase the maximum) instantiating
‘a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<0u>::size’
test2.cpp:5:   instantiated from ‘const char a::_rec<1u>::size’
test2.cpp:13:   instantiated from here

^C
(exit 130)


-- 
   Summary: gcc loops after reporting template instantiation errors
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mm at mezzarobba 

[Bug c++/39426] New: Gcc parser problems on default template arguments

[aran at 100acres dot us]

The gcc incorrectly parses the template arguments for default values in member
functions.  Here is an example:
template
class B
{
};

class A
{
public:
   void foo( B  x = B() )
  {
  }
};


Gcc 4.3.3 emits the following:

9: error: expected ',' or '...' before '>' token
9: error: wrong number of template arguments (1, should be 2)
:2: error: provided for 'template class B'
:9: error: default argument missing for parameter 2 of 'void A::foo(B, int)'


-- 
   Summary: Gcc parser problems on  default template arguments
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aran at 100acres dot us
 GCC build triplet: i386-unknown-netbsdelf5.99.7
  GCC host triplet: i386-unknown-netbsdelf5.99.7
GCC target triplet: i386-unknown-netbsdelf5.99.7


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

[Bug c++/39426] Gcc parser problems on default template arguments

[aran at 100acres dot us]

--- Comment #1 from aran at 100acres dot us  2009-03-10 22:56 ---
A typedef is an effective workaround


-- 


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

[Bug c++/39426] Gcc parser problems on default template arguments

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-03-10 23:01 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument

[pinskia at gcc dot gnu dot org]

--- Comment #42 from pinskia at gcc dot gnu dot org  2009-03-10 23:01 
---
*** Bug 39426 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aran at 100acres dot us


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

[Bug fortran/39427] New: Error on generic name equivalent to type name in same module

[damian at rouson dot net]

The Fortran 2003 standard Section C.1.6 allows a generic procedure to have the
same name as a type , but gfotran gives "Error: DERIVED attribute of 'foo'
conflicts with PROCEDURE attribute at (1)" on the following code:

module foo_module
  type foo
integer :: bar
  end type
  interface foo
procedure constructor
  end interface
contains
  type(foo) function constructor()
constructor%bar = 1
  end function
end module

I use this style throughout a textbook I'm writing because it seems like a
natural way to extend the intrinsic structure constructor syntax.  A more
extensive example of this technique is also in Figure 17.1 of Metcalf, Reid &
Cohen.

Damian


-- 
   Summary: Error on generic name equivalent to type name in same
module
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: damian at rouson dot net
 GCC build triplet: Using built-in specs. Target: i386-apple-darwin8.10.1
Configured
  GCC host triplet: Using built-in specs. Target: i386-apple-darwin8.10.1
Configured
GCC target triplet: Using built-in specs. Target: i386-apple-darwin8.10.1
Configured


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

gcc crash

[Alan Larson]

  When attempting to compile tcc-0.9.22 with gcc 3.4.6, bad things happen:


test108:24% gmake
gcc -O2 -g -Wall -mpreferred-stack-boundary=2 -m386 -malign-functions=0 -o 
tcc_g tcc.c
`-m386' is deprecated. Use `-march=i386' or `-mtune=i386' instead.
tcc.c:1: warning: -malign-functions is obsolete, use -falign-functions
tcc.c: In function `ieee_finite':
tcc.c:934: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
tcc.c: In function `expand_args':
tcc.c:10155: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
tcc.c: In function `parse_args':
tcc.c:10187: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
tcc.c:10258: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
tcc.c:10490:1: mtune=i386: No such file or directory
tcc.c: At top level:
tcc.c:10487: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
gmake: *** [tcc_g] Error 1



  tcc can be easily found with a quick google search.

  The gcc version info, etc:

test108:28% gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.6 [FreeBSD] 20060305
test108:29% pwd
/home/larson/tcc-0.9.22




  I would have entered it on the web site, but I didn't want to bother with
getting YET ANOTHER LOGIN ACCOUNT.


Alan

[Bug driver/39424] MinGW doesn't seem to work if main disk is not C:\

[dannysmith at users dot sourceforge dot net]

--- Comment #1 from dannysmith at users dot sourceforge dot net  2009-03-11 
02:41 ---
This is fixed in  4.3.x by

2006-11-20  Carlos O'Donell  
Mark Mitchell  

* cppdefault.c: Define cpp_PREFIX, cpp_PREFIX_len, and
gcc_exec_prefix.
(cpp_relocated): New function.
* cppdefault.h: Declare cpp_PREFIX, cpp_PREFIX_len, gcc_exec_prefix
and cpp_relocated.
* Makefile.in (PREPROCESSOR_DEFINES): Add -DPREFIX option.
* c-incpath.c (add_standard_paths): Call cpp_relocated. If relocated,
replace configured prefix with gcc_exec_prefix.


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 GCC target triplet||4.3.3
 Resolution||FIXED


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

[Bug debug/39086] [4.4 Regression] ICE in decl_ultimate_origin, at dwarf2out.c:5770 when compiling with -fno-tree-sra

[jason at gcc dot gnu dot org]

--- Comment #17 from jason at gcc dot gnu dot org  2009-03-11 05:01 ---
Subject: Bug 39086

Author: jason
Date: Wed Mar 11 05:01:30 2009
New Revision: 144772

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144772
Log:
PR debug/39086
* tree-nrv.c (tree_nrv): Don't do this optimization if the front
end already did.  Notice GIMPLE_CALL modifications of the result.
Don't copy debug information from an ignored decl or a decl from
another function.

Added:
trunk/gcc/testsuite/g++.dg/opt/nrv15.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-nrv.c


-- 


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

[Bug debug/39086] [4.4 Regression] ICE in decl_ultimate_origin, at dwarf2out.c:5770 when compiling with -fno-tree-sra

[jason at gcc dot gnu dot org]

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


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/39428] New: Stack allocation in the assembly output is more than needed.

[nascent dot mind at gmail dot com]

gcc is allocating more stack space than needed. It seems to be bug similar to
bug 9624.

C test code.


  1 #include 
  2
  3 void function1() {
  4 char a;
  5 }
  6
  7 int main() {
  8 function1();
  9 }


Assembly Output

 1 .file   "test1.c"
  2 .text
  3 .globl function1
  4 .type   function1, @function
  5 function1:
  6 pushl   %ebp
  7 movl%esp, %ebp
  8 subl$16, %esp   <- 16 bytes for a char??
  9 leave
 10 ret
 11 .size   function1, .-function1
 12 .globl main
 13 .type   main, @function
 14 main:
 15 leal4(%esp), %ecx
 16 andl$-16, %esp
 17 pushl   -4(%ecx)
 18 pushl   %ebp
 19 movl%esp, %ebp
 20 pushl   %ecx
 21 callfunction1
 22 popl%ecx
 23 popl%ebp
 24 leal-4(%ecx), %esp
 25 ret
 26 .size   main, .-main
 27 .ident  "GCC: (GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)"
 28 .section.note.GNU-stack,"",@progbits

gcc -v output
-
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)


-- 
   Summary: Stack allocation in the assembly output is more than
needed.
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nascent dot mind at gmail dot com


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