[Bug target/55811] [ERROR] - not enough GOT space for local GOT entries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55811 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||mips64-octeon-linux-gnu Component|c |target --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-12-26 08:28:56 UTC --- Can you report this directly to Cavium since you are using their (well I work for them) toolchain? Cavium includes a fix inside their binutils for an issue like this, are you using their binutils or your own? Also -Wa,-xgot does not make a difference really for 4.3 since 4.3 does explicit got references now; you should use -mxgot instead. -Wl,-Bstatic -lstdc++ -lrt -lm -Wl,-Bdynamic is also bad form. Really you should using Cavium's FAEs for help rather than going directly to the FSF for support.
[Bug target/55811] [ERROR] - not enough GOT space for local GOT entries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55811 --- Comment #2 from Manish manish.jamwal at gmail dot com 2012-12-26 09:17:31 UTC --- Hi Andrew Yes, I am using cavium's toolchain. Will contact Cavium's FAEs for further issues. Thanks very much for your quick reply. Have nice day On Wed, Dec 26, 2012 at 1:58 PM, pinskia at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: is also bad form
[Bug tree-optimization/55812] New: Unnecessary TLS accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55812
Bug #: 55812
Summary: Unnecessary TLS accesses
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Target: x86_64-linux-gnu
Hello,
TLS accesses are expensive, so as much as possible gcc should copy the address
to a local variable and use that instead. The following example may not be very
good, I am just trying to illustrate the issue.
#include vector
thread_local std::vectorint v;
int main(){
for(long i=0;i4;++i){
v.push_back(i);
}
return v.size();
}
compiled with g++ -std=c++11 -O2 -Wall -DNDEBUG. If I remove thread_local,
the speed-up is about 20%. It seems to me that the compiler should get the
address of v once at the beginning of main and use that for the rest of the
function, and thus the performance difference should be negligible.
If I add static in front of thread_local, the program fails to link, but my
gcc snapshot is a bit old (Nov 20) and I think I've already seen that reported.
I was surprised not to find any compiler option that would disable threads, so
I could write thread_local but not pay the price when compiling a
single-threaded program. Without -pthread, glibc uses cheap thread-unsafe
functions, but I still pay for TLS.
[Bug c++/48920] typename specifier should not ignore non-type names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48920 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-26 13:21:27 UTC --- For the first testcase [basic.scope.class] says no diagnostic required, doesn't it?
[Bug c++/55813] New: Poorly named/documented option Wctor-dtor-privacy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55813
Bug #: 55813
Summary: Poorly named/documented option Wctor-dtor-privacy
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: har...@gigawatt.nl
The -Wctor-dtor-privacy option is documented as
`-Wctor-dtor-privacy (C++ only)'
Warn when a class seems unusable, because all the constructors or
destructors in a class are private and the class has no friends or
public static member functions.
However, the option warns for more than just that:
class A { // warning: all member functions in class 'A' are private
void f();
};
class B { // no warning
void f() {}
public:
B() {}
};
The documentation does not explain why a warning for A is issued, nor does it
explain why A is treated differently from B. The option's name suggests that no
warning should be generated for either of them, but I cannot tell what the
actual intended behaviour is, only that gcc has behaved this way since before
3.x.
[Bug tree-optimization/55812] Unnecessary TLS accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55812
--- Comment #1 from Marc Glisse glisse at gcc dot gnu.org 2012-12-26 15:43:50
UTC ---
More precisely, the following seems equivalent to me and gets back all the
performance, so it would be good if gcc could turn the original code into this
one.
#include vector
thread_local std::vectorint v;
int main(){
std::vectorint*vp=v;
for(long i=0;i4;++i){
vp-push_back(i);
}
return vp-size();
}
[Bug target/53789] ICE in gen_reg_rtx, at emit-rtl.c:864/865 when compiling GNU MPFR on parisc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53789 --- Comment #13 from John David Anglin danglin at gcc dot gnu.org 2012-12-26 17:29:12 UTC --- Author: danglin Date: Wed Dec 26 17:29:08 2012 New Revision: 194723 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194723 Log: PR target/53789 * config/pa/pa.md (movsi): Reject expansion of TLS symbol references after reload starts. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/pa/pa.md
[Bug middle-end/55814] New: Missed optimization with short-circuit evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55814
Bug #: 55814
Summary: Missed optimization with short-circuit evaluation
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tkoe...@gcc.gnu.org
See PR 55806.
The Fortran front end generates code for intrinsics like ANY and ALL
which looks like (after loop unrolling)
_Bool foo(int *a, int *b)
{
_Bool f0, f1, f2, f3;
f0 = a[0] b[0];
f1 = a[1] b[1];
f2 = a[2] b[2];
f3 = a[2] b[2];
return f0 || f1 || f2 || f3;
}
There should be no need to perform the second comparison if the
first one is true.
[Bug fortran/54992] [4.8 Regression] [OOP] Wrong offset in the array offset calculation when using nonclass%class(index)%nonclass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54992
Paul Thomas pault at gcc dot gnu.org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |pault at gcc dot gnu.org
|gnu.org |
--- Comment #4 from Paul Thomas pault at gcc dot gnu.org 2012-12-26 17:56:31
UTC ---
This is another result of the underlying bug unearthed in PR54990.
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c(revision 194721)
--- gcc/fortran/trans-array.c(working copy)
*** static tree
*** 3099,3112
build_array_ref (tree desc, tree offset, tree decl)
{
tree tmp;
/* Class array references need special treatment because the assigned
type size needs to be used to point to the element. */
if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (desc))
TREE_CODE (desc) == COMPONENT_REF
! GFC_CLASS_TYPE_P (TREE_TYPE (TREE_OPERAND (desc, 0
{
! tree type = gfc_get_element_type (TREE_TYPE (desc));
tmp = TREE_OPERAND (desc, 0);
tmp = gfc_get_class_array_ref (offset, tmp);
tmp = fold_convert (build_pointer_type (type), tmp);
--- 3099,3118
build_array_ref (tree desc, tree offset, tree decl)
{
tree tmp;
+ tree type;
+
+ type = TREE_TYPE (TREE_OPERAND (desc, 0));
+ if (TYPE_CANONICAL (type)
+GFC_CLASS_TYPE_P (TYPE_CANONICAL (type)))
+ type = TYPE_CANONICAL (type);
/* Class array references need special treatment because the assigned
type size needs to be used to point to the element. */
if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (desc))
TREE_CODE (desc) == COMPONENT_REF
! GFC_CLASS_TYPE_P (type))
{
! type = gfc_get_element_type (TREE_TYPE (desc));
tmp = TREE_OPERAND (desc, 0);
tmp = gfc_get_class_array_ref (offset, tmp);
tmp = fold_convert (build_pointer_type (type), tmp);
fixes it. As remarked in PR54990, I do not know why this regression has
occurred. Evidently, GFC_CLASS_TYPE_P is not being transferred from the
canonical type, whereas this was happening before the regression (or a new type
was not being generated?). I will investigate more.
I have taken this PR.
Cheers
Paul
[Bug libfortran/48960] OPEN statement modifies NEWUNIT variable on error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48960 --- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2012-12-26 18:11:50 UTC --- Author: jvdelisle Date: Wed Dec 26 18:11:42 2012 New Revision: 194724 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194724 Log: 2012-12-26 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/48960 * io/open.c (st_parameter_open): Assign newunit number to user variable only if the the associated open statement is successful. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/open.c
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #17 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-26 19:34:29 UTC --- Another testcase that yields warnings with a sanitized libgomp: !$omp parallel default(none) private(i,j,k) !$omp do collapse(3) DO k = 1,10 DO j = 1,10 DO i = 1,10 ENDDO ENDDO ENDDO !$omp end parallel END WARNING: ThreadSanitizer: data race (pid=16133) Read of size 8 at 0x7d3272c8 by main thread: #0 gomp_iter_static_next /data/vjoost/gnu/gcc_exp/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/iter.c:71 (libgomp.so.1+0x623d) #1 GOMP_loop_static_start /data/vjoost/gnu/gcc_exp/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/loop.c:110 (libgomp.so.1+0x78ac) #2 MAIN__._omp_fn.0 /data/vjoost/clean/cp2k/test.f90:2 (exe+0x0c64)
[Bug target/53789] ICE in gen_reg_rtx, at emit-rtl.c:864/865 when compiling GNU MPFR on parisc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53789 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from John David Anglin danglin at gcc dot gnu.org 2012-12-26 19:47:33 UTC --- ICE is fixed on all active branches. However, there seems to be another problem with the tconst_pi test on hppa-linux. Looking into it. On HP-UX 11.11, 3.1.1 with allpatches builds and checks successfully for both 32 and 64 bit targets.
[Bug bootstrap/55784] [4.8 regression] declaration of C function 'const char* strsignal(int)' conflicts with /usr/include/string.h:112: error: previous declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55784 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|normal |blocker
[Bug middle-end/55114] [4.8 Regression] gcc.dg/builtins-53.c ICEs on mips64 soft-float
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55114 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code, patch Status|UNCONFIRMED |NEW URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-12/msg01369.htm ||l Last reconfirmed||2012-12-26 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-12-26 21:33:37 UTC --- Confirmed based on the patch.
[Bug libstdc++/55815] New: switch hash function of libstdc++ hash tables to siphash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55815 Bug #: 55815 Summary: switch hash function of libstdc++ hash tables to siphash Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: felix-...@fefe.de Hash functions traditionally used by language runtimes for hash tables do not assume that input values will be chosen maliciously to cause collisions and degrade performance. This has become a published attack vector on internet facing hash tables as used in, for example, web services or even memory cache code in front of a database or so. libsupc++ implements the Murmur hash, which was specifically targeted in a recent paper attacking hash functions. See https://131002.net/siphash/ for the attack code that produces collisions in Murmur2 and Murmur3. libsupc++ should switch the hash function to siphash, the function proposed by the authors of this attack. The same bug should be filed against other user facing hash table implementations in gcc. I can think of Java and Go, but there might be others. It may even make sense to replace the hash code gcc itself uses, as there are now web pages where you can paste code and see which code gcc generates for it, turning this problem into a security issue if someone pastes code with colliding symbols to exploit this problem.
[Bug middle-end/55814] Missed optimization with short-circuit evaluation of always evaluated comparisons/loads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55814
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-12-26
Summary|Missed optimization with|Missed optimization with
|short-circuit evaluation|short-circuit evaluation of
||always evaluated
||comparisons/loads
Ever Confirmed|0 |1
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-12-26
21:46:40 UTC ---
This is a sinking issue. Sinking of loads.
If the code was written as:
_Bool foo(int *a, int *b)
{
return (a[0] b[0]) || (a[1] b[1]) || (a[2] b[2]) || (a[3] b[3]);
}
Instead then it would short-circuit correctly.
[Bug target/55812] Unnecessary TLS accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55812 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|tree-optimization |target --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-12-26 21:54:57 UTC --- TLS accesses are expensive They should not be except for the -fPIC case.
[Bug tree-optimization/55812] Unnecessary TLS accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55812 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-26 Component|target |tree-optimization Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-12-26 21:57:12 UTC --- The issue is rather the call to _ZTH1v ( __tls_init) than anything else. So it is not TLS accesses which are expensive but rather making sure the thread_local variable has been initialized. I think Jason had proposed an attribute for these function calls but it was rejected IIRC.
[Bug tree-optimization/55600] excessive size of vectorized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55600 --- Comment #2 from Ondrej Bilka neleai at seznam dot cz 2012-12-26 22:03:59 UTC --- Yes when 128 is replaced by smaller constant. Attached patch gives on my i5 following: size 32 vector real0m0.224s user0m0.220s sys0m0.000s unroll real0m0.155s user0m0.148s sys0m0.004s size 64 vector real0m0.398s user0m0.396s sys0m0.000s unroll real0m0.380s user0m0.376s sys0m0.000s size 128 vector real0m0.703s user0m0.700s sys0m0.000s unroll real0m0.817s user0m0.812s sys0m0.000s
[Bug tree-optimization/55600] excessive size of vectorized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55600 --- Comment #3 from Ondrej Bilka neleai at seznam dot cz 2012-12-26 22:05:37 UTC --- Created attachment 29052 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29052 benchmark
[Bug c++/55804] [4.7/4.8 regression] GCC omits required call to constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55804 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Version|unknown |4.7.3 Target Milestone|--- |4.8.0
[Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c++/55810] pedantic-errors can not show message for redefined macros in system_header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55810 Jeff Guo guojiufu at gmail dot com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Jeff Guo guojiufu at gmail dot com 2012-12-27 04:03:53 UTC --- closed
[Bug libfortran/48960] OPEN statement modifies NEWUNIT variable on error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48960 --- Comment #5 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2012-12-27 06:37:15 UTC --- Fixed on trunk. I will commit a test case before closing this.
[Bug fortran/48976] INQUIRE with STREAM= not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48976 --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2012-12-27 06:39:08 UTC --- A patch has been submitted for review.
