[Bug web/55237] New: Please implement gcc.gnu.org/r123456 URL shorts for fast SVN revision access

[Bug web/55237] New: Please implement gcc.gnu.org/r123456 URL shorts for fast SVN revision access

[ubizjak at gmail dot com]

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

             Bug #: 55237
           Summary: Please implement gcc.gnu.org/r123456 URL shorts for
                    fast SVN revision access
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: web
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ubizjak@gmail.com


I would like to propose a scheme of short URLs for fast SVN revision access,
similar to the short URLs for fast PR access:

gcc.gnu.org/PR12345
(existing, very useful to reference/link to the particular PR)

Proposed:

gcc.gnu.org/r123456

in effect a short ULR for
http://gcc.gnu.org/viewcvs?view=revision&revision=123456

This shortcuts could be a nice way to add references to a correspondence on the
mainling lists, and can eventuall be used to insert automatic links to a
particular revision from bugzilla (again, similar to existing PR12345
processing).

[Bug web/55237] Please implement gcc.gnu.org/r123456 URL shorts for fast SVN revision access

[steven at gcc dot gnu.org]

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

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-11-08
                 CC|                            |gerald at gcc dot gnu.org,
                   |                            |steven at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #1 from Steven Bosscher <steven at gcc dot gnu.org> 2012-11-08 22:00:50 UTC ---
Good idea!

[Bug web/55237] Please implement gcc.gnu.org/r123456 URL shorts for fast SVN revision access

[gerald at pfeifer dot com]

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

Gerald Pfeifer <gerald at pfeifer dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |gerald at pfeifer dot com
         AssignedTo|unassigned at gcc dot       |gerald at pfeifer dot com
                   |gnu.org                     |

--- Comment #2 from Gerald Pfeifer <gerald at pfeifer dot com> 2012-11-11 08:31:57 UTC ---
I'll look into it.

[Bug web/55237] Please implement gcc.gnu.org/r123456 URL shorts for fast SVN revision access

[ubizjak at gmail dot com]

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

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |LpSolit at netscape dot net

--- Comment #3 from Uros Bizjak <ubizjak at gmail dot com> 2013-01-21 12:51:27 UTC ---
This is now implemented and works really well. Probably we should teach GCC
Bugzilla to insert automatic links for r123456 as in case of PR12345. CC added.

[Bug web/55237] Please implement gcc.gnu.org/r123456 URL shorts for fast SVN revision access

[LpSolit at netscape dot net]

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

--- Comment #4 from Frédéric Buclin <LpSolit at netscape dot net> 2013-01-21 22:34:37 UTC ---
Gerald, I see that you assigned the bug to you. How do you plan to fix it?

[Bug web/55237] Please implement gcc.gnu.org/r123456 URL shorts for fast SVN revision access

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-01-21 23:03:01 UTC ---
He did the URL redirect part already:
http://gcc.gnu.org/ml/gcc/2012-12/msg00181.html

[Bug web/55237] Please implement gcc.gnu.org/r123456 URL shorts for fast SVN revision access

[LpSolit at netscape dot net]

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

--- Comment #6 from Frédéric Buclin <LpSolit at netscape dot net> 2013-01-22 21:24:25 UTC ---
It would be simpler to simply type r1234 in Bugzilla instead of
http://gcc.gnu.org/r1234 and have it linkified to point to
http://gcc.gnu.org/viewcvs?view=revision&revision=1234. Is that what you
wanted? If not, then I have nothing to do about this bug.

[Bug web/55237] Please implement gcc.gnu.org/r123456 URL shorts for fast SVN revision access

[ubizjak at gmail dot com]

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

--- Comment #7 from Uros Bizjak <ubizjak at gmail dot com> 2013-01-22 21:27:59 UTC ---
(In reply to comment #6)
> It would be simpler to simply type r1234 in Bugzilla instead of
> http://gcc.gnu.org/r1234 and have it linkified to point to
> http://gcc.gnu.org/viewcvs?view=revision&revision=1234. Is that what you
> wanted? If not, then I have nothing to do about this bug.

Yes, linkifying r123456 is what I have in mind. Actually, the same as PR12345
does for links to Bugzilla.

[Bug web/55237] Please implement gcc.gnu.org/r123456 URL shorts for fast SVN revision access

[LpSolit at netscape dot net]

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

Frédéric Buclin <LpSolit at netscape dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|gerald at pfeifer dot com   |LpSolit at netscape dot net

--- Comment #8 from Frédéric Buclin <LpSolit at netscape dot net> 2013-04-18 16:29:40 UTC ---
OK, will do it.
>From gcc-bugs-return-420545-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 18 16:29:55 2013
Return-Path: <gcc-bugs-return-420545-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9629 invoked by alias); 18 Apr 2013 16:29:54 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9592 invoked by uid 48); 18 Apr 2013 16:29:52 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/56999] [4.8/4.9 Regression] LRA caused miscompilation of xulrunner
Date: Thu, 18 Apr 2013 16:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56999-4-rjSLzNXUJK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56999-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56999-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01690.txt.bz2
Content-length: 238


http://gcc.gnu.org/bugzilla/show_bug.cgi?idV999

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-18 16:29:52 UTC ---
Created attachment 29896
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id)896
jsi.ii

[Bug web/55237] Linkify r123456 in comments to point to SVN

[steven at gcc dot gnu.org]

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

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://gcc.gnu.org/viewcvs/ |http://gcc.gnu.org/viewcvs/
                   |gcc?view=revision&revision= |gcc?view=revision&revision=
                   |1234                        |123456

--- Comment #10 from Steven Bosscher <steven at gcc dot gnu.org> ---
Is it a good idea to only linkify references for r[0-9]{3,} so that
register names are not linkified? E.g. in bug 56833 all register names
like r26, r31, etc. are turned into SVN revision links (and probably in
this bug report now, too :-)

[Bug web/55237] Linkify r123456 in comments to point to SVN

[LpSolit at netscape dot net]

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

--- Comment #11 from Frédéric Buclin <LpSolit at netscape dot net> ---
What's the max value of a register name? r31?
>From gcc-bugs-return-422314-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 15 10:42:49 2013
Return-Path: <gcc-bugs-return-422314-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5900 invoked by alias); 15 May 2013 10:42:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 5870 invoked by uid 48); 15 May 2013 10:42:46 -0000
From: "ebotcazou at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/57281] [4.9 Regression] x86_64-linux loop fails to terminate at -O3 -m32
Date: Wed, 15 May 2013 10:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ebotcazou at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-57281-4-ePuLiPBVJr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57281-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57281-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-05/txt/msg00987.txt.bz2
Content-length: 1040

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW281

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #5 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> postreload leaves a REG_DEAD note on the
>
> (insn 19 78 21 4 (parallel [
>             (set (mem:DI (reg/f:SI 3 bx [orig:68 D.1736 ] [68]) [4 *_18+0 S8
> A64])
>                 (sign_extend:DI (reg:SI 0 ax [orig:75 b ] [75])))
>             (clobber (reg:CC 17 flags))
>             (clobber (reg:SI 1 dx [80]))
>         ]) t.c:9 137 {extendsidi2_1}
>      (expr_list:REG_UNUSED (reg:SI 1 dx [80])
>         (expr_list:REG_DEAD (reg:SI 0 ax [orig:75 b ] [75])
>             (nil))))
>
> which is bogus.

Leaving REG_DEAD/REG_UNUSED notes at the end of a pass is OK, it's up to the
next pass using them to make sure they are valid by invoking DF.

[Bug web/55237] Linkify r123456 in comments to point to SVN

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think ia64 uses registers up to r127.
As http://gcc.gnu.org/r999 is from mid 1992, it is very unlikely too many
bugzilla comments would like to refer to those commits and can use the URL
syntax in that case, so I think just linkifying only r followed by 4+ digits
would be best.

[Bug web/55237] Linkify r123456 in comments to point to SVN

[amonakov at gcc dot gnu.org]

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

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amonakov at gcc dot gnu.org

--- Comment #13 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
What about pseudo registers?  They are also r[0-9]+, and the number can easily
be in the thousands.

http://gcc.gnu.org/r99999 is almost 8 years ago, so bumping 4+ to 6+ should be
fine.

[Bug web/55237] Linkify r123456 in comments to point to SVN

[LpSolit at netscape dot net]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 13040 bytes --]

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

--- Comment #14 from Frédéric Buclin <LpSolit at netscape dot net> ---
On the other hand, you are free to not click on a register name which is
linkified.
>From gcc-bugs-return-422320-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 15 11:36:01 2013
Return-Path: <gcc-bugs-return-422320-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15660 invoked by alias); 15 May 2013 11:36:01 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15623 invoked by uid 48); 15 May 2013 11:35:57 -0000
From: "jojelino at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/57286] New: [4.9 regression] infinite recurison in fold-const.c:10037
Date: Wed, 15 May 2013 11:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jojelino at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-57286-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-05/txt/msg00993.txt.bz2
Content-length: 10867

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW286

            Bug ID: 57286
           Summary: [4.9 regression] infinite recurison in
                    fold-const.c:10037
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jojelino at gmail dot com

Created attachment 30121
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id0121&actioníit
preprocessed source

(gdb) r
Starting program: /usr/libexec/gcc/i686-pc-cygwin/4.9.0/cc1.exe -quiet -v -I .
-I .. -I ../include -MD .libs/libfaac_la-aacquant.d -MF
.deps/libfaac_la-aacquant.Tpo -MP -MT libfaac_la-aacquant.lo -Dunix -idirafter
/usr/lib/gcc/i686-pc-cygwin/4.9.0/../../../../include/w32api -idirafter
/usr/lib/gcc/i686-pc-cygwin/4.9.0/../../../../i686-pc-cygwin/lib/../../include/w32api
-D HAVE_CONFIG_H -D DRM -D DLL_EXPORT -D PIC aacquant.c -march=core2 -mcx16
-msahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma
-mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2
-msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase
-mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt --param
l1-cache-size2 --param l1-cache-line-sized --param l2-cache-size 48
-mtune=core2 -quiet -dumpbase aacquant.c -auxbase-strip
.libs/libfaac_la-aacquant.o -g -O4 -std=gnu11 -version -frename-registers
-fno-strict-overflow -o /tmp/ccEheGnn.s
[New Thread 16040.0x374c]
[New Thread 16040.0x1e20]
GNU C (GCC) version 4.9.0 20130515 (experimental) (i686-pc-cygwin)
        compiled by GNU C version 4.9.0 20130515 (experimental), GMP version
5.0.2, MPFR version 3.2.0-dev, MPC version 0.9
GGC heuristics: --param ggc-min-expand0 --param ggc-min-heapsize@96
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-cygwin/4.9.0/../../../../i686-pc-cygwin/include"
ignoring duplicate directory
"/usr/lib/gcc/i686-pc-cygwin/4.9.0/../../../../i686-pc-cygwin/lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
 .
 ..
 ../include
 /usr/lib/gcc/i686-pc-cygwin/4.9.0/include
 /usr/local/include
 /usr/lib/gcc/i686-pc-cygwin/4.9.0/include-fixed
 /usr/include
 /usr/lib/gcc/i686-pc-cygwin/4.9.0/../../../../include/w32api
End of search list.
GNU C (GCC) version 4.9.0 20130515 (experimental) (i686-pc-cygwin)
        compiled by GNU C version 4.9.0 20130515 (experimental), GMP version
5.0.2, MPFR version 3.2.0-dev, MPC version 0.9
GGC heuristics: --param ggc-min-expand0 --param ggc-min-heapsize@96
Compiler executable checksum: ebeca84797ce5db4d10946c78482951c

Program received signal SIGSEGV, Segmentation fault.
int_const_binop_1 (code=BIT_IOR_EXPR, arg1=0x7fbdfb40, arg2=0x7fbdfb20,
    overflowable=0x1) at ../.././gcc/fold-const.c:934
934       tree type = TREE_TYPE (arg1);
(gdb) bt -50
....

#25936 0x00799b42 in fold_binary_op_with_conditional_arg (loc=0x0,
    code=BIT_IOR_EXPR, type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9e28,
    cond=0x7fa71350, arg=0x7fac9e28, cond_first_p=0x1)
    at ../.././gcc/fold-const.c:6129
#25937 0x007b1963 in fold_binary_loc (loc=0x0, code=BIT_IOR_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9e28)
---Type <return> to continue, or q <return> to quit---
    at ../.././gcc/fold-const.c:10037
#25938 0x007e618d in fold_build2_stat_loc (loc=0x0, code=BIT_IOR_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9e28)
    at ../.././gcc/fold-const.c:14944
#25939 0x007e3f28 in fold_ternary_loc (loc=0x0, code=VEC_COND_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9e10, op2=0x7fac9e28)
    at ../.././gcc/fold-const.c:14261
#25940 0x007e6224 in fold_build3_stat_loc (loc=0x0, code=VEC_COND_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9e10, op2=0x7fac9e28)
    at ../.././gcc/fold-const.c:15006
#25941 0x00799b42 in fold_binary_op_with_conditional_arg (loc=0x0,
    code=BIT_IOR_EXPR, type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9dc8,
    cond=0x7fa71350, arg=0x7fac9dc8, cond_first_p=0x1)
    at ../.././gcc/fold-const.c:6129
#25942 0x007b1963 in fold_binary_loc (loc=0x0, code=BIT_IOR_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9dc8)
    at ../.././gcc/fold-const.c:10037
#25943 0x007e618d in fold_build2_stat_loc (loc=0x0, code=BIT_IOR_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9dc8)
    at ../.././gcc/fold-const.c:14944
#25944 0x007e3f28 in fold_ternary_loc (loc=0x0, code=VEC_COND_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9db0, op2=0x7fac9dc8)
    at ../.././gcc/fold-const.c:14261
---Type <return> to continue, or q <return> to quit---
#25945 0x007e6224 in fold_build3_stat_loc (loc=0x0, code=VEC_COND_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9db0, op2=0x7fac9dc8)
    at ../.././gcc/fold-const.c:15006
#25946 0x00799b42 in fold_binary_op_with_conditional_arg (loc=0x0,
    code=BIT_IOR_EXPR, type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9d68,
    cond=0x7fa71350, arg=0x7fac9d68, cond_first_p=0x1)
    at ../.././gcc/fold-const.c:6129
#25947 0x007b1963 in fold_binary_loc (loc=0x0, code=BIT_IOR_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9d68)
    at ../.././gcc/fold-const.c:10037
#25948 0x007e618d in fold_build2_stat_loc (loc=0x0, code=BIT_IOR_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9d68)
    at ../.././gcc/fold-const.c:14944
#25949 0x007e3f28 in fold_ternary_loc (loc=0x0, code=VEC_COND_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9d50, op2=0x7fac9d68)
    at ../.././gcc/fold-const.c:14261
#25950 0x007e6224 in fold_build3_stat_loc (loc=0x0, code=VEC_COND_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9d50, op2=0x7fac9d68)
    at ../.././gcc/fold-const.c:15006
#25951 0x00799b42 in fold_binary_op_with_conditional_arg (loc=0x0,
    code=BIT_IOR_EXPR, type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9d08,
    cond=0x7fa71350, arg=0x7fac9d08, cond_first_p=0x1)
    at ../.././gcc/fold-const.c:6129
---Type <return> to continue, or q <return> to quit---
#25952 0x007b1963 in fold_binary_loc (loc=0x0, code=BIT_IOR_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9d08)
    at ../.././gcc/fold-const.c:10037
#25953 0x007e618d in fold_build2_stat_loc (loc=0x0, code=BIT_IOR_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9d08)
    at ../.././gcc/fold-const.c:14944
#25954 0x007e3f28 in fold_ternary_loc (loc=0x0, code=VEC_COND_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9cf0, op2=0x7fac9d08)
    at ../.././gcc/fold-const.c:14261
#25955 0x007e6224 in fold_build3_stat_loc (loc=0x0, code=VEC_COND_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9cf0, op2=0x7fac9d08)
    at ../.././gcc/fold-const.c:15006
#25956 0x00799b42 in fold_binary_op_with_conditional_arg (loc=0x0,
    code=BIT_IOR_EXPR, type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9ca8,
    cond=0x7fa71350, arg=0x7fac9ca8, cond_first_p=0x1)
    at ../.././gcc/fold-const.c:6129
#25957 0x007b1963 in fold_binary_loc (loc=0x0, code=BIT_IOR_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9ca8)
    at ../.././gcc/fold-const.c:10037
#25958 0x007e618d in fold_build2_stat_loc (loc=0x0, code=BIT_IOR_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9ca8)
    at ../.././gcc/fold-const.c:14944
#25959 0x007e3f28 in fold_ternary_loc (loc=0x0, code=VEC_COND_EXPR,
---Type <return> to continue, or q <return> to quit---
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9c90, op2=0x7fac9ca8)
    at ../.././gcc/fold-const.c:14261
#25960 0x007e6224 in fold_build3_stat_loc (loc=0x0, code=VEC_COND_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9c90, op2=0x7fac9ca8)
    at ../.././gcc/fold-const.c:15006
#25961 0x00799b42 in fold_binary_op_with_conditional_arg (loc=0x0,
    code=BIT_IOR_EXPR, type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fa71338,
    cond=0x7fa71350, arg=0x7fa71338, cond_first_p=0x1)
    at ../.././gcc/fold-const.c:6129
#25962 0x007b1963 in fold_binary_loc (loc=0x0, code=BIT_IOR_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fa71338)
    at ../.././gcc/fold-const.c:10037
#25963 0x007e618d in fold_build2_stat_loc (loc=0x0, code=BIT_IOR_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fa71338)
    at ../.././gcc/fold-const.c:14944
#25964 0x007e3f28 in fold_ternary_loc (loc=0x0, code=VEC_COND_EXPR,
    type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fa71320, op2=0x7fa71338)
    at ../.././gcc/fold-const.c:14261
#25965 0x00b7b85a in fold_gimple_assign (si=0x5eea414)
    at ../.././gcc/gimple-fold.c:524
#25966 0x00b7d734 in fold_stmt_1 (gsi=0x5eea414, inplace=0x0)
    at ../.././gcc/gimple-fold.c:1184
#25967 0x00b7de12 in fold_stmt (gsi=0x5eea414)
---Type <return> to continue, or q <return> to quit---
    at ../.././gcc/gimple-fold.c:1312
#25968 0x00b96c72 in optimize_stmt (bb=0x7febc800, si=...)
    at ../.././gcc/tree-ssa-dom.c:2301
#25969 0x00b95c8f in dom_opt_enter_block (walk_data=0x5eea4d8, bb=0x7febc800)
    at ../.././gcc/tree-ssa-dom.c:1853
#25970 0x00e2fc6f in walk_dominator_tree (walk_data=0x5eea4d8, bb=0x7febc800)
    at ../.././gcc/domwalk.c:210
#25971 0x00b90adc in tree_ssa_dominator_optimize ()
    at ../.././gcc/tree-ssa-dom.c:827
#25972 0x006e5752 in execute_one_pass (pass=0x20041b58)
    at ../.././gcc/passes.c:2337
#25973 0x006e594d in execute_pass_list (pass=0x20041b58)
    at ../.././gcc/passes.c:2389
#25974 0x006e5979 in execute_pass_list (
    pass=0x1056500 <pass_all_optimizations>) at ../.././gcc/passes.c:2390
#25975 0x006ebb3f in expand_function (node=0x7fd244c0)
    at ../.././gcc/cgraphunit.c:1640
#25976 0x006ec080 in expand_all_functions () at ../.././gcc/cgraphunit.c:1744
#25977 0x006ecaeb in compile () at ../.././gcc/cgraphunit.c:2042
#25978 0x006ecc62 in finalize_compilation_unit ()
    at ../.././gcc/cgraphunit.c:2119
#25979 0x00423e4e in c_write_global_declarations ()
    at ../.././gcc/c/c-decl.c:10118
---Type <return> to continue, or q <return> to quit---
#25980 0x0077310b in compile_file () at ../.././gcc/toplev.c:558
#25981 0x00774f39 in do_compile () at ../.././gcc/toplev.c:1872
#25982 0x007750c0 in toplev_main (argc=0x51, argv=0x5eea790)
    at ../.././gcc/toplev.c:1948
#25983 0x00f2552c in main (argc=0x51, argv=0x5eea790) at ../.././gcc/main.c:36
#25984 0x610078d1 in _cygwin_exit_return ()
    at /netrel/src/cygwin-snapshot-20130409-1/winsup/cygwin/dcrt0.cc:1018
#25985 0x610053ed in _cygtls::call2 (this=<optimized out>,
    func=0x61006dc0 <dll_crt0_1(void*)>, arg=0x0,
    buf=0x6100558b <_cygtls::call(unsigned long (*)(void*, void*), void*)+91>)
    at /netrel/src/cygwin-snapshot-20130409-1/winsup/cygwin/cygtls.cc:99
#25986 0x05eeff78 in ?? ()
#25987 0x00faa422 in cygwin_crt0 (f=0xf2550c <main(int, char**)>)
    at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/lib/cygwin_crt0.c:22
#25988 0x00401015 in mainCRTStartup ()
    at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/crt0.c:29
(gdb)

[Bug web/55237] Linkify r123456 in comments to point to SVN

[stevenb.gcc at gmail dot com]

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

--- Comment #15 from stevenb.gcc at gmail dot com <stevenb.gcc at gmail dot com> ---
> --- Comment #14 from Frédéric Buclin <LpSolit at netscape dot net> ---
> On the other hand, you are free to not click on a register name which is
> linkified.

That is true, but it's a bit distracting.
Let's not bike shed over this. It's nothing major, only nice-to-have :-)
>From gcc-bugs-return-422323-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 15 11:50:16 2013
Return-Path: <gcc-bugs-return-422323-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24157 invoked by alias); 15 May 2013 11:50:16 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 24122 invoked by uid 48); 15 May 2013 11:50:13 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/57286] [4.9 regression] infinite recurison in fold-const.c:10037
Date: Wed, 15 May 2013 11:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc component target_milestone
Message-ID: <bug-57286-4-sL9QNPxSh3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57286-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57286-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-05/txt/msg00996.txt.bz2
Content-length: 537

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW286

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glisse at gcc dot gnu.org
          Component|tree-optimization           |middle-end
   Target Milestone|---                         |4.9.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the comment was correct after all ;)