[Bug c++/57011] Compiling with _GLIBCXX_CONCEPT_CHECKS rejects vector>

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||WONTFIX



--- Comment #1 from Paolo Carlini  2013-04-20 
07:53:44 UTC ---

The library-only checks date back to the C++98 times, nothing is supported

among the recent developments and we are not even trying to add that support,

many details are simply impossible to do right (not even the whole C++98 is

handled correctly). Will go completely away with constraints in the forthcoming

TS at this point.

[Bug libstdc++/57010] [c++0x] priority_queue<>::pop() calls self-move-assignment operator

[paolo.carlini at oracle dot com]

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



--- Comment #1 from Paolo Carlini  2013-04-20 
08:25:11 UTC ---

Note that the implementation of priority_queue::push and pop is fully

constrained by the Standard, directly boils down to operations on the

underlying container and std::push_heap and std::pop_heap calls, thus this

can't be an issue with our implementation of std::priority_queue itself.



Looks like the problem in in the implementation of std::pop_heap, eg,

__pop_heap should not be called at all when __last - __first == 0.

[Bug target/56797] [4.8 Regression] internal compiler error: in extract_insn, at recog.c:2150

[raj.khem at gmail dot com]

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



--- Comment #2 from Khem Raj  2013-04-20 08:39:48 
UTC ---

The patch posted here 

http://patchwork.ozlabs.org/patch/237891/

Fixed the problem for my case of building elfutils

[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size

[sch...@linux-m68k.org]

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



Andreas Schwab  changed:



   What|Removed |Added



   Keywords||wrong-code

   Target Milestone|--- |4.7.4

  Known to fail||4.7.1, 4.8.0



--- Comment #8 from Andreas Schwab  2013-04-20 09:54:32 
UTC ---

This is causing wrong code for libnss_files.so (_nss_files_init from

nss/files-init.c, only called by nscd) on powerpc due to the use of

-fsection-anchors, since the anchor offsets are computed from the wrong size

information.

[Bug libstdc++/57010] [c++0x] priority_queue<>::pop() calls self-move-assignment operator

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-20

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

   |gnu.org |com

 Ever Confirmed|0   |1



--- Comment #2 from Paolo Carlini  2013-04-20 
10:15:59 UTC ---

Mine. I'm testing something like this:



Index: stl_heap.h

===

--- stl_heap.h(revision 198008)

+++ stl_heap.h(working copy)

@@ -291,8 +291,11 @@

   __glibcxx_requires_valid_range(__first, __last);

   __glibcxx_requires_heap(__first, __last);



-  --__last;

-  std::__pop_heap(__first, __last, __last);

+  if (__last - __first > 1)

+{

+  --__last;

+  std::__pop_heap(__first, __last, __last);

+}

 }



   template 1)

+{

+  --__last;

+  std::__pop_heap(__first, __last, __last, __comp);

+}

 }



   /**

[Bug libstdc++/57010] [c++0x] priority_queue<>::pop() calls self-move-assignment operator

[glisse at gcc dot gnu.org]

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



Marc Glisse  changed:



   What|Removed |Added



 CC||glisse at gcc dot gnu.org



--- Comment #3 from Marc Glisse  2013-04-20 10:47:03 
UTC ---

(In reply to comment #2)

> Mine. I'm testing something like this:



Thanks.



> @@ -291,8 +291,11 @@



There's this cool diff option called -p that's recommended on the gcc website

;-)



>__glibcxx_requires_valid_range(__first, __last);

>__glibcxx_requires_heap(__first, __last);

> 

> -  --__last;

> -  std::__pop_heap(__first, __last, __last);

> +  if (__last - __first > 1)

> +{

> +  --__last;

> +  std::__pop_heap(__first, __last, __last);

> +}

>  }



Is that the same as:



  if (first != --__last)

std::__pop_heap(__first, __last, __last);

[Bug libstdc++/57010] [c++0x] priority_queue<>::pop() calls self-move-assignment operator

[glisse at gcc dot gnu.org]

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



Marc Glisse  changed:



   What|Removed |Added



 CC|glisse at gcc dot gnu.org   |



--- Comment #4 from Marc Glisse  2013-04-20 10:49:59 
UTC ---

[Gah, firefox has dumb key bindings that send unfinished messages...]



(In reply to comment #3)

> Is that the same as:

> 

>   if (first != --__last)

> std::__pop_heap(__first, __last, __last);



?



it would save one or two additions.

[Bug libstdc++/57010] [c++0x] priority_queue<>::pop() calls self-move-assignment operator

[paolo.carlini at oracle dot com]

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



--- Comment #5 from Paolo Carlini  2013-04-20 
10:55:44 UTC ---

Then we should consistently change the while loops elsewhere, right? Did you

analyze at all why both can't be optimized the same way?

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

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #1 from Tobias Burnus  2013-04-20 
11:02:41 UTC ---

Author: burnus

Date: Sat Apr 20 11:01:55 2013

New Revision: 198109



URL: http://gcc.gnu.org/viewcvs?rev=198109&root=gcc&view=rev

Log:

2013-04-20  Tobias Burnus  



PR fortran/56907

* trans-intrinsic.c (conv_isocbinding_function): Don't pack

* array

passed to C_LOC



2013-04-20  Tobias Burnus  



PR fortran/56907

* gfortran.dg/c_loc_test_22.f90: New.





Added:

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

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/trans-intrinsic.c

trunk/gcc/testsuite/ChangeLog

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

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #2 from Tobias Burnus  2013-04-20 
11:03:06 UTC ---

FIXED on the 4.9 trunk.

[Bug libstdc++/57010] [c++0x] priority_queue<>::pop() calls self-move-assignment operator

[paolo.carlini at oracle dot com]

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



--- Comment #6 from Paolo Carlini  2013-04-20 
11:07:38 UTC ---

By the way, traditionally, for *library* patches we never used -p + I'm

traveling sorry (C++ in Bristol), I barely installed some stuff on this tiny

laptop, I didn't mean to use it to do actual programming.



More to the point, I'm under the impression that preliminarily checking (__last

- __first > 1) is more user friendly as undefined behavior in case __first ==

__last happens to be true. I think we should just do that, consistently with

the existing while loops in the same file, at least to resolve this issue for

4.8.x too. Maybe reconsider later.

[Bug libstdc++/57010] [c++0x] priority_queue<>::pop() calls self-move-assignment operator

[glisse at gcc dot gnu.org]

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



--- Comment #7 from Marc Glisse  2013-04-20 11:17:27 
UTC ---

(In reply to comment #6)

> By the way, traditionally, for *library* patches we never used -p + I'm

> traveling sorry (C++ in Bristol), I barely installed some stuff on this tiny

> laptop, I didn't mean to use it to do actual programming.



I hope it is clear that it wasn't a reproach :-(



> More to the point, I'm under the impression that preliminarily checking 
> (__last

> - __first > 1) is more user friendly as undefined behavior in case __first ==

> __last happens to be true.



We do have __glibcxx_requires_non_empty_range in there, but that's only in some

debug mode I guess. By the way, sort_heap is the only similar while condition I

could see.



> I think we should just do that, consistently with

> the existing while loops in the same file, at least to resolve this issue for

> 4.8.x too. Maybe reconsider later.



Ok.

[Bug libstdc++/57010] [c++0x] priority_queue<>::pop() calls self-move-assignment operator

[glisse at gcc dot gnu.org]

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



--- Comment #8 from Marc Glisse  2013-04-20 11:25:30 
UTC ---

(In reply to comment #6)

> More to the point, I'm under the impression that preliminarily checking 
> (__last

> - __first > 1) is more user friendly as undefined behavior in case __first ==

> __last happens to be true.



Forgot to mention: this version should have the same user-friendliness, use of

!= vs < is mostly orthogonal.



  if (first < --__last)



(but you can stick to your version, I was only proposing an alternative)

[Bug c++/54948] template unnecessarily displayed as "A< template-parameter-1-1 >" not "A"

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  2013-04-20 
12:03:29 UTC ---
There are several "bugs" in this case. The first one is that we consider that
the type of:

template struct A

is "struct A<  >". It would be nicer to print something
like "struct A" or "struct A<>". Clang never needs to print made up
names.

The second bug is that I think we record T when parsing, but later we drop it.
I wasn't able to find when we drop it. There is a lot going on between the
moment we parse T and the moment we parse {, so it is rather difficult to
figure out. Stepping in the parser is rather frustrating.

I am afraid that the only person that may know what is going or where to look
is Jason. There is lookup_template_class, but by the time we call it, we
already dropped T (or so it seems to me, maybe it is recorded somewhere else).

[Bug c++/54948] template unnecessarily displayed as "A< template-parameter-1-1 >" not "A"

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  2013-04-20 
12:06:10 UTC ---
BTW, the parser may benefit by marking some functions with "skip" to help
debugging. All the cp_lexer_peek_* are useless to step into.

[Bug c++/57012] New: pretty-printer does not handle well template parameter packs

[manu at gcc dot gnu.org]

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



 Bug #: 57012

   Summary: pretty-printer does not handle well template parameter

packs

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: m...@gcc.gnu.org





/home/manuel/test3/src/gcc/testsuite/g++.dg/cpp0x/pr31432.C:2:40: error:

parameter pack '' must be at the end of the template

parameter list

/home/manuel/test3/src/gcc/testsuite/g++.dg/cpp0x/pr31432.C:7:11: error:

type/value mismatch at argument 1 in template parameter list for

'template<, class> struct A'

/home/manuel/test3/src/gcc/testsuite/g++.dg/cpp0x/pr31432.C:7:11: error:  

expected a constant of type '', got 'int'

/home/manuel/test3/src/gcc/testsuite/g++.dg/cpp0x/pr31432.C:7:14: error:

invalid type in declaration before ';' token

/home/manuel/test3/src/gcc/testsuite/g++.dg/cpp0x/pr31432.C:8:11: error:

type/value mismatch at argument 1 in template parameter list for

'template<, class> struct A'

/home/manuel/test3/src/gcc/testsuite/g++.dg/cpp0x/pr31432.C:8:11: error:  

expected a constant of type '', got 'char'

/home/manuel/test3/src/gcc/testsuite/g++.dg/cpp0x/pr31432.C:8:14: error:

invalid type in declaration before ';' token



Clang++ by comparison:



/home/manuel/test3/src/gcc/testsuite/g++.dg/cpp0x/pr31432.C:2:10: error:

template parameter pack must be the last template parameter

template struct A // { dg-error "parameter pack" }

 ^

[Bug c++/57013] New: pretty-printing canonical template-parameters is more confusing than helpful

[manu at gcc dot gnu.org]

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

 Bug #: 57013
   Summary: pretty-printing canonical template-parameters is more
confusing than helpful
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org


manuel@gcc10:~/test3/198021M/build/gcc$ ~/test3/198021M/build/gcc/cc1plus
/home/manuel/test3/src/gcc/testsuite/g++.dg/cpp0x/variadic79.C -std=c++11
/home/manuel/test3/src/gcc/testsuite/g++.dg/cpp0x/variadic79.C:7:57: error:
type/value mismatch at argument 1 in template parameter list for
‘template class ... > struct A’
 template class... B> struct A {}; // { dg-error
"mismatch|'template class ... B ...'" }
 ^
/home/manuel/test3/src/gcc/testsuite/g++.dg/cpp0x/variadic79.C:7:57: error:  
expected a template of type ‘template class
...’, got ‘template class ... B ...’


In this case, the canonical names are quite confusing, we'll be better off not
printing them at all. Just print ‘template class ... > struct
A’ and 'template class ...'

The second error should be a note and it should point to the declaration of A
and the parameter there.

[Bug c++/57014] New: pretty-printer prints anonymous for template-parameter with a name

[manu at gcc dot gnu.org]

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

 Bug #: 57014
   Summary: pretty-printer prints anonymous for template-parameter
with a name
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org


/home/manuel/test3/src/gcc/testsuite/g++.dg/other/default5.C:47:22: error:
default argument missing for parameter 2 of ‘void B< >::F2(int, int,
int)’
 template void B::F2(int = 0, int, int) {}  // { dg-error "default" }
  ^

It should say 'void B::F2(int,int,int)

The location is wrong, it should point to parameter 2.

[Bug c++/57014] pretty-printer prints anonymous for template-parameter with a name

[manu at gcc dot gnu.org]

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

--- Comment #1 from Manuel López-Ibáñez  2013-04-20 
12:50:01 UTC ---
Just looking at the testsuite output, one can find many examples of this.

[Bug c++/54948] template unnecessarily displayed as "A< template-parameter-1-1 >" not "A"

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  2013-04-20 
12:50:26 UTC ---
Possibly related PR57014.

[Bug target/57009] Select best typed instruction for scalar bitwise operations

[glisse at gcc dot gnu.org]

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



--- Comment #1 from Marc Glisse  2013-04-20 13:00:48 
UTC ---

At least in the case where a constant is involved, it would probably be

necessary to look at how the result is used (makes it much harder). If it is

used in a floating point operation, doing the logic operation in the FPU is

better. If it is used in an integer operation, it is probably better to let the

ALU handle it:



union A { double d; unsigned long long i; };

bool f(double x){

  A a; a.d = x;

  unsigned long long inf = 0x7ff0;

  return (a.i & inf) != inf;

}



(I use != and not < in the example above because gcc insists on creating a new

constant inf-1 and replacing 

[Bug target/11824] [ARM] Parameter passing via stack could be improved

[bpringlemeir at gmail dot com]

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



Bill Pringlemeir  changed:



   What|Removed |Added



 CC||bpringlemeir at gmail dot

   ||com



--- Comment #4 from Bill Pringlemeir  2013-04-20 
13:59:19 UTC ---

As far as I understand, the instruction stream is smaller, but there are two

extra memory writes to adjust the stack.  This optimization is only important

for '-Os'.  Generally, it will slow the code as data writes and code fetches

are generally the same cost and this trades 2 for 1.

[Bug rtl-optimization/17838] spills are not re-used

[bpringlemeir at gmail dot com]

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



Bill Pringlemeir  changed:



   What|Removed |Added



 CC||bpringlemeir at gmail dot

   ||com



--- Comment #12 from Bill Pringlemeir  
2013-04-20 15:47:36 UTC ---

(In reply to comment #11)



> Note that using -O3 for embedded targets isn't recommended; use -Os instead.



In this case the code is computationally intensive.  It doesn't make sense to

compile with '-Os' for cryptographic algorithms.



However, I think that a performance increase can be achieved by working with

gcc.  I have worked on an ARM project where two different developers choose

'TomsFastMath' and 'libgcrypt' as a crypto-base.  It seems that 'libgcrypt' was

performing better on the ARM.  I believe this is because it used 'gcc' inline

assembler to map op-codes not available in 'C'.  Gcc's inline assembler is very

nice as you don't have to do register allocation and all the other nice things

that 'gcc' does for us.



http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=mpi/longlong.h;hb=HEAD



The use of the carry bit for multi-precision arithmetic gives a large advantage

for algorithms such as RSA cites as being worse with ARMcc versus 'gcc' on the

ARM.



For the original issue which the bug was filed (x86 sha), I can understand your

frustration.  I also tried to expand the SHA to handle 64 bits at a time as you

have done with MMX ('__builtin_ia32_pslld', etc).  It is difficult to get this

to work with 'gcc'; I only had a 30% speed up versus 32bit versions.

[Bug gcov-profile/57015] New: Link error while building GCC 4.8.0 with 4.7.2 and Binutils 2.22: hidden symbol `__deregister_frame_info' in /.../4.7.2/libgcc_eh.a(unwind-dw2-fde-dip.o) is referenced by

[ludo at gnu dot org]

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



 Bug #: 57015

   Summary: Link error while building GCC 4.8.0 with 4.7.2 and

Binutils 2.22: hidden symbol `__deregister_frame_info'

in /.../4.7.2/libgcc_eh.a(unwind-dw2-fde-dip.o) is

referenced by DSO

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: gcov-profile

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

ReportedBy: l...@gnu.org





While building GCC 4.8.0 with GCC 4.7.2 and ld from Binutils 2.22, I get the

following error while link gcov:



g++   -g -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W

-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute

-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings

-fno-common  -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  gcov.o

libcommon.a ../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a

../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -o gcov

ld: gcov: hidden symbol `__deregister_frame_info' in

/nix/store/47myfniw4x7kfc601d7q1yvz5mixlr00-gcc-4.7.2/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/libgcc_eh.a(unwind-dw2-fde-dip.o)

is referenced by DSO

ld: final link failed: Bad value

collect2: error: ld returned 1 exit status



The problem vanishes when switching to Binutils 2.23.2.



In case it matters, the configure flags are:

("CONFIG_SHELL=/nix/store/ryk1ywzz31kp4biclxq3yq6hpjycalyy-bash-4.2/bin/bash"

"SHELL=/nix/store/ryk1ywzz31kp4biclxq3yq6hpjycalyy-bash-4.2/bin/bash"

"--prefix=/nix/store/2qwicp3m3lwq6j44i72kdly7awv3pppx-gcc-4.8.0"

"--enable-fast-install" "--enable-plugin" "--enable-languages=c,c++"

"--disable-multilib" "--with-local-prefix=/no-gcc-local-prefix"

"--with-native-system-header-dir=/nix/store/9fnjjsbarscbmakr44ixfv9yhg6z12mw-glibc-2.17/include").



Thanks,

Ludo'.

[Bug fortran/45424] [F2008] Add IS_CONTIGUOUS intrinsic

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 CC||janus at gcc dot gnu.org

Summary|F2008: Add is_contiguous|[F2008] Add IS_CONTIGUOUS

   |intrinsic   |intrinsic



--- Comment #4 from janus at gcc dot gnu.org 2013-04-20 17:41:22 UTC ---

(In reply to comment #1)

> d) The gfc_is_simply_contiguous function needs to be refined and extended - 
> and

> a "gfc_is_simply_noncontiguous" has to be added.



Another application for 'gfc_is_simply_noncontiguous' would be to reject

invalid code like



  integer, dimension(1:5,1:5), target :: zzz

  type(c_ptr) :: ptr

  ptr = c_loc (zzz(4:,4:))



cf. http://gcc.gnu.org/ml/fortran/2013-04/msg00181.html and follow-ups.

[Bug c++/57005] alias template's pseudo-destructor is rejected

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-20

 Ever Confirmed|0   |1



--- Comment #1 from Jonathan Wakely  2013-04-20 
18:56:11 UTC ---

I'm not 100% sure, but I think it's valid and should compile

[Bug c++/57016] New: [4.9 Regression] [C++0x] ICE: unexpected expression '__is_final(hash)' of kind trait_expr

[zsojka at seznam dot cz]

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



 Bug #: 57016

   Summary: [4.9 Regression] [C++0x] ICE: unexpected expression

'__is_final(hash)' of kind trait_expr

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: zso...@seznam.cz





Created attachment 29905

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

autoreduced testcase



Compiler output:

$ gcc -std=gnu++0x testcase.C 

testcase.C: In instantiation of 'class unordered_set':

testcase.C:130:16:   required from here

testcase.C:127:49: internal compiler error: unexpected expression

'__is_final(hash)' of kind trait_expr

   template < typename > pair < iterator, bool > emplace ();

 ^

0x72b0a8 cxx_eval_constant_expression

/mnt/svn/gcc-trunk/gcc/cp/semantics.c:8158

0x72dfc6 cxx_eval_outermost_constant_expr

/mnt/svn/gcc-trunk/gcc/cp/semantics.c:8178

0x617685 convert_nontype_argument

/mnt/svn/gcc-trunk/gcc/cp/pt.c:5601

0x617685 convert_template_argument

/mnt/svn/gcc-trunk/gcc/cp/pt.c:6382

0x610c1d coerce_template_parms

/mnt/svn/gcc-trunk/gcc/cp/pt.c:6721

0x619498 lookup_template_class_1

/mnt/svn/gcc-trunk/gcc/cp/pt.c:7280

0x619498 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,

int, int)

/mnt/svn/gcc-trunk/gcc/cp/pt.c:7577

0x61ea91 tsubst_aggr_type

/mnt/svn/gcc-trunk/gcc/cp/pt.c:9837

0x6121c0 tsubst(tree_node*, tree_node*, int, tree_node*)

/mnt/svn/gcc-trunk/gcc/cp/pt.c:11176

0x61e06a tsubst_template_args

/mnt/svn/gcc-trunk/gcc/cp/pt.c:9634

0x61e14b tsubst_template_args

/mnt/svn/gcc-trunk/gcc/cp/pt.c:9616

0x61ea6e tsubst_aggr_type

/mnt/svn/gcc-trunk/gcc/cp/pt.c:9831

0x6121c0 tsubst(tree_node*, tree_node*, int, tree_node*)

/mnt/svn/gcc-trunk/gcc/cp/pt.c:11176

0x61e06a tsubst_template_args

/mnt/svn/gcc-trunk/gcc/cp/pt.c:9634

0x61ea6e tsubst_aggr_type

/mnt/svn/gcc-trunk/gcc/cp/pt.c:9831

0x6121c0 tsubst(tree_node*, tree_node*, int, tree_node*)

/mnt/svn/gcc-trunk/gcc/cp/pt.c:11176

0x6353d5 tsubst_qualified_id

/mnt/svn/gcc-trunk/gcc/cp/pt.c:11967

0x5ff41f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,

bool)

/mnt/svn/gcc-trunk/gcc/cp/pt.c:13702

0x60809f tsubst_expr

/mnt/svn/gcc-trunk/gcc/cp/pt.c:13383

0x614d79 tsubst_template_arg

/mnt/svn/gcc-trunk/gcc/cp/pt.c:9100

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



Tested revisions:

r198108 - crash

4.8 r198108 - OK

[Bug c++/57011] Compiling with _GLIBCXX_CONCEPT_CHECKS rejects vector>

[redi at gcc dot gnu.org]

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



--- Comment #2 from Jonathan Wakely  2013-04-20 
19:41:38 UTC ---

I've fixed the note about concepts in the manual

[Bug libmudflap/41253] mudflap complains about c++ temporary passed in to global ctor

[kurt at roeckx dot be]

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



Kurt Roeckx  changed:



   What|Removed |Added



 CC||kurt at roeckx dot be



--- Comment #2 from Kurt Roeckx  2013-04-20 20:53:53 UTC 
---

Almost all mudflap violations I see seem to be related to temporary objects.

[Bug bootstrap/57017] New: «Error: expecting string instruction after `rep'» in code w/o inline assembly

[aversa at email dot arizona.edu]

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

 Bug #: 57017
   Summary: «Error: expecting string instruction after `rep'» in
code w/o inline assembly
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ave...@email.arizona.edu


Compiling code without inline assembly gives an error:

libtool: compile:  gcc -std=gnu99 -DPACKAGE_NAME=\"libblkmaker\"
-DPACKAGE_TARNAME=\"libblkmaker\" -DPACKAGE_VERSION=\"0.1\"
"-DPACKAGE_STRING=\"libblkmaker 0.1\""
-DPACKAGE_BUGREPORT=\"luke_libblkma...@dashjr.org\"
-DPACKAGE_URL=\"http://gitorious.org/bitcoin/libblkmaker\";
-DPACKAGE=\"libblkmaker\" -DVERSION=\"0.1\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -O3 -O3 -MT
blkmaker.lo -MD -MP -MF .deps/blkmaker.Tpo -c blkmaker.c  -fPIC -DPIC -o
.libs/blkmaker.o
/tmp/ccot8mMw.s: Assembler messages:
/tmp/ccot8mMw.s:529: Error: expecting string instruction after `rep'

However, disabling inline assembly "-fno-asm" only fixes the problem when "-O3"
is not used. The error always occurs when not specifying "-fno-asm".

[Bug bootstrap/57017] «Error: expecting string instruction after `rep'» in code w/o inline assembly

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2013-04-20 
21:44:50 UTC ---

Can you attach the preprocessed source?

[Bug c/57018] New: Miscompilation of bison 2.7.1 under "-Os -fomit-frame-pointer"

[michael at talamasca dot ocis.net]

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



 Bug #: 57018

   Summary: Miscompilation of bison 2.7.1 under "-Os

-fomit-frame-pointer"

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: mich...@talamasca.ocis.net





Created attachment 29906

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

Code to generate a pair of objects showing the bug



GCC 4.8.0 miscompiles bison 2.7.1 when compiling for space with frame pointer

omission.  (I've built gcc with --enable-frame-pointer expressly so my code

isn't bloated with exception data when I omit it on the command line.)



There are multiple breakages, but I've nailed down one of them in the attached

case.  It seems to involve the combination of passing structures by value and

the optimization opportunities of functions not called from outside an object.



So long as extenal_noop does nothing, calling real_entry_point should always

result in its argument being copied to main_blob.  But main_blob is full of

garbage at the problematic optimization "-Os -fomit-frame-pointer".



This is on i386-pc-linux-uclibc.

[Bug fortran/57019] New: Compiler crashes (and make wrong assignments) at some combinations of pointers

[thambsup at gmail dot com]

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

 Bug #: 57019
   Summary: Compiler crashes (and make wrong assignments) at some
combinations of pointers
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thamb...@gmail.com


This bug has two parts.

!here we have  types of data:
type cParticle
real(4) :: v(3),r0(2),rS(3),r1(2),SinA,CosA
endtype cParticle
type aParticle
real(4) :: v(3),r0(2)
endtype aParticle
type pCItem
type(aParticle) :: Atm
type(cParticle) :: Ele
type(cParticle) :: Ion
end type pCItem

!and array+pointers:
type(pCItem),allocatable,target,dimension(:,:)::pCellArray
type(cParticle),pointer,dimension(:,:)::pArray
type(cParticle),pointer::p_pointer
real(4),pointer,dimension(:)::v_pointer
real(4),pointer::s_pointer
allocate( pCellArray(1:ipMax,1:iCells) )
pArray=>pCellArray%Ele !for example

!now let's try
p_pointer=>pArray(1,1);

and we have
~/src gfortran -Wall bug.f95
data_types.f95: In function ‘MAIN__’:
data_types.f95:19: internal compiler error: Ошибка сегментирования
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

and we can achive this bug if we write s_pointer=>pArray(1,1)%SinA, but not if
v_pointer=>pArray(1,1)%v

!%%%
the second part of this bug is wrong assignments.

if we write "pArray(1,1)%v=10" -- only first component of vector will be
written, but if we make it via transitional pointer "v_pointer=>pArray(1,1)%v ;
v_pointer=10" -- everything is fine.

[Bug fortran/57019] Compiler crashes (and make wrong assignments) at some combinations of pointers

[thambsup at gmail dot com]

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



--- Comment #1 from thambsup at gmail dot com 2013-04-21 02:34:19 UTC ---

it was tested under ubuntu 10.04 and 12.04, (gfortran-4.4.3 & 4.4.6), and there

is no such problem in g95.

[Bug target/57018] Miscompilation of bison 2.7.1 under "-Os -fomit-frame-pointer"

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



   Keywords||wrong-code

 Target||i386-pc-linux-uclibc

  Component|c   |target



--- Comment #1 from Andrew Pinski  2013-04-21 
03:57:17 UTC ---

I tried to reproduce this on x86_64-linux-gnu with no luck.



Is there a reason why you are using i386 rather than i686 (or even i586) for

the target?  i386 is no longer even supported by the Linux kernel.

[Bug bootstrap/57017] «Error: expecting string instruction after `rep'» in code w/o inline assembly

[aversa at email dot arizona.edu]

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



--- Comment #2 from Alan Aversa  2013-04-21 
03:57:56 UTC ---

Created attachment 29907

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

the preprocessed C source file

[Bug target/57017] «Error: expecting string instruction after `rep'» in code w/o inline assembly

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-04-21

  Component|bootstrap   |target

 Ever Confirmed|0   |1



--- Comment #3 from Andrew Pinski  2013-04-21 
03:59:55 UTC ---

(In reply to comment #2)

> Created attachment 29907 [details]

> the preprocessed C source file



This cannot be the preprocessed source as it still includes #include in it.

[Bug target/57018] Miscompilation of bison 2.7.1 under "-Os -fomit-frame-pointer"

[michael at talamasca dot ocis.net]

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



--- Comment #2 from michael at talamasca dot ocis.net  2013-04-21 04:36:34 UTC ---

I've always been in the habit of specifying --host=i386-... so that my binaries

don't vary based on where I compile them.



I tried a few -march options to no effect.



However, I think I've found the reason.  One unusual thing about my GCC is that

I compiled with --enable-frame-pointer even though I always manually reverse

that from the command line.  This is because GCC bloats all omit-frame-pointer

code with exception tables otherwise.  (I wish GCC had an "-fundebuggable"

option to express what I've always meant by -fomit-frame-pointer all these

years...)



I tried compiling my case with "-Os -fomit-frame-pointer

-fasynchronous-unwind-tables" and that suppressed the bug.

[Bug target/57018] Miscompilation of bison 2.7.1 under "-Os -fomit-frame-pointer"

[pinskia at gcc dot gnu.org]

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



--- Comment #3 from Andrew Pinski  2013-04-21 
05:04:48 UTC ---

(In reply to comment #2)

> I've always been in the habit of specifying --host=i386-... so that my 
> binaries

> don't vary based on where I compile them.

> 

> I tried a few -march options to no effect.

> 

> However, I think I've found the reason.  One unusual thing about my GCC is 
> that

> I compiled with --enable-frame-pointer even though I always manually reverse

> that from the command line.  This is because GCC bloats all omit-frame-pointer

> code with exception tables otherwise.  (I wish GCC had an "-fundebuggable"

> option to express what I've always meant by -fomit-frame-pointer all these

> years...)



-fno-asynchronous-unwind-tables is your answer to that question which you

answer basically right below:



> 

> I tried compiling my case with "-Os -fomit-frame-pointer

> -fasynchronous-unwind-tables" and that suppressed the bug.

[Bug bootstrap/57020] New: error: expected expression before ‘)’ token

[aversa at email dot arizona.edu]

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

 Bug #: 57020
   Summary: error: expected expression before ‘)’ token
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ave...@email.arizona.edu


Created attachment 29908
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29908
full source file

I get this error:

elist.h:184:10: error: expected expression before ‘)’ token
  ((type *)((char *)(ptr)-(intptr_t)(&((type *)0)->member)))
  ^

Full code snippet:
#define list_entry(ptr, type, member) \
((type *)((char *)(ptr)-(intptr_t)(&((type *)0)->member)))