https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844
--- Comment #10 from Jakub Jelinek ---
Please see https://gcc.gnu.org/ml/gcc-patches/2009-04/msg01490.html for
reasoning why gcc considers it valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #6 from Sven C. Dack ---
It seems the problem is caused by the use of the jobserver. Changing
bootstrap-lto.mk from:
...
STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects
STAGE3_CFLAGS += -flto=jobserver -frandom-see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Sven C. Dack changed:
What|Removed |Added
Attachment #33285|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #8 from Andrew Pinski ---
(In reply to Sven C. Dack from comment #7)
> Created attachment 33299 [details]
> Removes the use of the jobserver from bootstrap-lto.mk
>
> The patch changes bootstrap-lto.mk to use a single, unpartitioned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844
--- Comment #11 from David Krauss ---
On 2014–08–12, at 3:10 PM, jakub at gcc dot gnu.org
wrote:
> Please see https://gcc.gnu.org/ml/gcc-patches/2009-04/msg01490.html for
> reasoning why gcc considers it valid.
That reasoning goes awry at “ISO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #10 from rguenther at suse dot de ---
On Tue, 12 Aug 2014, trippels at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
>
> Markus Trippelsdorf changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #9 from Jakub Jelinek ---
(In reply to Jeffrey A. Law from comment #6)
> It's late and I need to catch some zzzs. But as I hinted in my prior update,
> I think we may chasing something latent. I would recommend looking very
> closel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #11 from Venkataramanan ---
I am also trying to fix LTO bootstrap compare failure in Aarch64.
Bootstrap compare failure is not occurring in GCC FSF trunk (tested on aarch64
as well as x86_64 machine). Now I am doing one more round of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011
--- Comment #7 from Yuri Rumyantsev ---
Please ignore my previous comment - if we insert nullifying of destination
register before each popcnt (and lzcnt) performance will restore:
original test results:
unsigned8388663 0.848533
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #10 from Jakub Jelinek ---
And with:
--- sched-deps.c(revision 207605)
+++ sched-deps.c(working copy)
@@ -3034,6 +3034,21 @@ sched_analyze_insn (struct deps_desc *de
|| (NONJUMP_INSN_P (insn) && control_flow_insn_p (in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62104
Bug ID: 62104
Summary: [4.10 Regression] ICE: in
update_visibility_by_resolution_info, at
ipa-visibility.c:403
Product: gcc
Version: 4.10.0
Status: UN
braries like -lgcc and -lc are placed correctly maybe the
-l*san can be moved too?
I used a gcc built from recent SVN head on Ubuntu 14.04 amd64.
/tmp/jtaylor $ gcc-4.10 --version
gcc (GCC) 4.10.0 20140812 (experimental)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #12 from Richard Biener ---
Ok, so there is one thing that changed (but only very recently) on trunk which
is improved hashing of SCCs and thus more consistent ordering.
Especially I'm talking about the fact that at compile-time (!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62106
Bug ID: 62106
Summary: Adding a scalar variable to an array constructor gives
wrong result
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: major
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62106
--- Comment #1 from Martien Hulsen ---
It only shows up using optimisation, i.e. -On, with n>=1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62104
--- Comment #1 from Markus Trippelsdorf ---
markus@x4 /tmp % wget trippelsdorf.de/testcase.tar.bz2
--2014-08-12 12:07:24-- http://trippelsdorf.de/testcase.tar.bz2
Resolving trippelsdorf.de... 194.117.254.50
Connecting to trippelsdorf.de|194.117.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #13 from Richard Biener ---
(In reply to Richard Biener from comment #12)
> Ok, so there is one thing that changed (but only very recently) on trunk
> which
> is improved hashing of SCCs and thus more consistent ordering.
>
> Especia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #12 from amker at gcc dot gnu.org ---
Hi,
I can reproduce the exact mis-scheduled instruction issue as in Jakub's comment
with/without the ivopt patch (204497). Turns out gcc chooses candidate like
{&K512, 128}_loop with the patch wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011
--- Comment #8 from finis at in dot tum.de ---
@Yuri: Note however, that the result of your fixed u32 version seems to be
wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #14 from Venkataramanan ---
(In reply to Sven C. Dack from comment #6)
> It seems the problem is caused by the use of the jobserver. Changing
> bootstrap-lto.mk from:
>
> ...
> STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #13 from Jakub Jelinek ---
Just verified the trunk and it is the same thing there, also sched2 generating:
al %r3,252(%r8)
ahi %r8,128
alc %r2,120(%r8)
where the first insn is cc setter, second cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #15 from Sven C. Dack ---
(In reply to Venkataramanan from comment #14)
> ...
> I tried addding to stage2/3 the flags "-flto=1 -flto-partition=none" instead
> of jobserver in bootstrap-lto.mk and spawned bootstrap LTO build in one
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011
--- Comment #9 from Yuri Rumyantsev ---
This is not u32 version but u64. The first loop (u32) version looks like:
.L23:
leal1(%rdx), %ecx
xorq%rax, %rax
popcntq(%rbx,%rax,8), %rax
leal2(%rdx), %r8d
xorq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
--- Comment #2 from Peter A. Bigot ---
Thanks. The compiler and libstdc++ are built using Yocto's standard recipe for
the beaglebone. Obviously there's something wrong with it; what that would be
is not obvious and probably isn't a gcc problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61373
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62107
Bug ID: 62107
Summary: libgomp.fortran/target2.f90 FAIL while compiling for
OpenMP 4.0 offload target
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
Jakub Jelinek changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
--- Comment #3 from Jonathan Wakely ---
It might be obvious in the output of 'gcc -v'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60281
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #15 from Jakub Jelinek ---
So, what about this completely untested fix? Unfortunately the scheduler
change has been committed with no testcases. I guess I'll do a
bootstrap/regtest with some printout where this patch changes things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62098
Ramana Radhakrishnan changed:
What|Removed |Added
Keywords||wrong-code
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61962
--- Comment #1 from Kirill Yukhin ---
Author: kyukhin
Date: Tue Aug 12 12:27:41 2014
New Revision: 213858
URL: https://gcc.gnu.org/viewcvs?rev=213858&root=gcc&view=rev
Log:
PR other/61962
gcc/c-family/
* array-notation-common.c (find_ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61962
--- Comment #2 from Kirill Yukhin ---
Author: kyukhin
Date: Tue Aug 12 12:33:06 2014
New Revision: 213859
URL: https://gcc.gnu.org/viewcvs?rev=213859&root=gcc&view=rev
Log:
PR other/61962
gcc/c-family/
* array-notation-common.c (find_rank):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
--- Comment #4 from Peter A. Bigot ---
It's not obvious to me:
beaglebone[98]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/gcc/arm-poky-linux-gnueabi/4.9.1/lto-wrapper
Target: arm-poky-linux-gnueabi
Configured w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62098
Ramana Radhakrishnan changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #16 from Richard Biener ---
Ok, so what happens is that for build/genconfig.o we in one case write
a STRING_CST with a const char[7] with itself as main-variant and in
the other case with char[7] as main-variant. The STRING_CST is
wr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62106
Dominique d'Humieres changed:
What|Removed |Added
Keywords||wrong-code
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62098
--- Comment #2 from Ramana Radhakrishnan ---
Created attachment 33300
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33300&action=edit
Patch under testing.
Embarassing patch to fix the issue. Currently being tested .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62104
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61373
--- Comment #2 from John Breitenbach ---
Created attachment 33301
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33301&action=edit
siphash24.i
sorry for forgetting this attachment in the original report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to David Krauss from comment #6)
> I'd like to take it 100% but the testsuite isn't working on my system. The
> patch is small enough and unobscure enough that it's easier for someone else
> t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
--- Comment #9 from Mike Frysinger ---
i've verified that 4.8.0 & 4.9.1 fail as well :/
binutils 2.24 doesn't help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #16 from Jeffrey A. Law ---
In reference to c#12. I think the ivopts changes are just setting up the
situation that is mis-handled later. I'd gotten as far as seeing the +128
increment moving in the scheduler, but hadn't looked to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844
--- Comment #12 from joseph at codesourcery dot com ---
On Tue, 12 Aug 2014, potswa at mac dot com wrote:
> > each instance of a ## preprocessing token in the replacement list (not
> > from an argument) is deleted and the preceding preprocessin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62098
--- Comment #3 from Ramana Radhakrishnan ---
Author: ramana
Date: Tue Aug 12 14:32:07 2014
New Revision: 213861
URL: https://gcc.gnu.org/viewcvs?rev=213861&root=gcc&view=rev
Log:
Fix PR target/62098
2014-08-12 Ramana Radhakrishnan
PR ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844
--- Comment #13 from joseph at codesourcery dot com ---
Also, in the case of just two consecutive ##, with a placemarker either
side, I think however you read it the concatenations are currently valid
and you end up with no preprocessing tokens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61413
--- Comment #2 from Ramana Radhakrishnan ---
Author: ramana
Date: Tue Aug 12 14:59:23 2014
New Revision: 213864
URL: https://gcc.gnu.org/viewcvs?rev=213864&root=gcc&view=rev
Log:
Fix PR target/61413
2014-08-12 Ramana Radhakrishnan
PR t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357
--- Comment #4 from Dominique d'Humieres ---
Note that while
program testerprog
use testmod
Type(A) :: Me
Me%y=2
print *, Me%x, Me%y
end program
gives at run time
1 2
program testerprog
us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62087
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62094
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62108
Bug ID: 62108
Summary: Resolution of mismatched __attribute__ ((__section__
(""))) changes between 4.9 and 4.10.
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62094
--- Comment #5 from Steve Kargl ---
On Tue, Aug 12, 2014 at 03:40:06PM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62094
>
> Dominique d'Humieres changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62108
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848
Andrew Pinski changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54078
--- Comment #10 from wbrana ---
there is difference also with O2 and branch 4.9
size in bytes
57199 -O2
55222 -O2 -flto
60681 -O2 -finline-functions
75301 -O2 -flto -finline-functions
67083 -O2 -flto -finline-functions --param large-unit-insns=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61274
--- Comment #2 from wbrana ---
gcc should probably support new level -O4 which will optimize for benchmarks,
which will equal to current -O3
-O3 and bellow will optimize for applications with saner "--param" values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
Bug ID: 62109
Summary: __gthr_i486_lock_cmp_xchg missing clobber
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336
H.J. Lu changed:
What|Removed |Added
Component|target |c++
Version|4.8.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62110
Bug ID: 62110
Summary: Attempting to use template conversion operator in a
contextual conversion
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
Bug ID: 62111
Summary: ICE when building Linux kernel for sh64
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
--- Comment #1 from dhowells at redhat dot com ---
The following command line is sufficient to reproduce the error:
sh64-linux-gnu-gcc -m5-64media-nofpu -ml -O2 -S -o testcase.o testcase.i
Adding -v to the command line:
Using built-in specs.
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
--- Comment #2 from dhowells at redhat dot com ---
The binutils is based on the 2.24 branch, git commit
cab6c3ee9785f072a373afe31253df0451db93cf and was built targeting
sh64-linux-elf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62112
Bug ID: 62112
Summary: Optimize out malloc when block is unused or write-only
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62113
Bug ID: 62113
Summary: [graphite] ICE using -floop-parallelize-all
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62114
Bug ID: 62114
Summary: [graphite] ICE using -floop-parallelize-all and
-ffast-math
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
Oleg Endo changed:
What|Removed |Added
Target||sh*-*-*
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
--- Comment #4 from dhowells at redhat dot com ---
The compiler is gcc-4.9.1, dated 20140717, svnrev 212747.
One patch is applied - see bug 61844.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62110
--- Comment #1 from Jonathan Wakely ---
N3323 is not addressing a DR, so is not part of C++11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62112
--- Comment #1 from Marc Glisse ---
Main issue here is that DSE only applies to assignments and not function calls
like memcpy (there must be a few dups somewhere), so we never remove memcpy,
even if we call free(x);free(y); afterwards. With a fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62112
--- Comment #2 from Zack Weinberg ---
I observe that the `memcpy` does get lowered to inline code. Is it just a
phase-ordering problem that we then don't detect the stores as dead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #17 from Jakub Jelinek ---
Author: jakub
Date: Tue Aug 12 21:24:40 2014
New Revision: 213887
URL: https://gcc.gnu.org/viewcvs?rev=213887&root=gcc&view=rev
Log:
PR target/62025
* sched-deps.c (find_inc): Check if inc_insn does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #18 from Jakub Jelinek ---
Author: jakub
Date: Tue Aug 12 22:03:37 2014
New Revision: 213888
URL: https://gcc.gnu.org/viewcvs?rev=213888&root=gcc&view=rev
Log:
PR target/62025
* sched-deps.c (find_inc): Check if inc_insn does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742
--- Comment #38 from Steve Ellcey ---
FYI: I am testing a new patch for this that adds a new pass to do this
optimization. See https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01228.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336
--- Comment #23 from Andrew Pinski ---
(In reply to H.J. Lu from comment #22)
> This is a target independent issue. Clang++ skips empty struct argument
> and g++ passes it. Skip empty struct argument requires middle-end changes.
Except in c++,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62085
--- Comment #3 from James Lyon ---
Thanks for looking! Unfortunately I don't have access to EDG. I have dug
through the standard and it seems my understanding of SFINAE was (is) a
bit lacking and GCC is indeed correct. It seems there's a bug in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62115
Bug ID: 62115
Summary: [4.10 Regression] ICE with invalid default argument
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62115
Volker Reichelt changed:
What|Removed |Added
Target Milestone|--- |4.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62110
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #2 from TC ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54773
--- Comment #2 from chihin ko ---
g++ 4.8.1 on Linux fixed the problem, but problem still exists in g++ 4.8.1 on
solaris.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62116
Bug ID: 62116
Summary: Allowing redeclaration of global variable x using ::x
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336
--- Comment #24 from vagran ---
Just to be on a safe side, please, also do not forget that empty struct (or
class) is really zero in the case when another structure (or class) is derived
from it. For example, such test would be useful after fix:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62024
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62024
--- Comment #2 from Amanieu d'Antras ---
A similar error happens when trying to use the result of
__atomic_always_lock_free as the size of an array:
int array[__atomic_always_lock_free(sizeof(int), 0)];
test.c:1:5: error: variably modified ‘arr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62024
--- Comment #3 from Marek Polacek ---
(In reply to Amanieu d'Antras from comment #2)
> int array[__atomic_always_lock_free(sizeof(int), 0)];
>
> test.c:1:5: error: variably modified ‘array’ at file scope
I think it should be fine to reject this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62059
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62117
Bug ID: 62117
Summary: [4.9 regression] wrong code for passing small array
argument'Address, in generic
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62088
Marek Polacek changed:
What|Removed |Added
CC||dodji at gcc dot gnu.org,
93 matches
Mail list logo
