[Bug java/8923] [4.0/4.1/4.2 Regression] ICE when modifying a variable decleared "final static"
--- Comment #8 from simartin at users dot sourceforge dot net 2006-07-27 07:06 --- I've posted a patch for the test case given in comment #6 here: http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01142.html -- simartin at users dot sourceforge dot net changed: What|Removed |Added CC||simartin at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8923
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #24 from patchapp at dberlin dot org 2006-07-27 07:15 --- Subject: Bug number PR rtl-optimization/28071 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01144.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #25 from patchapp at dberlin dot org 2006-07-27 07:20 --- Subject: Bug number PR rtl-optimization/28071 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01145.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #26 from patchapp at dberlin dot org 2006-07-27 07:25 --- Subject: Bug number PR rtl-optimization/28071 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01146.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug gcov/profile/28480] [4.2 Regression] inliner-1.c:31: ICE: in set_bb_for_stmt, at tree-cfg.c:2775
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-07-27 07:42 --- I see the same on i686 now with the tramp3d tester. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, hubicka at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28480
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #27 from patchapp at dberlin dot org 2006-07-27 08:00 --- Subject: Bug number PR rtl-optimization/28071 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01147.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug bootstrap/28511] New: can't bootstrap gcc / syntax error in gcc/opt-gather.awk
configure detects sun's /usr/bin/awk which rejects gcc/opt-gather.awk. (...) TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h" DEFINES="" \ /bin/sh ../../gcc/mkconfig.sh config.h TARGET_CPU_DEFAULT="TARGET_CPU_v7" \ HEADERS="options.h config/sparc/biarch64.h config/sparc/sparc.h config/dbxelf.h config/elfos.h config/svr4.h config/sparc/sysv4.h config/sol2.h config/sparc/sol2.h config/sparc/sol2-bi.h config/tm-dwarf2.h defaults.h" DEFINES="" \ /bin/sh ../../gcc/mkconfig.sh tm.h awk -f ../../gcc/opt-gather.awk ../../gcc/c.opt ../../gcc/common.opt ../../gcc/config/sparc/sparc.opt > tmp-optionlist awk: syntax error near line 24 awk: bailing out near line 24 make[2]: *** [s-options] Error 2 make[2]: Leaving directory `/home/pawels/gcc-4_1-branch/builddir/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/home/pawels/gcc-4_1-branch/builddir/gcc' make: *** [bootstrap] i think gcc should check for gnu/awk in $path:/opt/sfw/bin. -- Summary: can't bootstrap gcc / syntax error in gcc/opt-gather.awk Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC build triplet: sparc-sun-solaris2.9 GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28511
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
--- Comment #6 from tbm at cyrius dot com 2006-07-27 08:59 --- Created an attachment (id=11955) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11955&action=view) test case Testcase from application "ickle". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug target/28508] Assembler Error: operand out of ragne (145 not between -128 and 127) form m32r-target
--- Comment #3 from nickc at redhat dot com 2006-07-27 10:20 --- Kazu, I will apply your proposed patch. One day we must really spend the time to fixup gcc so that the backends know about these debug labels and their effect on code placement. Cheers Nick PS. For the record this PR started here: http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01050.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28508
[Bug middle-end/28498] fstack-protector causes crash in combination with -Os
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-07-27 11:31 --- With checking enabled you get /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/bits/stl_algo.h: In function '_RandomAccessIterator std::__unguarded_partition(_RandomAccessIterator, _RandomAccessIterator, _Tp) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator > >, _Tp = QRect]': /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/bits/stl_algo.h:2182: error: NOTE_INSN_BASIC_BLOCK is missing for block 1 /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/bits/stl_algo.h:2182: error: NOTE_INSN_BASIC_BLOCK 21 in middle of basic block 1 /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/bits/stl_algo.h:2182: error: insn outside basic block (insn 19 17 21 1 (parallel [ (set (reg/f:SI 7 sp) (plus:SI (reg/f:SI 7 sp) (const_int 12 [0xc]))) (clobber (reg:CC 17 flags)) ]) -1 (nil) (nil)) /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/bits/stl_algo.h:2182: internal compiler error: in rtl_verify_flow_info, at cfgrtl.c:2250 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. not a regression, since 4.0 did not have -fstack-protector. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Keywords||ice-on-valid-code Known to fail||4.1.0 4.1.1 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28498
[Bug target/28508] Assembler Error: operand out of range (145 not between -128 and 127) form m32r-target
--- Comment #4 from nickc at gcc dot gnu dot org 2006-07-27 12:21 --- Subject: Bug 28508 Author: nickc Date: Thu Jul 27 12:21:39 2006 New Revision: 115773 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115773 Log: PR gcc/28508 * config/m32r/m32r.md (branch_insn): Reduce pc range for short branch. (rev_branch_insn): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m32r/m32r.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28508
[Bug middle-end/28498] fstack-protector causes crash in combination with -Os
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-27 12:48 --- Created an attachment (id=11956) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11956&action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28498
[Bug middle-end/28498] fstack-protector causes crash in combination with -Os
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-07-27 12:48 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-27 12:48:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28498
[Bug middle-end/26983] [4.0/4.1/4.2 Regression] Missing label with builtin_setjmp/longjmp
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-07-27 13:00
---
Here's a reduced testcase without nested functions:
void* jmpbuf[6];
void foo()
{
__builtin_setjmp (jmpbuf);
}
int main()
{
return 0;
}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1/4.2 Regression]
|Missing label in a nested |Missing label with
|function with |builtin_setjmp/longjmp
|builtin_setjmp/longjmp |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26983
[Bug middle-end/26983] [4.0/4.1/4.2 Regression] Missing label with builtin_setjmp/longjmp
--- Comment #6 from steven at gcc dot gnu dot org 2006-07-27 13:25 --- Thanks Volkert. I had a test case like that, I should have put it in this audit trail. I am *so* going to fix this bug. I think... -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-06-11 13:35:04 |2006-07-27 13:25:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26983
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #28 from hubicka at gcc dot gnu dot org 2006-07-27 16:02 --- Subject: Bug 28071 Author: hubicka Date: Thu Jul 27 16:02:27 2006 New Revision: 115776 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115776 Log: PR rtl-optimization/28071 * global.c (greg_obstack): New obstack. (allocate_bb_info): Use it. (free_bb_info): Likewise. (modify_reg_pav): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/global.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #29 from hubicka at gcc dot gnu dot org 2006-07-27 16:03 --- Subject: Bug 28071 Author: hubicka Date: Thu Jul 27 16:03:22 2006 New Revision: 115777 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115777 Log: PR rtl-optimization/28071 * cselib.c (cselib_process_insn): Don't remove useless values too often for very large hashtables. Modified: trunk/gcc/ChangeLog trunk/gcc/cselib.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug gcov/profile/28480] [4.2 Regression] inliner-1.c:31: ICE: in set_bb_for_stmt, at tree-cfg.c:2775
--- Comment #5 from hubicka at ucw dot cz 2006-07-27 16:06 ---
Subject: Re: [Bug gcov/profile/28480] [4.2 Regression] inliner-1.c:31: ICE: in
set_bb_for_stmt, at tree-cfg.c:2775
Hi,
it is hitting sanity check in set_bb_for_stmt that is bit insane in this
context. I am testing patch to inline neccesary parts of
set_bb_for_stmt (because of quadratic time issue it is time critical too
and we need very little of the function itself.)
Index: tree-cfg.c
===
*** tree-cfg.c (revision 115775)
--- tree-cfg.c (working copy)
*** tree_split_block (basic_block bb, void *
*** 4203,4209
new_bb->stmt_list = tsi_split_statement_list_before (&bsi.tsi);
for (tsi_tgt = tsi_start (new_bb->stmt_list);
!tsi_end_p (tsi_tgt); tsi_next (&tsi_tgt))
! set_bb_for_stmt (tsi_stmt (tsi_tgt), new_bb);
return new_bb;
}
--- 4205,4218
new_bb->stmt_list = tsi_split_statement_list_before (&bsi.tsi);
for (tsi_tgt = tsi_start (new_bb->stmt_list);
!tsi_end_p (tsi_tgt); tsi_next (&tsi_tgt))
! {
! tree stmt = tsi_stmt (tsi_tgt);
!
! get_stmt_ann (stmt)->bb = new_bb;
! if (TREE_CODE (stmt) == LABEL_EXPR)
! VEC_replace (basic_block, label_to_block_map,
!LABEL_DECL_UID (LABEL_EXPR_LABEL (stmt)), bb);
! }
return new_bb;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28480
[Bug gcov/profile/28480] [4.2 Regression] inliner-1.c:31: ICE: in set_bb_for_stmt, at tree-cfg.c:2775
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-07-27 16:07 --- Maybe with a comment that says this was set_bb_for_stmt and why it isn't anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28480
[Bug gcov/profile/28480] [4.2 Regression] inliner-1.c:31: ICE: in set_bb_for_stmt, at tree-cfg.c:2775
--- Comment #7 from amacleod at redhat dot com 2006-07-27 16:35 ---
There is always the danger of losing track of exceptions.
Another option is to create an inline routine in tree-flow-inline.h which does
what you lay out, and then change set_bb_for_stmt to call it, looking something
like:
Index: tree-cfg.c
===
*** tree-cfg.c (revision 114853)
--- tree-cfg.c (working copy)
*** set_bb_for_stmt (tree t, basic_block bb)
*** 2741,2749
}
else
{
- stmt_ann_t ann = get_stmt_ann (t);
- ann->bb = bb;
-
/* If the statement is a label, add the label to block-to-labels map
so that we can speed up edge creation for GOTO_EXPRs. */
if (TREE_CODE (t) == LABEL_EXPR)
--- 2741,2746
*** set_bb_for_stmt (tree t, basic_block bb)
*** 2773,2780
removed it from the old block. */
gcc_assert (!bb
|| !VEC_index (basic_block, label_to_block_map, uid));
- VEC_replace (basic_block, label_to_block_map, uid, bb);
}
}
}
--- 2770,2777
removed it from the old block. */
gcc_assert (!bb
|| !VEC_index (basic_block, label_to_block_map, uid));
}
+ set_bb_for_tree_stmt_raw (t, bb);
}
}
>From a quick glance it doesnt appear that changing the order like that is
significant, and then everything is still done in one place.
It'd probably be worthwhile to add gcc_assert()'s with ENABLE_CHECKING that the
tree passed to the new inline routine isn't a STMT_LIST or a PHI_NODE, and
maybe if it is a LABEL_EXPR, that the uid isn't -1... just to confirm
everything is kosher :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28480
[Bug c++/28513] New: QOI: Diagnostic missing since 3.3.x when naming rule is violated
class foo {
public:
typedef int bar;
};
class baz {
public:
foo::bar foo;
};
With G++ 3.3.6, this errors out with this diagnostic:
$ g++-3.3 -pedantic -Wall -Wcast-align -Wwrite-strings -Wswitch-default
-Wcast-qual -Wunused-variable -Wredundant-decls -Wctor-dtor-privacy
-Wnon-virtual-dtor -Wreorder -Wold-style-cast -Woverloaded-virtual
-fstrict-aliasing -c foo.cc
foo.cc:8: error: declaration of `int baz::foo'
foo.cc:1: error: changes meaning of `foo' from `class foo'
With G++ 3.4, 4.0, 4.1 and 4.2 (current CVS), no diagnostic is issued.
A diagnostic is not strictly required by the standard (§3.3.6,
basic.scope.class), but would be very useful.
Regards,
Roger
--
Summary: QOI: Diagnostic missing since 3.3.x when naming rule is
violated
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rleigh at debian dot org
GCC build triplet: powerpc-linux-gnu
GCC host triplet: powerpc-linux-gnu
GCC target triplet: powerpc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28513
[Bug c++/28514] New: pch vs. anonymous namespaces
Am running into this kind of thing when I convert include/ext/rope and friends
to using anonymous namespace.
This simplified source doesn't show the bug, sadly, but I'll put up
pre-processed code that demonstrates it in a bit.
namespace __gnu_cxx
{
namespace
{
enum _Tag1 {_S_leaf1, _S_concat1, _S_substringfn1, _S_function1};
}
namespace constants
{
enum _Tag2 {_S_leaf2, _S_concat2, _S_substringfn2, _S_function2};
}
template
struct A
{
static void foo(const T i)
{
int j;
switch(i)
{
case _S_concat1: // error here, invalid integer constant
j = 5;
break;
case constants::_S_leaf2:
j = 5;
break;
default:
j = 0;
}
}
};
Code seems correct, but something about PCH kills it.
--
Summary: pch vs. anonymous namespaces
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514
[Bug c++/28514] pch vs. anonymous namespaces
--- Comment #1 from bkoz at gcc dot gnu dot org 2006-07-27 17:04 --- Created an attachment (id=11957) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11957&action=view) reproducer with today's gcc To reproduce, do: /mnt/share/bld/gcc/./gcc/xgcc -shared-libgcc -B/mnt/share/bld/gcc/./gcc -nostdinc++ -Winvalid-pch -Wno-deprecated -x c++-header i686-pc-linux-gnu/bits/extc++.h.gch.ii -o i686-pc-linux-gnu/bits/extc++.h.gch/02g.gch Or equivalent, based on your current build compiler directory locations. Get: /mnt/share/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/ext/ropeimpl.h: In static member function 'static _CharT __gnu_cxx::rope<_CharT, _Alloc>::_S_fetch(__gnu_cxx::_Rope_RopeRep<_CharT, _Alloc>*, size_t) [with _CharT = char, _Alloc = std::allocator]': /mnt/share/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/ext/rope:1980: instantiated from '_CharT __gnu_cxx::rope<_CharT, _Alloc>::operator[](size_t) const [with _CharT = char, _Alloc = std::allocator]' /mnt/share/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/ext/rope:2894: instantiated from here /mnt/share/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/ext/ropeimpl.h:1334: error: case label does not reduce to an integer constant -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514
[Bug rtl-optimization/21299] [4.0/4.1/4.2 Regression] internal error on invalid asm statement
--- Comment #2 from tbm at cyrius dot com 2006-07-27 17:04 ---
This is not i386 specific. I get the same on ia64 with e.g.
void f(int port)
{
__asm__ volatile ("inb %1,%0"
:"=a" (port)
:"d"((unsigned short) port));
}
It's still there as of current gcc 4.2.
--
tbm at cyrius dot com changed:
What|Removed |Added
CC||tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21299
[Bug c++/28514] pch vs. anonymous namespaces
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-07-27 17:05 --- Jason can you look at this plz? -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #30 from hubicka at gcc dot gnu dot org 2006-07-27 17:10 --- Subject: Bug 28071 Author: hubicka Date: Thu Jul 27 17:10:07 2006 New Revision: 115779 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115779 Log: PR rtl-optimization/28071 * hashtab.c (htab_empty): Clear out n_deleted/n_elements; downsize the hashtable. Modified: trunk/libiberty/ChangeLog trunk/libiberty/hashtab.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug rtl-optimization/21299] [4.0/4.1/4.2 Regression] internal error on invalid asm statement
--- Comment #3 from tbm at cyrius dot com 2006-07-27 17:16 ---
(In reply to comment #2)
> This is not i386 specific. I get the same on ia64 with e.g.
>
> void f(int port)
> {
> __asm__ volatile ("inb %1,%0"
> :"=a" (port)
> :"d"((unsigned short) port));
> }
Just for the record, here's the output:
[EMAIL PROTECTED]:~/src/svgalib-1.4.3$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 x.c
x.c: In function 'f':
x.c:3: error: impossible register constraint in 'asm'
x.c:3: error: impossible register constraint in 'asm'
x.c:3: error: impossible register constraint in 'asm'
x.c:6: error: unrecognizable insn:
(insn 11 7 23 2 (set (reg:SI 2 r2)
(asm_operands/v:SI ("inb %1,%0") ("=a") 0 [
(reg:HI 112 in0)
]
[
(asm_input:HI ("d"))
] ("x.c") 3)) -1 (nil)
(nil))
x.c:6: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:393
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21299
[Bug rtl-optimization/21299] [4.0/4.1/4.2 Regression] internal error on invalid asm statement
--- Comment #4 from tbm at cyrius dot com 2006-07-27 17:17 --- FWIW, it works (i.e. error, but no ICE) on mipsel, x86_64 and powerpc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21299
[Bug debug/27574] [4.1/4.2 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor
--- Comment #13 from amylaar at gcc dot gnu dot org 2006-07-27 17:29 --- (In reply to comment #12) > It is a cgraph change. There were several patches affecting > cgraph_remove_node > during this time period; it was probably one of those. The problem appeared from r96653 to r96654; AFAICT this is the gcc-patches posting for the associated patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01709.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27574
[Bug bootstrap/28515] New: CFLAGS not propagated, resulting in object mismatch
Configured gcc with CFLAGS=-xarch=v9 (among other flags) to produce 64-bit code from the system compiler, instead of the default of 32-bit. (begin build log excerpt) cc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/tg/freeport/src/gcc/gcc--4.1.1/gcc -I/tg/freeport/src/gcc/gcc--4.1.1/gcc/build -I/tg/freeport/src/gcc/gcc--4.1.1/gcc/../include -I/tg/freeport/src/gcc/gcc--4.1.1/gcc/../libcpp/include -D__EXTENSIONS__ -D_REENTRANT -Dsparc-o build/errors.o /tg/freeport/src/gcc/gcc--4.1.1/gcc/errors.c cc -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genmodes \ build/genmodes.o build/errors.o ../build-sparc-sun-solaris2.8/libiberty/libiberty.a ild: (bad file) Input file ../build-sparc-sun-solaris2.8/libiberty/libiberty.a contains 64-bit relocatable, but producing a 32-bit file. gmake[2]: *** [build/genmodes] Error 1 gmake[2]: Leaving directory `/export/home/cport/tmp/gcc--4.1.1.build/gcc' gmake[1]: *** [stage1_build] Error 2 gmake[1]: Leaving directory `/export/home/cport/tmp/gcc--4.1.1.build/gcc' gmake: *** [bootstrap-lean] Error 2 (end build log excerpt) build/errors.o and build/genmodes are compiled and linked without the original CFLAGS, while libiberty.a was. From the looks of it, gcc/Makefile doesn't pick up CFLAGS at all. -- Summary: CFLAGS not propagated, resulting in object mismatch Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: skunk at iskunk dot org GCC build triplet: sparc-sun-solaris2.8 GCC host triplet: sparc-sun-solaris2.8 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-27 18:08 --- You need to also set STAGE1_CFLAGS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug target/28516] New: [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
Robert Schwebel reported on libc-ports that glibc failed to build on softfloat arm eabi with an ICE, see http://sources.redhat.com/ml/libc-ports/2006-07/msg00027.html It fails with -fexceptions and works without. I've attached a reduce testcase. I assume this is a regression but I don't have an older cross compiler so I cannot say for sure. (sid)207:[EMAIL PROTECTED]: ~] ~/tmp/gcc/4.2-arm-softfloat/gcc/xgcc -c -fexceptions glibc-dl-lookup.c glibc-dl-lookup.c: In function âcheck_matchâ: glibc-dl-lookup.c:149: internal compiler error: in arm_unwind_emit_set, at config/arm/arm.c:15419 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. (sid)208:[EMAIL PROTECTED]: ~] ~/tmp/gcc/4.2-arm-softfloat/gcc/xgcc -c glibc-dl-lookup.c (sid)209:[EMAIL PROTECTED]: ~] -- Summary: [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC host triplet: arm-softfloat-linux-gnueabi GCC target triplet: arm-softfloat-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #1 from tbm at cyrius dot com 2006-07-27 18:54 --- Created an attachment (id=11958) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11958&action=view) test case Reduced testcase from dl-lookup.c from glibc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #2 from skunk at iskunk dot org 2006-07-27 19:09 --- (In reply to comment #1) > You need to also set STAGE1_CFLAGS. Wait... how does that work? gcc/Makefile.in has these lines: # STAGE1_CFLAGS is set by configure on some targets or passed from toplevel # and sets the CFLAGS passed to stage1 of a bootstrap compilation. [...] CFLAGS = -g STAGE1_CFLAGS = -g @stage1_cflags@ @stage1_cflags@ is set in the configure script (both the top-level one and the one in gcc/), but the value incorporates no user-set variable; it's predicated on just the build triplet. So there's no way to set STAGE1_CFLAGS without manually overriding it in the makefile. That aside, why does this variable have to be set separately? If you set CC and CFLAGS, the assumption is that the two will always be used together. (What gets passed to xgcc and later stages is a different matter, of course.) In theory you could have a system compiler that behaves in a completely broken manner without some special flag. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug c++/28517] New: Incorrect floating point calculations when done in class constructor
OS: Fedora Core 3 (64 AMD) I have run into an issue where floating point calculations are incorrect (slightly off). The calculations are done as arguments to a class constructor. Attached is small program that demostrates this. However I was only able to reproduce it using the third party (a single header file of inline code under the GLPL) random number generator that our program uses. -- Summary: Incorrect floating point calculations when done in class constructor Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: emalloy at andrew dot cmu dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28517
[Bug c++/28517] Incorrect floating point calculations when done in class constructor
--- Comment #1 from emalloy at andrew dot cmu dot edu 2006-07-27 20:09 --- Created an attachment (id=11959) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11959&action=view) Main sample code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28517
[Bug c++/28517] Incorrect floating point calculations when done in class constructor
--- Comment #2 from emalloy at andrew dot cmu dot edu 2006-07-27 20:09 --- Created an attachment (id=11960) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11960&action=view) Third Party RNG Header -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28517
[Bug debug/27574] [4.1/4.2 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor
--- Comment #14 from drow at gcc dot gnu dot org 2006-07-27 20:12 --- Subject: Re: [4.1/4.2 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor On Thu, Jul 27, 2006 at 05:29:38PM -, amylaar at gcc dot gnu dot org wrote: > The problem appeared from r96653 to r96654; AFAICT this is the gcc-patches > posting for the associated patch: > http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01709.html Jan and Dan Berlin suggested that the right fix for this bug might be to not register the uncloned constructor with cgraph, only the clones. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27574
[Bug c++/28517] Incorrect floating point calculations when done in class constructor
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-27 20:30 --- Foo wrong_values((t1+rng1.RandomDouble(t1,t2)),(t2+rng1.RandomDouble(t1,t2))); The order of execution of the two function calls (to RandomDouble) in this statement is unspecified which means GCC can call it in either order. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28517
[Bug c++/28274] [4.0/4.1/4.2 Regression] Redeclaration with extra default argument doesn't work
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-07-27 20:31 --- This was caused by my patch for PR 16829. I'll take care of it. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||monitored Known to fail|4.1.1 |3.4.6 4.0.3 4.1.0 4.1.1 ||4.2.0 Known to work|3.3.6 3.4.0 |3.3.6 3.4.0 3.4.5 4.0.2 Summary|[4.1/4.2 Regression]|[4.0/4.1/4.2 Regression] |Redeclaration with extra|Redeclaration with extra |default argument doesn't|default argument doesn't |work|work Target Milestone|4.1.2 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28274
[Bug c/28518] New: Single stepping until exit ...
The m/c I use is Solaris running: SunOS hirst 5.10 Generic_118822-26 sun4u sparc SUNW,Sun-Blade-2500 I have gcc version 3.4.3 installed: Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs Configured with: /gates/sfw10/builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) and gcc version 4.1.1 installed: Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../gcc-4.1.1a/configure --prefix=/opt/gcc-4.4.1 --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 4.1.1 I have two problems when I enter GDB debugger via DDD (I get the problem even without DDD) I get the following: 1) (gdb) run deptsv li ~/lsa/src/web/inp.file warning: Lowest section in /usr/lib/libthread.so.1 is .dynamic at 0074 warning: Lowest section in /usr/lib/libdl.so.1 is .dynamic at 0094 Breakpoint 1, w_listDepts () at /export/home/lisa100/lsa/src/web/web_depts.c:63 /export/home/lisa100/lsa/src/web/web_depts.c:63:1519:beg:0x12064 Why am I getting the 'Lowest section...' message ? How can I avoid it ? 2) When I step through line by line through the code using 'n' for next, when it hits a particular while loop I get the following: (gdb) n Single stepping until exit from function w_dept_populate, which has no line number information. w_listDepts () at /export/home/lisa100/lsa/src/web/web_depts.c:73 I have built all the C modules with -g flag and I get this with both versions of gcc. I cannot seem to step through the code in my while loop. Please help. I need to know what I am doing wrong or what is causing this. As the module has been compiled with -g I would have expected every line to be stepped through. Please note that I can set breaks to one of the lines in the while loop buut the moment I say 'n' I get the above message. Please help... Cheers, Alex -- Summary: Single stepping until exit ... Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alex dot jacob at logicacmg dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28518
[Bug driver/28437] [4.2 Regression] multiple fno-builtin-* flags broken
--- Comment #11 from hjl at gcc dot gnu dot org 2006-07-27 21:27 --- Subject: Bug 28437 Author: hjl Date: Thu Jul 27 21:26:55 2006 New Revision: 115780 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115780 Log: 2006-07-27 H.J. Lu <[EMAIL PROTECTED]> PR driver/28437 * opts-common.c (prune_options): Skip joined switches. Modified: trunk/gcc/ChangeLog trunk/gcc/opts-common.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28437
[Bug debug/28518] Single stepping until exit ...
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-27 21:32 --- And why do you think this is a GCC bug and not a GDB bug? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |debug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28518
[Bug debug/28518] Single stepping until exit ...
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-27 21:32 --- Also we need a testcase to be able to reproduce this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28518
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #3 from schwab at suse dot de 2006-07-27 22:19 --- (In reply to comment #2) > (In reply to comment #1) > > You need to also set STAGE1_CFLAGS. > > Wait... how does that work? make STAGE1_CFLAGS=whatever -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug c++/28407] [4.2 regression] Issue with anonymous namespace
--- Comment #11 from bkoz at gcc dot gnu dot org 2006-07-27 22:21 --- I definitely remember Gaby talking about this at the standards meetings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28407
[Bug c/28519] New: unkillable, nonstandard warning
My users are griping about the large numbers of warnings like: >warning: the use of `tmpnam' is dangerous, better use `mkstemp' that gcc generates on every single link. Throwing the -w flag does not repress this message. I am limited to ANSI C standard routines only, and so cannot make the switch to the non-standard routine mkstemp. If gcc insists on warning about ANSI C standard function calls, it would be nice to have a way of turning them off. Thanks, Clint -- Summary: unkillable, nonstandard warning Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: whaley at cs dot utsa dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28519
[Bug c++/28514] pch vs. anonymous namespaces
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-07-27 22:32 --- Changing just the first case _S_concat: to case ::_S_concat: Fixes this. Wierd. I noticed a couple of other random lookup issues, or non-issues that surprised me. One was with static functions in global-scope anonymous namespaces have to be explicitly qualified with a :: operator. (mt_allocator.cc patches) global-scope enums used as integer constants in case labels of switch statements. Fully qualified too? Anyway. I'll attach the work-in-progress patch to convert libstdc++ __gnu_internal namespace to anonymous namespaces. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514
[Bug c++/28514] pch vs. anonymous namespaces
--- Comment #4 from bkoz at gcc dot gnu dot org 2006-07-27 22:33 --- Created an attachment (id=11961) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11961&action=view) work-in-progress patch to convert libstdc++ to anonymous namespaces -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514
[Bug c++/28514] libstdc++ vs. anonymous namespaces
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-07-27 22:33 --- change title -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Summary|pch vs. anonymous namespaces|libstdc++ vs. anonymous ||namespaces http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514
[Bug fortran/25818] Problem with handling optional and entry master arguments
--- Comment #2 from taschna at uni-muenster dot de 2006-07-27 22:38 ---
I'm an absolute beginner in programming gfortran, but the following patch seems
to solve this bug by inserting an if-block into the code in order to prevent
the access to the NULL pointer in case the array is pointing to NULL.
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (revision 115751)
+++ gcc/fortran/trans-array.c (working copy)
@@ -3656,7 +3656,9 @@ gfc_trans_g77_array (gfc_symbol * sym, t
locus loc;
tree offset;
tree tmp;
+ tree stmt;
stmtblock_t block;
+ bool optional_arg;
gfc_get_backend_locus (&loc);
gfc_set_backend_locus (&sym->declared_at);
@@ -3685,13 +3687,22 @@ gfc_trans_g77_array (gfc_symbol * sym, t
tmp = convert (TREE_TYPE (parm), GFC_DECL_SAVED_DESCRIPTOR (parm));
gfc_add_modify_expr (&block, parm, tmp);
}
- tmp = gfc_finish_block (&block);
+ stmt = gfc_finish_block (&block);
gfc_set_backend_locus (&loc);
gfc_start_block (&block);
/* Add the initialization code to the start of the function. */
- gfc_add_expr_to_block (&block, tmp);
+ optional_arg = (sym->attr.optional
+ || (sym->ns->proc_name->attr.entry_master
+ && sym->attr.dummy));
+ if (optional_arg)
+{
+ tmp = gfc_conv_expr_present (sym);
+ stmt = build3_v (COND_EXPR, tmp, stmt, build_empty_stmt ());
+}
+
+ gfc_add_expr_to_block (&block, stmt);
gfc_add_expr_to_block (&block, body);
return gfc_finish_block (&block);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25818
[Bug bootstrap/28497] /usr/ccs/bin/ld: Unrecognized argument: +init
--- Comment #3 from danglin at gcc dot gnu dot org 2006-07-27 22:47 --- Your HP system linker is too old. Please update to PHSS_33034 or later. +init is a "common" option for both 32 and 64 bit links. +init is used by GCC for initializers for the 32-bit runtime. You probably should install the latest patch bundle for 11.00. PHSS_33034 is recommended because it fixes a critical error. It's also needed for Java in 4.2. The installation documentation contains the minimum patch requirements. GNU ld doesn't support the 32-bit SOM runtime under hpux. It's a work in progress for the 64-bit runtime and not recommended. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28497
[Bug c/28519] unkillable, nonstandard warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-27 22:49 --- GCC is not what is warning. ld is warning because glibc tells it to warn. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28519
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
-- pbrook at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-27 23:33:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #2 from pbrook at gcc dot gnu dot org 2006-07-27 23:37 --- Huh. I thought glibc had removed all their nested functions. The unwind table generation code can't cope with the prologue generated for nested functions. The reduced testcase passes the -O because gcc un-nests the function. Is this true of the original testcase, or does glibc require trampolines? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #3 from tbm at cyrius dot com 2006-07-27 23:49 --- (In reply to comment #2) > The reduced testcase passes the -O because gcc un-nests the function. Is this > true of the original testcase, or does glibc require trampolines? I *think* it passed at -O but I cannot check right now. Instead, I'll attach the original, unreduced preprocessed source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #4 from tbm at cyrius dot com 2006-07-27 23:49 --- Created an attachment (id=11962) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11962&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug bootstrap/28497] /usr/ccs/bin/ld: Unrecognized argument: +init
--- Comment #4 from skunk at iskunk dot org 2006-07-28 02:04 --- (In reply to comment #3) > Your HP system linker is too old. Please update to PHSS_33034 or > later. Thanks for the note; I'll do that. It would be good to have a configure-time check for this. This did seem to be a system portability bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28497
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #4 from skunk at iskunk dot org 2006-07-28 02:20 ---
(In reply to comment #3)
>
> make STAGE1_CFLAGS=whatever
Yes. Editing the makefile works pretty well too :-)
But the point is, it's a bug for cc(1) to have been invoked without the
original CFLAGS. I admit that I don't fully understand how the
host/system/build/stageN settings are partitioned, but it seems like a pretty
clear problem for a straight-up CC+CFLAGS environment to give the build error I
quoted. Methinks something like
STAGE1_CFLAGS=${STAGE1_CFLAGS-${CFLAGS}}
should be happening at configure time, that STAGE1_CFLAGS can be set if you
want GCC's stage 1 to be built with different flags than libiberty, but
otherwise that you can just set CC+CFLAGS as usual and have it all work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #100 from bkoz at gcc dot gnu dot org 2006-07-28 04:57 --- Subject: Bug 19664 Author: bkoz Date: Fri Jul 28 04:57:34 2006 New Revision: 115790 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115790 Log: 2006-07-27 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/19664 round 3 * include/Makefile.am (tr1_headers): Add hashtable_policy.h. * include/Makefile.in: Regenerate. * include/tr1/hashtable: Move policy classes into... * include/tr1/hashtable_policy.h: ... this. New. * src/globals_locale.cc: Move contents * src/locale_init.cc: ... to here, put in anonymous namespace. * src/Makefile.am: Remove globals_locale.cc. * src/Makefile.in: Regenerate. * src/locale.cc: Convert __gnu_internal to anonymous namespace. * src/debug.cc: Same. * src/ext-inst.cc: Same. * src/mt_allocator.cc: Same. * src/pool_allocator.cc: Same. * include/tr1/random: Convert std::tr1::_Private to anonymous namespace. * include/tr1/random.tcc: Same. * include/tr1/hashtable: Move ::Internal to std::tr1::detail and enclose bits that can actually be internal in in anonymous namespace. * include/tr1/unordered_set: Adjust explicit qualifications for namespace changes. * include/tr1/unordered_map: Same. * include/tr1/cmath: Convert __gnu_internal to nested detail namespace. * include/bits/cpp_type_traits.h: Move __type_type into anonymous namespace. * include/ext/rope: Change _Rope_constants to anonymous namespace. * include/ext/ropeimpl.h: Same. * src/ext-inst.cc: Same. Added: trunk/libstdc++-v3/include/tr1/hashtable_policy.h Removed: trunk/libstdc++-v3/src/globals_locale.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/include/bits/cpp_type_traits.h trunk/libstdc++-v3/include/ext/rope trunk/libstdc++-v3/include/ext/ropeimpl.h trunk/libstdc++-v3/include/tr1/cmath trunk/libstdc++-v3/include/tr1/hashtable trunk/libstdc++-v3/include/tr1/random trunk/libstdc++-v3/include/tr1/random.tcc trunk/libstdc++-v3/include/tr1/unordered_map trunk/libstdc++-v3/include/tr1/unordered_set trunk/libstdc++-v3/src/Makefile.am trunk/libstdc++-v3/src/Makefile.in trunk/libstdc++-v3/src/debug.cc trunk/libstdc++-v3/src/ext-inst.cc trunk/libstdc++-v3/src/locale.cc trunk/libstdc++-v3/src/locale_init.cc trunk/libstdc++-v3/src/mt_allocator.cc trunk/libstdc++-v3/src/pool_allocator.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug preprocessor/28520] New: preprocessed output does not lex to correct tokens
This: #define x = http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28521] New: -E output incorrectly concatenates tokens into trigraphs
gcc -E on: #define z ? ?z( emits: ??( This won't lex correctly when trigraphs are enabled. -Chris -- Summary: -E output incorrectly concatenates tokens into trigraphs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
