[Bug rtl-optimization/56912] scheduler change breaks linux kernel LTO build with 4.8

2013-04-10 Thread abel at gcc dot gnu.org


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



Andrey Belevantsev  changed:



   What|Removed |Added



 CC||abel at gcc dot gnu.org



--- Comment #2 from Andrey Belevantsev  2013-04-11 
06:22:51 UTC ---

I will take a look given the test case.  It doesn't have to be small, any steps

to reproduce the issue would be fine (hopefully).


[Bug middle-end/56077] [4.6/4.7 Regression] volatile ignored when function inlined

2013-04-10 Thread abel at gcc dot gnu.org


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



--- Comment #16 from Andrey Belevantsev  2013-04-11 
06:17:41 UTC ---

The patch adds more pending list flushes and thus more dependencies.  So by

itself it is conservative and should not result in correctness issues that

arise when the scheduler gets more freedom.



However, the accidental change that the patch reverted was made back in 2008. 

Since then, obviously many changes were made to the scheduler, and some of

those could assume that pending lists are flushed on jumps only.  One such

iasue has surfaced immediately on 4.6/4.7, where the patch was reverted, but on

4.8 and trunk that was fixed by Maxim's patch.  PR 56912 is another issue

judging from the backtrace.  I will take a look there as soon as the testcase

shows up.



Overall, I agree with Jakub -- the patch fixes wrong code (though not very

important one as the bug was reported in 4.5 years after the change was made),

it is conservative, but has some fallout, so for 4.6/4.7 let's wait more until

all issues come up, and for 4.8 let's just fix the issues.


[Bug middle-end/56077] [4.6/4.7 Regression] volatile ignored when function inlined

2013-04-10 Thread jakub at gcc dot gnu.org


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



--- Comment #15 from Jakub Jelinek  2013-04-11 
05:37:30 UTC ---

No, it shouldn't be reverted, silent wrong code is IMHO more severe than LTO

only ICE.


[Bug c++/56904] rejection of legal code in c++11 mode. (maybe namespace lookup problem)

2013-04-10 Thread jason at gcc dot gnu.org


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



--- Comment #3 from Jason Merrill  2013-04-11 
02:54:34 UTC ---

See also DR 125:



http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#125


[Bug c++/56904] rejection of legal code in c++11 mode. (maybe namespace lookup problem)

2013-04-10 Thread jason at gcc dot gnu.org


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



Jason Merrill  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #2 from Jason Merrill  2013-04-11 
02:53:29 UTC ---

In C++11, enums have scopes, so the :: after the E is interpreted as looking

for a member of E.



icc and clang reject the testcase for the same reason.


[Bug c++/56842] Argument deduction failure note is empty for alias template

2013-04-10 Thread jason at gcc dot gnu.org


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



Jason Merrill  changed:



   What|Removed |Added



 CC||dodji at gcc dot gnu.org,

   ||jason at gcc dot gnu.org



--- Comment #1 from Jason Merrill  2013-04-11 
02:41:22 UTC ---

Another alias issue.


[Bug c++/56913] [C++11] SFINAE for ill-formed pointer-to-member operators with incompatible ref-qualifiers

2013-04-10 Thread paolo.carlini at oracle dot com


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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-11

 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot

   |gnu.org |com

 Ever Confirmed|0   |1



--- Comment #1 from Paolo Carlini  2013-04-11 
01:08:13 UTC ---

Seems very easy.


[Bug c++/56914] internal compiler error: Segmentation fault

2013-04-10 Thread vini.ipsmaker at gmail dot com

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

--- Comment #1 from Vinícius dos Santos Oliveira  2013-04-11 01:01:55 UTC ---
Created attachment 29852
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29852
The preprocessed source file.

[Bug c++/56914] New: internal compiler error: Segmentation fault

2013-04-10 Thread vini.ipsmaker at gmail dot com


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



 Bug #: 56914

   Summary: internal compiler error: Segmentation fault

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: vini.ipsma...@gmail.com





I tried to compile my code (and the code has a few bugs) and GCC segfault. It's

the first time this happen to me.



I use some experimental C++11 features. The command line argument is:

g++ main2.cpp -std=c++0x



The output is:

../main.cpp: In lambda function:

../main.cpp:17:22: internal compiler error: Segmentation fault

 QObject::connect(&req, &HttpServerResponse::end, []() {

  ^

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.



My system is an i686 Linux (ArchLinux). The GCC was built with this command:

https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gcc



I've used C++11, Qt 5.0.1 and my open source project. What else do I need to

inform?


[Bug c++/56913] New: [C++11] SFINAE for ill-formed pointer-to-member operators with incompatible ref-qualifiers

2013-04-10 Thread ai.azuma at gmail dot com


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



 Bug #: 56913

   Summary: [C++11] SFINAE for ill-formed pointer-to-member

operators with incompatible ref-qualifiers

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: c++

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

ReportedBy: ai.az...@gmail.com





Created attachment 29851

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

Output of -v option and preprocessed source



GCC 4.8.1 20130404 and 4.9.0 20130407 reject the following well-formed code;



//---

template

T &&declval();



template().*declval())())>

constexpr bool test(int)

{

  return true;

}



template

constexpr bool test(...)

{

  return false;

}



struct S

{};



static_assert(!test(0), "");

static_assert(test(0), "");

static_assert(test(0), "");

static_assert(!test(0), "");

//---



For the above code, GCC 4.9.0 20130407 complains as follows;



main.cpp:5:43: error: pointer-to-member-function type 'void (S::*)() &'

requires an lvalue

  typename = decltype((declval().*declval())())>

   ^

main.cpp:20:1: error: static assertion failed: 

 static_assert(!test(0), "");

 ^

main.cpp:5:43: error: pointer-to-member-function type 'void (S::*)() &&'

requires an rvalue

  typename = decltype((declval().*declval())())>

   ^

main.cpp:23:1: error: static assertion failed: 

 static_assert(!test(0), "");

 ^



SFINAE does not seem to be applied to ill-formed pointer-to-member operators

(as per N3485 [expr.mptr.oper]/6) instantiated in the first and fourth

static_asserts, and they result in hard errors.


[Bug rtl-optimization/56912] scheduler change breaks linux kernel LTO build with 4.8

2013-04-10 Thread pinskia at gcc dot gnu.org


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



--- Comment #1 from Andrew Pinski  2013-04-11 
00:39:29 UTC ---

>No simple test case unfortunately as it is LTO 



Actually it should not be hard to get a testcase if you use mutli-delta.  I

have reduced some LTO testcases already using mutli-delta and I had a customer

use it too to reduce the testcases for us when they reported the bugs due to

LTO.


[Bug middle-end/56077] [4.6/4.7 Regression] volatile ignored when function inlined

2013-04-10 Thread pinskia at gcc dot gnu.org


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



--- Comment #14 from Andrew Pinski  2013-04-11 
00:38:05 UTC ---

(In reply to comment #13)

> The fix has been reverted on the 4.6 and 4.7 branches.



I think it should also be reverted on the 4.8 branch, see PR 56912.


[Bug rtl-optimization/56912] New: scheduler change breaks linux kernel LTO build with 4.8

2013-04-10 Thread andi-gcc at firstfloor dot org


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



 Bug #: 56912

   Summary: scheduler change breaks linux kernel LTO build with

4.8

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: rtl-optimization

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

ReportedBy: andi-...@firstfloor.org





For the Linux kernel LTO build I get ICEs during LTO (segfaults) with the

recent 4.8 branch. I bisected it down to this patch and reverting fixes it.



No simple test case unfortunately as it is LTO 





Backport from mainline

2013-02-25  Andrey Belevantsev  

Alexander Monakov  



PR middle-end/56077

* sched-deps.c (sched_analyze_insn): When reg_pending_barrier,

flush pending lists also on non-jumps.  Adjust comment.







Typical crash:







#7  

#8  sched_analyze_1 (deps=0x7fff550a5c00, x=0x7fa0311e2ed0,

insn=0x7fa0311f40d8)

at ../../gcc/gcc/sched-deps.c:2479

#9  0x00b668d5 in sched_analyze_insn (deps=deps@entry=0x7fff550a5c00, 

x=0x7fa0311e2e70, insn=insn@entry=0x7fa0311f40d8) at

../../gcc/gcc/sched-deps.c:2859

#10 0x00b6859b in deps_analyze_insn (deps=deps@entry=0x7fff550a5c00, 

insn=insn@entry=0x7fa0311f40d8) at ../../gcc/gcc/sched-deps.c:3505

#11 0x00b689c3 in sched_analyze (deps=0x7fff550a5c00, head=, 

tail=0x7fa0311f8c18) at ../../gcc/gcc/sched-deps.c:3653

#12 0x0070b635 in compute_block_dependences (bb=0) at

../../gcc/gcc/sched-rgn.c:2702

#13 sched_rgn_compute_dependencies (rgn=rgn@entry=5) at

../../gcc/gcc/sched-rgn.c:3140

#14 0x0070df84 in schedule_region (rgn=5) at

../../gcc/gcc/sched-rgn.c:2915

#15 schedule_insns () at ../../gcc/gcc/sched-rgn.c:3299

#16 schedule_insns () at ../../gcc/gcc/sched-rgn.c:3278

#17 0x0070e3b1 in rest_of_handle_sched2 () at

../../gcc/gcc/sched-rgn.c:3523

#18 0x006b534e in execute_one_pass (pass=pass@entry=0x112e240

)

at ../../gcc/gcc/passes.c:2084

#19 0x006b56bd in execute_pass_list (pass=0x112e240 )

at ../../gcc/gcc/passes.c:2139

#20 0x006b56cf in execute_pass_list (pass=0x112d840 )

at ../../gcc/gcc/passes.c:2140

#21 0x006b56cf in execute_pass_list (pass=0x112d8a0

)

at ../../gcc/gcc/passes.c:2140

#22 0x00792043 in tree_rest_of_compilation (fndecl=0x7fa03f899700)

at ../../gcc/gcc/tree-optimize.c:422

#23 0x00536f7b in cgraph_expand_function (node=0x7fa03c49b5a0)


[Bug c++/56895] [4.8/4.9 Regression] ICE: unexpected expression of kind arrow_expr

2013-04-10 Thread markus at trippelsdorf dot de


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



--- Comment #13 from Markus Trippelsdorf  
2013-04-10 20:04:03 UTC ---

struct B

{

void operator<< (B& ());

void operator<< (int);

};

B b;

struct A

{

bool foo ();

A bar ();

};

A *a;

template 

void

fn1 ()

{

b << (a->bar().foo() ? : 0);

}


[Bug c++/56895] [4.8/4.9 Regression] ICE: unexpected expression of kind arrow_expr

2013-04-10 Thread markus at trippelsdorf dot de

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

--- Comment #12 from Markus Trippelsdorf  
2013-04-10 19:56:00 UTC ---
Just double checked and the original testcase still ICEs.

markus@x4 tmp % cat test.cpp
#include 
extern struct A { bool foo (); A bar (); } *a;
template  
void
fn1 ()
{
  std::cout << (a->bar().foo() ? 1 : 0);
}

markus@x4 tmp % c++ -c test.cpp
test.cpp: In function ‘void fn1()’:
test.cpp:7:39: internal compiler error: unexpected expression ‘a->’ of kind
arrow_expr

[Bug c++/56911] [4.8 Regression] g++.dg/cpp0x/enum25.C:14:19: ICE: in finish_class_member_access_expr, at cp/typeck.c:2673 with -fpic

2013-04-10 Thread markus at trippelsdorf dot de


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



--- Comment #4 from Markus Trippelsdorf  
2013-04-10 18:42:07 UTC ---

gcc version 4.8.0 (GCC) in my case.


[Bug c++/56911] [4.8 Regression] g++.dg/cpp0x/enum25.C:14:19: ICE: in finish_class_member_access_expr, at cp/typeck.c:2673 with -fpic

2013-04-10 Thread ubizjak at gmail dot com

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

--- Comment #3 from Uros Bizjak  2013-04-10 18:39:14 
UTC ---
(In reply to comment #2)
> Hmm, I can confirm the ICE (and it's not the only one in this directory):

To be precise, 4.8 branch that works for me:

xgcc (GCC) 4.8.1 20130410 (prerelease) [gcc-4_8-branch revision 197677]

~/gcc-build-48/gcc/cc1plus -fpic -std=c++11 enum25.C
 int main()
enum25.C:17:8: error: ‘enum class D::Y’ is not a member of ‘C’
   c.D::Y;   // { dg-error "not a member" }
^

(Which is expected error).

[Bug c++/56911] [4.8 Regression] g++.dg/cpp0x/enum25.C:14:19: ICE: in finish_class_member_access_expr, at cp/typeck.c:2673 with -fpic

2013-04-10 Thread markus at trippelsdorf dot de


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



Markus Trippelsdorf  changed:



   What|Removed |Added



 CC||markus at trippelsdorf dot

   ||de



--- Comment #2 from Markus Trippelsdorf  
2013-04-10 18:33:50 UTC ---

Hmm, I can confirm the ICE (and it's not the only one in this directory):



 % g++ -c -fpic -std=c++11 gcc/testsuite/g++.dg/cpp0x/*.C 2>&1 | grep internal

gcc/testsuite/g++.dg/cpp0x/constexpr-array5.C:6:23: internal compiler error:

Segmentation fault

gcc/testsuite/g++.dg/cpp0x/constexpr-reinterpret1.C:37:49: internal compiler

error: in gimple_expand_cfg, at cfgexpand.c:4575

gcc/testsuite/g++.dg/cpp0x/constexpr-static11.C:8:36: internal compiler error:

Segmentation fault

gcc/testsuite/g++.dg/cpp0x/constexpr-template5.C:6:29: internal compiler error:

in convert_nontype_argument, at cp/pt.c:5558

gcc/testsuite/g++.dg/cpp0x/enum25.C:14:19: internal compiler error: in

finish_class_member_access_expr, at cp/typeck.c:2673

gcc/testsuite/g++.dg/cpp0x/nsdmi-local.C:7:12: internal compiler error: in

expand_expr_real_1, at expr.c:9327

gcc/testsuite/g++.dg/cpp0x/range-for23.C:6:20: internal compiler error:

Segmentation fault

gcc/testsuite/g++.dg/cpp0x/trailing9.C:10:14: internal compiler error: in

cp_parser_late_return_type_opt, at cp/parser.c:16970


[Bug c/56824] pragma GCC diagnostic push/pop regression for GCC diagnostic ignored "-Waggregate-return"

2013-04-10 Thread manu at gcc dot gnu.org

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-04-10
 CC||manu at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from Manuel López-Ibáñez  2013-04-10 
18:32:00 UTC ---
I think the problem is the continue, which moves to the next i--:

Index: diagnostic.c
===
--- diagnostic.c(revision 197394)
+++ diagnostic.c(working copy)
@@ -664,13 +685,13 @@ diagnostic_report_diagnostic (diagnostic
return false;

   /* This tests for #pragma diagnostic changes.  */
   if (context->n_classification_history > 0)
{
- int i;
+ int i = context->n_classification_history - 1;
  /* FIXME: Stupid search.  Optimize later. */
- for (i = context->n_classification_history - 1; i >= 0; i --)
+ while (i >= 0)
{
  if (linemap_location_before_p
  (line_table,
   context->classification_history[i].location,
   location))
@@ -686,10 +707,11 @@ diagnostic_report_diagnostic (diagnostic
  if (diag_class != DK_UNSPECIFIED)
diagnostic->kind = diag_class;
  break;
}
}
+  i--;
}
}
   /* This tests if the user provided the appropriate -Werror=foo
 option.  */
   if (diag_class == DK_UNSPECIFIED

but someone would need to test the patch.

But it is a bug.

[Bug c++/56911] [4.8 Regression] g++.dg/cpp0x/enum25.C:14:19: ICE: in finish_class_member_access_expr, at cp/typeck.c:2673 with -fpic

2013-04-10 Thread ubizjak at gmail dot com


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



Uros Bizjak  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Uros Bizjak  2013-04-10 18:02:14 
UTC ---

Ops, wrong binary was used.


[Bug c++/56911] New: [4.8 Regression] g++.dg/cpp0x/enum25.C:14:19: ICE: in finish_class_member_access_expr, at cp/typeck.c:2673 with -fpic

2013-04-10 Thread ubizjak at gmail dot com


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



 Bug #: 56911

   Summary: [4.8 Regression] g++.dg/cpp0x/enum25.C:14:19: ICE: in

finish_class_member_access_expr, at cp/typeck.c:2673

with -fpic

Classification: Unclassified

   Product: gcc

   Version: 4.8.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: ubiz...@gmail.com

Target: x86_64-pc-linux-gnu





~/gcc-build-48/gcc/cc1plus -std=c++11 -fpic enum25.C

 int main()

enum25.C:14:19: internal compiler error: in finish_class_member_access_expr, at

cp/typeck.c:2673

   if (a.b == a.B::Y)

   ^

0x58655b finish_class_member_access_expr(tree_node*, tree_node*, bool, int)

../../gcc-svn/branches/gcc-4_8-branch/gcc/cp/typeck.c:2673

0x57317b cp_parser_postfix_dot_deref_expression

../../gcc-svn/branches/gcc-4_8-branch/gcc/cp/parser.c:6140

0x55cd50 cp_parser_postfix_expression

../../gcc-svn/branches/gcc-4_8-branch/gcc/cp/parser.c:5864

...


[Bug c/56910] New: Syntax error seemingly sneaks through gcc

2013-04-10 Thread daven at model dot com

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

 Bug #: 56910
   Summary: Syntax error seemingly sneaks through gcc
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: da...@model.com


I'm not sure if the following code is triggering some obscure extension
to gcc or not, but it sure seems like it should generate a syntax
error (it does in all other compilers I've tried).

--- cut here (z.c) ---
typedef int int32_t;
typedef unsigned int uint32_t;

#include 

extern void vl_create_cell_reg(
int32_t reg_idx,
int32_t state_idx,
uint32_t CR_flags,
uint32_t init_val,
char *name;  /* <--- this parameter is missing in the body and contains a
spurious ';' */
);

void vl_create_cell_reg( int32_t reg_idx, int32_t state_idx, uint32_t CR_flags,
uint32_t init_val )
{
}
--- cut here (end of z.c) ---

If I cut/paste this source to a file called "z.c", it compiles fine, i.e.:

$ gcc -c -Wall -Werror z.c
<< no errors/warnings reported >>

Note, if I remove the spurious ';', I get the expected error:

$ gcc -c -Wall -Werror z.c
z.c:15:6: error: conflicting types for ‘vl_create_cell_reg’
z.c:7:13: note: previous declaration of ‘vl_create_cell_reg’ was here

[Bug tree-optimization/56900] [4.9 regression] FAIL: gcc.dg/tree-ssa/vrp87.c scan-tree-dump vrp2 "Folded into: if.*"

2013-04-10 Thread law at redhat dot com


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



Jeffrey A. Law  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-10

 CC||law at redhat dot com

 Ever Confirmed|0   |1



--- Comment #2 from Jeffrey A. Law  2013-04-10 17:00:26 
UTC ---

False positive.  Difference in BRANCH_COST values results in significantly

different enough gimple code in VRP that this test doesn't make any sense.


[Bug ada/56909] [4.8 regression] Ada: s-atopri.adb:multiple undefined references on mingw32

2013-04-10 Thread mail2arthur at gmail dot com


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



--- Comment #1 from Arthur Zhang  2013-04-10 
16:32:49 UTC ---

Less undefined references if add '--with-arch=i486 --with-tune=i686' to

configure.



s-atopri.o: In function `system__atomic_primitives__lock_free_read_64':

e:\test1\bd\wk\build\gcc\ada\rts/s-atopri.adb:80: undefined reference to

`__atomic_load_8'

s-atopri.o: In function `system__atomic_primitives__lock_free_try_write_64':

e:\test1\bd\wk\build\gcc\ada\rts/s-atopri.adb:188: undefined reference to

`__sync_val_compare_and_swap_8'

collect2.exe: error: ld returned 1 exit status



Full configure command line:



  $srcdir/configure \

--enable-languages=c,c++,ada,fortran,objc,obj-c++  \

--with-arch=i486 --with-tune=i686 \

--disable-sjlj-exceptions\

--with-dwarf2\

--enable-shared  \

--enable-libgomp \

--disable-win32-registry \

--enable-libstdcxx-debug \

--disable-build-poststage1-with-cxx \

--enable-version-specific-runtime-libs \

--build=mingw32  \

--prefix=/mingw

}


[Bug fortran/56872] [4.8/4.9 Regression] Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize

2013-04-10 Thread mikael at gcc dot gnu.org


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



Mikael Morin  changed:



   What|Removed |Added



 Status|RESOLVED|REOPENED

 CC||mikael at gcc dot gnu.org

 Resolution|FIXED   |



--- Comment #10 from Mikael Morin  2013-04-10 
16:09:38 UTC ---

> -  if (c == NULL)

> +  /* Don't do any simplififcation if we have

> + - no element in the constructor or

> + - only have a single element in the array which contains an

> + iterator.  */

> +

> +  if (c == NULL || (c->iterator != NULL && gfc_constructor_next (c) == NULL))

>  return 0;

> 

I don't think it is enough if there is something after the iterator.

Testcase:





  real:: s

  integer :: m

  integer :: k



  m = 2

  s = 1000.



  print *,[(s**(REAL(k-1)/REAL(m-1)),k=1,m)]



  print *,SUM([(s**(REAL(k-1)/REAL(m-1)),k=1,m), 0.0])



end program sum_bug


[Bug ada/56909] New: [4.8 regression] Ada: s-atopri.adb:multiple undefined references on mingw32

2013-04-10 Thread mail2arthur at gmail dot com


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



 Bug #: 56909

   Summary: [4.8 regression] Ada: s-atopri.adb:multiple undefined

references on mingw32

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: ada

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

ReportedBy: mail2art...@gmail.com





Both for 4.8.0 release tarball and SVN 4_8-Branch



Error:



s-atopri.o: In function `system__atomic_primitives__lock_free_read_64':

e:\test1\bd\wk\build\gcc\ada\rts/s-atopri.adb:80: undefined reference to

`__atomic_load_8'

s-atopri.o: In function `system__atomic_primitives__lock_free_try_write_8':

e:\test1\bd\wk\build\gcc\ada\rts/s-atopri.adb:101: undefined reference to

`__sync_val_compare_and_swap_1'

s-atopri.o: In function `system__atomic_primitives__lock_free_try_write_16':

e:\test1\bd\wk\build\gcc\ada\rts/s-atopri.adb:130: undefined reference to

`__sync_val_compare_and_swap_2'

s-atopri.o: In function `system__atomic_primitives__lock_free_try_write_32':

e:\test1\bd\wk\build\gcc\ada\rts/s-atopri.adb:159: undefined reference to

`__sync_val_compare_and_swap_4'

s-atopri.o: In function `system__atomic_primitives__lock_free_try_write_64':

e:\test1\bd\wk\build\gcc\ada\rts/s-atopri.adb:188: undefined reference to

`__sync_val_compare_and_swap_8'

collect2.exe: error: ld returned 1 exit status

make[4]: *** [gnatlib-shared-win32] Error 1

make[4]: Leaving directory `/home/t/bd/wk/build/gcc/ada'

make[3]: *** [gnatlib-shared] Error 2

make[3]: Leaving directory `/home/t/bd/wk/build/gcc/ada'

make[2]: *** [gnatlib-shared] Error 2

make[2]: Leaving directory `/home/t/bd/wk/build/mingw32/libada'

make[1]: *** [all-target-libada] Error 2

make[1]: Leaving directory `/home/t/bd/wk/build'

make: *** [all] Error 2





Command:



...

/mingw/mingw32/bin/ranlib rts/libgnarl.a

/mingw/mingw32/bin/ar rc rts/libgmem.a \

  rts/memtrack.o

/mingw/mingw32/bin/ranlib rts/libgmem.a

chmod a-wx rts/*.ali

touch ../stamp-gnatlib-rts

make[5]: Leaving directory `/home/t/bd/wk/build/gcc/ada'

rm -f rts/libgna*.dll

cd rts; `echo "/home/t/bd/wk/build/./gcc/xgcc -B/home/t/bd/wk/build/./gcc/

-L/home/t/bd/wk/build/mingw32/winsup/mingw

-L/home/t/bd/wk/build/mingw32/winsup/w32api/lib -isystem

/home/t/bd/wk/gcc-4.8.0/winsup/mingw/include -isystem

/home/t/bd/wk/gcc-4.8.0/winsup/w32api/include -B/mingw/mingw32/bin/

-B/mingw/mingw32/lib/ -isystem /mingw/mingw32/include -isystem

/mingw/mingw32/sys-include   " \

| sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'`

-shared -shared-libgcc \

 \

-o libgnat-4.8.dll \

a-assert.o a-btgbso.o a-calari.o a-calcon.o a-caldel.o a-calend.o

a-calfor.o a-catizo.o a-cbhama.o a-cbhase.o a-cborse.o a-cbdlli.o a-cbmutr.o

a-cborma.o a-cbprqu.o a-cbsyqu.o a-cdlili.o a-cfdlli.o a-cfhama.o a-cfhase.o

a-cforma.o a-cforse.o a-cgaaso.o a-cgarso.o a-cgcaso.o a-chacon.o a-chahan.o

a-charac.o a-chlat1.o a-chlat9.o a-chtgbo.o a-chtgbk.o a-chtgke.o a-chtgop.o

a-chzla1.o a-chzla9.o a-cidlli.o a-cihama.o a-cihase.o a-ciorma.o a-ciormu.o

a-ciorse.o a-clrefi.o a-cogeso.o a-cohama.o a-cohase.o a-cohata.o a-coinho.o

a-coinve.o a-colien.o a-colire.o a-comlin.o a-contai.o a-convec.o a-cobove.o

a-cofove.o a-coorma.o a-coormu.o a-coorse.o a-coprnu.o a-coteio.o a-crbltr.o

a-crbtgk.o a-crbtgo.o a-crdlli.o a-comutr.o a-cimutr.o a-csquin.o a-cuprqu.o

a-cusyqu.o a-cwila1.o a-cwila9.o a-decima.o a-diocst.o a-direct.o a-direio.o

a-dirval.o a-einuoc.o a-elchha.o a-envvar.o a-except.o a-exctra.o a-finali.o

a-flteio.o a-fwteio.o a-fzteio.o a-inteio.o a-ioexce.o a-iteint.o a-iwteio.o

a-izteio.o a-lcteio.o a-lfteio.o a-lfwtio.o a-lfztio.o a-liteio.o a-liwtio.o

a-liztio.o a-llctio.o a-llftio.o a-llfwti.o a-llfzti.o a-llitio.o a-lliwti.o

a-llizti.o a-locale.o a-ncelfu.o a-ngcefu.o a-ngcoar.o a-ngcoty.o a-ngelfu.o

a-ngrear.o a-nlcefu.o a-nlcoar.o a-nlcoty.o a-nlelfu.o a-nlrear.o a-nllcar.o

a-nllcef.o a-nllcty.o a-nllefu.o a-nllrar.o a-nscefu.o a-nscoty.o a-nselfu.o

a-nucoar.o a-nucoty.o a-nudira.o a-nuelfu.o a-nuflra.o a-numaux.o a-numeri.o

a-nurear.o a-rbtgbo.o a-rbtgbk.o a-rbtgso.o a-sbecin.o a-sbhcin.o a-sblcin.o

a-scteio.o a-secain.o a-sequio.o a-sfecin.o a-sfhcin.o a-sflcin.o a-sfteio.o

a-sfwtio.o a-sfztio.o a-shcain.o a-siocst.o a-siteio.o a-siwtio.o a-siztio.o

a-slcain.o a-ssicst.o a-ssitio.o a-ssiwti.o a-ssizti.o a-stboha.o a-stfiha.o

a-stmaco.o a-storio.o a-strbou.o a-stream.o a-strfix.o a-strhas.o a-string.o

a-strmap.o a-strsea.o a-strsup.o a-strunb.o a-ststio.o a-stunau.o a-stunha.o

a-stuten.o a-stwibo.o a-stwifi.o a-stwiha.o a-stwima.o a-stwise.o a-stwisu.o

a-stwiun.o a-stzbou.o a-stzfix.o a-stzhas.o a-stzmap.o a-stzsea.o a-stzsup.o

a-stzunb.o a-suecin.o a-suenco.o a-suenst.o a-suewst.o a-suezst.o a-suhcin.o

a-sulcin.o a-suteio.o a-swbwha.o a-swfwha.o

[Bug c++/56908] New: Spurious warning when XOR-ing uint8_t values

2013-04-10 Thread hniksic at gmail dot com


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



 Bug #: 56908

   Summary: Spurious warning when XOR-ing uint8_t values

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: hnik...@gmail.com





g++ -Wconversion displays what I believe is a spurious warning in my code:



warning: conversion to 'uint8_t {aka unsigned char}' from 'int' may alter its

value [-Wconversion]



-Wconversion is mandated by the project I'm working on.  Since I'm striving for

warningless compilation, I looked into the function. Even after a careful

examination, I cannot find fault with it, nor an obvious way to get rid of the

warning without compromising the code's readability.  The minimal example that

warns is:



#include 

#include 



void

xorblock(uint8_t* dest, const uint8_t* src, size_t len)

{

  while (len--)

*dest++ ^= *src++;

}



Compiled with g++ -Wconversion a.cc, it prints the warning as:



a.cc: In function 'void xorblock(uint8_t*, const uint8_t*, size_t)':

a.cc:8:20: warning: conversion to 'uint8_t {aka unsigned char}' from 'int' may

alter its value [-Wconversion]



Both operands have the same type, which is appropriate for the calculation.

Casting the right-hand side of the compound assignment to either int, uint8_t,

or unsigned int fails to silence the warning.  The warning does not occur with

gcc, only with g++.



The only way I found to remove the warning is to rewrite the assignment as a

non-compound assignment.  But this precludes the use of the post-increment

operator and consequently makes the function harder to follow.  (In this case

shorter is more readable, as *dest++ = *src++ is one of the most widely

understood C idioms.)



The warning happens with g++ 4.7 and 4.8, but not with g++ 4.6 series.


[Bug fortran/56907] New: C_LOC shall not call internal-PACK when an array argument is used

2013-04-10 Thread burnus at gcc dot gnu.org


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



 Bug #: 56907

   Summary: C_LOC shall not call internal-PACK when an array

argument is used

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Keywords: missed-optimization

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: bur...@gcc.gnu.org





Found when looking at gfortran.dg/assumed_type_2.f90.



For an array argument, C_LOC should simply take the first element of the array

(section). Currently, it invokes internal packing.



As Fortran 2008 demands that the argument is contiguous, internal_packing

should simply return the original array (section) - hence, there is no

wrong-code issue - just a missed optimization.



>From the dump:

D.1901 = _gfortran_internal_pack (&parm.4);

D.1903 = D.1901;



Test case:



! { dg-do compile }

! { dg-options "-fdump-tree-original" }

!

! PR fortran/ <<<

!



subroutine sub(xxx)

  use iso_c_binding

  implicit none

  integer, target :: xxx(:)

  type(c_ptr) :: ptr

  ptr = c_loc (xxx)

end

! { dg-final { scan-tree-dump-not " _gfortran_internal_pack" "original" } }

! { dg-final { cleanup-tree-dump "optimized" } }


[Bug tree-optimization/56878] Issue with candidate choice in vect_gen_niters_for_prolog_loop.

2013-04-10 Thread rguenth at gcc dot gnu.org


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



--- Comment #4 from Richard Biener  2013-04-10 
15:05:44 UTC ---

Like with the simple



Index: gcc/tree-vect-data-refs.c

===

--- gcc/tree-vect-data-refs.c   (revision 196872)

+++ gcc/tree-vect-data-refs.c   (working copy)

@@ -1454,6 +1454,12 @@ vect_enhance_data_refs_alignment (loop_v

  = STMT_VINFO_SAME_ALIGN_REFS (stmt_info).length ();

   dr0 = dr;

 }

+ /* If DR has an invariant base address, prefer it.  */

+ else if (same_align_drs_max

+  == STMT_VINFO_SAME_ALIGN_REFS (stmt_info).length ()

+  && TREE_CODE (DR_BASE_ADDRESS (dr)) == SSA_NAME

+  && SSA_NAME_IS_DEFAULT_DEF (DR_BASE_ADDRESS (dr)))

+   dr0 = dr;



   if (!first_store && DR_IS_WRITE (dr))

 first_store = dr;



to be improved tomorrow to cover more cases.


[Bug testsuite/56906] New: FAIL: g++.dg/opt/vt4.C -std=gnu++* scan-assembler-not _ZTV.A

2013-04-10 Thread dominiq at lps dot ens.fr


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



 Bug #: 56906

   Summary: FAIL: g++.dg/opt/vt4.C -std=gnu++*  scan-assembler-not

_ZTV.A

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: testsuite

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

ReportedBy: domi...@lps.ens.fr

CC: ja...@gcc.gnu.org

  Host: x86_64-apple-darwin10

Target: x86_64-apple-darwin10

 Build: x86_64-apple-darwin10





The test g++.dg/opt/vt4.C fails on x86_64-apple-darwin10:



[macbook] f90/bug% egrep "_ZTV.A" vt4.s

.globl __ZTV1A

.weak_definition __ZTV1A

__ZTV1A:


[Bug other/56881] Miscompilation (optimisation failure?) causing NULL dereference and segfault at runtime

2013-04-10 Thread devspam at moreofthesa dot me.uk

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

--- Comment #5 from devspam at moreofthesa dot me.uk 2013-04-10 15:02:54 UTC ---
The tarball which I've attached also provides its own test case – compile it
then pass it one of its own source files. It'll either segfault or not
depending on compile-time optimisation settings.

[Bug tree-optimization/56878] Issue with candidate choice in vect_gen_niters_for_prolog_loop.

2013-04-10 Thread rguenth at gcc dot gnu.org


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



--- Comment #3 from Richard Biener  2013-04-10 
14:58:00 UTC ---

Hmm, it seems to be a rather unfortunate choice of aligning x vs. v1 which

seems to only depend on the order in which the data-refs appear in the

data-ref array.  That is, vect_enhance_data_refs_alignment should

prefer amongst several choices that are otherwise equal the data-ref

that has the most invariant base address.


[Bug other/56881] Miscompilation (optimisation failure?) causing NULL dereference and segfault at runtime

2013-04-10 Thread devspam at moreofthesa dot me.uk


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



--- Comment #4 from devspam at moreofthesa dot me.uk 2013-04-10 14:49:24 UTC ---

Created attachment 29850

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

Full source of the problem program, both in original form and fully

pre-processed


[Bug libstdc++/56905] New: [C++11][DR 1130] std::copy_exception should be removed or no longer be used

2013-04-10 Thread daniel.kruegler at googlemail dot com


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



 Bug #: 56905

   Summary: [C++11][DR 1130] std::copy_exception should be removed

or no longer be used

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: libstdc++

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

ReportedBy: daniel.krueg...@googlemail.com





According to 



http://cplusplus.github.io/LWG/lwg-defects.html#1130



std::copy_exception has been replaced by std::make_exception_ptr. While I

understand that this function still exists for backward compatibility reasons

in libstdc++, I noticed that other places of the library (such as )

still refer to std::copy_exception, which complicates a possible transition in

the future. I would recommend to replace all usages of std::copy_exception by

the library by std::make_exception_ptr. std::make_exception_ptr should be

defined independent of std::copy_exception. Personally I would recommend to

remove std::copy_exception, alternatively to define it in terms of

std::make_exception_ptr.


[Bug debug/37132] Debug: No DW_TAG_namelist emitted for NAMELISTS

2013-04-10 Thread burnus at gcc dot gnu.org


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



--- Comment #3 from Tobias Burnus  2013-04-10 
13:08:22 UTC ---

(In reply to comment #1)

> Draft patch: http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00560.html



The draft patch fails for dummy arguments as the shipping comes to early: There

is no die to be referenced for them. Thus, the generation of DW_TAG_namelist

has to be deferred until the full function decl is available.



The current idea is to add a NAMELIST_DECL to BLOCK_VARS in tree.def, similarly

to IMPORTED_DECL. DECL_NAME will then contain the the namelist /name/ - and the

decl the vector with all decls in that namelist.  See C++ for how IMPORTED_DECL

gets filled - and "grep IMPORTED_DECL" which files are affected (including

LTO!).


[Bug c++/56904] rejection of legal code in c++11 mode. (maybe namespace lookup problem)

2013-04-10 Thread jakub at gcc dot gnu.org


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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org,

   ||jason at gcc dot gnu.org



--- Comment #1 from Jakub Jelinek  2013-04-10 
12:10:31 UTC ---

This stopped being accepted I think with http://gcc.gnu.org/r139611 , so if

this is indeed valid C++11, then it would be a regression.  But whether it is

valid or not I'll leave to C++ maintainers.


[Bug rtl-optimization/56903] [4.8/4.9 Regression] gcc is 4.8.0 fails to compile netdev.c from the linux kernel [internal compiler error: Maximum number of LRA constraint passes is achieved]

2013-04-10 Thread jakub at gcc dot gnu.org


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



--- Comment #4 from Jakub Jelinek  2013-04-10 
12:02:27 UTC ---

Slightly cleaned up testcase:

/* PR rtl-optimization/56903 */

/* { dg-do compile } */

/* { dg-options "-Os" } */

/* { dg-additional-options "-march=pentium3" { target ia32 } } */



int a, *b, c;

struct S { int s : 1; } *fn1 (void);

extern int fn3 (void), fn4 (int *);



void

fn2 (void)

{

  int e = fn3 ();

  char f = c + fn1 ()->s * 4;

  if (*b && f == e)

a = *b;

  fn4 (b);

}


[Bug rtl-optimization/56903] [4.8/4.9 Regression] gcc is 4.8.0 fails to compile netdev.c from the linux kernel [internal compiler error: Maximum number of LRA constraint passes is achieved]

2013-04-10 Thread mpolacek at gcc dot gnu.org


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



Marek Polacek  changed:



   What|Removed |Added



  Known to work||4.7.3

   Target Milestone|--- |4.8.1

  Known to fail||4.8.0, 4.9.0


[Bug c/56903] gcc is 4.8.0 fails to compile netdev.c from the linux kernel [internal compiler error: Maximum number of LRA constraint passes is achieved]

2013-04-10 Thread mpolacek at gcc dot gnu.org


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



Marek Polacek  changed:



   What|Removed |Added



 Status|WAITING |NEW

 CC||mpolacek at gcc dot

   ||gnu.org, vmakarov at gcc

   ||dot gnu.org



--- Comment #3 from Marek Polacek  2013-04-10 
11:53:03 UTC ---

Confirmed with testcase by Markus.  LRA, thus adding Vlad.


[Bug c/56903] gcc is 4.8.0 fails to compile netdev.c from the linux kernel [internal compiler error: Maximum number of LRA constraint passes is achieved]

2013-04-10 Thread markus at trippelsdorf dot de

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #2 from Markus Trippelsdorf  
2013-04-10 11:49:35 UTC ---
Reduced:

markus@x4 linux % cat test.i
extern int fn3(),fn4();
struct
{
int data_len;
}
*b;
struct tcphdr
{
int doff:1;
};
int a, c;
struct tcphdr *fn1 ();
void fn2 ()
{
int d, e = fn3 ();
char f;
d = fn1 ()->doff * 4;
f = c + d;
if (b->data_len && f == e)
a = (
{
b->data_len;
}
);
fn4 (b);
}
markus@x4 linux % gcc -Os -m32 -mtune=pentium3 -c test.i
test.i: In function ‘fn2’:
test.i:26:1: internal compiler error: Maximum number of LRA constraint passes
is achieved (30)

[Bug c/56903] gcc is 4.8.0 fails to compile netdev.c from the linux kernel [internal compiler error: Maximum number of LRA constraint passes is achieved]

2013-04-10 Thread jakub at gcc dot gnu.org


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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-04-10

 CC||jakub at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2013-04-10 
11:47:26 UTC ---

Please provide info requested in http://gcc.gnu.org/bugs.html


[Bug c++/56904] New: rejection of legal code in c++11 mode. (maybe namespace lookup problem)

2013-04-10 Thread dirk.bonekaemper at dfs dot de


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



 Bug #: 56904

   Summary: rejection of legal code in c++11 mode. (maybe

namespace lookup problem)

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: dirk.bonekaem...@dfs.de





Created attachment 29849

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

preprocessed c++ souce for bug report



Problem appears only with -std=c++11.

If I remove the global scope operator from the ::n::S::foo definition, it

compiles.



c++ -v -save-temps -std=c++11 -c gcc-4-8-0-namespace-problem.cc 

Using built-in specs.

COLLECT_GCC=c++

Target: i686-pc-linux-gnu

Configured with: ../../packages/gcc-4.8.0/configure

--prefix=/usr/localdisk/bondi011/gcc-4.8.0 --enable-languages=c,c++

Thread model: posix

gcc version 4.8.0 (GCC) 

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-c' '-shared-libgcc'

'-mtune=generic' '-march=pentiumpro'

 /usr/localdisk/bondi011/gcc-4.8.0/libexec/gcc/i686-pc-linux-gnu/4.8.0/cc1plus

-E -quiet -v -D_GNU_SOURCE gcc-4-8-0-namespace-problem.cc -mtune=generic

-march=pentiumpro -std=c++11 -fpch-preprocess -o gcc-4-8-0-namespace-problem.ii

ignoring nonexistent directory

"/usr/localdisk/bondi011/gcc-4.8.0/lib/gcc/i686-pc-linux-gnu/4.8.0/../../../../i686-pc-linux-gnu/include"

#include "..." search starts here:

#include <...> search starts here:



/usr/localdisk/bondi011/gcc-4.8.0/lib/gcc/i686-pc-linux-gnu/4.8.0/../../../../include/c++/4.8.0



/usr/localdisk/bondi011/gcc-4.8.0/lib/gcc/i686-pc-linux-gnu/4.8.0/../../../../include/c++/4.8.0/i686-pc-linux-gnu



/usr/localdisk/bondi011/gcc-4.8.0/lib/gcc/i686-pc-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward

 /usr/localdisk/bondi011/gcc-4.8.0/lib/gcc/i686-pc-linux-gnu/4.8.0/include

 /usr/local/include

 /usr/localdisk/bondi011/gcc-4.8.0/include



/usr/localdisk/bondi011/gcc-4.8.0/lib/gcc/i686-pc-linux-gnu/4.8.0/include-fixed

 /usr/include

End of search list.

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-c' '-shared-libgcc'

'-mtune=generic' '-march=pentiumpro'

 /usr/localdisk/bondi011/gcc-4.8.0/libexec/gcc/i686-pc-linux-gnu/4.8.0/cc1plus

-fpreprocessed gcc-4-8-0-namespace-problem.ii -quiet -dumpbase

gcc-4-8-0-namespace-problem.cc -mtune=generic -march=pentiumpro -auxbase

gcc-4-8-0-namespace-problem -std=c++11 -version -o

gcc-4-8-0-namespace-problem.s

GNU C++ (GCC) version 4.8.0 (i686-pc-linux-gnu)

compiled by GNU C version 4.8.0, GMP version 4.3.2, MPFR version 2.4.2, MPC

version 0.8.1

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

GNU C++ (GCC) version 4.8.0 (i686-pc-linux-gnu)

compiled by GNU C version 4.8.0, GMP version 4.3.2, MPFR version 2.4.2, MPC

version 0.8.1

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

Compiler executable checksum: 078491655d66ce4db43e7026e58f8fec

gcc-4-8-0-namespace-problem.cc:11:1: error: 'n' in 'enum n::E' does not name a

type

 ::n::E  ::n::S::foo() { return e; }

 ^


[Bug tree-optimization/55524] If fnma exists but not fms, convert_mult_to_fma should prefer to former over the latter.

2013-04-10 Thread amylaar at gcc dot gnu.org


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



Jorn Wolfgang Rennecke  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #4 from Jorn Wolfgang Rennecke  
2013-04-10 11:32:51 UTC ---

Fixed in mainline:

http://gcc.gnu.org/ml/gcc-cvs/2013-04/msg00376.html


[Bug c/56903] New: gcc is 4.8.0 fails to compile netdev.c from the linux kernel [internal compiler error: Maximum number of LRA constraint passes is achieved]

2013-04-10 Thread gdamjan at gmail dot com

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

 Bug #: 56903
   Summary: gcc is 4.8.0 fails to compile netdev.c from the linux
kernel [internal compiler error: Maximum number of LRA
constraint passes is achieved]
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gdam...@gmail.com


I'm using 32bit ArchLinux (i686)
The gcc package version is 4.8.0-1

When compiling the latest Linux kernel 3.8.6 the compile fails with the
following error. With the help of other Arch users we concluded that it's due
to target processor beeing set to "Pentium M". It doesn't happen on 64bit Arch
Linuxes.

The error:

  CC [M]  drivers/net/ethernet/intel/e1000e/netdev.o
drivers/net/ethernet/intel/e1000e/netdev.c: In function ‘e1000_xmit_frame’:
drivers/net/ethernet/intel/e1000e/netdev.c:5159:1: internal compiler error:
Maximum number of LRA constraint passes is achieved (30)

 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[5]: *** [drivers/net/ethernet/intel/e1000e/netdev.o] Error 1
make[4]: *** [drivers/net/ethernet/intel/e1000e] Error 2

[Bug tree-optimization/56902] New: Fails to SLP with mismatched +/- and negatable constants

2013-04-10 Thread rguenth at gcc dot gnu.org


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



 Bug #: 56902

   Summary: Fails to SLP with mismatched +/- and negatable

constants

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Keywords: missed-optimization

  Severity: enhancement

  Priority: P3

 Component: tree-optimization

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

ReportedBy: rgue...@gcc.gnu.org

Blocks: 53947





double x[1024], y[1024], z[1024];

void foo (double w)

{

  int i;

  for (i = 0; i < 1023; i+=2)

{

  z[i] = x[i] + 3.;

  z[i+1] = x[i+1] + -3.;

}

}

void bar (double w)

{

  int i;

  for (i = 0; i < 1023; i+=2)

{

  z[i] = x[i] + w;

  z[i+1] = x[i+1] + -3.;

}

}

void baz (double w)

{

  int i;

  for (i = 0; i < 1023; i+=2)

{

  z[i] = x[i] - w;

  z[i+1] = x[i+1] + 3.;

}

}


[Bug c++/56901] [4.9 regression] lambda with implicit capture by reference

2013-04-10 Thread rguenth at gcc dot gnu.org


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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.9.0


[Bug tree-optimization/56899] [4.6/4.7/4.8/4.9 Regression] Wrong constant folding

2013-04-10 Thread rguenth at gcc dot gnu.org


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



--- Comment #9 from Richard Biener  2013-04-10 
09:29:43 UTC ---

(In reply to comment #8)

> That said, removing that hunk completely would remove it even for the case

> where the type has defined overflow, shouldn't we remove it just for undefined

> overflow (or, replace the addition/subtraction with undefined one)?



Yes, that works (remove it for undefined overflow).  Replacing it with

defined overflow one, too, but I prefer to make extract_muldiv do less

(it's a scary beast ...).


[Bug tree-optimization/56900] [4.9 regression] FAIL: gcc.dg/tree-ssa/vrp87.c scan-tree-dump vrp2 "Folded into: if.*"

2013-04-10 Thread rguenth at gcc dot gnu.org


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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.9.0


[Bug c++/52748] [4.9 Regression][C++11] N3276 changes to decltype

2013-04-10 Thread zeratul976 at hotmail dot com


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



Nathan Ridge  changed:



   What|Removed |Added



 Status|RESOLVED|REOPENED

 Resolution|FIXED   |



--- Comment #14 from Nathan Ridge  2013-04-10 
09:27:10 UTC ---

Here is a related example that still fails to compile:





template  struct A;



template  struct B : A {};



template 

B operator-(T);



struct S

{

struct F

{

typedef S type;

};



auto foo() -> decltype(-F());

};







This is compiled successfully by clang, but GCC (4.9, r197663) gives the

following error:



test.cpp: In instantiation of 'struct B':

test.cpp:15:31:   required from here

test.cpp:3:42: error: invalid application of 'sizeof' to incomplete type 'S'

 template  struct B : A {};

  ^





If the operator- is replaced by a non-operator function, GCC compiles the

example successfully, which leads me to believe it's a bug.


[Bug c++/56901] [4.9 regression] lambda with implicit capture by reference

2013-04-10 Thread paolo.carlini at oracle dot com


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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-10

 Blocks||54367

 Ever Confirmed|0   |1


[Bug c++/56901] [4.9 regression] lambda with implicit capture by reference

2013-04-10 Thread zeratul976 at hotmail dot com


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



--- Comment #1 from Nathan Ridge  2013-04-10 
08:30:23 UTC ---

Tested with r197663.


[Bug c++/56901] New: [4.9 regression] lambda with implicit capture by reference

2013-04-10 Thread zeratul976 at hotmail dot com


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



 Bug #: 56901

   Summary: [4.9 regression] lambda with implicit capture by

reference

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: zeratul...@hotmail.com





The following code compiles with gcc 4.8 and clang, but not with gcc 4.9:





template 

void foo_impl()

{

int data;

auto L = [&](){ return data; };

[&](){ L(); }();

}



void foo()

{

foo_impl();

}





The error is:





test.cpp: In instantiation of 'foo_impl() [with  =

int]::__lambda1':

test.cpp:6:12:   required from 'struct foo_impl() [with

 = int]::__lambda1'

test.cpp:6:19:   required from 'void foo_impl() [with 

= int]'

test.cpp:11:19:   required from here

test.cpp:5:14: error: uninitialized const member 'foo_impl() [with

 = int]::__lambda0::__data'

 auto L = [&](){ return data; };

  ^





The error goes away if:

  - foo_impl is made a nontemplate

  - the call to the second lambda is inlined

  - either lambda is made to capture by value instead of reference


[Bug tree-optimization/56899] [4.6/4.7/4.8/4.9 Regression] Wrong constant folding

2013-04-10 Thread jakub at gcc dot gnu.org


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



--- Comment #8 from Jakub Jelinek  2013-04-10 
08:24:46 UTC ---

That said, removing that hunk completely would remove it even for the case

where the type has defined overflow, shouldn't we remove it just for undefined

overflow (or, replace the addition/subtraction with undefined one)?


[Bug tree-optimization/56900] [4.9 regression] FAIL: gcc.dg/tree-ssa/vrp87.c scan-tree-dump vrp2 "Folded into: if.*"

2013-04-10 Thread sch...@linux-m68k.org


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



--- Comment #1 from Andreas Schwab  2013-04-10 08:23:59 
UTC ---

Created attachment 29848

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

vrp87.c.128t.cddce2


[Bug tree-optimization/56900] New: [4.9 regression] FAIL: gcc.dg/tree-ssa/vrp87.c scan-tree-dump vrp2 "Folded into: if.*"

2013-04-10 Thread sch...@linux-m68k.org


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



 Bug #: 56900

   Summary: [4.9 regression] FAIL: gcc.dg/tree-ssa/vrp87.c

scan-tree-dump vrp2 "Folded into: if.*"

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: sch...@linux-m68k.org

CC: l...@gcc.gnu.org

Target: m68k-*-*





Created attachment 29847

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

vrp87.c.127t.vrp2



spawn /daten/aranym/gcc/gcc-20130410/Build/gcc/xgcc

-B/daten/aranym/gcc/gcc-20130410/Build/gcc/

/daten/aranym/gcc/gcc-20130410/gcc/testsuite/gcc.dg/tree-ssa/vrp87.c

-fno-diagnostics-show-caret -O2 -fdump-tree-vrp2-details

-fdump-tree-cddce2-details -S -o vrp87.s

PASS: gcc.dg/tree-ssa/vrp87.c (test for excess errors)

FAIL: gcc.dg/tree-ssa/vrp87.c scan-tree-dump vrp2 "Folded into: if.*"

FAIL: gcc.dg/tree-ssa/vrp87.c scan-tree-dump cddce2 "Deleting.*_Bool.*;"


[Bug tree-optimization/56899] [4.6/4.7/4.8/4.9 Regression] Wrong constant folding

2013-04-10 Thread jakub at gcc dot gnu.org


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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org

   Target Milestone|--- |4.7.3

Summary|Wrong constant folding  |[4.6/4.7/4.8/4.9

   ||Regression] Wrong constant

   ||folding



--- Comment #7 from Jakub Jelinek  2013-04-10 
08:23:00 UTC ---

I guess http://gcc.gnu.org/r152217 .  Anyway, shouldn't be hard to reproduce

even with plus (say if v is negative).



I've tried

__attribute__((noinline, noclone)) void

foo (int v)

{

  int x = 214748365 * (v + 1);

  if (x != -1932735285)

__builtin_abort ();

}



int

main ()

{

  foo (-10);

  return 0;

}

but we don't miscompile it, because while we perform the distributive law in

that case too (also wrongly), it is folded back to the (v + 1) * 214748365

form (after recursing several times between the two forms).


[Bug middle-end/53676] [4.7 regression] empty loop is not always removed now

2013-04-10 Thread rguenth at gcc dot gnu.org


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



Richard Biener  changed:



   What|Removed |Added



 CC||laurent.alfonsi at st dot

   ||com



--- Comment #18 from Richard Biener  2013-04-10 
08:11:36 UTC ---

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


[Bug c++/56894] performance regression in gcc 4.7.x due to a += operation

2013-04-10 Thread rguenth at gcc dot gnu.org


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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #2 from Richard Biener  2013-04-10 
08:11:36 UTC ---

The regression was fixed for 4.8 with



2012-06-27  Richard Guenther  



PR middle-end/53676

* tree-chrec.c (chrec_convert_1): Represent truncation to

a type with undefined overflow as truncation to an unsigned

type converted to the type with undefined overflow.

* tree-scalar-evolution.c (interpret_rhs_expr): For computing

the scalar evolution of a truncated widened operation avoid

looking at the non-existing evolution of the widened operation

result.



which this bug is a duplicate of.



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


[Bug c/56824] pragma GCC diagnostic push/pop regression for GCC diagnostic ignored "-Waggregate-return"

2013-04-10 Thread magnus.reftel at gmail dot com


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



Magnus Reftel  changed:



   What|Removed |Added



   Keywords||diagnostic



--- Comment #2 from Magnus Reftel  2013-04-10 
08:10:44 UTC ---

The problem also occurs when "-x c++" is specified, so it's not limited to C

only. I can't find any better component for the bug than C, so I'll leave it

here for now. Please move it if there's a better component.


[Bug tree-optimization/56899] Wrong constant folding

2013-04-10 Thread jakub at gcc dot gnu.org


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



--- Comment #6 from Jakub Jelinek  2013-04-10 
08:05:52 UTC ---

Better testcase:

__attribute__((noinline, noclone)) void

foo (int v)

{

  int x = -214748365 * (v - 1);

  if (x != -1932735285)

__builtin_abort ();

}



int

main ()

{

  foo (10);

  return 0;

}



This doesn't really look like an expansion issue, but folder issue, introduced

in between r152207 and r152360 (going to bisect it now).



The good *.original dump is:

  int x = (1 - v) * 214748365;

  if (x != -1932735285)

while bad is:

  int x = v * -214748365 + 214748365;

  if (x != -1932735285)

If we want to do this, we'd need to perform the addition in unsigned type

instead of signed.


[Bug tree-optimization/56899] Wrong constant folding

2013-04-10 Thread rguenth at gcc dot gnu.org


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



Richard Biener  changed:



   What|Removed |Added



   Keywords||wrong-code



--- Comment #5 from Richard Biener  2013-04-10 
08:01:22 UTC ---

We fold (1 - v) * 214748365 to v * -214748365 + 214748365 which is wrong

as it may introduce undefined overflow:



  /* The last case is if we are a multiply.  In that case, we can

 apply the distributive law to commute the multiply and addition

 if the multiplication of the constants doesn't overflow.  */

  if (code == MULT_EXPR)

return fold_build2 (tcode, ctype,

fold_build2 (code, ctype,

 fold_convert (ctype, op0),

 fold_convert (ctype, c)),

op1);



misses the fact that the multiplication of the non-constant part can

also overflow.  I think the case has to be removed completely.


[Bug tree-optimization/56899] Wrong constant folding

2013-04-10 Thread glisse at gcc dot gnu.org


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



--- Comment #4 from Marc Glisse  2013-04-10 07:49:24 
UTC ---

(In reply to comment #3)

> What's the target?  I can't reproduce on x86_64, armv5tel, or m68k.



I've reproduced it with -O2 on x86_64-linux-gnu using trunk.


[Bug tree-optimization/56899] Wrong constant folding

2013-04-10 Thread mikpe at it dot uu.se


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



--- Comment #3 from Mikael Pettersson  2013-04-10 
07:45:20 UTC ---

What's the target?  I can't reproduce on x86_64, armv5tel, or m68k.


[Bug tree-optimization/56899] Wrong constant folding

2013-04-10 Thread glisse at gcc dot gnu.org


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



Marc Glisse  changed:



   What|Removed |Added



 Status|RESOLVED|NEW

   Last reconfirmed||2013-04-10

 CC||glisse at gcc dot gnu.org

 Resolution|INVALID |

 Ever Confirmed|0   |1



--- Comment #2 from Marc Glisse  2013-04-10 07:42:51 
UTC ---

Andrew, he isn't multiplying INT_MIN by 9 but some number that is roughly

INT_MIN/10. extract_muldiv_1 seems to be missing some checks before

distributing the multiplication.


[Bug tree-optimization/56899] Wrong constant folding

2013-04-10 Thread pinskia at gcc dot gnu.org


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



Andrew Pinski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Andrew Pinski  2013-04-10 
07:32:52 UTC ---

-2147483648 * 9 overflows so the code is undefined so both answers are correct

but inconsistent.


[Bug bootstrap/56813] [4.9 regression] invalid assembly code for libiberty/cp-demangle.c on armv5tel-linux-gnueabi

2013-04-10 Thread mikpe at it dot uu.se


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



Mikael Pettersson  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #2 from Mikael Pettersson  2013-04-10 
07:24:50 UTC ---

The error is gone in gcc-4.9-20130407.  Don't know exactly which rev fixed it.


[Bug tree-optimization/56899] New: Wrong constant folding

2013-04-10 Thread ishiura-compiler at ml dot kwansei.ac.jp


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



 Bug #: 56899

   Summary: Wrong constant folding

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: ishiura-compi...@ml.kwansei.ac.jp





GCC 4.7.2 and 4.8.0 with -O2 option miscompile the following code where

INT_MIN == -2147483648.



  $ cat error.c

  int main (void)

  {

volatile int v = 10;

int x =  -214748365 * ( v - 1 );

return ( x == -1932735285 );/* should return 1 */

  }

  $ gcc error.c -O2

  $ ./a.out

  $ echo $?

  0



The following code, with "volatile" removed from variable v, is

correctly compiled.



  $ cat noerror.c

  int main(void)

  {

int v = 10;

int x =  -214748365 * ( v - 1 );

return ( x == -1932735285 );/* should return 1 */

  }

  $ gcc noerror.c -O2

  $ ./a.out

  $ echo $?

  1



The miscompile occurs on options "-O1 -fstrict-overflow."