https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104197
Bug ID: 104197
Summary: clang: gcc/cp/pt.cc:28481:19: warning: predefined
identifier is only valid inside function
[-Wpredefined-identifier-outside-function]
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104156
--- Comment #10 from rguenther at suse dot de ---
On Sat, 22 Jan 2022, cnsun at uwaterloo dot ca wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104156
>
> --- Comment #9 from Chengnian Sun ---
> Thanks, Andrew.
>
> What about -flto?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104187
Martin Liška changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100491
--- Comment #9 from Fredrik Hederstierna
---
I tested with gcc-12-20220123 snapshot, and lastest gcc now produces the same
result as gcc-10.2.0, so I agree I think this issue is resolved now.
Thanks! BR Fredrik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104019
--- Comment #9 from Rimvydas (RJ) ---
Also there are more possible teststuite failures when running with:
$ make check-target-libstdc++-v3 -k RUNTESTFLAGS="conformance.exp=17_intro*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104196
Serge Belyshev changed:
What|Removed |Added
CC||belyshev at depni dot
sinp.msu.ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104019
--- Comment #8 from Rimvydas (RJ) ---
Thank you for the patches. Testsuite now gives:
PASS: 17_intro/headers/c++1998/stdc++.cc (test for excess errors)PASS:
17_intro/headers/c++1998/stdc++_multiple_inclusion.cc (test for excess errors)
PASS:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59950
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103598
Jason Merrill changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
Levy Hsu changed:
What|Removed |Added
CC||admin at levyhsu dot com
--- Comment #9
Committed, thanks!
On Wed, Jan 19, 2022 at 5:18 PM Martin Liška wrote:
>
> On 1/19/22 10:15, shi...@iscas.ac.cn wrote:
> > |From: LiaoShihua After commit
> > 591b6e00d1bfe12932ca31530d5859f95db8a35a " riscv: fix -Wformat-diag errors
> > ", some strings in implement was changed. This patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950
--- Comment #10 from Andrew Pinski ---
Note the reason why the standard is written this way is because in K C, every
function argument was promoted to int as there were no prototypes and then the
function would cast it back to char/unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950
--- Comment #9 from Andrew Pinski ---
strchr has the same wording too:
The strchr function locates the first occurrence of c (converted to a char ) in
the string pointed to by s .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104196
--- Comment #6 from Andrew Pinski ---
Here is a new testcase where we have the same IR (including the range) in GCC
11.2.0 and the trunk:
int a = 6;
int main() {
for (;;)
{
int c = 111;
if (a < 0)
c = 1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104196
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> The problem looks like a latent bug in reassoc1.
So it looks like it is a new bug in reassoc1.
On 1/20/22 04:02, Richard Sandiford wrote:
Thanks for the patch and sorry for the (very) slow review.
Thanks for the review, Richard :).
+/* Handle a "no_sanitize_shadow_call_stack" attribute; arguments as in
+ struct attribute_spec.handler. */
+static tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104196
--- Comment #4 from Andrew Pinski ---
The problem looks like a latent bug in reassoc1.
Before:
if (a.0_1 < 0)
goto ; [41.00%]
else
goto ; [59.00%]
[local count: 440234144]:
# RANGE [-2147483646, 1]
c_6 = -2147483647 - a.0_1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104196
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Also for some reason using the C++ front-end also works around the issue ...
> (but I don't see how though).
-ffinite-loops is the difference there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104188
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104188
--- Comment #13 from CVS Commits ---
The releases/gcc-11 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:520147ba19db8034b1f911326beee104da606daa
commit r11-9489-g520147ba19db8034b1f911326beee104da606daa
Author: H.J. Lu
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104188
--- Comment #12 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:4d2321314a656dd3e30117e2a5266cbacb1e60eb
commit r12-6831-g4d2321314a656dd3e30117e2a5266cbacb1e60eb
Author: H.J. Lu
Date: Sat Jan 22
On Sun, Jan 23, 2022 at 4:35 PM Hongtao Liu wrote:
>
> On Sun, Jan 23, 2022 at 8:28 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > Return false for invalid mode on memory broadcast in bcst_mem_operand:
> >
> > (vec_duplicate:V16SF (mem/j:V4SF (reg/v/f:DI 109 [ b ])))
> >
> Yes, thanks.
I will also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104196
--- Comment #2 from Andrew Pinski ---
Here is one which shows the issue just in case fold gets in the way:
int a = 6;
int main() {
for (;;)
{
int c = 111;
if (a < 0)
c = -__INT_MAX__ - a;
int b = a;
On Sun, Jan 23, 2022 at 8:28 PM H.J. Lu via Gcc-patches
wrote:
>
> Return false for invalid mode on memory broadcast in bcst_mem_operand:
>
> (vec_duplicate:V16SF (mem/j:V4SF (reg/v/f:DI 109 [ b ])))
>
Yes, thanks.
> gcc/
>
> PR target/104188
> * config/i386/predicates.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104196
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104196
--- Comment #1 from Jakub Jelinek ---
Started with r12-4790-g4b3a325f07acebf47e82de227ce1d5ba62f5bcae
Slightly adjusted testcase:
int a = 6;
int
main ()
{
while (1)
{
int b = a < 0 && 0 < -__INT_MAX__ - a ? 0 : a;
if (b !=
c-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220123 (experimental) [master -g9718bc4b0] (GCC)
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104032
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104019
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104174
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
I thought I'd CC'd Maged on this patch, but apparently not. I've
pushed it to trunk now.
On Fri, 21 Jan 2022 at 13:50, Jonathan Wakely wrote:
>
> Tested powerpc64le-linux. Does anybody see a problem with this change?
>
>
> The non-atomic store that sets both reference counts to zero uses a
>
Tested powerpc64le-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
PR libstdc++/104032
* include/std/spanstream (basic_spanbuf(basic_spanbuf&&)): Use
mem-initializer for _M_buf.
(basic_spanbuf::Operator=(basic_spanbuf&&)): Fix ill-formed
member access.
Tested powerpc64le-linux, pushed to trunk.
We can use the new from_chars implementation when long double and double
have the same representation.
libstdc++-v3/ChangeLog:
* src/c++17/floating_from_chars.cc (USE_STRTOD_FOR_FROM_CHARS):
Define macro for case where std::from_chars
Tested powerpc64le-linux, pushed to trunk.
I broke this unintentionally in r12-4259.
libstdc++-v3/ChangeLog:
PR libstdc++/104174
* include/bits/hashtable_policy.h (_Map_base): Add partial
specialization for maps with const key types.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104032
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:51631875a2fa0af62ebda7484ac48368e1805dff
commit r12-6829-g51631875a2fa0af62ebda7484ac48368e1805dff
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104174
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:084680db9af077ca37c5523a58b6c11e090e7335
commit r12-6827-g084680db9af077ca37c5523a58b6c11e090e7335
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104019
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:2d8a9ad4a922e3248d0f6c60a6331be6f47dc435
commit r12-6826-g2d8a9ad4a922e3248d0f6c60a6331be6f47dc435
Author: Jonathan Wakely
Snapshot gcc-12-20220123 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20220123/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104182
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101072
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
On 1/22/22 16:24, Patrick Palka wrote:
Here the call to the &&-qualified toLower() is incorrectly rejected
because the object expression is deemed to be an lvalue, even though it's
really a prvalue. The object expression, instance()->applicationName(),
is expressed as an INDIRECT_REF of a
On 1/17/22 14:29, will wray wrote:
Attached
(the cut n paste looks like it removed some whitespace formatting)
Pushed, thanks! I incorporated the introduction from your initial email
in the commit message.
Jason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227
--- Comment #16 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:2da90ad39bf8fa9ee287e040d1f4411cb7a2e7ed
commit r12-6825-g2da90ad39bf8fa9ee287e040d1f4411cb7a2e7ed
Author: Will Wray
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64821
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64821
--- Comment #9 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:cbcf4a50fa21abd7a4a50a7ce47ada80b115febc
commit r12-6824-gcbcf4a50fa21abd7a4a50a7ce47ada80b115febc
Author: Andrew Pinski
Date:
From: Andrew Pinski
This is a simple patch which simplifies the __builtin_aarch64_sqrt* builtins
into the internal function SQRT which allows for constant folding and other
optimizations at the gimple level. It was originally suggested we do to
__builtin_sqrt just for __builtin_aarch64_sqrtdf
On Tue, 18 Jan 2022, Palmer Dabbelt wrote:
> Yep. Seeing this go by, though, I think there's some English issues with the
> original messages. I'd write it more like this, but I'm never 100% sure on
> these things:
>
>diff --git a/gcc/common/config/riscv/riscv-common.cc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103782
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103782
--- Comment #9 from CVS Commits ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:7fecbf36d174c8005e8c5cfb7089c6bd4d0f6a79
commit r9-9923-g7fecbf36d174c8005e8c5cfb7089c6bd4d0f6a79
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104191
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104128
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
Dear Fortranners,
conversions between different character kinds using TRANSFER exhibit
inconsistencies that can occur between expr->representation.string
(which is char*) on the one hand, and expr->->value.character.string.
One issue (in target-memory.cc) is easily fixed by simply passing
a
Hi, sir.
I've been trying to understand the static analyzer's code. I spent most of
my time learning the state machine's API. I learned how state machine's
on_stmt is supposed to "recognize" specific functions and how on_transition
takes a specific tree from one state to another, and how the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104128
--- Comment #6 from anlauf at gcc dot gnu.org ---
The remaining issues in this PR seem to be related to inconsistencies
between expr->representation.string and expr->value.character.string
that occur for non-default character kind that are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83079
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:a8c234519366b9a93a4bbc0717d609de27ccdc0e
commit r11-9487-ga8c234519366b9a93a4bbc0717d609de27ccdc0e
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194
--- Comment #1 from Segher Boessenkool ---
Maybe we should say what actual mode is used in the DWARF info, not the C
way of getting there? So something that denotes DP / double-double / QP,
for our three options for long double?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104188
--- Comment #11 from H.J. Lu ---
The v2 patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589125.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104195
--- Comment #2 from Andrew Pinski ---
For char, 2, unsigned int (on aarch64, I suspect x86_64 is similar):
(set (reg/i:SI 0 x0)
(zero_extend:SI (mem:QI (plus:DI (and:DI (subreg:DI (reg/v:SI 99 [ i ]) 0)
(const_int 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104195
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104192
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Thanks for the review.
Here's the updated patch.
Le mardi 18 janvier 2022 à 18:22 -0500, David Malcolm a écrit :
> On Mon, 2022-01-17 at 21:02 -0500, Antoni Boucher via Gcc-patches
> wrote:
> > Hi.
> > This option will be useful for rustc_codegen_gcc to hide the error
> > about unsupported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104195
Bug ID: 104195
Summary: Fails to optimize nested array indexing
p[i/N].data[i%N]
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Hello,
Le 21/01/2022 à 00:59, David Malcolm via Gcc-patches a écrit :
diff --git a/gcc/analyzer/constraint-manager.cc
b/gcc/analyzer/constraint-manager.cc
index 568e7150ea7..7c4a85bbb24 100644
--- a/gcc/analyzer/constraint-manager.cc
+++ b/gcc/analyzer/constraint-manager.cc
@@ -301,6 +301,80
Le 23/01/2022 à 11:05, FX a écrit :
Hi Mikael,
I spotted two unexpected things (to me at least) related to x86 extended type:
- You check for endianness, so the format is not x86-specific?
- Is it expected that the padding bits are in the middle of the data in the
big-endian case?
IEEE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194
Bug ID: 104194
Summary: No way to distinguish IEEE and IBM long double in
debug info
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39270
Patrick Palka changed:
What|Removed |Added
CC||fchelnokov at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104193
--- Comment #2 from Patrick Palka ---
er, dup of PR39270 rather
*** This bug has been marked as a duplicate of bug 39270 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39720
Patrick Palka changed:
What|Removed |Added
CC||fchelnokov at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104193
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104193
Bug ID: 104193
Summary: Valid function template instantiation rejected
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69818
Frank Heckenbach changed:
What|Removed |Added
CC||f.heckenb...@fh-soft.de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104192
Bug ID: 104192
Summary: Uninitialized object read is not detected in a
constant expression
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Am Sa., 15. Jan. 2022 um 14:56 Uhr schrieb Marc Nieper-Wißkirchen
:
>
> Jeff, David, do you need any more input from my side?
>
> -- Marc
>
> Am Sa., 8. Jan. 2022 um 17:32 Uhr schrieb Jeff Law :
> >
> >
> >
> > On 1/6/2022 6:53 AM, David Malcolm via Gcc-patches wrote:
> > > On Sun, 2021-12-19 at
Return false for invalid mode on memory broadcast in bcst_mem_operand:
(vec_duplicate:V16SF (mem/j:V4SF (reg/v/f:DI 109 [ b ])))
gcc/
PR target/104188
* config/i386/predicates.md (bcst_mem_operand): Also check mode
of memory broadcast.
gcc/testsuite/
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104189
--- Comment #3 from John Paul Adrian Glaubitz ---
(In reply to Eric Botcazou from comment #2)
> Created attachment 52272 [details]
> Tentative fix
Thanks a lot for the quick fix.
> This requires that the kernel preserves the full 64-bit
On Sun, Jan 23, 2022 at 10:06:24AM +0100, Uros Bizjak wrote:
> > 2022-01-22 Jakub Jelinek
> >
> > * config/linux.h (OPTION_GLIBC_P, OPTION_UCLIBC_P,
> > OPTION_BIONIC_P, OPTION_MUSL_P): Define.
> > (OPTION_GLIBC, OPTION_UCLIBC, OPTION_BIONIC, OPTION_MUSL): Redefine
> >
Hi Mikael,
> I spotted two unexpected things (to me at least) related to x86 extended type:
> - You check for endianness, so the format is not x86-specific?
> - Is it expected that the padding bits are in the middle of the data in the
> big-endian case?
IEEE specifies that extended precision
在 2022/1/23 下午5:00, Xi Ruoyao 写道:
On Sun, 2022-01-23 at 16:39 +0800, 程璐璐 wrote:
在 2022/1/22 下午4:42, Xi Ruoyao 写道:
On Sat, 2022-01-22 at 15:55 +0800, Chenghua Xu wrote:
+mstrict-align
+Target Var(TARGET_STRICT_ALIGN) Init(0)
+Do not generate unaligned memory accesses.
Section 2.1.8
> Does anyone know the reasoning behind this?
Solaris preserves the full 64-bit registers in 32-bit mode.
--
Eric Botcazou
> While playing around with the compiler options trying to find a solution, I
> made an interesting discovery which is that GCC support 64-bit compare and
> swap on SPARCv8plus but not on 32-bit SPARCv9:
>
> glaubitz@gcc202:~$ echo | gcc -mv8plus -E -dM -|grep -i SWAP
> #define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104189
--- Comment #2 from Eric Botcazou ---
Created attachment 52272
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52272=edit
Tentative fix
This requires that the kernel preserves the full 64-bit registers even in
32-bit mode, like on
On Sat, Jan 22, 2022 at 7:04 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Sat, Jan 22, 2022 at 01:16:38PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > Actually, I suspect we either need something like following patch,
> > or need to change gcc/config/{linux,rs6000/linux{,64},alpha/linux}.h
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104189
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |12.0
Ever confirmed|0
On Sun, 2022-01-23 at 16:39 +0800, 程璐璐 wrote:
>
> 在 2022/1/22 下午4:42, Xi Ruoyao 写道:
>
>
> > On Sat, 2022-01-22 at 15:55 +0800, Chenghua Xu wrote:
> >
> >
> > > +mstrict-align
> > > +Target Var(TARGET_STRICT_ALIGN) Init(0)
> > > +Do not generate unaligned memory accesses.
> > Section 2.1.8
在 2022/1/22 下午4:42, Xi Ruoyao 写道:
On Sat, 2022-01-22 at 15:55 +0800, Chenghua Xu wrote:
+mstrict-align
+Target Var(TARGET_STRICT_ALIGN) Init(0)
+Do not generate unaligned memory accesses.
Section 2.1.8 of LoongArch spec says "load/store instruction *may* be
implemented to allow unaligned
在 2022/1/22 下午5:31, Jakub Jelinek 写道:
On Sat, Jan 22, 2022 at 05:05:00PM +0800, Xi Ruoyao wrote:
On Sat, 2022-01-22 at 16:56 +0800, 程璐璐 wrote:
Under the MIPS architecture, *.opt files are also generated in
$(srcdir).
Well, but then you should put the commands for generating those files
87 matches
Mail list logo
