[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

2012-12-01 Thread pault at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46897



--- Comment #9 from Paul Thomas pault at gcc dot gnu.org 2012-12-01 08:00:32 
UTC ---

Author: pault

Date: Sat Dec  1 08:00:22 2012

New Revision: 194016



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194016

Log:

2012-12-01   Alessandro Fanfarillo alessandro.fanfari...@gmail.com

 Paul Thomas  pa...@gcc.gnu.org



PR fortran/46897

* gfortran.h : Add bit field 'defined_assign_comp' to

symbol_attribute structure.

Add primitive for gfc_add_full_array_ref.

* expr.c (gfc_add_full_array_ref): New function.

(gfc_lval_expr_from_sym): Call new function.

* resolve.c (add_comp_ref): New function.

(build_assignment): New function.

(get_temp_from_expr): New function

(add_code_to_chain): New function

(generate_component_assignments): New function that calls all

the above new functions.

(resolve_code): Call generate_component_assignments.

(check_defined_assignments): New function.

(resolve_fl_derived0): Call check_defined_assignments.

(gfc_resolve): Reset component_assignment_level in case it is

left in a bad state by errors.





* resolve.c (is_sym_host_assoc, resolve_procedure_interface,

resolve_contained_fntype, resolve_procedure_expression,

resolve_elemental_actual, resolve_global_procedure,

is_scalar_expr_ptr, gfc_iso_c_func_interface, resolve_function,

set_name_and_label, gfc_iso_c_sub_interface,

resolve_specific_s0, resolve_operator, compare_bound_mpz_t,

gfc_resolve_character_operator, resolve_typebound_function,

gfc_resolve_expr, forall_index, remove_last_array_ref,

conformable_arrays, resolve_allocate_expr,

resolve_allocate_deallocate, resolve_select_type,

resolve_transfer, resolve_where,

gfc_resolve_where_code_in_forall, gfc_resolve_forall_body,

gfc_count_forall_iterators, resolve_values,

resolve_bind_c_comms, resolve_bind_c_derived_types,

gfc_verify_binding_labels, apply_default_init,

build_default_init_expr, apply_default_init_local,

resolve_fl_var_and_proc, resolve_fl_procedure,

gfc_resolve_finalizers, check_generic_tbp_ambiguity,

resolve_typebound_intrinsic_op, resolve_typebound_procedure,

resolve_typebound_procedures, ensure_not_abstract,

resolve_fl_derived0, resolve_fl_parameter, resolve_symbol,

resolve_equivalence_derived): Remove trailing white space.

* gfortran.h : Remove trailing white space.



2012-12-01   Alessandro Fanfarillo alessandro.fanfari...@gmail.com

 Paul Thomas  pa...@gcc.gnu.org



PR fortran/46897

* gfortran.dg/defined_assignment_1.f90: New test.

* gfortran.dg/defined_assignment_2.f90: New test.

* gfortran.dg/defined_assignment_3.f90: New test.

* gfortran.dg/defined_assignment_4.f90: New test.

* gfortran.dg/defined_assignment_5.f90: New test.





Added:

trunk/gcc/testsuite/gfortran.dg/defined_assignment_1.f90

trunk/gcc/testsuite/gfortran.dg/defined_assignment_2.f90

trunk/gcc/testsuite/gfortran.dg/defined_assignment_3.f90

trunk/gcc/testsuite/gfortran.dg/defined_assignment_4.f90

trunk/gcc/testsuite/gfortran.dg/defined_assignment_5.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/expr.c

trunk/gcc/fortran/gfortran.h

trunk/gcc/fortran/resolve.c

trunk/gcc/testsuite/ChangeLog


[Bug ada/52110] s-osinte.ads:447:09: clockid_t conflicts with declaration at line 194

2012-12-01 Thread pinskia at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52110



Andrew Pinski pinskia at gcc dot gnu.org changed:



   What|Removed |Added



   Target Milestone|3.3.1   |---


[Bug tree-optimization/45216] Rotate expressions not recognized at tree level

2012-12-01 Thread glisse at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45216



--- Comment #8 from Marc Glisse glisse at gcc dot gnu.org 2012-12-01 08:51:12 
UTC ---

(In reply to comment #7)

 unsigned long rotate_left(unsigned long a, unsigned int shift)

 {

 return a  shift | a  (sizeof(a) * 8 - shift);

 }



We have a regression in C++ in 4.8 there. Comparing -O3 -fdump-tree-optimized

in gcc-4.7, g++-4.7 and gcc-4.8:



  D.1708_3 = a_1(D) r shift_2(D);



and in g++-4.8:



  shift.0_2 = (int) shift_1(D);

  _4 = a_3(D)  shift.0_2;

  _5 = 64 - shift_1(D);

  _6 = (int) _5;

  _7 = a_3(D)  _6;

  _8 = _7 | _4;


[Bug gcov-profile/55551] Revision 193999 breaks lto/profiledbootstrap

2012-12-01 Thread markus at trippelsdorf dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1



--- Comment #8 from Markus Trippelsdorf markus at trippelsdorf dot de 
2012-12-01 09:01:33 UTC ---

(In reply to comment #5)

 

 Index: lto-cgraph.c

 ===

 --- lto-cgraph.c(revision 193999)

 +++ lto-cgraph.c(working copy)

 @@ -1345,7 +1345,8 @@ merge_profile_summaries (struct lto_file_decl_data

  /* Save a pointer to the profile_info with the largest

 scaled sum_all and the scale for use in merging the

 histogram.  */

 -if (lto_gcov_summary.sum_all  saved_sum_all)

 +if (!saved_profile_info

 +|| lto_gcov_summary.sum_all  saved_sum_all)

{

  saved_profile_info = file_data-profile_info;

  saved_sum_all = lto_gcov_summary.sum_all;

 

 Can you try adding this patch and seeing if that fixes the issue? I

 will hold off on sending the first fix for review  to see if I should

 add this one.



Yes this fixes the issue. Firefox now builds fine.

Thanks.


[Bug rtl-optimization/55547] Alias analysis does not handle AND addresses correctly

2012-12-01 Thread ubizjak at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55547



Uros Bizjak ubizjak at gmail dot com changed:



   What|Removed |Added



 CC||aoliva at gcc dot gnu.org



--- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2012-12-01 09:21:49 
UTC ---

Reverting r188868 as suggested by Steven [1] solves the problem, too.



CC author of the patch.



[1] http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02549.html


[Bug rtl-optimization/55547] [4.8 Regression] Alias analysis does not handle AND addresses correctly

2012-12-01 Thread ubizjak at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55547



Uros Bizjak ubizjak at gmail dot com changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-12-01

   Target Milestone|--- |4.8.0

Summary|Alias analysis does not |[4.8 Regression] Alias

   |handle AND addresses|analysis does not handle

   |correctly   |AND addresses correctly

 Ever Confirmed|0   |1



--- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2012-12-01 09:23:04 
UTC ---

Confirmed as 4.8 regression.


[Bug c++/55544] -fexcess-precision=standard is not implemented for C++

2012-12-01 Thread joerg.rich...@pdv-fs.de

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55544

--- Comment #7 from Jörg Richter joerg.rich...@pdv-fs.de 2012-12-01 09:53:13 
UTC ---
I see no reference to -fexcess-precision=standard in (garbage sink) bug 323, do
you? So IMHO this is not a dup.


[Bug fortran/55548] SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)

2012-12-01 Thread janus at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55548



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-12-01

 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from janus at gcc dot gnu.org 2012-12-01 10:18:17 UTC ---

I just checked the COUNT_RATE results of a few other compilers that I have

access to:



ifort 12.1.2:

integer(2): 1E3 (1 ms)

integer(4): 1E4 (0.1 ms)

integer(8): 1E6 (1 microsec)



sunf95 12.3:

integer(2): 1E3 (1 ms)

integer(4): 1E3 (1 ms)

integer(8): 1E3 (1 ms)



g95 0.93:

integer(2): 1E4 (0.1 ms)

integer(4): 1E4 (0.1 ms)

integer(8): 1E4 (0.1 ms)



None of them supports integer(16). sunf95 and g95 both give a COUNT_MAX of -1

with integer(2).


[Bug fortran/30609] Calculating masks twice

2012-12-01 Thread tkoenig at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30609



Thomas Koenig tkoenig at gcc dot gnu.org changed:



   What|Removed |Added



 Status|WAITING |NEW



--- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-12-01 
10:31:41 UTC ---

Probably something for front-end optimization,

or improved scalarization, or both.


[Bug fortran/51589] Modification of loop index variable by intent(out) or intent(inout) procedures

2012-12-01 Thread tkoenig at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51589



Thomas Koenig tkoenig at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-12-01 
10:37:43 UTC ---

Fixed with http://gcc.gnu.org/viewcvs?root=gccview=revrev=193793 

which sailed under the flag of PR 30146.


[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

2012-12-01 Thread markus at trippelsdorf dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375



--- Comment #144 from Markus Trippelsdorf markus at trippelsdorf dot de 
2012-12-01 12:39:30 UTC ---

It looks like there is a LTO code-size regression on trunk:

(size of libxul.so, build without elfhack):



gcc lto/pgo : size: 42204584 | Kraken bench: 2723.9ms +/- 0.9%

gcc : size: 34072808 | Kraken bench: 2804.3ms +/- 1.6%

clang lto   : size: 35071848 | Kraken bench: 2804.2ms +/- 1.2%

clang   : size: 36797384 | Kraken bench: 2819.6ms +/- 1.4%


[Bug sanitizer/55521] many instances of ASAN:SIGSEGV failures in g++ testsuite with -fsanitize=address

2012-12-01 Thread jakub at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55521



--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-01 
13:54:49 UTC ---

Or just say asan isn't supported on darwin.


[Bug c/55554] New: GCC generates illegal instruction for optimization level =O1 when invoking casted pointer to function

2012-12-01 Thread avshabanov at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4



 Bug #: 4

   Summary: GCC generates illegal instruction for optimization

level =O1 when invoking casted pointer to function

Classification: Unclassified

   Product: gcc

   Version: 4.2.1

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: avshaba...@gmail.com





Created attachment 28843

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28843

smallest possible program that reproduces an error



The attached program generates an illegal instruction error when compiled on

Mac OS X 10.8.2.



 == GCC info ==

 $ gcc -v

 Using built-in specs.

 Target: i686-apple-darwin11

 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~67/src/configure

--disable-checking --enable-werror

--prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2

--mandir=/share/man --enable-languages=c,objc,c++,obj-c++

--program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/

--with-slibdir=/usr/lib --build=i686-apple-darwin11

--enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~67/dst-llvmCore/Developer/usr/local

--program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11

--target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1

 Thread model: posix

 gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)



 == BUG ==

 To reproduce the bug compile with O1 and higher:

 $ gcc -std=c99 -fomit-frame-pointer -O1 gccbug.c -o gccbug

 $ ./gccbug

 Illegal instruction: 4



 == WORKAROUND ==

 Compile with O0:

 $ gcc -std=c99 -fomit-frame-pointer -O0 -g gccbug.c -o gccbug

 $ ./gccbug

 OK

 OK

 OK

 OK



Please, feel free to contact me if you happen to know *any* (GCC-specific)

workaround for the specified issue.


[Bug c/55554] GCC generates illegal instruction for optimization level =O1 when invoking casted pointer to function

2012-12-01 Thread avshabanov at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4



--- Comment #1 from Alexander S avshabanov at gmail dot com 2012-12-01 
14:30:19 UTC ---

Created attachment 28844

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28844

Preprocessed output


[Bug c/55554] GCC generates illegal instruction for optimization level =O1 when invoking casted pointer to function

2012-12-01 Thread avshabanov at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4



Alexander S avshabanov at gmail dot com changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #2 from Alexander S avshabanov at gmail dot com 2012-12-01 
15:16:13 UTC ---

Please, close this bug as invalid one, there is an error in source code - table

pointer is not initialized with NULL in main.


[Bug middle-end/55555] New: [4.8 Regression] miscompilation at -O2

2012-12-01 Thread Joost.VandeVondele at mat dot ethz.ch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5



 Bug #: 5

   Summary: [4.8 Regression] miscompilation at -O2

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: joost.vandevond...@mat.ethz.ch





Created attachment 28845

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28845

testcase



The attached testcase is miscompiled at -O2, but runs fine at -O1.



To reproduce



gfortran -O2 bug.f90 ; ./a.out

#3  0x400C7E in MAIN__ at bug.f90:97

Aborted



I believe this is a recent regression on trunk. Tested with



gcc version 4.8.0 20121201 (experimental) [trunk revision 194017] (GCC)


[Bug middle-end/55555] [4.8 Regression] miscompilation at -O2 (tree-pre?)

2012-12-01 Thread Joost.VandeVondele at mat dot ethz.ch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5



Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:



   What|Removed |Added



 CC||Joost.VandeVondele at mat

   ||dot ethz.ch

Summary|[4.8 Regression]|[4.8 Regression]

   |miscompilation at -O2   |miscompilation at -O2

   ||(tree-pre?)



--- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 
2012-12-01 15:53:17 UTC ---

Using -O2 -fno-tree-pre fixes the testcase.

Using -O1 -ftree-pre leads to an infinite loop at runtime.


[Bug debug/53860] [4.8 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6254 with -fkeep-inline-functions -fdebug-types-section -g

2012-12-01 Thread hjl at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53860



--- Comment #4 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-12-01 
16:10:44 UTC ---

Author: hjl

Date: Sat Dec  1 16:10:30 2012

New Revision: 194019



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194019

Log:

Fix a typo in PR debug/53860 ChangeLog



Modified:

trunk/gcc/testsuite/ChangeLog


[Bug debug/53860] [4.8 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6254 with -fkeep-inline-functions -fdebug-types-section -g

2012-12-01 Thread hjl.tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53860



H.J. Lu hjl.tools at gmail dot com changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-12-01 16:11:05 
UTC ---

Fixed.


[Bug target/50829] avx extra copy for _mm256_insertf128_pd

2012-12-01 Thread glisse at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50829



Marc Glisse glisse at gcc dot gnu.org changed:



   What|Removed |Added



 CC||glisse at gcc dot gnu.org



--- Comment #9 from Marc Glisse glisse at gcc dot gnu.org 2012-12-01 16:30:23 
UTC ---

The code with intrinsics still has the extra move, but note that this version

without intrinsics generates perfect code:



#include x86intrin.h

__m256d concat(__m128d x){

  __m256d z={x[0],x[1],x[0],x[1]};

  return z;

}


[Bug gcov-profile/55551] Revision 193999 breaks lto/profiledbootstrap

2012-12-01 Thread tejohnson at google dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1



--- Comment #9 from Teresa Johnson tejohnson at google dot com 2012-12-01 
16:38:25 UTC ---

On Sat, Dec 1, 2012 at 1:01 AM, markus at trippelsdorf dot de

gcc-bugzi...@gcc.gnu.org wrote:



 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1



 --- Comment #8 from Markus Trippelsdorf markus at trippelsdorf dot de 
 2012-12-01 09:01:33 UTC ---

 (In reply to comment #5)



 Index: lto-cgraph.c

 ===

 --- lto-cgraph.c(revision 193999)

 +++ lto-cgraph.c(working copy)

 @@ -1345,7 +1345,8 @@ merge_profile_summaries (struct lto_file_decl_data

  /* Save a pointer to the profile_info with the largest

 scaled sum_all and the scale for use in merging the

 histogram.  */

 -if (lto_gcov_summary.sum_all  saved_sum_all)

 +if (!saved_profile_info

 +|| lto_gcov_summary.sum_all  saved_sum_all)

{

  saved_profile_info = file_data-profile_info;

  saved_sum_all = lto_gcov_summary.sum_all;



 Can you try adding this patch and seeing if that fixes the issue? I

 will hold off on sending the first fix for review  to see if I should

 add this one.



 Yes this fixes the issue. Firefox now builds fine.

 Thanks.



This is exactly what is happening. From gcov-dump on test.gcda:



test.gcda: a300:  22:PROGRAM_SUMMARY checksum=0x01847361

test.gcda:  counts=617, runs=5, sum_all=0, run_max=0, sum_max=0

test.gcda:  counter histogram:

test.gcda:  0: num counts=617, min counter=0, cum_counter=0



Not sure why there are no non-zero counters when there are 0 runs,

but the above patch handles this situation.



Will send in patch a little later today when bootstrap tests complete.

Teresa







 --

 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

 --- You are receiving this mail because: ---

 You are on the CC list for the bug.







--

Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413


[Bug bootstrap/55556] New: gcc/exec-tool.in isn't parallel build safe in combined tree

2012-12-01 Thread hjl.tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6



 Bug #: 6

   Summary: gcc/exec-tool.in isn't parallel build safe in combined

tree

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: hjl.to...@gmail.com





When bootstrap GCC and binutils in a combined-tree,

prev-gcc/as has



ORIGINAL_AS_FOR_TARGET=../gas/as-new

...

dir=gas

prog=as-new



if test -x $scriptdir/../$dir/$prog; then

  exec $scriptdir/../$dir/$prog

else

  exec $scriptdir/../prev-$dir/$prog 

fi



When we are building gas parallel with bintils,

gold, gprof and ld, we may run into race condition

that prev-gcc/as checks ../gas/as-new at the same

time when we are creating it.


[Bug middle-end/50713] SLP vs loop: code generated differs (SLP less efficient)

2012-12-01 Thread glisse at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50713



--- Comment #8 from Marc Glisse glisse at gcc dot gnu.org 2012-12-01 16:54:08 
UTC ---

(In reply to comment #5)



We seem to do better now. I see essentially the same code for the vector and

loop versions. The main issue left is for dfma8*, copying the result to the

output register. This looks similar to PR55266.


[Bug middle-end/55555] [4.8 Regression] miscompilation at -O2 (tree-pre?)

2012-12-01 Thread dominiq at lps dot ens.fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5



Dominique d'Humieres dominiq at lps dot ens.fr changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-12-01

 Ever Confirmed|0   |1



--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-12-01 
17:03:37 UTC ---

Revision 192891 (2012-10-28) is OK.

Revision 193261 (2012-11-06) is not.


[Bug middle-end/50713] SLP vs loop: code generated differs (SLP less efficient)

2012-12-01 Thread vincenzo.innocente at cern dot ch

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50713

--- Comment #9 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2012-12-01 17:49:00 UTC ---
indeed.
and now this other vectorizes also on corei7 (yesterday was ok only with AVX)

float64x4_t cross_product(float64x4_t x, float64x4_t y) {
  // yz - zy, zx - xz, xy - yx, 0
  float64x4_t x1200 = (float64x4_t){ x[1], x[2], x[0], x[0] };
  float64x4_t y1200 = (float64x4_t){ y[1], y[2], y[0], y[0] };
  float64x4_t x2010 = (float64x4_t){ x[2], x[0], x[1], x[0] };
  float64x4_t y2010 = (float64x4_t){ y[2], y[0], y[1], y[0] };
  return x1200 * y2010 - x2010 * y1200;
}

the generated code (particularly on AVX) looks comparable to handcrafted one.
(for float32x4 even nicer)
congrats…


[Bug libstdc++/55503] FAIL: 30_threads/condition_variable/members/53841.cc (test for excess errors)

2012-12-01 Thread danglin at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55503



--- Comment #3 from John David Anglin danglin at gcc dot gnu.org 2012-12-01 
18:25:21 UTC ---

Author: danglin

Date: Sat Dec  1 18:25:11 2012

New Revision: 194021



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194021

Log:

PR libstdc++/55503

* testsuite/30_threads/condition_variable/members/53841.cc: Add

hppa*-hp-hpux11* to -pthread dg-options.





Modified:

trunk/libstdc++-v3/ChangeLog

trunk/libstdc++-v3/testsuite/30_threads/condition_variable/members/53841.cc


[Bug middle-end/55555] [4.8 Regression] miscompilation at -O2 (tree-pre?)

2012-12-01 Thread hjl.tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5



H.J. Lu hjl.tools at gmail dot com changed:



   What|Removed |Added



 CC||hubicka at gcc dot gnu.org

   Target Milestone|--- |4.8.0



--- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-12-01 19:17:36 
UTC ---

It is caused by revision 193098:



http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00045.html


[Bug libstdc++/55503] FAIL: 30_threads/condition_variable/members/53841.cc (test for excess errors)

2012-12-01 Thread danglin at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55503



--- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2012-12-01 
19:20:45 UTC ---

Author: danglin

Date: Sat Dec  1 19:20:39 2012

New Revision: 194023



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194023

Log:

PR libstdc++/55503

* testsuite/30_threads/condition_variable/members/53841.cc: Add

hppa*-hp-hpux11* to -pthread dg-options.





Modified:

branches/gcc-4_7-branch/libstdc++-v3/ChangeLog

   

branches/gcc-4_7-branch/libstdc++-v3/testsuite/30_threads/condition_variable/members/53841.cc


[Bug driver/55470] Support -fuse-ld=bfd and -fuse-ld=gold

2012-12-01 Thread hjl.tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55470



H.J. Lu hjl.tools at gmail dot com changed:



   What|Removed |Added



Summary|Enable both ld and gold in  |Support -fuse-ld=bfd and

   |gcc |-fuse-ld=gold



--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-12-01 19:24:38 
UTC ---

A minimum patch is at



http://gcc.gnu.org/git/?p=gcc.git;a=patch;h=ae2d4a12a0be6dd66db9d87d5caddd9496b13981


[Bug libstdc++/55503] FAIL: 30_threads/condition_variable/members/53841.cc (test for excess errors)

2012-12-01 Thread danglin at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55503



John David Anglin danglin at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #5 from John David Anglin danglin at gcc dot gnu.org 2012-12-01 
19:26:06 UTC ---

Fixed.


[Bug ada/52110] s-osinte.ads:447:09: clockid_t conflicts with declaration at line 194

2012-12-01 Thread danglin at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52110



--- Comment #10 from John David Anglin danglin at gcc dot gnu.org 2012-12-01 
19:43:08 UTC ---

Author: danglin

Date: Sat Dec  1 19:43:04 2012

New Revision: 194024



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194024

Log:

PR ada/52110

* s-osinte-hpux-dce.ads: Declare pthread_rwlockattr_t and

pthread_rwlock_t subtypes.  Delete duplicate declaration of clockid_t.

* s-taspri-hpux-dce.ads: Change pragma Atomic (Thread) to comment.





Modified:

trunk/gcc/ada/ChangeLog

trunk/gcc/ada/s-osinte-hpux-dce.ads

trunk/gcc/ada/s-taspri-hpux-dce.ads


[Bug ada/52110] s-osinte.ads:447:09: clockid_t conflicts with declaration at line 194

2012-12-01 Thread danglin at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52110



--- Comment #11 from John David Anglin danglin at gcc dot gnu.org 2012-12-01 
19:45:29 UTC ---

Author: danglin

Date: Sat Dec  1 19:45:24 2012

New Revision: 194025



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194025

Log:

PR ada/52110

* s-osinte-hpux-dce.ads: Declare pthread_rwlockattr_t and

pthread_rwlock_t subtypes.  Delete duplicate declaration of clockid_t.

* s-taspri-hpux-dce.ads: Change pragma Atomic (Thread) to comment.





Modified:

branches/gcc-4_7-branch/gcc/ada/ChangeLog

branches/gcc-4_7-branch/gcc/ada/s-osinte-hpux-dce.ads

branches/gcc-4_7-branch/gcc/ada/s-taspri-hpux-dce.ads


[Bug ada/52110] s-osinte.ads:447:09: clockid_t conflicts with declaration at line 194

2012-12-01 Thread danglin at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52110



John David Anglin danglin at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #12 from John David Anglin danglin at gcc dot gnu.org 2012-12-01 
19:47:08 UTC ---

Fixed.


[Bug fortran/54572] Use libbacktrace library

2012-12-01 Thread jb at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572



--- Comment #15 from Janne Blomqvist jb at gcc dot gnu.org 2012-12-01 
19:48:12 UTC ---

(In reply to comment #14)

 Thanks for the additional info.

 

 #1  0x77bb53be in build_address_map (addrs=0x7fffc710,

 data=0x7fffcf1c, 

 error_callback=0x77ad51f0 error_callback, is_bigendian=0,

 dwarf_str_size=360, 

 dwarf_str=0x77ff71e3 integer(kind=4), dwarf_ranges_size=0, 

 dwarf_ranges=0x77ff6000 Address 0x77ff6000 out of bounds,

 dwarf_abbrev_size=253, 

 dwarf_abbrev=0x77ff708f

 \001\021\001%\016\023\vB\v\003\016\033\016\021\001\022\001\020\006, 

 dwarf_info_size=484, dwarf_info=0x77ff6eab Address 0x77ff6eab out

 of bounds, 

 base_address=optimized out, state=optimized out) at

 ../../../trunk-git/libbacktrace/dwarf.c:1299

 

 That is weird because it is showing the parameters in reverse order.  Is that

 what gdb normally does on your system?  It doesn't seem to do it for other

 functions.



No, I've never seen it before. Then again, before yesterday I had never used

GDB 7.5, only older versions.



 Here gdb says that the value of dwarf_info is out of bounds.  That is not 
 good.

  That is most likely the immediate cause of the problem.  (dwarf_ranges is 
 also

 out of bounds, but that likely doesn't matter as dwarf_ranges_size is zero.)

 

 It looks like it had trouble getting the debug info for the executable file

 itself.  Can you add the output of readelf -S on the executable?



$ readelf -S bt2.g

There are 35 section headers, starting at offset 0x1668:



Section Headers:

  [Nr] Name  Type Address   Offset

   Size  EntSize  Flags  Link  Info  Align

  [ 0]   NULL   

        0 0 0

  [ 1] .interp   PROGBITS 00400200  0200

   001c     A   0 0 1

  [ 2] .note.ABI-tag NOTE 0040021c  021c

   0020     A   0 0 4

  [ 3] .hash HASH 00400240  0240

   0040  0004   A   4 0 8

  [ 4] .dynsym   DYNSYM   00400280  0280

   0108  0018   A   5 1 8

  [ 5] .dynstr   STRTAB   00400388  0388

   01c8     A   0 0 1

  [ 6] .gnu.version  VERSYM   00400550  0550

   0016  0002   A   4 0 2

  [ 7] .gnu.version_rVERNEED  00400568  0568

   0050     A   5 2 8

  [ 8] .rela.dyn RELA 004005b8  05b8

   0018  0018   A   4 0 8

  [ 9] .rela.plt RELA 004005d0  05d0

   0090  0018   A   411 8

  [10] .init PROGBITS 00400660  0660

   000e    AX   0 0 4

  [11] .plt  PROGBITS 00400670  0670

   0070  0010  AX   0 0 16  

  [12] .text PROGBITS 004006e0  06e0

   02f4    AX   0 0 16  

  [13] .fini PROGBITS 004009d4  09d4

   0009    AX   0 0 4   

  [14] .rodata   PROGBITS 004009e0  09e0

   003c     A   0 0 16  

  [15] .eh_frame_hdr PROGBITS 00400a1c  0a1c

   004c     A   0 0 4   

  [16] .eh_frame PROGBITS 00400a68  0a68

   0124     A   0 0 8   

  [17] .init_array   INIT_ARRAY   00600b90  0b90

   0008    WA   0 0 8   

  [18] .fini_array   FINI_ARRAY   00600b98  0b98

   0008    WA   0 0 8

  [19] .jcr  PROGBITS 00600ba0  0ba0

   0008    WA   0 0 8

  [20] .dynamic  DYNAMIC  00600ba8  0ba8

   0220  0010  WA   5 0 8

  [21] .got  PROGBITS 00600dc8  0dc8

   0008  0008  WA   0 0 8

  [22] .got.plt  

[Bug target/50829] avx extra copy for _mm256_insertf128_pd

2012-12-01 Thread glisse at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50829



--- Comment #10 from Marc Glisse glisse at gcc dot gnu.org 2012-12-01 
19:50:28 UTC ---

Created attachment 28846

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28846

Use subreg



Hmm, I don't understand why we use UNSPEC_CAST. I tried the attached patch to

use a subreg instead. It passed bootstrap+testsuite and generates optimal code

for the testcase of this PR.



So, any idea what advantage the unspec has over a subreg? And if none, what is

the best way to use a subreg?


[Bug middle-end/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

2012-12-01 Thread danglin at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52450



--- Comment #13 from John David Anglin danglin at gcc dot gnu.org 2012-12-01 
20:17:22 UTC ---

Author: danglin

Date: Sat Dec  1 20:17:13 2012

New Revision: 194026



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194026

Log:

PR middle-end/52450

* gcc.dg/torture/pr52402.c: Remove xfail for hppa*-*-hpux*.





Modified:

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/gcc.dg/torture/pr52402.c


[Bug target/50829] avx extra copy for _mm256_insertf128_pd

2012-12-01 Thread hjl.tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50829



H.J. Lu hjl.tools at gmail dot com changed:



   What|Removed |Added



 CC||areg.melikadamyan at gmail

   ||dot com, hjl.tools at gmail

   ||dot com



--- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2012-12-01 20:26:32 
UTC ---

(In reply to comment #10)

 Created attachment 28846 [details]

 Use subreg

 

 Hmm, I don't understand why we use UNSPEC_CAST. I tried the attached patch to

 use a subreg instead. It passed bootstrap+testsuite and generates optimal code

 for the testcase of this PR.

 

 So, any idea what advantage the unspec has over a subreg? And if none, what is

 the best way to use a subreg?



subreg didn't work before.


[Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances

2012-12-01 Thread danglin at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195



--- Comment #18 from John David Anglin danglin at gcc dot gnu.org 2012-12-01 
20:36:08 UTC ---

Author: danglin

Date: Sat Dec  1 20:36:04 2012

New Revision: 194027



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194027

Log:

Backport from mainline:

2012-11-12  John David Anglin  dave.ang...@nrc-cnrc.gc.ca



PR target/55195

* config/pa/pa.md (type): Add sibcall and sh_func_adrs insn types.

(in_branch_delay): Don't allow sibcall or sh_func_adrs insns.

(in_nullified_branch_delay): Likewise.

(in_call_delay): Likewise.

Define delay for sibcall insns.  Adjust Z3 and Z4 insn reservations for

new types.  Add opaque cond to mark all calls, sibcalls, dyncalls and

the $$sh_func_adrs call as variable.  Update type of sibcalls and

$$sh_func_adrs call.

* config/pa/pa.c (pa_adjust_insn_length): Revise to return updated

length instead of adjustment.  Handle negative and undefined call

adjustments for insn_default_length.  Remove adjustment for millicode

insn with unfilled delay slot.

(pa_output_millicode_call): Update for revised millicode length.

* config/pa/pa.h (ADJUST_INSN_LENGTH): Revise to set LENGTH.





Modified:

branches/gcc-4_7-branch/gcc/ChangeLog

branches/gcc-4_7-branch/gcc/config/pa/pa.c

branches/gcc-4_7-branch/gcc/config/pa/pa.h

branches/gcc-4_7-branch/gcc/config/pa/pa.md


[Bug c++/55557] New: g++ 4.7 does not issue a warning on the first auto_ptr

2012-12-01 Thread pashev.igor at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7

 Bug #: 7
   Summary: g++ 4.7 does not issue a warning on the first auto_ptr
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pashev.i...@gmail.com


Here is a C++ source code:

# cat -n test.cpp
 1  #include memory
 2  using namespace std;
 3   
 4  int main(int argc, char **argv)
 5  {
 6  auto_ptrint x;
 7  auto_ptrint y;
 8  auto_ptrint z;
 9   
10  return 0;
11  }

Command line to compile it with C++11 standard:
g++-4.7 -std=gnu++11 -Wall -Wextra -Wdeprecated-declarations  -pedantic
test.cpp 

Here is the g++ output:
test.cpp: In function ‘int main(int, char**)’:
test.cpp:7:19: warning: ‘auto_ptr’ is deprecated (declared at
/usr/include/c++/4.7/backward/auto_ptr.h:87) [-Wdeprecated-declarations]
test.cpp:8:19: warning: ‘auto_ptr’ is deprecated (declared at
/usr/include/c++/4.7/backward/auto_ptr.h:87) [-Wdeprecated-declarations]
test.cpp: At global scope:
test.cpp:4:5: warning: unused parameter ‘argc’ [-Wunused-parameter]
test.cpp:4:5: warning: unused parameter ‘argv’ [-Wunused-parameter]

A warning about auto_ptr being deprecated has been issued only for y and z. I
expect a warning for x too.

Moreover, if I leave only one auto_ptr (say, x) I will see no deprecation
warning at all.

It is expected to see warning on every auto_ptr instantiation.


[Bug c++/55557] g++ 4.7 does not issue a warning on the first auto_ptr

2012-12-01 Thread pashev.igor at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7



--- Comment #1 from Igor Pashev pashev.igor at gmail dot com 2012-12-01 
20:46:12 UTC ---

# g++-4.7 --version

g++-4.7 (Debian 4.7.2-4) 4.7.2

Copyright (C) 2012 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


[Bug c++/55558] New: [C++11] decltype on a static member variable of a specialized class in a template function results in an internal compiler error

2012-12-01 Thread devkid at gmx dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8



 Bug #: 8

   Summary: [C++11] decltype on a static member variable of a

specialized class in a template function results in an

internal compiler error

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: dev...@gmx.net





The following piece of code:



templateclass T class A

{

};



class B

{

};



template class AB

{

public:

static int member;

};



templatetypename T void foobar ()

{

typedef decltype (AB::member) myType;

}



produces the following error:



test.cpp: In function 'void foobar()':

test.cpp:17:32: internal compiler error: in finish_decltype_type, at

cp/semantics.c:5274



I accidently used the actual class B instead of the template parameter T in the

foobar function and stumbled upon this error. The error is NOT reproducible

when at least ONE of the following points applies:

- the member variable 'member' is not static

- 'foobar' is not a template method

- the expression inside the decltype statement is inside another expression,

e.g. a function call or as an operand to an operator



The typedef expression is not relevant for the error, it also happens when the

decltype expression is used to declare a variable or as a template parameter.


[Bug c++/55544] -fexcess-precision=standard is not implemented for C++

2012-12-01 Thread joseph at codesourcery dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55544



--- Comment #8 from joseph at codesourcery dot com joseph at codesourcery dot 
com 2012-12-01 20:53:02 UTC ---

On Sat, 1 Dec 2012, joerg.rich...@pdv-fs.de wrote:



 I see no reference to -fexcess-precision=standard in (garbage sink) bug 323, 
 do

 you? So IMHO this is not a dup.



See comment 127 in that bug.


[Bug c++/55558] [C++11] decltype on a static member variable in a template function results in an internal compiler error

2012-12-01 Thread devkid at gmx dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8



--- Comment #1 from Alfred Krohmer devkid at gmx dot net 2012-12-01 20:57:57 
UTC ---

Just figured out that the class does not need to be specialized in order to

reproduce the bug, so the member variable could also be declared in the

unspecialized class.


[Bug c++/55558] [C++11] decltype on a static member variable in a template function results in an internal compiler error

2012-12-01 Thread devkid at gmx dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8



--- Comment #2 from Alfred Krohmer devkid at gmx dot net 2012-12-01 21:18:00 
UTC ---

Well, this is awkward, not even a template class is needed, the following code

also produces the bug:



struct A

{

static int member;

};



templatetypename T void foobar ()

{

typedef decltype (A::member) myType;

}


[Bug sanitizer/55521] many instances of ASAN:SIGSEGV failures in g++ testsuite with -fsanitize=address

2012-12-01 Thread howarth at nitro dot med.uc.edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55521



--- Comment #10 from Jack Howarth howarth at nitro dot med.uc.edu 2012-12-01 
21:37:10 UTC ---

Created attachment 28847

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28847

mockup patch for switching darwin to mac function interpose


[Bug target/54791] AIX-only: Constructors are not called in main program.

2012-12-01 Thread dje at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791



--- Comment #33 from David Edelsohn dje at gcc dot gnu.org 2012-12-01 
21:42:10 UTC ---

You cannot ask legal questions and expect to receive an answer.


[Bug sanitizer/55521] many instances of ASAN:SIGSEGV failures in g++ testsuite with -fsanitize=address

2012-12-01 Thread howarth at nitro dot med.uc.edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55521



--- Comment #11 from Jack Howarth howarth at nitro dot med.uc.edu 2012-12-01 
21:42:41 UTC ---

(In reply to comment #10)

 Created attachment 28847 [details]

 mockup patch for switching darwin to mac function interpose



This patch bootstraps gcc trunk to build libasan with functional mac function

interpose support that passes the asan.exp testsuite without regressions. It

also eliminates PR55521 by avoiding the use of mach_override. It still needs

some cleanup. In particular, I have used 'if 0' to avoid dispatch calls on FSF

gcc which required the missing blocks support. This needs to be replaced by a

test on an appropriate definition specific to FSF gcc (any ideas?). As I

understand it, the use of blocks is for objc which isn't a huge deal at the

moment.


[Bug c++/55558] [C++11] decltype on a static member variable in a template function results in an internal compiler error

2012-12-01 Thread paolo.carlini at oracle dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8



Paolo Carlini paolo.carlini at oracle dot com changed:



   What|Removed |Added



   Severity|major   |normal



--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-12-01 
21:57:04 UTC ---

Works in mainline and never really, worked, at best was rejected without ICE.

I'm adding the testcase and closing the PR.


[Bug c++/55557] no deprecated warning on the first std::auto_ptr

2012-12-01 Thread paolo.carlini at oracle dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7



Paolo Carlini paolo.carlini at oracle dot com changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-12-01

Summary|g++ 4.7 does not issue a|no deprecated warning on

   |warning on the first|the first std::auto_ptr

   |auto_ptr|

 Ever Confirmed|0   |1



--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-12-01 
22:01:35 UTC ---

Weird, doesn't seem a regression though.


[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

2012-12-01 Thread hubicka at ucw dot cz


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375



--- Comment #145 from Jan Hubicka hubicka at ucw dot cz 2012-12-01 22:09:07 
UTC ---

 

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

 

 --- Comment #144 from Markus Trippelsdorf markus at trippelsdorf dot de 
 2012-12-01 12:39:30 UTC ---

 It looks like there is a LTO code-size regression on trunk:

 (size of libxul.so, build without elfhack):

 

 gcc lto/pgo : size: 42204584 | Kraken bench: 2723.9ms +/- 0.9%



About LTO+PGO please be sure that you have the Teresa's fix from this Friday in

your tree.



 gcc : size: 34072808 | Kraken bench: 2804.3ms +/- 1.6%



Is LTO w/o PGO bigger than previous builds?



 clang lto   : size: 35071848 | Kraken bench: 2804.2ms +/- 1.2%

 clang   : size: 36797384 | Kraken bench: 2819.6ms +/- 1.4%


[Bug c++/55557] no deprecated warning on the first std::auto_ptr

2012-12-01 Thread paolo.carlini at oracle dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7



Paolo Carlini paolo.carlini at oracle dot com changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||DUPLICATE



--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-12-01 
22:12:13 UTC ---

Well, this is the old PR33911: only, in that one Benjamin didn't notice that an

additional:



gooint f2b;



finally gets the working.



*** This bug has been marked as a duplicate of bug 33911 ***


[Bug c++/33911] attribute deprecated vs. templates

2012-12-01 Thread paolo.carlini at oracle dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911



Paolo Carlini paolo.carlini at oracle dot com changed:



   What|Removed |Added



 CC||pashev.igor at gmail dot

   ||com



--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-12-01 
22:12:13 UTC ---

*** Bug 7 has been marked as a duplicate of this bug. ***


[Bug target/50829] avx extra copy for _mm256_insertf128_pd

2012-12-01 Thread hjl.tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50829



--- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2012-12-01 22:22:28 
UTC ---

Also see PR 44551.


[Bug target/44551] [missed optimization] AVX vextractf128 after vinsertf128

2012-12-01 Thread glisse at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44551



Marc Glisse glisse at gcc dot gnu.org changed:



   What|Removed |Added



 CC||glisse at gcc dot gnu.org



--- Comment #12 from Marc Glisse glisse at gcc dot gnu.org 2012-12-01 
22:38:15 UTC ---

Hmm, maybe this patch:



http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00373.html



would help with the testcase in comment #11 ? I'll have to try and resurrect

it.


[Bug c++/55558] [C++11] decltype on a static member variable in a template function results in an internal compiler error

2012-12-01 Thread paolo at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8



--- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 
2012-12-01 22:52:35 UTC ---

Author: paolo

Date: Sat Dec  1 22:52:27 2012

New Revision: 194036



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194036

Log:

2012-12-01  Paolo Carlini  paolo.carl...@oracle.com



PR c++/8

* g++.dg/cpp0x/decltype46.C: New.



Added:

trunk/gcc/testsuite/g++.dg/cpp0x/decltype46.C

Modified:

trunk/gcc/testsuite/ChangeLog


[Bug c++/55559] New: Marshalling double through union with inlines, incorrect behavior with -O2

2012-12-01 Thread mpreda at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9



 Bug #: 9

   Summary: Marshalling double through union with inlines,

incorrect behavior with -O2

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mpr...@gmail.com





Created attachment 28848

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28848

.ii preprocessed source



The following simple program returns different results depending on being

compiled with / without -O2.



The expected result is (unsigned)-1, but the observed result with -O2 is 0.



//--

union V {

long long v;

double dbl;

};



inline long long VAL_NUM(double d)   { return V{dbl: d}.v; }

inline double GET_NUM(long long val) { return V{v: val}.dbl; }



int main() {

return (unsigned) GET_NUM(VAL_NUM(-1));

}

//-



gcc -v -save-temps -std=c++11 -Wall bug.cpp

Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper

Target: x86_64-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro

4.7.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs

--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr

--program-suffix=-4.7 --enable-shared --enable-linker-build-id

--with-system-zlib --libexecdir=/usr/lib --without-included-gettext

--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7

--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu

--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object

--enable-plugin --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

Thread model: posix

gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) 

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-mtune=generic'

'-march=x86-64'

 /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1plus -E -quiet -v -imultiarch

x86_64-linux-gnu -D_GNU_SOURCE bug.cpp -mtune=generic -march=x86-64 -std=c++11

-Wall -fpch-preprocess -fstack-protector -o bug.ii

ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu

ignoring nonexistent directory

/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include

#include ... search starts here:

#include ... search starts here:

 /usr/include/c++/4.7

 /usr/include/c++/4.7/x86_64-linux-gnu

 /usr/include/c++/4.7/backward

 /usr/lib/gcc/x86_64-linux-gnu/4.7/include

 /usr/local/include

 /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed

 /usr/include/x86_64-linux-gnu

 /usr/include

End of search list.

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-mtune=generic'

'-march=x86-64'

 /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1plus -fpreprocessed bug.ii -quiet

-dumpbase bug.cpp -mtune=generic -march=x86-64 -auxbase bug -Wall -std=c++11

-version -fstack-protector -o bug.s

GNU C++ (Ubuntu/Linaro 4.7.2-2ubuntu1) version 4.7.2 (x86_64-linux-gnu)

compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.0-p3,

MPC version 0.9

warning: GMP header version 5.0.2 differs from library version 5.0.5.

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

GNU C++ (Ubuntu/Linaro 4.7.2-2ubuntu1) version 4.7.2 (x86_64-linux-gnu)

compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.0-p3,

MPC version 0.9

warning: GMP header version 5.0.2 differs from library version 5.0.5.

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

Compiler executable checksum: 521527ea42f0901bf839bcaad0cb13e6

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-mtune=generic'

'-march=x86-64'

 as -v --64 -o bug.o bug.s

GNU assembler version 2.22.90 (x86_64-linux-gnu) using BFD version (GNU

Binutils for Ubuntu) 2.22.90.20120924

COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/

LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../:/lib/:/usr/lib/

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-mtune=generic'

'-march=x86-64'

 /usr/lib/gcc/x86_64-linux-gnu/4.7/collect2 --sysroot=/ --build-id

--no-add-needed --as-needed --eh-frame-hdr -m elf_x86_64 --hash-style=gnu

-dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro

/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crt1.o

/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crti.o


[Bug rtl-optimization/55158] [4.8 Regression] [IA64] ICE: segv in schedule_region

2012-12-01 Thread gary at intrepid dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158



--- Comment #10 from Gary Funck gary at intrepid dot com 2012-12-01 23:17:00 
UTC ---

(In reply to comment #9)

 OK, I applied it to our autotester and we will see tomorrow if it fixes the

 segfaults.

 If so, can I go ahead and commit it?

 

 Honza



Ping: was this patch tested and then applied?



thanks.


[Bug sanitizer/55521] many instances of ASAN:SIGSEGV failures in g++ testsuite with -fsanitize=address

2012-12-01 Thread howarth at nitro dot med.uc.edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55521



Jack Howarth howarth at nitro dot med.uc.edu changed:



   What|Removed |Added



  Attachment #28847|0   |1

is obsolete||



--- Comment #12 from Jack Howarth howarth at nitro dot med.uc.edu 2012-12-01 
23:27:17 UTC ---

Created attachment 28849

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28849

preliminary mac function interpose patch


[Bug sanitizer/55521] many instances of ASAN:SIGSEGV failures in g++ testsuite with -fsanitize=address

2012-12-01 Thread howarth at nitro dot med.uc.edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55521



--- Comment #13 from Jack Howarth howarth at nitro dot med.uc.edu 2012-12-01 
23:50:15 UTC ---

Created attachment 28850

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28850

revised preliminary mac function interpose patch



Add missing removal of usage of USING_MACH_OVERRIDE from

libsanitizer/interception/Makefile.am.


[Bug sanitizer/55521] many instances of ASAN:SIGSEGV failures in g++ testsuite with -fsanitize=address

2012-12-01 Thread howarth at nitro dot med.uc.edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55521



Jack Howarth howarth at nitro dot med.uc.edu changed:



   What|Removed |Added



  Attachment #28849|0   |1

is obsolete||

  Attachment #28850|0   |1

is obsolete||



--- Comment #14 from Jack Howarth howarth at nitro dot med.uc.edu 2012-12-01 
23:51:05 UTC ---

Created attachment 28851

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28851

revised preliminary mac function interpose patch


[Bug tree-optimization/55559] Marshalling double through union with inlines, incorrect behavior with -O2

2012-12-01 Thread pinskia at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9



Andrew Pinski pinskia at gcc dot gnu.org changed:



   What|Removed |Added



   Keywords||wrong-code

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-12-02

  Component|c++ |tree-optimization

 Ever Confirmed|0   |1

  Known to fail||4.7.0, 4.8.0



--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-12-02 
00:09:30 UTC ---

CCP is broken:

Visiting statement:

D.1625_1 = D.1625_8;

Lattice value changed to CONSTANT -4616189618054758400.  Adding SSA edges to

worklist.



Visiting statement:

D.1631_7 = VIEW_CONVERT_EXPRdouble(D.1625_1);

which is likely CONSTANT

Lattice value changed to CONSTANT -1.0e+0.  Adding SSA edges to worklist.



Visiting statement:

D.1631_9 = D.1631_7;

Lattice value changed to CONSTANT -1.0e+0.  Adding SSA edges to worklist.



Visiting statement:

D.1631_2 = D.1631_9;

Lattice value changed to CONSTANT -1.0e+0.  Adding SSA edges to worklist.



Visiting statement:

D.1610_3 = (unsigned int) D.1631_2;

which is likely CONSTANT

Lattice value changed to CONSTANT 0.  Adding SSA edges to worklist.





I think this is a regression if the code does not use extended  initializer

lists but I have not tested it though.


[Bug sanitizer/55521] many instances of ASAN:SIGSEGV failures in g++ testsuite with -fsanitize=address

2012-12-01 Thread howarth at nitro dot med.uc.edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55521



--- Comment #15 from Jack Howarth howarth at nitro dot med.uc.edu 2012-12-02 
02:57:46 UTC ---

Patch to switch libsanitizer on darwin from mach_override to mac interpose

functions submitted to gcc-patches at

http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00055.html.


[Bug sanitizer/55521] many instances of ASAN:SIGSEGV failures in g++ testsuite with -fsanitize=address

2012-12-01 Thread howarth at nitro dot med.uc.edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55521



--- Comment #16 from Jack Howarth howarth at nitro dot med.uc.edu 2012-12-02 
05:38:09 UTC ---

Using mac function interposition on x86_64-apple-darwin12 produces only 8

remaining g++ testsuite failures emitting ASAN:SIGSEGV messages compared to 10

seen in the g++ testsuite under x86_64 Fedora 15. Also on

x86_64-apple-darwin12, the switch from mach_override to mac function

interposition reduces the unexpected failures in the g++ testsuite from 841 to

323. This is still far more than seen under x86_64 Fedora 15 (which shows 107)

but still is a major improvement over mach_override.


[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows

2012-12-01 Thread nightstrike at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659



nightstrike nightstrike at gmail dot com changed:



   What|Removed |Added



 CC||ktietz at gcc dot gnu.org,

   ||nightstrike at gmail dot

   ||com



--- Comment #5 from nightstrike nightstrike at gmail dot com 2012-12-02 
05:51:25 UTC ---

1(In reply to comment #3)

 On Fri, Oct 26, 2012 at 8:05 AM, rguenther at suse dot de

 gcc-bugzi...@gcc.gnu.org wrote:

 

  Fact is that all this stuff happens because gmp.h is not included

  from system.h ...

 

 I broke Ada when I tried it.  I don't remember the details, but it

 seemed tedious to fix.

 

 

 Diego.



So instead you broke Windows?


[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

2012-12-01 Thread markus at trippelsdorf dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375



--- Comment #146 from Markus Trippelsdorf markus at trippelsdorf dot de 
2012-12-02 07:36:02 UTC ---

(In reply to comment #145)

  

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

  

  --- Comment #144 from Markus Trippelsdorf markus at trippelsdorf dot de 
  2012-12-01 12:39:30 UTC ---

  It looks like there is a LTO code-size regression on trunk:

  (size of libxul.so, build without elfhack):

  

  gcc lto/pgo : size: 42204584 | Kraken bench: 2723.9ms +/- 0.9%

 

 About LTO+PGO please be sure that you have the Teresa's fix from this Friday 
 in

 your tree.



Yes, my tree already included this fix and also the fix from bug 1.



  gcc : size: 34072808 | Kraken bench: 2804.3ms +/- 1.6%

 

 Is LTO w/o PGO bigger than previous builds?



Couldn't tell, because it doesn't link:



/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld:

warning: hidden symbol 'pixman_add_triangles' in

/var/tmp/moz-build-dir/toolkit/library/../../gfx/cairo/libpixman/src/pixman-trap.o

is referenced by DSO /usr/lib64/libcairo.so

/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld:

error: /tmp/cc0oq4BG.ltrans1.ltrans.o: requires dynamic R_X86_64_PC32 reloc

against '_ZN12SkAnnotationC1ER23SkFlattenableReadBuffer' which may overflow at

runtime; recompile with -fPIC

/tmp/cc0oq4BG.ltrans0.ltrans.o:cc0oq4BG.ltrans0.o:function SharedStub: error:

undefined reference to 'PrepareAndDispatch'

/tmp/cc0oq4BG.ltrans1.ltrans.o:cc0oq4BG.ltrans1.o:function

SkAnnotation::CreateProc(SkFlattenableReadBuffer) [clone .local.7828.1055099]:

error: undefined reference to

'SkAnnotation::SkAnnotation(SkFlattenableReadBuffer)'

collect2: error: ld returned 1 exit status



The undefined reference to PrepareAndDispatch is easily fixed by

an __attribute__ ((used)).

Do you have an idea on how to fix the

SkAnnotation::SkAnnotation(SkFlattenableReadBuffer) issue?


[Bug other/55560] New: fesetround(FE_DOWNWARD) causes cos() to return values outside the range of -1 to +1

2012-12-01 Thread pj at ecstaticlyrics dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55560



 Bug #: 55560

   Summary: fesetround(FE_DOWNWARD) causes cos() to return values

outside the range of -1 to +1

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: other

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: p...@ecstaticlyrics.com





Created attachment 28852

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28852

Contents of /proc/cpuinfo



Simple test program:



#include stdio.h

#include math.h

#include fenv.h



void main() {

  double a, c;

  fesetround(FE_DOWNWARD);

  for (a = -M_PI; a = +M_PI; a += 0.01) {

c = cos(a);

if (c  -1.0 || c  +1.0) {

  printf(cos(%f) is not %f\n, a, c);

};

  };

};



Compile like so: gcc -o test test.c -lm



Expected output is nothing at all, since cos() always returns values between

-1.0 and +1.0.  The actual output, however, is 20,009 lines.  Here are the

first ten:



cos(-3.141593) is not -1.000485

cos(2.430171) is not 3614403565883090812337301068370710204239577088.00

cos(2.430172) is not 195176399637579483727029815821181674649563430912.00

cos(2.430173) is not 386738395709080693943503989636585388708949131264.00

cos(2.430174) is not 578300391780195078044017318793663580791807934464.00

cos(2.430175) is not 769862387850731413470826575343659276213015281664.00

cos(2.430176) is not 961424383920497666369804385270998542397395173376.00

cos(2.430177) is not 1152986379989302370794292276806879317292807618560.00

cos(2.430178) is not 1344548376056954223056908607395862930425122914304.00

cos(2.430179) is not 1536110372123261919470271734482510711320211357696.00



The problem disappears if the test program is compiled with -m32 or if

fesetround(FE_DOWNWARD) is removed.


[Bug other/55560] fesetround(FE_DOWNWARD) causes cos() to return values outside the range of -1 to +1

2012-12-01 Thread pinskia at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55560



Andrew Pinski pinskia at gcc dot gnu.org changed:



   What|Removed |Added



   Severity|major   |normal



--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-12-02 
07:40:16 UTC ---

I think this is a bug in the glibc version you are using rather than GCC.  Have

you tried a newer version of glibc like say 2.16?  



Oh what version of glibc are you using?  find out by invoking /lib/libc.so.6 .