[Bug c++/58147] New: Template template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58147
Bug ID: 58147
Summary: Template template parameter
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
Although the usage is a bit dubious, name lookup of the identifier after a
nested-name-specifier should not find a template parameter name. But it does,
seemingly only for a template template parameter.
template< typename > struct b {};
template< template< typename > class b > struct d
: b< int >
{ using d::b< int >::b; };
template struct d< b >;
[Bug tree-optimization/58121] [4.9 regression] FAIL: cc1224a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58121 Andreas Schwab changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from Andreas Schwab --- Still failing as of r201681.
[Bug c++/58147] Template template parameter name found after nested-name-specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58147 David Krauss changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from David Krauss --- Never mind; I was missing a template keyword after the nested-name-specifier. NEEDS MOAR TEMPLATE!
[Bug middle-end/52544] compilation fails with -finstrument-functions and sse c code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52544 --- Comment #6 from Rodrigo Campos --- Actually, I recently find out that the memory corruption thing was not a GCC bug. It was a really weird error that only appears in the library if you do a print to stdout (not stderr) before some thing happens. And when I added a print compiling without -finstrument-functions, I did not added at the **very** beginning (but after some other thing, if not you will not hit the bug) and when compiling with "-finstrument-functions" it was added there. So I did not hit this weird bug when I tried to :) So I'm just hitting the bug originally reported with the same symptoms, sorry for the noise! If I can help in any way, please let me know :-) Thanks a lot, Rodrigo
[Bug c++/58144] Receive "virtual memory exhausted: Cannot allocate memory" while compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58144 --- Comment #1 from Jonathan Wakely --- (In reply to Amit Chitnis from comment #0) > 2. create a big file (say 900M) named "new" in a location which is a part of > your include path. This is your problem, is a standard header so you must not replace it.
[Bug fortran/58007] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007 janus at gcc dot gnu.org changed: What|Removed |Added Attachment #30567|0 |1 is obsolete|| CC||janus at gcc dot gnu.org --- Comment #4 from janus at gcc dot gnu.org --- Created attachment 30641 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30641&action=edit further reduced test case Here is a further reduced test case, based on comment 2. It consists of only two files. One contains the three modules, the other one an almost empty main program. For me this fails only with 4.8 and trunk, but not with 4.7.
[Bug fortran/44978] derived types are resolved more than once
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44978
--- Comment #17 from Dominique d'Humieres ---
In what follows "Janus' patch" will refer to
http://gcc.gnu.org/bugzilla/attachment.cgi?id=30629
and "Mikael's patch" to
http://gcc.gnu.org/bugzilla/attachment.cgi?id=30633
Although there are still duplicate errors, both patches regtest cleanly and are
a significant improvement. I have seen the following differences between the
two patches (I'll attach the full differences):
(1) pr43591, Mikael's patch output the additional error
pr43591.f90:8.77:
procedure(number_flavor_states), nopass, pointer :: number_flavor_states
=> NULL()
1
Error: Interface 'number_flavor_states' at (1) must be explicit
For both patches the error
pr43591.f90:15.23:
integer, dimension(physical%number_particles_out(), &
1
Error: Expression at (1) must be of INTEGER type, found UNKNOWN
is printed twice.
(2) pr48095, the error
pr48095.f90:7.79:
procedure(get_area), pointer, pass(this) :: get_special_area => get_my_area
1
Error: Interface mismatch in procedure pointer assignment at (1): Type mismatch
in argument 'this' (CLASS(rectangle)/TYPE(rectangle))
is printed three times with Janus' patch and only twice with Mikael's one.
(3) pr55983, with Janus' patch, the last error is
pr55983.f90:16.32:
class(bcd_t), pointer :: bcx, bcy
1
Error: The pointer component 'bcx' of '__class_solver_mpdata_m_Mpdata_t' at (1)
is a type that has not been declared
while with Mikael's patch it is
pr55983.f90:16.37:
class(bcd_t), pointer :: bcx, bcy
1
Error: The pointer component 'bcy' of 'mpdata_t' at (1) is a type that has not
been declared
For a clean tree it is
class(bcd_t), pointer :: bcx, bcy
1
Error: The pointer component 'bcx' of 'mpdata_t' at (1) is a type that has not
been declared
(4) pr58023, compiling both tests with Janus' patch gives an ICE, while with
Mikale's patch the first test gives a second error
pr58023.f90:11.34:
procedure(mr), pointer :: mr2
1
Error: Procedure pointer component 'mr2' with PASS at (1) must have at least
one argument
> I also took the opportunity to extend your pr51945 change (hunk below)
> to the whole loop.
This also fixes pr58023#c0. pr58023#c1 is fixed if I replace the following
hunks
@@ -12024,7 +12036,8 @@ resolve_fl_derived0 (gfc_symbol *sym)
gfc_error ("Component '%s' at %L with coarray component "
"shall be a nonpointer, nonallocatable scalar",
c->name, &c->loc);
- return false;
+ retval = false;
+ continue;
}
/* F2008, C448. */
@@ -12032,7 +12045,8 @@ resolve_fl_derived0 (gfc_symbol *sym)
{
gfc_error ("Component '%s' at %L has the CONTIGUOUS attribute but "
"is not an array pointer", c->name, &c->loc);
- return false;
+ retval = false;
+ continue;
}
if (c->attr.proc_pointer && c->ts.interface)
with
@@ -12031,16 +12035,20 @@ resolve_fl_derived0 (gfc_symbol *sym)
{
gfc_error ("Component '%s' at %L has the CONTIGUOUS attribute but "
"is not an array pointer", c->name, &c->loc);
- return false;
+ retval = false;
+ continue;
}
if (c->attr.proc_pointer && c->ts.interface)
{
gfc_symbol *ifc = c->ts.interface;
- if (!sym->attr.vtype
- && !check_proc_interface (ifc, &c->loc))
-return false;
+ if (!sym->attr.vtype && !check_proc_interface (ifc, &c->loc))
+{
+ c->tb->error = 1;
+ retval = false;
+ continue;
+}
if (ifc->attr.if_source || ifc->attr.intrinsic)
{
[Bug fortran/44978] derived types are resolved more than once
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44978 --- Comment #18 from Dominique d'Humieres --- Created attachment 30642 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30642&action=edit Differences between the errors printed with patches 30629 and 30633
[Bug rtl-optimization/57459] [4.8 Regression] LRA inheritance bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57459 --- Comment #8 from Jakub Jelinek --- Created attachment 30643 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30643&action=edit rh995446.i We've got this reported in https://bugzilla.redhat.com/show_bug.cgi?id=995446 too. I've created a self-contained executable testcase out of that. Vlad, can you please backport this to 4.8 branch or are there any issues that prevent it? I'll add the testcase to 4.8/trunk afterwards.
[Bug libstdc++/58148] New: [C++11] Fails to insert iterator range into sequence container with -D_GLIBCXX_DEBUG when conversion is needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58148
Bug ID: 58148
Summary: [C++11] Fails to insert iterator range into sequence
container with -D_GLIBCXX_DEBUG when conversion is
needed
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ai.azuma at gmail dot com
Created attachment 30644
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30644&action=edit
reproducing source code and output of -v option
The following valid code fails to compile with 4.9.0 20130804 and
`-D_GLIBCXX_DEBUG':
//
#include
int main()
{
std::vector v;
char c = 'a';
v.insert(v.begin(), &c, &c); // compile error
}
//
The above code successfully compiles with 4.9.0 20130728 and
`-D_GLIBCXX_DEBUG'. So this seems a regression, which has been introduced
between 20130728 and 20130804.
The same problem also occurs for `std::deque'.
Наш цех работы и обработки металла
Тел.8(3462)99-72-32; 8(3462)61-56-10; почта nagor...@mail.ru
[Bug libstdc++/58148] [C++11] Fails to insert iterator range into sequence container with -D_GLIBCXX_DEBUG when conversion is needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58148 --- Comment #1 from Paolo Carlini --- Francois, can you please have a look?
[Bug fortran/44978] derived types are resolved more than once
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44978 --- Comment #19 from Dominique d'Humieres --- Created attachment 30645 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30645&action=edit Test showing a spectacular improvement with both patches
[Bug tree-optimization/58137] [trunk, ICE] full unroll + AVX2 vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137 --- Comment #4 from Yukhin Kirill --- > Could some one check if the generated code is now correct ? Patch works both on attached AVX2 testcase and on root AVX-512 issue, thanks. I think it should be submitted to gcc-patches.
[Bug target/58067] ICE in GFortran recog.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
Created attachment 30646
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30646&action=edit
gnu largepic TLS
An attempt to handle -mcmodel=large -fpic TLS GD/LD in the compiler.
Seems to work for me on testcase like:
__thread int a;
static __thread int b;
int
foo ()
{
return a++ + b++;
}
int
main ()
{
return foo () + foo () - 2;
}
but unfortunately ld will fail if this code is being attempted to link into an
executable or PIE:
/usr/bin/ld: /tmp/ccWao1Is.o: TLS transition from R_X86_64_TLSGD to
R_X86_64_GOTTPOFF against `a' at 0x26 in section `.text' failed
/tmp/ccWao1Is.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
[Bug fortran/58007] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #5 from Mikael Morin --- I suppose the following is happening (based on Janus' test): - At the time bsr is use-associated we see references to matrix::sparse_matrix, but as the type has already been loaded, we redirect references to matrix::sparse_matrix to the one already loaded. See read_module, the code that comes after the comment: /* See if the symbol has already been loaded by a previous module. If so, we reference the existing symbol and prevent it from being loaded again. This should not happen if the symbol being read is an index for an assumed shape dummy array (ns != 1). */ - Normally, mio_component (called from mio_component_list, from mio_symbol) associates a component pointer to the corresponding pointer id so that it can be referenced in expressions for example. As the type is not loaded from file (see above) the association isn't done either. - get_neighbors contains an expression (in the result's array spec) referencing max_degree, one of matrix::sparse_matrix's components. Because of the above, the reference is not associated with the corresponding component pointer, and it leads to the internal error.
[Bug regression/55754] FAIL: gcc.target/arm/unsigned-extend-2.c scan-assembler ands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55754 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.8.0 --- Comment #4 from Ramana Radhakrishnan --- fixed for 4.8.0
[Bug rtl-optimization/57662] [4.9 Regression] ICE: SIGSEGV in code_motion_process_successors with -fschedule-insns2 -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57662 Andrey Belevantsev changed: What|Removed |Added Status|NEW |ASSIGNED CC||abel at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |abel at gcc dot gnu.org --- Comment #3 from Andrey Belevantsev --- I will take a look, but I will be on vacation in two days, so do not expect much on this until September.
[Bug tree-optimization/57980] [4.7/4.8/4.9 Regression] gcc 4.8.1 -foptimize-sibling-calls -O1 ICE in build_int_cst_wide, at tree.c:1210
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57980 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Tue Aug 13 13:34:08 2013 New Revision: 201687 URL: http://gcc.gnu.org/viewcvs?rev=201687&root=gcc&view=rev Log: 2013-08-13 Marek Polacek Jakub Jelinek PR tree-optimization/57980 * tree-tailcall.c (process_assignment): Return false when not dealing with integers or floats. * gcc.dg/pr57980.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr57980.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-tailcall.c
[Bug tree-optimization/57980] [4.7/4.8/4.9 Regression] gcc 4.8.1 -foptimize-sibling-calls -O1 ICE in build_int_cst_wide, at tree.c:1210
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57980 --- Comment #6 from Marek Polacek --- Author: mpolacek Date: Tue Aug 13 13:42:28 2013 New Revision: 201688 URL: http://gcc.gnu.org/viewcvs?rev=201688&root=gcc&view=rev Log: 2013-08-13 Marek Polacek Jakub Jelinek PR tree-optimization/57980 * tree-tailcall.c (process_assignment): Return false when not dealing with integers or floats. * gcc.dg/pr57980.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr57980.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-tailcall.c
[Bug tree-optimization/57980] [4.7/4.8/4.9 Regression] gcc 4.8.1 -foptimize-sibling-calls -O1 ICE in build_int_cst_wide, at tree.c:1210
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57980 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Fixed.
[Bug fortran/58146] Array slice bounds checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58146 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-13 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug fortran/44978] derived types are resolved more than once
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44978 --- Comment #20 from Dominique d'Humieres --- I have run my tests with the patch in comment #17. As expected it fixes pr58023#c1, but it also remove the duplicate error in pr43591.f90 and pr43591.f90:15.55: integer, dimension(physical%number_particles_out(), & 1 Error: Expression at (1) must be of INTEGER type, found UNKNOWN I am a little bit puzzled by this error. I think it is an attempt to emit if for physical%number_flavor_states(), but the error does not give the right locus (probably due to the continuation line). I don't understand why it is removed by the change and don't know how bad it is to remove it. My analysis for pr48095 has been to fast: there is no duplicate, but two different errors: pr48095.f90:7.79: procedure(get_area), pointer, pass(this) :: get_special_area => get_my_area 1 Error: Interface mismatch in procedure pointer assignment at (1): Type mismatch in argument 'this' (CLASS(rectangle)/TYPE(rectangle)) pr48095.f90:7.79: procedure(get_area), pointer, pass(this) :: get_special_area => get_my_area 1 Error: Interface mismatch for procedure-pointer component 'get_special_area' in structure constructor at (1): Type mismatch in argument 'this' (CLASS(rectangle)/TYPE(rectangle)) The locus for the second error should probably at the end of get_special_area. With the Mikael's patch + the change in comment #17, I have spotted two remaining duplicates: the test in comment #4 and gfortran.dg/spec_expr_6.f90. Indeed I have probably overlooked other cases (I have no idea on how to do an exhaustive search).
[Bug fortran/58100] Spurious "DO loop at (1) will be executed zero times" warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58100 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-13 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Still present after r201658 (pr5, after it -Wall is needed).
[Bug fortran/57924] -Werror -Warray-temporaries -Wno-error=array-temporaries fails on array temporary warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57924 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-13 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Confirmed.
[Bug preprocessor/57620] Phantom terminator confuses raw string literal parsing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57620 Jakub Jelinek changed: What|Removed |Added CC||bcmpinc at hotmail dot com --- Comment #6 from Jakub Jelinek --- *** Bug 52852 has been marked as a duplicate of this bug. ***
[Bug preprocessor/52852] [C++11] The preprocessor fails to parse multi-line c++0x/c++11 raw strings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52852 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 57620 ***
[Bug preprocessor/57824] Raw string literals not handled correctly in macro arguments or deferred pragmas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57824 Jakub Jelinek changed: What|Removed |Added CC||bcmpinc at hotmail dot com --- Comment #3 from Jakub Jelinek --- *** Bug 52852 has been marked as a duplicate of this bug. ***
[Bug preprocessor/52852] [C++11] The preprocessor fails to parse multi-line c++0x/c++11 raw strings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52852 --- Comment #3 from Jakub Jelinek --- *** This bug has been marked as a duplicate of bug 57824 ***
[Bug c++/51253] [C++11][DR 1030] Evaluation order (sequenced-before relation) among initializer-clauses in braced-init-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253 Broes De Cat changed: What|Removed |Added CC||broes.decat at gmail dot com --- Comment #3 from Broes De Cat --- Confirmed, hit the bug with 4.7.3 in c++11 mode.
[Bug c++/58083] [4.8/4.9 Regression] ICE with lambda as default parameter of a template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58083 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #3 from Daniel Krügler --- For gcc 4.9.0 20130616 (experimental) I got: "main.cpp|18|internal compiler error: in push_class_level_binding_1, at cp/name-lookup.c:3067" on my mingw 64 bit system
[Bug tree-optimization/58010] [4.8/4.9 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4378
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- With -O2 -funswitch-loops -fvectorize -fno-vect-const-model it started with r178728 . Richard, when you are back, can you please look at this?
[Bug middle-end/56417] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56417 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Tue Aug 13 16:58:46 2013 New Revision: 201696 URL: http://gcc.gnu.org/viewcvs?rev=201696&root=gcc&view=rev Log: PR sanitizer/56417 * asan.c (instrument_strlen_call): Fix typo in comment. Use char * type even for the lhs of POINTER_PLUS_EXPR. * gcc.dg/asan/pr56417.c: New test. Added: trunk/gcc/testsuite/gcc.dg/asan/pr56417.c Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c trunk/gcc/testsuite/ChangeLog Author: jakub Date: Tue Aug 13 17:02:13 2013 New Revision: 201697 URL: http://gcc.gnu.org/viewcvs?rev=201697&root=gcc&view=rev Log: PR sanitizer/56417 * asan.c (instrument_strlen_call): Fix typo in comment. Use char * type even for the lhs of POINTER_PLUS_EXPR. * gcc.dg/asan/pr56417.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/asan/pr56417.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/asan.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/57661] [4.9 Regression] ICE: SIGSEGV in verify_ssa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57661 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Tue Aug 13 17:06:13 2013 New Revision: 201698 URL: http://gcc.gnu.org/viewcvs?rev=201698&root=gcc&view=rev Log: PR tree-optimization/57661 * tree-inline.h (struct copy_body_data): Add blocks_to_copy field. * tree-inline.c (tree_function_versioning): Initialize it. (remap_gimple_stmt): Return GIMPLE_NOP for MEM_REF lhs clobber stmts if id->blocks_to_copy and MEM_REF's SSA_NAME is defined in a block that is not being copied. * g++.dg/opt/pr57661.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr57661.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c trunk/gcc/tree-inline.h
[Bug fortran/58146] Array slice bounds checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58146 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- Created attachment 30647 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30647&action=edit Proposed patch This should work for a compile-time check, where this is possible.
[Bug bootstrap/58149] New: GCC4.8.1 fails on OS X 10.8.4, 'pointer_t' error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58149
Bug ID: 58149
Summary: GCC4.8.1 fails on OS X 10.8.4, 'pointer_t' error
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: eleonora.in.washingtondc at gmail dot com
Here it is the log file:
info:build ../../gcc-4.8.1/gcc/fortran/module.c:110:1: error: conflicting
declaration 'typedef enum pointer_t pointer_t'
:info:build pointer_t;
:info:build ^
:info:build In file included from /usr/include/mach/memory_object_types.h:77:0,
:info:build from /usr/include/mach/mach_types.h:85,
:info:build from
/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_lang_gcc48/libgcc/work/build/prev-gcc/include-fixed/malloc.h:37,
:info:build from ../../gcc-4.8.1/gcc/system.h:460,
:info:build from ../../gcc-4.8.1/gcc/fortran/module.c:68:
:info:build /usr/include/mach/vm_types.h:40:26: error: 'pointer_t' has a
previous declaration as 'typedef vm_offset_t pointer_t'
:info:build typedef vm_offset_t pointer_t;
:info:build ^
:info:build make[3]: *** [fortran/module.o] Error 1
:info:build make[3]: *** Waiting for unfinished jobs
:info:build rm gfortran.pod gcc.pod
:info:build make[3]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_lang_gcc48/libgcc/work/build/gcc'
:info:build make[2]: *** [all-stage2-gcc] Error 2
:info:build make[2]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_lang_gcc48/libgcc/work/build'
:info:build make[1]: *** [stage2-bubble] Error 2
:info:build make[1]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_lang_gcc48/libgcc/work/build'
:info:build make: *** [bootstrap] Error 2
:info:build make: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_lang_gcc48/libgcc/work/build'
:info:build Command failed: cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_lang_gcc48/libgcc/work/build"
&& /usr/bin/make -j4 -w bootstrap
:info:build Exit code: 2
:error:build org.macports.build for port libgcc returned: command execution
failed
:debug:build Error code: CHILDSTATUS 10697 2
:debug:build Backtrace: command execution failed
while executing
"system -nice 0 $fullcmdstring"
("eval" body line 1)
invoked from within
"eval system $notty $nice \$fullcmdstring"
invoked from within
"command_exec build"
(procedure "portbuild::build_main" line 8)
invoked from within
"$procedure $targetname"
:info:build Warning: targets not executed for libgcc: org.macports.activate
org.macports.build org.macports.destroot org.macports.install
:notice:build Please see the log file for port libgcc for details:
/opt/local/var/macports/logs/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_lang_gcc48/libgcc/main.log
[Bug fortran/58146] Array slice bounds checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58146 --- Comment #3 from Thomas Koenig --- Actually, the patch doesn't work (yet). Working on it.
[Bug middle-end/58145] [Regression]: volatileness of write is discarded, perhaps in "lim1" related to loop optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 30648 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30648&action=edit untested fix Seems to be a tree-sra.c bug to me. Untested fix attached, with no testcase yet etc.
[Bug debug/58150] New: debug info about definition of enum class not emitted if the declaration was already used in a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58150 Bug ID: 58150 Summary: debug info about definition of enum class not emitted if the declaration was already used in a template Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: b.r.longbons at gmail dot com Created attachment 30649 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30649&action=edit minimal testcase If an enum class has a forward declaration and it is used as a class member (functions seem to be okay), the full debuginfo is not emitted when the definition appear later in the TU. This makes debugging practically impossible. enums are unusual in that they can be fully used even when they have just a definition. Tested gcc versions: g++-4.6 (Debian 4.6.4-2) 4.6.4 g++-4.7 (Debian 4.7.3-4) 4.7.3 g++-4.8 (Debian 4.8.1-8) 4.8.1 Versions before 4.6 did not implement forward declarations of enum classes, so this bug is primordial. The relevant part of the debug information looks like: <1><34>: Abbrev Number: 3 (DW_TAG_enumeration_type) <35> DW_AT_name: (indirect string, offset: 0x84): ByteCode <39> DW_AT_enum_class : 1 <39> DW_AT_declaration : 1 <39> DW_AT_byte_size : 1 <3a> DW_AT_decl_file : 1 <3b> DW_AT_decl_line : 3 Whereas clang generates: <1><6f>: Abbrev Number: 6 (DW_TAG_enumeration_type) <70> DW_AT_type: <0x64> <74> DW_AT_enum_class : 1 <75> DW_AT_name: (indirect string, offset: 0x98): ByteCode <79> DW_AT_byte_size : 1 <7a> DW_AT_decl_file : 1 <7b> DW_AT_decl_line : 10
[Bug target/58105] wrong code generation for multiversioned functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58105 --- Comment #3 from Bernd Edlinger --- Patch was posted here: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00770.html
[Bug c/50584] No warning for passing small array to C99 static array declarator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584 Malcolm Inglis changed: What|Removed |Added CC||me at minglis dot id.au --- Comment #2 from Malcolm Inglis --- GCC 4.8.1 is still failing to warn for static array indices in function parameters. The C99 status pages say this feature has been done since 3.1: http://gcc.gnu.org/gcc-3.1/c99status.html Was there a regression?
[Bug rtl-optimization/57662] [4.9 Regression] ICE: SIGSEGV in code_motion_process_successors with -fschedule-insns2 -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57662 --- Comment #4 from Andrey Belevantsev --- Created attachment 30650 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30650&action=edit proposed patch When moving up an instruction, we can make empty basic blocks or create other possibilities for control flow simplification, thus we do it along the way. This means that while we are in the iterator over successor blocks, those blocks could change, and we need to rescan successors to make sure we visit all of them. We do that with checking whether the number of successor blocks of the visiting block changed or the visiting block index itself changed, and we get hold of the visiting block via its last insn. Now, the problem is that this last insn itself can be removed during simplification. I have convinced myself that only case when this might happen is when the insn is an unconditional jump (the conditional jump might be changed to unconditional but not removed altogether). In this case we had a single successor and we have already visited it, so we just break from the successor iterator instead of attempting to rescan. I will test the attached patch and submit if succesful.
