[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 --- Comment #18 from Anitha Boyapati 2011-06-14 07:00:45 UTC --- (In reply to comment #17) > Created attachment 24512 [details] > loosen constraints on register elimination > > This seems to fix the problem. At least for this small test case. I think there are 2 issues here. The first issue deals with avr-gcc which was built without dwarf2 support. The second issue (comment #1 onwards) deals with avr build errors. Maybe we should separate them. > A full build for AVR fails, but that seems to be related to other > open bugs. Please let me know if any other known bugs exist with regarding to build failure. AFAIK, there are some open PRs for emitting CFI information but not for build failures (Bug #44643 is fixed) But the current 4.6.0 build is without CFI support, which is possible as CFI is optional. As far as I have analyzed, AVR build with DWARF2 support fails with the reasons discussed in comment #3 (and later on). All the changes were made in 4.6.0 release. Since the build is known to pass in 4.5.x release, this is a regression. And I think we need to address these issues as part of this bug.
[Bug target/48542] mmix code which calls setjmp/longjmp may not work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48542 --- Comment #5 from Hans-Peter Nilsson 2011-06-14 07:02:02 UTC --- (In reply to comment #4) > on trunk: the > initial-value machinery should have handled the register with the > return-address being clobbered. It does partially; note the store of that > register at the function prologue (with an unpatched gcc). Yep, it's (brr) reload. I'll attach a patch momentarily. I'll have to finish my analysis and do a mmix regtest and a hosted regtest before posting.
[Bug c++/49399] New: [C++0x] substitution failure error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399 Summary: [C++0x] substitution failure error Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jarr...@cse.unsw.edu.au Created attachment 24515 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24515 substitution failure When accessing a private member of a class in a substitution failure is not an error sort of way, the compiler reports an error. Compiling the attached code gives the following: g++ --std=c++0x value_type.cpp value_type.cpp: In function ‘int broken_fun(int, typename T::value_type*) [with T = broken, typename T::value_type = int]’: value_type.cpp:4:15: error: ‘typedef int broken::value_type’ is private value_type.cpp:14:37: error: within this context It works fine without c++0x mode, and on previous versions of gcc. output of gcc -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/home/jarryd/local/gcc-4.7/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/jarryd/installers/gcc-svn/configure --prefix=/home/jarryd/local/gcc-4.7 --disable-multilib --enable-languages=c,c++,go Thread model: posix gcc version 4.7.0 20110614 (experimental) (GCC)
[Bug target/48542] mmix code which calls setjmp/longjmp may not work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48542 Hans-Peter Nilsson changed: What|Removed |Added Attachment #23938|0 |1 is obsolete|| --- Comment #6 from Hans-Peter Nilsson 2011-06-14 07:12:04 UTC --- Created attachment 24516 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24516 Fix for trunk and maybe branches Patch against trunk r174961. Fixes in two places (reload.c:find_equiv_reg and reload1.c:reload_as_needed) are necessary, because when register contents is invalidated for the main path (the patch to reload1.c), there's fallback code that also iterates over code, and which also lacks proper handling of setjmp-type calls. So, you can see this bug on other targets if you're "unlucky" enough to write code that need reloads and which seems reusable across a setjmp-call. This just naturally happens more often for mmix (like always), given that (set rJ (mem ...)) is emitted after every call and always needs a reload through a general register, and is always reloaded from the same mem. (Tentative partial analysis.)
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #10 from Mikael Pettersson 2011-06-14 08:12:54 UTC --- (In reply to comment #9) > > - __gnat_malloc is defined in Ada to return Address (integer, so in d0), but > > it's called from a couple of places via fake "extern" declarations that > > pretend > > it returns void* (pointer, so in a0). The attached patch fixes the two call > > sites affected (in Interfaces.C.Strings and build_call_alloc_dealloc), as > > well > > as the internal fake prototype (init_gigi_decls). > > - Source code inspection showed that get_jmpbuf_address probably suffers > > from > > the same issue (mismatching decl and use via wrong intermediate fake > > prototype) > > so I fixed that too. > > I don't think that we want __gnat_malloc to return anything else than a > pointer > in the GCC representation. Its DECL node is DECL_IS_MALLOC and had better > mimic a canonical malloc as much as possible. In that case the Ada side of __gnat_malloc has to be changed to use a pointer type rather than Address. Is Interfaces.C.Strings.chars_ptr acceptible, or is there a better approximation for void* somewhere? > Andreas mentioned a compatibility trick in comment #6. How is it implemented? The effect is that a pointer-valued callee returns its value in both %a0 and %d0. A caller that has seen the pointer-valued prototype picks up the value from %a0, but a caller that hasn't seen that prototype picks it up from %d0. The actual implementation is in m68k_function_value.
[Bug c++/49399] [C++0x] substitution failure error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399 --- Comment #1 from Jonathan Wakely 2011-06-14 08:15:14 UTC --- when you say "works fine" do you mean "doesn't do the access check"? surely if SFINAE correctly honours access control then the function shouldn't be callable and the program won't compile
[Bug fortran/49400] New: Proc-pointer declaration in BLOCK construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49400 Summary: Proc-pointer declaration in BLOCK construct Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org, do...@gcc.gnu.org Follow up to PR 49397. The following code should be parsed correctly. Currently, one gets: test.f90:8.8: Procedure(Real),Pointer :: p 1 Error: Unclassifiable statement at (1) (Regarding the validity, cf. also PR 49397 and IR J3/11-198.) Program m5 Call s Contains Subroutine s Print *,g() block Procedure(Real),Pointer :: p p => g Print *,p() end block End Subroutine End Program Function g() g = 2 End Function
[Bug fortran/49397] ICE with proc pointer assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49397
--- Comment #1 from Tobias Burnus 2011-06-14
08:27:44 UTC ---
More information:
* (2): Case "g" works: If the "print *, g()" as the "p => g" is in the same
scoping unit, there is no error or ICE.
* (1) If the "print *, f" is in the host of "p => f", there is an ICE.
* (example (3) works - thus not shown, cf. IR 11-198).
My impression is that the error message is OK, but that the assert is wrong. If
you change the assert, please make sure it works also with additional nesting
due to BLOCK (cf. PR 49400).
The failing assert is:
1774 /* Allow only one nesting level. Allow public declarations. */
1775 gcc_assert (current_function_decl == NULL_TREE
1776 || DECL_FILE_SCOPE_P (current_function_decl)
1777 || (TREE_CODE (DECL_CONTEXT (current_function_decl))
1778 == NAMESPACE_DECL));
The check leading to the error message is generated in
gfc_check_pointer_assign:
3349 attr = gfc_expr_attr (rvalue);
3350 if (!((rvalue->expr_type == EXPR_NULL)
3351 || (rvalue->expr_type == EXPR_FUNCTION && attr.proc_pointer)
3352 || (rvalue->expr_type == EXPR_VARIABLE && attr.proc_pointer)
3353 || (rvalue->expr_type == EXPR_VARIABLE
3354 && attr.flavor == FL_PROCEDURE)))
3355 {
3356 gfc_error ("Invalid procedure pointer assignment at %L",
3357 &rvalue->where);
3358 return FAILURE;
3359 }
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #11 from Eric Botcazou 2011-06-14 08:44:12 UTC --- > In that case the Ada side of __gnat_malloc has to be changed to use a pointer > type rather than Address. Is Interfaces.C.Strings.chars_ptr acceptible, or is > there a better approximation for void* somewhere? The problem is that pointers drag a heavy machinery in Ada (to make it impossible to introduce the dangling sub-species) so low-level routines don't really want to use pointers, as they (are supposed to) know what they are doing. > The effect is that a pointer-valued callee returns its value in both %a0 and > %d0. A caller that has seen the pointer-valued prototype picks up the value > from %a0, but a caller that hasn't seen that prototype picks it up from %d0. I see, thanks. What about creating a machine-specific attribute, tentatively named "pointer return", that a m68k-specific version of s-memory.ads would put on the problematic functions? GNAT already supports machine-specific attributes. The effect would be the same as the one implemented in m68k_function_value.
[Bug other/49401] New: Warning regression for 'uninitialized' variable on non-existant code path (in mep-pragma.c)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49401 Summary: Warning regression for 'uninitialized' variable on non-existant code path (in mep-pragma.c) Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: build, diagnostic Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org Blocks: 44756 Host: x86_64-unknown-linux-gnu Created attachment 24517 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24517 Preprocessed source file GCC 4.7.0 20110613 (experimental) (revision 174993) warns about a construct in mep-pragma.c which was fine with 4.7.0 20110412. An if clause tests if a variable is within a particular range, and then has a switch that initialized another variable for each possible value of the first variable in the tested-for range. GCC 4.7.0 20110613 now says that the second variable might be uninitialized. amylaar@gcc20:~/pr46489/jun13/multi2/mep-elf/gcc$ /home/amylaar/inst/20110412/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/cc1 -fpreprocessed mep-pragma.i -quiet -dumpbase mep-pragma.c -mtune=generic -march=x86-64 -auxbase mep-pragma -g -O2 -Wextra -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -version -fno-common -o mep-pragma.s GNU C (GCC) version 4.7.0 20110412 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.0 20110412 (experimental), GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.7.0 20110412 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.0 20110412 (experimental), GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 41657c4e14ab8d46a76879065321da34 amylaar@gcc20:~/pr46489/jun13/multi2/mep-elf/gcc$ echo $? 0 amylaar@gcc20:~/pr46489/jun13/multi2/mep-elf/gcc$ /home/amylaar/inst/20110613/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/cc1 -fpreprocessed mep-pragma.i -quiet -dumpbase mep-pragma.c -mtune=generic -march=x86-64 -auxbase mep-pragma -g -O2 -Wextra -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -version -fno-common -o mep-pragma.s GNU C (GCC) version 4.7.0 20110613 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.0 20110613 (experimental), GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.7.0 20110613 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.0 20110613 (experimental), GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 843a960cd48831f97b6a22dedb2d6c40 ../../../gcc/gcc/config/mep/mep-pragma.c: In function ‘mep_pragma_coprocessor’: ../../../gcc/gcc/config/mep/mep-pragma.c:298:54: error: ‘rclass’ may be used uninitialized in this function [-Werror=maybe-uninitialized] ../../../gcc/gcc/config/mep/mep-pragma.c:271:18: note: ‘rclass’ was declared here cc1: all warnings being treated as errors
[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 Georg-Johann Lay changed: What|Removed |Added Target Milestone|4.7.0 |4.6.1
[Bug target/49402] New: Duplicate use of v850.opt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49402 Summary: Duplicate use of v850.opt Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org CC: ni...@redhat.com Blocks: 47093 Target: v850-elf gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../../gcc/gcc -I../../../gcc/gcc/build -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber\ -o build/genflags.o ../../../gcc/gcc/genflags.c In file included from ./tm.h:14:0, from ../../../gcc/gcc/genflags.c:27: ./options.h:3422:0: error: "MASK_US_BIT_SET" redefined [-Werror] ./options.h:3421:0: note: this is the location of the previous definition ./options.h:3424:0: error: "MASK_APP_REGS" redefined [-Werror] ./options.h:3423:0: note: this is the location of the previous definition ./options.h:3426:0: error: "MASK_BIG_SWITCH" redefined [-Werror] ./options.h:3425:0: note: this is the location of the previous definition ./options.h:3428:0: error: "MASK_DEBUG" redefined [-Werror] ./options.h:3427:0: note: this is the location of the previous definition ./options.h:3430:0: error: "MASK_DISABLE_CALLT" redefined [-Werror] ./options.h:3429:0: note: this is the location of the previous definition ./options.h:3432:0: error: "MASK_EP" redefined [-Werror] ./options.h:3431:0: note: this is the location of the previous definition ./options.h:3434:0: error: "MASK_GHS" redefined [-Werror] ./options.h:3433:0: note: this is the location of the previous definition The v850-elf build fails with: ./options.h:3436:0: error: "MASK_JUMP_TABLES_IN_DATA_SECTION" redefined [-Werror] ./options.h:3435:0: note: this is the location of the previous definition ./options.h:3438:0: error: "MASK_LONG_CALLS" redefined [-Werror] ./options.h:3437:0: note: this is the location of the previous definition ./options.h:3440:0: error: "MASK_NO_STRICT_ALIGN" redefined [-Werror] ./options.h:3439:0: note: this is the location of the previous definition ./options.h:3442:0: error: "MASK_PROLOG_FUNCTION" redefined [-Werror] ./options.h:3441:0: note: this is the location of the previous definition ./options.h:3444:0: error: "MASK_SMALL_SLD" redefined [-Werror] ./options.h:3443:0: note: this is the location of the previous definition ./options.h:3446:0: error: "MASK_V850" redefined [-Werror] ./options.h:3445:0: note: this is the location of the previous definition ./options.h:3448:0: error: "MASK_V850E" redefined [-Werror] ./options.h:3447:0: note: this is the location of the previous definition ./options.h:3450:0: error: "MASK_V850E1" redefined [-Werror] ./options.h:3449:0: note: this is the location of the previous definition ./options.h:3452:0: error: "MASK_V850E2" redefined [-Werror] ./options.h:3451:0: note: this is the location of the previous definition ./options.h:3454:0: error: "MASK_V850E2V3" redefined [-Werror] ./options.h:3453:0: note: this is the location of the previous definition ./options.h:3455:2: error: #error too many target masks cc1: all warnings being treated as errors make[2]: *** [build/genflags.o] Error 1 I see that v850.opt ends up being used twice: amylaar@gcc20:~/pr46489/jun13/multi2/v850-elf/gcc$ grep 'v850\.opt' * config.log:extra_opt_files=' $(srcdir)/config/v850/v850.opt $(srcdir)/config/v850/v850.opt' config.status:S["extra_opt_files"]=" $(srcdir)/config/v850/v850.opt $(srcdir)/config/v850/v850.opt" Makefile:extra_opt_files= $(srcdir)/config/v850/v850.opt $(srcdir)/config/v850/v850.opt
[Bug target/49403] New: v850e-elf: incompatible pointer type (near initialization for ‘targetm.memory_move_cost’)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49403 Summary: v850e-elf: incompatible pointer type (near initialization for ‘targetm.memory_move_cost’) Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org CC: ni...@redhat.com Blocks: 44756 Target: v850e-elf The v850e-elf build fails with: gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber\ ../../../gcc/gcc/config/v850/v850.c -o v850.o ../../../gcc/gcc/config/v850/v850.c:3283:8: error: initialization from incompatible pointer type [-Werror] ../../../gcc/gcc/config/v850/v850.c:3283:8: error: (near initialization for ‘targetm.memory_move_cost’) [-Werror] cc1: all warnings being treated as errors make[2]: *** [v850.o] Error 1
[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 Georg-Johann Lay changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #19 from Georg-Johann Lay 2011-06-14 09:46:21 UTC --- (In reply to comment #17) > A full build for AVR fails, but that seems to be related to other > open bugs. What bugs? I can build avr-gcc SVN 175011 from today without problems on i686-pc-linux-gnu + gcc 4.3.2. Target: avr Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.7 --disable-nls --disable-shared --enable-languages=c,c++ Thread model: single gcc version 4.7.0 20110614 (experimental) (GCC) GNU assembler version 2.21 (avr) using BFD version (GNU Binutils) 2.21 GMP 5.0.1 MPFR 3.0.0 MPC 0.8.2
[Bug debug/49382] -O2 -g: DW_AT_location at the very first PC is already modified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49382 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.14 10:28:52 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Jakub Jelinek 2011-06-14 10:28:52 UTC --- Created attachment 24518 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24518 gcc47-pr49382.patch Untested patch to implement that.
[Bug tree-optimization/49365] 436.cactusADM performance regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49365 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.14 10:49:14 CC||changpeng.fang at amd dot ||com Ever Confirmed|0 |1 --- Comment #4 from Richard Guenther 2011-06-14 10:49:14 UTC --- Indeed, for the important loop in StaggeredLeapfrog2.F we now have Ahead 1, unroll factor 1, trip count -1 insn count 919, mem ref count 100, prefetch count 100 Not prefetching -- instruction to prefetch ratio (9) too small while before the patch we had insn count 1019, mem ref count 100, prefetch count 100 as we now have half the cost for the vectorized mem-refs (100 instead of 200). Building with --param min-insn-to-prefetch-ratio=9 fixes it.
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #12 from Thorsten Glaser 2011-06-14 10:59:03 UTC --- Why not patch the frontend to magically make System.Address a pointer type for the backend to deal with? That way, no functions have to be changed, and potential other targets with “weird” calling conventions immediately share in the benefit. As for the “compatibility trick”, it works the other way around, only when a pointer-returning function is called expecting integers. Here, we have an integer-returning function by mistake.
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #13 from Eric Botcazou 2011-06-14 11:27:24 UTC --- > Why not patch the frontend to magically make System.Address a pointer type for > the backend to deal with? That way, no functions have to be changed, and > potential other targets with “weird” calling conventions immediately share in > the benefit. Let's be clear: changing the Ada front-end because of weird ABIs on little-used platforms is pretty much out of question; this issue only arises on m68k AFAIK. > As for the “compatibility trick”, it works the other way around, only when a > pointer-returning function is called expecting integers. Here, we have an > integer-returning function by mistake. Right, that's precisely why I proposed the attribute.
[Bug target/49392] [arm] spurious EABI version mismatches when LTO enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49392 --- Comment #1 from Ramana Radhakrishnan 2011-06-14 11:31:55 UTC --- It looks like a linker error but ... Hmmm with a later version of gcc 4.6 branch that I have lying around the same example doesn't spew out such error messages. I don't have a 4.6.0 build handy to try this. I seem to be running binutils 2.21.51.20110525 FTR. cheers Ramana
[Bug c++/49399] [C++0x] substitution failure error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399 --- Comment #2 from Jarryd Beck 2011-06-14 11:52:58 UTC --- By works fine I mean that the code compiles, and when it runs, the program returns the number 4. Maybe I'm misunderstanding how this is all supposed to work and something has changed in the spec meaning that this is now broken. However that would mean boost is broken too (quite possible). It comes from BOOST_MPL_HAS_XXX_TRAIT_DEF. They use it to work out if a class has a particular member defined. It has been working fine up until recently when it broke with C++0x.
[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
Paolo Carlini changed:
What|Removed |Added
CC||daniel.kruegler at
||googlemail dot com
--- Comment #16 from Paolo Carlini 2011-06-14
12:04:56 UTC ---
I had another look at this issue. Something I didn't realize at the time is
that simply adding begin() and end() overloads taking a const _Expr& is not
going to work in practice for the usages we care about, like the range-based
for-loop, unless one manages somehow to pass the *same* temporary _Expr to
both. I think we have an issue with that, I don't know if it's in the specs of
the range-based for-loop vs the valarray case at issue, or just in the GCC
implementation of the latter. Anyway, if I add the overloads:
template
inline const _Tp*
begin(const _Expr<_Clos, _Tp>& __ex)
{ return std::__addressof(__ex()[0]); }
template
inline const _Tp*
end(const _Expr<_Clos, _Tp>& __ex)
{ return std::__addressof(__ex()[0]) + __ex.size(); }
Then, the snippet:
std::valarray v1{ 0, 1, 2, 3, 4 }, v2{ 5, 6, 7, 8, 9};
for (int i : v1 + v2)
{ std::cout << i << std::endl; }
compiles but then misbehaves at compile-time, per valgrind too: apparently we
don't have a proper range. Note that the following misbehaves exactly in the
*same way*, and this appears to support my conjecture that we have a problem
somewhere with two different temporary _Expr passed to the begin and end
overloads:
for (auto b = std::begin(v1 + v2), e = std::end(v1 + v2); b < e; ++b)
{ std::cout << *b << std::endl; }
Maybe we should somehow point out this specific point in LWG 2058?
[Bug c++/49399] [C++0x] substitution failure error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399
--- Comment #3 from Jonathan Wakely 2011-06-14
12:11:05 UTC ---
The program should not compile.
In C++03 it should fail to compile because it accesses a private member. SFINAE
does not take access control into account in C++03, so that is an error. G++
fails to reject the program because access checking in templates is buggy.
There was a last minute change in the C++0x FDIS to make SFINAE consider access
control. The previous draft
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf) says in
section 14.8.2 [temp.deduct] p8 "Access checking is not done as part of the
substitution process. Consequently, when deduction succeeds, an access error
could still result when the function is instantiated."
That was changed in the FDIS, so accessing the private member should cause
deduction to fail, so there is no broken_fun and the call to it in main should
fail. G++ 4.7 doesn't implement that change yet, so rejects the program for
the wrong reason.
If you had a second, less specific, overload of broken_fun then the program
would still be invalid in C++03 but should be well-formed in C++0x. G++ doesn't
accept it because access checking is not done as part of the substitution
process yet.
e.g. this is valid C++0x
struct broken
{
private:
typedef int value_type;
};
template
int
broken_fun(int, typename T::value_type* = 0);
template
char
broken_fun(...);
int main(int argc, char* argv[])
{
return sizeof(broken_fun(5));
}
[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #17 from Daniel Krügler 2011-06-14 12:20:21 UTC --- (In reply to comment #16) > I had another look at this issue. Something I didn't realize at the time is > that simply adding begin() and end() overloads taking a const _Expr& is not > going to work in practice for the usages we care about, like the range-based > for-loop, unless one manages somehow to pass the *same* temporary _Expr to > both. [..] > Maybe we should somehow point out this specific point in LWG 2058? I think that Gaby has expressed exactly this problem in the discussion around LWG 2058, therefore I would suggest to add an exclusion sentence to [valarray.syn] p4 in regard to the begin/end overloads. I don't think that the library should support more than the most simple use-case in regard to valarray range support.
[Bug c++/49399] [C++0x] substitution failure error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399
--- Comment #4 from Jarryd Beck 2011-06-14
12:21:15 UTC ---
(In reply to comment #3)
> The program should not compile.
>
> In C++03 it should fail to compile because it accesses a private member.
> SFINAE
> does not take access control into account in C++03, so that is an error. G++
> fails to reject the program because access checking in templates is buggy.
>
> There was a last minute change in the C++0x FDIS to make SFINAE consider
> access
> control. The previous draft
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf) says in
> section 14.8.2 [temp.deduct] p8 "Access checking is not done as part of the
> substitution process. Consequently, when deduction succeeds, an access error
> could still result when the function is instantiated."
> That was changed in the FDIS, so accessing the private member should cause
> deduction to fail, so there is no broken_fun and the call to it in main should
> fail. G++ 4.7 doesn't implement that change yet, so rejects the program for
> the wrong reason.
>
> If you had a second, less specific, overload of broken_fun then the program
> would still be invalid in C++03 but should be well-formed in C++0x. G++
> doesn't
> accept it because access checking is not done as part of the substitution
> process yet.
>
> e.g. this is valid C++0x
>
> struct broken
> {
> private:
> typedef int value_type;
> };
>
> template
> int
> broken_fun(int, typename T::value_type* = 0);
>
> template
> char
> broken_fun(...);
>
> int main(int argc, char* argv[])
> {
>
> return sizeof(broken_fun(5));
> }
Ah, I see. Well the example you gave also doesn't compile. This is exactly what
the boost library does too, I missed that part in their code, meaning that
parts of boost no longer compile with gcc 4.7.
[Bug c++/49399] [C++0x] substitution failure error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399 --- Comment #5 from Jonathan Wakely 2011-06-14 12:27:35 UTC --- Then they never should have compiled in the first place, and won't compile with clang or Comeau either. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1170 is the relevant DR
[Bug rtl-optimization/49390] [4.6/4.7 Regression] GCSE miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49390 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.14 12:29:44 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/49399] [C++0x] substitution failure error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399 --- Comment #6 from Jonathan Wakely 2011-06-14 12:30:06 UTC --- (In reply to comment #4) > Ah, I see. Well the example you gave also doesn't compile. This is exactly > what > the boost library does too, I missed that part in their code, meaning that > parts of boost no longer compile with gcc 4.7. And I know it doesn't, as I said "G++ doesn't accept it because access checking is not done as part of the substitution process yet." Even when that's done, it will only be valid C++0x not, C++03.
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278 --- Comment #6 from Tobias Burnus 2011-06-14 12:32:02 UTC --- I have now filled an interpretation request (J3/11-201) - in time for WG5 and J3 meeting (m195), which is end of June. Let's see what J3/WG5 will decide. Cf. http://j3-fortran.org/doc/meeting/195/11-201.txt [Remember: Updates will be put in files named "11-201r1.txt", ...r2.txt, etc.]
[Bug driver/49178] [4.6/4.7 Regression] Space between linker option and library in gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49178 Jakub Jelinek changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME
[Bug c++/49399] [C++0x] substitution failure error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399 --- Comment #7 from Jarryd Beck 2011-06-14 12:34:35 UTC --- (In reply to comment #6) > (In reply to comment #4) > > Ah, I see. Well the example you gave also doesn't compile. This is exactly > > what > > the boost library does too, I missed that part in their code, meaning that > > parts of boost no longer compile with gcc 4.7. > > And I know it doesn't, as I said "G++ doesn't accept it because access > checking > is not done as part of the substitution process yet." > > Even when that's done, it will only be valid C++0x not, C++03. Ok, I thought that was what you meant. Does this however mean that this bug is now valid for C++0x, given what they say in the link that you gave? "If a substitution results in an invalid type or expression, type deduction fails. An invalid type or expression is one that would be ill-formed if written using the substituted arguments. [Note: Access checking is not done as part of the substitution process. —end note]" Should a bug for the reverse also be filed for the C++03 part of gcc? I wonder what boost mpl people would say about a bug report since this actually works even though it's wrong...
[Bug c++/49399] [C++0x] substitution failure error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399 --- Comment #8 from Jarryd Beck 2011-06-14 12:35:31 UTC --- (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #4) > > > Ah, I see. Well the example you gave also doesn't compile. This is > > > exactly what > > > the boost library does too, I missed that part in their code, meaning that > > > parts of boost no longer compile with gcc 4.7. > > > > And I know it doesn't, as I said "G++ doesn't accept it because access > > checking > > is not done as part of the substitution process yet." > > > > Even when that's done, it will only be valid C++0x not, C++03. > > Ok, I thought that was what you meant. Does this however mean that this bug is > now valid for C++0x, given what they say in the link that you gave? > > "If a substitution results in an invalid type or expression, type deduction > fails. An invalid type or expression is one that would be ill-formed if > written > using the substituted arguments. [Note: Access checking is not done as part of > the substitution process. —end note]" > > Should a bug for the reverse also be filed for the C++03 part of gcc? I wonder > what boost mpl people would say about a bug report since this actually works > even though it's wrong... Sorry that should be access checking is done. This text entry didn't preserve the strike through of the not.
[Bug target/49392] [arm] spurious EABI version mismatches when LTO enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49392 --- Comment #2 from Richard Guenther 2011-06-14 12:40:03 UTC --- There wasn't any change on the branch that would change this.
[Bug c++/49399] [C++0x] substitution failure error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399 --- Comment #9 from Jonathan Wakely 2011-06-14 12:40:52 UTC --- Note that returning 4 was *never* correct for that program. In C++03 it shouldn't compile and in C++0x it should return 1. There's a bug in the Boost.MPL docs which should say the macro works for *public* nested type member x::name and cannot be used if the name is not accessible (and if you report that you might as well also report the docs keep saying "memeber") There are already several bug reports for G++ not doing access checking correctly in templates, no need to report another one. You could consider it a bug that the resolution of DR1170 isn't implemented yet, but it's a known missing feature that simply hasn't been implemented yet.
[Bug tree-optimization/49367] missed optimization with __restrict field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49367 --- Comment #3 from Richard Guenther 2011-06-14 12:44:35 UTC --- The last example is because with a restrict qualified loaded pointer the later conversion to a restrict qualified pointer is thrown away. As for the first example the only case that would work is by passing the argument in a way that the FE sets DECL_BY_REFERENCE and uses a restrict qualified pointer for it. Which it does when the source passes it by value I think. That's the only case where we can assume something about the pointed-to type.
[Bug middle-end/49394] [4.7 Regression] libstdc++-v3/testsuite/30_threads/lock_guard/cons/1.cc FAILs with -fipa-pta -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49394
Richard Guenther changed:
What|Removed |Added
Target Milestone|--- |4.7.0
--- Comment #1 from Richard Guenther 2011-06-14
12:45:43 UTC ---
Maybe related to the g++.dg/torture/pr43879-1_1.C FAIL. Fix for that:
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c (revision 175011)
+++ tree-ssa-structalias.c (working copy)
@@ -3925,8 +3925,14 @@ handle_pure_call (gimple stmt, VEC(ce_s,
static varinfo_t
get_fi_for_callee (gimple call)
{
- tree decl, fn = gimple_call_fn (call);
+ tree decl, fn;
+ struct cgraph_edge *e;
+ e = cgraph_edge (cgraph_get_node (cfun->decl), call);
+ if (e && e->callee && e->callee->decl)
+return get_vi_for_tree (e->callee->decl);
+
+ fn = gimple_call_fn (call);
if (fn && TREE_CODE (fn) == OBJ_TYPE_REF)
fn = OBJ_TYPE_REF_EXPR (fn);
[Bug c/49396] c-family/c-cppbuiltin.c: duplicate if expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49396
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.06.14 12:47:55
CC||jsm28 at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther 2011-06-14
12:47:55 UTC ---
I think it should be
Index: c-family/c-cppbuiltin.c
===
--- c-family/c-cppbuiltin.c (revision 175011)
+++ c-family/c-cppbuiltin.c (working copy)
@@ -559,7 +559,7 @@ c_cpp_builtins_optimize_pragma (cpp_read
cpp_undef (pfile, "__FINITE_MATH_ONLY__");
cpp_define (pfile, "__FINITE_MATH_ONLY__=1");
}
- else if (!prev->x_flag_finite_math_only && cur->x_flag_finite_math_only)
+ else if (prev->x_flag_finite_math_only && !cur->x_flag_finite_math_only)
{
cpp_undef (pfile, "__FINITE_MATH_ONLY__");
cpp_define (pfile, "__FINITE_MATH_ONLY__=0");
Joseph?
[Bug target/49398] [4.7 Regression] bootstrap broken for arm-linux-gnueabi with thumb mode.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49398 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0 Summary|[4.7 ] bootstrap broken for |[4.7 Regression] bootstrap |arm-linux-gnueabi with |broken for |thumb mode. |arm-linux-gnueabi with ||thumb mode.
[Bug debug/49382] -O2 -g: DW_AT_location at the very first PC is already modified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49382 --- Comment #5 from Jan Kratochvil 2011-06-14 12:50:22 UTC --- ../../../gccemptyrange/libgcc/../gcc/config/soft-fp/floattitf.c:34:8: warning: no previous prototype for ‘__floattitf’ [-Wmissing-prototypes] ../../../gccemptyrange/libgcc/../gcc/config/soft-fp/floattitf.c: In function ‘__floattitf’: ../../../gccemptyrange/libgcc/../gcc/config/soft-fp/floattitf.c:45:1: internal compiler error: Segmentation fault Program received signal SIGSEGV, Segmentation fault. 0x00be4403 in add_var_loc_to_decl (decl=0x71fa3b28, loc_note=0x71de7a80, label=0x71f63b88 "*.LVL2") at ../../gccemptyrange/gcc/dwarf2out.c:8633 8633 && GET_CODE (NOTE_VAR_LOCATION_LOC (temp->first->loc)) (I did not have -g3 to say more.)
[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #18 from Jonathan Wakely 2011-06-14
12:51:45 UTC ---
(In reply to comment #16)
> Then, the snippet:
>
> std::valarray v1{ 0, 1, 2, 3, 4 }, v2{ 5, 6, 7, 8, 9};
>
> for (int i : v1 + v2)
> { std::cout << i << std::endl; }
>
> compiles but then misbehaves at compile-time, per valgrind too: apparently we
> don't have a proper range. Note that the following misbehaves exactly in the
> *same way*, and this appears to support my conjecture that we have a problem
> somewhere with two different temporary _Expr passed to the begin and end
> overloads:
>
> for (auto b = std::begin(v1 + v2), e = std::end(v1 + v2); b < e; ++b)
> { std::cout << *b << std::endl; }
Hmm, then range-based for is implemented incorrectly, I'll take a look.
It should be identical to
auto&& range = v1 + v2;
for (auto b = std::begin(range), e = std::end(range); b != e; ++b)
{ ... }
(see 6.5.4 [stmt.ranged])
of course the same problem is present for any temporary expression:
std::string s = "hello"
for (auto b = std::begin(s+"!"), e = std::end(s+"!"); b != e; ++b)
but it should work correctly as:
for (auto c : s+"!")
[Bug c/49396] c-family/c-cppbuiltin.c: duplicate if expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49396 --- Comment #2 from Richard Guenther 2011-06-14 12:53:45 UTC --- Same error on all branches back to 4.4.
[Bug debug/49382] -O2 -g: DW_AT_location at the very first PC is already modified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49382 --- Comment #6 from Jakub Jelinek 2011-06-14 12:54:34 UTC --- Yeah, sure, I've noticed that an hour ago too. Fixed in my copy, but now libgo build failed for unrelated reason :(.
[Bug c/49362] Arm Neon intrinsic types not correctly interpreted by compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49362
Greta Yorsh changed:
What|Removed |Added
CC||Greta.Yorsh at arm dot com
--- Comment #3 from Greta Yorsh 2011-06-14
12:59:11 UTC ---
It looks like the problem you described has already been fixed.
When the example is compiled with gcc from trunk (gcc version 4.7.0 with -O2),
vld1q variant has 15 instructions and vld2q variant has 13 instructions (see
below).
The version of gcc you use is 4.4.1. The issue hasn't been fixed in the latest
gcc release 4.6, but the fix should be included in the next release and
probably won't be backported to 4.5 and 4.6 releases.
Disassembly of section .text:
:
0:f460438f vld2.32{d20-d23}, [r0]
4:f461038f vld2.32{d16-d19}, [r1]
8:f34481f0 veorq12, q10, q8
c:f34601f2 veorq8, q11, q9
10:f3f02568 vcnt.8q9, q12
14:f3f00560 vcnt.8q8, q8
18:f24208e0 vadd.i8q8, q9, q8
1c:f3f002e0 vpaddl.u8q8, q8
20:f3f402e0 vpaddl.u16q8, q8
24:f26121b1 vorrd18, d17, d17
28:f2620bb0 vpadd.i32d16, d18, d16
2c:f2600bb0 vpadd.i32d16, d16, d16
30:ee100b90 vmov.32r0, d16[0]
34:e12fff1e bxlr
0038 :
38:f4602a8d vld1.32{d18-d19}, [r0]!
3c:f4610a8d vld1.32{d16-d17}, [r1]!
40:f34221f0 veorq9, q9, q8
44:f4604a8f vld1.32{d20-d21}, [r0]
48:f3f02562 vcnt.8q9, q9
4c:f4610a8f vld1.32{d16-d17}, [r1]
50:f34401f0 veorq8, q10, q8
54:f3f00560 vcnt.8q8, q8
58:f24208e0 vadd.i8q8, q9, q8
5c:f3f002e0 vpaddl.u8q8, q8
60:f3f402e0 vpaddl.u16q8, q8
64:f26121b1 vorrd18, d17, d17
68:f2620bb0 vpadd.i32d16, d18, d16
6c:f2600bb0 vpadd.i32d16, d16, d16
70:ee100b90 vmov.32r0, d16[0]
74:e12fff1e bxlr
[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #19 from Jonathan Wakely 2011-06-14 13:01:24 UTC --- Ah, no the problem is std::__addressof(__ex()[0]) which takes the address of a temporary returned by operator[] The range-based for seems to do the right thing
[Bug fortran/49324] Deep copy missing for array constructors of DT w/ allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49324 --- Comment #9 from Tobias Burnus 2011-06-14 13:07:07 UTC --- (Comment fixed 8 fixed the missing deep copy.) Regarding the reallocate (cf. comment 6, but using scalars to reduce the dump size): For type t integer, allocatable :: A end type t type(t), allocatable :: z ... z = [ x ] One gets the following dump: /* If not initialized. For arrays: Also realloc, if the size is wrong. */ if (z != 0B) goto L.1; z = (struct t *) __builtin_malloc (8); So far so good, but one then has D.1552 = *z; if (D.1552.a != 0B) __builtin_free ((void *) D.1552.a); which is only OK if "z.data" has neither been just allocated nor reallocated. If it has, there are two problems: (a) The old memory is not freed. (b) if malloc/realloc does not return nullified memory, free() operates on some random pointer. The question is how to handle it best? The assignment is handled in gfc_trans_assignment_1, which calls gfc_alloc_allocatable_for_assignment for the realloc and gfc_trans_scalar_assign for the assignment.
[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #20 from Paolo Carlini 2011-06-14 13:22:13 UTC --- I'm not sure, really. I'm going to attach a variant which more explicitly only uses return by const ref and shows the same fundamental problem for me.
[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #21 from Paolo Carlini 2011-06-14 13:23:29 UTC --- Created attachment 24519 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24519 patch
[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #22 from Paolo Carlini 2011-06-14 13:27:03 UTC --- To be clear: I fully agree with the exclusion sentence. But I had to play a bit with this stuff to realize that really adding overloads to begin() and end() cannot work.
[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459
Richard Henderson changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #20 from Richard Henderson 2011-06-14
13:23:53 UTC ---
(In reply to comment #19)
> > A full build for AVR fails, but that seems to be related to other
> > open bugs.
>
> What bugs?
Perhaps I shouldn't assume.
../../../../../../comb/newlib/libc/search/hash.c: In function ‘__expand_table’:
../../../../../../comb/newlib/libc/search/hash.c:898:1: error: unable to find a
register to spill in class ‘POINTER_REGS’
../../../../../../comb/newlib/libc/search/hash.c:898:1: error: this is the
insn:
(insn 190 97 191 10 (set (reg:QI 18 r18)
(mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 5 [0x5])) [14 S1 A8]))
../../../../../../comb/newlib/libc/search/hash.c:886 4 {*movqi}
(nil))
../../../../../../comb/newlib/libc/search/hash.c:898:1: internal compiler
error: in spill_failure, at reload1.c:2113
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[8]: *** [lib_a-hash.o] Error 1
make[8]: Leaving directory
`/home/rth/work/gcc/bld-avr/avr-elf/avr25/newlib/libc/search'
I saw r28 in there and assumed it was the same problem with the
frame pointer as PR46779.
Anyway, I believe I've fixed the problem for #c0. I'll commit it shortly.
[Bug c/49396] c-family/c-cppbuiltin.c: duplicate if expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49396
--- Comment #3 from joseph at codesourcery dot com 2011-06-14 13:23:09 UTC ---
On Tue, 14 Jun 2011, rguenth at gcc dot gnu.org wrote:
> I think it should be
>
> Index: c-family/c-cppbuiltin.c
> ===
> --- c-family/c-cppbuiltin.c (revision 175011)
> +++ c-family/c-cppbuiltin.c (working copy)
> @@ -559,7 +559,7 @@ c_cpp_builtins_optimize_pragma (cpp_read
>cpp_undef (pfile, "__FINITE_MATH_ONLY__");
>cpp_define (pfile, "__FINITE_MATH_ONLY__=1");
> }
> - else if (!prev->x_flag_finite_math_only && cur->x_flag_finite_math_only)
> + else if (prev->x_flag_finite_math_only && !cur->x_flag_finite_math_only)
> {
>cpp_undef (pfile, "__FINITE_MATH_ONLY__");
>cpp_define (pfile, "__FINITE_MATH_ONLY__=0");
Looks right to me.
[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 --- Comment #21 from Richard Henderson 2011-06-14 13:31:47 UTC --- Author: rth Date: Tue Jun 14 13:31:43 2011 New Revision: 175018 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175018 Log: PR debug/48459 * dwarf2out.c (frame_pointer_fb_offset_valid): New. (based_loc_descr): Assert it's true. (compute_frame_pointer_to_fb_displacement): Set it, rather than aborting immediately. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug target/49404] New: ARM _Unwind_Backtrace returns _URC_FAILURE too eagerly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49404 Summary: ARM _Unwind_Backtrace returns _URC_FAILURE too eagerly Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: akos.paszt...@gmail.com Host: i686-pc-linux-gnu Target: arm-none-linux-gnueabi In the ARM implementation of _Unwind_Backtrace [1], if get_eit_entry() returns _URC_END_OF_STACK, as it will when reaching a .cantunwind function (e.g. _start), it is turned into _URC_FAILURE. Thus, _Unwind_Backtrace will (almost always?) return _URC_FAILURE, which is bad if someone relies on that return value. I wonder if the get_eit_entry() result should be just returned verbatim, if it's not _URC_OK, something like: if ((code = get_eit_entry (ucbp, saved_vrs.core.r[R_PC])) != _URC_OK) break; [1] http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/arm/unwind-arm.c;h=4a9e2325c39afca79d05148be46ff72663a8b5cd;hb=HEAD#l974
[Bug c/49362] Arm Neon intrinsic types not correctly interpreted by compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49362 mark.pupilli at dyson dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from mark.pupilli at dyson dot com 2011-06-14 13:46:51 UTC --- Ok, looks like the optimiser will be better in 4.7 as well. Thank you!
[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #23 from Paolo Carlini 2011-06-14 13:50:56 UTC --- Ok, now I see, it's the operator[] of _BinBase which returns by value, I overlooked that. Thus, fine it seems confirmed that range-based for-loop itself is Ok, but making sure we have return by const ref everywhere for _Expr seems unmanageable. Thus, again, confirmed that I agree with removing the overloads.
[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36610 --- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-06-14 13:53:56 UTC --- objc.dg/torture/forward-1.m now seems to XPASS (almost?) everywhere with -fgnu-runtime: alpha-dec-osf5.1b i386-pc-solaris2.1[01] -m64 mips-sgi-irix6.5 sparc-sun-solaris2* Could it be that this PR has now been fixed by the libobjc API rework? If so, the xfail should be removed. Rainer
[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #24 from Gabriel Dos Reis 2011-06-14
13:54:13 UTC ---
(In reply to comment #18)
> It should be identical to
>
> auto&& range = v1 + v2;
> for (auto b = std::begin(range), e = std::end(range); b != e; ++b)
> { ... }
> (see 6.5.4 [stmt.ranged])
This will not work with expression template-based implementation
of valarray. The reason is that `range' may be a surrogate, and
you are likely to get rubbish addresses.
I urge people to drop range-based iteration on valarrays.
It wasn't something we were dieing for. It grew out of
someone's idea of "uniformity" that failed to appreciate
that a valarray is not your usual container.
- Gaby
[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36610 --- Comment #22 from js-gcc at webkeks dot org 2011-06-14 14:02:05 UTC --- Nope, it's still using __builtin_apply.
[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #25 from Gabriel Dos Reis 2011-06-14 14:01:30 UTC --- (In reply to comment #23) > Ok, now I see, it's the operator[] of _BinBase which returns by value, I > overlooked that. Yes, "val" in "valarray" stands for "value", e.g. a valarray is a fundamentally a value, from a conceptual point of view; not an object. Range-based "for" is fundamentally container-oriented in the sense that it assumes that the container is an *object* that resides in memory, and the iteration really visits each cell in that object. A valarray is a *value*, and each individual value in that array may be produced by any mean, e.g. surrogates.
[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #26 from Paolo Carlini 2011-06-14 14:02:15 UTC --- ... among other things, std::valarray, at variance with the containers, does *not* have member begin and end, thus I don't even think novice programmers may have expectations about that.
[Bug libstdc++/48365] Non-constant references in std::valarray::operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48365 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #4 from Paolo Carlini 2011-06-14 14:10:48 UTC --- Gaby, we should somehow resolve this one too...
[Bug libstdc++/48365] Non-constant references in std::valarray::operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48365 Gabriel Dos Reis changed: What|Removed |Added CC||gdr at gcc dot gnu.org --- Comment #5 from Gabriel Dos Reis 2011-06-14 14:17:54 UTC --- (In reply to comment #1) > Gaby, can you have a look to this issue? It seems to me that in general, given > the expression templates mechanism we have in place, something like > > k = k[0] * k,(1) > > where k is a valarray, cannot possibly work as intuitively expected, because > the multiplication is expanded "in place": operator= triggers the computation > of the new k[0] and then k[1] which definitely uses the new k[0], contrary to > intuition. Is this actually undefined behavior, like morally in > > operator*(const T& t, const valarray& v) > > t cannot be an element of v? Seems something falling under the special > features > of valarray wrt aliasing, but I don't see it mentioned anywhere in C++03. > > Interestingly, if I change (1) to > > k *= k[0] > > which should be in principle equivalent, the behavior is the same on GCC, > whereas another implementation of valarray agrees with GCC in this case. Yes, Paolo, you are right. Valarray computations assume absence of certain form of aliasing, and this appears to be one of them.
[Bug c/49362] Arm Neon intrinsic types not correctly interpreted by compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49362 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org Target Milestone|--- |4.7.0
[Bug middle-end/45098] Missed induction variable optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45098 --- Comment #14 from vries at gcc dot gnu.org 2011-06-14 14:30:01 UTC --- Author: vries Date: Tue Jun 14 14:29:58 2011 New Revision: 175022 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175022 Log: 2011-06-14 Zdenek Dvorak Tom de Vries PR target/45098 * cfgloop.h (nb_iterations_upper_bound, nb_iterations_estimate): Document changed semantics. (max_stmt_executions, max_stmt_executions_int): Declare. * tree-data-ref.c (estimated_loop_iterations) (estimated_loop_iterations_int): Move functions... * tree-ssa-loop-niter.c (estimated_loop_iterations) (estimated_loop_iterations_int): here. (record_estimate): Change nb_iterations_upper_bound and nb_iterations_estimate semantics. (max_stmt_executions, max_stmt_executions_int): New function. * tree-data-ref.c (estimated_loop_iterations_tree): Rename to ... (max_stmt_executions_tree): this. (analyze_miv_subscript): Use max_stmt_executions_tree instead of estimated_loop_iterations_tree. tree-ssa-loop-ivopts.c (avg_loop_niter): Use max_stmt_executions_int instead of estimated_loop_iterations_int. * predict.c (predict_loops): Idem. * tree-parloops.c (parallelize_loops): Idem. * tree-data-ref.c (analyze_siv_subscript_cst_affine) (compute_overlap_steps_for_affine_1_2, analyze_subscript_affine_affine) (init_omega_for_ddr_1): Idem. * tree-ssa-loop-prefetch.c (determine_loop_nest_reuse) (loop_prefetch_arrays): Idem * graphite-sese-to-poly.c (build_loop_iteration_domains): Use max_stmt_executions instead of estimated_loop_iterations. * tree-data-ref.c (estimated_loop_iterations_tree): Idem. * tree-vrp.c (adjust_range_with_scev): Use estimated_loop_iterations instead of nb_iterations_upper_bound. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloop.h trunk/gcc/graphite-sese-to-poly.c trunk/gcc/predict.c trunk/gcc/tree-data-ref.c trunk/gcc/tree-parloops.c trunk/gcc/tree-ssa-loop-ivopts.c trunk/gcc/tree-ssa-loop-niter.c trunk/gcc/tree-ssa-loop-prefetch.c trunk/gcc/tree-vrp.c
[Bug rtl-optimization/49390] [4.6/4.7 Regression] GCSE miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49390 --- Comment #5 from Jakub Jelinek 2011-06-14 14:59:55 UTC --- Author: jakub Date: Tue Jun 14 14:59:52 2011 New Revision: 175023 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175023 Log: PR rtl-optimization/49390 Revert: 2010-06-29 Bernd Schmidt * cse.c (exp_equiv_p): For MEMs, if for_gcse, only compare MEM_ALIAS_SET. * gcc.c-torture/execute/pr49390.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr49390.c Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/49390] [4.6/4.7 Regression] GCSE miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49390 --- Comment #6 from Jakub Jelinek 2011-06-14 15:01:15 UTC --- Author: jakub Date: Tue Jun 14 15:01:10 2011 New Revision: 175024 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175024 Log: PR rtl-optimization/49390 Revert: 2010-06-29 Bernd Schmidt * cse.c (exp_equiv_p): For MEMs, if for_gcse, only compare MEM_ALIAS_SET. * gcc.c-torture/execute/pr49390.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr49390.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/cse.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug middle-end/45098] Missed induction variable optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45098 --- Comment #15 from vries at gcc dot gnu.org 2011-06-14 15:05:29 UTC --- Author: vries Date: Tue Jun 14 15:05:26 2011 New Revision: 175025 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175025 Log: 2011-06-14 Tom de Vries PR target/45098 * gcc.target/arm/ivopts-3.c: New test. * gcc.target/arm/ivopts-4.c: New test. * gcc.target/arm/ivopts-5.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/ivopts-3.c trunk/gcc/testsuite/gcc.target/arm/ivopts-4.c trunk/gcc/testsuite/gcc.target/arm/ivopts-5.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/49103] [4.6/4.7 Regression] local variables exchange values / wrong code with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49103 --- Comment #14 from Jakub Jelinek 2011-06-14 15:27:28 UTC --- Author: jakub Date: Tue Jun 14 15:27:24 2011 New Revision: 175028 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175028 Log: PR fortran/49103 * tree.h (DECL_NONSHAREABLE): Define. (struct tree_decl_common): Change decl_common_unused to decl_nonshareable_flag. * cfgexpand.c (expand_used_vars_for_block, clear_tree_used): Ignore vars with DECL_NONSHAREABLE bit set. * tree-cfg.c (gimple_duplicate_bb): Set DECL_NONSHAREABLE on stores to automatic aggregate vars. * gfortran.dg/pr49103.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr49103.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree.h
[Bug fortran/49103] [4.6/4.7 Regression] local variables exchange values / wrong code with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49103 --- Comment #15 from Jakub Jelinek 2011-06-14 15:28:27 UTC --- Author: jakub Date: Tue Jun 14 15:28:21 2011 New Revision: 175029 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175029 Log: PR fortran/49103 * tree.h (DECL_NONSHAREABLE): Define. (struct tree_decl_common): Change decl_common_unused to decl_nonshareable_flag. * cfgexpand.c (expand_used_vars_for_block, clear_tree_used): Ignore vars with DECL_NONSHAREABLE bit set. * tree-cfg.c (gimple_duplicate_bb): Set DECL_NONSHAREABLE on stores to automatic aggregate vars. * gfortran.dg/pr49103.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/pr49103.f90 Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/cfgexpand.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-cfg.c branches/gcc-4_6-branch/gcc/tree.h
[Bug target/49402] Duplicate use of v850.opt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49402 --- Comment #1 from Nick Clifton 2011-06-14 15:30:15 UTC --- Author: nickc Date: Tue Jun 14 15:30:05 2011 New Revision: 175030 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175030 Log: PR target/49403 * config/v850/v850.c (v850_memory_move_cost): Add reg_class_t parameter. PR target/49402 * config.gcc(v850*-*-*): Avoid duplication of v850.opt. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/v850/v850.c
[Bug target/49403] v850e-elf: incompatible pointer type (near initialization for ‘targetm.memory_move_cost’)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49403 --- Comment #1 from Nick Clifton 2011-06-14 15:30:15 UTC --- Author: nickc Date: Tue Jun 14 15:30:05 2011 New Revision: 175030 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175030 Log: PR target/49403 * config/v850/v850.c (v850_memory_move_cost): Add reg_class_t parameter. PR target/49402 * config.gcc(v850*-*-*): Avoid duplication of v850.opt. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/v850/v850.c
[Bug target/49403] v850e-elf: incompatible pointer type (near initialization for ‘targetm.memory_move_cost’)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49403 --- Comment #2 from Nick Clifton 2011-06-14 15:32:13 UTC --- Fixed in mainline.
[Bug target/49402] Duplicate use of v850.opt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49402 --- Comment #2 from Nick Clifton 2011-06-14 15:32:49 UTC --- Fixed in mainline.
[Bug testsuite/49375] Target libstdc++.so used by host cc1plus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49375 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-06-14 15:41:50 UTC --- IMO this is a clear example why LD_LIBRARY_PATH is evil: the execution tests in the testsuite should be linked with -R/-rpath/whatever is required so the correct target libraries are found. This has the additional advantage that you can manually reexecute a failing tests without first having to set LD_LIBRARY_PATH to all the directories necessary to locate the runtime libraries. I think some testsuites get this right, with the exception of libgcc_s.so.1. As a workaround, you could link cc1plus with libppl and libstdc++ statically. At least this avoids all RPATH/LD_LIBRARY_PATH issues. Certainly not pretty, but that's what I've been doing all the time and what happens for go1 out of the box. I always found the contortions necessary to correctly link with libppl a nightmare, and it has only improved a little bit recently. Rainer
[Bug target/47333] [4.6 regression] g++.dg/lto/20091219 FAILs on Solaris 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333 --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-06-14 15:47:16 UTC --- > --- Comment #14 from Richard Guenther 2011-06-12 > 12:48:32 UTC --- > A target issue as it only depends on the assembler used. Rainer, as people > don't have access to solaris as I guess you have to debug it and propose a > fix. > I suspect some symout assembler hook gets in the way? AFAICS, the code doesn't handle assemblers without weakref support correctly. So this will work with gas, but with nothing else. I don't really know what's necessary to avoid this issue, given that I haven't really digged what weakrefs are and how to represent the same concept on non-gas platforms. Rainer
[Bug libfortran/49214] [4.7 Regression] Broken pipe in backtrace for x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49214 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Tobias Burnus 2011-06-14 15:56:59 UTC --- (In reply to comment #6) > Can this PR be closed? The original issue seems to be fixed in comment 3 and > the issue of comment 4 seems to be a bug in Darwin's libc implementation of > backtrace_symbols_fd. No objections raised - thus: Close as FIXED.
[Bug target/47364] [x32] internal compiler error: in emit_move_insn, at expr.c:3355
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47364 --- Comment #7 from hjl at gcc dot gnu.org 2011-06-14 16:32:01 UTC --- Author: hjl Date: Tue Jun 14 16:31:57 2011 New Revision: 175034 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175034 Log: Properly expand strlen to Pmode. 2011-06-14 H.J. Lu PR middle-end/47364 * builtins.c (expand_builtin_strlen): Expand strlen to Pmode and properly handle result not in Pmode. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c
[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459
--- Comment #22 from Georg-Johann Lay 2011-06-14
16:32:08 UTC ---
(In reply to comment #20)
> (In reply to comment #19)
> > > A full build for AVR fails, but that seems to be related to other
> > > open bugs.
> >
> > What bugs?
>
> Perhaps I shouldn't assume.
>
> ../../../../../../comb/newlib/libc/search/hash.c: In function
> ‘__expand_table’:
> ../../../../../../comb/newlib/libc/search/hash.c:898:1: error: unable to find
> a
> register to spill in class ‘POINTER_REGS’
> ../../../../../../comb/newlib/libc/search/hash.c:898:1: error: this is the
> insn:
> (insn 190 97 191 10 (set (reg:QI 18 r18)
> (mem/c:QI (plus:HI (reg/f:HI 28 r28)
> (const_int 5 [0x5])) [14 S1 A8]))
> ../../../../../../comb/newlib/libc/search/hash.c:886 4 {*movqi}
> (nil))
> ../../../../../../comb/newlib/libc/search/hash.c:898:1: internal compiler
> error: in spill_failure, at reload1.c:2113
Oh, I doubt newlib works with avr-gcc. There is just one libc implementation
that cooperates with avr-gcc: avr-libc from
http://avr-libc.nongnu.org/
Note that avr-libc does not support in-tree builds, just set --host=avr
CC=/your/avr-gcc
[Bug target/47364] [x32] internal compiler error: in emit_move_insn, at expr.c:3355
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47364 --- Comment #8 from hjl at gcc dot gnu.org 2011-06-14 16:36:16 UTC --- Author: hjl Date: Tue Jun 14 16:36:12 2011 New Revision: 175035 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175035 Log: Pass POINTERS_EXTEND_UNSIGNED to convert_to_mode. 2011-06-12 H.J. Lu PR middle-end/47364 * builtins.c (expand_builtin_strlen): Properly handle target not in Pmode if POINTERS_EXTEND_UNSIGNED is defined. Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/builtins.c
[Bug target/47364] [x32] internal compiler error: in emit_move_insn, at expr.c:3355
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47364 --- Comment #9 from hjl at gcc dot gnu.org 2011-06-14 16:36:50 UTC --- Author: hjl Date: Tue Jun 14 16:36:45 2011 New Revision: 175036 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175036 Log: Expand strlen to Pmode. 2011-06-14 H.J. Lu PR middle-end/47364 * builtins.c (expand_builtin_strlen): Expand strlen to Pmode. Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/builtins.c
[Bug target/49402] Duplicate use of v850.opt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49402 Uros Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Uros Bizjak 2011-06-14 17:44:04 UTC --- .
[Bug c++/49405] New: Inlining in inheritance seems broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49405 Summary: Inlining in inheritance seems broken Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: neotheone...@gmail.com
[Bug c++/49405] Inlining in inheritance seems broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49405 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Paolo Carlini 2011-06-14 18:09:34 UTC --- Not a PR.
[Bug c++/49290] [4.6/4.7 Regression][C++0x] ICE in in cxx_eval_indirect_ref, at cp/semantics.c:6795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49290 --- Comment #2 from Jason Merrill 2011-06-14 18:15:46 UTC --- Author: jason Date: Tue Jun 14 18:15:43 2011 New Revision: 175041 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175041 Log: PR c++/49290 * semantics.c (cxx_fold_indirect_ref): Local, more permissive copy of fold_indirect_ref_1. (cxx_eval_indirect_ref): Use it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array-ptr7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/49389] [C++0x] Wrong value category for pointer-to-member expression with rvalue object expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49389 --- Comment #1 from Jason Merrill 2011-06-14 18:16:00 UTC --- Author: jason Date: Tue Jun 14 18:15:58 2011 New Revision: 175043 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175043 Log: PR c++/49389 * typeck2.c (build_m_component_ref): Preserve rvalueness. Added: trunk/gcc/testsuite/g++.dg/cpp0x/rv-dotstar.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/49369] typeof() strips const from member when used in const method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49369 --- Comment #5 from Jason Merrill 2011-06-14 18:15:53 UTC --- Author: jason Date: Tue Jun 14 18:15:51 2011 New Revision: 175042 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175042 Log: PR c++/49369 * class.c (build_base_path): Fix cv-quals in unevaluated context. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype30.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug c++/49117] 4.5 -> 4.6: user-unfriendly change in "invalid conversion" error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49117 --- Comment #1 from Jason Merrill 2011-06-14 18:16:08 UTC --- Author: jason Date: Tue Jun 14 18:16:06 2011 New Revision: 175044 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175044 Log: PR c++/49117 * call.c (perform_implicit_conversion_flags): Print source type as well as expression. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/other/error23.C trunk/gcc/testsuite/g++.dg/other/error32.C
[Bug c++/49406] New: Inlining in inheritance seems broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49406
Summary: Inlining in inheritance seems broken
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: neotheone...@gmail.com
Gcc version: 4.5.2
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default
--with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Consider the following two classes: Base and Derived.
The complete code is as follows:
//Base.h
class Base
{
public:
void showBase();
};
//Base.c++
inline void
Base::showBase()
{
std::cout << "This is the base class.";
}
//Derived.h
class Derived : public Base
{
public:
void showDerived();
};
//Derived.c++
void
Derived::showDerived()
{
std::cout << "This is derived class.\n";
std::cout << "Calling base class method.\n";
Base::showBase();
}
//InlineTest.c++
int main()
{
Derived derived;
derived.showDerived();
return 0;
}
Command-line : g++ InlineText.c++ Base.c++ Derived.c++ -o Inline.o
Compiler error output: /tmp/ccDKDhFN.o: In function `Derived::showDerived()':
Derived.c++:(.text+0x32): undefined reference to `Base::showBase()'
collect2: ld returned 1 exit status
[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36610 Nicola Pero changed: What|Removed |Added CC||nicola at gcc dot gnu.org --- Comment #23 from Nicola Pero 2011-06-14 18:26:40 UTC --- Yes, in a strict sense this bug could be closed ... because objc_msg_sendv() no longer exists in the GNU Objective-C runtime. So if the bug is about it not working on some platforms, it can certainly be closed. ;-) Forwarding in libobjc still uses __builtin_apply(), so the problem, in a wider sense, still exists. But that forwarding is not used by any user of libobjc as far as I know (they all have their own libffi-based implementation of forwarding that are used through the forwarding hooks that libobjc has) and I'm planning on entirely removing it for 4.7.0 - it's unused (the forwarding hooks override any implementation in libobjc), and it often doesn't work. I also have some other plans for a new forwarding infrastructure, that may or may not happen for 4.7.0. Summarizing, I would close the bug, or leave it open but just to remind me/us to: * remove the existing forwarding code from libobjc; * remove the forward-1.m testcase; * add new testcases for the libobjc forwarding hooks. As these are the official ways to use forwarding (and the only ones available), we should have testcases. Let me know if you have any comments. Thanks
[Bug c++/49406] Inlining in inheritance seems broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49406 --- Comment #1 from neotheone222 at gmail dot com 2011-06-14 18:33:25 UTC --- Created attachment 24520 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24520 Base header file
[Bug c++/49406] Inlining in inheritance seems broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49406 --- Comment #2 from neotheone222 at gmail dot com 2011-06-14 18:33:52 UTC --- Created attachment 24521 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24521 Base implementation file
[Bug c++/49406] Inlining in inheritance seems broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49406 --- Comment #3 from neotheone222 at gmail dot com 2011-06-14 18:34:18 UTC --- Created attachment 24522 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24522 Base preprocessed file
[Bug c++/49406] Inlining in inheritance seems broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49406 --- Comment #4 from neotheone222 at gmail dot com 2011-06-14 18:34:43 UTC --- Created attachment 24523 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24523 Derived header file
[Bug c++/49406] Inlining in inheritance seems broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49406 --- Comment #5 from neotheone222 at gmail dot com 2011-06-14 18:35:04 UTC --- Created attachment 24524 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24524 Derived implementation file
[Bug c++/49406] Inlining in inheritance seems broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49406 --- Comment #6 from neotheone222 at gmail dot com 2011-06-14 18:35:22 UTC --- Created attachment 24525 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24525 Derived preprocessed file
[Bug c++/49406] Inlining in inheritance seems broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49406 --- Comment #7 from neotheone222 at gmail dot com 2011-06-14 18:36:01 UTC --- Created attachment 24526 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24526 InlineText main file
[Bug c++/49406] Inlining in inheritance seems broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49406 --- Comment #8 from neotheone222 at gmail dot com 2011-06-14 18:36:35 UTC --- Created attachment 24527 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24527 InlineText preprocessed file
[Bug c++/49406] Inlining in inheritance seems broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49406 --- Comment #9 from Jonathan Wakely 2011-06-14 18:37:28 UTC --- your program is invalid if a function is declared inline in one translation unit (such as Base.c++) then it must be declared inline in all translation units that refer to it
[Bug c++/49406] Inlining in inheritance seems broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49406 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #10 from Jonathan Wakely 2011-06-14 18:39:55 UTC --- the usual way to do that is to define the inline function in a header (e.g. Base.h would be the obvious place) it cannot be inlined in Derived.c++ if its definition is not included in that file
[Bug debug/49407] unusable debuginfo for dll-imported functions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49407 --- Comment #1 from Pawel Sikora 2011-06-14 19:04:34 UTC --- Created attachment 24528 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24528 testcase
[Bug debug/49407] New: unusable debuginfo for dll-imported functions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49407
Summary: unusable debuginfo for dll-imported functions.
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
Hi,
i;m currently testing the 4,6-based i686-pc-mingw32 toolchain and
afaics the debuginfo for dll-imported functions are quite unusable :/
$ cat d.cpp
#include
extern "C" __declspec(dllexport) void bar( void )
{
puts( "bar is here!" );
}
$ cat m.cpp
#include
extern "C" void bar( void );
int main()
{
bar();
}
$ make
/local/devel/toolchain46/i686-pc-mingw32/bin/i686-pc-mingw32-g++ -Wall
-mthreads -g2 d.cpp -shared -o d.dll
/local/devel/toolchain46/i686-pc-mingw32/bin/i686-pc-mingw32-objdump -xw d.dll
> d.txt
/local/devel/toolchain46/i686-pc-mingw32/bin/i686-pc-mingw32-g++ -Wall
-mthreads -g2 m.cpp -o m.exe d.dll
/local/devel/toolchain46/i686-pc-mingw32/bin/i686-pc-mingw32-objdump -xw m.exe
> m.txt
and now on windows host the gdb.exe shows me:
D:\mingw.tests>d:\mingw32\bin\gdb.exe m.exe
GNU gdb (GDB) 7.2.90.20110602-cvs
(...)
(gdb) b bar
Breakpoint 1 at 0x402798
(gdb) r
Starting program: D:\mingw.tests/m.exe
(...)
Breakpoint 1, 0x00402798 in bar ()
(gdb) disassemble
Dump of assembler code for function bar:
=> 0x00402798 <+0>: jmp*0x406200
0x0040279e <+6>: nop
0x0040279f <+7>: nop
End of assembler dump.
(gdb) si
0x6b4414c0 in ?? ()
(gdb) disassemble
No function contains program counter for selected frame.
at this point i can't debug the 'bar' function :(
[Bug debug/49408] New: member function template id not matching linkage name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49408
Summary: member function template id not matching linkage name
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.kratoch...@redhat.com
CC: do...@gcc.gnu.org
Target: x86_64-unknown-linux-gnu
FAIL gcc (GCC) 4.4.7 20110614 (prerelease)
FAIL gcc (GCC) 4.7.0 20110614 (experimental)
struct S {
void m (int x) {}
};
template
struct K {
void f () { S s; (s.*F) (5); }
};
int main () {
K<&S::m> k;
k.f ();
}
-g
<1><64>: Abbrev Number: 8 (DW_TAG_structure_type)
<65> DW_AT_name: K<&S::m>
<2><8a>: Abbrev Number: 10 (DW_TAG_template_value_param)
<8b> DW_AT_name: F
<8d> DW_AT_type: <0x170>
<2><70>: Abbrev Number: 9 (DW_TAG_subprogram)
<72> DW_AT_name: f
<76> DW_AT_MIPS_linkage_name: _ZN1KIXadL_ZN1S1mEiEEE1fEv
<1><11d>: Abbrev Number: 18 (DW_TAG_subprogram)
<11e> DW_AT_specification: <0x70>
<122> DW_AT_low_pc : 0x4004de
004004de W _ZN1KIXadL_ZN1S1mEiEEE1fEv
004004de W K<&(S::m(int))>::f()
The linkage name has class name: K<&(S::m(int))>
But DW_AT_name of that class is: K<&S::m>
It is not ambiguous but it breaks debugger lookups.
