What do you propose that we do?
Probably just jump to 5.0 (or 5.1) without the subsequent acceleration.
Step 1: We agree that the current major revision number conveys no
information, and therefore we will change the major revision number
with every release. (I understand that you do not
On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote:
What do you propose that we do?
Probably just jump to 5.0 (or 5.1) without the subsequent acceleration.
That was my preference too.
Jakub
On Wed, Aug 06, 2014 at 09:42:23AM +0200, Jakub Jelinek wrote:
On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote:
What do you propose that we do?
Probably just jump to 5.0 (or 5.1) without the subsequent acceleration.
That was my preference too.
FWIW, me too. This way
On Wed, Aug 6, 2014 at 9:42 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote:
What do you propose that we do?
Probably just jump to 5.0 (or 5.1) without the subsequent acceleration.
That was my preference too.
What singles out 5.0 to
On Wed, Aug 06, 2014 at 10:44:11AM +0200, Richard Biener wrote:
On Wed, Aug 6, 2014 at 9:42 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote:
What do you propose that we do?
Probably just jump to 5.0 (or 5.1) without the subsequent
On Wed, Aug 6, 2014 at 10:48 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Aug 06, 2014 at 10:44:11AM +0200, Richard Biener wrote:
On Wed, Aug 6, 2014 at 9:42 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote:
What do you propose
On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote:
- libstdc++ ABI changes (it is a significant user visible change,
if you rebuild everything, no extra effort is needed, but otherwise
if you want some C++ code built with older compilers work together
with code built
On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote:
On Wed, Aug 6, 2014 at 10:48 AM, Jakub Jelinek ja...@redhat.com wrote:
- libstdc++ ABI changes (it is a significant user visible change,
if you rebuild everything, no extra effort is needed, but otherwise
if you want some
On Aug 6, 2014, at 2:10 AM, Marek Polacek pola...@redhat.com wrote:
On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote:
On Wed, Aug 6, 2014 at 10:48 AM, Jakub Jelinek ja...@redhat.com wrote:
- libstdc++ ABI changes (it is a significant user visible change,
if you rebuild
On Wed, 6 Aug 2014, Jakub Jelinek wrote:
- libstdc++ ABI changes
It seems unlikely to be in the next release, it is too late in the cycle.
Chances to break the ABI don't come often, and rushing one at the end of
stage1 would be wasting a good opportunity.
--
Marc Glisse
On Wed, Aug 06, 2014 at 11:20:01AM +0200, Marc Glisse wrote:
On Wed, 6 Aug 2014, Jakub Jelinek wrote:
- libstdc++ ABI changes
It seems unlikely to be in the next release, it is too late in the cycle.
Chances to break the ABI don't come often, and rushing one at the end of
stage1 would be
On 6 August 2014 10:06, Jakub Jelinek wrote:
On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote:
- libstdc++ ABI changes (it is a significant user visible change,
if you rebuild everything, no extra effort is needed, but otherwise
if you want some C++ code built with older
On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely jwakely@gmail.com wrote:
On 6 August 2014 10:06, Jakub Jelinek wrote:
On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote:
- libstdc++ ABI changes (it is a significant user visible change,
if you rebuild everything, no extra
On Wed, Aug 6, 2014 at 12:20 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely jwakely@gmail.com
wrote:
On 6 August 2014 10:06, Jakub Jelinek wrote:
On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote:
- libstdc++ ABI
On 6 August 2014 11:20, Richard Biener wrote:
On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely jwakely@gmail.com
wrote:
On 6 August 2014 10:06, Jakub Jelinek wrote:
On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote:
- libstdc++ ABI changes (it is a significant user visible
On Wed, Aug 06, 2014 at 12:20:04PM +0200, Richard Biener wrote:
No, AFAIK it is also -std=c++98. At least my understanding was that
std::list and std::string are going to change ABI (and get new abi_tag)
in all C++ modes. Jonathan/Jason/Paolo, is that right?
Correct. We want C++03 code
On Wed, Aug 6, 2014 at 12:25 PM, Jonathan Wakely jwakely@gmail.com wrote:
On 6 August 2014 11:20, Richard Biener wrote:
On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely jwakely@gmail.com
wrote:
On 6 August 2014 10:06, Jakub Jelinek wrote:
On Wed, Aug 06, 2014 at 11:04:14AM +0200,
On Wed, 6 Aug 2014, Richard Biener wrote:
It's an ABI change for all modes (but not a SONAME change because the
old and new definitions will both be present in the .so).
Ugh. That's going to be a nightmare to support.
Yes. And IMO a waste of effort compared to a clean .so.7 break, but
On Wed, Aug 06, 2014 at 12:31:57PM +0200, Richard Biener wrote:
Ok, so the problematical case is
struct X { std::string s; };
void foo (X);
Yeah.
then. OTOH I remember that then mangling of X changes as well?
Only if you add abi_tag attribute to X.
I hope the libstdc++ folks will add
On Wed, Aug 06, 2014 at 12:35:02PM +0200, Marc Glisse wrote:
It's an ABI change for all modes (but not a SONAME change because the
old and new definitions will both be present in the .so).
Ugh. That's going to be a nightmare to support.
Yes. And IMO a waste of effort compared to a clean
On Wed, 6 Aug 2014, Jakub Jelinek wrote:
On Wed, Aug 06, 2014 at 12:31:57PM +0200, Richard Biener wrote:
Ok, so the problematical case is
struct X { std::string s; };
void foo (X);
Yeah.
then. OTOH I remember that then mangling of X changes as well?
Only if you add abi_tag attribute to
On Wed, Aug 6, 2014 at 12:50 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Wed, 6 Aug 2014, Jakub Jelinek wrote:
On Wed, Aug 06, 2014 at 12:31:57PM +0200, Richard Biener wrote:
Ok, so the problematical case is
struct X { std::string s; };
void foo (X);
Yeah.
then. OTOH I remember
On 5 August 2014 19:32, Роман Донченко wrote:
Hello,
Tags for the following releases are not in the Git mirror repository:
* 3.3
* 3.3.1
* 3.3.5
* 3.3.6
* 4.7.4
* 4.8.3
* 4.9.1
I figure this is the place to report it?
Yes, this is the right place, thanks. The tags in the Git mirror
On 08/05/2014 10:21 AM, Prathamesh Kulkarni wrote:
Hi,
I have written notes on GCC re-architecture BOF
presented at the Cauldron. I would be grateful if you would
review it for me.
Seems to cover the core parts well... all subject to change as we go
tho :-)
initial focus wlll be the
On 6 August 2014 11:31, Richard Biener richard.guent...@gmail.com wrote:
Ok, so the problematical case is
struct X { std::string s; };
void foo (X);
Wouldn't it be even more troublesome with an application that dynloads
dsos depending on user input.
The install script might check if the dso
Hi Art,
I tried the '--without-gnu-ld --with-ld=/usr/ccs/bin/ld' configure options
and my build failed again as my GNU 'ld' binary was again being found. So
strange: I'd have expected for gcc to honor a full path in --with-ld
(and --with-ls for that matter). But then I never tried this before
On Wed, Aug 06, 2014 at 12:33:42PM +0100, Joern Rennecke wrote:
On 6 August 2014 11:31, Richard Biener richard.guent...@gmail.com wrote:
Ok, so the problematical case is
struct X { std::string s; };
void foo (X);
Wouldn't it be even more troublesome with an application that dynloads
On Tue, 2014-08-05 at 03:18 +0530, Prathamesh Kulkarni wrote:
Hi,
Please find attached my notes on libgccjit.so - An experimental
JIT library using GCC as backend. I would be grateful if you would
review it for me.
Looks good to me
Dave
On Tue, 2014-08-05 at 03:20 +0530, Prathamesh Kulkarni wrote:
Hi,
Please find attached my notes on A proposal on type-safe RTL.
I would be grateful if you would review it for me.
Thanks,
Prathamesh
A proposal for type-safe RTL
Author: David Malcolm
RTL is a low-level
Hi,
These are my notes for Machine guided energy efficient
compilation presented at Cauldron.
Machine guided energy efficient compilation.
Author: Jeremy Bennett
MAGEEC (Machine guided energy efficient compilation),
is a plugin for GCC and other compilers, which includes a
machine
Hi,
I have written notes for libabigail - Towards Better ABI
compatibility checking presented at Cauldron. I would be
grateful if you would review it for me.
libabigail - Towards Better ABI compatibility checking
Author: Dodji Seketeli
libabigail (Library for ABI generic analysis and
Hi,
I have written notes for GNU C library BOF presented at
Cauldron. I would be grateful if you would review it for me.
GNU C library BOF
Author: Carlos O'Donell
glibc (GNU C library) is available on most GNU systems
with the Linux kernel. It follows all relevant standards including
Jakub,
I've looked into how to implement the openacc kernels directive in gcc.
In order to map the loopnests marked by the kernels directive efficiently on
accelerator hardware, we need parallelization and vectorization.
Focussing on paralellization for the moment, a possibility for
Dear
How are you?
I have a very Lucrative and Life Changing Business Opportuinity for you.
You can also check on my Biography from this link as well (
http://bank.hangseng.com/1/2/about-us/directors-organisation/board-of-directors
).
This is my email:sarah.legg...@gmail.com
I hope to hear
I found the root cause.
In function rs6000_preferred_reload_class, it specifically check the
case that reload 0 into a VSX register, then the target reload class
is VSX register. VSX instructions can't load a constant into VSX
registers directly, I guess the author wanted to use a SUB or XOR
Accessing https://gcc.gnu.org/viewvc/gcc/trunk/
Says it is showing 38 files. But in fact, it shows only the first 25. As an
example, libstdc++-v3 is missing.
Same thing happens in other parts of the tree.
I checked the HTML page source, and the files simply aren't there.
David
On Aug 6, 2014, at 2:38 PM, David Gero david.g...@exfo.com wrote:
Accessing https://gcc.gnu.org/viewvc/gcc/trunk/
Says it is showing 38 files. But in fact, it shows only the first 25. As an
example, libstdc++-v3 is missing.
Same thing happens in other parts of the tree.
I checked
Hi,
On 08/06/2014 08:48 PM, paul_kon...@dell.com wrote:
On Aug 6, 2014, at 2:38 PM, David Gero david.g...@exfo.com wrote:
Accessing https://gcc.gnu.org/viewvc/gcc/trunk/
Says it is showing 38 files. But in fact, it shows only the first 25. As an
example, libstdc++-v3 is missing.
Same
On Aug 6, 2014, at 2:59 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
On 08/06/2014 08:48 PM, paul_kon...@dell.com wrote:
On Aug 6, 2014, at 2:38 PM, David Gero david.g...@exfo.com wrote:
Accessing https://gcc.gnu.org/viewvc/gcc/trunk/
Says it is showing 38 files. But in
Hi,
On 08/06/2014 08:48 PM, paul_kon...@dell.com wrote:
On Aug 6, 2014, at 2:38 PM, David Gero david.g...@exfo.com wrote:
Accessing https://gcc.gnu.org/viewvc/gcc/trunk/
Says it is showing 38 files. But in fact, it shows only the first 25. As
an example, libstdc++-v3 is missing.
Same
Hi,
On 08/06/2014 09:19 PM, David Gero wrote:
Wow. What an amazingly unintuitive widget. I looked all over the page
for a Next 25 files button. A Go To button that doesn't talk about
next 25 files meant nothing. ViewVC used to display all the files.
This is a giant leap backward in the User
On Wed, 2014-08-06 at 21:34 +0200, Paolo Carlini wrote:
Hi,
On 08/06/2014 09:19 PM, David Gero wrote:
Wow. What an amazingly unintuitive widget. I looked all over the page
for a Next 25 files button. A Go To button that doesn't talk about
next 25 files meant nothing. ViewVC used to
On 6 August 2014 20:12, paul_kon...@dell.com wrote:
But the preferred answer in my mind is to get rid of this thing and go back
to displaying the whole page. If you do want to keep the subset thing, at
least make it NOT the default.
IIRC that causes timeouts when the site is busy, because
Snapshot gcc-4.9-20140806 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140806/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Tue, Aug 05, 2014 at 08:18:06PM -0400, Ulrich Drepper wrote:
On Tue, Aug 5, 2014 at 12:57 AM, Alan Modra amo...@gmail.com wrote:
What version linker? In particular, do you have the fix for PR12975?
The Fedora 19 version. I think it hasn't changed since then which
means it is
On 07/28/2014 17:38, Matthew Fortune wrote:
I'll switch to replying on PR61538. I had not read all the ticket
previously and although I may have found a problem it seems it may not
be the cause of this failure.
The generated code differences after the patches seem significant but
I may not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
wangzheyu tony.wang at arm dot com changed:
What|Removed |Added
CC||tony.wang at arm dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030
vries at gcc dot gnu.org changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to vries from comment #2)
I think the test-case is reading an undefined value from n-next, but that's
easy enough to fix with an intializer for node.
Since node is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62004
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
Heh, interesting set of events ;)
I have a store version that fires on mips64 with a modified testcase too, see
bug 62030.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031
Bug ID: 62031
Summary: Different results between O2 and O3 for gcc-4.7.2-5
(Debian 4.7.2-5)
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030
--- Comment #4 from vries at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #3)
(In reply to vries from comment #2)
I think the test-case is reading an undefined value from n-next, but that's
easy enough to fix with an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014
--- Comment #15 from ktkachov at gcc dot gnu.org ---
I can't reproduce this with current trunk and 4.9.1.
What exact compiler version and options did you use?
I used -O2 -mgeneral-regs-only on an aarch64-none-elf compiler
gcc version 4.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032
Bug ID: 62032
Summary: FAIL: vsnprintf-chk.c execution, -O2 -flto
-fno-use-linker-plugin -flto-partition=none
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032
--- Comment #1 from bin.cheng amker.cheng at gmail dot com ---
Only fail with lto options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
--- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Wed Aug 6 08:40:19 2014
New Revision: 213652
URL: https://gcc.gnu.org/viewcvs?rev=213652root=gccview=rev
Log:
PR rtl-optimization/61801
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
--- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Wed Aug 6 08:44:05 2014
New Revision: 213653
URL: https://gcc.gnu.org/viewcvs?rev=213653root=gccview=rev
Log:
PR rtl-optimization/61801
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
--- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Wed Aug 6 08:50:12 2014
New Revision: 213654
URL: https://gcc.gnu.org/viewcvs?rev=213654root=gccview=rev
Log:
PR rtl-optimization/61801
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62033
Bug ID: 62033
Summary: okteta 4.13.97 error at -O3 -D_FORTIFY_SOURCE=2
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62033
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
I don't see a bug here as there is one case where addSize can return 0 and with
jump threading and basic block copying, we get a zero size passed to memset.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030
--- Comment #5 from vries at gcc dot gnu.org ---
Created attachment 33258
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33258action=edit
Updated tentative patch for if-conversion, including fix for pr62030
Updated tentative patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62033
--- Comment #2 from Alan Modra amodra at gmail dot com ---
I can see where you're coming from Andrew, but what is disconcerting about this
is that the _FORTIFY_SOURCE warning is plainly incorrect here. How is one
supposed to write a string.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49571
Alan Modra amodra at gmail dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52401
Alan Modra amodra at gmail dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at
of statically initialized
data.
gcc --version
gcc (GCC) 4.10.0 20140806 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
gcc -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #65 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE ---
--- Comment #61 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
[...]
can you test and apply that patch?
I think that it needs to be applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #66 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Wed Aug 6 11:41:13 2014
New Revision: 213661
URL: https://gcc.gnu.org/viewcvs?rev=213661root=gccview=rev
Log:
2014-08-06 Richard Biener rguent...@suse.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #67 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Wed Aug 6 11:42:22 2014
New Revision: 213662
URL: https://gcc.gnu.org/viewcvs?rev=213662root=gccview=rev
Log:
2014-08-06 Richard Biener rguent...@suse.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62021
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
The problem is that get_vectype_for_scalar_type_and_size for pointers just
returns vectors of pointer sized integers instead of vectors of pointers.
So, either we need to VCE it, or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61535
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE ---
I'm seeing the same on the 4.7, 4.8, and 4.9 branches. Also
reproducible in i386-pc-solaris2.11 x sparc-solaris2.11 and
x86_64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Better patch:
Index: gcc/lto-streamer-in.c
===
--- gcc/lto-streamer-in.c (revision 213660)
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62021
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
The problem is that get_vectype_for_scalar_type_and_size for pointers just
returns vectors of pointer sized integers instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62035
Bug ID: 62035
Summary: [4.9 Regresion] wrong code building libapache-mod-perl
with -O1, works with -O1 -fno-tree-dse
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874
--- Comment #8 from Uroš Bizjak ubizjak at gmail dot com ---
After lots of debugging...
The problem is with the label that is passed as an argument to
__go_set_defer_retaddr. In function main.$thunk0, in _.179r.cse1 dump, we have:
...
(insn 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62035
--- Comment #1 from Matthias Klose doko at gcc dot gnu.org ---
seen with r213518 on the trunk as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874
--- Comment #9 from Uroš Bizjak ubizjak at gmail dot com ---
To illustrate unreliable approach, please compile following test:
--cut here--
extern void foo (void *);
int test(void)
{
__label__ bla;
foo (bla);
bla:
return 0;
}
--cut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61749
--- Comment #3 from ktkachov at gcc dot gnu.org ---
vqdmlal_lane_s16 expects an immediate/literal lane number as the fourth
argument and the builtin expansion code in aarch64-builtins.c is actually
equipped to error out when given a variable (in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874
--- Comment #10 from Andreas Schwab sch...@linux-m68k.org ---
If you never use goto *exp in the same function the value of label is
undefined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874
--- Comment #11 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Andreas Schwab from comment #10)
If you never use goto *exp in the same function the value of label is
undefined.
I did try adding goto bla: just before label, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62035
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Wed Aug 6 13:53:09 2014
New Revision: 213664
URL: https://gcc.gnu.org/viewcvs?rev=213664root=gccview=rev
Log:
2014-08-06 Richard Biener rguent...@suse.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874
--- Comment #12 from Ian Lance Taylor ian at airs dot com ---
Thanks for the analysis. See also PR 60406.
Dominik sent me a patch for 60406 but 1) he has no copyright assignment; 2) I
think that his patch does not work for SJLJ exceptions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61393
--- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org ---
Author: jamborm
Date: Wed Aug 6 13:59:18 2014
New Revision: 213666
URL: https://gcc.gnu.org/viewcvs?rev=213666root=gccview=rev
Log:
2014-08-06 Martin Jambor mjam...@suse.cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61393
Martin Jambor jamborm at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62036
Bug ID: 62036
Summary: Braced-init-list issuing -Wsequence-point warning
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62037
Bug ID: 62037
Summary: cannot pass 'int **' as a 'int const* const*'
parameter
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62037
--- Comment #1 from Michael Rolnik mrolnik at gmail dot com ---
Created attachment 33262
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33262action=edit
compiler output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608
jgreenhalgh at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
1 - 100 of 465 matches
Mail list logo
