[Bug c++/58057] gcc lexer cannot parse extern "\x43" void blah() with option -std=c++0x;

2013-08-02 Thread 3dw4rd at verizon dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057

--- Comment #12 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
On 08/02/2013 01:47 PM, paolo.carlini at oracle dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057
>
> --- Comment #11 from Paolo Carlini  ---
> Ed, your analysis matches my intuition, but the error message is still very
> poor: to the user something like "... before STRING_USERDEF..." makes no sense
> at all. Can we improve it?
>
I agree that a better message is desirable.
I am starting to track this down and fix it.
(Any ideas?)

Ed


[Bug target/58067] ICE in GFortran recog.c:2158

2013-08-02 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067

Andrew Pinski  changed:

   What|Removed |Added

 Target||aarch64-linux-gnu
  Component|fortran |target

--- Comment #1 from Andrew Pinski  ---
I don't think -mcmodel=large support has been added for TLS yet.


[Bug tree-optimization/58069] New: ICE in tree_ssa_unswitch_loops at -O3 in 32 bit mode

2013-08-02 Thread su at cs dot ucdavis.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58069

Bug ID: 58069
   Summary: ICE in tree_ssa_unswitch_loops at -O3 in 32 bit mode
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux in 32-bit mode only. This is a regression from 4.8.x.

It may be related to 58018, which also manifests in 64-bit mode though. 

This testcase is also a lot more complex than the one for 58018; I wasn't able
to reduce it further. 


$ gcc-trunk -v
gcc version 4.9.0 20130801 (experimental) [trunk revision 201397] (GCC) 
$ gcc-trunk -m64 -O3 reduced.c
/tmp/ccHrLaas.o: In function `main':
reduced.c:(.text.startup+0x7): undefined reference to `fn2'
reduced.c:(.text.startup+0x18): undefined reference to `fn3'
reduced.c:(.text.startup+0x54): undefined reference to `fn7'
reduced.c:(.text.startup+0x76): undefined reference to `fn4'
reduced.c:(.text.startup+0x87): undefined reference to `fn6'
reduced.c:(.text.startup+0x96): undefined reference to `fn5'
collect2: error: ld returned 1 exit status
$ gcc-trunk -m32 -O2 reduced.c
/tmp/cc6hsIbp.o: In function `main':
reduced.c:(.text.startup+0x55): undefined reference to `fn2'
reduced.c:(.text.startup+0x72): undefined reference to `fn4'
reduced.c:(.text.startup+0xfe): undefined reference to `fn7'
reduced.c:(.text.startup+0x117): undefined reference to `fn3'
reduced.c:(.text.startup+0x127): undefined reference to `fn6'
reduced.c:(.text.startup+0x137): undefined reference to `fn5'
collect2: error: ld returned 1 exit status
$ gcc-4.8 -m32 -O3 reduced.c
/tmp/ccCehBNw.o: In function `main':
reduced.c:(.text.startup+0xa): undefined reference to `fn2'
reduced.c:(.text.startup+0x18): undefined reference to `fn3'
reduced.c:(.text.startup+0x52): undefined reference to `fn7'
reduced.c:(.text.startup+0x6f): undefined reference to `fn4'
reduced.c:(.text.startup+0x7e): undefined reference to `fn6'
reduced.c:(.text.startup+0x8e): undefined reference to `fn5'
collect2: error: ld returned 1 exit status
$ gcc-trunk -m32 -O3 reduced.c
reduced.c: In function ‘main’:
reduced.c:43:5: internal compiler error: Segmentation fault
 int main ()
 ^
0x7d52ef crash_signal
../../gcc-trunk/gcc/toplev.c:334
0x7fd37b ssa_default_def(function*, tree_node*)
../../gcc-trunk/gcc/tree-dfa.c:314
0x7fd640 get_or_create_ssa_default_def(function*, tree_node*)
../../gcc-trunk/gcc/tree-dfa.c:362
0x8168ea get_reaching_def
../../gcc-trunk/gcc/tree-into-ssa.c:1184
0x81ca5a maybe_replace_use
../../gcc-trunk/gcc/tree-into-ssa.c:1784
0x81ca5a rewrite_update_stmt
../../gcc-trunk/gcc/tree-into-ssa.c:1967
0x81ca5a rewrite_update_enter_block
../../gcc-trunk/gcc/tree-into-ssa.c:2136
0xb3716a walk_dominator_tree(dom_walk_data*, basic_block_def*)
../../gcc-trunk/gcc/domwalk.c:210
0x8155f3 rewrite_blocks
../../gcc-trunk/gcc/tree-into-ssa.c:2216
0x81bd0e update_ssa(unsigned int)
../../gcc-trunk/gcc/tree-into-ssa.c:3303
0xb9e4da tree_unswitch_single_loop
../../gcc-trunk/gcc/tree-ssa-loop-unswitch.c:358
0xb9eac8 tree_ssa_unswitch_loops()
../../gcc-trunk/gcc/tree-ssa-loop-unswitch.c:116
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 



---


int a, b, c, e, p;
static int *d = &c;

static int foo (int p)
{
  int f, i, j = 0, *g = &a; 
  int h[] = { 0, 0, 0, 1, 0, 0, 0, 0, 1 };
  for (i = 0; i < 1; i++)
{
  int *k = &b;
  {
int **l = 0;
int ***m = &l;
int n = &m;
j || fn2 ();
*n = 0;
if (*g)
  fn3 ();
else
  {
*k = 0;
fn4 ();
  }
  }
  *g = *k;

  for (j = 8; j >= 0; j--)
{
  for (f = 3; f <= 8; f++)
*d |= h[f] && *k;
  if (e)
{
  fn5 (fn6 () && 1);
  return 0;
}
  int *o = &h[7];
  *d = -1L <= ((*o ^= *k) && f);
}
  fn7 (p <= (a & 5UL));
}
}

int main ()
{
  p = foo (1);
  return 0;
}

[Bug rtl-optimization/58068] New: ICE in execute_strength_reduction at -O3 (both 32-bit and 64-bit modes)

2013-08-02 Thread su at cs dot ucdavis.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58068

Bug ID: 58068
   Summary: ICE in execute_strength_reduction at -O3 (both 32-bit
and 64-bit modes)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux (both 32-bit and 64-bit modes). This is a regression from
4.8.x.

$ gcc-trunk -v
gcc version 4.9.0 20130801 (experimental) [trunk revision 201397] (GCC) 
$ gcc-trunk -O2 -c reduced.c
$ gcc-trunk -O3 -c reduced.c
reduced.c: In function ‘foo’:
reduced.c:4:6: internal compiler error: Segmentation fault
 void foo ()
  ^
0x7d52ef crash_signal
../../gcc-trunk/gcc/toplev.c:334
0x5d8ddb dominated_by_p(cdi_direction, basic_block_def const*, basic_block_def
const*)
../../gcc-trunk/gcc/dominance.c:974
0xb3f0c6 phi_add_costs
../../gcc-trunk/gcc/gimple-ssa-strength-reduction.c:2192
0xb4125d replace_uncond_cands_and_profitable_phis
../../gcc-trunk/gcc/gimple-ssa-strength-reduction.c:2242
0xb426d3 analyze_candidates_and_replace
../../gcc-trunk/gcc/gimple-ssa-strength-reduction.c:3371
0xb426d3 execute_strength_reduction
../../gcc-trunk/gcc/gimple-ssa-strength-reduction.c:3458
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ gcc-4.8 -O3 -c reduced.c
$ 



--


int a, c;
unsigned int b;

void foo ()
{
  for (; b < 2; b++)
if (++c * -1 > 0)
  for (;; a++)
;
}

[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64

2013-08-02 Thread ppluzhnikov at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

--- Comment #2 from Paul Pluzhnikov  ---
(In reply to Andrew Pinski from comment #1)

> Which most Linux distro default to anyways ...

Ubuntu 12.04.1 LTS doesn't.
Configuring trunk GCC on it doesn't default to GNU2 TLS either.

What is the way to turn it on?


[Bug fortran/58067] New: ICE in GFortran recog.c:2158

2013-08-02 Thread woodard at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067

Bug ID: 58067
   Summary: ICE in GFortran recog.c:2158
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: woodard at redhat dot com

Created attachment 30602
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30602&action=edit
a flattened self contained version of the NAS benchmark.

When I try to compile one of the NAS benchmark's with -fpic and -mcmodel=large
with GCC 4.8.0 up through the current trunk (20130802) I get an internal
compiler error. This looks rather similar to PR56797 but that particular bug
seems to have been only on ARM and this occurs on x86_64. So it may be that
PR56797 is more expansive than initially thought or this might be a different
bug. I can't tell.

[ben@snog BT-MZ]$ PATH=/home/ben/Work/gcc-test/bin/:$PATH gfortran -c
-save-temps -O2 -g -fopenmp -fpic -mcmodel=large bt-all.f
bt-all.f: In function ‘MAIN__._omp_fn.1’:
bt-all.f:305:0: note: non-delegitimized UNSPEC UNSPEC_PLTOFF (9) found in
variable location
do iz = 1, proc_num_zones
 ^
bt-all.f:305:0: note: non-delegitimized UNSPEC UNSPEC_PLTOFF (9) found in
variable location
bt-all.f: In function ‘MAIN__._omp_fn.0’:
bt-all.f:449:0: error: unrecognizable insn:
  999   continue
 ^
(call_insn/u 52 51 53 2 (parallel [
(set (reg:DI 0 ax)
(call:DI (mem:QI (symbol_ref:DI ("__tls_get_addr")) [0 S1 A8])
(const_int 0 [0])))
(unspec:DI [
(symbol_ref:DI ("omp_cmn2a_") [flags 0x10] )
] UNSPEC_TLS_GD)
]) bt-all.f:48 -1
 (expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil))
(nil))
bt-all.f:449:0: internal compiler error: in extract_insn, at recog.c:2158
0x922c1a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../.././gcc/rtl-error.c:109
0x922c49 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../.././gcc/rtl-error.c:117
0x8f966a extract_insn(rtx_def*)
../.././gcc/recog.c:2158
0x7bdbee instantiate_virtual_regs_in_insn
../.././gcc/function.c:1609
0x7bdbee instantiate_virtual_regs
../.././gcc/function.c:1926
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

This problem doesn't seem to occur except when you have -fpic and
-mcmodel=large. Changing the memory model to medium or small or removing the
-fpic allows the code to compile.

Attached is a flattened self contained version of the NAS benchmark my fortran
is not good enough to boil it down into a more parsimonious reproducer.

[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64

2013-08-02 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
> However, it appears to have only been fully implemented for the GNU2 TLS
>  descriptor style ...

Which most Linux distro default to anyways ...


[Bug tree-optimization/57994] Constant folding of infinity

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |4.9.0

--- Comment #14 from Paolo Carlini  ---
Let's see.


[Bug c/58066] New: GCC mis-compiles access to TLS variable with -fPIC on x86_64

2013-08-02 Thread ppluzhnikov at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

Bug ID: 58066
   Summary: GCC mis-compiles access to TLS variable with -fPIC on
x86_64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

Google ref: b/10151411

Reproduced with current trunk, but is broken since at least gcc-4.3.1.

On Linux/x86_64, libstdc++.so.6 __cxa_get_globals looks like so:

Dump of assembler code for function __cxa_get_globals:
   0x000cb430 <+0>: lea0x233131(%rip),%rdi
   0x000cb437 <+7>: callq  0x4f570 <__tls_get_addr@plt>
   0x000cb43c <+12>:add$0x0,%rax
   0x000cb442 <+18>:retq   

This calls external function __tls_get_addr with mis-aligned stack.
__tls_get_addr may itself call malloc, and malloc is user-replaceable,
and may assume that stack is properly aligned (and crash when it isn't).

Trivial test case:


static __thread char ccc;
extern "C" void* __cxa_get_globals() throw()
{
 return &ccc;
}

  g++ -fPIC -S -O2 t.cc

results in:

__cxa_get_globals:
   leaq_ZL3ccc@tlsld(%rip), %rdi
   call__tls_get_addr@PLT
   addq$_ZL3ccc@dtpoff, %rax
   ret



Ian Lance Taylor says:

  There is code in the i386 backend that is designed to avoid this.
  However, it appears to have only been fully implemented for the GNU2 TLS
  descriptor style ...

  I suspect that the right fix is to add the line

 ix86_tls_descriptor_calls_expanded_in_cfun = true;

  to tls_global_dynamic_64_ and tls_local_dynamic_base_64_
  in gcc/config/i386/i386.md.


[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-08-02 Thread bernd.edlinger at hotmail dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #16 from Bernd Edlinger  ---
(In reply to Martin Jambor from comment #15)
> Anyway, the policy of GCC
> seems to be that the default of MALLOC_ABI_ALIGNMENT is ultra-safe and
> targets should override it.  So I would suggest, again :-), that you open a
> separate bug and CC ARM maintainers that should take care of it.

Done. Bug#58065


[Bug target/58065] ARM MALLOC_ABI_ALIGNMENT is wrong

2013-08-02 Thread bernd.edlinger at hotmail dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065

--- Comment #4 from Bernd Edlinger  ---
Created attachment 30601
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30601&action=edit
Proposed patch


[Bug target/58065] ARM MALLOC_ABI_ALIGNMENT is wrong

2013-08-02 Thread bernd.edlinger at hotmail dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065

--- Comment #3 from Bernd Edlinger  ---
Created attachment 30600
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30600&action=edit
correct compiler output with patch


[Bug target/58065] ARM MALLOC_ABI_ALIGNMENT is wrong

2013-08-02 Thread bernd.edlinger at hotmail dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065

--- Comment #2 from Bernd Edlinger  ---
Created attachment 30599
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30599&action=edit
compiler output without this patch


[Bug target/58065] ARM MALLOC_ABI_ALIGNMENT is wrong

2013-08-02 Thread bernd.edlinger at hotmail dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065

--- Comment #1 from Bernd Edlinger  ---
Created attachment 30598
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30598&action=edit
test case


[Bug target/58065] New: ARM MALLOC_ABI_ALIGNMENT is wrong

2013-08-02 Thread bernd.edlinger at hotmail dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065

Bug ID: 58065
   Summary: ARM MALLOC_ABI_ALIGNMENT is wrong
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
Target: arm*-*-*

the ARM target architecture does not define the MALLOC_ABI_ALIGNMENT,
therefore the default is used as BITS_PER_WORD, 32 in this case.

This produces sometimes suboptimal code, because the front-end
assumes that the function malloc() returns only word-aligned pointers,
which is likely wrong. I have not found any specific requirements
on the malloc alignment in the AAPCS document at
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf
but I believe that the intention is to align everything including stack
pointers to 8 bytes.

Therefore I would suggest the attached patch which defines
MALLOC_ABI_ALIGNMENT as BIGGEST_ALIGNMENT, which is 64 bits.

As a proof that this has indeed some subtle influence on the generated code
I attach a test case. The function foo is called by bar, and bar uses
malloc to allocate the memory, with compiler options "-O3 -g0 -mfpu=neon
-mfloat-abi=softfp" the function foo is inlined into bar,
but the inlined version does not use vstr instructions any more, because
the front-end does assume that malloc returns 4 byte aligned memory.

If that was really true, foo must fail, if it is called without inlining.
Therefore this code is just clumsy and less optimal than it could be.


[Bug fortran/58064] New: Cannot compile gcc-4.8.1 by gcc-3.4.6

2013-08-02 Thread shinn.wu at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58064

Bug ID: 58064
   Summary: Cannot compile gcc-4.8.1 by gcc-3.4.6
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shinn.wu at gmail dot com

Created attachment 30597
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30597&action=edit
config.log

When compiling gcc-4.8.1 from 

SunOS xxx 5.11 11.1 i86pc i386 i86pc

the error occurred after two hours.


[Bug libstdc++/57885] unordered_map find slower in 4.8.1 than 4.7.3 with integer key

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57885

--- Comment #8 from Paolo Carlini  ---
Francois, you attached to the wrong bug.


[Bug libstdc++/57840] ::std ::result_of is undocumented

2013-08-02 Thread fdumont at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57840

--- Comment #2 from François Dumont  ---
Created attachment 30596
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30596&action=edit
The modified hashtable implementation

To replace hashtable.h in include/bits

[Bug libstdc++/57840] ::std ::result_of is undocumented

2013-08-02 Thread fdumont at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57840

François Dumont  changed:

   What|Removed |Added

 CC||fdumont at gcc dot gnu.org

--- Comment #1 from François Dumont  ---
Created attachment 30595
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30595&action=edit
To replace hashtable_policy.h in include/bits folder

[Bug libstdc++/57885] unordered_map find slower in 4.8.1 than 4.7.3 with integer key

2013-08-02 Thread fdumont at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57885

--- Comment #7 from François Dumont  ---
I had a try and the result is not good. I attached the modified implementation
if you want to have a try even if it is not perfect cause there are some
exception safety issue.

With the current implementation on my device I have the following result:

Container:std::unordered_map  Key:int
Insertion: 23521 13329 13899 13544 13870  min=13329 max=23521
Lookup:29246 29120 32406 29524 29065  min=29065 max=32406

Container:std::tr1::unordered_map  Key:int
Insertion: 24410 10392 10404 10226 10180  min=10180 max=24410
Lookup:22728 19985 20314 19918 20741  min=19918 max=22728

With the modified solution using empty nodes to mark end of bucket I had:

Container:std::unordered_map  Key:int
Insertion: 30080 19250 17861 18955 18350  min=17861 max=30080
Lookup:35884 36518 38623 35896 36661  min=35884 max=38623

Container:std::tr1::unordered_map  Key:int
Insertion: 28912 10112 10046 10447 13026  min=10046 max=28912
Lookup:22515 20114 19517 20400 19543  min=19517 max=22515

I fear that the memory overhead is not only impacting memory. It is surely not
good for memory cache. If you want to give it a try and check generated
assembly, additional testq should have vanish.

François

[Bug c++/58063] New: default arguments evaluated twice per call

2013-08-02 Thread plokinom at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063

Bug ID: 58063
   Summary: default arguments evaluated twice per call
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: plokinom at gmail dot com

% cat try.cc
#include 

void f(bool x = !(std::cout << "hi!\n")) {
std::cout << x << '\n';
}

int main() {
f();
}

% g++ try.cc
% ./a.out 
hi!
hi!
0

My question: Why is the default argument evaluated twice for each call to f()?

Is this allowed by the standard or a bug in g++?


% g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/mauke/usr/local/libexec/gcc/i686-pc-linux-gnu/4.8.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.8.1/configure --prefix=/home/mauke/usr/local
--with-arch=native --with-tune=native --enable-__cxa_atexit
--enable-languages=c,c++,go --disable-nls
Thread model: posix
gcc version 4.8.1 (GCC)


[Bug c++/58054] 11.3 Friends, example from standard not compiled

2013-08-02 Thread dushistov at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58054

--- Comment #3 from Evgeniy Dushistov  ---
Here history of changes of C++ standard that related to this bug:

http://wg21.cmeerw.net/cwg/issue372


[Bug middle-end/58041] Unaligned access to arrays in packed structure

2013-08-02 Thread wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #26 from Bill Schmidt  ---
Martin's patch bootstrapped on powerpc64-unknown-linux-gnu with no new
regressions.


[Bug c++/57548] calling gnu multiversioned function at file scope causes ICE

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57548

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #4 from Paolo Carlini  ---
Ok, thanks.


[Bug c++/58057] gcc lexer cannot parse extern "\x43" void blah() with option -std=c++0x;

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057

--- Comment #11 from Paolo Carlini  ---
Ed, your analysis matches my intuition, but the error message is still very
poor: to the user something like "... before STRING_USERDEF..." makes no sense
at all. Can we improve it?


[Bug c++/57548] calling gnu multiversioned function at file scope causes ICE

2013-08-02 Thread tmsriram at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57548

--- Comment #3 from Sriraman Tallam  ---
(In reply to Paolo Carlini from comment #2)
> What happened to the patch?

http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00426.html
Patch has been submitted on Jun 7 in rev. 199842 to trunk. Sorry for not
updating this bug. It can be marked fixed.

Thanks
Sri


[Bug c++/58057] gcc lexer cannot parse extern "\x43" void blah() with option -std=c++0x;

2013-08-02 Thread 3dw4rd at verizon dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057

--- Comment #10 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
No, I remember now.  This code *cannot* be right.

With the addition of user-defined literals in C++11 and DR1473
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3675.html#1473)
placing keywords immediately after a string literal forms a valid user-defined
string literal.

As an extension we admit macros so placed with a warning.  We do this not to
break user code with inttypes.h and other user-created string macros.

See http://gcc.gnu.org/ml/gcc/2013-06/msg00119.html and onwards - especially
http://gcc.gnu.org/ml/gcc/2013-06/msg00121.html.

This is not a bug.  I vote close INVALID.


[Bug c++/58062] [C++11] bogus __func__ lookup in lambda body

2013-08-02 Thread hstong at ca dot ibm.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58062

--- Comment #1 from Hubert Tong  ---
Compiler invocation was:
g++ -std='c++11' main.cpp -Wall -Wextra -pedantic -c


[Bug c++/58062] New: [C++11] bogus __func__ lookup in lambda body

2013-08-02 Thread hstong at ca dot ibm.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58062

Bug ID: 58062
   Summary: [C++11] bogus __func__ lookup in lambda body
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com

In the case below, the __func__ identifier appears within a lambda body at
namespace scope.

GCC seems to find __func__ from somewhere, but the behaviour does not appear to
be supported by the Standard. MSVC gives the expected error.

When we are told by C++11 subclause 5.1.2 [expr.prim.lambda] paragraph 7 that
the compound-statement "yields" the function-body of the function call
operator, it can be taken that it means that a function-body is produced from
the compound-statement and that the latter is not an actual function-body. We
are also told that for the purposes of name lookup, the compound-statement is
considered in the context of the lambda-expression.

We find that, in the absence of a function-body, __func__ is not a specified to
be a predefined variable (8.4.1 [dcl.fct.def.general] paragraphs 7-8). We also
note that the form of a function definition (8.4.1 paragraph 1) is not present
in the above program and that the wording in subclauses 3.3.2
[basic.scope.pdecl] and 3.3.3 [basic.scope.block] (paragraphs 8 and 2,
respectively) covers only function-local predefined variables in function
definitions.

The conclusion is that __func__ in a lambda body is bound using the context of
the lambda-expression, and not bound later to be the function-local predefined
variable which would exist in the context of the function-call operator's
compiler-generated definition.

In the case of the code below, it means that the lookup for __func__ fails and
renders the program ill-formed.

## Small test:
namespace K {
   auto ff = [] { return __func__; };
}

## Actual output:
Clean compile.

## Expected output:
main.cpp: In lambda function:
main.cpp:2:26: error: ‘__func__’ was not declared in this scope
auto ff = [] { return __func__; };
  ^

## g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --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.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04)

[Bug middle-end/58041] Unaligned access to arrays in packed structure

2013-08-02 Thread wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #25 from Bill Schmidt  ---
Yep, that's terrific.  Thanks.


[Bug c++/53756] [C++1y] ICE: in gen_type_die_with_usage, at dwarf2out.c:18774 with -g and operator auto ()

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53756

Paolo Carlini  changed:

   What|Removed |Added

 CC||jogojapan at gmail dot com

--- Comment #2 from Paolo Carlini  ---
*** Bug 56014 has been marked as a duplicate of this bug. ***


[Bug c++/56014] [C++1y] ICE using return type deduction for member functions with -g enabled

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56014

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Paolo Carlini  ---
Dup.

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


[Bug middle-end/58041] Unaligned access to arrays in packed structure

2013-08-02 Thread jamborm at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

Martin Jambor  changed:

   What|Removed |Added

   Assignee|wschmidt at gcc dot gnu.org|jamborm at gcc dot 
gnu.org

--- Comment #24 from Martin Jambor  ---
Created attachment 30594
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30594&action=edit
Proposed patch

(In reply to Bill Schmidt from comment #20)
> After thinking it over some more, I think you are right, Martin.  We should
> go ahead with the optimization with the corrected alignment attached to the
> type.  Please go ahead with your patch.  I will run a round of regression
> testing on PowerPC (an architecture for which the generic test produces
> misaligned but legal memory references) as well.
> 
> Sorry for going back and forth on this.  I try to avoid wasting compile time
> on useless transformations, but in this case we will still see some benefit
> in some cases, and the code should be no worse than before when we don't.
> 

No worries, I'm currently bootstrapping and testing the attached
patch.  I'm bootstrapping on x86_64-linux and with bugs like this one,
any additional testing on other platforms is very welcome.

(In reply to Bill Schmidt from comment #21)
> My only comment on the patch would be to please add commentary indicating
> why the change is being made, and referencing this PR.  Something along the
> lines of:
> 
>   /* Ensure the memory reference carries the minimum alignment
>  requirement for the data type.  Some targets (e.g., ARM)
>  can't always handle an unaligned reference otherwise.  See PR58041.  */
> 
> ...or something like that.
> 

The alignment information should be there regardless of the target so
I just used the first sentence and the PR reference.  I hope that is
enough.  Thanks.


[Bug rtl-optimization/57708] [4.8 regression] function clobbers callee saved register on ARM

2013-08-02 Thread rearnsha at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57708

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-02
  Component|target  |rtl-optimization
Summary|function clobbers callee|[4.8 regression] function
   |saved register on ARM   |clobbers callee saved
   ||register on ARM
 Ever confirmed|0   |1

--- Comment #3 from Richard Earnshaw  ---
This is a bug in peep2_find_free_register() which fails to correctly validate
that second and subsequent registers in a multi-register mode are available for
use.

Marked as a regression since this code would have worked correctly on older
compilers.


[Bug c++/57548] calling gnu multiversioned function at file scope causes ICE

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57548

--- Comment #2 from Paolo Carlini  ---
What happened to the patch?


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

2013-08-02 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

--- Comment #186 from Jan Hubicka  ---
oprofile of merging
6764713.0501  lto1 inflate_fast
38682 7.4624  lto1 compare_tree_sccs_1(tree_node*,
tree_node*, tree_node***)
32365 6.2437  lto1 streamer_read_uhwi(lto_input_block*)
31198 6.0186  lto1
streamer_read_tree_bitfields(lto_input_block*, data_in*, tree_node*)
21155 4.0811  libc-2.11.1.so   msort_with_tmp
19581 3.7775  lto1 ht_lookup_with_hash(ht*, unsigned
char const*, unsigned long, unsigned int, ht_lookup_option)
16584 3.1993  lto1 lto_input_tree(lto_input_block*,
data_in*)
15203 2.9329  lto1 lto_input_tree_1(lto_input_block*,
data_in*, LTO_tags, unsigned int)
15194 2.9312  libc-2.11.1.so   memcpy
14823 2.8596  lto1 htab_find_slot_with_hash
12860 2.4809  lto1
streamer_read_tree_body(lto_input_block*, data_in*, tree_node*)
12705 2.4510  lto1 hash_table::find_slot_with_hash(tree_scc const*, unsigned int, insert_option)
11773 2.2712  lto1 adler32
11504 2.2193  libc-2.11.1.so   _IO_vfscanf
11401 2.1994  lto1 unify_scc(streamer_tree_cache_d*,
unsigned int, unsigned int, unsigned int, unsigned int)
9548  1.8420  lto1
streamer_get_pickled_tree(lto_input_block*, data_in*)
9315  1.7970  lto1 inflate

IPA
18799 6.2862  lto1
symtab_remove_unreachable_nodes(bool, _IO_FILE*)
11878 3.9719  lto1
cgraph_redirect_edge_callee(cgraph_edge*, cgraph_node*)
11223 3.7528  lto1 do_per_function(void (*)(void*),
void*)
10813 3.6157  lto1 pointer_set_lookup(pointer_set_t
const*, void const*, unsigned long*)
8415  2.8139  lto1 ipa_reverse_postorder(cgraph_node**)
7689  2.5711  lto1 htab_find_slot_with_hash
7677  2.5671  lto1 do_estimate_growth_1(cgraph_node*,
void*)
7477  2.5002  libc-2.11.1.so   free
7035  2.3524  libc-2.11.1.so   malloc_consolidate

Stream out
9440 16.1663  lto1 linemap_lookup(line_maps*, unsigned
int)
7663 13.1231  lto1 DFS_write_tree(output_block*, sccs*,
tree_node*, bool, bool)
6052 10.3643  lto1
streamer_write_uhwi_stream(lto_output_stream*, unsigned long)
5831  9.9858  lto1 pointer_set_lookup(pointer_set_t
const*, void const*, unsigned long*)
3342  5.7233  lto1
streamer_tree_cache_lookup(streamer_tree_cache_d*, tree_node*, unsigned int*)
2229  3.8172  lto1 pointer_map_insert(pointer_map_t*,
void const*)
2196  3.7607  lto1
streamer_pack_tree_bitfields(output_block*, bitpack_d*, tree_node*)
2054  3.5175  lto1 lto_output_tree(output_block*,
tree_node*, bool, bool)
1656  2.8360  lto1 inflate_fast
1655  2.8342  lto1 pointer_map::insert(void const*, bool*)


[Bug libgcc/58061] New: internal compiler error

2013-08-02 Thread whitequill at abstractions dot me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58061

Bug ID: 58061
   Summary: internal compiler error
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: whitequill at abstractions dot me

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.7/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.7
--enable-ssp --disable-libssp --disable-libitm --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--program-suffix=-4.7 --enable-linux-futex --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) 


AR=/tools/bin/$LFS_TGT-ar RANLIB=/tools/bin/$LFS_TGT-ranlib
/mnt/Share/source/gcc/configure --build=$MACHTYPE --host=$MACHTYPE
--target=$LFS_TGT --prefix=/tools --disable-nls --disable-shared
--disable-multilib --disable-decimal-float --disable-threads
--disable-libmudflap --disable-libssp --disable-libgomp
--enable-languages=c,c++ --without-ppl --without-cloog
--with-headers=/tools/$LFS_TGT/include

/home/lfs/./gcc/xgcc -B/home/lfs/./gcc/ -L/tools/x86_64-w64-mingw32/lib
-L/tools/mingw/lib -isystem /tools/x86_64-w64-mingw32/include -isystem
/tools/mingw/include -B/tools/x86_64-w64-mingw32/bin/
-B/tools/x86_64-w64-mingw32/lib/ -isystem /tools/x86_64-w64-mingw32/include
-isystem /tools/x86_64-w64-mingw32/sys-include-g -O2 -O2  -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  
-I. -I. -I../.././gcc -I/mnt/Share/source/gcc/libgcc
-I/mnt/Share/source/gcc/libgcc/. -I/mnt/Share/source/gcc/libgcc/../gcc
-I/mnt/Share/source/gcc/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o
_trampoline.o -MT _trampoline.o -MD -MP -MF _trampoline.dep -DL_trampoline -c
/mnt/Share/source/gcc/libgcc/libgcc2.c 
In file included from /home/lfs/gcc/include/x86intrin.h:27:0,
 from /tools/x86_64-w64-mingw32/include/intrin.h:30,
 from /tools/x86_64-w64-mingw32/include/winnt.h:1444,
 from /tools/x86_64-w64-mingw32/include/windef.h:137,
 from /tools/x86_64-w64-mingw32/include/windows.h:62,
 from /mnt/Share/source/gcc/libgcc/libgcc2.c:2082:
/home/lfs/gcc/include/ia32intrin.h:54:9: internal compiler error: in
c_builtin_function_ext_scope, at c/c-decl.c:3633
 #pragma GCC target("sse4.2")
 ^
0x50f1a2 c_builtin_function_ext_scope(tree_node*)
/mnt/Share/source/gcc/gcc/c/c-decl.c:3633
0x808f01 add_builtin_function_common
/mnt/Share/source/gcc/gcc/langhooks.c:561
0x809bb3 add_builtin_function_ext_scope(char const*, tree_node*, int,
built_in_class, char const*, tree_node*)
/mnt/Share/source/gcc/gcc/langhooks.c:597
0xb7fdc8 ix86_add_new_builtins
/mnt/Share/source/gcc/gcc/config/i386/i386.c:27184
0xb7fdc8 ix86_valid_target_attribute_tree(tree_node*)
/mnt/Share/source/gcc/gcc/config/i386/i386.c:4512
0x5c99d0 ix86_pragma_target_parse
/mnt/Share/source/gcc/gcc/config/i386/i386-c.c:385
0x5afb6d handle_pragma_target
/mnt/Share/source/gcc/gcc/c-family/c-pragma.c:805
0x54f5be c_parser_pragma
/mnt/Share/source/gcc/gcc/c/c-parser.c:8972
0x55ffeb c_parser_external_declaration
/mnt/Share/source/gcc/gcc/c/c-parser.c:1345
0x560957 c_parser_translation_unit
/mnt/Share/source/gcc/gcc/c/c-parser.c:1251
0x560957 c_parse_file()
/mnt/Share/source/gcc/gcc/c/c-parser.c:11223
0x5ad6f4 c_common_parse_file()
/mnt/Share/source/gcc/gcc/c-family/c-opts.c:1046

for proper reproduction the version of gcc build being cross-built was:
revision: 201377 from svn update.

the headers being included are here:
http://mingw-wine.googlecode.com/files/mingw64api-mingwport-src.7z

/mnt/network/source/mingw64api-mingwport-src/mingw-w64-headers/configure
--build=$MACHTYPE  --host=$LFS_TGT --prefix=/tools/$LFS_TGT


[Bug fortran/58058] [4.7/4.8/4.9 Regression] Memory leak with transfer function

2013-08-02 Thread janus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58058

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> I think the following should be enough to fix it:

It also regtests cleanly.


[Bug middle-end/58041] Unaligned access to arrays in packed structure

2013-08-02 Thread wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #23 from Bill Schmidt  ---
(In reply to Eric Botcazou from comment #22)
> We should be very wary of generating unaligned accesses during optimization
> for targets that define SLOW_UNALIGNED_ACCESS.  And note that most
> architectures supported by GCC are STRICT_ALIGNMENT, not the other way
> around, so it's the common case.

I fully agree.  In this case, we aren't introducing new unaligned accesses, but
simply restructuring the address that points to the same (unaligned) location. 
The restructuring allows us to common the base addressing for related array
elements in the same misaligned structure, which will produce slightly better
code with the same number of unaligned accesses.  Martin's patch just makes
sure the necessary alignment is recorded on the restructured memory reference,
so the back ends can do their usual tricks to copy misaligned references in
parts, etc.


[Bug middle-end/58041] Unaligned access to arrays in packed structure

2013-08-02 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #22 from Eric Botcazou  ---
> After thinking it over some more, I think you are right, Martin.  We should
> go ahead with the optimization with the corrected alignment attached to the
> type.  Please go ahead with your patch.  I will run a round of regression
> testing on PowerPC (an architecture for which the generic test produces
> misaligned but legal memory references) as well.
> 
> Sorry for going back and forth on this.  I try to avoid wasting compile time
> on useless transformations, but in this case we will still see some benefit
> in some cases, and the code should be no worse than before when we don't.

We should be very wary of generating unaligned accesses during optimization for
targets that define SLOW_UNALIGNED_ACCESS.  And note that most architectures
supported by GCC are STRICT_ALIGNMENT, not the other way around, so it's the
common case.


[Bug middle-end/58041] Unaligned access to arrays in packed structure

2013-08-02 Thread wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #21 from Bill Schmidt  ---
My only comment on the patch would be to please add commentary indicating why
the change is being made, and referencing this PR.  Something along the lines
of:

  /* Ensure the memory reference carries the minimum alignment
 requirement for the data type.  Some targets (e.g., ARM)
 can't always handle an unaligned reference otherwise.  See PR58041.  */

...or something like that.

Thanks again!

Bill


[Bug c++/58057] gcc lexer cannot parse extern "\x43" void blah() with option -std=c++0x;

2013-08-02 Thread 3dw4rd at verizon dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057

--- Comment #9 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
I think I need to test for keyword in addition to testing for macro in
libcpp/lex.c

I'll look at this.

I'll also look at getting a better error.


[Bug middle-end/58041] Unaligned access to arrays in packed structure

2013-08-02 Thread wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #20 from Bill Schmidt  ---
After thinking it over some more, I think you are right, Martin.  We should go
ahead with the optimization with the corrected alignment attached to the type. 
Please go ahead with your patch.  I will run a round of regression testing on
PowerPC (an architecture for which the generic test produces misaligned but
legal memory references) as well.

Sorry for going back and forth on this.  I try to avoid wasting compile time on
useless transformations, but in this case we will still see some benefit in
some cases, and the code should be no worse than before when we don't.

Thanks,
Bill


[Bug target/57431] ICE in simplify_const_unary_operation vld1_dup_s64/vst1_s64

2013-08-02 Thread rearnsha at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57431

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-02
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
Confirmed. 

vld1_dup_[su]64() are degenerate into simple load operations and shouldn't be
using vec_duplicate at all.


[Bug fortran/58058] [4.7/4.8/4.9 Regression] Memory leak with transfer function

2013-08-02 Thread janus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58058

--- Comment #2 from janus at gcc dot gnu.org ---
I think the following should be enough to fix it:


Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c(revision 201331)
+++ gcc/fortran/trans-intrinsic.c(working copy)
@@ -5652,8 +5652,7 @@ scalar_transfer:

   if (expr->ts.type == BT_CHARACTER)
 {
-  tree direct;
-  tree indirect;
+  tree direct, indirect, free;

   ptr = convert (gfc_get_pchar_type (expr->ts.kind), source);
   tmpdecl = gfc_create_var (gfc_get_pchar_type (expr->ts.kind),
@@ -5686,6 +5685,13 @@ scalar_transfer:
   tmp = build3_v (COND_EXPR, tmp, direct, indirect);
   gfc_add_expr_to_block (&se->pre, tmp);

+  /* Free the temporary string, if necessary.  */
+  free = gfc_call_free (tmpdecl);
+  tmp = fold_build2_loc (input_location, GT_EXPR, boolean_type_node,
+ dest_word_len, source_bytes);
+  tmp = build3_v (COND_EXPR, tmp, free, build_empty_stmt
(input_location));
+  gfc_add_expr_to_block (&se->post, tmp);
+
   se->expr = tmpdecl;
   se->string_length = fold_convert (gfc_charlen_type_node, dest_word_len);
 }


[Bug c++/58060] separate compilation of gnu multiversioning gives undefined/multiple defined symbols at link time

2013-08-02 Thread mib.bugzilla at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58060

--- Comment #1 from mib.bugzilla at gmail dot com ---
Created attachment 30593
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30593&action=edit
test case part 2


[Bug c++/58060] New: separate compilation of gnu multiversioning gives undefined/multiple defined symbols at link time

2013-08-02 Thread mib.bugzilla at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58060

Bug ID: 58060
   Summary: separate compilation of gnu multiversioning gives
undefined/multiple defined symbols at link time
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mib.bugzilla at gmail dot com

Created attachment 30592
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30592&action=edit
test case part 1

I tried gnu multiversioning with separate compilation but I get both these
messages at link time: multiple defined symbols and undefined symbol. 

g++ -o foo.exe mv6c-1.o mv6c.o
mv6c.o: In function `foo()':
mv6c.C:(.text+0x0): multiple definition of `foo()'
mv6c-1.o:mv6c-1.C:(.text+0x0): first defined here
mv6c-1.o: In function `_Z3foov.resolver':
mv6c-1.C:(.text._Z3foov.resolver[_Z3foov.resolver]+0x1b): undefined reference
to `_Z3foov.arch_corei7'
collect2: error: ld returned 1 exit status
-bash-4.1$ cp mv6c*C ~/my_home
-bash-4.1$ cat mv6c.C
  /* corei7 version of foo.  */
  __attribute__ ((target("arch=corei7")))
  int foo () { return 7; }
// I thought this compilation unit would create a function with the name
arch_corei7, but it just creates a foo without target decoration


[Bug c++/57546] templated gnu multiversion function pointer returns wrong value

2013-08-02 Thread mib.bugzilla at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57546

--- Comment #2 from mib.bugzilla at gmail dot com ---
I rerun this test today and the program segfaults.

Also get the same behavior (segfault) if the template is removed. I'll attach
the non-templated test case

 g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/site/spt/rdrive/ref/gcc/4.8.1/rhel60/efi2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/configure
--prefix=/rdrive/ref/gcc/4.8.1/rhel60/efi2
--enable-languages=c,c++,objc,fortran --disable-multilib --enable-bootstrap
--target=x86_64-unknown-linux-gnu --disable-bootstrap --enable-decimal-float
--with-gmp=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2
--with-mpfr=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2
--with-mpc=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2
Thread model: posix
gcc version 4.8.1 (GCC)


[Bug c++/57546] templated gnu multiversion function pointer returns wrong value

2013-08-02 Thread mib.bugzilla at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57546

mib.bugzilla at gmail dot com changed:

   What|Removed |Added

 CC||mib.bugzilla at gmail dot com

--- Comment #1 from mib.bugzilla at gmail dot com ---
Created attachment 30591
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30591&action=edit
test case without template, also segfault


[Bug c++/58059] gcc-4.7.2-r1 - g++: internal compiler error: Segmentation fault (program cc1plus)

2013-08-02 Thread nacitar at ubercpp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58059

--- Comment #2 from Jacob McIntosh  ---
Oh, and of course, compilation yields nothing more than this:

$ g++ -std=c++11 gcc_crash.cc 
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


I also filed a downstream bug on gentoo,
https://bugs.gentoo.org/show_bug.cgi?id=479444 but the gentoo guys in the help
channel advised me to file this one upstream.


[Bug c++/58059] gcc-4.7.2-r1 - g++: internal compiler error: Segmentation fault (program cc1plus)

2013-08-02 Thread nacitar at ubercpp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58059

--- Comment #1 from Jacob McIntosh  ---
Created attachment 30590
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30590&action=edit
preprocessed output


Generating this file crashed too:
$ gcc -v -save-temps -std=c++11 gcc_crash.cc
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.2/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/configure --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-cloog --without-ppl --disable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib
--with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/python
--enable-checking=release --disable-libgcj --enable-libstdcxx-time
--enable-languages=c,c++,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.7.2-r1 p1.6,
pie-0.5.5'
Thread model: posix
gcc version 4.7.2 (Gentoo 4.7.2-r1 p1.6, pie-0.5.5) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.2/cc1plus -E -quiet -v -D_GNU_SOURCE
gcc_crash.cc -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess -o
gcc_crash.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.2/cc1plus -fpreprocessed gcc_crash.ii
-quiet -dumpbase gcc_crash.cc -mtune=generic -march=x86-64 -auxbase gcc_crash
-std=c++11 -version -o gcc_crash.s
GNU C++ (Gentoo 4.7.2-r1 p1.6, pie-0.5.5) version 4.7.2 (x86_64-pc-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.1,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Gentoo 4.7.2-r1 p1.6, pie-0.5.5) version 4.7.2 (x86_64-pc-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.1,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6937aad24b81042c4f11f96fe3cea84a
gcc: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


[Bug c++/58059] New: gcc-4.7.2-r1 - g++: internal compiler error: Segmentation fault (program cc1plus)

2013-08-02 Thread nacitar at ubercpp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58059

Bug ID: 58059
   Summary: gcc-4.7.2-r1 - g++: internal compiler error:
Segmentation fault (program cc1plus)
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nacitar at ubercpp dot com

Created attachment 30589
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30589&action=edit
source file

When building a c++11 program using the command line:
  g++ -std=c++11 gcc_crash.cc

I get an internal compiler error.  When trying to generate the preprocessed
source, the same crash occurs.


$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.2/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/configure --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include
--datadir=/usr/share/gcc-data/x86_6
4-pc-linux-gnu/4.7.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-cloog --without-ppl --disable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib
--with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/python
--enable-checking=release --disable-libgcj --enable-libstdcxx-time
--enable-languages=c,c++,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.7.2-r1 p1.6,
pie-0.5.5'  Thread model: posix
gcc version 4.7.2 (Gentoo 4.7.2-r1 p1.6, pie-0.5.5)


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

2013-08-02 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

--- Comment #185 from Jan Hubicka  ---
I merged in some patches intended to reduce memory of Firefox LTO and also
updated firefox tree. Some more involved patches are on the way, so it is
summary where we stand now.

WPA usage in TOP is 10GB now.

1) After streaming in trees, the GGC usage is now 5.1GB
   - 2.5GB are trees,
   - 1GB are linemaps
   - 0.8GB are decl maps (decl states)

tree_list12561507
integer_type 1511296
pointer_type 4610735
record_type  8139077
method_type  2401664
integer_cst  6677946
string_cst   2127890
function_decl6069299
label_decl504859
field_decl   5104957
var_decl  596020
const_decl   5401253
parm_decl9002744
type_decl10150100
result_decl  2181250
addr_expr4173661
tree_binfo   4780477


 I have cache that cuts down the linemaps + patch to not stream PARM_DECLs and
RETURN_DECLs.  With this the usage goes bellow 3GB.

2) Cgraph streaming now becomes important factor.  
   GGC usage goes up to 7.7GB
   GGC use:
 - cgraph nodes themselves are 1.5GB
 - inline summaries are 0.5GB
 - cgraph edges are 3.7GB
 - IPA references 2.3GB
 - IPA-prop 0.7GB
   Off GGC
 - IPA-prop 0.6GB
 - Inline summary 0.5GB
 - symtab encoder 0.17GB

   Here one can easily
 - compress the vectors recording definitions
 - pull off parts of cgraph nodes that are not really needed by WPA (nested
info, etc.)
 - perhaps implement of streaming of merged cgraph.

so good news is that we now have a lot of interesting low hanging fruit. Bad
news is that tree streaming still feels slow.  I suppose we need to dig more
into what trees really need to go into WPA...


[Bug fortran/58058] [4.7/4.8/4.9 Regression] Memory leak with transfer function

2013-08-02 Thread janus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58058

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-02
 CC||janus at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
Summary|Memory leak with transfer   |[4.7/4.8/4.9 Regression]
   |function|Memory leak with transfer
   ||function
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
I can confirm the leak with gfortran versions 4.7, 4.8 and trunk. However,
there is no leak in 4.3, so it is a regression (haven't tried other versions).

Indeed the dump produced by -fdump-tree-original shows a __builtin_malloc,
which is never freed. The regression seems to be due to this commit:

http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=143462


[Bug tree-optimization/58010] [4.8/4.9 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4378

2013-08-02 Thread wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010

--- Comment #3 from Bill Schmidt  ---
r189527 is probably a red herring.  That just changed the cost model to be
turned on by default at -O3.  Somebody who's actively working on the vectorizer
should probably have a look at this.

If you want to narrow it down further, try turning on -fvect-cost-model and
bisecting.  The problem will probably show up as being introduced further back
if you do this.

This also suggests a workaround for the OP of using -fno-vect-cost-model, if a
workaround is needed.


[Bug c++/58052] Copy initialization using conversion operator does not find correct candidates for initialization of final result

2013-08-02 Thread hstong at ca dot ibm.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58052

--- Comment #2 from Hubert Tong  ---
(In reply to Paolo Carlini from comment #1)
> Not having spent a lot of time on this, I doubt it's a bug: the latest clang
> and icc behave exactly like gcc.

I had a vague recollection why I found the code weird to begin with.
After consideration, I found that the MSVC behaviour made sense after all.

There is wording in 12.3 [class.conv]:
At most one user-defined conversion (constructor or conversion function) is
implicitly applied to a single value.

To poke some holes in the applicability of the above wording, I will modify the
test case:
@@ -3,7 +3,8 @@ struct A {
A();
A(const A &, bool = 0);
A(const A &, short = 0);
-   A(B &);
+
+   template  explicit A(T &);
 };

 struct B : A { };

Note that explicit constructors are not converting constructors.

The modified version of the test case works fine with clang++ and icc, but not
GCC. MSVC chokes on the "explicit".


[Bug other/58056] ld segfaults when "-undefined dynamic_lookup" is set

2013-08-02 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58056

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |other

--- Comment #2 from Andrew Pinski  ---
(In reply to Paolo Carlini from comment #1)
> Thus this is about ld *not* gcc, right?

Meaning you should report this to Apple about their ld crashing.


[Bug c++/58057] gcc lexer cannot parse extern "\x43" void blah() with option -std=c++0x;

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057

--- Comment #8 from Paolo Carlini  ---
Among the compilers I have at hand, only the latest Icc accepts this.


[Bug c++/58057] gcc lexer cannot parse extern "\x43" void blah() with option -std=c++0x;

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057

Paolo Carlini  changed:

   What|Removed |Added

 CC|schnoerr at mailzone dot com   |3dw4rd at verizon dot 
net

--- Comment #7 from Paolo Carlini  ---
The error message could be better, but I don't think this is valid.


[Bug c++/58057] gcc lexer cannot parse extern "\x43" void blah() with option -std=c++0x;

2013-08-02 Thread schnoerr at mailzone dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057

schnoerr at mailzone dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |---

--- Comment #6 from schnoerr at mailzone dot com ---
I'm sorry again, the cause of the error seemed to be so obvious.

The removed spaces are the reason.
Here is a small program I could isolate the problem:

--
//command: g++ -std=c++0x test.cc -o test
//version: g++ (GCC) 4.7.3

extern "C" void * blah_1( void * );  //ok

extern "\x43" void*blah_2(void*);//ok

extern"\x43"void*blah_3(void*);  //<-- error only here with -std=c++0x and
g++4.7.3
 //no error with g++4.6.3

int main() {

}

error message: test.cc:7:7: error: expected unqualified-id before
‘STRING_USERDEF’ token

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-08-02 Thread jamborm at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #15 from Martin Jambor  ---
I have submitted the patch to the mailing list for review:

http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00082.html


(In reply to Bernd Edlinger from comment #14)
> What I mean is, maybe the defautlt for MALOC_ABI_ALIGNMENT
> should changed to BIGGEST_ALIGNMENT. What do You think?

If ARM can trap accessing an 8 byte variable of a type that can be
defined without any fancy attributes, then unambiguously yes, malloc
has to return memory aligned to at least 8 bytes and
MALLOC_ABI_ALIGNMENT needs to be bumped to at least 64.

I am not sure whether BIGGEST_ALIGNMENT is the right value, e.g. on
x86_64 the value of MALLOC_ABI_ALIGNMENT is 64 whereas
BIGGEST_ALIGNMENT is 128.  Of course, on ARM the latter is also 64, so
at the moment it would not make a real difference.

Anyway, the policy of GCC seems to be that the default of
MALLOC_ABI_ALIGNMENT is ultra-safe and targets should override it.  So
I would suggest, again :-), that you open a separate bug and CC ARM
maintainers that should take care of it.


[Bug fortran/58058] New: Memory leak with transfer function

2013-08-02 Thread thomas.jourdan at orange dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58058

Bug ID: 58058
   Summary: Memory leak with transfer function
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.jourdan at orange dot fr

Hello,

Using gfortran 4.8.1, the following code runs fine but according to valgrind it
produces a memory leak:

program test1

  implicit none

  integer, dimension(3) :: t1, t2
  character(len=64) :: str

  t1 = (/1,2,3/)

  !str = transfer((/1,2,3/),str) ! works
  str = transfer(t1,str) ! memory leak
  t2 = transfer(str,t1)

  write(*,*) 't2 = ',t2

end program test1

The output is:
==7005== Memcheck, a memory error detector
==7005== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==7005== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==7005== Command: ./test1
==7005== 
 t2 =1   2   3
==7005== 
==7005== HEAP SUMMARY:
==7005== in use at exit: 64 bytes in 1 blocks
==7005==   total heap usage: 23 allocs, 22 frees, 11,897 bytes allocated
==7005== 
==7005== LEAK SUMMARY:
==7005==definitely lost: 64 bytes in 1 blocks
==7005==indirectly lost: 0 bytes in 0 blocks
==7005==  possibly lost: 0 bytes in 0 blocks
==7005==still reachable: 0 bytes in 0 blocks
==7005== suppressed: 0 bytes in 0 blocks
==7005== Rerun with --leak-check=full to see details of leaked memory
==7005== 
==7005== For counts of detected and suppressed errors, rerun with: -v
==7005== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)


If I use directly "str = transfer((/1,2,3/),str)" instead, no memory problem
occurs. I experienced the same problem with the following test:


program test2

  implicit none

  type tuple
integer :: nn
integer :: pp
integer :: qq
  end type tuple

  character(len=64) :: str
  type(tuple) :: mt1, mt2

  mt1%nn = 1
  mt1%pp = 2
  mt1%qq = 3

  str = transfer(mt1,str)
  mt2 = transfer(str,mt2)

end program test2

Thanks,

Thomas


[Bug fortran/57987] Fortran finalizers considered extern-inline by middle-end

2013-08-02 Thread jamborm at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57987

--- Comment #5 from Martin Jambor  ---
OK, so eventually I have posted the patch to the mailing list:

http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00074.html

Thanks.


[Bug c++/58057] gcc lexer cannot parse extern "\x43" void blah() with option -std=c++0x;

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Paolo Carlini  ---
Yep.


[Bug c++/58057] gcc lexer cannot parse extern "\x43" void blah() with option -std=c++0x;

2013-08-02 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057

--- Comment #4 from Marek Polacek  ---
Weird, even with -std=c++0x I still see no failures at all.


[Bug c++/58057] gcc lexer cannot parse extern "\x43" void blah() with option -std=c++0x;

2013-08-02 Thread schnoerr at mailzone dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057

schnoerr at mailzone dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 CC||schnoerr at mailzone dot com
 Resolution|WORKSFORME  |---
Summary|gcc lexer cannot parse  |gcc lexer cannot parse
   |extern "\x43" void blah();  |extern "\x43" void blah()
   ||with option -std=c++0x;

--- Comment #3 from schnoerr at mailzone dot com ---
sorry, I've forgotten a detail:
The problem only occurs with the option '-std=c++0x'.
With '-std=c++98' all works fine.


[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5

2013-08-02 Thread ro at CeBiTec dot Uni-Bielefeld.DE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Vincent Lefèvre  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #6)
>> Certainly not: IRIX isn't PowerPC but MIPS!
>
> OK, that wasn't clear because the original but report mentioned:
> "gcc.target/powerpc/rs6000-ldouble-2.c".
> ^^^

Right, but that test isn't run on regular testsuite runs on IRIX,
although there's nothing powerpc specific in there except for the
-mlong-double-128 option which can only be used on powerpc targets.

Running it manually on IRIX shows the failure.

Rainer

[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5

2013-08-02 Thread vincent-gcc at vinc17 dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341

--- Comment #7 from Vincent Lefèvre  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #6)
> Certainly not: IRIX isn't PowerPC but MIPS!

OK, that wasn't clear because the original but report mentioned:
"gcc.target/powerpc/rs6000-ldouble-2.c".
^^^

> If need be, just refer to the double/double format.

Yes.

[Bug c++/57408] lambda, Variable length arrays, thread, internal compiler error: in expand_expr_real_1, at expr.c:9327

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57408

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC|jason at gcc dot gnu.org   |
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #7 from Paolo Carlini  ---
Thus fixed for 4.9.0.


[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5

2013-08-02 Thread ro at CeBiTec dot Uni-Bielefeld.DE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #5 from Vincent Lefèvre  ---
> (In reply to Vincent Lefèvre from comment #4)
>> I can see the same problem under Linux (gcc110.fsffrance.org).
>
> In case this wasn't clear, the architecture is also a PowerPC. The
> double-double format comes from the PowerPC ABI, and isn't directly related to
> the OS itself (FYI it was also used under Mac OS X / PowerPC).
>
> Thus the summary of this bug should be changed to:
>
>   LDBL_EPSILON is wrong on PowerPC

Certainly not: IRIX isn't PowerPC but MIPS!  If need be, just refer to
the double/double format.

Rainer

[Bug c++/58047] parse error with typedef introduced from base class

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047

--- Comment #3 from Paolo Carlini  ---
Seems closely related to PR37140.


[Bug c++/58047] parse error with typedef introduced from base class

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047

Paolo Carlini  changed:

   What|Removed |Added

 CC||fabien at gcc dot gnu.org

--- Comment #2 from Paolo Carlini  ---
... hard to believe we don't have a Dup.


[Bug c++/58047] parse error with typedef introduced from base class

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047

--- Comment #1 from Paolo Carlini  ---
Let's have this at hand, just c++98:

template 
struct print_arg { };

struct const_holder {
  static const int CONSTANT = 42;
};

template 
struct identity {
  typedef T type;
};

template 
struct test_case : public identity {
  using typename identity::type;
  print_arg printer;
};

template struct test_case;


[Bug rtl-optimization/58008] ICE: Max. number of generated reload insns per insn is achieved (90)

2013-08-02 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58008

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Might be the same as PR58048...


[Bug tree-optimization/58010] [4.8/4.9 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4378

2013-08-02 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010

Marek Polacek  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with http://gcc.gnu.org/r189527


[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5

2013-08-02 Thread vincent-gcc at vinc17 dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341

--- Comment #5 from Vincent Lefèvre  ---
(In reply to Vincent Lefèvre from comment #4)
> I can see the same problem under Linux (gcc110.fsffrance.org).

In case this wasn't clear, the architecture is also a PowerPC. The
double-double format comes from the PowerPC ABI, and isn't directly related to
the OS itself (FYI it was also used under Mac OS X / PowerPC).

Thus the summary of this bug should be changed to:

  LDBL_EPSILON is wrong on PowerPC

[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5

2013-08-02 Thread vincent-gcc at vinc17 dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341

--- Comment #4 from Vincent Lefèvre  ---
I can see the same problem under Linux (gcc110.fsffrance.org).

According to the C standard (C99 and C11), the *_EPSILON values are "the
difference between 1 and the least value greater than 1 that is representable
in the given floating point type, b^(1-p)".

Here b = 2 and p = LDBL_MANT_DIG = 106.

I think that the C standard is badly worded. It should have said "the
difference between 1 and the least floating-point value greater than 1 that is
representable in the given type, b^(1-p)". What is regarded as a floating-point
value is specified by the standard: see 5.2.4.2.2p2 "A floating-point number
(x) is defined by the following model: [...]".

[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

2013-08-02 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048

--- Comment #7 from Uroš Bizjak  ---
Looking a bit into this problem:

A reload reg is inserted before "fscale" asm, but the chosen alternative can
move an immediate to memory directly.

Inserting insn reload before:
  227: r184:SI=0x20

  alt=0,overall=13,losers=2,rld_nregs=1
  alt=1,overall=9,losers=1,rld_nregs=0
  alt=4,overall=19,losers=2 -- reject
  alt=10,overall=19,losers=2 -- reject
 Choosing alt 1 in insn 227:  (0) m  (1) re {*movsi_internal}
  Creating newreg=185 from oldreg=184, assigning class NO_REGS to r185
  227: r185:SI=0x20
Inserting insn reload after:

The alternative does not need a register, so class NO_REGS is correct. However,
it looks that follow-up code is not prepared for this and trips into a loop,
trying to assign another reload reg.

[Bug c++/58057] gcc lexer cannot parse extern "\x43" void blah();

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Paolo Carlini  ---
Indeed.


[Bug c++/58057] gcc lexer cannot parse extern "\x43" void blah();

2013-08-02 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I can't seem to reproduce it with 4.7/4.8/trunk (if you really parse it using
the C++ compiler).


[Bug c++/58040] Cannot take address-of public using-declaration of member from protected base class

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040

--- Comment #4 from Paolo Carlini  ---
Thanks!


[Bug c++/58056] ld segfaults when "-undefined dynamic_lookup" is set

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58056

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Paolo Carlini  ---
Thus this is about ld *not* gcc, right?


[Bug tree-optimization/58010] [4.8/4.9 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4378

2013-08-02 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-02
 CC||mpolacek at gcc dot gnu.org
  Known to work||4.7.3
   Target Milestone|--- |4.8.2
Summary|ICE in  |[4.8/4.9 Regression] ICE in
   |vect_create_epilog_for_redu |vect_create_epilog_for_redu
   |ction, at   |ction, at
   |tree-vect-loop.c:4378   |tree-vect-loop.c:4378
 Ever confirmed|0   |1
  Known to fail||4.8.1, 4.9.0

--- Comment #1 from Marek Polacek  ---
Confirmed.


[Bug c++/58057] New: gcc lexer cannot parse extern "\x43" void blah();

2013-08-02 Thread schnoerr at mailzone dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057

Bug ID: 58057
   Summary: gcc lexer cannot parse  extern "\x43" void blah();
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: schnoerr at mailzone dot com

g++ 4.7.3 fails to compile 
extern "\x43" void blah();
which is obfuscated and equivalent to
extern "C" void blah();

This is no problem for the g++ 4.6.3 so it must have been newly introduced in
g++.


[Bug c++/58040] Cannot take address-of public using-declaration of member from protected base class

2013-08-02 Thread fabien at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040

fabien at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-08-02
   Assignee|unassigned at gcc dot gnu.org  |fabien at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from fabien at gcc dot gnu.org ---
(In reply to Paolo Carlini from comment #2)
> Fabien, are you interested in this?

Yes, let's put it on my TODO list. Might be related to PR c++/19377.


[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

2013-08-02 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048

--- Comment #6 from Marek Polacek  ---
...and -O is everything that's needed to trigger that.


[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

2013-08-02 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048

--- Comment #5 from Marek Polacek  ---
Right, thanks, but then the ICE doesn't occur, so this makes it pretty much ICE
on invalid.  Reduced nevertheless...

void
div3 (void)
{
double tmp1;
asm volatile ("fscale":"=t" (tmp1):"0" (0), "u" (0));
}

(with sed 's/(0/(0.0/g' the ICE's gone)


[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

2013-08-02 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048

--- Comment #4 from Uroš Bizjak  ---
(In reply to Marek Polacek from comment #3)
> Note that with -O0:
> d.c: In function ‘div3’:
> d.c:102:3: error: inconsistent operand constraints in an ‘asm’

Just replace 32 with 32.0 as the asm operand.

[Bug c++/58056] New: ld segfaults when "-undefined dynamic_lookup" is set

2013-08-02 Thread freget at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58056

Bug ID: 58056
   Summary: ld segfaults when "-undefined dynamic_lookup" is set
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freget at googlemail dot com

Created attachment 30588
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30588&action=edit
Object file causing the error

I'm using g++ 4.8.1 on OS X with the following configuration:

Ziel: x86_64-apple-darwin12.4.0
Konfiguriert mit: ../configure --build=x86_64-apple-darwin12.4.0
--prefix=/usr/local/Cellar/gcc48/4.8.1/gcc
--datarootdir=/usr/local/Cellar/gcc48/4.8.1/share
--bindir=/usr/local/Cellar/gcc48/4.8.1/bin
--enable-languages=c,c++,fortran,java,objc,obj-c++ --program-suffix=-4.8
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-cloog=/usr/local/opt/cloog
--with-isl=/usr/local/opt/isl --with-system-zlib --enable-libstdcxx-time=yes
--enable-stage1-checking --enable-checking=release --enable-lto
--disable-werror --enable-plugin
--with-ecj-jar=/usr/local/opt/ecj/share/java/ecj.jar --disable-multilib
Thread-Modell: posix
gcc-Version 4.8.1 (GCC) 

Using the (faulty) object file attached, the following call causes a segfault: 

> g++-4.8   -std=c++0x -g -dynamiclib  -undefined dynamic_lookup -o 
> output.dylib Notifications.cpp.o 
collect2: Fehler: ld mit Signal 11 [Segmentation fault: 11] beendet

However, once I link without "-undefined dynamic_lookup", I get a meaningful
error description:

> g++-4.8 -std=c++0x -g -dynamiclib   -o output.dylib Notifications.cpp.o 
Undefined symbols for architecture x86_64:
  "libsoda::(anonymous namespace)::CustomOutputBuffer::~CustomOutputBuffer()",
referenced from:
  libsoda::(anonymous namespace)::CustomWarnBuffer::~CustomWarnBuffer() in
Notifications.cpp.o
  libsoda::(anonymous namespace)::CustomErrBuffer::~CustomErrBuffer() in
Notifications.cpp.o
  libsoda::(anonymous namespace)::CustomPrintBuffer::~CustomPrintBuffer()
in Notifications.cpp.o
  "vtable for libsoda::(anonymous namespace)::CustomOutputBuffer", referenced
from:
  libsoda::(anonymous
namespace)::CustomOutputBuffer::CustomOutputBuffer(unsigned long) in
Notifications.cpp.o
  NOTE: a missing vtable usually means the first non-inline virtual member
function has no definition.
  "_elog_finish", referenced from:
  libsoda::(anonymous namespace)::CustomPrintBuffer::printToUser(char*) in
Notifications.cpp.o
  libsoda::(anonymous namespace)::CustomErrBuffer::printToUser(char*) in
Notifications.cpp.o
  libsoda::(anonymous namespace)::CustomWarnBuffer::printToUser(char*) in
Notifications.cpp.o
  libsoda::(anonymous namespace)::DefaultHandler(char const*, char const*,
char const*, int) in Notifications.cpp.o
  "_elog_start", referenced from:
  libsoda::(anonymous namespace)::CustomPrintBuffer::printToUser(char*) in
Notifications.cpp.o
  libsoda::(anonymous namespace)::CustomErrBuffer::printToUser(char*) in
Notifications.cpp.o
  libsoda::(anonymous namespace)::CustomWarnBuffer::printToUser(char*) in
Notifications.cpp.o
  libsoda::(anonymous namespace)::DefaultHandler(char const*, char const*,
char const*, int) in Notifications.cpp.o
ld: symbol(s) not found for architecture x86_64
collect2: Fehler: ld gab 1 als Ende-Status zurück

This is something I can work with. Debugging with the only output beeing a
segfault is not that easy. 
Not that the example above was stripped down as much as possible and will never
compile successfully in this configuration.

[Bug c++/37140] type inherited from base class not recognized

2013-08-02 Thread fabien at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140

--- Comment #8 from fabien at gcc dot gnu.org ---
(In reply to Paolo Carlini from comment #7)
> Any news on this?

Sorry Paolo, no news. I will look into it after I resurrect some "stage one 1
material" patches on using decls (comming after c++/54537). I think this one
can be tackled in stage 3.


[Bug c++/54537] undiagnosed using-declaration conflicting with used function

2013-08-02 Thread fabien at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54537

--- Comment #3 from fabien at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #1)
> Given the OK by Paolo, I retested the patch from:
> 
> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01166.html
> 
> It needed a small change to the expected error message from using9.C, but
> otherwise bootstrapped and regtested with no errors.  Committed to mainline
> as revision 201414.

Thank you very much.

> I have also asked about the appropriateness of backporting it to the FSF 4.8
> branch.

It is not a regression, so I think you would need an approval. Just ask it on
gcc-patches.


[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

2013-08-02 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048

--- Comment #3 from Marek Polacek  ---
Note that with -O0:
d.c: In function ‘div3’:
d.c:102:3: error: inconsistent operand constraints in an ‘asm’

[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

2013-08-02 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-02
 CC||mpolacek at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
  Known to work||4.7.3
   Target Milestone|--- |4.8.2
Summary|internal compiler error:|[4.8/4.9 Regression]
   |Max. number of generated|internal compiler error:
   |reload insns per insn is|Max. number of generated
   |achieved (90)   |reload insns per insn is
   ||achieved (90)
 Ever confirmed|0   |1
  Known to fail||4.8.1, 4.9.0

--- Comment #2 from Marek Polacek  ---
Confirmed, started with http://gcc.gnu.org/r192719
I'll try to reduce this a bit.


[Bug c++/58051] No named return value optimization when returned object is implicitly converted

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051

Paolo Carlini  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement


[Bug c++/58050] No return value optimization when calling static function through unnamed temporary

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58050

Paolo Carlini  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement


[Bug c++/58055] [meta-bug] RVO / NRVO improvements

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-02
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
Adding Jason in CC, I seem to remember he did the ssa implementation.


[Bug c++/58055] New: [meta-bug] RVO / NRVO improvements

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055

Bug ID: 58055
   Summary: [meta-bug] RVO / NRVO improvements
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paolo.carlini at oracle dot com


[Bug libstdc++/58049] [4.9 Regression] libstdc++ bootstrap failure for fix to PR libstdc++/57779

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58049

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #2 from Paolo Carlini  ---
Done.


[Bug c++/58052] Copy initialization using conversion operator does not find correct candidates for initialization of final result

2013-08-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58052

--- Comment #1 from Paolo Carlini  ---
Not having spent a lot of time on this, I doubt it's a bug: the latest clang
and icc behave exactly like gcc.


[Bug inline-asm/58044] -mno-see2avx does not seems to work

2013-08-02 Thread jerome.pouiller at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58044

--- Comment #1 from Jérôme Pouiller  ---
AVX instructions seems to not been generated by assembler. Compiler directly
generate these instructions. Since -mavx2 is specified, compiler behaviour can
be considered correct. But, I don't see any case where -mno-sse2avx may change
result, isn't? This option may be removed?


For my specific test case, there is a workaround. I can add 
__attribute__((__target__("no-avx"))) to memcpy_16to8_sse.

  1   2   >