[Bug inline-asm/46573] New: wrong "opcode is not supported on this processor" error message on MIPS 4KSD.

[uzunov at datecs dot bg]

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

   Summary: wrong "opcode is not supported on this processor"
error message on MIPS 4KSD.
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: uzu...@datecs.bg


using inline-assembler the compiler report error that opcode is not supported
on this processor.

I use a processor MAXIM USIP400C with 4KSD core. The processor support 
"SmartMIPS ASE Cryptography Support". In the command line options the
"-march=4ksd" is selected.

When I try to compile the next line:

 asm("mtlhx t0");

the compiler report this error:

 Error: opcode not supported on this processor: mips32r2 (mips32r2) `mtlhx t0'

When I compile this source code using old gcc compiler (3.4.4) the code is
compiled correctly and worked correctly.

-
The used compiler is:
 gcc version 4.4.1 (Sourcery G++ Lite 4.4-226)

[Bug libstdc++/46572] forward_list nodes are not packed

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2010-11-20 
06:02:33 UTC ---
hmm, no, I have no opinion about this except to say a non-normative note
doesn't imply non-portable requirements.

I think the standard doesn't mean "should have absolutely no overhead compared
with the most optimised, non-portable implementation if you use attributes"

this could be left open as an enhancement, but I don't know if anyone would
ever work on it.

[Bug lto/46531] Many benchmarks in SPEC CPU 2006 are miscompiled by LTO

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2010-11-20 03:53:00 
UTC ---
As of revision 166944, with

-O3 -mfpmath=sse -msse2 -funroll-loops -ffast-math  -fwhole-program
-flto=jobserver -fuse-linker-plugin  

SPEC CPU 2K is compiled and run correctly for both
ia32 and x86-64.

For SPEC CPU 2006, with reference input, the only failure is:

  Running 416.gamess ref peak lto default

416.gamess: copy 0 non-zero return code (exit code=0, signal=11)



Contents of cytosine.2.err

STOP IN ABRT




Contents of triazolium.err

STOP IN ABRT



for both ia32 and x86-64.

For test input, the only 2 failures are

  Running 416.gamess test peak lto default


Contents of exam29.err

STOP IN ABRT



*** Miscompare of exam29.out; for details see
   
/export/gnu/import/svn/gcc-test-spec/spec/2006/i686/spec/benchspec/CPU2006/4
16.gamess/run/run_peak_test_lto./exam29.out.mis

  Running 465.tonto test peak lto default

*** Miscompare of stdout; for details see
   
/export/gnu/import/svn/gcc-test-spec/spec/2006/i686/spec/benchspec/CPU2006/4
65.tonto/run/run_peak_test_lto./stdout.mis

for both ia32 and x86-64.  They may be the same bug.

[Bug target/45263] registers used in __do_global_ctors can get clobbered

[orangewarrior at gmail dot com]

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

Lukasz Ligowski  changed:

   What|Removed |Added

 CC||orangewarrior at gmail dot
   ||com

--- Comment #5 from Lukasz Ligowski  2010-11-20 
01:56:34 UTC ---
works for me with ATmega2560 (arduino mega) on Gentoo gcc-4.5.1

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

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

--- Comment #13 from Jorn Wolfgang Rennecke  
2010-11-20 01:31:12 UTC ---
(In reply to comment #12)
> (In reply to comment #11)
> > Does the generated tm.texi still have carriage return characters?
> > Or is there some other difference to the tm.texi in $(srcdir)/doc ?
> 
> When opening tm.texi under Word, I see ¶ character at the end of the lines. It
> must be the carriage return.

I'm not sure - it's been ages since I had to use minicom on DOS for the lack
of a terminal program on Linux (There's been seyon since... ISPs... and ADSL.)

Do you have od installed under cygwin?
You could try
od -x tm.texi|less
to fine out what really is in there.  Or you could use hexdump if you have
that, but not od.

[jo...@laria gcc]$ od -x tm.texi|head -5
000 6340 4320 706f 7279 6769 7468 2820 2943
020 3120 3839 2c38 3931 3938 312c 3939 2c32
040 3931 3339 312c 3939 2c34 3931 3539 312c
060 3939 2c36 3931 3739 312c 3939 2c38 3931
100 3939 322c 3030 2c30 3032 3130 0a2c 6340

Notice the penultimate byte pair in the last line above.  0a is newline.
carriage return would show up as 0d .

Assuming you actually have a carriage return there, I wonder where things
go wrong with the conversion.
On a Linux system, echo will not emit a carriage return by default, but
I can ask it to:

[amyl...@meolyon ~]$ echo -e '\r' |od -x
000 0a0d
002

You should be getting two carriage returns (0d) on cygwin with that command.

And then I can filter out the carriage return with the tr command used in
the makefile:

[amyl...@meolyon ~]$ echo -e '\r' |tr -d '\015'|od -x
000 000a
001

The case statement can also be tested separately:
[amyl...@meolyon ~]$ case `echo X|tr X '\101'` in \
>A) echo ascii;;\
>*) echo ebdic;;\
>  esac
ascii

Could you cut & paste this into a bash shell under cygwin and report the
results?

echo -e '\r' |od -x

echo -e '\r' |tr -d '\015'|od -x

case `echo X|tr X '\101'` in \
   A) echo ascii;;\
   *) echo ebdic;;\
 esac

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

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

--- Comment #12 from Anh Vo  2010-11-20 01:04:59 
UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > case `echo X|tr X '\101'` in \
> >   A) tr -d '\015' < tmp-tm.texi > tmp2-tm.texi ;; \
> >   *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \
> > esac
> > mv tmp2-tm.texi tmp-tm.texi
> > /bin/sh ../../gcc-4.6-20101113/gcc/../move-if-change tmp-tm.texi tm.texi
> > 
> > You should edit ../../gcc-4.6-20101113/gcc/doc/tm.texi.in rather than
> > ../../gcc-
> > 4.6-20101113/gcc/doc/tm.texi .
> Does the generated tm.texi still have carriage return characters?
> Or is there some other difference to the tm.texi in $(srcdir)/doc ?

When opening tm.texi under Word, I see ¶ character at the end of the lines. It
must be the carriage return.

[Bug c++/46527] Member of template class gets wrong debug location when template (but not member) is used before member is defined

[jyasskin at gcc dot gnu.org]

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

Jeffrey Yasskin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.20 00:57:42
 AssignedTo|unassigned at gcc dot   |jyasskin at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Jeffrey Yasskin  2010-11-20 
00:57:42 UTC ---
Created attachment 22465
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22465
Possible fix

Here's a possible patch. I'll add a test and run the test suite and then send
it to gcc-patches. Corrections are welcome in the mean time.

[Bug libstdc++/46572] forward_list nodes are not packed

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jwakely.gcc at gmail dot
   ||com

--- Comment #4 from Paolo Carlini  2010-11-20 
00:47:28 UTC ---
Jon, do you have an opinion about this? I don't think that non-normative note
must be read as requiring packing (with all its pro and cons): I read it just
as saying something about C++ abstraction penalties, not about requiring the
use of a packed attribute, which, has exactly the same meaning in C++ and C
and, from the ISO point of view, does *not* exist in C anyway.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

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

--- Comment #11 from Jorn Wolfgang Rennecke  
2010-11-20 00:16:07 UTC ---
(In reply to comment #10)

> case `echo X|tr X '\101'` in \
>   A) tr -d '\015' < tmp-tm.texi > tmp2-tm.texi ;; \
>   *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \
> esac
> mv tmp2-tm.texi tmp-tm.texi
> /bin/sh ../../gcc-4.6-20101113/gcc/../move-if-change tmp-tm.texi tm.texi
> 
> You should edit ../../gcc-4.6-20101113/gcc/doc/tm.texi.in rather than
> ../../gcc-
> 4.6-20101113/gcc/doc/tm.texi .

Does the generated tm.texi still have carriage return characters?
Or is there some other difference to the tm.texi in $(srcdir)/doc ?

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

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

--- Comment #10 from Anh Vo  2010-11-20 00:05:19 
UTC ---
(In reply to comment #8)
> Created attachment 22400 [details]
> Proposed patch
> Does this patch work for you on Cygwin?
> It doesn't address MacOS 9 Issues, but then, the current Makefile doesn't
> do the right thing for MacOS 9 build systems either - assuming you can
> actually configure GCC 4.6 on such a platform.

I have the results for this question. I hope you do not mind.

No, it did not work on Cygwin nor MinGW with error message below.

...
echo "@set BUGURL @uref{http://gcc.gnu.org/bugs.html}"; >> gcc-vers.texiT; \
mv -f gcc-vers.texiT gcc-vers.texi
if [ xinfo = xinfo ]; then \
makeinfo --split-size=500 --split-size=500
--split-size=
500 --no-split -I . -I ../../gcc-4.6-20101113/gcc/doc \
-I ../../gcc-4.6-20101113/gcc/doc/include -o
doc/cpp.inf
o ../../gcc-4.6-20101113/gcc/doc/cpp.texi; \
fi
if [ xinfo = xinfo ]; then \
makeinfo --split-size=500 --split-size=500
--split-size=
500 --no-split -I . -I ../../gcc-4.6-20101113/gcc/doc \
-I ../../gcc-4.6-20101113/gcc/doc/include -o
doc/gcc.inf
o ../../gcc-4.6-20101113/gcc/doc/gcc.texi; \
fi
make[3]: Circular s-tm-texi <- ../../gcc-4.6-20101113/gcc/doc/tm.texi
dependency
 dropped.
build/genhooks.exe \
../../gcc-4.6-20101113/gcc/doc/tm.texi.in > tmp-tm.texi
case `echo X|tr X '\101'` in \
  A) tr -d '\015' < tmp-tm.texi > tmp2-tm.texi ;; \
  *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \
esac
mv tmp2-tm.texi tmp-tm.texi
/bin/sh ../../gcc-4.6-20101113/gcc/../move-if-change tmp-tm.texi tm.texi

You should edit ../../gcc-4.6-20101113/gcc/doc/tm.texi.in rather than
../../gcc-
4.6-20101113/gcc/doc/tm.texi .
make[3]: *** [s-tm-texi] Error 1
make[3]: Leaving directory `/cygdrive/c/Gcc/Build-4.6.x/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/cygdrive/c/Gcc/Build-4.6.x'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/cygdrive/c/Gcc/Build-4.6.x'
make: *** [all] Error 2

[Bug c++/46526] [4.6 Regression] VTable Problem?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #8 from Jakub Jelinek  2010-11-19 
23:53:46 UTC ---
Fixed.

[Bug tree-optimization/45830] [4.4/4.5 Regression] Code+rodata increase with -ftree-switch-conversion

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.4/4.5/4.6 Regression]|[4.4/4.5 Regression]
   |Code+rodata increase with   |Code+rodata increase with
   |-ftree-switch-conversion|-ftree-switch-conversion

--- Comment #4 from Jakub Jelinek  2010-11-19 
23:53:04 UTC ---
Fixed on the trunk.

[Bug c++/46526] [4.6 Regression] VTable Problem?

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2010-11-19 
23:50:26 UTC ---
Author: jakub
Date: Fri Nov 19 23:50:21 2010
New Revision: 166967

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166967
Log:
PR c++/46526
* semantics.c (cxx_eval_call_expression): Unshare the result.

* g++.dg/cpp0x/constexpr-base3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-base3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/45830] [4.4/4.5/4.6 Regression] Code+rodata increase with -ftree-switch-conversion

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2010-11-19 
23:49:03 UTC ---
Author: jakub
Date: Fri Nov 19 23:48:57 2010
New Revision: 166966

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166966
Log:
PR tree-optimization/45830
* stmt.c (expand_switch_using_bit_tests_p): New function.
(expand_case): Use it.
* tree.h (expand_switch_using_bit_tests_p): New prototype.
* tree-switch-conversion.c (struct switch_conv_info): Add
bit_test_uniq, bit_test_count and bit_test_bb fields.
(check_range): Fix a comment.
(check_process_case): Compute bit_test_uniq and bit_test_count.
(create_temp_arrays): Use XCNEWVEC, merge 3 arrays into one
allocation.
(free_temp_arrays): Use XDELETEVEC, adjust for the 3 arrays merging.
(constructor_contains_same_values_p): Use FOR_EACH_VEC_ELT.
(array_value_type): New function.
(build_one_array): Use it, if it returned different type,
fold_convert all constructor fields and convert back to the
wider type in the generated code.
(process_switch): Initialize bit_test_uniq, bit_test_count and
bit_test_bb fields.  Don't optimize if expand_switch_using_bit_tests_p
returned true.

* gcc.target/i386/pr45830.c: New test.
* gcc.c-torture/execute/pr45830.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr45830.c
trunk/gcc/testsuite/gcc.target/i386/pr45830.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-switch-conversion.c
trunk/gcc/tree.h

[Bug fortran/28105] Check for memory allocations bigger than size_t

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jb at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from Janne Blomqvist  2010-11-19 23:48:39 
UTC ---
Assigning to myself.

[Bug c/46547] [4.5 Regression] internal compiler error when converting a complex to a bool

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  2010-11-19 
23:47:01 UTC ---
Author: jakub
Date: Fri Nov 19 23:46:57 2010
New Revision: 166965

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166965
Log:
PR c/46547
* objc-act.c (in_late_binary_op): Remove.

Modified:
branches/gcc-4_5-branch/gcc/objc/ChangeLog
branches/gcc-4_5-branch/gcc/objc/objc-act.c

[Bug c/46547] [4.5 Regression] internal compiler error when converting a complex to a bool

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  2010-11-19 
23:44:51 UTC ---
Author: jakub
Date: Fri Nov 19 23:44:47 2010
New Revision: 166964

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166964
Log:
PR c/46547
* objc-act.c (in_late_binary_op): Remove.

Modified:
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c

[Bug rtl-optimization/46571] [4.6 Regression] bootsrap comparison failure in fortran/trans-openmp.c

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||build
   Priority|P2  |P1
Summary|bootsrap comparison failure |[4.6 Regression] bootsrap
   |in fortran/trans-openmp.c   |comparison failure in
   ||fortran/trans-openmp.c

[Bug libstdc++/46572] forward_list nodes are not packed

[kyle.kloepper at riverbed dot com]

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

--- Comment #3 from Kyle Kloepper  
2010-11-19 23:01:07 UTC ---
I would read the standard as in inclusive or. But even if you read it as one or
the other, I do not think that in all cases speed would be prefered over space. 

Is there any way to implement something like this:

std::forward_list __attribute((packed));

Such that the packed attribute would propogate to the list nodes?

[Bug libstdc++/46572] forward_list nodes are not packed

[kyle.kloepper at riverbed dot com]

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

--- Comment #2 from Kyle Kloepper  
2010-11-19 22:47:47 UTC ---
Created attachment 22464
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22464
Program to print out the size used by forward_list node allocation

[Bug libstdc++/46572] forward_list nodes are not packed

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2010-11-19 
22:25:32 UTC ---
>zero space or time overhead

We have a zero time overhead here.  packed would increase the time overhead
here really.

[Bug libstdc++/46572] New: forward_list nodes are not packed

[kyle.kloepper at riverbed dot com]

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

   Summary: forward_list nodes are not packed
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kyle.kloep...@riverbed.com


I was playing around with forward_list and realized that all the list nodes
took up a minimum of 16 bytes (with larger sizes in multiples of 8--I am using
a 64-bit machine). This conflicts with what the standard notes in 23.3.3
paragraph 1:

Note: It is intended that forward_list have zero space or time overhead
relative to a hand-written C-style singly linked list.

If I was implementing a memory space critical linked list I would decorate the
list node struct with packed. This is not possible to do with the internal list
node.

I will upload an example program shortly.

[Bug rtl-optimization/46571] bootsrap comparison failure in fortran/trans-openmp.c

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Target||ia64-linux
   Priority|P3  |P2
   Target Milestone|--- |4.6.0

--- Comment #2 from Richard Henderson  2010-11-19 
22:15:40 UTC ---
The first real code generation difference appears during the
173r.cprop3 pass, where the important difference is:

-GLOBAL COPY-PROP: Replacing reg 424 in insn 90 with reg 427

the replacement does not happen with -g.  Now to figure out why...

[Bug rtl-optimization/46571] bootsrap comparison failure in fortran/trans-openmp.c

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.19 22:11:13
 AssignedTo|unassigned at gcc dot   |rth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Richard Henderson  2010-11-19 
22:11:13 UTC ---
Created attachment 22463
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22463
Minimized test case

[Bug rtl-optimization/46571] New: bootsrap comparison failure in fortran/trans-openmp.c

[rth at gcc dot gnu.org]

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

   Summary: bootsrap comparison failure in fortran/trans-openmp.c
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


Stage2/3 differ on this file on ia64-linux.  This is a real
code generation difference observable with/without -g.

Command line:
  ./xgcc -B./ -O2 -g z.i

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[dominiq at lps dot ens.fr]

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

--- Comment #25 from Dominique d'Humieres  
2010-11-19 21:46:56 UTC ---
> Well, in theory, I believe it should work with Paul's patch.
> Of course, theory and experience are two different beast. :)

When Paul will have commit his final patch, it will be time to open a PR if the
agreement is that this should work and if it does not;-)

[Bug c++/46564] [4.6 Regression] ICE: in decl_constant_var_p, at cp/decl2.c:3562 on invalid recursive initialization

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.19 21:36:45
 CC||jason at redhat dot com
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-11-19 21:36:45 
UTC ---
It is caused by revision 166164:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00050.html

[Bug c++/46568] special symbol "a caret" shows up for errors and warnings when running g++

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andrew Pinski  2010-11-19 
21:32:49 UTC ---
This is a bug in how you have LANG and LC_* env variables set up.  They
currently say your terminal supports UTF-8 but obviously it does not.  Just set
LANG to C and that will fix your issue.

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #24 from Steve Kargl  
2010-11-19 21:32:38 UTC ---
On Fri, Nov 19, 2010 at 09:04:42PM +, dominiq at lps dot ens.fr wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339
> 
> --- Comment #22 from Dominique d'Humieres  
> 2010-11-19 21:04:22 UTC ---
> > > Is there something invalid here?
> >
> > Yes.  You need to allocate ptr unless you have
> > pault's [re-]allocate on assignment patch.
> 
> Even with Paul's patch it does not work.
> 

Well, in theory, I believe it should work with Paul's patch.
Of course, theory and experience are two different beast. :)

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[david.sagan at gmail dot com]

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

--- Comment #23 from david.sagan at gmail dot com 2010-11-19 21:24:01 UTC ---
(In reply to comment #22)
> > > Is there something invalid here?
> >
> > Yes.  You need to allocate ptr unless you have
> > pault's [re-]allocate on assignment patch.
> 
> Even with Paul's patch it does not work.

It works for me. The following two variants give the correct result (and this
is without any patching):

program main
 use test
 implicit none
 type(a), target :: myA
 integer, dimension(:), pointer :: ptr
 myA%i(1:4)%j = (/ 1, 2, 3, 4 /)
 myA%i(1:4)%c = (/ 'a', 'b', 'c', 'd' /)
 allocate (ptr(4))
 ptr =  myA%i%j
 print *, "   ptr =", ptr
 print *, "   myA%i%j =", myA%i%j
end program main

program main
 use test
 implicit none
 type(a), target :: myA
 integer, dimension(:), pointer :: ptr
 myA%i(1:4)%j = (/ 1, 2, 3, 4 /)
 myA%i(1:4)%c = (/ 'a', 'b', 'c', 'd' /)
 ptr => myA%i%j
 print *, "   ptr =", ptr
 print *, "   myA%i%j =", myA%i%j
end program main


Both give:
ptr =   1   2   3   4
myA%i%j =   1   2   3   4

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[dominiq at lps dot ens.fr]

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

--- Comment #22 from Dominique d'Humieres  
2010-11-19 21:04:22 UTC ---
> > Is there something invalid here?
>
> Yes.  You need to allocate ptr unless you have
> pault's [re-]allocate on assignment patch.

Even with Paul's patch it does not work.

[Bug tree-optimization/46077] [4.6 regression] ICE in tree vectorization when compiling towns_audio.cpp from scummvm

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||matz at gcc dot gnu.org
 Resolution||FIXED

--- Comment #7 from Michael Matz  2010-11-19 21:03:34 
UTC ---
Fixed.

[Bug c/46547] [4.5 Regression] internal compiler error when converting a complex to a bool

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  
2010-11-19 21:01:04 UTC ---
Revision 166951 breaks bootstrap with obj-c++ enabled:

ld: duplicate symbol _in_late_binary_op in c-family/c-common.o and
objcp/objcp-act.o

[Bug tree-optimization/46077] [4.6 regression] ICE in tree vectorization when compiling towns_audio.cpp from scummvm

[matz at gcc dot gnu.org]

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

--- Comment #6 from Michael Matz  2010-11-19 20:56:33 
UTC ---
Author: matz
Date: Fri Nov 19 20:56:27 2010
New Revision: 166958

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166958
Log:
PR tree-optimization/46077
* tree-chrec.c (eq_evolutions_p): Accept some expressions.

testsuite/
PR tree-optimization/46077
* gcc.dg/vect/O3-pr46077.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/O3-pr46077.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chrec.c

[Bug c/46547] [4.5 Regression] internal compiler error when converting a complex to a bool

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.5.2
 Resolution||FIXED

--- Comment #12 from Joseph S. Myers  2010-11-19 
20:54:28 UTC ---
Fixed for 4.5.2 and 4.6.

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #21 from kargl at gcc dot gnu.org 2010-11-19 20:49:31 UTC ---
(In reply to comment #19)

> Is there something invalid here?

Yes.  You need to allocate ptr unless you have
pault's [re-]allocate on assignment patch.

> module test
>   implicit none
>   type b
> integer :: j
> character :: c
>   end type b
>   type a
> type(b), dimension(4) :: i
>   end type a
> end module test
> 
> program main
>   use test
>   implicit none
>   type(a), target :: myA
>   integer, dimension(:), pointer :: ptr
>   myA%i(1:4)%j = (/ 1, 2, 3, 4 /)
>   myA%i(1:4)%c = (/ 'a', 'b', 'c', 'd' /)

allocate(ptr(size(myA%i)))

>   ptr = myA%i%j
>   print *, "   ptr =", ptr
>   print *, "   myA%i%j =", myA%i%j
> end program main

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[david.sagan at gmail dot com]

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

--- Comment #20 from david.sagan at gmail dot com 2010-11-19 20:46:36 UTC ---
(In reply to comment #19)

> Is there something invalid here?
>   ptr = myA%i%j

Yes this is not correct. This line should be:
  ptr => myA%i%j

If you use "gfortran -fcheck=all test.f90" then what you get when you run the
program is:

At line 19 of file test.f90
Fortran runtime error: Array bound mismatch for dimension 1 of array 'ptr'
(140736642904848/4)

[Bug c/46547] [4.5 Regression] internal compiler error when converting a complex to a bool

[jsm28 at gcc dot gnu.org]

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

--- Comment #11 from Joseph S. Myers  2010-11-19 
20:45:07 UTC ---
Author: jsm28
Date: Fri Nov 19 20:45:00 2010
New Revision: 166957

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166957
Log:
PR c/46547
* c-common.c (in_late_binary_op): Define.
(c_common_truthvalue_conversion): Check in_late_binary_op before
calling c_save_expr.
* c-common.h (in_late_binary_op): Declare.
* c-tree.h (in_late_binary_op): Move to c-common.h.
* c-typeck.c (in_late_binary_op): Move to c-common.c.

testsuite:
* gcc.c-torture/compile/pr46547-1.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr46547-1.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/c-common.c
branches/gcc-4_5-branch/gcc/c-common.h
branches/gcc-4_5-branch/gcc/c-tree.h
branches/gcc-4_5-branch/gcc/c-typeck.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug c++/46568] New: special symbol "a caret" shows up for errors and warnings when running g++

[jared.rubin at saic dot com]

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

   Summary: special symbol "a caret" shows up for errors and
warnings when running g++
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jared.ru...@saic.com


Created attachment 22462
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22462
look at the highlighted section

If my c++ code has any errors or warnings, the special symbol "a caret" shows
up instead of the 
function name or symbol that is the problem.
I built gcc 4.4.3 on RedHat linux 5.5 instead of using the default gcc compiler
that comes with the o/s
thanks

[Bug debug/46561] [4.6 Regression] -fcompare-debug failure (length) with -O2 -ftree-vectorize -ftree-parallelize-loops

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2010-11-19 
20:19:44 UTC ---
Created attachment 22461
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22461
gcc46-pr46561.patch

Untested fix.

[Bug tree-optimization/46561] [4.6 Regression] -fcompare-debug failure (length) with -O2 -ftree-vectorize -ftree-parallelize-loops

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  2010-11-19 
20:04:14 UTC ---
Mine.

[Bug c++/46565] [4.5/4.6 Regression] ICE: SIGSEGV in pop_tinst_level (pt.c:7513) with -gstabs -g on invalid code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||error-recovery
   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.5.2

[Bug c++/46564] [4.6 Regression] ICE: in decl_constant_var_p, at cp/decl2.c:3562 on invalid recursive initialization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||error-recovery
   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.6.0

[Bug target/46436] m68hc11-elf --enable-werror-always build fails

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Jorn Wolfgang Rennecke  
2010-11-19 19:26:11 UTC ---
Patch has been applied to trunk.

[Bug target/46434] crx-elf --enable-werror-always build fails

[amylaar at gcc dot gnu.org]

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

--- Comment #2 from Jorn Wolfgang Rennecke  
2010-11-19 19:22:31 UTC ---
Author: amylaar
Date: Fri Nov 19 19:22:27 2010
New Revision: 166954

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166954
Log:
PR target/46434
* config/crx/crx.c (crx_expand_epilogue): Remove unused variable.
Index: config/crx/crx.c
===
--- config/crx/crx.c(revision 166609)
+++ config/crx/crx.c(working copy)
@@ -613,6 +613,8 @@ static int crx_addr_reg_p (rtx addr_reg)
   return FALSE;
 }

+  gcc_assert (REGNO (reg) != CC_REGNUM);
+
   return TRUE;
 }

@@ -1439,17 +1441,12 @@ crx_expand_prologue (void)
 void
 crx_expand_epilogue (void)
 {
-  rtx return_reg;
-
   /* Nonzero if we need to return and pop only RA. This will generate a
* different insn. This differentiate is for the peepholes for call as last
* statement in function. */
   int only_popret_RA = (save_regs[RETURN_ADDRESS_REGNUM]
 && (sum_regs == UNITS_PER_WORD));

-  /* Return register.  */
-  return_reg = gen_rtx_REG (Pmode, RETURN_ADDRESS_REGNUM);
-
   if (frame_pointer_needed)
 /* Restore the stack pointer with the frame pointers value */
 emit_move_insn (stack_pointer_rtx, frame_pointer_rtx);

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

[Bug target/46436] m68hc11-elf --enable-werror-always build fails

[amylaar at gcc dot gnu.org]

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

--- Comment #2 from Jorn Wolfgang Rennecke  
2010-11-19 18:40:31 UTC ---
Author: amylaar
Date: Fri Nov 19 18:40:24 2010
New Revision: 166952

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166952
Log:
PR target/46436
* config/m68hc11/m68hc11.c (m68hc11_gen_highpart): Split shift count
to accomodate 32 bit HOST_WIDE_INT.
(m68hc11_emit_logical): Remove unused variable insn.
(m68hc11_check_z_replacement) : Set this_insn_uses_ix and
this_insn_uses_iy before use.

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

[Bug c/46547] [4.5/4.6 Regression] internal compiler error when converting a complex to a bool

[jsm28 at gcc dot gnu.org]

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

--- Comment #10 from Joseph S. Myers  2010-11-19 
18:33:02 UTC ---
Author: jsm28
Date: Fri Nov 19 18:32:57 2010
New Revision: 166951

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166951
Log:
PR c/46547
* c-tree.h (in_late_binary_op): Move to c-family/c-common.h.
* c-typeck.c (in_late_binary_op): Move to c-family/c-common.c.

c-family:
* c-common.c (in_late_binary_op): Define.
(c_common_truthvalue_conversion): Check in_late_binary_op before
calling c_save_expr.
* c-common.h (in_late_binary_op): Declare.

testsuite:
* gcc.c-torture/compile/pr46547-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr46547-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c-tree.h
trunk/gcc/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/45940] [trans-mem] Error of unsafe function even if annotated

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.19 18:17:31
 AssignedTo|unassigned at gcc dot   |aldyh at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Aldy Hernandez  2010-11-19 
18:17:31 UTC ---
Mine

[Bug other/46567] ipa_tm_decrement_clone_counts ICE at -O2

[aldyh at gcc dot gnu.org]

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

--- Comment #2 from Aldy Hernandez  2010-11-19 
18:14:07 UTC ---
*** Bug 46566 has been marked as a duplicate of this bug. ***

[Bug other/46566] New: ipa_tm_decrement_clone_counts ICE at -O2

[aldyh at gcc dot gnu.org]

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

   Summary: ipa_tm_decrement_clone_counts ICE at -O2
   Product: gcc
   Version: trans-mem
Status: RESOLVED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: al...@gcc.gnu.org


Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

$  ./cc1plus c.cc -O -fgnu-tm -fdump-tree-all -fdump-ipa-all -quiet -O2
c.cc: In function 'void* buildProjectSyncStepConcurrently(int, int)':
c.cc:2674:1: internal compiler error: in ipa_tm_decrement_clone_counts, at
trans-mem.c:3687
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

--- Comment #1 from Aldy Hernandez  2010-11-19 
18:14:07 UTC ---
whoops, hit send twice

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

[Bug other/46567] ipa_tm_decrement_clone_counts ICE at -O2

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

   Keywords||trans-mem
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.19 18:11:58
 Ever Confirmed|0   |1

[Bug other/46567] ipa_tm_decrement_clone_counts ICE at -O2

[aldyh at gcc dot gnu.org]

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

--- Comment #1 from Aldy Hernandez  2010-11-19 
18:11:23 UTC ---
Created attachment 22460
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22460
boom

[Bug other/46567] New: ipa_tm_decrement_clone_counts ICE at -O2

[aldyh at gcc dot gnu.org]

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

   Summary: ipa_tm_decrement_clone_counts ICE at -O2
   Product: gcc
   Version: trans-mem
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: al...@gcc.gnu.org


$  ./cc1plus c.cc -O -fgnu-tm -fdump-tree-all -fdump-ipa-all -quiet -O2
c.cc: In function 'void* buildProjectSyncStepConcurrently(int, int)':
c.cc:2674:1: internal compiler error: in ipa_tm_decrement_clone_counts, at
trans-mem.c:3687
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug other/46026] [trans-mem] Unable to build libitm on Solaris/x86

[aldyh at gcc dot gnu.org]

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

--- Comment #2 from Aldy Hernandez  2010-11-19 
18:06:01 UTC ---
BTW, a workaround while Alex gets his patch committed is to run make again on
the partially built tree.  The second time around, the build will succeed.

[Bug c++/46270] [trans-mem] internal compiler error: verify_stmts failed

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #1 from Aldy Hernandez  2010-11-19 
18:02:29 UTC ---
Fixed
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02025.html

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[jvdelisle at gcc dot gnu.org]

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

--- Comment #19 from Jerry DeLisle  2010-11-19 
17:42:12 UTC ---
Another test case to think about. Ifort compiles but gives:

ptr =
myA%i%j =   1   2   3   4

gfortran compiles and gives:

$ ./a.out 
Segmentation fault (core dumped)

$ gfc -fbounds-check test3.f90
$ ./a.out 
At line 19 of file test3.f90
Fortran runtime error: Array bound mismatch for dimension 1 of array 'ptr'
(140251380424698/4)

Is there something invalid here?

module test
  implicit none
  type b
integer :: j
character :: c
  end type b
  type a
type(b), dimension(4) :: i
  end type a
end module test

program main
  use test
  implicit none
  type(a), target :: myA
  integer, dimension(:), pointer :: ptr
  myA%i(1:4)%j = (/ 1, 2, 3, 4 /)
  myA%i(1:4)%c = (/ 'a', 'b', 'c', 'd' /)
  ptr = myA%i%j
  print *, "   ptr =", ptr
  print *, "   myA%i%j =", myA%i%j
end program main

[Bug driver/46563] link with -lgcc when creating a shared lib

[mikpe at it dot uu.se]

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

--- Comment #7 from Mikael Pettersson  2010-11-19 
17:38:35 UTC ---
The example works for me also with a cross built from gcc-4.5.1 with
--enable-shared --enable-languages=c,c++.

> armv5tel-unknown-linux-gnueabi-g++ atomic.cxx -fPIC -shared -o libatomic.so
> armv5tel-unknown-linux-gnueabi-g++ atomain.cxx -o atomain -L. -latomic

'make install' automatically installed the linker script in
$PREFIX/armv5tel-unknown-linux-gnueabi/lib/libgcc_s.so

I don't see "-gnueabi" in your compile command. Is it an OABI toolchain?

[Bug driver/46563] link with -lgcc when creating a shared lib

[aph at gcc dot gnu.org]

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

--- Comment #6 from Andrew Haley  2010-11-19 17:30:35 
UTC ---
I am cross-compiling too.

Try this:

 $ cat /home/aph/x-arm/install/arm-linux-gnueabi/lib/libgcc_s.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library.  */
GROUP ( libgcc_s.so.1 libgcc.a )

[Bug c/46547] [4.5/4.6 Regression] internal compiler error when converting a complex to a bool

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jsm28 at gcc dot gnu.org
   |gnu.org |

--- Comment #9 from Joseph S. Myers  2010-11-19 
17:20:15 UTC ---
Testing a patch.

[Bug driver/46563] link with -lgcc when creating a shared lib

[christophe.lyon at st dot com]

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

--- Comment #5 from christophe.lyon at st dot com 2010-11-19 16:49:05 UTC ---
I am not sure what you mean about "libgcc_s.so linker script".

But I think the difference is that I am cross-compiling.

[Bug driver/46563] link with -lgcc when creating a shared lib

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #4 from Mikael Pettersson  2010-11-19 
16:45:51 UTC ---
(In reply to comment #0)
> Created attachment 22457 [details]
> main prog C++ source
> 
> As discussed in http://gcc.gnu.org/ml/gcc-help/2010-11/msg00198.html, the G++
> driver does not link with -lgcc when creating a shared lib.

The example in the link above works for me with my native arm-linux-gnueabi
toolchain.

Did you forget to install the libgcc_s.so linker script?  The very purpose of
that script is to make -lgcc_s suck in both the dynamic and the static libgcc,
since (as you've noticed) some symbols are only defined in the static libgcc.

[Bug c++/46565] [4.5/4.6 Regression] ICE: SIGSEGV in pop_tinst_level (pt.c:7513) with -gstabs -g on invalid code

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
  Known to work||4.4.6
  Known to fail||4.5.2, 4.6.0
   Severity|normal  |minor

[Bug c++/46565] New: [4.5/4.6 Regression] ICE: SIGSEGV in pop_tinst_level (pt.c:7513) with -gstabs -g on invalid code

[zsojka at seznam dot cz]

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

   Summary: [4.5/4.6 Regression] ICE: SIGSEGV in pop_tinst_level
(pt.c:7513) with -gstabs -g on invalid code
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


--- testcase.C 
template < int N > struct X {
  static const int value = X < N - 1 >::value;
};
template struct X <1000>;
---
(g++.dg/template/recurse2.C)

Compiler output:
$ gcc -gstabs -g testcase.C
testcase.C:1:27: error: template instantiation depth exceeds maximum of 1024
(use -ftemplate-depth= to increase the maximum) instantiating
'X<-0x00017>::value'
testcase.C:2:41:   recursively instantiated from 'const int X<999>::value'
testcase.C:2:41:   instantiated from 'const int X<1000>::value'
testcase.C:4:17:   instantiated from here

testcase.C:2:41: error: template instantiation depth exceeds maximum of 1024
(use -ftemplate-depth= to increase the maximum) instantiating 'struct
X<-0x00019>'
testcase.C:2:41:   recursively instantiated from 'const int X<999>::value'
testcase.C:2:41:   instantiated from 'const int X<1000>::value'
testcase.C:4:17:   instantiated from here

testcase.C:2:41: error: incomplete type 'X<-0x00019>' used in
nested name specifier
==3448== Invalid read of size 4
==3448==at 0x518875: pop_tinst_level (pt.c:7513)
==3448==by 0x54EAF2: instantiate_decl (pt.c:17402)
==3448==by 0x550681: do_type_instantiation (pt.c:16682)
==3448==by 0x5BAB68: cp_parser_explicit_instantiation (parser.c:12269)
==3448==by 0x5BDD89: cp_parser_declaration (parser.c:9415)
==3448==by 0x5BC569: cp_parser_declaration_seq_opt (parser.c:9328)
==3448==by 0x5BE234: c_parse_file (parser.c:3445)
==3448==by 0x6922F4: c_common_parse_file (c-opts.c:1070)
==3448==by 0x9F7423: toplev_main (toplev.c:870)
==3448==by 0x6376BBC: (below main) (in /lib64/libc-2.11.2.so)
==3448==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
==3448== 
testcase.C:4:17: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Tested revisions:
r166936 - crash
4.5 r166509 - crash
4.4 r166509 - OK

[Bug tree-optimization/45830] [4.4/4.5/4.6 Regression] Code+rodata increase with -ftree-switch-conversion

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  2010-11-19 
16:17:06 UTC ---
Created attachment 22459
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22459
gcc46-pr45830.patch

Untested fix that should cure both reported issues, i.e. don't optimize and let
switch being expanded as bit test if beneficial, and use smaller integral types
when possible for the CSWTCH arrays.

[Bug driver/46563] link with -lgcc when creating a shared lib

[christophe.lyon at st dot com]

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

--- Comment #3 from christophe.lyon at st dot com 2010-11-19 16:12:11 UTC ---
Yes. I did find this workaround myself, but I was very surprised I had to do it
manually.

(As I said, the problem arised when building QT, and I guess I'm not the first
one to build QT for ARM, so probably every other person have applied that
workaround in the QT sources without contributing back ;-)

[Bug c++/46564] New: [4.6 Regression] ICE: in decl_constant_var_p, at cp/decl2.c:3562 on invalid recursive initialization

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: in decl_constant_var_p, at
cp/decl2.c:3562 on invalid recursive initialization
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


--- testcase.C 
template < int N > struct X {
  static const int value = X::value;
};
template struct X<1000>;
---

Compiler output:
$ gcc testcase.C
testcase.C:2:34: error: template instantiation depth exceeds maximum of 1024
(use -ftemplate-depth= to increase the maximum) instantiating 'X<1000>::value'
testcase.C:2:34:   recursively instantiated from 'const int X<1000>::value'
testcase.C:2:34:   instantiated from 'const int X<1000>::value'
testcase.C:4:17:   instantiated from here

testcase.C:2:34: error: template instantiation depth exceeds maximum of 1024
(use -ftemplate-depth= to increase the maximum) instantiating 'X<1000>::value'
testcase.C:2:34:   recursively instantiated from 'const int X<1000>::value'
testcase.C:2:34:   instantiated from 'const int X<1000>::value'
testcase.C:4:17:   instantiated from here

testcase.C:2:34: internal compiler error: in decl_constant_var_p, at
cp/decl2.c:3562
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r166936 - crash
r165699 - OK
4.5 r166509 - OK

[Bug driver/46563] link with -lgcc when creating a shared lib

[aph at gcc dot gnu.org]

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

--- Comment #2 from Andrew Haley  2010-11-19 16:09:00 
UTC ---
If you try linking with "-lgcc_s -lgcc", does everything then work?

[Bug driver/46563] link with -lgcc when creating a shared lib

[christophe.lyon at st dot com]

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

--- Comment #1 from christophe.lyon at st dot com 2010-11-19 16:05:16 UTC ---
Created attachment 22458
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22458
shared lib C++ source

[Bug driver/46563] New: link with -lgcc when creating a shared lib

[christophe.lyon at st dot com]

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

   Summary: link with -lgcc when creating a shared lib
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: christophe.l...@st.com


Created attachment 22457
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22457
main prog C++ source

As discussed in http://gcc.gnu.org/ml/gcc-help/2010-11/msg00198.html, the G++
driver does not link with -lgcc when creating a shared lib.

This is a problem when the shared lib references some symbols which are only
present in libgcc.a (such as __sync_fetch_and_add and all __sync*). This is the
case for instance on ARM.

I have attached atomic.cxx (shared lib) and atomain.cxx (main prog) to be
compiled with:
$ arm-linux-g++ atomic.cxx -fPIC -shared -o libatomic.so
$ arm-linux-g++ atomain.cxx -o atomain -L. -latomic
.../ld: atomain: hidden symbol `__sync_fetch_and_add_4' in
/.../libgcc.a(linux-atomic.o) is referenced by DSO

As a fix I can suggest to patch gcc.c:init_gcc_specs() and to add static_name
next to shared_name when expanding the specs.
diff -up gcc.c gcc.c.patch
--- gcc.c   2010-02-25 17:20:51.83115 +0100
+++ gcc.c.patch 2010-11-19 17:02:37.141674000 +0100
@@ -1722,7 +1722,7 @@ init_gcc_specs (struct obstack *obstack,
static_name, " --as-needed ", shared_name, " --no-as-needed"
"}"
"%{shared-libgcc:",
-   shared_name, "%{!shared: ", static_name, "}"
+   shared_name, " ", static_name, "%{!shared: ", static_name, "}"
"}"
 #else
"%{!shared:"
@@ -1731,11 +1731,11 @@ init_gcc_specs (struct obstack *obstack,
"}"
 #ifdef LINK_EH_SPEC
"%{shared:"
-   "%{shared-libgcc:", shared_name, "}"
+   "%{shared-libgcc:", shared_name, " ", static_name"}"
"%{!shared-libgcc:", static_name, "}"
"}"
 #else
-   "%{shared:", shared_name, "}"
+   "%{shared:", shared_name, " ", static_name"}"
 #endif
 #endif
"}}", NULL);

gcc-bugs@gcc.gnu.org

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2010-11-19 
15:57:32 UTC ---
SCCVN also fails to recognize &a[i_1] as constant.

I'll add a get_addr_base_and_unit_offset variant with a callback to valueize
SSA names.  That should cover both.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[rwild at gcc dot gnu.org]

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

Ralf Wildenhues  changed:

   What|Removed |Added

 CC||anhvofrcaus at gmail dot
   ||com

--- Comment #9 from Ralf Wildenhues  2010-11-19 
15:50:33 UTC ---
*** Bug 46549 has been marked as a duplicate of this bug. ***

[Bug bootstrap/46549] MinGW bootstrap failure regarding texi GFPL license

[rwild at gcc dot gnu.org]

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

Ralf Wildenhues  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||rwild at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #1 from Ralf Wildenhues  2010-11-19 
15:50:33 UTC ---
.

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

gcc-bugs@gcc.gnu.org

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.19 15:45:11
 Ever Confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Richard Guenther  2010-11-19 
15:45:11 UTC ---
Mine.

gcc-bugs@gcc.gnu.org

[rguenth at gcc dot gnu.org]

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

   Summary: CCP currently needs iteration for &a[i]
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: rgue...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


static int a[4];
int foo(void)
{
  int i = 1;
  int *p = &a[i];
  return *p;
}

compiled with the C++ FE (to yield an ARRAY_REF) shows that CCP needs
to iterate to figure out that p is a constant (and thus fold the read
from a[1]).

[Bug tree-optimization/46557] [4.6 Regression] ICE in cgraph_will_be_removed_from_program_if_no_direct_calls, at cgraph.c:2820

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.19 15:30:39
 CC||jason at redhat dot com
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-11-19 15:30:39 
UTC ---
This is caused by revision 166167:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00053.html

[Bug tree-optimization/46561] [4.6 Regression] -fcompare-debug failure (length) with -O2 -ftree-vectorize -ftree-parallelize-loops

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||irar at il dot ibm.com
   Target Milestone|--- |4.6.0

--- Comment #2 from H.J. Lu  2010-11-19 14:59:05 
UTC ---
It is caused by revision 161797:

http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00151.html

[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10

[howarth at nitro dot med.uc.edu]

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

--- Comment #16 from Jack Howarth  2010-11-19 
13:48:45 UTC ---
I can confirm that removing the gcc_assert (!DECL_EXTERNAL (decl)) as suggested
in comment 8 does eliminate the bootstrap failures without regressions on
x86_64-apple-darwin10...

http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg01621.html

[Bug testsuite/43925] Plugin tests unresolved on IRIX 6.5: libintl.h: No such file or directory

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|mips-sgi-irix6.5|mips-sgi-irix6.5,
   ||mips-sgi-irix5.3
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.19 13:40:20
   Host|mips-sgi-irix6.5|mips-sgi-irix6.5,
   ||mips-sgi-irix5.3
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1
  Build|mips-sgi-irix6.5|mips-sgi-irix6.5,
   ||mips-sgi-irix5.3

--- Comment #1 from Rainer Orth  2010-11-19 13:40:20 UTC 
---
Mine.

[Bug debug/46558] dbgcnt.c messages not marked for translation

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  2010-11-19 13:22:23 UTC ---
On Fri, 19 Nov 2010, rguenth at gcc dot gnu.org wrote:

> Hm.  debug counters are for debugging only thus I don't think we need to
> translate strings there (much as we don't translate comments in GCC code
> or stuff we dump with -ftime-report or -fmem-report).

This is help text from -fdbg-cnt-list which I think is much like --help.  
It's only the table headings I think should be translated, not the rest of 
the content.

[Bug c/46547] [4.5/4.6 Regression] internal compiler error when converting a complex to a bool

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  2010-11-19 13:18:55 
UTC ---
It is caused by revision 145254:

http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00761.html

[Bug c/46547] [4.5/4.6 Regression] internal compiler error when converting a complex to a bool

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  2010-11-19 13:18:21 
UTC ---
It is caused by revision 46547:

http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00761.html

[Bug tree-optimization/46561] [4.6 Regression] -fcompare-debug failure (length) with -O2 -ftree-vectorize -ftree-parallelize-loops

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.19 13:16:33
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2010-11-19 
13:16:33 UTC ---
tree-parloop.c is indeed a mess stmt matching-wise.

[Bug debug/46558] dbgcnt.c messages not marked for translation

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2010-11-19 
13:16:04 UTC ---
Hm.  debug counters are for debugging only thus I don't think we need to
translate strings there (much as we don't translate comments in GCC code
or stuff we dump with -ftime-report or -fmem-report).

[Bug libstdc++/46544] std::map::at() defined even if __GXX_EXPERIMENTAL_CXX0X__ is not

[phresnel at gmail dot com]

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

--- Comment #4 from Sebastian Mach  2010-11-19 
13:12:10 UTC ---
(In reply to comment #3)
> As a general rule, if you see in the code mentioned a "DR XXX.
> YYY", with _GLIBCXX_RESOLVE_LIB_DEFECTS before, it means we are implementing a
> change beyond the letter of C++98/03, per the resolution of a successive ISO
> DR. 

Allright. I never stumbled over DR code, and that's prolly the reason why I did
not recognize it (or possibly I thought that DRs are to be under -std=c++0x).
Carved into synapses for the future.

> For some time, many years ago, that _GLIBCXX_RESOLVE_LIB_DEFECTS was an
> actual macro and we tried to deliver both a vanilla C++98 and an amended
> version, depending on that macro, but it became quickly unmanageable, for
> various reasons (what to do with exported symbols, ODR, etc). 

I already wanted to ask about a switch and it's non-presence, but seeing the
number of DRs I already guessed it would be unmaintanable.

> Besides,
> according to the ISO rules, resolved DRs *are* part of the Standard in law,
> even if a completely new document does not exist yet.

That's both interesting and valuable knowledge, as I am nitpicky myself at
times :D


Thanks for sharing your time :)

[Bug tree-optimization/46561] New: [4.6 Regression] -fcompare-debug failure (length) with -O2 -ftree-vectorize -ftree-parallelize-loops

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] -fcompare-debug failure (length) with
-O2 -ftree-vectorize -ftree-parallelize-loops
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: aol...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 22456
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22456
reduced testcase

Compiler output:
$ gcc -O2 -ftree-vectorize -ftree-parallelize-loops=2 -fcompare-debug pr46561.c 
gcc: error: pr46561.c: -fcompare-debug failure (length)

The dumps are very different, it seems the loop is not parallelized in the -g
case.

Tested revisions:
r166899 - fail
r163636 - fail
r161659 - OK
4.5 r166509 - OK

[Bug tree-optimization/46560] New: libstdc++ execute FAILs with -flto

[rguenth at gcc dot gnu.org]

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

   Summary: libstdc++ execute FAILs with -flto
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: lto, wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


make -k check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=unix/-flto"

yields

Running target unix/-flto
FAIL: 21_strings/basic_string/insert/char/1.cc execution test
FAIL: 21_strings/basic_string/insert/wchar_t/1.cc execution test
FAIL: 23_containers/deque/capacity/29134-2.cc execution test
FAIL: 23_containers/deque/cons/2.cc execution test
FAIL: 23_containers/forward_list/requirements/exception/basic.cc execution test
FAIL: 23_containers/list/modifiers/3.cc execution test
FAIL: 23_containers/list/modifiers/insert/25288.cc execution test
FAIL: 23_containers/list/operations/5.cc execution test
FAIL: 23_containers/list/requirements/exception/basic.cc execution test
FAIL: 23_containers/multimap/requirements/exception/basic.cc execution test
FAIL: 23_containers/multiset/requirements/exception/basic.cc execution test
FAIL: 23_containers/unordered_map/dr761.cc execution test
FAIL: 23_containers/unordered_map/requirements/exception/basic.cc execution
test
FAIL: 23_containers/unordered_multimap/requirements/exception/basic.cc
execution
 test
FAIL: 23_containers/unordered_multiset/requirements/exception/basic.cc
execution
 test
FAIL: 23_containers/unordered_set/requirements/exception/basic.cc execution
test
FAIL: 23_containers/vector/bool/modifiers/insert/31370.cc execution test
FAIL: 23_containers/vector/capacity/2.cc execution test
FAIL: 23_containers/vector/ext_pointer/modifiers/insert.cc execution test
FAIL: 30_threads/promise/members/set_exception2.cc execution test
FAIL: 30_threads/promise/members/set_value2.cc execution test
FAIL: ext/bitmap_allocator/check_allocate_max_size.cc execution test
FAIL: ext/pb_ds/regression/hash_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/hash_no_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/list_update_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/list_update_no_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/priority_queue_rand.cc execution test
FAIL: ext/pb_ds/regression/tree_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/tree_no_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/trie_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/trie_no_data_map_rand.cc execution test
FAIL: ext/throw_allocator/check_deallocate_null.cc execution test

[Bug c/46547] [4.5/4.6 Regression] internal compiler error when converting a complex to a bool

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  2010-11-19 13:01:35 UTC ---
My inclination is that the problem is a missing check of 
in_late_binary_op.  Specifically, that c_common_truthvalue_conversion 
should call save_expr instead of c_save_expr if in_late_binary_op (which 
in turn requires that in_late_binary_op move from c-tree.h/c-typeck.c to 
being defined/declared in c-family code).

[Bug middle-end/46559] New: libstdc++ link FAILs with -flto

[rguenth at gcc dot gnu.org]

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

   Summary: libstdc++ link FAILs with -flto
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: lto
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


make -k check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=unix/-flto"

yields

FAIL: 27_io/basic_filebuf/close/12790-1.cc (test for excess errors)
WARNING: 27_io/basic_filebuf/close/12790-1.cc compilation failed to produce
exec
utable
FAIL: 27_io/basic_filebuf/cons/2020.cc (test for excess errors)
WARNING: 27_io/basic_filebuf/cons/2020.cc compilation failed to produce
executab
le
FAIL: 27_io/basic_filebuf/open/12790-1.cc (test for excess errors)
WARNING: 27_io/basic_filebuf/open/12790-1.cc compilation failed to produce
execu
table
FAIL: 27_io/basic_filebuf/seekoff/10132-2.cc (test for excess errors)
WARNING: 27_io/basic_filebuf/seekoff/10132-2.cc compilation failed to produce
ex
ecutable
FAIL: 27_io/basic_filebuf/seekoff/12790-1.cc (test for excess errors)
WARNING: 27_io/basic_filebuf/seekoff/12790-1.cc compilation failed to produce
ex
ecutable
FAIL: 27_io/basic_filebuf/seekoff/12790-2.cc (test for excess errors)
WARNING: 27_io/basic_filebuf/seekoff/12790-2.cc compilation failed to produce
ex
ecutable
FAIL: 27_io/basic_filebuf/seekoff/12790-3.cc (test for excess errors)
WARNING: 27_io/basic_filebuf/seekpos/10132-3.cc compilation failed to produce
ex
ecutable
FAIL: 27_io/basic_filebuf/seekpos/12790-2.cc (test for excess errors)
WARNING: 27_io/basic_filebuf/seekpos/12790-2.cc compilation failed to produce
ex
ecutable
FAIL: 27_io/basic_fstream/cons/1.cc (test for excess errors)
WARNING: 27_io/basic_fstream/cons/1.cc compilation failed to produce executable
FAIL: 27_io/basic_ifstream/cons/2020.cc (test for excess errors)
WARNING: 27_io/basic_ifstream/cons/2020.cc compilation failed to produce
executa
ble
FAIL: 27_io/basic_ofstream/cons/2020.cc (test for excess errors)
WARNING: 27_io/basic_ofstream/cons/2020.cc compilation failed to produce
executa
ble
FAIL: ext/enc_filebuf/char/13189.cc (test for excess errors)
WARNING: ext/enc_filebuf/char/13189.cc compilation failed to produce executable
FAIL: ext/enc_filebuf/char/13598.cc (test for excess errors)
WARNING: ext/enc_filebuf/char/13598.cc compilation failed to produce executable
FAIL: ext/enc_filebuf/wchar_t/13189.cc (test for excess errors)
WARNING: ext/enc_filebuf/wchar_t/13189.cc compilation failed to produce
executab
le

all with excess errors of the form

FAIL: 27_io/basic_filebuf/seekoff/12790-1.cc (test for excess errors)
Excess errors:
/tmp/ccXujZVx.ltrans0.ltrans.o:(.debug_info+0x1153): undefined reference to
`.LLST0'
/tmp/ccXujZVx.ltrans0.ltrans.o:(.debug_info+0x1169): undefined reference to
`.LLST1'
/tmp/ccXujZVx.ltrans0.ltrans.o:(.debug_info+0x126b): undefined reference to
`.LLST2'
/tmp/ccXujZVx.ltrans0.ltrans.o:(.debug_info+0x127c): undefined reference to
`.LLST3'
/tmp/ccXujZVx.ltrans0.ltrans.o:(.debug_info+0x129d): undefined reference to
`.LLST4'
...

[Bug debug/46558] New: dbgcnt.c messages not marked for translation

[jsm28 at gcc dot gnu.org]

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

   Summary: dbgcnt.c messages not marked for translation
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: js...@gcc.gnu.org
Blocks: 40883


dbgcnt.c contains code

  printf ("  %-30s %-5s %-5s\n", "counter name",  "limit", "value");

with untranslated English phrases "counter name", "limit", "value".  These
should be marked for translation.  As the width of column names in this table
may need to vary depending on the length of the translations, the code should
probably do something involving gcc_gettext_width to compute widths (that's
better than marking the format strings for translation and having translators
adjust widths manually).

[Bug lto/45789] [4.6 Regression] ICE: tree code 'lang_type' is not supported in gimple streams with -flto when using __builtin_printf()

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Richard Guenther  2010-11-19 
11:57:40 UTC ---
Fixed.

[Bug lto/45789] [4.6 Regression] ICE: tree code 'lang_type' is not supported in gimple streams with -flto when using __builtin_printf()

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2010-11-19 
11:57:26 UTC ---
Author: rguenth
Date: Fri Nov 19 11:57:21 2010
New Revision: 166936

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166936
Log:
2010-11-19  Richard Guenther  

PR lto/45789
* lto-streamer-out.c (lto_output_ts_common_tree_pointers): For
IDENTIFIERs do not stream TREE_TYPE.
* lto-streamer-in.c (lto_input_ts_common_tree_pointers): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer-out.c

[Bug libstdc++/46544] std::map::at() defined even if __GXX_EXPERIMENTAL_CXX0X__ is not

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2010-11-19 
11:20:17 UTC ---
I understand ;) As a general rule, if you see in the code mentioned a "DR XXX.
YYY", with _GLIBCXX_RESOLVE_LIB_DEFECTS before, it means we are implementing a
change beyond the letter of C++98/03, per the resolution of a successive ISO
DR. For some time, many years ago, that _GLIBCXX_RESOLVE_LIB_DEFECTS was an
actual macro and we tried to deliver both a vanilla C++98 and an amended
version, depending on that macro, but it became quickly unmanageable, for
various reasons (what to do with exported symbols, ODR, etc). Besides,
according to the ISO rules, resolved DRs *are* part of the Standard in law,
even if a completely new document does not exist yet.

[Bug libstdc++/46544] std::map::at() defined even if __GXX_EXPERIMENTAL_CXX0X__ is not

[phresnel at gmail dot com]

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

--- Comment #2 from Sebastian Mach  2010-11-19 
11:13:49 UTC ---
(In reply to comment #1)

Thanks for clarifiying.

> As you can clearly see

It wasn't that clear to me. As a user of g++ and C++, and as a programmer, I am
not into every DR, as I am already laden with getting codework done, and
looking into the standards can already be hard enough if you relate it to
release-pressure. Additionally grokking every single DR on top of that is not
always managable.

[Bug middle-end/46554] Less inlining leads to CSiBE regression

[hubicka at ucw dot cz]

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

--- Comment #2 from Jan Hubicka  2010-11-19 10:57:57 UTC 
---
> I thought partial inlining would maybe fix this?  Otherwise it's really a
> case that needs IP analysis.

Not with -Os, we really know that it will optimize away.

Honza

Re: [Bug middle-end/46554] Less inlining leads to CSiBE regression

[Jan Hubicka]

> I thought partial inlining would maybe fix this?  Otherwise it's really a
> case that needs IP analysis.

Not with -Os, we really know that it will optimize away.

Honza

[Bug middle-end/46555] PHI RTL expansion leads to CSiBE regression

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.19 10:55:11
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2010-11-19 
10:55:11 UTC ---
Yep.  That's one optimization that was removed (out-of-SSA did that) and
we thought of doing this reverse mergephi optimization as a separate pass
before expansion.

[Bug middle-end/46554] Less inlining leads to CSiBE regression

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.19 10:52:53
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2010-11-19 
10:52:53 UTC ---
I thought partial inlining would maybe fix this?  Otherwise it's really a
case that needs IP analysis.

[Bug c++/46552] [4.6 Regression] [C++0x] Internal compiler error on pointer to member variable with template

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.19 10:50:45
   Target Milestone|--- |4.6.0
Summary|Internal compiler error on  |[4.6 Regression] [C++0x]
   |pointer to member variable  |Internal compiler error on
   |with template   |pointer to member variable
   ||with template
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2010-11-19 
10:50:45 UTC ---
Confirmed.  Works without -std=c++0x and with 4.5.

[Bug lto/45789] [4.6 Regression] ICE: tree code 'lang_type' is not supported in gimple streams with -flto when using __builtin_printf()

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.19 10:32:23
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #3 from Richard Guenther  2010-11-19 
10:32:23 UTC ---
In TYPE_ATTRIBUTES we have

 
bindings <0x75d42910> local bindings <(nil)>>

an identifier with a type - we clean that in free-lang-data but probably
fail to walk TYPE_ATTRIBUTES.

Mine.

[Bug tree-optimization/46557] [4.6 Regression] ICE in cgraph_will_be_removed_from_program_if_no_direct_calls, at cgraph.c:2820

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0