[Bug rtl-optimization/51366] [cygwin] ICE in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51366 --- Comment #6 from Denis Excoffier 2012-01-18 08:45:36 UTC --- This bug was still present under gcc-4.7-20120107 snapshot, but it does no longer show up under gcc-4.7-20120114 snapshot. I suppose it has been corrected. Thank you.
[Bug rtl-optimization/51505] [4.5/4.6/4.7 Regression] ICE: in form_sum, at reload.c:5349 with -O --param max-cse-insns=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505 --- Comment #8 from Paolo Bonzini 2012-01-18 08:58:33 UTC --- I think you can just kill the note and call df_notes_rescan, can't you? (Sorry for leaving this implicit in comment 4 and then forgetting about it yesterday).
[Bug tree-optimization/51782] -ftree-sra: Missing address-space information leads to wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #13 from Georg-Johann Lay 2012-01-18 09:17:29 UTC --- (In reply to comment #12) > Author: rguenth > Date: Tue Jan 17 14:52:57 2012 > New Revision: 183249 Just for feedback: In r183270 the bug is still present (and -fno-tree-sra is work around).
[Bug target/19520] protected function pointer doesn't work right
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Comment #25 from Richard Guenther 2012-01-18
09:21:14 UTC ---
LD bug: http://sourceware.org/bugzilla/show_bug.cgi?id=13600
The GCC side is a QOI thing and maybe a conformance thing. ICC generates
for
__attribute__((visibility("protected")))
void * foo (void) { return (void *)foo; }
.protected foo
.globl foo
foo:
..B1.1: # Preds ..B1.0
..___tag_value_foo.1: #1.60
movq foo@GOTPCREL(%rip), %rax #1.77
thus does not resolve the function address to the local symbol, which GCC
does and which confuses LD (thus the linker bug):
.globl foo
.protected foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
leaqfoo(%rip), %rax
I think ICC this way avoids the function pointer comparison issues with
symbols with protected visibility (can someone double-check? HJs testcase
doesn't compile for me).
[Bug tree-optimization/50873] The fix to PR50730 causes gcc.c-torture/unsorted/dilayout.c to ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50873 rsand...@gcc.gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from rsandifo at gcc dot gnu.org 2012-01-18 09:32:44 UTC --- Fixed on trunk.
[Bug tree-optimization/51890] New: vectorizer does not recognize intrinsic functions like sqrt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51890 Bug #: 51890 Summary: vectorizer does not recognize intrinsic functions like sqrt Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: heiko.kl...@gmx.net Created attachment 26360 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26360 test code which does not vectorize properly Compiling attached program with gcc4.6.2/bin/gcc -std=c99 -O2 -mfpmath=sse -msse2 -lm -o test_novector test_novector.c -ftree-vectorize -ftree-vectorizer-verbose=2 results in the comment: test_novector.c:8: note: not vectorized: loop contains function calls or data references that cannot be analyzed (older compilers, i.e. gcc4.4.3 just complain about data reference) The only function call is sqrt(), but sqrt is an intrinsic vectorized function (_mm_sqrt_pd) and can be easily vectorized. Due to missing vectorization, this code is 2x (4x with AVX) slower than compiled with other compilers (tested against icc12).
[Bug target/40419] __attribute__((mips16)) is broken on trunk.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40419 rsand...@gcc.gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from rsandifo at gcc dot gnu.org 2012-01-18 09:34:48 UTC --- Yeah, seems to have been working for a while.
[Bug rtl-optimization/51505] [4.5/4.6/4.7 Regression] ICE: in form_sum, at reload.c:5349 with -O --param max-cse-insns=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505
--- Comment #9 from Andrey Belevantsev 2012-01-18
09:46:41 UTC ---
This seems like an overkill as we only need to remove a single vector. The
below helper looks enough:
+/* Remove the EQ_USES vector for INSN assuming it exists. */
+void
+df_ref_remove_eq_uses (rtx insn)
+{
+ struct df_insn_info *insn_info = DF_INSN_UID_GET (INSN_UID (insn));
+ df_mw_hardreg_chain_delete_eq_uses (insn_info);
+ df_ref_chain_delete (insn_info->eq_uses);
+ insn_info->eq_uses = df_null_ref_rec;
+}
+
The patch then just calls this after killing a note.
[Bug libobjc/51891] New: class_copyIvarList crashes on empty ivars
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51891 Bug #: 51891 Summary: class_copyIvarList crashes on empty ivars Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: libobjc AssignedTo: unassig...@gcc.gnu.org ReportedBy: t...@pruetz.net Created attachment 26361 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26361 simple example When calling class_copyIvarList(class, NULL) with a class that has no ivars the app crashes with a segfault. Please find an example attached.
[Bug c++/51885] g++ compiler options -O2 and -O3 modifies program results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51885 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez 2012-01-18 10:02:04 UTC --- (In reply to comment #2) > The reinterpret_cast definitely results in undefined behaviour, because it > accesses the float objects through a different type, violating [basic.lval]/10 > > And indeed, -fno-strict-aliasing makes the problem go away. It definitely does not make the problem go away, it merely hides it. The undefined behavior does not disappear just by using command-line options. On the other hand, is it possible to cast a float pointer to a uint32 pointer and use it for anything that does not invoke undefined behaviour? GCC gives a warning with -Wstrict-aliasing=1 but no with other levels.
[Bug tree-optimization/51890] vectorizer does not recognize intrinsic functions like sqrt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51890 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Guenther 2012-01-18 10:06:07 UTC --- You need to enable -fno-math-errno as sqrt may set errno which we cannot vectorize. Then the loop is vectorized (-ffast-math conveniently also enables -fno-math-errno).
[Bug c++/51889] [4.7 regression] can't override a using-declaration in a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51889 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug lto/51887] wrapped function with LTO - multiple prevailing defs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51887 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Richard Guenther 2012-01-18 10:08:39 UTC --- I'd say it's a duplicate (and I think an ld bug, ld should put the backwards-translated names in the resolution file). *** This bug has been marked as a duplicate of bug 51859 ***
[Bug lto/51859] Linker option effects not reflected in symbol resolution file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51859 --- Comment #4 from Richard Guenther 2012-01-18 10:08:39 UTC --- *** Bug 51887 has been marked as a duplicate of this bug. ***
[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 --- Comment #20 from Tobias Burnus 2012-01-18 10:16:10 UTC --- Status: a) Passing absent optional as actual argument to elemental procedures. 4.4-4.7 Regression. Fixed on the 4.7 trunk, needs backporting. See comment 5 / http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00206.html b) Passing unallocated allocatable / unassociated pointer: Affects 4.6/4.7; fixed on the 4.7 trunk with comment 19 http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00793.html Consider backporting to 4.6. c) Issues with polymorphism and elemental See testcase of comment 13 and draft patch of comment 16 and comment 18. (A tiny part of the patch has been committed in comment 19.) That's a trunk-only item.
[Bug tree-optimization/51879] Missed tail merging with non-const/pure calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51879 --- Comment #2 from Jakub Jelinek 2012-01-18 10:36:39 UTC --- I'm afraid a lot would break. It really depends on what you use VN for and on what code. If you have: D.12345_1 = bar (7); D.12346_2 = bar (7); and bar isn't const/pure call, then if VN equivalences D.12345_1 and D.12346_2, it is wrong. Of course if you have: : D.12345_1 = bar (7); goto bb9; : D.12346_2 = bar (7); : D.12347_3 = PHI (this case), you could VN them the same.
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484
--- Comment #8 from Richard Guenther 2012-01-18
10:38:15 UTC ---
(In reply to comment #5)
> It doesn't really help - there are more races. The following does seem
> to help though, but is certainly not applicable.
>
> Index: gcc/libgcov.c
> ===
> --- gcc/libgcov.c (revision 183243)
> +++ gcc/libgcov.c (working copy)
> @@ -77,6 +77,7 @@ void __gcov_merge_delta (gcov_type *coun
> #include
> #include
> #endif
> +#include
>
> #ifdef L_gcov
> #include "gcov-io.c"
> @@ -584,7 +585,9 @@ void
> __gcov_flush (void)
> {
>const struct gcov_info *gi_ptr;
> + static pthread_mutex_t mx = PTHREAD_MUTEX_INITIALIZER;
>
> + pthread_mutex_lock (&mx);
>gcov_exit ();
>for (gi_ptr = gcov_list; gi_ptr; gi_ptr = gi_ptr->next)
> {
> @@ -598,6 +601,7 @@ __gcov_flush (void)
> ci_ptr++;
> }
> }
> + pthread_mutex_unlock (&mx);
> }
>
> #endif /* L_gcov */
Would be applicable when we compile a second libgcov_r which we'd use
when linking with -pthread.
[Bug tree-optimization/51879] Missed tail merging with non-const/pure calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51879 --- Comment #3 from Richard Guenther 2012-01-18 10:45:01 UTC --- (In reply to comment #2) > I'm afraid a lot would break. It really depends on what you use VN for and on > what code. > If you have: > D.12345_1 = bar (7); > D.12346_2 = bar (7); > and bar isn't const/pure call, then if VN equivalences D.12345_1 and > D.12346_2, > it is wrong. Of course if you have: > : > D.12345_1 = bar (7); > goto bb9; > : > D.12346_2 = bar (7); > : > D.12347_3 = PHI > (this case), you could VN them the same. Yes, but not for D.12345_1 = bar (7); D.12346_2 = bar (7); so you can't really value-number the calls the same. As we are working on SSA SCCs and not on a CFG (and thus do not do predicated value-numbering) that ability is useless.
[Bug tree-optimization/51879] Missed tail merging with non-const/pure calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51879 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-18 Ever Confirmed|0 |1 --- Comment #4 from Richard Guenther 2012-01-18 10:46:00 UTC --- Confirmed btw.
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek 2012-01-18 10:57:07 UTC --- Why? Just use gthr.h stuff...
[Bug rtl-optimization/51505] [4.5/4.6/4.7 Regression] ICE: in form_sum, at reload.c:5349 with -O --param max-cse-insns=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505 --- Comment #10 from Paolo Bonzini 2012-01-18 10:58:19 UTC --- Not using df_notes_rescan looks like premature optimization to me...
[Bug tree-optimization/50444] [4.6/4.7 Regression] -ftree-sra ignores alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50444
--- Comment #14 from Martin Jambor 2012-01-18
11:23:00 UTC ---
Created attachment 26362
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26362
patch-in-progress
I talked to richi on IRC yesterday and we agreed that because we rely
on build_ref_for_model to create the whole chain of COMPONENT_REFs on
strict alignment platforms, that we would disable some scalarization
in cases like this, after all.
However, in addition to what richi suggested in comment #12, I found
out that that was not enough to make the test pass on i686. Also,
propagation across assignments is not the only way how these may be
created for the aggregate on the LHS, they might just be there because
of pre-existing accesses elsewhere in the function.
So I looked at the caster dumps again and found out that indeed the
very first assignment
MEM[(char * {ref-all})&c1x128] = MEM[(char * {ref-all})&c4x32];
had the LHS replaced by a SRA vector replacement and the RHS by a
reference created by build_ref_for_model with the same problems. This
lead to a similar situation but with switched sides.
So I looked at where these build_ref_for_model an came up with the
following patch which is fairly straightforward and makes the testcase
pass also on i686. However, there are two problems with the patch.
1. This is the easy part. I'm afraid similar problems are lurking in
processing aggregate copies with children accesses. But those could
be dealt with afterwards.
2. When I bootstrapped gcc and run the testsuite with this patch, I
got a new failure in libstdc++:
23_containers/forward_list/modifiers/1.cc
The failure persists with -fno-tree-sra, so something went wrong when
compiling the library. The patch is very simple and only disabling
stuff which then has to through the VIEW_CONVERT_EXPR path so at the
moment I think that either the condition guarding the following
force_gimple_rhs = true;
is wrong or I have uncovered some other bug :-(
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 --- Comment #10 from Richard Guenther 2012-01-18 11:49:58 UTC --- Created attachment 26363 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26363 draft patch Draft patch that doesn't work because we do not unconditionally provide __GTHREAD_MUTEX_INIT_FUNCTION.
[Bug middle-end/48660] [4.5/4.6 Regression] ARM ICE in expand_expr_real_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48660 rsand...@gcc.gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from rsandifo at gcc dot gnu.org 2012-01-18 11:53:39 UTC --- Fixed on branches and trunk.
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 rsand...@gcc.gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|rsandifo at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #7 from rsandifo at gcc dot gnu.org 2012-01-18 11:54:27 UTC --- No longer working on this.
[Bug rtl-optimization/51505] [4.5/4.6/4.7 Regression] ICE: in form_sum, at reload.c:5349 with -O --param max-cse-insns=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505 --- Comment #11 from Andrey Belevantsev 2012-01-18 12:02:36 UTC --- No problem -- I will go back to df_notes_rescan and repost to gcc-patches.
[Bug target/49030] ICE in get_arm_condition_code, at config/arm/arm.c:17180
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49030 rsand...@gcc.gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from rsandifo at gcc dot gnu.org 2012-01-18 12:04:49 UTC --- Fixed on trunk, and not marked as a regression.
[Bug target/50090] ARM EABI symbols in libgcc.a have default visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50090 rsand...@gcc.gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from rsandifo at gcc dot gnu.org 2012-01-18 12:05:54 UTC --- Fix applied to 4.5, 4.6 and trunk.
[Bug tree-optimization/51890] vectorizer does not recognize intrinsic functions like sqrt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51890 --- Comment #2 from Heiko Klein 2012-01-18 12:26:18 UTC --- Thanks, adding -fno-math-errno vectorizes the code and gives exactly the speedup as with icc. Heiko
[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 --- Comment #21 from Mikael Morin 2012-01-18 13:05:01 UTC --- Thanks Tobias. (In reply to comment #20) > Status: > > a) Passing absent optional as actual argument to elemental procedures. >4.4-4.7 Regression. Fixed on the 4.7 trunk, needs backporting. >See comment 5 / http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00206.html > > b) Passing unallocated allocatable / unassociated pointer: >Affects 4.6/4.7; fixed on the 4.7 trunk with comment 19 >http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00793.html >Consider backporting to 4.6. > > c) Issues with polymorphism and elemental >See testcase of comment 13 and draft patch of comment 16 and comment 18. >(A tiny part of the patch has been committed in comment 19.) >That's a trunk-only item. I should be able to produce a patch for c) before the end of the week. I'll defer backporting after that because it's possible that the final patch affects the way a) and b) are done. Let's wait until the code has settled a bit on the trunk before applying (part of) it to the branche(s).
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org |
[Bug target/19520] protected function pointer doesn't work right
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Comment #26 from Thiago Macieira 2012-01-18
13:28:05 UTC ---
ld *can* link, it just chooses not to.
$ cat > foo.c
__attribute__((visibility("protected")))
void * foo (void) { return (void *)foo; }
$ gcc -fPIC -shared foo.c
/usr/bin/ld: /tmp/cclrufLV.o: relocation R_X86_64_PC32 against protected symbol
`foo' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
$ gcc -Wl,-Bsymbolic-functions -fPIC -shared foo.c && echo success
success
$ cat > empty.dynlist
{ "__this_symbol_isnt_present__"; };
$ gcc -Wl,--dynamic-list,empty.dynlist -fPIC -shared foo.c && echo success
success
I also cannot confirm that icc does anything different:
$ icc -fPIC -shared foo.c
ld: /tmp/iccf15gTK.o: relocation R_X86_64_PC32 against protected symbol `foo'
can not be used when making a shared object
ld: final link failed: Bad value
$ icc -O3 -S -o /dev/stdout -fPIC -shared foo.c | grep -A4 foo:
foo:
..B1.1: # Preds ..B1.0
..___tag_value_foo.1: #2.19
lea foo(%rip), %rax #2.36
ret #2.36
What's more, if you actually do compile the following program into a shared
library, it succeeds:
$ cat > foo.S
.text
.globl foo
.protected foo
.type foo, @function
foo:
movq foo@GOTPCREL(%rip), %rax
ret
$ gcc -shared foo.S && echo success
success
But the resulting shared object has the following (extracted from eu-readelf):
Relocation section [ 5] '.rela.dyn' for section [ 0] '' at offset 0x230
contains 1 entry:
Offset TypeValue Addend Name
0x00200330 X86_64_GLOB_DAT 0x0248 +0 foo
2: 0248 0 FUNCGLOBAL PROTECTED 6 foo
Now we introduce a third component to this discussion: the dynamic linker. What
will it do?
This has become a decision, not a bug: what should the compiler do when taking
the address of a function when said function is under protected visibility.
Both solutions are technically correct and would load the same function address
under the correct circumstances.
The compiler is also taking on the "protected" visibility to the letter (at
least, according to its own definition of so):
"protected"
Protected visibility is like default visibility except that it
indicates that references within the defining module will
bind to the definition in that module. That is, the declared
entity cannot be overridden by another module.
Since the symbol was marked as "protected" in the symbol table, it's expected
that the linker and dynamic linker will bind it locally. That being the case,
the compiler can optimise for that fact. It can calculate what value would be
placed in the GOT entry and load that instead. That's the LEA instruction.
The linker, however, mandates that the address to symbol should not be loaded
directly, but only through the GOT. This is necessary because the psABI
requires that the function address resolve to the PLT entry found in the
position-dependent executable. If the executable takes the address of this
global (but protected) symbol, it will hardcode the address to its own address
space, forcing other ELF modules to follow suit.
Finally, what does the dynamic linker do when an "entity (that) cannot be
overridden by another module" is overridden by another module? The glibc 2.14
loader will resolve the GOT entry's relocation to the executable's PLT stub,
even if the symbol in question has protected visibility. Other loaders might
work differently.
As it stands, the psABI requires that the address to a protected function be
loaded through the GOT, even though the compiler thinks it knows what the
address will be.
However, I really wish the compiler *not* to change its behaviour for PIC code,
but instead change its behaviour for ELF position-dependent executables. I am
asking for a change in the psABI and requesting that the loading of function
addresses for "default" visibility symbols (not protected!) should be done via
the GOT. In other words, I'm asking that we optimise for shared libraries, not
for executables.
Versions:
GCC: 4.6.0
ld: 2.21.51.0.6-6.fc15 20110118
ICC: 12.1.0 20111011
[Bug libgcj/50057] [4.7 regression] misalignment of java_exception_header resulted in throwable to be null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50057
--- Comment #4 from gee 2012-01-18 13:28:53 UTC ---
Created attachment 26365
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26365
proposed patch
it fixes invalid padding that caused the bug.
#include
#define DEBUG 1
#include
#include
#include
#include
typedef int* jthrowable,_Unwind_Ptr;
struct alignment_test_struct
{
char space;
char end[0] __attribute__((aligned));
};
struct java_exception_header
{
#define MEMBER_AT_FRONT \
_Unwind_Ptr* landingPad;\
int handlerSwitchValue;
MEMBER_AT_FRONT
struct _pad{MEMBER_AT_FRONT};
#undef MEMBER_AT_FRONT
#define PADORZERO(x,y,z) (sizeof(x)
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 Richard Guenther changed: What|Removed |Added Attachment #26363|0 |1 is obsolete|| --- Comment #11 from Richard Guenther 2012-01-18 13:26:01 UTC --- Created attachment 26364 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26364 more complete patch Changes __GTHREAD_MUTEX_INIT_FUNCTION to be unconditionally available (but not for all configs). Still shows an issue when __GTHREAD_MUTEX_INIT is not available in the fork () path. While we can re-init the mutex there with __GTHREAD_MUTEX_INIT_FUNCTION, the non-__GTHREAD_MUTEX_INIT path will later use a broken once in init_mx_once (and of course initialize it again). Unless it is somehow guaranteed that already triggered gthread-once things will work fine after forking. Otherwise seems to work fine on x86_64-linux sofar.
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 --- Comment #12 from Jakub Jelinek 2012-01-18 13:35:28 UTC --- Well, pthread_once can't be called in fork child if fork has been done from multi-threaded process (similarly to most other calls).
[Bug libgcj/51500] [4.7 regression] 106 unexpected libjava testsuite failures with mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51500 --- Comment #7 from gee 2012-01-18 13:35:15 UTC --- after applying pr50057 patch http://gcc.gnu.org/bugzilla/attachment.cgi?id=26365 === libjava Summary === # of expected passes2324 # of unexpected failures51 # of untested testcases 35
[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784
Iain Sandoe changed:
What|Removed |Added
Attachment #26324|0 |1
is obsolete||
Attachment #26330|0 |1
is obsolete||
--- Comment #35 from Iain Sandoe 2012-01-18 13:43:07
UTC ---
Created attachment 26366
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26366
initial fix.
there are a few wrinkles;
1/ the use of epilogue_completed has to be conditional on optimization because
otherwise there's no post-epilogue split pass.
2/ When there's a non-local label in nested code it looks like this:
bx = got load
jmp
nonlocal:
do the fixup
:
which is fine.
However, in except.c we have:
void
expand_dw2_landing_pad_for_region (eh_region region)
{
#ifdef HAVE_exception_receiver
if (HAVE_exception_receiver)
emit_insn (gen_exception_receiver ());
else
#endif
#ifdef HAVE_nonlocal_goto_receiver
if (HAVE_nonlocal_goto_receiver)
emit_insn (gen_nonlocal_goto_receiver ());
else
which causes sequences like this:
bx = load got (emits pic base label).
...
...
exception_return = > forces in a got restore via the insert of nonlocal goto
rx.
bx = got restore
(got correction - uses pic base label)
...
the optimizer figures that the first (got load) is not needed because nothing
touches bx in the meantime -- so it drops the got load.
Unfortunately, it can't see that the got load is what emits the pic-base label
needed by subsequent pic code (and the correction).
The nice solution would be to carry the pic-base label in per function visible
RTL and to make all the pic handling "open" in the md ... but that's not going
to happen any time soon (well, not in stage 4 anyways).
So .. the solution I've put in the patch is that we always try to do a pic load
- and we notice (per function) if we've already output the pic-base label. If
so, we don't try to do it again.
This works (there's a marginal inefficiency in that, once in a while, in
exception handling code you will get a zero correction made), but that's only
on exception non-local jump branches .. so we can probably live with it for
now.
A similar solution works also for PPC (the pic code is a lot more in the md
there - so it's a bit more involved).
[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #36 from Iain Sandoe 2012-01-18 13:47:36 UTC --- (In reply to comment #34) > 5) to determine if you need to load the pic register or not, you should match > what > the prologue expansion does, try > (pic_offset_table_rtx > && (df_regs_ever_live_p (REAL_PIC_OFFSET_TABLE_REGNUM) > || crtl->profile)) nothing seems to use df_regs_ever_live_p in the md files, and the function is not visible. I also wonder if it is updated during RTL optimization? (I tried making a function in i386.c that performed these tests and was visible from the md - but it didn't work). For now, I've used crtl->uses_pic_offset_table which seems to work. Is there any other suggestion? > probably also anded with && !current_function_is_leaf - non-local goto > receiver > in leaf functions doesn't make much sense and certainly doesn't need to > restore > PIC pointer, plus it will simplify it (for leaf functions we sometimes decide > to use a different register as pic pointer instead of %ebx). hopefully using pic_offset_table_rtx will pick up the current one?
[Bug target/50946] ICE on armhf with webkitgtk+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50946 Matthew Gretton-Dann changed: What|Removed |Added CC||mgretton at sourceware dot ||org --- Comment #3 from Matthew Gretton-Dann 2012-01-18 13:57:12 UTC --- I can reproduce this for GCC 4.6.2 (rev 183061) with an bare-metal target (arm-none-eabi):c arm-none-eabi-g++ -O2 -mfpu=vfpv3 -mfloat-abi=hard -march=armv7-a -mthumb -fpermissive -w -c webkit_testcase-min.i Current trunk does not ICE on the test case.
[Bug target/10901] non-local goto's don't work on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org Known to fail|| --- Comment #23 from Iain Sandoe 2012-01-18 14:16:31 UTC --- I have a fix for this in progress see also PR 51784. JFTR, I suspect the issue is moot in clang/llvm because they don't support nested functions AFAICT - but use 'blocks' instead. BTW, is there any access to the 'positron' branch - was it ever on an FSF server?
[Bug libobjc/51892] New: +initialize is not being called when calling class method via new runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51892 Bug #: 51892 Summary: +initialize is not being called when calling class method via new runtime Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: libobjc AssignedTo: unassig...@gcc.gnu.org ReportedBy: t...@pruetz.net Created attachment 26367 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26367 simple example When calling a class method for the first time the +initialize message should be send to it. This is not the case when the method is send using new runtime methods only. Please find a simple example attached.
[Bug target/19520] protected function pointer doesn't work right
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520 --- Comment #27 from Richard Guenther 2012-01-18 15:17:19 UTC --- (In reply to comment #26) > The linker, however, mandates that the address to symbol should not be loaded > directly, but only through the GOT. This is necessary because the psABI > requires that the function address resolve to the PLT entry found in the > position-dependent executable. Why on earth does it do that? If we have to go through the GOT it can as well contain the functions address and not that of the PLT entry?
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 --- Comment #13 from Richard Guenther 2012-01-18 15:41:02 UTC --- Hmm, and as libgcov is static we can end up with multiple copies in shared libraries which means multiple mutexes and thus exposal to the fcntl file-locking ineffectiveness (in this case the library must fork, of course). At least we should not see crashes even in this case because we properly protect the non-shared __gcov_var.
[Bug libstdc++/51850] debug mode for std::array and tr1::array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51850 --- Comment #1 from Edward Rosten 2012-01-18 16:35:40 UTC --- Created attachment 26368 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26368 Adds bounds checking to std::array and tr1::array in debug mode. I've attached a patch which adds bounds checking to std::array (C++0x) and std::tr1::array. The std::array patch keeps operator[] as constexpr.
[Bug middle-end/51893] New: Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51893 Bug #: 51893 Summary: Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: aurelien.buhrig@gmail.com Created attachment 26369 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26369 Patch The subword index (wordnum) passed to operand_subword_force in store_bit_field_1 is incorrect for BIG_ENDIAN targets when bitsize > BITS_PER_WORD. wordnum, which is used to get the subword of value, is computed wrt the number of words needed by bitsize instead of the number of words needed by the integer mode of the field, which is the mode used to compute subwords. For instance, for a 40bit field to be set by a DI reg (with HI words), the offset of the LSWord of the DI reg should be 3, not 2 as currently computed. The attached patch seems to solve the issue. Tested on the C testsuite without any regression (for my target only). Note that this problem occurs on a "private" target (hardly reproducible).
[Bug middle-end/51893] Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51893 Aurelien Buhrig changed: What|Removed |Added Severity|normal |critical
[Bug target/10901] non-local goto's don't work on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901 m...@gcc.gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #24 from mrs at gcc dot gnu.org 2012-01-18 17:19:07 UTC --- apple-branch is what's on the FSF server. The positron branch should be on the Apple open source website, though, just grabbing the top of the tree (latest version of gcc-4.2) I think would be preferable. There is a version in the llvm repo, though, it does have all the llvm goop in it as well.
[Bug fortran/48426] [patch] Quad precision promotion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426 --- Comment #20 from kargl at gcc dot gnu.org 2012-01-18 17:24:23 UTC --- Author: kargl Date: Wed Jan 18 17:24:14 2012 New Revision: 183277 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183277 Log: Insert ChangeLog entry that should have been included in svn revision 183217 for PR fortran/48426. Modified: trunk/gcc/fortran/ChangeLog
[Bug libitm/51830] FAIL: libitm.c/mem(cpy|set)-1.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51830 Uros Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | Target Milestone|--- |4.7.0 --- Comment #2 from Uros Bizjak 2012-01-18 18:13:17 UTC --- I have a patch in testing.
[Bug target/10901] non-local goto's don't work on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901 --- Comment #25 from Iain Sandoe 2012-01-18 18:29:12 UTC --- Created attachment 26370 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26370 initial fix this shares some changes with the fix to PR51784 (and that is somewhere to read about the issues that prevent an easier fix). AFAICT, the bugs are still present in the Apple OS tree - at least they are with 4.2.1/5577 - which postdates the comments here. Anyway, this is a starting point - I expect that there is scope to tidy it up. As things stand we need to differentiate the load-picbase from the reload-picbase on PPC because more of the work is done in the md. On x86 it's hidden away in i386.c - which made it easier to fix there.
[Bug testsuite/51875] FAIL: gfortran.dg/guality/pr41558.f90 -O0 line 7 s == 'foo'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51875 --- Comment #2 from dave.anglin at bell dot net 2012-01-18 18:49:55 UTC --- On 1/17/2012 5:03 AM, rguenth at gcc dot gnu.org wrote: > Confirmed. That seems to be the usual by-reference passing for a callee copy > thing. Not sure if we can cater for this difference in the testcase easily. I think gdb is also a factor as the test doesn't fail on PA ELF targets.
[Bug libstdc++/51845] [4.7 regression] 23_containers/unordered_multimap/erase/24061-multimap.cc segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845 --- Comment #17 from Jakub Jelinek 2012-01-18 18:51:57 UTC --- I think the bug is in the two argument erase in hashtable.h. In the testcase we are removing two elements, the last element from bucket 10 and first element from bucket 20, but there is also another element in bucket 20. This means that __is_bucket_begin is false initially, the last element from bucket 10 is removed, then __is_bucket_begin is set to true, but as we don't remove the whole bucket (we stop when __n_bkt == __bkt because we reach __last_n), the _M_remove_bucket_begin call does nothing. But as __n_bkt == __bkt, we dont' update _M_buckets[__n_bkt], so it references a removed node. --- libstdc++-v3/include/bits/hashtable.h2012-01-15 20:59:53.765526939 +0100 +++ libstdc++-v3/include/bits/hashtable.h2012-01-18 19:49:39.222388730 +0100 @@ -1541,7 +1541,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION __bkt = __n_bkt; } - if (__n && __n_bkt != __bkt) + if (__n && (__n_bkt != __bkt || __is_bucket_begin)) _M_buckets[__n_bkt] = __prev_n; __prev_n->_M_nxt = __n; return iterator(__n); seems to fix this and I think it should be safe, when __is_bucket_begin is set, it means __n will be the bucket begin, so _M_buckets[__n_bkt] should be __prev_n. The __n_bkt != __bkt test is still needed, for the case where we remove just the trailing elements of some bucket, then we want to update the next bucket, even when __is_bucket_begin is false.
[Bug c/51894] New: Fail to warn on likely precedence error in conditional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51894
Bug #: 51894
Summary: Fail to warn on likely precedence error in conditional
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aravindvijayan224...@gmail.com
Created attachment 26371
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26371
example program showing the failure to warn
example program showing the failure to warn:
gcc version 4.7.0
If you have:
if (ret = return_neg_one() == 1)
printf("direct_test==true\n");
else
printf("direct_test==false\n");
The compiler will warn:
/tmp/tmp.c:51:2: warning: suggest parentheses around assignment used as truth
value
But if it is a complex conditional:
if (!cond ||
(ret = return_neg_one() == 1))
The compiler will not warn. It seems it should warn in this case as well.
[Bug tree-optimization/49642] constant part of a macro not optimized away as expected due to splitter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49642 --- Comment #10 from William J. Schmidt 2012-01-18 19:28:23 UTC --- Author: wschmidt Date: Wed Jan 18 19:28:19 2012 New Revision: 183284 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183284 Log: gcc: 2012-01-11 Bill Schmidt PR tree-optimization/49642 * ipa-split.c (forbidden_dominators): New variable. (check_forbidden_calls): New function. (dominated_by_forbidden): Likewise. (consider_split): Check for forbidden dominators. (execute_split_functions): Initialize and free forbidden dominators info; call check_forbidden_calls. gcc/testsuite: 2012-01-11 Bill Schmidt PR tree-optimization/49642 * gcc.dg/tree-ssa/pr49642.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/tree-ssa/pr49642.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/ipa-split.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug libitm/51830] FAIL: libitm.c/mem(cpy|set)-1.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51830 Uros Bizjak changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-01/msg00924.htm ||l --- Comment #3 from Uros Bizjak 2012-01-18 19:28:16 UTC --- Patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00924.html
[Bug c++/51364] C++ interoperability with ISO-C extension DFP types requires explicit typedefs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51364
--- Comment #12 from Ryan S. Arnold 2012-01-18 20:00:08
UTC ---
Returning to the bug report at hand...
In my version of float.h I have the following (which aligns with the typedef
definitions in the std::decimal namespace). This works just fine for _Decimal*
and decimal* compatibility:
typedef float _Decimal32 __attribute__((mode(SD)));
typedef float _Decimal64 __attribute__((mode(DD)));
typedef float _Decimal128 __attribute__((mode(TD)));
But the TR indicates that the following compatibility types are to be provided
instead so I attempted to replace what I have with these:
3.4.2 Header synopsis
// C-compatibility convenience typedefs:
typedef std::decimal::decimal32 _Decimal32;
typedef std::decimal::decimal64 _Decimal64;
typedef std::decimal::decimal128 _Decimal128;
I've found that when this is provided in float.h (my own overloaded float.h) I
get the following warning:
warning: format '%Df' expects type '_Decimal64', but argument 2 has type
'_Decimal64'
And more importantly, the following error:
../libdfp-decimal/dfp/decimal/decimal:241:32: error: no matching function for
call to 'std::decimal::decimal32::__setval(_Decimal32&)'
/opt/at4.0/lib/gcc/powerpc64-linux/4.5.4/../../../../include/c++/4.5.4/decimal/decimal:304:10:
note: candidate is: void
std::decimal::decimal32::__setval(std::decimal::decimal32::__decfloat32)
Where the error identified code is doing the following:
template
inline std::basic_istream &
operator>>(std::basic_istream & is, decimal32 & d)
{
char buf[CHAR_MAX];
memset(buf, '\0', CHAR_MAX);
is.read(buf,CHAR_MAX);
--->d.__setval(strtod32(buf, NULL));
return is;
}
(Note: This error isn't encountered when _Decimal32 is typedefed to float
_Decimal32 __attribute__((mode(SD)));).
This is how I'd expect to be able to set the actual value in the decimal32
number (coming out of a routine that returns a C-style _Decimal32) but this
obviously isn't correct since _Decimal32 is recognized by the C++ compiler as a
std::decimal::decimal32 typedef and is not type compatible with
std::decimal:decimal32::__decfloat32.
Interestingly, adding the following to the system decimal/decimal
std::decimal::decimal32 class definition makes the error go away:
operator __decfloat32() { return __val; }
I presume what is happening is that _Decimal32 is recognized as
std::decimal::decimal32 (due to the typedef) and then the __decfloat32 operator
is applied to it and it then magically matches the __setval() prototype and the
error is silenced. The problem is, it doesn't work, i.e., the assignment never
makes it way into __val correctly.
So I'm not sure what to make of the TR's requirement. It seems that the
typedef float _Decimal32 __attribute__((mode(SD))); method is the correct one.
[Bug c++/51344] [4.4/4.5/4.6/4.7 regression] cc1plus hangs when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51344 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Known to work||4.2.5 Summary|cc1plus hangs when |[4.4/4.5/4.6/4.7 |compiling |regression] cc1plus hangs ||when compiling Known to fail||4.3.6, 4.4.7, 4.5.4, 4.6.3, ||4.7.0 --- Comment #5 from Jason Merrill 2012-01-18 20:06:48 UTC --- The testcase compiles in 4.2; I think that is because we silently ignored the attribute.
[Bug libstdc++/51866] [c++0x][4.7 Regression] unordered_multiset compares moved-out values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51866 --- Comment #7 from François Dumont 2012-01-18 20:18:20 UTC --- Author: fdumont Date: Wed Jan 18 20:17:57 2012 New Revision: 183285 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183285 Log: 2012-01-18 François Dumont Roman Kononov PR libstdc++/51866 * include/bits/hashtable.h (_Hashtable<>::_M_insert(_Arg, false_type)): Do not keep a reference to a potentially moved instance. * testsuite/23_containers/unordered_multiset/insert/51866.cc: New. * testsuite/23_containers/unordered_multimap/insert/51866.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/insert/51866.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/insert/51866.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable.h
[Bug tree-optimization/49642] constant part of a macro not optimized away as expected due to splitter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49642 William J. Schmidt changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #11 from William J. Schmidt 2012-01-18 20:21:04 UTC --- Fixed in 4.7, 4.6, ibm/4.6 = AT5.0.
[Bug c++/51225] [c++0x] [4.7 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51225 --- Comment #4 from paolo at gcc dot gnu.org 2012-01-18 20:27:27 UTC --- Author: paolo Date: Wed Jan 18 20:27:23 2012 New Revision: 183286 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183286 Log: /cp 2012-01-18 Paolo Carlini PR c++/51225 * typeck2.c (store_init_value): Within a template guard cxx_constant_value with require_potential_constant_expression. * pt.c (convert_nontype_argument): Likewise. /testsuite 2012-01-18 Paolo Carlini PR c++/51225 * g++.dg/cpp0x/pr51225.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr51225.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51225] [c++0x] [4.7 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51225 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Paolo Carlini 2012-01-18 20:30:58 UTC --- Done.
[Bug libstdc++/51866] [c++0x][4.7 Regression] unordered_multiset compares moved-out values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51866 François Dumont changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from François Dumont 2012-01-18 20:36:47 UTC --- This issue is solved now. Thanks for the great test case.
[Bug libstdc++/51845] [4.7 regression] 23_containers/unordered_multimap/erase/24061-multimap.cc segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845 --- Comment #18 from François Dumont 2012-01-18 20:44:21 UTC --- I was about to say that resolution of PR 51866 might also explain the memory issue of this PR but I am now going to double check your post. Thanks
[Bug libstdc++/51845] [4.7 regression] 23_containers/unordered_multimap/erase/24061-multimap.cc segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845 --- Comment #19 from Jakub Jelinek 2012-01-18 20:52:27 UTC --- Other alternatives to fix this would be to add size_t __prev_bkt = _M_bucket_index(__prev_n); before the for (;;) loop and change the if (__n && __n_bkt != __bkt) test to if (__n && __prev_bkt != __n_bkt) or remove the __is_bucket_begin = true; line and do instead __is_bucket_begin = __n_bkt != __bkt; before the if (__n == __last_n) test and then test just __n && __is_bucket_begin after the for (;;) loop. But I think the patch I'm bootstrapping/regtesting right now is cheaper than that.
[Bug fortran/51634] [OOP] ICE with polymorphic operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51634 --- Comment #3 from Paul Thomas 2012-01-18 20:52:51 UTC --- Author: pault Date: Wed Jan 18 20:52:48 2012 New Revision: 183287 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183287 Log: 2012-01-18 Paul Thomas PR fortran/51634 * trans-expr.c (gfc_conv_procedure_call): Deallocate allocatable components of temporary class arguments. 2012-01-18 Paul Thomas PR fortran/51634 * gfortran.dg/typebound_operator_12.f03: New. * gfortran.dg/typebound_operator_13.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_operator_12.f03 trunk/gcc/testsuite/gfortran.dg/typebound_operator_13.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/49642] constant part of a macro not optimized away as expected due to splitter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49642 Eric Botcazou changed: What|Removed |Added Status|CLOSED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org
[Bug rtl-optimization/40761] IRA memory hog for insanely nested loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761 Vladimir Makarov changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #16 from Vladimir Makarov 2012-01-18 22:01:11 UTC --- I'll work on it.
[Bug middle-end/51893] Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51893 Andrew Pinski changed: What|Removed |Added Severity|critical|normal
[Bug middle-end/51893] Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51893 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #1 from Andrew Pinski 2012-01-18 23:06:20 UTC --- I see the issue, one place does it right and the other does not.
[Bug libobjc/51891] class_copyIvarList crashes on empty ivars
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51891 Andrew Pinski changed: What|Removed |Added Severity|blocker |normal
[Bug libobjc/51892] +initialize is not being called when calling class method via new runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51892 Andrew Pinski changed: What|Removed |Added Severity|critical|normal
[Bug middle-end/51895] New: [4.7 Regression] ICE in simplify_subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51895
Bug #: 51895
Summary: [4.7 Regression] ICE in simplify_subreg
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: berg...@gcc.gnu.org
Target: powerpc64-linux
struct S
{
long a;
char b;
S () : a (0), b (0) {}
bool baz ();
};
__attribute__((noinline)) static bool
bar (S x, S y)
{
y = x;
return y.baz ();
}
bool
foo (S x)
{
S y;
return bar (x, y);
}
ICEs at -O2 -m64 with:
rh782868.ii: In function ‘bool foo(S)’:
rh782868.ii:20:19: internal compiler error: in simplify_subreg, at
simplify-rtx.c:5420
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug c/51896] New: Should gcc warn if a variable initializer inside a switch statement is never used?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51896
Bug #: 51896
Summary: Should gcc warn if a variable initializer inside a
switch statement is never used?
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: k...@kuix.de
While maintaining existing code, we encountered a snippet like this:
--- begin test.c ---
#include "stdio.h"
#include "stdlib.h"
int main(int argc, char *argv[])
{
int *a = (int*)0x;
printf("a is: %p\n", a);
int r = rand() % 2;
switch (r)
{
int *b = (int*)0x;
case 2: break;
default:
printf("b is: %p\n", b);
}
return 0;
}
--- end test.c ---
$ gcc -o test -Wall test.c
test.c: In function ‘main’:
test.c:17:13: warning: ‘b’ may be used uninitialized in this function
[-Wuninitialized]
$ ./test
a is: 0x
b is: 0x434b5fc4
Proposal:
As gcc decides to ignore value 0x, it should print a warning message,
informing the user, e.g.:
test.c: warning: ignoring initialization value ‘0x’
[Bug middle-end/42688] gcc 4.3.3 with -O2 thinks a often non-zero expression is always zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42688 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #6 from Andrew Pinski 2012-01-19 02:20:20 UTC --- No testcase provided in almost 2 years so closing as invalid.
[Bug lto/44378] lto1: internal compiler error: in cgraph_mark_functions_to_output, at cgraphunit.c:1168
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44378 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski 2012-01-19 02:22:18 UTC --- No feedback about the trunk and no testcase for over a year and halve so closing as invalid.
[Bug preprocessor/46784] Internal compiler error with cairo In function `_cairo_bo_sweep_line_compare_edges'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46784 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski 2012-01-19 02:23:22 UTC --- No feedback in over a year so closing as invalid.
[Bug c/50236] compiler throws internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50236 Andrew Pinski changed: What|Removed |Added Target||mipsel-linux-uclibc Status|WAITING |RESOLVED Resolution||INVALID --- Comment #2 from Andrew Pinski 2012-01-19 02:33:46 UTC --- No feedback in over 3 months so closing. We really need the preprocessed source.
[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51895 --- Comment #1 from Peter Bergner 2012-01-19 02:42:44 UTC --- We ICE when we try and do a BLK move from a reg:TI. In GCC 4.6, we don't see this, since the args[i].tree_value is different: (gdb-gcc4.6) ptree args[i].tree_value unit size align 64 symtab 0 alias set 43 canonical type 0xfffafd6f960 fields used private unsigned nonlocal decl_3 DI file t.ii line 30433 col 11 size unit size align 64 offset_align 128 offset bit offset context chain > context full-name "class llvm::SDValue" needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown pointer_to_this reference_to_this chain > used TI file t.ii line 45352 col 9 size unit size align 64 context abstract_origin (reg/v:TI 306 [ Ptr1 ])> versus for gcc 4.7: (gdb-gc4.7) ptree args[i].tree_value unit size align 8 symtab 0 alias set -1 canonical type 0xfffb5e403f0 precision 8 min max pointer_to_this reference_to_this > BLK size unit size align 8 symtab 0 alias set 0 canonical type 0xfffb0cac198 domain DI size unit size align 64 symtab 0 alias set -1 canonical type 0xfffb0cac0f0 precision 64 min max > pointer_to_this > arg 0 sizes-gimplified public unsigned type_6 DI size unit size align 64 symtab 0 alias set 2 canonical type 0xfffa8d50b28 pointer_to_this > arg 0 used TI file t.ii line 45286 col 6 size unit size align 64 context abstract_origin (reg/v:TI 279 [ Ptr1 ])>> arg 1 constant 0>> That difference forces us down different paths starting at this load_register_parameters() test: else if (TYPE_MODE (TREE_TYPE (args[i].tree_value)) == BLKmode) For 4.6, the mode is a TImode and for 4.7, it's a BLKmode. The following patch seems to fix it: Index: gcc/emit-rtl.c === --- gcc/emit-rtl.c (revision 183280) +++ gcc/emit-rtl.c (working copy) @@ -1401,6 +1401,9 @@ operand_subword (rtx op, unsigned int of return replace_equiv_address (new_rtx, XEXP (new_rtx, 0)); } + if (REG_P (op) && mode == BLKmode) +mode = GET_MODE (op); + /* Rest can be handled by simplify_subreg. */ return simplify_gen_subreg (word_mode, op, mode, (offset * UNITS_PER_WORD)); } I'm bootstraping/regtesting this patch now.
[Bug c++/51897] New: command line option to create a namespace alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51897
Bug #: 51897
Summary: command line option to create a namespace alias
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: danielgut...@gmail.com
In C, the compiler driver allows the
-Dxxx=yyy
option, so programs can be parameterized based on such definition.
In C++, we could do likewise with namespaces.
For example:
namespace Version1
{
void f() { /* version 1 implementation */ }
typedef int MyInt;
}
namespace Version2
{
void f() { /* version 2 implementation */ }
typedef long long int MyInt;
}
then, if we could have a namespace alias such as
namespace NM = Version1;
we could happily do:
NM::f();
NM::MyInt myInt;
Therefore, I suggest to add a new command line option to the driver to define
namespace alias, a C++ counterpart of the C macro definition.
For example, we could do
--namespace_alias NM=Version1
or alike when compiling stuff.
Yes, this can also be done with macros, but it's a cleaner preprocessor-free
choice.
[Bug target/40030] vector float * vector float + vector float should produce only vmaddfp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40030 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #2 from Andrew Pinski 2012-01-19 04:09:14 UTC --- The original testcase is fixed so just closing as fixed.
[Bug other/26692] Build configure misses valid ld in hidden test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26692 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #4 from Andrew Pinski 2012-01-19 04:16:29 UTC --- Closing as won't fix as this version of binutils is not an official version of binutils.
[Bug bootstrap/30775] Bootstrap segmentation faults checking for sqrtl declaration...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30775 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-01-19 Ever Confirmed|0 |1 --- Comment #3 from Andrew Pinski 2012-01-19 04:21:05 UTC --- Can you try with a newer version of GCC? GCC 3.4.x is no longer supported.
[Bug libmudflap/30994] App using Qt lib aborts immediately during startup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30994 --- Comment #1 from Andrew Pinski 2012-01-19 04:37:33 UTC --- >From the sound of it, libmudflap is not being initialized before QT is. QT is calling malloc in its initialization and malloc returns NULL.
[Bug middle-end/35260] ICE in ipa-type-escape.c with -fipa-struct-reorg -fipa-type-escape
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35260 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.7.0 --- Comment #2 from Andrew Pinski 2012-01-19 04:53:18 UTC --- These options/passes were removed by: 2011-03-23 Richard Guenther * Makefile.in (IPA_TYPE_ESCAPE_H): Remove. (OBJS-archive): Remove ipa-struct-reorg.o and ipa-type-escape.o. (tree-ssa-alias.o): Do not depend on IPA_TYPE_ESCAPE_H. (alias.o): Likewise. ... So closing as won't fix.
[Bug tree-optimization/38355] ICE with -fipa-struct-reorg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38355 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.7.0 Known to fail|| --- Comment #6 from Andrew Pinski 2012-01-19 04:56:06 UTC --- The pass was removed by: 2011-03-23 Richard Guenther * Makefile.in (IPA_TYPE_ESCAPE_H): Remove. (OBJS-archive): Remove ipa-struct-reorg.o and ipa-type-escape.o. (tree-ssa-alias.o): Do not depend on IPA_TYPE_ESCAPE_H. (alias.o): Likewise. (ipa-type-escape.o): Remove. (ipa-struct-reorg.o): Likewise. (GTFILES): Remove ipa-struct-reorg.c. * alias.c: Do not include ipa-type-escape.h. * tree-ssa-alias.c: Likewise. * common.opt (fipa-struct-reorg): Preserve for backward compatibility. * opts.c (finish_options): Do not reset flag_ipa_struct_reorg. * passes.c (init_optimization_passes): Remove ipa-struct-reorg and ipa-type-escape passes. * tree-pass.h (pass_ipa_type_escape): Remove. (pass_ipa_struct_reorg): Likewise. So closing as won't fix.
[Bug target/31394] cos() returns wrong value unless -O0 is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31394 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from Andrew Pinski 2012-01-19 05:01:17 UTC --- This is a bug in Solaris's libc where sincos does not produce the same results as sin() and cos() separately would.
[Bug middle-end/32412] Passing struct as parameter breaks SRA for stack-allocated struct inside called function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32412 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #4 from Andrew Pinski 2012-01-19 05:12:44 UTC --- Fixed in 4.6.0 and above. Note you really need to mark foo as static or use -fwhole-program to get the result you want.
[Bug bootstrap/32537] Boostrap failure: ICE when compiling gengtype-lex.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32537 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-01-19 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski 2012-01-19 05:13:25 UTC --- Can you try again? This most likely has been fixed already.
[Bug c++/51889] [4.7 regression] can't override a using-declaration in a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51889 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-01-19 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug libstdc++/33394] Add test case for Thread race segfault in std::string::append with -O and -s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33394 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-19 Component|testsuite |libstdc++ Ever Confirmed|0 |1 Known to fail|| --- Comment #1 from Andrew Pinski 2012-01-19 05:31:00 UTC --- Confirmed.
[Bug bootstrap/34881] Bootstrap fails on building libstdc++: can't find file for: -lgcc_s.10.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34881 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-01-19 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski 2012-01-19 05:32:24 UTC --- Does this work now?
[Bug bootstrap/34259] Compile gcc 3.4.6 on tru64 unix v5.1b problem with yacc syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34259 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski 2012-01-19 05:31:52 UTC --- Invalid based on Jim's comments.
[Bug bootstrap/34259] Compile gcc 3.4.6 on tru64 unix v5.1b problem with yacc syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34259 --- Comment #4 from P-VEREECKE at siih5962 dot fr 2012-01-19 05:32:49 UTC --- Je suis absent du 16/1/2012 au 18/1/2012 inclus. Je traiterai votre message à mon retour le 19/1/2012. Pour toute urgence, contacter la cellule d'appels au 44481. Merci.
[Bug middle-end/35676] internal compiler error: in expand_mult, at expmed.c:3225
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35676 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 --- Comment #3 from Andrew Pinski 2012-01-19 05:34:20 UTC --- Fixed for 4.2.0.
[Bug middle-end/50200] ICE: SIGSEGV in df_insn_refs_collect (df-scan.c:3405)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50200 --- Comment #1 from Andrew Pinski 2012-01-19 05:42:43 UTC --- This works on the trunk for me.
[Bug middle-end/50211] ICE: verify_flow_info: Incorrect fallthru 11->12 with -funroll-all-loops --param case-values-threshold=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50211 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-19 Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski 2012-01-19 05:45:18 UTC --- Confirmed.
[Bug debug/50203] ICE: in output_loc_list, at dwarf2out.c:8188 with --param max-vartrack-expr-depth=140
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50203 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #5 from Andrew Pinski 2012-01-19 05:47:40 UTC --- This is basically a dup of bug 51695 because that is also a >= 64KB expression. *** This bug has been marked as a duplicate of bug 51695 ***
[Bug debug/51695] NOTE_INSN_VAR_LOCATION notes are sometimes too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695 Andrew Pinski changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #8 from Andrew Pinski 2012-01-19 05:47:40 UTC --- *** Bug 50203 has been marked as a duplicate of this bug. ***
[Bug c++/51226] [c++0x] ICE with opaque enum and invalid template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51226 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-19 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski 2012-01-19 05:48:45 UTC --- Confirmed.
[Bug target/35080] __thread generators a.out that creates segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35080 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 --- Comment #2 from Andrew Pinski 2012-01-19 05:51:53 UTC --- Fixed.
