On Tue, Nov 5, 2013 at 4:41 PM, Jonathan Wakely jwakely@gmail.com wrote:
On 5 November 2013 15:38, Jonathan Wakely wrote:
On 5 November 2013 15:32, Jonathan Wakely wrote:
On 5 November 2013 15:27, Iyer, Balaji V wrote:
In file included from /usr/include/sys/vt.h:1:0,
from
Are you including linux/vt.h yourself? If you get it via a glibc header then
it's a SUSE issue, yes. Can you specify the SUSE version you are looking at?
Even for 12.1 I see 'newev' here though SLE11 seems to have 'new'.
I get the error with
SUSE Linux Enterprise Server 11 (x86_64)
On 6 November 2013 10:45, Richard Biener wrote:
Are you including linux/vt.h yourself? If you get it via a glibc header
then it's a SUSE issue, yes. Can you specify the SUSE version
you are looking at? Even for 12.1 I see 'newev' here though SLE11
seems to have 'new'.
libsanitizer
On Wed, Nov 6, 2013 at 11:50 AM, Gopalasubramanian, Ganesh
ganesh.gopalasubraman...@amd.com wrote:
Are you including linux/vt.h yourself? If you get it via a glibc header
then it's a SUSE issue, yes. Can you specify the SUSE version you are
looking at? Even for 12.1 I see 'newev' here
Ping
On Thu, Oct 31, 2013 at 7:42 PM, Andrey Turetskiy
andrey.turets...@gmail.com wrote:
Let's check my understanding:
1) We can configure gcc with, say, --offload-target=mic,ptx. It means
that after build and install we have 3 compilers: for host, for mic
and for ptx. In general case, the
Hi all,
GCC has a number of floating-point-related type-generic built-ins, which are
great and which we largely rely on in the gfortran runtime library (rather than
depending on the possibly poor-quality target math library).
However, I have not been able to find a way to test for a signaling
On Wed, Nov 06, 2013 at 05:11:07PM +0400, Andrey Turetskiy wrote:
Let's check my understanding:
1) We can configure gcc with, say, --offload-target=mic,ptx. It means
Note, configure options should be either --with- or --enable- prefixed.
Plus, it is probably better to use configuration
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: Wednesday, November 6, 2013 5:55 AM
To: Gopalasubramanian, Ganesh
Cc: Iyer, Balaji V; gcc@gcc.gnu.org; konstantin.s.serebry...@gmail.com;
Jonathan Wakely
Subject: Re: Bootstrap issues in libsanitizer
On Wed, 6 Nov 2013, FX wrote:
GCC has a number of floating-point-related type-generic built-ins, which
are great and which we largely rely on in the gfortran runtime library
(rather than depending on the possibly poor-quality target math
library).
However, I have not been able to find a
On Wed, Nov 6, 2013 at 7:37 AM, Tom Tromey tro...@redhat.com wrote:
Tobias == Tobias Burnus bur...@net-b.de writes:
Tobias + cpp_warning (pfile, CPP_W_DATE_TIME, Macro \%s\ might
prevent
Tobias + reproduce builds, NODE_NAME (node));
Tobias + cpp_warning
On Nov 6 2013, FX wrote:
GCC has a number of floating-point-related type-generic built-ins, which
are great and which we largely rely on in the gfortran runtime library
(rather than depending on the possibly poor-quality target math library).
However, I have not been able to find a way to
On Wed, 6 Nov 2013, N.M. Maclaren wrote:
Yes, due to the poor quality of the IEEE 754 specifications. In 1984,
the distinction was left completely unspecified (even in intent). In
2008, there is a recommendation (no more) that the top bit of the payload
is used, with no specification of
Yes, due to the poor quality of the IEEE 754 specifications. In 1984,
the distinction was left completely unspecified (even in intent). In
2008, there is a recommendation (no more) that the top bit of the payload
is used, with no specification of what to do if that is zero (which is
the most
I'll do the patch tomorrow to fix it. The patch should be not big but it will
need a lot testing.
Thanks Vladimir. The fix appears to be working.
On Wed, 6 Nov 2013, N.M. Maclaren wrote:
Yes, due to the poor quality of the IEEE 754 specifications. In 1984,
the distinction was left completely unspecified (even in intent). In
2008, there is a recommendation (no more) that the top bit of the payload
is used, with no
The patch I've posted at
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00493.html is intended to
be mainline-ready (with the hopes that other people may pick up the ObjC
and OpenMP issues, and floating-point handling for non-x86 targets, once
it's in mainline). If that gets in in time for 4.9
On Wed, Nov 6, 2013 at 5:44 AM, FX fxcoud...@gmail.com wrote:
GCC has a number of floating-point-related type-generic built-ins, which are
great and which we largely rely on in the gfortran runtime library (rather
than depending on the possibly poor-quality target math library).
However, I
On 11/06/13 15:07, Joseph S. Myers wrote:
The patch I've posted at
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00493.html is intended to
be mainline-ready
[ ... ]
Joseph, just wanted to say thanks for picking this up and running with
it. It was a tough decision to have Andrew put the work
Given how murky signaling NaNs are in practice, I think it's worth
asking: why do you want to know?
Because I am writing an implementation of the IEEE support modules in GNU
Fortran, which are part of the Fortran 2003 standard. And the standard provides
for a procedure (IEEE_CLASS) to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59015
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||accepts-invalid,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58290
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
This appears to have been fixed / gone latent between r204377 and r204433 (~
Nov 6th.)
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
gcc version 4.9.0 20131106 (experimental) [trunk revision 204433] (GCC) yields
the following internal compiler error:
f951: internal compiler error: Segmentation fault
0x9fee4f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926
--- Comment #10 from lailavrazda1979 at gmail dot com ---
Is this going to be fixed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59011
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58421
Yukhin Kirill kirill.yukhin at intel dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59011
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
void
foo (int m)
{
int a[m];
void bar (void)
{
{
int baz (void)
{
return a[0];
}
}
a[0] = 42;
}
bar ();
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59015
--- Comment #2 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
We don't trigger the check in resolve.c:resolve_transfer() because we bail out
early:
if (exp == NULL || (exp-expr_type != EXPR_VARIABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59017
Bug ID: 59017
Summary: Infinite loop introduced in program with -O2 or -O3 on
Mageia Linux x86-64 Cauldron with gcc-4.8.2
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59017
--- Comment #1 from Shlomi Fish shlomif at shlomifish dot org ---
Created attachment 31171
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31171action=edit
The .c file
This is the offending .c file . I forgot to note that the problem is that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59015
--- Comment #3 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
Allowing EXPR_STRUCTURE to go through the tests (by adding it along
EXPR_VARIABLE and EXPR_FUNCTION) leads to a failure of c_ptr_tests_16.f90 (the
rest of the testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50436
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58985
Hans-Peter Nilsson hp at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
Bug ID: 59018
Summary: [4.9 Regression] libsanitizer doesn't build for x32
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59014
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
Bug ID: 59019
Summary: [4.9 regression] ICE in advance_target_bb, at
sched-rgn.c:3561
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59014
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
I'd say this is .vrp1. In .mergephi2, we have
bb 4:
a.1_11 = a.1_5;
d = a.1_11;
return 0;
but in .vrp1:
bb 4:
a.1_13 = 0;
a.1_11 = 0;
d = 0;
return 0;
And
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59020
Bug ID: 59020
Summary: [4.9 Regression] internal compiler error: in
maybe_add_or_update_dep_1, at sched-deps.c:933
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
-in specs.
COLLECT_GCC=gfortran
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/data/vjoost/gnu/gcc_trunk/install
--enable-languages=c,c++,fortran --disable-multilib --enable-plugins
--enable-lto --disable-bootstrap
Thread model: posix
gcc version 4.9.0 20131106
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59014
--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
And, it's not related to -Os; the bug triggers exactly when VRP is run.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59021
Bug ID: 59021
Summary: [4.9 regression] new vzeroupper instructions generated
with -mavx
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59020
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||x86_64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59021
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||x86_64-*-*,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59017
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59014
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59011
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
Known
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59008
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59014
--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
It seems we create wrong ASSERT_EXPR:
a.1_5 = a;
_7 = (_Bool) a.1_5;
_8 = _4 | _7;
if (_8 != 0)
goto bb 5;
else
goto bb 6;
bb 6:
a.1_15 = ASSERT_EXPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020
--- Comment #23 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #16)
I want to mention that there is now some additional support for IEEE in
libgfortran/config. None of those functions is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58580
Dodji Seketeli dodji at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58653
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
The issue is that predcom treats
e[c + 3][d] and e[c + 4][d]
as having distance '2', but that's in a dimension that is not evolving.
Later we adjust the evolving dimension index
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733
--- Comment #3 from octoploid at yandex dot com ---
The issue only happens when I use the 'gold' linker,
ld.bfd is fine. So maybe a binutils bug?
Honza?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59022
Bug ID: 59022
Summary: Bogus warning: conversion to 'short int' from 'int'
may alter its value [-Wconversion]
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59021
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
CC||kyukhin at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58580
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59022
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #28 from Jan Smets jan.sm...@alcatel-lucent.com ---
Can this be backported to 4.8 please.
Thanks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59023
Bug ID: 59023
Summary: [4.9 regression] ICE in gfc_search_interface with
BIND(C)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59021
--- Comment #2 from Uroš Bizjak ubizjak at gmail dot com ---
Isn't the argument list a bit strange for call insn?
(call_insn 20 19 21 2 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI (foo) [flags 0x41] function_decl
0x2b9e82c58f00 foo)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58697
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58653
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org ---
*** Bug 58697 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59011
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Known to work|4.3.6 |4.4.0
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58653
--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Wed Nov 6 15:00:16 2013
New Revision: 204458
URL: http://gcc.gnu.org/viewcvs?rev=204458root=gccview=rev
Log:
2013-11-06 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58653
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59023
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59006
--- Comment #1 from John Regehr regehr at cs dot utah.edu ---
Simpler test case:
$ cat small.c
int a[10], b;
int main() {
for (; b = 0; b++)
a[b] = a[0] || b;
}
$ gcc -O3 small.c
small.c: In function ‘main’:
small.c:2:5: internal compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59024
Bug ID: 59024
Summary: ICE: after printing certain error messages, the
compiler seg faults.
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025
Bug ID: 59025
Summary: Revision 203979 causes failure in CPU2006 benchmark
435.gromacs
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58985
--- Comment #7 from wmi at gcc dot gnu.org ---
Author: wmi
Date: Wed Nov 6 17:06:46 2013
New Revision: 204461
URL: http://gcc.gnu.org/viewcvs?rev=204461root=gccview=rev
Log:
2013-11-06 Wei Mi w...@google.com
PR regression/58985
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
Was this before r204348, or can you reproduce it also after that follow-up fix?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59006
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58580
--- Comment #9 from rguenther at suse dot de rguenther at suse dot de ---
On Wed, 6 Nov 2013, dodji at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58580
Dodji Seketeli dodji at gcc dot gnu.org changed:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59021
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
--- Comment #1 from Kostya Serebryany kcc at gcc dot gnu.org ---
At least one of these patches does not build with clang:
/home/kcc/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:807:21:
error: ignored asm label 'r8' on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Kostya Serebryany from comment #1)
At least one of these patches does not build with clang:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59021
--- Comment #4 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Uroš Bizjak from comment #3)
I have patch in testing.
The call_insn RTX should always define its mode. Previously, the state was
switched to DIRTY by an eventual move to a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Kostya Serebryany from comment #1)
At least one of these patches does not build with clang:
/home/kcc/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
--- Comment #4 from Kostya Serebryany kcc at gcc dot gnu.org ---
the patches look good and pass our testing on x86_64 and i386.
Thanks!
committed as http://llvm.org/viewvc/llvm-project?view=revisionrevision=194155
(fixed 4 small lint warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
--- Comment #5 from Kostya Serebryany kcc at gcc dot gnu.org ---
Can you try
register void *r8 __asm__ (r8) = newtls;
register int *r10 __asm__ (r10) = child_tidptr;
Yep, works!
But you need to enable x32 first on your OS, which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Kostya Serebryany from comment #4)
the patches look good and pass our testing on x86_64 and i386.
Thanks!
committed as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
--- Comment #7 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Kostya Serebryany from comment #5)
Can you try
register void *r8 __asm__ (r8) = newtls;
register int *r10 __asm__ (r10) = child_tidptr;
Yep, works!
But you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
--- Comment #8 from Kostya Serebryany kcc at gcc dot gnu.org ---
I will submit my patches to GCC now.
Ok!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55946
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025
--- Comment #2 from Pat Haugen pthaugen at gcc dot gnu.org ---
Yes, this still fails with r204348.
I did discover that adding -mrecip=rsqrt allows the benchmark to succeed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59021
--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Nov 6 19:37:12 2013
New Revision: 204464
URL: http://gcc.gnu.org/viewcvs?rev=204464root=gccview=rev
Log:
PR target/59021
* config/i386/i386.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59026
Bug ID: 59026
Summary: ELEMENTAL procedure with VALUE arguments emits wrong
code
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56806
Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59028
Bug ID: 59028
Summary: gengtype 4.7 fails with operator inside GTY-ed struct
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59029
Bug ID: 59029
Summary: ICE with builtin function and -fsanitize=address
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027
Bug ID: 59027
Summary: std::is_signed does not include check for
is_arithmetic
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59029
--- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org ---
The broken caret diagnostic seems to be a general problem of today's build.
I'll open a separate bug report for this.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
With today's trunk (4.9.0 20131106) the caret diagnostic always points to the
first line, although the line number is correct.
==
// First
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11006
--- Comment #9 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org ---
Author: paolo
Date: Wed Nov 6 20:19:10 2013
New Revision: 204469
URL: http://gcc.gnu.org/viewcvs?rev=204469root=gccview=rev
Log:
/cp
2013-11-06 Paolo Carlini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59030
--- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org ---
With yesterday's build I got a correct diagnostic:
bug.cc:5:9: error: expected primary-expression before ';'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11468
Bug 11468 depends on bug 11006, which changed state.
Bug 11006 Summary: [CNI] ICE with use of __java_boolean
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11006
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4439
Bug 4439 depends on bug 11006, which changed state.
Bug 11006 Summary: [CNI] ICE with use of __java_boolean
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11006
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11006
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59030
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||dodji at gcc dot
1 - 100 of 292 matches
Mail list logo
