Snapshot gcc-4.8-20140522 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140522/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, May 22, 2014 at 01:36:47PM +0200, Richard Biener wrote:
> The GNU Compiler Collection version 4.8.3 has been released.
>
> GCC 4.8.3 is the third bug-fix release containing important fixes for
> regressions and serious bugs in GCC 4.8.2 with over 141 bugs fixed since
> the previous release
On 05/22/2014 03:12 AM, Jakub Jelinek wrote:
> No way. SUBREG_PROMOTED_UNSIGNED_P right now resides in two separate bits,
> volatil and unchanging. Right now volatile != 0, unchanging ignored
> is -1, volatile == 0, then the value is unchanging.
> What I meant is change this representation, e.g.
On 05/22/2014 10:16 PM, Vladimir Makarov wrote:
It also permits to
rematerialize not only on loop borders (although it is the most
important points).
That would certainly be interesting for the following hot subroutine in
our weather forecasting model (attached). Note the loop from (line 157
On 05/21/2014 12:25 AM, Ajit Kumar Agarwal wrote:
> Hello All:
>
> Simpson does the Live range shrinking and reduction of register pressure by
> using the computation that are not load and store but the arithmetic
> computation. The computation
> where the operands and registers are live at the e
On Thu, May 22, 2014 at 12:36 PM, Regan, Brian (EPC COE)
wrote:
> Don't misunderstand - I like the behaviour. I don't want the unnecessary
> implicit conversions).
>
> My concern stems only from the compliance to the standard. Some of our
> internal software standards require ISO99 compliance, a
Don't misunderstand - I like the behaviour. I don't want the unnecessary
implicit conversions).
My concern stems only from the compliance to the standard. Some of our internal
software standards require ISO99 compliance, as do standards imposed by our
customers (e.g. Boeing via their D6).
If w
On Thu, May 22, 2014 at 07:16:43PM +, Regan, Brian (EPC COE) wrote:
> I wonder if someone could help shed light on this for me.
Why do you think this is a problem? Conversion from float to double
can't raise any exceptions, no bits are lost, and
(double) a < 200.0
and
a < 200.0f
have the exa
I wonder if someone could help shed light on this for me.
Based on the statement in ISO C spec (ISO 9899:1990) section '6.1.3.1 Floating
Constants' statement "An unsuffixed floating constant has type double." it
appears to me that the gcc compiler may not be in strict compliance.
--
> The fix is attached. Ok to commit?
OK,
thanks!
Honza
The fix is attached. Ok to commit?
David
On Thu, May 22, 2014 at 9:11 AM, Xinliang David Li wrote:
> I did -- but very likely there was a process error in my side. Will
> fix them soon.
>
> David
>
> On Thu, May 22, 2014 at 2:12 AM, Richard Biener
> wrote:
>> On Thu, May 22, 2014 at 10:49 AM, P
Tejas Belagod wrote:
Are there any tricks I can use to debug an LTO ICE?
See LTO section on https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
Tobias
On 05/21/2014 05:30 PM, Vladimir Makarov wrote:
On 2014-05-20, 5:18 PM, shmeel gutl wrote:
The problem that I see is that the haifa scheduler schedules one cycle
at a time, in a forward order, by picking from a list of instructions
that can be scheduled without delays. So, in the above example,
I did -- but very likely there was a process error in my side. Will
fix them soon.
David
On Thu, May 22, 2014 at 2:12 AM, Richard Biener
wrote:
> On Thu, May 22, 2014 at 10:49 AM, Paolo Carlini
> wrote:
>> Hi,
>>
>> is somebody already working on the regressions which appeared yesterday,
>> see
Hi,
Are there any tricks I can use to debug an LTO ICE? Lto1 --help does not seem to
give me an option to output trace dumps etc.
What I suspect is happening is that cc1 builds erroneous LTO IR info in the
objects that causes the ICEs. Is there a reader that will dump the IR from these
LTO obj
PR60901 is listed in the bug fixes for gcc 4.8.3, but I don't see the patch
ever applied to the 4_8 branch in the bug report, and 4.8.3 is listed as known
to fail.
-Kenny
The GNU Compiler Collection version 4.8.3 has been released.
GCC 4.8.3 is the third bug-fix release containing important fixes for
regressions and serious bugs in GCC 4.8.2 with over 141 bugs fixed since
the previous release.
This release is available from the FTP servers listed at:
http://ww
Status
==
GCC 4.8.3 has been released, the branch is now open again under the usual
release branch rules (regression fixes and documentation fixes only).
Quality Data
Priority # Change from last report
--- ---
P1
On Thu, May 22, 2014 at 08:01:45PM +1000, Kugan wrote:
> --- a/gcc/expr.c
> +++ b/gcc/expr.c
> @@ -328,7 +328,8 @@ convert_move (rtx to, rtx from, int unsignedp)
>if (GET_CODE (from) == SUBREG && SUBREG_PROMOTED_VAR_P (from)
>&& (GET_MODE_PRECISION (GET_MODE (SUBREG_REG (from)))
>
On 21/05/14 17:05, Jakub Jelinek wrote:
> On Wed, May 21, 2014 at 12:53:47PM +1000, Kugan wrote:
>> On 20/05/14 16:52, Jakub Jelinek wrote:
>>> On Tue, May 20, 2014 at 12:27:31PM +1000, Kugan wrote:
1. Handling NOP_EXPR or CONVERT_EXPR that are in the IL because they
are required for typ
On Thu, May 22, 2014 at 10:49 AM, Paolo Carlini
wrote:
> Hi,
>
> is somebody already working on the regressions which appeared yesterday,
> see:
David, did you forget to run the testsuite?
Richard.
> https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg01920.html
>
> ie:
>
> FAIL: g++.dg/ipa/dev
On 21 May 2014 14:13, Sheheryar Zahoor Qazi
wrote:
>>>Building libgcc is not optional. It is required for all targets.
>
> So, irrespective whether i provide floating point implementation by
> soft-fp, fpu-bit or ieeelib, an error free libgcc build is a MUST?
>
> What if I dont want to generate c
Hi,
is somebody already working on the regressions which appeared yesterday,
see:
https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg01920.html
ie:
FAIL: g++.dg/ipa/devirt-15.C -std=gnu++98 scan-ipa-dump devirt "Speculatively
devirtualizing call"
FAIL: g++.dg/ipa/devirt-15.C -std=gnu++11
23 matches
Mail list logo
