[Bug middle-end/52940] conversion from MODE_PARTIAL_INT uses sign extension for unsigned types

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2012-04/msg01043.htm
   ||l
   Last reconfirmed||2012-04-24
 CC||bernds at gcc dot gnu.org,
   ||ebotcazou at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-24
 CC||jb at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Janne Blomqvist  2012-04-24 06:37:16 
UTC ---
Confirmed.

I agree that at runtime we should allow full use of the range that the hardware
provides, the Fortran numerical model be damned. 

Also, since the overhead of range checking in string->character conversions is
AFAICS insignificant, I see no reason why it couldn't be enabled all the time.
Thus it's IMHO unnecessary to burden users with having to remember yet another
option.

In order to implement this, we'd need to consider MIN values of signed types
separately from MAX values. Perhaps in mk-kinds-h.sh we should also generate
GFC_INTEGER_X_{MAX,MIN} macros. Trying to figure out whether such macros are
always available also on non-C99 targets, I got bogged down in a maze of
GCC_HEADER_STDINT, glimits.h and whatnot, so I'm not sure actually. OTOH,
currently we typedef the GFC_{U}INTEGER_X types to the C99 {u}intNN_t types,
which are required to have two's complement representation, so we could just
hardcode the values (except for __int128_t where the compiler apparently
doesn't support large enough literals?).

[Bug middle-end/27139] Optimize double INT->FP->INT conversions with -ffast-math

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #2 from Marc Glisse  2012-04-24 
06:35:43 UTC ---
(In reply to comment #0)
> int test (int a)
> {
> return (double) a;
> }

I just wrote the very same testcase today, extracted from my code...

> Produces:
> 
> cvtsi2sd%edi, %xmm0
> cvttsd2si   %xmm0, %eax
> ret

Still does. Did you have any idea how to handle it?

> However, following code does the same (at least for -ffast-math):
> movl%edi, %eax
> ret

I don't think -ffast-math is relevant here, on x86 the int->double conversion
is exact hence the reverse has to be as well.

(In reply to comment #1)
> Confirmed, I doubt this shows up that much anyways.

Just posting to mention that it does show up...

[Bug c++/53099] New: Internal compiler error on short testcase

[rippey.e at gmail dot com]

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

 Bug #: 53099
   Summary: Internal compiler error on short testcase
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rippe...@gmail.com


When a file containing only "template a() { class a <" is run it produces:

bad21.cpp:1:10: error: ‘A’ has not been declared
 template a() { class a <
  ^
bad21.cpp:1:15: error: ISO C++ forbids declaration of ‘a’ with no type
[-fpermissive]
 template a() { class a <
   ^
bad21.cpp: In function ‘int a()’:
bad21.cpp:1:25: error: parse error in template argument list
 template a() { class a <
 ^
bad21.cpp:1:25: error: using typedef-name ‘a< >’ after
‘class’
 template a() { class a <
 ^
bad21.cpp:1:25: internal compiler error: tree check: expected tree that
contains ‘decl minimal’ structure, have ‘template_id_expr’ in
check_elaborated_type_specifier, at cp/decl.c:11513
 template a() { class a <
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This is with SVN version 186738 on i686 GNU/Linux, with no configure options.
No special command line options are required - this is triggered by "g++
bad.cpp".  

The code snippet is obviously invalid C++.  The snippet was arrived at by
taking a program that was valid C++ but also triggered internal compiler
errors, and reducing its size as much as possible without regard for validity.

[Bug middle-end/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  2012-04-24 
06:14:43 UTC ---
Author: jakub
Date: Tue Apr 24 06:14:37 2012
New Revision: 186746

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186746
Log:
PR middle-end/53084
* varasm.c (compute_reloc_for_constant): Handle ADDR_EXPR
of MEM_REF.
(output_addressed_constants): Likewise.

* gcc.c-torture/execute/pr53084.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr53084.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/varasm.c

[Bug middle-end/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2012-04-24 
06:11:00 UTC ---
Author: jakub
Date: Tue Apr 24 06:10:53 2012
New Revision: 186745

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186745
Log:
PR middle-end/53084
* varasm.c (compute_reloc_for_constant): Handle ADDR_EXPR
of MEM_REF.
(output_addressed_constants): Likewise.

* gcc.c-torture/execute/pr53084.c: New test.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/execute/pr53084.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/varasm.c

[Bug middle-end/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2012-04-24 
06:09:00 UTC ---
Author: jakub
Date: Tue Apr 24 06:08:55 2012
New Revision: 186743

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186743
Log:
PR middle-end/52999
* varasm.c (get_section): Don't ICE for section conflicts with
built-in section kinds.

Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/varasm.c

[Bug middle-end/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2012-04-24 
06:07:34 UTC ---
Author: jakub
Date: Tue Apr 24 06:07:30 2012
New Revision: 186742

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186742
Log:
PR middle-end/53084
* varasm.c (compute_reloc_for_constant): Handle ADDR_EXPR
of MEM_REF.
(output_addressed_constants): Likewise.

* gcc.c-torture/execute/pr53084.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr53084.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug middle-end/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2012-04-24 
06:03:47 UTC ---
Author: jakub
Date: Tue Apr 24 06:03:43 2012
New Revision: 186741

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186741
Log:
PR middle-end/52999
* varasm.c (get_section): Don't ICE for section conflicts with
built-in section kinds.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/varasm.c

[Bug middle-end/53010] [4.8 Regression] crash due to null ptr deref

[regehr at cs dot utah.edu]

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

--- Comment #2 from John Regehr  2012-04-24 04:51:01 
UTC ---
Yes, this has gone away as of the last couple days.

[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate

[noloader at gmail dot com]

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

--- Comment #6 from Jeffrey Walton  2012-04-24 
04:38:54 UTC ---
(In reply to comment #5)

> >At code generation, I did not think there was even the concept of program or 
> >shared object.
> 
> And this is where you are wrong.  GCC has a concept of program vs shared
> library.
My apologies. I was not aware that object code had a gender (program versus
shared object).

[Bug middle-end/53010] [4.8 Regression] crash due to null ptr deref

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end
   Target Milestone|--- |4.8.0
Summary|crash due to null ptr deref |[4.8 Regression] crash due
   ||to null ptr deref

--- Comment #1 from Andrew Pinski  2012-04-24 
04:38:16 UTC ---
I think this has been fixed already.

[Bug preprocessor/52998] caret and -ftrack-macro-expansion don't mix well

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-24
 Ever Confirmed|0   |1

--- Comment #3 from Andrew Pinski  2012-04-24 
04:36:42 UTC ---
Confirmed.

[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  2012-04-24 
04:35:57 UTC ---
>Forgive my ignorance, but why does it matter at the code generation stage? 

Easy.  With PIE, global variables and functions are considered to bind local
while with PIC they are considered to bind globally (aka override able).


>At code generation, I did not think there was even the concept of program or 
>shared object.

And this is where you are wrong.  GCC has a concept of program vs shared
library.

[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate

[noloader at gmail dot com]

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

--- Comment #4 from Jeffrey Walton  2012-04-24 
04:34:42 UTC ---
(In reply to comment #1)
> 
> Also how can you tell the difference between compiling for executable and
> shared library if you don't supply -fPIC?  So adding -aslr is not going to be
> useful really.
The compiler driver would make the determination at link time, and pass the
appropriate switch to the linker. I did not think it was a difficult concept.
My apologies.

[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate

[noloader at gmail dot com]

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

--- Comment #3 from Jeffrey Walton  2012-04-24 
04:32:35 UTC ---
(In reply to comment #2)
> GCC is not a mind reader.
I kind of knew that.

> There is no way for GCC to know if you want to do
> PIC or PIE code.
Forgive my ignorance, but why does it matter at the code generation stage? How
are relocations different in the object code of a program versus a shared
object? At code generation, I did not think there was even the concept of
program or shared object.

[Bug libgomp/52993] gomp_init_nest_lock_25: possible bad call to memset

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-24
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2012-04-24 
04:32:17 UTC ---
For LP64I32 targets, the code will most likely just work correctly as the
struct will be two ints which is the same size as one pointer.

While for LPI32 targets, it will be broken.  So confirmed.

[Bug target/52989] Installation error on OS X (arm-eabi) cross-compiler

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
 Target||arm-eabi
  Component|other   |target

--- Comment #1 from Andrew Pinski  2012-04-24 
04:26:31 UTC ---
>--with-multilib-list=interwork

Maybe that is broken.

[Bug c++/52987] bogus expected ; before for undeclared type

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-24
 Ever Confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  2012-04-24 
04:23:33 UTC ---
Confirmed.  The C front-end handles this much better:
t.c: In function ‘foo’:
t.c:2:3: error: unknown type name ‘x’
   x var;
   ^

[Bug c/52986] x86_64 GCC 4.7.0 can't compile x86 GCC 4.6.2; gtype-desc.c

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Andrew Pinski  2012-04-24 
04:22:19 UTC ---
Dup so closing as such.

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

[Bug bootstrap/51969] [4.6 regression] trunk gcc unable to build gcc 4.6

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||kallisti5 at unixzen dot
   ||com

--- Comment #7 from Andrew Pinski  2012-04-24 
04:22:19 UTC ---
*** Bug 52986 has been marked as a duplicate of this bug. ***

[Bug translation/52984] Different information message in Turkish locale.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||MOVED

--- Comment #1 from Andrew Pinski  2012-04-24 
04:21:16 UTC ---
The translations are handled by the translation project.  Translation issues
should be reported directly to them rather to us.

[Bug driver/52982] add option to select particular linker

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-04-24 
04:17:58 UTC ---
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00402.html

[Bug other/52930] quadmath: missing logbq, modfq, nexttowardq, exp2q

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/52875] ADL failure + ICE in decltype

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-24
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2012-04-24 
04:04:59 UTC ---
Confirmed.

[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #2 from Andrew Pinski  2012-04-24 
04:03:38 UTC ---
GCC is not a mind reader.  There is no way for GCC to know if you want to do
PIC or PIE code.

[Bug bootstrap/52847] "case" shell quoting problem in top-level makefile

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-24
 Ever Confirmed|0   |1

--- Comment #2 from Andrew Pinski  2012-04-24 
04:01:49 UTC ---
Index: config/mh-ppc-aix
===
--- config/mh-ppc-aix(revision 186738)
+++ config/mh-ppc-aix(working copy)
@@ -5,4 +5,4 @@
 # don't do it any more.
 BOOT_ADAFLAGS = -gnatapg
 BOOT_LDFLAGS = -Wl,-bbigtoc
-LDFLAGS = `case $(CC) in *gcc*) echo -Wl,-bbigtoc ;; esac;`
+LDFLAGS = `case "$(CC)" in *gcc*) echo -Wl,-bbigtoc ;; esac;`


Is the full patch.

[Bug bootstrap/52847] "case" shell quoting problem in top-level makefile

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||powerpc-*-aix*
  Component|other   |bootstrap

--- Comment #1 from Andrew Pinski  2012-04-24 
04:00:41 UTC ---
>CC="gcc -mminimal-toc"

You should not need -mminimal-toc because of this toplevel makefile part.

[Bug bootstrap/52850] Linker path ends up using wrong zlib

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-04-24 
03:58:50 UTC ---
>The problem is that there is an unsuitable copy of libz installed 

That sounds like an user problem rather than a GCC issue.

[Bug driver/52863] Enable -Wall by default

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #3 from Andrew Pinski  2012-04-24 
03:57:17 UTC ---
I think we should not.  I did not write in the thread on the email list because
I was busy at the time.

I have only seen two bug reports asking for it in the last 6 years (this is one
of them).

I think we should spend more time in improving our documentation rather than
enabling -Wall by default.

[Bug middle-end/53093] [4.8 Regression]: tls/alias-1.c ICE, emutls

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug c/53064] -Wsequence-point behaves inconsistently

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2012-04-24 
03:52:18 UTC ---
Note in the other case there is no sequence point because function arguments
are in the same sequence as the addition.

[Bug c/53064] -Wsequence-point behaves inconsistently

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-04-24 
03:51:32 UTC ---
>  a + (++a ? 0 : 0);

Hmm, I don't think there is a sequence point issue here compared to the other
case where it might cause an undefined code.

(++a ? 0 : 0) is all in done in one sequence point so that is defined and then
added to a.  a might be accessed before or after the sequence point where a is
modified but there is a sequence point between the access and the modification.

[Bug c++/53097] [c++0x] Missed optimization: lambda closure object could be smaller

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-24
 Ever Confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  2012-04-24 
01:45:51 UTC ---
The easy way to implement this would be something like:
include 

int main(int argc, char **argv)
{
  struct {
  int a, b;
  };
  auto foo = [&](){return a + b;};
  printf("%d\n", (int)sizeof(foo));
  return 0;
}

and then only the pointer to the struct needs to be done for the closure.

[Bug tree-optimization/53098] New: [4.8 Regression] tree-vect-loop.c:1414:19: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]

[danglin at gcc dot gnu.org]

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

 Bug #: 53098
   Summary: [4.8 Regression] tree-vect-loop.c:1414:19: error:
comparison between signed and unsigned integer
expressions [-Werror=sign-compare]
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu


/home/dave/gnu/gcc/objdir/./prev-gcc/g++
-B/home/dave/gnu/gcc/objdir/./prev-gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.7.0/hppa-linux-gnu/bin/ -nostdinc++
-B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu
-I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -c
  -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber../../gcc/gcc/tree-vect-loop.c -o tree-vect-loop.o
../../gcc/gcc/tree-vect-loop.c: In function ‘bool
vect_analyze_loop_operations(loop_vec_info, bool)’:
../../gcc/gcc/tree-vect-loop.c:1414:19: error: comparison between signed and
unsigned integer expressions [-Werror=sign-compare]
&& max_niter < vectorization_factor))
   ^
cc1plus: all warnings being treated as errors
make[3]: *** [tree-vect-loop.o] Error 1

[Bug target/47197] ICE in gimplify_expr, at gimplify.c:7153 on AltiVec code (vec_dst)

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from William J. Schmidt  2012-04-24 
01:12:07 UTC ---
Thanks, Joseph -- I'll get that fixed up.  Appreciate the help.

[Bug c++/53097] New: [c++0x] Missed optimization: lambda closure object could be smaller

[luto at mit dot edu]

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

 Bug #: 53097
   Summary: [c++0x] Missed optimization: lambda closure object
could be smaller
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@mit.edu


This code:

include 

int main(int argc, char **argv)
{
  int a, b;
  auto foo = [&](){return a + b;};
  printf("%d\n", (int)sizeof(foo));
  return 0;
}

prints 16 (on x86-64) on gcc 4.6 and something quite close to 4.7 at -O2 and
-Ofast.  This is as expected if the closure object is implemented as imagined
in the spec.

In this particular case, accessing a from the lambda is defined behavior iff
accessing b is defined (because either a and b are both in scope or both out of
scope, so the lambda could be optimized based on the knowledge that a and b are
at a fixed offset from each other.  This would give size 8.

(It sounds like this could be rather difficult.  clang++ 2.9 works the same way
as g++.  I don't really expect to see this optimization implemented anytime
soon.)

[Bug target/53087] [powerpc] Poor code from cstore expander

[dje at gcc dot gnu.org]

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

--- Comment #6 from David Edelsohn  2012-04-24 00:40:28 
UTC ---
GCC 4.1 produced:

 lis 9,0xcf8
 li 0,1
 ori 9,9,63
 slw 0,0,3
 and 0,0,9
 neg 0,0
 srwi 3,0,31
 blr

The branch code is better than the code using mfcr, but the straight-line code
from XLC or GCC avoiding CR is better than both.

[Bug testsuite/53028] add dg-pedantic

[mikestump at comcast dot net]

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

--- Comment #9 from Mike Stump  2012-04-24 
00:31:35 UTC ---
Since little proof was added to support the assertion that the additional
testing is useful, I can remain skeptical about it, though, the CFE people
certainly are free to require it, what they say goes.  I like the idea of
testing new code, just I think it could be over done.

I'll give you an example, I think we all can agree on.

Let's say we add a warning.  The code goes in, and a single testcase:

main() {
i = code to produce warning;  // warning
}

but, we don't also test:

-pedantic-errors

main() {
i = code to produce warning; // warning
}

even though, it is reasonable.  We could, but don't.  Why don't we, because it
isn't worth the testing time and the maintenance time.  Testing it once, and
assuming that no one will accidentally change the warning is reasonable.  We
also don't test that the warning goes away with -w.  We don't test the warning
turns into an error with -Werror.

How many times has one of these tests caught someone modifying a pedantic into
a warning?  How many times has one of these tests caught someone modifying a
pedantic into an error?  How many times did someone modify a pedantic in one of
the two ways because a testcase wasn't present?

Feel free to use your best recollection for the above answers.  I can't help
but think the numbers are so low, as to not be worth the cost of the additional
testcases.

[Bug bootstrap/52878] [4.8 regression] bootstrap failure: "MASK_LONG_DOUBLE_128" redefined

[hjl at gcc dot gnu.org]

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

--- Comment #17 from hjl at gcc dot gnu.org  2012-04-23 
23:32:58 UTC ---
Author: hjl
Date: Mon Apr 23 23:32:54 2012
New Revision: 186729

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186729
Log:
Check if MASK_/TARGET_ macros defined for extra_masks

2012-04-23  H.J. Lu  

PR bootstrap/52878
* opth-gen.awk: Check if MASK_ and TARGET_ macros are defined for
extra_masks.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/opth-gen.awk

[Bug c++/53096] [DR 1333] [c++11] should be possible to default a copy ctor that takes non-const arg

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||rejects-valid
   Last reconfirmed||2012-04-23
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|[c++11] should be possible  |[DR 1333] [c++11] should be
   |to default a copy ctor that |possible to default a copy
   |takes non-const arg |ctor that takes non-const
   ||arg

[Bug bootstrap/52878] [4.8 regression] bootstrap failure: "MASK_LONG_DOUBLE_128" redefined

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #16 from Richard Henderson  2012-04-23 
23:20:43 UTC ---
(In reply to comment #14)

The patch looks hackish, as if there's an artificial distinction
between "normal" masks and extra masks.  Why is that?

That said, please commit the tested patch as-is, so that we repair
the bootstrap breakage.  Cleanups to "extra" can come later.

[Bug c++/53096] New: [c++11] should be possible to default a copy ctor that takes non-const arg

[eric.niebler at gmail dot com]

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

 Bug #: 53096
   Summary: [c++11] should be possible to default a copy ctor that
takes non-const arg
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eric.nieb...@gmail.com


The following code does not compile:

struct foo
{
foo() = default;
foo(foo &) = default; // ERROR HERE
foo(foo const &) = default;
};

The error is:

error: ‘foo::foo(foo&)’ declared to take non-const reference
cannot be defaulted in the class body

This was correct for the FDIS, but is now incorrect given the resolution for
core issue 1333:

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

The code above should be accepted.

[Bug c/53095] std=gnu99 atof x86

[JoaquinMonleon at gmail dot com]

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

--- Comment #3 from q2p0  2012-04-23 22:53:56 
UTC ---
#include 

int main()
{

// Error.
  double a = 0.5;
  double b = 0.01;
  std::cout << (int)(a / b) << std::endl;

// No error.
  double c = a/b;
  std::cout << (int)c << std::endl;

  return 0;
}


* I compile with other...

Sory, about my last sarcastic expresions, and my bad english.
I take a look to the paper when I have time.

Thanks for improve the GNU compiler GCC.

[Bug bootstrap/49797] CLooG use of LANGUAGE_C conflicts with MIPS compilers

[matt at use dot net]

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

Matt Hargett  changed:

   What|Removed |Added

 CC||matt at use dot net

--- Comment #3 from Matt Hargett  2012-04-23 22:19:35 UTC 
---
Can you please back port this to 4.6 as well? Running into this on Scientific
Linux 6.1 on x64 with GCC 4.6 trunk and latest cloog-isl and ppl. Thanks!

[Bug c/53095] std=gnu99 atof x86

[JoaquinMonleon at gmail dot com]

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

--- Comment #2 from q2p0  2012-04-23 22:04:15 
UTC ---
But if:

I use one architecture of 64 bits OR
I use the standard -std=99 OR
I use a temporal double variable OR
I compile other compiler that is not GCC

I don't get this error.

Ok I acept the response "This is the result of rounding".
All we know that the nearest representable number for a double (-259.) in a
short is (-258). I answering me if you really take a look to the code of main.

[Bug c/29467] -ansi -pedantic accepts _Bool without diagnostic

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #5 from Manuel López-Ibáñez  2012-04-23 
21:47:30 UTC ---
So confirmed.

[Bug target/47197] ICE in gimplify_expr, at gimplify.c:7153 on AltiVec code (vec_dst)

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  2012-04-23 21:46:23 UTC ---
On Wed, 18 Apr 2012, wschmidt at gcc dot gnu.org wrote:

> Joseph, could you please take a look?  Or let me know if you think it's not a
> front end problem.

In rs6000-c.c, when you put an argument inside a CALL_EXPR or SAVE_EXPR as 
part of resolving an AltiVec built-in function, you need to use 
c_fully_fold because subsequent calls to c_fully_fold won't look inside 
that expression.  In such a case, you can do

  bool maybe_const = true;
  if (!c_dialect_cxx ())
expr = c_fully_fold (expr, false, &maybe_const);

before using the new value of expr (and ignore whatever value maybe_const 
may have been set to).

[Bug testsuite/53028] add dg-pedantic

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  2012-04-23 21:38:00 UTC ---
On Wed, 18 Apr 2012, mikestump at comcast dot net wrote:

> I don't see much value in this.  The primary idea of the gcc testsuite is as a
> regression suite.  For a regression, there is just one bit of code that you're
> testing, with one set of options.

For more than a decade it's been established that the testsuite should 
verify that features or fixes added work as intended; it's not just 
testing a particular bug fix, but comprehensively covering the area of a 
change.  If the intended semantics are pedwarn-if-pedantic, that does mean 
testing what happens in three cases.  If it's a matter of differences 
between standard versions, similarly, testing for each version (and see 
the discussion referenced in 
 when I started 
adding such tests).

I think features such as dg-pedwarn-if-pedantic or similar would be a 
useful addition to the testsuite infrastructure.

[Bug c/47901] -Wall should not imply -Wformat-zero-length by default

[andersk at mit dot edu]

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

--- Comment #7 from Anders Kaseorg  2012-04-23 21:31:18 
UTC ---
That’s a _much_ higher-level style decision than assumed by any of the other
-Wall warnings (or indeed any other warning switches at all), and a
questionable one at that.  -Wall should not encourage me to duplicate all my
custom printf-like functions just so they can be used with the empty string.

I understand that I can turn this warning off, but this bug is about the
defaults, and defaults are important.

[Bug c/29467] -ansi -pedantic accepts _Bool without diagnostic

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  2012-04-23 21:22:38 UTC ---
I'd say it's a quality-of-implementation issue, but it probably would be 
best to diagnose this.  I've added such diagnostics for C11 keywords such 
as _Noreturn and _Static_assert outside C11 mode when adding support for 
those keywords, for example.

[Bug c/51712] -Wtype-limits should not trigger for types of implementation-defined signedness

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  2012-04-23 21:11:33 UTC ---
On Tue, 17 Apr 2012, manu at gcc dot gnu.org wrote:

> Unfortunately, I cannot see any way to know that FOO is a constant that comes
> from an enum. Joseph, is this possible to do in the C FE? 

The original types of expressions that came from enums are already tracked 
for use of -Wc++-compat (checking if C code is compatible with stricter 
C++ rules for enums).  (This is what c-typeck.c:build_external_ref uses 
the type pointer for: storing the original type of an enum.)  So the 
information is available in at least parts of the C front end.

[Bug c/53095] std=gnu99 atof x86

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-04-23 
21:05:38 UTC ---
http://gcc.gnu.org/bugs/#nonbugs_general

[Bug c/53091] Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 - works fine in clang

[bugs at m8y dot org]

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

--- Comment #11 from bugs at m8y dot org 2012-04-23 21:01:03 UTC ---
Yeah, I get the difference now.
Ok. Fair.
So, I guess clang is just taking the values of the const ints at the time the
assignment occurs (0x01 and 0x02)
and assigning 0x03.  If RIGHT or UP were changed, RIGHTUP would not change.

Ok, what gcc is doing *does* make sense I 'spose :)

[Bug c/53091] Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 - works fine in clang

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  2012-04-23 
20:50:21 UTC ---
(In reply to comment #3)
> Hey. I attached it as well. I didn't just provide a URL.

Yeah, sorry, I wrote my comment before you attached it.

(In reply to comment #6)
> Can rewrite both const int and enum, so I don't really see why enum is
> permitted but const int isn't, they both offer
> about the same amount of safety.

http://c-faq.com/ansi/constasconst.html

Take it up with the C committee, not GCC.


(In reply to comment #8)
> Not that you are likely to care, but the Standard states that enumeration 
> types
> are of a type that is compatible with an implementation-defined one of the
> integral types.

Enumeration TYPES are compatible with integral TYPES.  But enumerators are
constant, const-qualified variables are not constants.

> So. you can rewrite enum values just as easily as you can a const int by 
> taking
> a pointer to it.  And that site claims it behaves like a const int.

The site's wrong.

[Bug c/47901] -Wall should not imply -Wformat-zero-length by default

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  2012-04-23 20:49:38 UTC ---
-Wall is expecting printf-like functions where empty strings are useless 
as arguments and might indicate e.g. cruft you hadn't completely cleaned 
up from your program.  Or a style where you have separate specialized 
functions for such cases (like the style where you carefully use fputs, 
fputc etc. for cases that can be covered by those functions, instead of 
using printf universally).

There's nothing wrong with using a -Wno- option (or associated pragmas) if 
the stylistic choices for your program are different from those for -Wall.  
Wall tries to strike a reasonable balance, but won't be perfect for 
everyone; it's a good starting point for both enabling further warnings, 
and disabling other warnings, to taste.

[Bug c/53095] New: std=gnu99 atof x86

[JoaquinMonleon at gmail dot com]

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

 Bug #: 53095
   Summary: std=gnu99 atof x86
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joaquinmonl...@gmail.com


Created attachment 27227
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27227
the preprocessed file (*.i*) that triggers the bug

/*

Exact version of GCC: That I know that version 4.3, 4.6 and 4.7 has this bug.

System Type: x86_32, i686, 32BITS Intel architecture. It don't occurs in 64 bit
intel architectures.

Options given when GCC was configured/build: The error happen when you use
-std=gnu99 ¡¡BY DEFAULT :O!! standar or -std=gnu89, but not when you use other
standar like -std=c99

The complete command line that triggers the bug: "gcc main.c -o main"

The compiler output (error messages, warnings, etc.): None.

the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, or, in the case of a bug
report for the GNAT front end, a complete set of source files (see below): As
attachment

Thank's I love GNU & your work a million of thanks.

*/

#include 
#include 

int main(){

char *cadena = "-25.9";

//USING A TEMP VARIABLE
double d = atof(cadena) * 10;
short s1 = (short) d;
printf("%d\n",s1); //I GET -259

//WITHOUT A TEMP VARIABLE
short s2 = atof(cadena) * 10;
printf("%d\n",s2); //I GET -258? WTF?
}

[Bug c/53091] Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 - works fine in clang

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

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

--- Comment #9 from Andreas Schwab  2012-04-23 20:36:10 
UTC ---
enum constants are not objects, they don't have an address.

[Bug c++/49152] pretty printer cannot handle iterators and other complex expressions

[manu at gcc dot gnu.org]

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

--- Comment #45 from Manuel López-Ibáñez  2012-04-23 
20:27:39 UTC ---
(In reply to comment #44)
> On Sun, 1 Apr 2012, manu at gcc dot gnu.org wrote:
> 
> > moving
> > line-map out of libcpp to create a source-location library has been 
> > rejected in
> > the past.
> 
> I've reviewed my contributions to that discussion 
>  and I at least 
> did not reject that move; I wanted the new library not to contain any 
> translatable messages (so it doesn't need another message domain), and I 
> wanted motivation for the patch in terms of modularity and better 
> interfaces being the goal and physical separation into a library simply 
> being a means to that goal, but I did not object to a move as such.

Re-reading that very old discussion, and with four years of more experience, I
basically agree with everything you and others say there, including the fact
that a new library is probably not needed. However, I still think that physical
separation, be a directory along-side libcpp or under gcc, helps to clarify
module boundaries. 

Nevertheless, since it turns out I did not need a source-location library to
implement the caret, I am not planning to work on that patch. Getting that
patch approved is likely going to be a bikesheding exercise of epic
proportions. It would be nice if GCC became more modular, but now I don't see
that patch making a huge difference.

[Bug target/53087] [powerpc] Poor code from cstore expander

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

--- Comment #5 from David Edelsohn  2012-04-23 20:23:42 
UTC ---
XLC produces:

addi   r0,r0,1
addis  r4,r0,3320
slwr0,r0,r3
addi   r3,r4,63
andr0,r0,r3
cntlzw r3,r0
addi   r0,r3,-32
rlwinm r3,r0,1,31,31
blr

[Bug c/47901] -Wall should not imply -Wformat-zero-length by default

[andersk at mit dot edu]

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

--- Comment #5 from Anders Kaseorg  2012-04-23 20:22:20 
UTC ---
I’m not sure ("%s", "") is a suitable replacement in general.  Maybe this is a
far-fetched example, but what the purpose of custom_printf is to shell-quote
all its arguments, so that custom_printf(foo, "") writes "some_command" with no
arguments but custom_printf(foo, "%s", "") writes "some_command ''" with a
single empty argument?

In any event, ("%s", "") is certainly different code with a potential runtime
cost, and it’s not fair for -Wall to complain about the more straightforward
("") unless it’s reasonably likely for that code to be hiding some class of
bugs.  Is it?

(Another real-world example from a project I help maintain:
https://github.com/barnowl/barnowl/blob/barnowl-1.8.1/keys.c#L337 )

[Bug middle-end/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly

[ktietz at gcc dot gnu.org]

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

--- Comment #7 from Kai Tietz  2012-04-23 20:14:05 
UTC ---
This patch fixes issues for noticed for mingw targets on trunk and for 4.7.

[Bug c++/53094] New: vector literal

[marc.glisse at normalesup dot org]

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

 Bug #: 53094
   Summary: vector literal
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org


Hello,

VECTOR_TYPE should be a literal type in C++11, so we can have for instance:
constexpr __m128i v = { 1, 0 };
constexpr __m128i s = v + v;

Once PR c++/51033 is fixed, ideally, the following would also work:
constexpr long long i = v[1];
constexpr __m128i w = __builtin_shuffle (m, m);

but I guess this can be made in several steps as long as the compiler doesn't
ICE on those.

[Bug target/53087] [powerpc] Poor code from cstore expander

[steven at gcc dot gnu.org]

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

--- Comment #4 from Steven Bosscher  2012-04-23 
20:13:29 UTC ---
Smaller test case:

_Bool
foo (long unsigned int a)
{
  return (((1L << a) & 217579583UL) != 0);
}

==>

   .file   "t.c"
.section".toc","aw"
.section".text"
.align 2
.p2align 4,,15
.globl foo
.section".opd","aw"
.align 3
foo:
.quad   .L.foo,.TOC.@tocbase,0
.previous
.type   foo, @function
.L.foo:
li 10,1
lis 9,0xcf8
sld 3,10,3
ori 9,9,63
and. 10,3,9
mfcr 3
rlwinm 3,3,3,1
xori 3,3,1
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size   foo,.-.L.foo
.ident  "GCC: (GNU) 4.8.0 20120418 (experimental) [trunk revision
186580]"

[Bug target/53087] [powerpc] Poor code from cstore expander

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

Summary|Poor code for conversion|[powerpc] Poor code from
   |from _Bool to int   |cstore expander

--- Comment #3 from Steven Bosscher  2012-04-23 
20:12:37 UTC ---
The first time round to rs6000.md:cstore4, the insn isn't generated
because code==NE. The second time, some insns are emitted:

Breakpoint 11, emit_store_flag_1 (target=0x0, code=EQ, op0=0xfffb5f092c0,
op1=0xfffb5f60470, mode=DImode, unsignedp=0, normalizep=1, target_mode=QImode)
at ../../trunk/gcc/expmed.c:5363
5363  do_pending_stack_adjust ();
(gdb) next
5364  tem = emit_cstore (target, icode, code, mode, compare_mode,
(gdb) 
5366  if (tem)
(gdb) p tem
$67 = (rtx) 0xfffb5f094a0
(gdb) p debug_rtx(tem)
(reg:QI 132)
$68 = void
(gdb) p debug_rtx_list (get_last_insn(), -7)
(insn 15 14 16 (set (reg:CC 134)
(compare:CC (reg:DI 123 [ D.2005 ])
(const_int 0 [0]))) t.c:16 -1
 (nil))

(insn 16 15 17 (set (reg:DI 135)
(eq:DI (reg:CC 134)
(const_int 0 [0]))) t.c:16 -1
 (nil))

(insn 17 16 18 (set (reg:SI 133)
(subreg:SI (reg:DI 135) 4)) t.c:16 -1
 (nil))

(insn 18 17 0 (set (reg:QI 132)
(subreg:QI (reg:SI 133) 3)) t.c:16 -1
 (nil))

$69 = void
(gdb) next
5367return tem;
(gdb) 
5381}
(gdb) 
emit_store_flag (target=0xfffb5f09460, code=NE, op0=0xfffb5f092c0,
op1=0xfffb5f60470, mode=DImode, unsignedp=1, normalizep=1) at
../../trunk/gcc/expmed.c:5578
5578  if (tem != 0)
(gdb) p tem
$70 = (rtx) 0xfffb5f094a0
(gdb) l
5573   && rtx_cost (trueval, XOR, 1,
5574optimize_insn_for_speed_p ()) == 0)
5575{
5576  tem = emit_store_flag_1 (subtarget, rcode, op0, op1, mode, 0,
5577   normalizep, target_mode);
5578  if (tem != 0)
5579tem = expand_binop (target_mode, xor_optab, tem, trueval,
target,
5580INTVAL (trueval) >= 0, OPTAB_WIDEN);
5581}


So the problem is not the _Bool->int conversion but the cstore for
";; D.2013_7 = D.2005_5 != 0;"

[Bug c/47901] -Wall should not imply -Wformat-zero-length by default

[andersk at mit dot edu]

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

--- Comment #4 from Anders Kaseorg  2012-04-23 20:10:22 
UTC ---
Yes, I understand what -Wall is supposed to mean.

I don’t have a problem with -Wall warning about ‘if (foo = 3)’ when I probably
intended ‘if (foo == 3)’ and I could have written ‘if ((foo = 3))’ if that’s
what I really wanted.

I don’t have a problem with -Wall warning about ‘printf("hello", "world")’ when
I probably intended ‘printf("hello %s", "world")’ and I could have written
‘printf("hello")’ if that’s what I really wanted.

But ‘custom_printf_like_function(foo, "")’ is something different.  What do you
think that line indicates I intended?  What coding style do you think -Wall is
expecting if I really meant the empty string?

[Bug c/47901] -Wall should not imply -Wformat-zero-length by default

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  2012-04-23 
20:08:09 UTC ---
Well, I don't really see how custom_printf("") can produce any damage. It may
be an oversight when one actually wanted to print something, but it may be as
likely that one didn't want to print something and just trigger some side
effect of custom_printf.

As an alternative, the warning could suggest to use ("%s", "") to silence the
warning, no?

[Bug tree-optimization/52907] Underflowing floating point expressions wrongly folded to zero

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  2012-04-23 20:02:50 UTC ---
On Tue, 10 Apr 2012, rguenth at gcc dot gnu.org wrote:

> Does real.c even communicate this fact?

You can identify underflow from the result of multiplication or division 
being zero or subnormal (unless an operand is zero or infinite), just as 
overflow is identified from an infinite result.  Information about 
subnormal results may not be conveniently communicated by real.c, but 
simply handling zero results here would be enough for the use cases in 
glibc.

[Bug c/47901] -Wall should not imply -Wformat-zero-length by default

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  2012-04-23 19:58:15 UTC ---
There are plenty of warnings in -Wall that relate to things that are 
unusual but may be OK in some cases, or where -Wall expects a particular 
coding style to be used.  I think -Wformat-zero-length falls into the 
category of pointing out something that might be OK but is likely not to 
be intended.  So I think it's fine in -Wall - but if a subset of format 
checking warnings were enabled by default (as in Ubuntu, for example) then 
maybe that default subset would not include this one.

[Bug c/53091] Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 - works fine in clang

[bugs at m8y dot org]

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

--- Comment #8 from bugs at m8y dot org 2012-04-23 19:57:37 UTC ---
In response to comment #7, I was referring to this portion of the linked
document.
--
Not that you are likely to care, but the Standard states that enumeration types
are of a type that is compatible with an implementation-defined one of the
integral types. So what? For interest's sake here is an illustration:

enum ee{a,b,c}e_var, *ep;

The names a, b, and c all behave as if they were int constants when you use
them;
--
So. you can rewrite enum values just as easily as you can a const int by taking
a pointer to it.  And that site claims it behaves like a const int.
So, yeah, gotta say clang's behaviour seems more rational here.

Oh well. unc0rr might switch to enum in the interest of getting it working. 
The conversion code is not quite as tidy, but no matter.

I'll let you guys hash it out.  At leas clang works for now.

[Bug target/52877] ARC cross-compiler cc1 fails on "x=-1;"

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  2012-04-23 19:55:25 UTC ---
ARC support was obsoleted in 4.6 and removed for 4.7, so this should be 
closed WONTFIX.

[Bug c++/49152] pretty printer cannot handle iterators and other complex expressions

[joseph at codesourcery dot com]

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

--- Comment #44 from joseph at codesourcery dot com  2012-04-23 19:54:09 UTC ---
On Sun, 1 Apr 2012, manu at gcc dot gnu.org wrote:

> moving
> line-map out of libcpp to create a source-location library has been rejected 
> in
> the past.

I've reviewed my contributions to that discussion 
 and I at least 
did not reject that move; I wanted the new library not to contain any 
translatable messages (so it doesn't need another message domain), and I 
wanted motivation for the patch in terms of modularity and better 
interfaces being the goal and physical separation into a library simply 
being a means to that goal, but I did not object to a move as such.

[Bug middle-end/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #6 from Jakub Jelinek  2012-04-23 
19:50:40 UTC ---
Created attachment 27226
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27226
gcc47-pr53084.patch

Untested fix.

[Bug c/53091] Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 - works fine in clang

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  2012-04-23 
19:39:52 UTC ---
>But it does make 0 sense to me that const int is forbidden, but enum is
allowed...


Why variables are not part of C's constant integer expressions.  enum values
are not variables.

[Bug middle-end/53093] New: [4.8 Regression]: tls/alias-1.c ICE, emutls

[hp at gcc dot gnu.org]

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

 Bug #: 53093
   Summary: [4.8 Regression]: tls/alias-1.c ICE, emutls
Classification: Unclassified
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: h...@gcc.gnu.org
CC: hubi...@gcc.gnu.org
Target: cris-axis-elf


With revision 186677 this test passed.
>From revision 186688 and on, this test has failed as follows:

Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/tls/tls.exp ...
FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
FAIL: gcc.dg/tls/alias-1.c (test for excess errors)

With the message in gcc.log being:

Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/tls/alias-1.c 
-fno-diagnostics-show-caret-ansi -pedantic-errors   -isystem
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem
/tmp/hpautotest-gcc1/gcc/newlib/libc/include
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris/
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris
-L/tmp/hpautotest-gcc1/gcc/libgloss/cris 
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib -sim3  -lm   -o
alias-1.exe(timeout = 300)
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/tls/alias-1.c:24:3: internal
compiler error: vector VEC(varpool_node_ptr,base) push domain error, in
create_emultls_var at tree-emutls.c:709
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
compiler exited with status 1

Author of suspect patch in revision range CC:ed.

[Bug c/53091] Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 - works fine in clang

[bugs at m8y dot org]

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

--- Comment #6 from bugs at m8y dot org 2012-04-23 19:35:18 UTC ---
Oh, cool.
Probably going to replace w/ an enum, which does seem to work.
But it does make 0 sense to me that const int is forbidden, but enum is
allowed...

http://publications.gbdirect.co.uk/c_book/chapter6/enums.html

Can rewrite both const int and enum, so I don't really see why enum is
permitted but const int isn't, they both offer
about the same amount of safety.

I mean, might as well just force #define only. (please don't!)

[Bug c/53091] Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 - works fine in clang

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
URL|http://m8y.org/tmp/gcc_bug. |
   |c   |
 CC||jsm28 at gcc dot gnu.org,
   ||manu at gcc dot gnu.org
 Resolution|INVALID |

--- Comment #5 from Manuel López-Ibáñez  2012-04-23 
19:25:26 UTC ---
(In reply to comment #3)
> Anyway, I take it this is a "Won't Fix" ?

Not sure why. If Clang is allowed by the C standard, then surely GCC is allowed
as well. If the C++ FE has code to enable this, probably it can be reused in
the C FE. GCC could accept it with a -Wpedantic warning.

In any case, like everything, it boils down to having someone make it happen,
that is, providing a patch. I don't think any existing GCC developer will
tackle this in the near future, otherwise it would have been done already.

But let's wait for Joseph opinion to confirm this.

[Bug c/53091] Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 - works fine in clang

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #4 from Andreas Schwab  2012-04-23 19:20:25 
UTC ---
Just use an enum.

[Bug rtl-optimization/52528] combine bug (powerpc testcase)

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2012-04-23
 CC||ebotcazou at gcc dot
   ||gnu.org
 Resolution|FIXED   |
 Ever Confirmed|0   |1

--- Comment #5 from Eric Botcazou  2012-04-23 
19:06:49 UTC ---
Of course not.  Please backport patches in order.

[Bug c/53091] Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 - works fine in clang

[bugs at m8y dot org]

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

--- Comment #3 from bugs at m8y dot org 2012-04-23 18:59:59 UTC ---
Hey. I attached it as well. I didn't just provide a URL.

Anyway, I take it this is a "Won't Fix" ?

I guess it isn't the end of the world since we are targetting clang for llvm
output anyway.
Although gcc would be nice-to-have.
I don't think he's big on making specialcase #defines in this converter.

[Bug middle-end/53089] [4.8 Regression] gfortran.dg/coarray/atomic_1.f90 and gfortran.dg/coarray/registering_1.f90

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-23
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-04-23 
18:55:25 UTC ---
Confirmed.  Maybe a frontend bug.

[Bug middle-end/53088] [4.8 Regression] gcc.target/i386/pr39082-1.c

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-04-23 
18:54:41 UTC ---
(In reply to comment #1)
> Mine.  i386 outputs the message with input_loc, so it seems we need to set it
> correctly.

It should use some more sensible location though - input_location should be
essentially non-accessible from outside the frontend.  Also see the bogus
caret on the function prototype (which should point to the union parameter?)

[Bug other/53092] New: ICE using -ftree-loop-if-convert-stores -O3

[b3timmons at speedymail dot org]

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

 Bug #: 53092
   Summary: ICE using -ftree-loop-if-convert-stores -O3
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b3timm...@speedymail.org


Created attachment 27225
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27225
preprocessed C source

I reduced the original file atapi.i slightly, but here is the invocation:

gcc -v -B. -r -nostdlib -Wall -ftree-loop-if-convert-stores -O3 atapi.i
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++
--enable-cloog-backend=isl
Thread model: posix
gcc version 4.8.0 20120417 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-B' '.' '-r' '-nostdlib' '-Wall'
'-ftree-loop-if-convert-stores' '-O3' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1 -fpreprocessed
atapi.i -quiet -dumpbase atapi.i -mtune=generic -march=x86-64 -auxbase atapi
-O3 -Wall -version -ftree-loop-if-convert-stores -o /tmp/cc7uZdoI.s
GNU C (GCC) version 4.8.0 20120417 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.0 20120417 (experimental), GMP version
5.0.4, MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.8.0 20120417 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.0 20120417 (experimental), GMP version
5.0.4, MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 18e514d302ccbc55708943dff7b495a6
In file included from /build/qemu/sysemu.h:9:0,
 from /build/qemu/hw/ide/internal.h:13,
 from /build/qemu/hw/ide/atapi.c:26:
/build/qemu/hw/ide/internal.h: In function ‘cmd_inquiry’:
/build/qemu/hw/ide/internal.h:432:13: internal compiler error: Segmentation
fault

[Bug middle-end/53088] [4.8 Regression] gcc.target/i386/pr39082-1.c

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-23
 Ever Confirmed|0   |1

--- Comment #1 from Jan Hubicka  2012-04-23 
18:40:29 UTC ---
Mine.  i386 outputs the message with input_loc, so it seems we need to set it
correctly.

[Bug c/53091] Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 - works fine in clang

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-04-23 
18:38:29 UTC ---
The bug reporting guidelines ask for source code, not a URL.

Here's the code from the URL

#include 

const int SDL_HAT_UP = 0x01;
const int SDL_HAT_RIGHT = 0x02;
const int SDL_HAT_RIGHTUP = (SDL_HAT_RIGHT | SDL_HAT_UP);

int main(int argc, char **argv)
{
  printf("%x\n",SDL_HAT_RIGHTUP);
  return 0;
}

I think GCC is correct, the code is valid C++ but not valid C.

In C the initializer for a global variable must be a constant expression ("All
the expressions in an initializer for an object that has static storage
duration shall be constant expressions or string literals.") and (SDL_HAT_RIGHT
| SDL_HAT_UP) is not a constant expression.

http://c-faq.com/ansi/constasconst.html

I believe Clang is allowed to accept the code because the C standard also says
implementations may accept other forms of constant expression.

[Bug c/53091] Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 - works fine in clang

[bugs at m8y dot org]

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

--- Comment #1 from bugs at m8y dot org 2012-04-23 18:25:42 UTC ---
Created attachment 27224
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27224
Demo of problem

[Bug c/53091] New: Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 - works fine in clang

[bugs at m8y dot org]

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

 Bug #: 53091
   Summary: Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 -
works fine in clang
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
   URL: http://m8y.org/tmp/gcc_bug.c
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b...@m8y.org


Works in Clang 2.9 and Clang 3.0

Succeeds in g++ FWIW.

$ gcc gcc_bug.c
gcc_bug.c:5: error: initializer element is not constant

[Bug tree-optimization/52979] [4.7/4.8 Regression] likely wrong code bug w/packed bitfields

[regehr at cs dot utah.edu]

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

--- Comment #3 from John Regehr  2012-04-23 17:47:42 
UTC ---
I'll see if I can find another test case for this one.

[Bug c/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-04-23 
17:45:55 UTC ---
I don't see that on the trunk:
.section.rodata
.LC1:
.string"foo"
.align 8
.typeaa.1706, @object
.sizeaa.1706, 8
aa.1706:
.quad.LC1+1
Ah, but looking at current 4.7, I can reproduce that.  Will look at it.

[Bug tree-optimization/52979] [4.7/4.8 Regression] likely wrong code bug w/packed bitfields

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2012-04-23 
17:38:43 UTC ---
Doesn't reproduce with r186687 and above (supposedly just went latent with this
testcase).

[Bug middle-end/53090] suboptimal ivopt

[xinliangli at gmail dot com]

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

--- Comment #1 from davidxl  2012-04-23 17:37:40 
UTC ---
Created attachment 27223
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27223
benchmark source

[Bug middle-end/53090] New: suboptimal ivopt

[xinliangli at gmail dot com]

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

 Bug #: 53090
   Summary: suboptimal ivopt
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com


Compiling the attached benchmark code with trunk gcc, the code generated for
the hot memory swap loop (line 60) is very inefficient : both icc and llvm use
two ivs and generate a tight loop with 9 instructions, but gcc decides to use 3
ivs, and the loop exit testing code is wierd and inefficient -- it ends up
produce a loop with 11 instructions.

#define XCH(x,y){ Aint t_mp; t_mp=(x); (x)=(y); (y)=t_mp; }

for( i=1, j=k-1 ; iThis Inner Loop Header: Depth=3
movl(%rbx,%rdi,4), %ebp
movl(%rbx,%rsi,4), %eax
movl%eax, (%rbx,%rdi,4)
movl%ebp, (%rbx,%rsi,4)
decq%rsi
incq%rdi
cmpl%edx, %edi
leal-1(%rdx), %edx
jl.LBB0_11


The gcc version:

.L18:
movl(%rdx), %edi
addl$1, %ecx
movl(%rsi), %eax
movl%eax, (%rdx)
addq$4, %rdx
movl%edi, (%rsi)
movl%r8d, %edi
subq$4, %rsi
subl%ecx, %edi
cmpl%edi, %ecx
jl.L18


However gcc is doing the right thing when applied on the extracted test case:

#define XCH(x,y) { int t_mp; t_mp=(x); (x)=(y); (y)=t_mp; }

void foo (int *perm, int k)
{
 int i,j;
 for( i=1, j=k-1 ; i

[Bug c/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Target|*-*-mingw*  |x86_64-*-* i686-*-*

--- Comment #4 from Kai Tietz  2012-04-23 17:19:27 
UTC ---
(In reply to comment #3)
> Can't reproduce on x86_64-linux, please fill in Target.

Hmm, I can.  For x86_64-unknown-linux-gnu using -O0 as optimization option, I
see for this test

aa.2162:
.LC1:
 .string "foo"
 .quad .LC1+1

which is wrong, too.

[Bug target/53087] Poor code for conversion from _Bool to int

[steven at gcc dot gnu.org]

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

--- Comment #2 from Steven Bosscher  2012-04-23 
17:13:28 UTC ---
Expected code:

foo:
.quad   .L.foo,.TOC.@tocbase,0
.previous
.type   foo, @function
.L.foo:
lwz 9,0(3)
cmplwi 7,9,27
bgt 7,.L4
li 8,1
lis 10,0xcf8
sld 9,8,9
ori 10,10,63
and. 8,9,10
li 3,1
bnelr 0
.L4:
li 3,0
blr

[Bug lto/52605] LTO -g ICE when looking up context of VMTs of classes defined within functions

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
  Known to fail||4.7.0, 4.8.0

--- Comment #1 from Martin Jambor  2012-04-23 
17:04:23 UTC ---
This is still the only problem that prevents me from LTO building
Firefox with -g.  Moreover, I have just verified the problem is also
present also in 4.7 (and it's also the only one).  I really think we
should fix this for 4.7.1.

My patch proposed on the mailing list still applies (to both trunk and
the branch).

[Bug middle-end/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer

[dave.anglin at bell dot net]

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

--- Comment #6 from dave.anglin at bell dot net 2012-04-23 17:04:13 UTC ---
On 4/23/2012 12:16 PM, jakub at gcc dot gnu.org wrote:
> The PA specific thing there is that PA puts rtx constant pool into 
> .data.rel.ro
> section, something that doesn't happen on i?86/x86_64/ppc/ppc64 etc. to my
> knowledge.
This occurs in default_elf_select_section.  For example,

  case SECCAT_DATA_REL:
   sname = ".data.rel";
   break;
 case SECCAT_DATA_REL_LOCAL:
   sname = ".data.rel.local";
   break;
 case SECCAT_DATA_REL_RO:
   sname = ".data.rel.ro";

The category comes from here:

   else if (! TREE_READONLY (decl)
|| TREE_SIDE_EFFECTS (decl)
|| ! TREE_CONSTANT (DECL_INITIAL (decl)))
 {
   /* Here the reloc_rw_mask is not testing whether the section 
should
  be read-only or not, but whether the dynamic link will have to
  do something.  If so, we wish to segregate the data in 
order to
  minimize cache misses inside the dynamic linker.  */
   if (reloc & targetm.asm_out.reloc_rw_mask ())
 ret = reloc == 1 ? SECCAT_DATA_REL_LOCAL : SECCAT_DATA_REL;
   else
 ret = SECCAT_DATA;
 }

With PIC code, we get SECCAT_DATA_REL for the variable that caused
the diagnostic ICE.  It lacked a "const" qualifier.

[Bug middle-end/53089] New: [4.8 Regression] gcc.target/i386/pr39082-1.c

[hjl.tools at gmail dot com]

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

 Bug #: 53089
   Summary: [4.8 Regression] gcc.target/i386/pr39082-1.c
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: hubi...@gcc.gnu.org
Depends on: 53088


+++ This bug was initially created as a clone of Bug #53088 +++

On Linux/x86, revision 186687:

http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00639.html

caused:

FAIL: gfortran.dg/coarray/atomic_1.f90 -fcoarray=lib  -O2  -lcaf_single
execution test
FAIL: gfortran.dg/coarray/registering_1.f90 -fcoarray=lib  -O2  -lcaf_single
execution test

[Bug middle-end/53088] New: [4.8 Regression] gcc.target/i386/pr39082-1.c

[hjl.tools at gmail dot com]

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

 Bug #: 53088
   Summary: [4.8 Regression] gcc.target/i386/pr39082-1.c
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: hubi...@gcc.gnu.org


On Linux/x86-64, revision 186687:

http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00639.html

gave

FAIL: gcc.target/i386/pr39082-1.c  (test for warnings, line 33)

./xgcc -B./ -S ../../src-trunk/gcc/testsuite/gcc.target/i386/pr39082-1.c -O2
../../src-trunk/gcc/testsuite/gcc.target/i386/pr39082-1.c: In function ‘foo1’:
../../src-trunk/gcc/testsuite/gcc.target/i386/pr39082-1.c:16:1: note: the ABI
of passing union with long double has changed in GCC 4.4
 foo1 (union un u)
 ^

Revision 186685 gave

gcc -S -O2 gcc/gcc/testsuite/gcc.target/i386/pr39082-1.c
gcc/gcc/testsuite/gcc.target/i386/pr39082-1.c: In function ‘foo3’:
gcc/gcc/testsuite/gcc.target/i386/pr39082-1.c:33:12: note: the ABI of passing
union with long double has changed in GCC 4.4
   union un u = bar2 (x); /* { dg-message "note: the ABI of passing union with
long double has changed in GCC 4.4" } */
^

[Bug c/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2012-04-23 
16:47:32 UTC ---
Can't reproduce on x86_64-linux, please fill in Target.

[Bug target/53087] Poor code for conversion from _Bool to int

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||powerpc-unknown-linux-gnu
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-23
 Ever Confirmed|0   |1
  Known to fail||4.8.0

--- Comment #1 from Steven Bosscher  2012-04-23 
16:40:30 UTC ---
This code generation problem is important because the GIMPLE switch lowering
transformations (as ported from stmt.c) introduce this kind of code a lot (e.g.
for the gimple.[ch] predicates).