[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

[kcc at gcc dot gnu.org]

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



--- Comment #43 from Kostya Serebryany  2013-02-22 
07:11:06 UTC ---

gcc r196201:  -O2 -fno-aggressive-loop-optimizations

clang 175735: -O2 



x86_64 linux, both are using the new 7fff8000 shadow offset



   400.perlbench,  1136.00,-1.00,-0.00

   401.bzip2,   838.00,  1154.00, 1.38

 403.gcc,   716.00,   742.00, 1.04

 429.mcf,   582.00,   578.00, 0.99

   445.gobmk,   801.00,  1138.00, 1.42

   456.hmmer,  1277.00,  1515.00, 1.19

   458.sjeng,   869.00,  1258.00, 1.45

  462.libquantum,   532.00,   469.00, 0.88

 464.h264ref,  1303.00,  4395.00, 3.37

 471.omnetpp,   568.00,   585.00, 1.03

   473.astar,   647.00,   748.00, 1.16

   483.xalancbmk,   460.00,   534.00, 1.16

433.milc,   659.00,   614.00, 0.93

444.namd,   592.00,   531.00, 0.90

  447.dealII,   614.00,   706.00, 1.15

  450.soplex,   367.00,   406.00, 1.11

  453.povray,   423.00,   410.00, 0.97

 470.lbm,   377.00,   401.00, 1.06

 482.sphinx3,   958.00,  1325.00, 1.38



400.perlbench fails with a global-buffer-overflow which clang does not detect.

I did not investigate why. It could be a gcc false positive or clang false

negative.



464.h264ref is VERY slow, I did not look why.

[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects

[kcc at gcc dot gnu.org]

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



--- Comment #19 from Kostya Serebryany  2013-02-22 
07:01:51 UTC ---

In clang, static asan-rt is the default and the only option on Linux. 

(On Mac, the only option is dynamic, but that's a quite unfortunate limitation 

of the platform, it costs us quite a bit of pain during deployment).

I would also prefer to have static as the default on gcc-linux (for both asan

and tsan). 



In regular cases, when you build your own program static is what you need.



There is one case where we do need dynamic asan-rt and we build it separately:

C++ code called via SWIG from a python program. 

We already have the pre-built python binary and can not link anything to it

statically. 

But the deployment is rather painful here too, it would have been much simpler

if we could link asan-rt to python statically.

[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects

[pinskia at gcc dot gnu.org]

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



--- Comment #18 from Andrew Pinski  2013-02-22 
06:55:59 UTC ---

(In reply to comment #17)

> It works for me, thank you very much for your efforts.

> Why don't you set -static-libasan as default?

> Because I still don't understand in which case dynamic libasan is useful...



It is more useful than having a static only version of libasan really.  I think

the asan guys are wrong in requiring static only stuff.

[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects

[t-gcc-bugzilla at snowelm dot com]

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



--- Comment #17 from Takaki Makino  
2013-02-22 06:38:33 UTC ---

(In reply to comment #15)

> r196201 landed the fresh asan run-time into gcc.

> -static-libasan should work well now, please try.



It works for me, thank you very much for your efforts.

Why don't you set -static-libasan as default?

Because I still don't understand in which case dynamic libasan is useful...

[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)

[howarth at nitro dot med.uc.edu]

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



Jack Howarth  changed:



   What|Removed |Added



  Attachment #29521|0   |1

is obsolete||



--- Comment #9 from Jack Howarth  2013-02-22 
04:59:53 UTC ---

Created attachment 29522

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

complete gcc-4_6-branch fixes for bootstrap against texinfo 5.0



One additional fix (present in gcc-4_7-branch and trunk) is required for

bootstrapping gcc-4_6-branch against texinfo 5.0. Tested on

x86_64-apple-darwin11.

[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled but supported by as (Solaris & Linux)

[dirtyepic at gentoo dot org]

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



--- Comment #9 from Ryan Hill  2013-02-22 02:31:03 
UTC ---

Well, the trouble is nowadays that many CPUs are exactly "this, except without

that".  But anyways, the test is fragile.  There is no reason something like

-march=core2 -mno-sse3 should cause this to fail (I don't think it should even

try to build it in the first place, but I'm sure there must be a reason).  So

if this code expects and requires -mavx to compile, append it after the user's

CFLAGS rather than letting them blow their feet off.

[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)

[howarth at nitro dot med.uc.edu]

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



--- Comment #8 from Jack Howarth  2013-02-22 
02:03:14 UTC ---

Created attachment 29521

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

backport of gcc-4_7-branch fixes to gcc-4_6-branch



The attached patch backports the additional fixes to gcc-4_6-branch.

[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)

[howarth at nitro dot med.uc.edu]

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



--- Comment #7 from Jack Howarth  2013-02-22 
02:01:10 UTC ---

Created attachment 29520

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

patch to fix gcc-4_7-branch bootstrap against texinfo 5.0



Current gcc-4_7-branch still fails to bootstrap against texinfo 5.0 due to

additional instances of @itemx. The attached patch fixes these and bootstraps

on x86_64-apple-darwin12.

Re: Not exception-safe default move constructors (demonstrated on std::pair)

[Daniel Krügler]

2013/2/21 Dmitry Marakasov :
> Hi!
>
> I'm not really sure which (g++ or libstdc++) problem this really is, so
> posting into both lists.

It doesn't look like a problem of libstdc++ to me (see below why).

> The problem is described here:
> http://cpp-next.com/archive/2009/10/exceptionally-moving/
>
> - You have two classes:
>   A, which has a proper move constructor which doesn't throw
>   B, which which only has copy constructor which may throw
> - You have an std::pair
> - You move a pair
>   std::pair pair1;
>   try {
> std::pair pair2(std::move(a));
>   }
>
> What happens:
> - A part is moved with move constructor. This is obviously destructive
>   to pair1.
> - B part is copied as it doesn't have move constuctor.
> - Now, that copy constructor throws (which is pretty expectable is it
> likely allocates resources). After this, as A part was already moved,
> we're left with corrupted pair1 (with empty A part).

I agree that this is the current to be expected behaviour. But it is
what the standard currently requires:

template 
struct pair {
  [..]
  pair(const pair&) = default;
  pair(pair&&) = default;
  [..]
};

> The same problem applies to most containers, but, for example, in
> std::vector it is solved gracefully:
>
> --- bits/vector.tcc from gcc-4.8:
>   pointer __tmp = _M_allocate_and_copy(__n,
>   _GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(this->_M_impl._M_start),
>   
> _GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(this->_M_impl._M_finish));
> ---
>
> so move semantics are only used IF the type has non-throwing(noexcept)
> move constructor.
>
> However, with pair this does not apply:
>
> --- bits/stl_pair.h from gcc-4.8:
> struct pair {
> ...
> constexpr pair(pair&&) = default;
> ---

I agree with the divergence relative to containers, but the current
specification imposes this requirement. User-code could observe any
difference (you do, for example), therefore it is hard to change.

I suggest that you instead send an LWG issue submission request as
described here:

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#submit_issue

> Either the default constructor generated by gcc is unsafe, or there
> should be custom, safe move constuctor with corresponding enable_if.
>
> I lean towards the former, as safe default move constuctors should be
> always generated probably, and specific ones may be really hard to
> implement for more complex types (tuples).

While I agree with your arguments this is primarily a standard Library
specification problem.

> I've written a small program which demonstrates the problem:
>
> https://gist.github.com/AMDmi3/5005557
>
> tested it on FreeBSD with gcc-4.8 and on Debian with gcc-4.7, and it
> showed problem on both.
>
> Is this really a gcc problem? Should I file a bug?

I don't think so. I suggest to send an LWG issue request instead.

- Daniel

[Bug middle-end/56420] [4.8 Regression] Arithmetic error in computation with compile time unsigned __int128 constant

[st at quanttec dot com]

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



--- Comment #5 from Stephan Tolksdorf  2013-02-21 
21:38:27 UTC ---

That was fast, thanks!

[Bug middle-end/56420] [4.8 Regression] Arithmetic error in computation with compile time unsigned __int128 constant

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #4 from Jakub Jelinek  2013-02-21 
21:36:57 UTC ---

Fixed.

[Bug rtl-optimization/50339] suboptimal register allocation for abs(__int128_t)

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



Summary|[4.8 Regression] suboptimal |suboptimal register

   |register allocation for |allocation for

   |abs(__int128_t) |abs(__int128_t)



--- Comment #6 from Jakub Jelinek  2013-02-21 
21:36:17 UTC ---

Removing the regression tag, while the RA should be still improved, this is no

longer a regression.

[Bug middle-end/56420] [4.8 Regression] Arithmetic error in computation with compile time unsigned __int128 constant

[jakub at gcc dot gnu.org]

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



--- Comment #3 from Jakub Jelinek  2013-02-21 
21:29:33 UTC ---

Author: jakub

Date: Thu Feb 21 21:29:29 2013

New Revision: 196215



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

Log:

PR middle-end/56420

* expmed.c (EXACT_POWER_OF_2_OR_ZERO_P): Do subtraction in uhwi, to

avoid signed wrapping.

(expand_mult): Handle properly multiplication by

((dword_type) -1) << (BITS_PER_WORD - 1).  Improve multiplication by

((dword_type) 1) << (BITS_PER_WORD - 1).  Avoid undefined behavior

in the compiler if coeff is HOST_WIDE_INT_MIN.

(expand_divmod): Don't make ext_op1 static, change it's type to

uhwi.  Avoid undefined behavior in -INTVAL (op1).



* gcc.dg/torture/pr56420.c: New test.



Added:

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

Modified:

trunk/gcc/ChangeLog

trunk/gcc/expmed.c

trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/50339] [4.8 Regression] suboptimal register allocation for abs(__int128_t)

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2013-02-21 
21:28:07 UTC ---

Author: jakub

Date: Thu Feb 21 21:28:03 2013

New Revision: 196214



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

Log:

PR rtl-optimization/50339

* lower-subreg.h (struct lower_subreg_choices): Add splitting_ashiftrt

field.

* lower-subreg.c (compute_splitting_shift): Handle ASHIFTRT.

(compute_costs): Call compute_splitting_shift also for ASHIFTRT

into splitting_ashiftrt field.

(find_decomposable_shift_zext, resolve_shift_zext): Handle also

ASHIFTRT.

(dump_choices): Fix up printing LSHIFTRT choices, print ASHIFTRT

choices.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/lower-subreg.c

trunk/gcc/lower-subreg.h

[Bug fortran/56423] New: F08/0071: Shall reject invalid Vector subscript target with Pointer assignment

[burnus at gcc dot gnu.org]

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



 Bug #: 56423

   Summary: F08/0071: Shall reject invalid Vector subscript target

with Pointer assignment

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: ice-on-invalid-code

  Severity: normal

  Priority: P3

 Component: fortran

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

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





Interp F08/0071, http://www.j3-fortran.org/doc/year/13/13-250.txt



Note: The J3/WG5 vote is still pending.





Case (4) of the test case below is invalid per clarified constraint F2008,

C724:



  "A variable that is a pointer target shall have either the TARGET

   or POINTER attribute, and shall not be an array section with a

   vector subscript."



Currently, gfortran ICEs with:

internal compiler error: in gfc_conv_expr_descriptor, at

fortran/trans-array.c:6589



  PROGRAM m197006

REAL,TARGET :: x(100) = [ (i,i=1,100) ]

REAL,POINTER :: p(:)

TYPE t

  REAL,POINTER :: q(:)

END TYPE

TYPE(t) y

p => x ! (1)

y = t(x)   ! (2)

!   p => x( [ 1,4,9,25 ] ) ! (3)  ! Invalid and rejected

y = t(x( [ 1,4,9,25 ] ))   ! (4)  ! Invalid per IR F08/0071 but not

rejected

PRINT *,y%q

  END PROGRAM

[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled but supported by as (Solaris & Linux)

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #8 from Jakub Jelinek  2013-02-21 
21:22:48 UTC ---

That is a user error, just don't do that.  As the user provided CFLAGS/CXXFLAGS

override the default flags, you really shouldn't be using -mno-this and

-mno-that when building gcc, because that will disable what is required to

compile gcc successfully.  If you want to build gcc to support some CPU that

doesn't have AVX etc., just configure it for such a CPU.

[Bug fortran/56422] New: IR F08/0086: gfortran rejects valid implied-shape arrays

[burnus at gcc dot gnu.org]

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



 Bug #: 56422

   Summary: IR F08/0086: gfortran rejects valid implied-shape

arrays

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: rejects-valid

  Severity: normal

  Priority: P3

 Component: fortran

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

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





IR F08/0086, http://www.j3-fortran.org/doc/year/13/13-235r1.txt allows the

following, which is currently rejected by:



   Error: Assumed size array at (1) must be a dummy argument



Note: The IR has not yet passed the J3/WG5 vote and has thus to be taken with a

pinch of salt.





Q1.  Consider



  Program test1

Character(*) a,b(*)

Dimension c(*)

Parameter (a='123', b=['1','2','3'])

Character(*),Parameter :: c = [ '44','55','66' ]

Print *,a,b,c

  End



[...]



Q2. Consider



  Subroutine test2(a)

Real,Dimension(*) :: a,c

Parameter (c = [ 45.6 ])

a(b) = c

  End Subroutine



[...]

ANSWER:



A1. Yes, the program was intended to conform to the Fortran standard.

An edit is provided to modify the requirement for prior

specification so as to allow this case.



A2. Yes, the program is intended to conform to the Fortran standard.

An edit is provided to add syntax to permit this unambiguously.

[...]

[Bug libfortran/30162] [4.7/4.8 Regression] Unformatted sequential I/O with named pipes does not work

[jb at gcc dot gnu.org]

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



--- Comment #54 from Janne Blomqvist  2013-02-21 
20:39:58 UTC ---

I'd suggest to close the unformatted sequential part of this PR as WONTFIX.

Maybe it worked sometime in the past for small record sizes when buffered IO

was used for pipes, but that was by accident not by design. I think re-enabling

buffering for pipes would open up a can of worms for very little benefit.



A way to "properly" enable this would be to rework the IO library so that we

know how much we're writing before writing the initial record marker (so that

we don't need to seek back and fill in the correct value later), however that

implies a rather major rework of how we do IO, so IMHO the benefit is not worth

it.

[Bug middle-end/56140] GCC inlines incorrect function in __transaction_relaxed

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #2 from Aldy Hernandez  2013-02-21 
20:35:40 UTC ---

With my patch for PR56108, since this transaction is obviously irrevocable, we

will no longer instrument the inlined code, thus fixing this PR as well.



Fixed in trunk.

[Bug middle-end/56108] Asm statement in transaction_relaxed crashes compiler.

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #7 from Aldy Hernandez  2013-02-21 
20:31:28 UTC ---

And now closing for real...

[Bug c++/56418] errors do not show the types (makes it hard to debug)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  2013-02-21 
20:26:24 UTC ---
Clang doesn't do much better:

test.cc:18:3: error: no matching function for call to 'foo'
  foo({ 1, 2.3, 123 }); // error -- argument mismatch [8]
  ^~~
test.cc:4:6: note: candidate function not viable: cannot convert initializer
list argument to 'const Foo'
void foo(const Foo &f);
 ^

but at least it doesn't print ‘’.

[Bug middle-end/56108] Asm statement in transaction_relaxed crashes compiler.

[aldyh at gcc dot gnu.org]

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



--- Comment #5 from Aldy Hernandez  2013-02-21 
20:16:34 UTC ---

Author: aldyh

Date: Thu Feb 21 20:16:26 2013

New Revision: 196213



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

Log:

PR middle-end/56108

* trans-mem.c (execute_tm_mark): Do not expand transactions that

are sure to go irrevocable.

testsuite/

* gcc.dg/tm/memopt-1.c: Declare functions transaction_safe.



Added:

trunk/gcc/testsuite/gcc.dg/tm/pr56108.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/gcc.dg/tm/memopt-1.c

trunk/gcc/trans-mem.c

[Bug libfortran/30162] [4.7/4.8 Regression] Unformatted sequential I/O with named pipes does not work

[jb at gcc dot gnu.org]

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



--- Comment #53 from Janne Blomqvist  2013-02-21 
20:13:12 UTC ---

Author: jb

Date: Thu Feb 21 20:13:04 2013

New Revision: 196212



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

Log:

Fix regression when writing formatted sequential to a pipe.



2013-02-21  Janne Blomqvist  



PR libfortran/30162

* io/open.c (test_endfile): Call stell only if size != 0.

* io/unix.c (raw_tell): Revert r194694.

(raw_size): Return size field only for regular files, otherwise 0.



Modified:

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

branches/gcc-4_7-branch/libgfortran/io/open.c

branches/gcc-4_7-branch/libgfortran/io/unix.c

[Bug c++/56421] New: Non-matching overload produces template substitution error

[kristian.spangsege at gmail dot com]

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

 Bug #: 56421
   Summary: Non-matching overload produces template substitution
error
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kristian.spangs...@gmail.com


template struct Foo {
  typedef typename S::type type;
};

template void foo();
template typename Foo::type foo(int);

int main()
{
  foo();
}


Produces the following error in both gcc-4.7.2 and gcc-4.6.3:

$ g++ -c t.cpp
t.cpp: In instantiation of ‘struct Foo’:
t.cpp:6:41:   required by substitution of ‘template typename Foo::type
foo(int) [with S = int]’
t.cpp:10:12:   required from here
t.cpp:2:28: error: ‘int’ is not a class, struct, or union type


Clang accepts it as valid.


Note: No errors are reported by GCC if we change line 6 from

  template typename Foo::type foo(int);

to

  template typename S::type foo(int);

[Bug tree-optimization/56310] [4.8 Regression] ICE: in decide_about_value, at ipa-cp.c:3310 with -fipa-cp -fno-early-inlining -fipa-cp-clone --param=ipa-cp-eval-threshold=1

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 CC||jakub at gcc dot gnu.org

 Resolution||FIXED



--- Comment #6 from Jakub Jelinek  2013-02-21 
19:15:26 UTC ---

Fixed.

[Bug libfortran/30162] [4.7/4.8 Regression] Unformatted sequential I/O with named pipes does not work

[jb at gcc dot gnu.org]

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



--- Comment #52 from Janne Blomqvist  2013-02-21 
19:03:19 UTC ---

Author: jb

Date: Thu Feb 21 19:03:10 2013

New Revision: 196210



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

Log:

Fix regression when writing formatted sequential to a pipe.



2013-02-21  Janne Blomqvist  



PR libfortran/30162

* io/open.c (test_endfile): Call stell only if size != 0.

* io/unix.c (raw_tell): Revert r194679.

(raw_size): Return size field only for regular files, otherwise 0.



Modified:

trunk/libgfortran/ChangeLog

trunk/libgfortran/io/open.c

trunk/libgfortran/io/unix.c

[Bug c++/56268] [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant during assignment

[koraq at xs4all dot nl]

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



--- Comment #8 from koraq at xs4all dot nl 2013-02-21 18:56:06 UTC ---

I can confirm it is fixed in Debian Experimental 4.8-20130217-1. Thanks for the

fix.

[Bug middle-end/56420] [4.8 Regression] Arithmetic error in computation with compile time unsigned __int128 constant

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #2 from Jakub Jelinek  2013-02-21 
18:32:40 UTC ---

Created attachment 29519

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

gcc48-pr56420.patch



Untested fix.

[Bug middle-end/53884] [4.7/4.8 Regression] ICE: in function_and_variable_visibility, at ipa.c:818 with -flto -fno-weak

[hubicka at gcc dot gnu.org]

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



Jan Hubicka  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED



--- Comment #5 from Jan Hubicka  2013-02-21 
17:57:50 UTC ---

mine.

Not exception-safe default move constructors (demonstrated on std::pair)

[Dmitry Marakasov]

Hi!

I'm not really sure which (g++ or libstdc++) problem this really is, so
posting into both lists.

The problem is described here:
http://cpp-next.com/archive/2009/10/exceptionally-moving/

- You have two classes:
  A, which has a proper move constructor which doesn't throw
  B, which which only has copy constructor which may throw
- You have an std::pair
- You move a pair
  std::pair pair1;
  try {
std::pair pair2(std::move(a));
  }

What happens:
- A part is moved with move constructor. This is obviously destructive
  to pair1.
- B part is copied as it doesn't have move constuctor.
- Now, that copy constructor throws (which is pretty expectable is it
likely allocates resources). After this, as A part was already moved,
we're left with corrupted pair1 (with empty A part).

The same problem applies to most containers, but, for example, in
std::vector it is solved gracefully:

--- bits/vector.tcc from gcc-4.8:
  pointer __tmp = _M_allocate_and_copy(__n,
  _GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(this->_M_impl._M_start),
  _GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(this->_M_impl._M_finish));
---

so move semantics are only used IF the type has non-throwing(noexcept)
move constructor.

However, with pair this does not apply:

--- bits/stl_pair.h from gcc-4.8:
struct pair {
...
constexpr pair(pair&&) = default;
---

Either the default constructor generated by gcc is unsafe, or there
should be custom, safe move constuctor with corresponding enable_if.

I lean towards the former, as safe default move constuctors should be
always generated probably, and specific ones may be really hard to
implement for more complex types (tuples).

I've written a small program which demonstrates the problem:

https://gist.github.com/AMDmi3/5005557

tested it on FreeBSD with gcc-4.8 and on Debian with gcc-4.7, and it
showed problem on both.

Is this really a gcc problem? Should I file a bug?

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru  ..:  jabber: amd...@jabber.ruhttp://www.amdmi3.ru

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[sergio at serjux dot com]

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

--- Comment #13 from Sérgio Basto  2013-02-21 
17:45:53 UTC ---
Hi, it see that was applied on gcc-4.8.0-0.12 

Thanks,

[Bug go/56320] Several libgo tests FAIL on 64-bit Solaris/x86

[ro at CeBiTec dot Uni-Bielefeld.DE]

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



--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  2013-02-21 16:23:52 UTC ---

> --- Comment #2 from Ian Lance Taylor  2013-02-20 
> 19:46:42 UTC ---

> Should be fixed now, I hope.



Unfortunately, this is not enough.  I had the equivalent of your patch

in my tree when I noticed that I got different results for running the

tests via gotest and manually.  This got rid of the runtime_lfstackpush

error, but the failures remain.



panic: runtime error: invalid memory address or nil pointer dereference

[recovered]

panic: runtime error: invalid memory address or nil pointer dereference

[signal 0xb code=0x1 addr=0x105]



[...]



Running the os test under mdb reveals (in the child process):



mdb: fork1 detected: follow (p)arent or (c)hild? c

mdb: target forked child process 24260 (debugger following child)

mdb: stop on SIGSEGV

mdb: target stopped at:

libc.so.1`close+0x44:   addl   $0x1,(%rdx)

> $c

libc.so.1`close+0x44()

libgo.so.3.0.1`syscall.raw_fcntl.constprop.124+0x13()

libgo.so.3.0.1`syscall.forkExec+0x940()

libgo.so.3.0.1`syscall.StartProcess+0x2f()

os.StartProcess+0x20d()

os_test.exec+0x179()

os_test.TestStartProcess+0x101()

libgo.so.3.0.1`testing.$thunk10+0xd9()

libgo.so.3.0.1`kickoff+0x2e()

libc.so.1`resumecontext()

libgo.so.3.0.1`testing.RunTests+0x41e()

libgo.so.3.0.1`testing.Main+0x3ee()

main.main+0x7d()

libgo.so.3.0.1`runtime_main+0x6a()

libgo.so.3.0.1`kickoff+0x2e()

libc.so.1`resumecontext()

main+0x40()

_start+0x6c()



Under truss, I see this:



24271:  fcntl(4, F_DUP2FD, 0x0001)  = 1

24271:  Incurred fault #6, FLTBOUNDS  %pc = 0xFD7FEE350718

24271:siginfo: SIGSEGV SEGV_MAPERR addr=0xC20F9CFEA9

24271:  Received signal #11, SIGSEGV [caught]

24271:siginfo: SIGSEGV SEGV_MAPERR addr=0xC20F9CFEA9



I couldn't yet associate this SEGV with the exact source code location.

At least the net/http failure seems related: the test dies with SIGILL

in fcntl:



Program received signal SIGILL, Illegal instruction.

[Switching to Thread 15 (LWP 15)]

0xfd7fee350415 in fcntl () from /lib/64/libc.so.1

(gdb) where

#0  0xfd7fee350415 in fcntl () from /lib/64/libc.so.1

#1  0xfd7feeab085a in syscall.fcntl (fd=fd@entry=38, cmd=cmd@entry=2, 

arg=arg@entry=1) at libcalls.go:416



  fcntl (38, F_SETFD, FD_CLOEXEC);



#2  0xfd7feeabeb4e in syscall.CloseOnExec (fd=fd@entry=38)

at /vol/gcc/src/hg/trunk/local/libgo/go/syscall/exec_unix.go:130

#3  0xfd7feea7c984 in net.sysSocket (p=, t=2, f=2)

at /vol/gcc/src/hg/trunk/local/libgo/go/net/sys_cloexec.go:21

#4  net.socket (net=..., f=f@entry=2, t=t@entry=2, p=p@entry=0, 

ipv6only=ipv6only@entry=false, ulsa=ulsa@entry=..., ursa=ursa@entry=..., 

deadline=..., toAddr=toAddr@entry=0xfd7feea7a920 )

at /vol/gcc/src/hg/trunk/local/libgo/go/net/sock_posix.go:20

#5  0xfd7feea7d0ca in net.internetSocket (net=..., laddr=..., raddr=..., 

deadline=..., sotype=sotype@entry=2, proto=proto@entry=0, mode=..., 

toAddr=toAddr@entry=0xfd7feea7a920 )

at /vol/gcc/src/hg/trunk/local/libgo/go/net/ipsock_posix.go:146

#6  0xfd7feea7d28a in net.dialTCP (net=..., laddr=laddr@entry=0x0, 

raddr=raddr@entry=0xc2061630f0, deadline=...)

at /vol/gcc/src/hg/trunk/local/libgo/go/net/tcpsock_posix.go:153

#7  0xfd7feea7e051 in net.dialAddr (net=..., addr=..., addri=..., 

deadline=...) at /vol/gcc/src/hg/trunk/local/libgo/go/net/dial.go:99

#8  0xfd7feea82d52 in net.Dial (net=..., addr=...)

at /vol/gcc/src/hg/trunk/local/libgo/go/net/dial.go:93

#9  0x0044e3f1 in net_http.dial.pN18_net_http.Transport (

t=t@entry=0xc204c78540, network=..., addr=...) at transport.go:314

#10 0x0044e49c in net_http.getConn.pN18_net_http.Transport (

t=t@entry=0xc204c78540, cm=0xc206163090) at transport.go:326

#11 0x0044d944 in net_http.RoundTrip.pN18_net_http.Transport (

t=0xc204c78540, req=0xc206165000) at transport.go:160

#12 0x0043dd7c in http.send (t=..., req=0xc206165000) at client.go:162

#13 net_http.send.pN15_net_http.Client (c=c@entry=0xc2052a1f60, 

req=req@entry=0xc206165000) at client.go:96

#14 0x0043e262 in net_http.doFollowingRedirects.pN15_net_http.Client (

c=c@entry=0xc2052a1f60, ireq=0xc206165000, 

shouldRedirect=shouldRedirect@entry=0x43e080 )

at client.go:278

#15 0x0043e181 in net_http.Get.pN15_net_http.Client (c=0xc2052a1f60, 

url=...) at client.go:232

#16 0x0047fead in http_test.$nested112 () at transport_test.go:940

#17 0xfd7feea3fd2e in kickoff ()

at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:369

#18 0xfd7fee2d1460 in ?? () from /lib/64/libc.so.1

#19 0x0001 in ?? ()

#20 0x in ?? ()



Rainer

[Bug tree-optimization/56310] [4.8 Regression] ICE: in decide_about_value, at ipa-cp.c:3310 with -fipa-cp -fno-early-inlining -fipa-cp-clone --param=ipa-cp-eval-threshold=1

[jamborm at gcc dot gnu.org]

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



--- Comment #5 from Martin Jambor  2013-02-21 
16:08:58 UTC ---

Author: jamborm

Date: Thu Feb 21 16:08:51 2013

New Revision: 196207



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

Log:

2013-02-21  Martin Jambor  



PR tree-optimization/56310

* ipa-cp.c (agg_replacements_to_vector): New parameter index, copy

only matching indices and non-negative final offsets.

(intersect_aggregates_with_edge): Pass src_idx to

agg_replacements_to_vector.  Pass src_idx insstead of index to

intersect_with_agg_replacements.



testsuite/

* g++.dg/ipa/pr56310.C: New test.





Added:

trunk/gcc/testsuite/g++.dg/ipa/pr56310.C

Modified:

trunk/gcc/ChangeLog

trunk/gcc/ipa-cp.c

trunk/gcc/testsuite/ChangeLog

[Bug middle-end/56420] [4.8 Regression] Arithmetic error in computation with compile time unsigned __int128 constant

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-21

  Component|c++ |middle-end

 CC||jakub at gcc dot gnu.org

 Ever Confirmed|0   |1

Summary|Arithmetic error in |[4.8 Regression] Arithmetic

   |computation with compile|error in computation with

   |time unsigned __int128  |compile time unsigned

   |constant|__int128 constant

   Target Milestone|--- |4.8.0



--- Comment #1 from Jakub Jelinek  2013-02-21 
16:00:56 UTC ---

Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188786

I'll have a look.

[Bug middle-end/56417] internal compiler error: verify_gimple failed

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-02-21

  Component|c   |middle-end

 Ever Confirmed|0   |1

[Bug c++/56420] New: Arithmetic error in computation with compile time unsigned __int128 constant

[st at quanttec dot com]

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



 Bug #: 56420

   Summary: Arithmetic error in computation with compile time

unsigned __int128 constant

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: s...@quanttec.com





With GCC 4.8 (x86-64, snapshot 20130203 on Linux) the following simple test

case demonstrates an arithmetic bug for code involving a static unsigned

__int128 constant. This seems to be a regression from GCC 4.7.





#include 



typedef unsigned __int128 uint128_t;



static const uint128_t c = ((uint128_t)-1ULL << 64) + (1ULL << 63);



int main() {

// use volatile to prevent optimizer from optimizing the test

volatile uint128_t a = (uint128_t)1 << 127;

volatile uint128_t b = 1;



volatile uint128_t cc = c;



uint128_t result1 = a - b*c;

uint128_t result2 = a - b*cc;



if (result1 != result2) {

std::cout << "Error: results differ.\n";

return 1;

} else {

std::cout << "No error.\n";

return 0;

}

}

[Bug middle-end/53884] [4.7/4.8 Regression] ICE: in function_and_variable_visibility, at ipa.c:818 with -flto -fno-weak

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



   Target Milestone|4.7.3   |4.8.0

[Bug c++/56419] [4.8 regression] transactions in for-loops disappear

[jakub at gcc dot gnu.org]

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



--- Comment #2 from Jakub Jelinek  2013-02-21 
14:51:49 UTC ---

Broken by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186546

[Bug c++/56419] [4.8 regression] transactions in for-loops disappear

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



   Priority|P3  |P2

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-21

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

   |gnu.org |

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Aldy Hernandez  2013-02-21 
14:46:37 UTC ---

Confirmed.  Worked in 4.7.  Mine.

[Bug c++/56419] New: [4.8 regression] transactions in for-loops disappear

[torvald at gcc dot gnu.org]

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



 Bug #: 56419

   Summary: [4.8 regression] transactions in for-loops disappear

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: torv...@gcc.gnu.org

CC: al...@gcc.gnu.org, sp...@cse.lehigh.edu





Transaction statements in for-loops don't show up in Gimple.  For example:



int x = 0;

int inc_func(int i) {

 for (int j = 0; j < i; ++j)

 {

 __transaction_atomic { x+=1; }

 }

 return 0;

}



g++ -v -O0 test.cc -c -fgnu-tm -fdump-tree-all -Wall

leads to the following test.cc.004t.gimple:



int inc_func(int) (int i)

{

  int D.2360;



  {

int j;



j = 0;

goto ;

:

j = j + 1;

:

if (j < i) goto ; else goto ;

:

  }

  D.2360 = 0;

  return D.2360;

}



This does work when using the C frontend.  Seems to also work when the

transaction is in while loops or on an if-branch.  Doesn't seem to be sensitive

to which C++ standard is requested.



Originally reported by Mike Spear.  Mike says this works with 4.7.2, but

doesn't with g++ (GCC) 4.8.0 20130221 (experimental) (revision 

196192).  I've confirmed with an early-December build.

[Bug middle-end/55308] /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale"

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org,

   ||ro at gcc dot gnu.org



--- Comment #6 from Tobias Burnus  2013-02-21 
14:15:07 UTC ---

Comment 1 states:



> This appears to be due to r162478; in particular, gcc/configure.ac:3163 is
>  

>tls_as_opt="-32 --fatal-warnings", which may be correct for 
> Solaris,

> but is certainly wrong on freebsd portbld (where binutils does not support

> elf32-sparc-freebsd).



That's the following pretty old commit (4.6 trunk):



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



2010-07-23  Rainer Orth  



   * configure.ac: Don't disable TLS on Solaris 8/9 by default

   Set tga_func for Solaris 2/x86 resp. SPARC.

   Remove duplicate parts of sparc*-sun-solaris2.* TLS check.

   (LIB_THREAD_LDFLAGS_SPEC): Define.

   (LIB_TLS_SPEC): Define.

   ...

[Bug middle-end/53884] [4.7/4.8 Regression] ICE: in function_and_variable_visibility, at ipa.c:818 with -flto -fno-weak

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 CC||mpolacek at gcc dot gnu.org



--- Comment #4 from Marek Polacek  2013-02-21 
14:09:42 UTC ---

ISTM that we ICE here because we arrive at the assert at ipa.c:818 with:

 >

QI

size 

unit size 

align 8 symtab 0 alias set -1 canonical type 0x7f7dda50e690 method

basetype 

arg-types 

chain >>

pointer_to_this >

addressable used ignored weak decl_5 QI file zz.C line 3 col 3 align 8

initial 

arguments 

readonly unsigned DI

size 

unit size 

align 64 symtab 0 alias set -1 canonical type 0x7f7dda50e888>

readonly used unsigned DI file zz.C line 3 col 6 size  unit size 

align 64 context 

abstract_origin  arg-type >

full-name "void _ZN1SIL_Z3foovEEC1Ev()"



I think two things here are interesting: that decl is WEAK, even though we're

using -fno-weak, and that DECL_INITIAL of that decl is error_mark_node.  Not

sure what to do here: with the assert guarded by

  if (DECL_INITIAL (node->symbol.decl) != error_mark_node)

the ICE's gone and the final assembly looks ok.  

Is LTO misbehaving with -fno-weak, i.e., can it even produce a weak

FUNCTION_DECL like above?

[Bug tree-optimization/56175] [4.7/4.8 Regression] Issue with combine phase on x86.

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.7.3

Summary|Issue with combine phase on |[4.7/4.8 Regression] Issue

   |x86.|with combine phase on x86.

   Severity|enhancement |normal

[Bug tree-optimization/56175] Issue with combine phase on x86.

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 CC||rguenth at gcc dot gnu.org



--- Comment #12 from Richard Biener  2013-02-21 
13:44:09 UTC ---

For the real testcase I see



.L2:

shrw%ax

movl%edi, %edx

subb$1, %dl

movl%edx, %edi

je  .L9

.L4:

movl%ecx, %esi

movl%eax, %ebx

andl$1, %esi

andl$1, %ebx

shrb%cl

movl%esi, %edx

cmpb%bl, %dl

je  .L2



thus



andl$1, %esi

andl$1, %ebx

cmpb%bl, %dl



for



   t = (u8)((x & 1) ^ ((u8)y & 1));

   if (t == 1)



and with disabling the forwprop transformation:



.L2:

shrw%ax

subb$1, %dl

je  .L9

.L4:

movl%ecx, %ebx

shrb%cl

xorl%eax, %ebx

andl$1, %ebx

je  .L2



to confirm the issue again.  There is one less used register and the

zero-flag use by the conditional jump.



The following testcase is too simple to be not optimized anyway

at the RTL level but it may serve as a testcase for forwprop.



void bar (void);

unsigned short

foo (unsigned char x, unsigned short y)

{

  unsigned char t = (unsigned char)((x & 1) ^ ((unsigned char)y & 1));

  if (t == 1)

bar ();

  return y;

}

[Bug c++/56418] New: errors do not show the types (makes it hard to debug)

[msclrhd at gmail dot com]

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

 Bug #: 56418
   Summary:  errors do not show
the types (makes it hard to debug)
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mscl...@gmail.com


Created attachment 29518
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29518
Example of the problem.

When you have something like:

foo({ 1, 2, 3 });

vs:

foo(Bar(1, 2, 3));

the error message is hard to diagnose. See the attached foo.cpp for an example.

In the foo.cpp example, the lines that pass the wrong argument via explicit
construction ([5] and [7]) tell the user exactly what the problem is:

foo.cpp:12:21: note: candidates are:
foo.cpp:2:14: note: Foo::Foo(int, float, Bar)
foo.cpp:2:14: note:   no known conversion for argument 3 from ‘int’ to
‘Bar’

whereas the lines that pass the arguments using the initializer list syntax are
impossible to diagnose from the error message:

foo.cpp:18:21: error: invalid initialization of reference of type ‘const
Foo&’ from expression of type ‘’
foo.cpp:4:6: error: in passing argument 1 of ‘void foo(const Foo&)’

[Bug rtl-optimization/50339] [4.8 Regression] suboptimal register allocation for abs(__int128_t)

[jakub at gcc dot gnu.org]

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



--- Comment #4 from Jakub Jelinek  2013-02-21 
12:57:40 UTC ---

Created attachment 29517

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

gcc48-pr50339.patch



Patch that improves 4.8 generated code to one insn better than what 4.7 did, by

lowering ASHIFTRT similarly how lower-subreg lowers ASHIFT and LSHIFTRT

already.



On this testcase the difference is between unpatched trunk and patched trunk:

-movq%rdi, %r9

-movq%rsi, %rdi

-movq%rsi, %r10

-sarq$63, %rdi

-movq%rdi, %rcx

-xorq%r9, %rcx

-movq%rcx, %rax

-movq%r10, %rcx

-xorq%rdi, %rcx

-subq%rdi, %rax

-movq%rcx, %rdx

-sbbq%rdi, %rdx

+movq%rsi, %rax

+sarq$63, %rax

+movq%rax, %r9

+xorq%rax, %rdi

+xorq%r9, %rsi

+movq%rdi, %rax

+movq%rsi, %rdx

+subq%r9, %rax

+sbbq%r9, %rdx



i.e. 4 moves instead of former 7 (no idea why RA chooses to do this shift on

%rax (i.e. first move %rsi to %rax, then shift %rax, then move %rax to %r9),

instead of copying %rsi to %r9 and shifting %r9, that would mean one less

move).

Even smaller code would probably need different expansion or much smarter

register allocation.



Anyway, also tested:

__int128_t

f1 (__int128_t a)

{

  return a >> 67;

}



__int128_t

f2 (__int128_t a)

{

  return a >> 64;

}



__int128_t

f3 (__int128_t a)

{

  return a >> 127;

}



__uint128_t

f4 (__uint128_t a)

{

  return a >> 67;

}



__uint128_t

f5 (__uint128_t a)

{

  return a >> 64;

}



__uint128_t

f6 (__uint128_t a)

{

  return a >> 127;

}



on x86_64 and the difference at -O2 is:

-movq%rsi, %rax

 movq%rsi, %rdx

+movq%rsi, %rax

 sarq$63, %rdx

 sarq$3, %rax

for f1,

-movq%rsi, %rdx

 movq%rsi, %rax

-sarq$63, %rdx

+cqto

for f2 and

+sarq$63, %rsi

 movq%rsi, %rdx

-sarq$63, %rdx

-movq%rdx, %rax

+movq%rsi, %rax

for f3, so either no pessimization, or small improvement.  On:

long long int

f1 (long long int a)

{

  return a >> 35;

}



long long int

f2 (long long int a)

{

  return a >> 32;

}



long long int

f3 (long long int a)

{

  return a >> 63;

}



unsigned long long int

f4 (unsigned long long int a)

{

  return a >> 35;

}



unsigned long long int

f5 (unsigned long long int a)

{

  return a >> 32;

}



unsigned long long int

f6 (unsigned long long int a)

{

  return a >> 63;

}



for -O2 -m32 the improvements are even better, for f1:

-movl8(%esp), %edx

-movl%edx, %eax

-movl%eax, %edx

-sarl$31, %edx

+movl8(%esp), %eax

+cltd

 sarl$3, %eax

and for f2:

-movl8(%esp), %edx

-movl%edx, %eax

-movl%eax, %edx

-sarl$31, %edx

+movl8(%esp), %eax

+cltd

(no difference for f3).

[Bug pending/55996] [meta-bug] GCC 4.9 pending patches

[steven at gcc dot gnu.org]

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



--- Comment #4 from Steven Bosscher  2013-02-21 
12:36:46 UTC ---

Patch to make DF-scan dumps cleaner and speed up complete re-scanning

and deferred rescanning:



http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00961.html

[Bug fortran/56385] [4.6/4.7/4.8 Regression] [OOP] ICE with allocatable function result in a procedure-pointer component

[janus at gcc dot gnu.org]

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



--- Comment #4 from janus at gcc dot gnu.org 2013-02-21 12:26:54 UTC ---

Author: janus

Date: Thu Feb 21 12:26:44 2013

New Revision: 196202



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

Log:

2013-02-21  Janus Weil  



PR fortran/56385

* trans-array.c (structure_alloc_comps): Handle procedure-pointer

components with allocatable result.



2013-02-21  Janus Weil  



PR fortran/56385

* gfortran.dg/proc_ptr_comp_37.f90: New.



Added:

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

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/trans-array.c

trunk/gcc/testsuite/ChangeLog

[Bug fortran/56416] texinfo 5: Many warnings for gfortran's *.texi

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||burnus at gcc dot gnu.org

 Resolution||FIXED



--- Comment #2 from Tobias Burnus  2013-02-21 
12:10:50 UTC ---

FIXED on the 4.8 trunk. (Only warnings - contrary to PR 56258; hence, I do not

intent to backport it.)

[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects

[eugeni.stepanov at gmail dot com]

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



--- Comment #16 from Evgeniy Stepanov  
2013-02-21 11:51:17 UTC ---

(In reply to comment #14)

> (In reply to comment #13)

> > We've got this problem on Android, where an instrumented JNI library is 
> > loaded

> > into Dalvik VM, which is outside of user control. We "solve" it by requiring

> > that the runtime library is LD_PRELOAD-ed into the DVM (Android has a 
> > mechanism

> > to do this on an individual app basis on rooted devices).

> 

> OT, but what is this mechanism you speak of?  Currently this bug is the top

> google hit for "Dalvik sanitizer LD_PRELOAD", and I don't see how it might 
> work

> if the VM only forks, not execs.



https://android.googlesource.com/platform/frameworks/base/+/master/core/java/com/android/internal/os/ZygoteConnection.java



See the code for applyInvokeWithSystemProperty().



Also, https://code.google.com/p/address-sanitizer/wiki/Android.

Sorry, this page was outdated until just now.

[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects

[kcc at gcc dot gnu.org]

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



--- Comment #15 from Kostya Serebryany  2013-02-21 
11:35:51 UTC ---

r196201 landed the fresh asan run-time into gcc.

-static-libasan should work well now, please try.

[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects

[amonakov at gcc dot gnu.org]

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



Alexander Monakov  changed:



   What|Removed |Added



 CC||amonakov at gcc dot gnu.org



--- Comment #14 from Alexander Monakov  2013-02-21 
10:54:13 UTC ---

(In reply to comment #13)

> We've got this problem on Android, where an instrumented JNI library is loaded

> into Dalvik VM, which is outside of user control. We "solve" it by requiring

> that the runtime library is LD_PRELOAD-ed into the DVM (Android has a 
> mechanism

> to do this on an individual app basis on rooted devices).



OT, but what is this mechanism you speak of?  Currently this bug is the top

google hit for "Dalvik sanitizer LD_PRELOAD", and I don't see how it might work

if the VM only forks, not execs.

[Bug tree-optimization/56273] [4.8 regression] Bogus -Warray-bounds warning

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|RESOLVED|ASSIGNED

Version|unknown |4.8.0

 Resolution|FIXED   |



--- Comment #12 from Richard Biener  2013-02-21 
10:54:02 UTC ---

Re-open, patch has been reverted.

[Bug bootstrap/53731] [4.7] Bootstrap fails for libgfortran on Solaris 10 x86 with error "Where has __float128 gone?"

[windward at gmx dot com]

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



Martin  changed:



   What|Removed |Added



Version|4.7.1   |4.7.2



--- Comment #2 from Martin  2013-02-21 10:53:07 UTC ---

Ping?

Bug still exists in 4.7.2, workaround stays the same:



--- gcc-4.7.2_unpatched/Makefile.tpl2012-08-06 16:34:27.0 +0200

+++ gcc-4.7.2_patched/Makefile.tpl  2013-02-21 12:11:44.817759549 +0100

@@ -555,7 +555,7 @@ HOST_LIB_PATH = [+ FOR host_modules +][+



 # Define HOST_LIB_PATH_gcc here, for the sake of TARGET_LIB_PATH, ouch

 @if gcc

-HOST_LIB_PATH_gcc =

$$r/$(HOST_SUBDIR)/gcc$(GCC_SHLIB_SUBDIR):$$r/$(HOST_SUBDIR)/prev-gcc$(GCC_SHLIB_SUBDIR):

+HOST_LIB_PATH_gcc =

$$r/$(HOST_SUBDIR)/gcc$(MULTISUBDIR)$(GCC_SHLIB_SUBDIR):$$r/$(HOST_SUBDIR)/prev-gcc$(MULTISUBDIR)$(GCC_SHLIB_SUBDIR):

 @endif gcc



 [+ FOR host_modules +][+ IF lib_path +]





--- gcc-4.7.2_unpatched/Makefile.in 2012-08-06 16:34:27.0 +0200

+++ gcc-4.7.2_patched/Makefile.in   2013-02-21 12:11:44.817793304 +0100

@@ -629,7 +629,7 @@ HOST_LIB_PATH = $(HOST_LIB_PATH_bfd)$(HO



 # Define HOST_LIB_PATH_gcc here, for the sake of TARGET_LIB_PATH, ouch

 @if gcc

-HOST_LIB_PATH_gcc =

$$r/$(HOST_SUBDIR)/gcc$(GCC_SHLIB_SUBDIR):$$r/$(HOST_SUBDIR)/prev-gcc$(GCC_SHLIB_SUBDIR):

+HOST_LIB_PATH_gcc =

$$r/$(HOST_SUBDIR)/gcc$(MULTISUBDIR)$(GCC_SHLIB_SUBDIR):$$r/$(HOST_SUBDIR)/prev-gcc$(MULTISUBDIR)$(GCC_SHLIB_SUBDIR):

 @endif gcc

[Bug tree-optimization/56415] [4.8 Regression] Performance regression after fix for 56273

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #6 from Richard Biener  2013-02-21 
10:53:00 UTC ---

Fixed.

[Bug tree-optimization/56415] [4.8 Regression] Performance regression after fix for 56273

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Biener  2013-02-21 
10:52:44 UTC ---

Author: rguenth

Date: Thu Feb 21 10:52:39 2013

New Revision: 196200



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

Log:

2013-02-21  Richard Biener  



PR tree-optimization/56415

Revert

2013-02-11  Richard Biener  



PR tree-optimization/56273

* tree-vrp.c (simplify_cond_using_ranges): Disable for the

first VRP run.



* g++.dg/warn/Warray-bounds-6.C: New testcase.

* gcc.dg/tree-ssa/pr21559.c: Adjust.

* gcc.dg/tree-ssa/vrp17.c: Likewise.

* gcc.dg/tree-ssa/vrp18.c: Likewise.

* gcc.dg/tree-ssa/vrp23.c: Likewise.

* gcc.dg/tree-ssa/vrp24.c: Likewise.



Removed:

trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-6.C

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/gcc.dg/tree-ssa/pr21559.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp17.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp18.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp23.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp24.c

trunk/gcc/tree-vrp.c

[Bug tree-optimization/56273] [4.8 regression] Bogus -Warray-bounds warning

[rguenth at gcc dot gnu.org]

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



--- Comment #11 from Richard Biener  2013-02-21 
10:52:44 UTC ---

Author: rguenth

Date: Thu Feb 21 10:52:39 2013

New Revision: 196200



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

Log:

2013-02-21  Richard Biener  



PR tree-optimization/56415

Revert

2013-02-11  Richard Biener  



PR tree-optimization/56273

* tree-vrp.c (simplify_cond_using_ranges): Disable for the

first VRP run.



* g++.dg/warn/Warray-bounds-6.C: New testcase.

* gcc.dg/tree-ssa/pr21559.c: Adjust.

* gcc.dg/tree-ssa/vrp17.c: Likewise.

* gcc.dg/tree-ssa/vrp18.c: Likewise.

* gcc.dg/tree-ssa/vrp23.c: Likewise.

* gcc.dg/tree-ssa/vrp24.c: Likewise.



Removed:

trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-6.C

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/gcc.dg/tree-ssa/pr21559.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp17.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp18.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp23.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp24.c

trunk/gcc/tree-vrp.c

[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled but supported by as (Solaris & Linux)

[windward at gmx dot com]

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



Martin  changed:



   What|Removed |Added



Version|4.7.0   |4.7.2



--- Comment #7 from Martin  2013-02-21 10:49:25 UTC ---

Ping?

Bug still exists in 4.7.2, just tested on Solaris 10 and Linux (CentOS 5.5)

[Bug tree-optimization/56415] [4.8 Regression] Performance regression after fix for 56273

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0

Summary|Performance regression  |[4.8 Regression]

   |after fix for 56273 |Performance regression

   ||after fix for 56273



--- Comment #4 from Richard Biener  2013-02-21 
10:44:38 UTC ---

Ok, the fact is that with changes like



@@ -917,7 +839,7 @@

   _201 = *_111[_200];

   t[6] = _201;

   _206 = _108;

-  if (_108 == 8)

+  if (_108 > 7)

 goto ;



@@ -906,7 +828,7 @@

   _187 = *_111[_186];

   t[5] = _187;

   _192 = _108;

-  if (_108 != 6)

+  if (_108 > 6)

 goto ;

   else

 goto ;



we weaken range information on one code-path but improve it on another.

We should be still able to figure out the original ranges though, so

this change probably only papered over the other PR.



I'll revert that change.

[Bug middle-end/56242] [4.8 Regression] libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:175:0: ICE: Segmentation fault

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 Depends on||56131



--- Comment #12 from Steven Bosscher  2013-02-21 
10:33:11 UTC ---

(In reply to comment #2)

> I'd say if NOTE_INSN_BASIC_BLOCK has NULL BLOCK_FOR_INSN, rather than 

> trying to use NOTE_BASIC_BLOCK the code should just assume cfg has been 

> freed and can't be used.



Right. I just added the same comment to bug 56131 and re-opened it.  This

bug 56242 is just collateral from the incorrect fix for bug 56131.

[Bug middle-end/56242] [4.8 Regression] libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:175:0: ICE: Segmentation fault

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 CC||steven at gcc dot gnu.org



--- Comment #11 from Steven Bosscher  2013-02-21 
10:31:03 UTC ---

(In reply to comment #3)



> Index: cfgrtl.c

> ===

> --- cfgrtl.c (revision 195874)

> +++ cfgrtl.c (working copy)

> @@ -119,6 +119,28 @@ can_delete_label_p (const_rtx label)

>&& !in_expr_list_p (forced_labels, label));

>  }

> 

> +static void

> +update_next_prev_in_sequence (const_rtx insn)



This wouldn't belong in cfgrtl.c but in emit-rtl.c.

[Bug rtl-optimization/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 Status|RESOLVED|REOPENED

 CC||steven at gcc dot gnu.org

 Resolution|FIXED   |



--- Comment #13 from Steven Bosscher  2013-02-21 
10:29:25 UTC ---

The fix for this PR is wrong.



Nothing even trying to look at the CFG after freeing it, so the looks at

BLOCK_FOR_INSN in delete_insn are non-sense. Looking for the basic block

anywhere at all at this point makes no sense, basic block contents and

boundaries are not maintained and may be scrambled enough to make even

the basic block notes unreliable.



Also, "If the label is not marked with a bb, assume it's the same bb"

is wrong if the label is a marker for a constant pool or a jump table.

[Bug tree-optimization/56398] [4.8 Regression] ICE (Segmentation fault) in dominated_by_p

[mpolacek at gcc dot gnu.org]

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



--- Comment #9 from Marek Polacek  2013-02-21 
10:28:57 UTC ---

Author: mpolacek

Date: Thu Feb 21 10:21:19 2013

New Revision: 196199



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

Log:

New test for PR56398.



Added:

trunk/gcc/testsuite/g++.dg/torture/pr56398.C

Modified:

trunk/gcc/testsuite/ChangeLog

[Bug inline-asm/56405] [4.8 Regression] ICE on questionable "m" argument

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #3 from Jakub Jelinek  2013-02-21 
10:18:14 UTC ---

Fixed.

[Bug c/56417] internal compiler error: verify_gimple failed

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #1 from Jakub Jelinek  2013-02-21 
10:06:59 UTC ---

Without the preprocessed source this bugreport is useless, please see

http://gcc.gnu.org/bugs.html for instructions.

[Bug c/56417] New: internal compiler error: verify_gimple failed

[roel at vandepaar dot com]

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



 Bug #: 56417

   Summary: internal compiler error: verify_gimple failed

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: r...@vandepaar.com





I was trying to compile Percona Server with gcc 4.8 with ASan (trunk build) and

ran into this during the build-binary.sh script supplied with Percona Server:



===

[  7%] Building C object

cmd-line-utils/readline/CMakeFiles/readline.dir/readline.c.o

cd /percona-server/5.5/Percona-Server-5.5.28-rel29.3/cmd-line-utils/readline &&

/usr/local/bin/gcc  -DHAVE_RESPONSE_TIME_DISTRIBUTION -DHAVE_CONFIG_H

-DHAVE_CONFIG_H -DNO_KILL_INTR -fsanitize=address -fno-omit-frame-pointer -fPIC

-Wall -O3 -g -static-libgcc -fno-omit-frame-pointer

-DPERCONA_INNODB_VERSION=rel29.3-fPIC -Wall -O -g -static-libgcc

-fno-omit-frame-pointer -fno-strict-aliasing -DENABLED_DEBUG_SYNC

-I/percona-server/5.5/Percona-Server-5.5.28-rel29.3/include

-I/percona-server/5.5/Percona-Server-5.5.28-rel29.3/cmd-line-utils-o

CMakeFiles/readline.dir/readline.c.o   -c

/percona-server/5.5/Percona-Server-5.5.28-rel29.3/cmd-line-utils/readline/readline.c/percona-server/5.5/Percona-Server-5.5.28-rel29.3/cmd-line-utils/readline/readline.c:

In function '_rl_dispatch_subseq':

/percona-server/5.5/Percona-Server-5.5.28-rel29.3/cmd-line-utils/readline/readline.c:690:1:

error: type mismatch in pointer plus expression

 _rl_dispatch_subseq (key, map, got_subseq)

 ^

int (*) (int, int)



char *



long unsigned int



_309 = _298 + _120;



/percona-server/5.5/Percona-Server-5.5.28-rel29.3/cmd-line-utils/readline/readline.c:690:1:

internal compiler error: verify_gimple failed

0x903f9c verify_gimple_in_cfg(function*)

../.././gcc/tree-cfg.c:4727

0x83e7b7 execute_function_todo

../.././gcc/passes.c:1970

0x83f0d7 execute_todo

../.././gcc/passes.c:1999

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.

make[2]: *** [cmd-line-utils/readline/CMakeFiles/readline.dir/readline.c.o]

Error 1

make[2]: Leaving directory `/percona-server/5.5/Percona-Server'

make[1]: *** [cmd-line-utils/readline/CMakeFiles/readline.dir/all] Error 2

make[1]: Leaving directory `/percona-server/5.5/Percona-Server'

make: *** [all] Error 2

===



I realize there is seemingly an issue in the code, but it is interesting to see

the "internal compiler error: verify_gimple failed".



I tried making a reduced testcase, but ran into issues there so decided to just

log this bug as-is as a FYI.



Note that Percona Server compiles with gcc 4.7.2



To repeat, you may be able to do something like this:



$ bzr branch -rjenk...@jenkins.percona.com-20130220064132-vewblweu0emq39np

lp:percona-server/5.5

$ cd 5.5

$ gcc --version | grep GCC ; /usr/local/bin/gcc --version

gcc (GCC) 4.8.0 20130218 (experimental)

gcc (GCC) 4.8.0 20130218 (experimental)

$ export LD_LIBRARY_PATH=/usr/local/lib  # messy libraries

$ chmod +x ./build/build-binary.sh

$ ./build/build-binary.sh [--debug] .# try with/without --debug



other version info: gmp: 5.1.1, mpfr: 3.1.1, mpc: 1.0, flex: 2.5.37



$ uname -a   # Fedora Core x64

Linux  3.6.10-2.fc17.x86_64 #1 SMP Tue Dec 11 18:07:34 UTC 2012

x86_64 x86_64 x86_64 GNU/Linux



See bug 49731 and bug 50363 for more "internal compiler error: verify_gimple

failed"

[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)

[jakub at gcc dot gnu.org]

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



--- Comment #6 from Jakub Jelinek  2013-02-21 
09:56:07 UTC ---

Author: jakub

Date: Thu Feb 21 09:56:01 2013

New Revision: 196198



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

Log:

PR bootstrap/56258

* doc/invoke.texi (-fdump-rtl-pro_and_epilogue): Use @item

instead of @itemx.



* gnat-style.texi (@title): Remove @hfill.

* projects.texi: Avoid line wrapping inside of @pxref or

@xref.



* doc/cp-tools.texinfo (Virtual Machine Options): Use just

one @gccoptlist instead of 3 separate ones.



Modified:

branches/gcc-4_6-branch/gcc/ChangeLog

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

branches/gcc-4_6-branch/gcc/ada/gnat-style.texi

branches/gcc-4_6-branch/gcc/ada/projects.texi

branches/gcc-4_6-branch/gcc/doc/invoke.texi

branches/gcc-4_6-branch/libjava/classpath/ChangeLog.gcj

branches/gcc-4_6-branch/libjava/classpath/doc/cp-tools.texinfo

[Bug libstdc++/56414] C++11 atomic are not always atomic on load and store depending on the command line on x86-64

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #3 from Richard Biener  2013-02-21 
09:46:16 UTC ---

Well, what did you expect ...

[Bug tree-optimization/56415] Performance regression after fix for 56273

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-02-21

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #3 from Richard Biener  2013-02-21 
09:45:46 UTC ---

I will have a look.

[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2013-02-21 
09:43:00 UTC ---

Author: jakub

Date: Thu Feb 21 09:42:39 2013

New Revision: 196197



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

Log:

PR bootstrap/56258

* doc/invoke.texi (-fdump-rtl-pro_and_epilogue): Use @item

instead of @itemx.



* gnat-style.texi (@title): Remove @hfill.

* projects.texi: Avoid line wrapping inside of @pxref or

@xref.



* doc/cp-tools.texinfo (Virtual Machine Options): Use just

one @gccoptlist instead of 3 separate ones.



Modified:

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

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

branches/gcc-4_7-branch/gcc/ada/gnat-style.texi

branches/gcc-4_7-branch/gcc/ada/projects.texi

branches/gcc-4_7-branch/gcc/doc/invoke.texi

branches/gcc-4_7-branch/libjava/classpath/ChangeLog.gcj

branches/gcc-4_7-branch/libjava/classpath/doc/cp-tools.texinfo

[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)

[jakub at gcc dot gnu.org]

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



--- Comment #4 from Jakub Jelinek  2013-02-21 
09:41:05 UTC ---

Author: jakub

Date: Thu Feb 21 09:40:44 2013

New Revision: 196196



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

Log:

PR bootstrap/56258

* doc/invoke.texi (-fdump-rtl-pro_and_epilogue): Use @item

instead of @itemx.



* gnat-style.texi (@title): Remove @hfill.

* projects.texi: Avoid line wrapping inside of @pxref or

@xref.



* doc/cp-tools.texinfo (Virtual Machine Options): Use just

one @gccoptlist instead of 3 separate ones.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/ada/ChangeLog

trunk/gcc/ada/gnat-style.texi

trunk/gcc/ada/projects.texi

trunk/gcc/doc/invoke.texi

trunk/libjava/classpath/ChangeLog.gcj

trunk/libjava/classpath/doc/cp-tools.texinfo

[Bug inline-asm/56405] [4.8 Regression] ICE on questionable "m" argument

[jakub at gcc dot gnu.org]

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



--- Comment #2 from Jakub Jelinek  2013-02-21 
09:33:54 UTC ---

Author: jakub

Date: Thu Feb 21 09:33:49 2013

New Revision: 196195



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

Log:

PR inline-asm/56405

* expr.c (expand_expr_real_1) : Don't

use movmisalign or extract_bit_field for EXPAND_MEMORY modifier.



* gcc.c-torture/compile/pr56405.c: New test.



Added:

trunk/gcc/testsuite/gcc.c-torture/compile/pr56405.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/expr.c

trunk/gcc/testsuite/ChangeLog

[Bug fortran/56416] texinfo 5: Many warnings for gfortran's *.texi

[burnus at gcc dot gnu.org]

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



--- Comment #1 from Tobias Burnus  2013-02-21 
09:23:38 UTC ---

Author: burnus

Date: Thu Feb 21 09:23:31 2013

New Revision: 196194



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

Log:

2012-02-21  Tobias Burnus  



PR fortran/56416

* gfortran.texi (Part II: Language Reference, Extensions,

Non-Fortran Main Program): Sort @menu to match actual section order.

* intrinsic.texi (Intrinsic Procedures): Ditto.

(C_F_POINTER, PRECISION): Move to the alphabetically correct place.





Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/gfortran.texi

trunk/gcc/fortran/intrinsic.texi

[Bug tree-optimization/56415] Performance regression after fix for 56273

[ysrumyan at gmail dot com]

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



--- Comment #2 from Yuri Rumyantsev  2013-02-21 
09:11:21 UTC ---

This bug was introduced by the following fix:



r195940 is guilty:



Author: rguenth

Date: Mon Feb 11 13:33:19 2013

New Revision: 195940



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

Log:

2013-02-11 Richard Biener 

PR tree-optimization/56273

   * tree-vrp.c (simplify_cond_using_ranges): Disable for thefirst VRP run.

   (check_array_ref): Fix missing newline in dumps.(search_for_addr_array):

Likewise.

[Bug fortran/56416] New: texinfo 5: Many warnings for gfortran's *.texi

[burnus at gcc dot gnu.org]

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



 Bug #: 56416

   Summary: texinfo 5: Many warnings for gfortran's *.texi

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: documentation

  Severity: normal

  Priority: P3

 Component: fortran

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

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





Created attachment 29516

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

texinfo.log



Texinfo 5.0 shows 43 warnings for gfortran's *.texi files, see attachment.



(That's with "make info", "make pdf" seems to have no warnings; I haven't tried

"make html", yet.)

[Bug tree-optimization/56415] Performance regression after fix for 56273

[ysrumyan at gmail dot com]

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



--- Comment #1 from Yuri Rumyantsev  2013-02-21 
08:59:33 UTC ---

Created attachment 29515

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

testcase



Test must be compiled with "-O3 -funroll-loops" options.

[Bug tree-optimization/56398] [4.8 Regression] ICE (Segmentation fault) in dominated_by_p

[rguenther at suse dot de]

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



--- Comment #8 from rguenther at suse dot de  
2013-02-21 08:58:11 UTC ---

On Wed, 20 Feb 2013, mpolacek at gcc dot gnu.org wrote:



> 

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

> 

> --- Comment #7 from Marek Polacek  2013-02-20 
> 15:33:52 UTC ---

> Reduced.  Should I add the testcase to into testsuite?



Yes, that would be nice.



Thanks,

Richard.



> namespace

> {

> #0 "/usr/include/c/4.8/bits/postypes.h" 3

> }

> 

> vtkpow (int b)

> {

>   int a1;

>   int b1;

>   int c;

>   while (b1)

> {

>   while (b)

> b1 = 0;

>   b1 = b1 - 1;

>   c = c * a1;

> }

>   return c;

> }

[Bug tree-optimization/56415] New: Performance regression after fix for 56273

[ysrumyan at gmail dot com]

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



 Bug #: 56415

   Summary: Performance regression after fix for 56273

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: ysrum...@gmail.com





In process of testing x86 platforms we found out that the fix for 56273 caused

-30% regression for one important benchmark. This regression can be

illustraated by attache test (it must be compiled with "-O3 -funroll-loops"

options:



before fix 

time ./t_before.exe 

19



real0m4.324s

user0m4.262s

sys 0m0.000s



after fix

time ./t_after.exe 

19



real0m10.530s

user0m10.400s

sys 0m0.000s



Note that for 32-bit mode timing is worse.



Test is attached.

[Bug middle-end/56362] bitfield refs over-optimized?

[jay.krell at cornell dot edu]

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



--- Comment #2 from Jay  2013-02-21 08:07:15 UTC 
---

Looking back at other data I have..this has something to do with configure

-enable-checking..but I don't know exactly what.



I am *guessing* that the signedness of the bitfield ref and the signedess of

the element could vary. Stripping of the bitfield ref would therefore change

the type of the expression, and that could then be sign extended.



I doubt I can construct a repro in C, but I can poke around to see if C or Java

or Ada can produce such bitfield refs..